《Hadoop权威指南：大数据的存储与分析》—3.2.5 HDFS的高可用性

3.2.5  HDFS的高可用性

通过联合使用在多个文件系统中备份namenode的元数据和通过备用namenode创建监测点能防止数据丢失，但是依旧无法实现文件系统的高可用性。namenode 依旧存在单点失效(SPOF, single point of failure)的问题。如果namenode失效了，那么所有的客户端，包括MapReduce作业，均无法读、写或列举(list)文件，因为namenode是唯一存储元数据与文件到数据块映射的地方。在这一情况下，Hadoop系统无法提供服务直到有新的namenode上线。

在这样的情况下，要想从一个失效的namenode恢复，系统管理员得启动一个拥有文件系统元数据副本的新的namenode，并配置datanode和客户端以便使用这个新的namenode。新的namenode直到满足以下情形才能响应服务：(1)将命名空间的映像导入内存中；(2)重演编辑日志；(3)接收到足够多的来自datanode的数据块报告并退出安全模式。对于一个大型并拥有大量文件和数据块的集群，namenode的冷启动需要30分钟，甚至更长时间。

系统恢复时间太长，也会影响到日常维护。事实上，预期外的namenode失效出现概率很低，所以在现实中，计划内的系统失效时间实际更为重要。

Hadoop2针对上述问题增加了对HDFS高可用性(HA)的支持。在这一实现中，配置了一对活动-备用(active-standby) namenode。当活动namenode失效，备用namenode就会接管它的任务并开始服务于来自客户端的请求，不会有任何明显中断。实现这一目标需要在架构上做如下修改。

namenode之间需要通过高可用共享存储实现编辑日志的共享。当备用namenode接管工作之后，它将通读共享编辑日志直至末尾，以实现与活动namenode的状态同步，并继续读取由活动namenode写入的新条目。

datanode需要同时向两个namenode发送数据块处理报告，因为数据块的映射信息存储在namenode的内存中，而非磁盘。

客户端需要使用特定的机制来处理namenode的失效问题，这一机制对用户是透明的。

辅助namenode的角色被备用namenode所包含，备用namenode为活动的namenode命名空间设置周期性检查点。

可以从两种高可用性共享存储做出选择：NFS过滤器或群体日志管理器(QJM，quorum journal manager)。QJM是一个专用的HDFS实现，为提供一个高可用的编辑日志而设计，被推荐用于大多数HDFS部署中。QJM以一组日志节点(journal node)的形式运行，每一次编辑必须写入多数日志节点。典型的，有三个journal节点，所以系统能够忍受其中任何一个的丢失。这种安排与ZooKeeper的工作方式类似，当然必须认识到，QJM的实现并没使用ZooKeeper。(然而，值得注意的是，HDFS HA在选取活动的namenode时确实使用了ZooKeeper技术，详情参见下一章。)

在活动namenode失效之后，备用namenode能够快速(几十秒的时间)实现任务接管，因为最新的状态存储在内存中：包括最新的编辑日志条目和最新的数据块映射信息。实际观察到的失效时间略长一点(需要1分钟左右)，这是因为系统需要保守确定活动namenode是否真的失效了。

在活动namenode失效且备用namenode也失效的情况下，当然这类情况发生的概率非常低，管理员依旧可以声明一个备用namenode并实现冷启动。这类情况并不会比非高可用(non-HA)的情况更差，并且从操作的角度讲这是一个进步，因为上述处理已是一个标准的处理过程并植入Hadoop中。

系统中有一个称为故障转移控制器(failover controller)的新实体，管理着将活动namenode转移为备用namenode的转换过程。有多种故障转移控制器，但默认的一种是使用了ZooKeeper来确保有且仅有一个活动namenode。每一个namenode运行着一个轻量级的故障转移控制器，其工作就是监视宿主namenode是否失效(通过一个简单的心跳机制实现)并在namenode失效时进行故障切换。

管理员也可以手动发起故障转移，例如在进行日常维护时。这称为“平稳的故障转移”(graceful failover)，因为故障转移控制器可以组织两个namenode有序地切换角色。

但在非平稳故障转移的情况下，无法确切知道失效namenode是否已经停止运行。例如，在网速非常慢或者网络被分割的情况下，同样也可能激发故障转移，但是先前的活动namenode依然运行着并且依旧是活动namenode。高可用实现做了更进一步的优化，以确保先前活动的namenode不会执行危害系统并导致系统崩溃的操作，该方法称为“规避”(fencing)。

同一时间QJM仅允许一个namenode向编辑日志中写入数据。然而，对于先前的活动namenode而言，仍有可能响应并处理客户过时的读请求，因此，设置一个SSH规避命令用于杀死namenode的进程是一个好主意。当使用NFS过滤器实现共享编辑日志时，由于不可能同一时间只允许一个namenode写入数据(这也是为什么推荐QJM的原因)，因此需要更有力的规避方法。规避机制包括：撤销namenode访问共享存储目录的权限（通常使用供应商指定的NFS命令）、通过远程管理命令屏蔽相应的网络端口。诉诸的最后手段是，先前活动namenode可以通过一个相当形象的称为“一枪爆头”STONITH，shoot the other node in the head)的技术进行规避，该方法主要通过一个特定的供电单元对相应主机进行断电操作。

客户端的故障转移通过客户端类库实现透明处理。最简单的实现是通过客户端的配置文件实现故障转移的控制。HDFS URI使用一个逻辑主机名，该主机名映射到一对namenode地址(在配置文件中设置)，客户端类库会访问每一个namenode地址直至处理完成。

Hadoop 大数据

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。