cdh4b1之HDFS的HA(High Availability)原理简介

2019-03-28 13:49|来源: 网络

0 引入

         以前Hadoop版本中,NameNodeHDFS集群的单点故障(single point of failure,SPoF)SPoF指系统中这个部件失效或停止运转将会导致整个系统不能工作。而这在下面两种情况出现:

         (1) 意外事件如机器crash,集群直到重启NameNode操作执行后才可用;

         (2) 计划维修事件,如NameNode上的软硬件升级会导致NameNode一段宕机时间。

         HDFS HA提供在一个集群中配置两台冗余NN来解决上述问题,是一种双机热备。这可以在NN崩溃时快速的故障恢复,同时在自发管理的计划维修时快速失效备援。当前hadoop版本是hadoop-0.23.0-cdh4b1

         HA主要机制是:两个单独机器运行NN,在所有时刻只有一台出于active状态,而另外一台出于standby状态。active NN负责客户端对集群的所有操作,而Standby NN作为从设备只是保存足够的状态来进行快速的故障恢复。

 

HA总体流程图

         Block location: 为了快速failoverstandby NN必须知道这个的相关信息。为了达到此目的,所有DN上都配置了此两个NN,并且发送block locationheartbeat到两个NN上。

         至关重要的一点:只有一个Active NN.两个NN都是active即所谓脑裂情景(split-brain scenario),因此管理员必须设置一个对共享存储的fencing method(绝缘方法),当不能确定前Active NN不会自己重新变成active时,需要切断其对共享存储的访问权限,如此便能使新active NN安全的故障恢复。

         standby NN也执行namespace的状态检查,因此HA集群不需要运行Secondary NN, Checkpoint Node, Backup Node

下面是详细的配置安装,请参见CDH4_High_Availability_Guide_b1.pdf。

免费下载地址在 http://linux.linuxidc.com/

用户名与密码都是www.linuxidc.com

具体下载目录在 /2012年资料/4月/19日/cdh4b1之HDFS的HA(High Availability)原理简介/

1 软硬件配置

1.1硬件配置

(1)NN机器,两台配置相同的机器来运行active standby NN, 并且这两台机器的配置和用non-HA集群时 NN的配置相同。

(2)两个NN都有读写权限的共享存储:多路径到存储,自身的冗余(disk, network, power)。鉴于上面这些,推荐共享存储服务器用高级专用的网络连接式存储(NAS)设备,而非简单的LinuxServer

1.2 软件配置

NamesService ID

NameNode ID

2 HA部署

3 HA管理

更多Hadoop相关信息见Hadoop 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=13

相关问答

