hadoop namenode 高可用（HA）搭建指南 QJM方式

一、HDFS的高可用性

1.概述

         本指南提供了一个HDFS的高可用性（HA）功能的概述，以及如何配置和管理HDFS高可用性(HA)集群。本文档假定读者具有对HDFS集群的组件和节点类型具有一定理解。有关详情，请参阅Apache的HDFS的架构指南。

http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/HDFSHighAvailabilityWithQJM.html

2.背景

         CDH4之前，在HDFS集群中NameNode存在单点故障（SPOF）。对于只有一个NameNode的集群，如果NameNode机器出现故障，那么整个集群将无法使用，直到NameNode重新启动。

NameNode主要在以下两个方面影响HDFS集群:

(1). NameNode机器发生意外，比如宕机，集群将无法使用，直到管理员重启NameNode

(2). NameNode机器需要升级，包括软件、硬件升级，此时集群也将无法使用

         HDFS的HA功能通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode很快的切换到另外一台机器。

3.架构

         HDFSHA的解决方案可谓百花齐放，Linux HA, VMware FT, sharedNAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode等等。目前普遍采用的是shard NAS+NFS，因为简单易用，但是需要提供一个HA的共享存储设备。而社区已经把基于QJM/Quorum Journal Manager的方案merge到trunk了，clouderea提供的发行版中也包含了这个feature，这种方案也是社区在未来发行版中默认的HA方案。

         在HA具体实现方法不同的情况下，HA框架的流程是一致的。不一致的就是如何存储和管理日志。在Active NN和Standby NN之间要有个共享的存储日志的地方，Active NN把EditLog写到这个共享的存储日志的地方，Standby NN去读取日志然后执行，这样Active和Standby NN内存中的HDFS元数据保持着同步。一旦发生主从切换Standby NN可以尽快接管Active NN的工作（虽然要经历一小段时间让原来Standby追上原来的Active，但是时间很短）。

         说到这个共享的存储日志的地方，目前采用最多的就是用共享存储NAS+NFS。缺点有：1）这个存储设备要求是HA的，不能挂掉；2）主从切换时需要fencing方法让原来的Active不再写EditLog，否则的话会发生brain-split，因为如果不阻止原来的Active停止向共享存储写EditLog，那么就有两个Active NN了，这样就会破坏HDFS的元数据了。对于防止brain-split问题，在QJM出现之前，常见的方法就是在发生主从切换的时候，把共享存储上存放EditLog的文件夹对原来的Active的写权限拿掉，那么就可以保证同时至多只有一个Active NN，防止了破坏HDFS元数据。

         Clouera为解决这个问题提出了QJM/Qurom Journal Manager，这是一个基于Paxos算法实现的HDFS HA方案。QJM的结构图如下所示：