更多
  • 看起来您在/ etc / hadoop / conf目录中使用了错误的客户端配置。 有时Cloudera Manager(CM)部署客户端配置选项可能不起作用。 正如您启用NN HA,您应该在hadoop客户端配置目录中拥有有效的core-site.xml和hdfs-site.xml文件。 要获取有效的站点文件,请从CM转到HDFS服务从“ 操作”按钮中选择“ 下载客户端配置”选项。 您将以zip格式获取配置文件,解压zip文件,并用提取的core-site.xml替换/etc/hadoop/conf/co ...
  • 使用DNS负载平衡 ,这基本上是循环DNS 。 DNS负载平衡是在域名系统(DNS)中配置域的做法,以便客户端对域的请求分布在一组服务器计算机上。 域可以对应于网站,邮件系统,打印服务器或可通过因特网访问的其他服务。 在您的情况下,服务器组分布在云提供商之间。 很多警告和挑战,但它是可能的。 另请参阅在AWS和Rackspace之间进行负载平衡的最佳方法 。 类似的用例。 Use DNS load balancing, which is basically Round robin DNS. DNS load ...
  • 对于StackOverflow,您的问题可能有点宽泛,但我处于您的情况,所以我可以同情。 粘性会话不是首选,因为需要使用它们会表明您的应用程序不是无状态的。 换句话说,您需要粘性会话,这意味着您的应用程序依赖于服务器内存进行会话管理,因此,一旦初始化会话,该用户必须在整个会话期间保持在该服务器上。 这是可以的,但不太理想(相比之下,如果您的请求根本不关心它运行的是哪个服务器实例),因为如果您的流量速度减慢并且Elastic Beanstalk决定终止您所使用的实例,那么下一步请求当负载均衡器将您路由到另一个 ...
  • Cloudera Manager不支持将多个NameNode添加到同一物理主机,因此无法进行列出的配置。 这是为了避免NameNode主机过载而设计的。 如果要为3个单独的命名空间启用高可用性,则需要将群集扩展为6个节点。 Cloudera Manager doesn't support adding multiple NameNodes to the same physical host, so the configuration you listed won't be possible. This is ...
  • 对于ASF Hadoop 1.1.2,没有可靠的NameNode HA选项。 这些是2.0版本发布的,包含在像Cloudera的CDH4这样的流行发行版中。 NameNode HA的选项包括运行主NameNode和热备用NameNode。 它们共享编辑日志,可以是NFS挂载,也可以是HDFS本身的仲裁日志模式。 前者为您提供了存储HDFS元数据的外部源的好处,而后者为您提供了Hadoop外部无依赖性的好处。 就个人而言,我喜欢NFS选项,因为您可以轻松快照/备份驻留在文件服务器上的数据。 这种方法的缺点是在 ...
  • 事实证明Snakebite没有一个,而是两个解决这个问题的方法: AutoConfigClient ,它将从hadoop配置中获取配置,而HAClient则需要两个名称节点 。 就我而言,我实际上是通过气流使用蛇咬伤。 事实证明,气流的HDFSHook非常智能,可以应对在一个连接中提供的两个名称节点,然后使用HAClient。 It turns out that Snakebite has not one, but two solutions to this problem: AutoConfigClien ...
  • namenode和jobtracker共享一个类似的HA实现,只要它们都扩展了相同的基类。 它们都使用后备zookeeper集群来决定哪个可用节点处于活动状态。 zookeeper中使用的位置是通过将故障转移组名称(即dfs.nameservices和mapred.job.tracker给出的值) mapred.job.tracker到可配置前缀来构造的。 对于这两种服务,默认情况下可配置前缀为/hadoop-ha 。 这意味着如果两个服务配置了相同的故障转移组名称(例如, my-application ) ...
  • HDFS高可用性和HDFS联合之间的主要区别在于联合中的名称节点彼此不相关。 在HDFS联合中,所有名称节点共享一个元数据池,其中每个名称节点都有自己的池,因此提供了容错功能,即如果联合中的一个名称节点失败,则不会影响其他名称节点的数据。 所以,Federation =多个名称节点,没有相关性。 在HDFS HA的情况下,有两个名称节点 - 主NN和备用NN。 主NN每次都很努力,而Standby NN只是坐在那里,并且偶尔会对主要Namenode的元数据进行冷却和更新,这使得它们相关。 当主要NN厌倦了这 ...
  • 是的我相信这是一个错误:issues.apache.org/jira/browse/FLINK-6000。 它已经有一个待定的PR。 Yes I believe it is a bug: issues.apache.org/jira/browse/FLINK-6000. It has already a pending PR.
  • 流接收器是位于多个工作节点还是驱动程序机器 接收器位于工作节点上, 工作节点负责消耗保存数据的源。 如果其中一个接收数据的节点出现故障(断电/重启)会发生什么 接收器位于工作节点上。 工作节点从驱动程序获取它的任务。 如果您在客户端模式下运行,则此驱动程序可以位于专用主服务器上;如果您在群集模式下运行,则该驱动程序可以位于其中一个工作服务器上。 如果节点发生故障且未运行驱动程序,则驱动程序会将故障节点上保存的分区重新分配给另一个节点,然后可以从源中重新读取数据,并执行其他操作。从故障中恢复所需的处理。 这就 ...