Hadoop-2.4.1学习之QJM HA的自动故障转移

       前面学习了使用命令hdfs haadmin -failover手动进行故障转移，在该模式下，即使现役NameNode已经失效，系统也不会自动从现役NameNode转移到待机NameNode，下面学习如何配置部署HA自动进行故障转移。自动故障转移为HDFS部署增加了两个新组件：ZooKeeper和ZKFailoverController（ZKFC）进程。ZooKeeper是维护少量协调数据，通知客户端这些数据的改变和监视客户端故障的高可用服务。HA的自动故障转移依赖于ZooKeeper的以下功能：

• 故障检测：集群中的每个NameNode在ZooKeeper中维护了一个持久会话，如果机器崩溃，ZooKeeper中的会话将终止，ZooKeeper通知另一个NameNode需要触发故障转移。
• 现役NameNode选择：ZooKeeper提供了一个简单的机制用于唯一的选择一个节点为active状态。如果目前现役NameNode崩溃，另一个节点可能从ZooKeeper获得特殊的排外锁以表明它应该成为现役NameNode。

       ZKFC是自动故障转移中的另一个新组件，是ZooKeeper的客户端，也监视和管理NameNode的状态。每个运行NameNode的主机也运行了一个ZKFC进程，ZKFC负责：

• 健康监测：ZKFC使用一个健康检查命令定期地ping与之在相同主机的NameNode，只要该NameNode及时地回复健康状态，ZKFC认为该节点是健康的。如果该节点崩溃，冻结或进入不健康状态，健康监测器标识该节点为非健康的。
• ZooKeeper会话管理：当本地NameNode是健康的，ZKFC保持一个在ZooKeeper中打开的会话。如果本地NameNode处于active状态，ZKFC也保持一个特殊的znode锁，该锁使用了ZooKeeper对短暂节点的支持，如果会话终止，锁节点将自动删除。
• 基于ZooKeeper的选择：如果本地NameNode是健康的，且ZKFC发现没有其它的节点当前持有znode锁，它将为自己获取该锁。如果成功，则它已经赢得了选择，并负责运行故障转移进程以使它的本地NameNode为active。故障转移进城与前面描述的手动故障转移相似，首先如果必要保护之前的现役NameNode，然后本地NameNode转换为active状态。

       在典型部署中，ZooKeeper守护进程运行在三个或者五个节点上，但由于ZooKeeper本身需要较少的资源，所以将ZooKeeper部署在与现役NameNode和待机NameNode相同的主机上，还可以将ZooKeeper部署到与YARN的ResourceManager相同的节点上。建议配置ZooKeeper将数据存储在与HDFS元数据不同的硬盘上以得到最好的性能和隔离性。在配置自动故障转移之前需要先停掉集群，目前在集群运行时还不可能将手动故障转移的安装转换为自动故障转移的安装。接下来看看如何配置HA的自动故障转移。首先在hdfs-site.xml中添加下面的参数，该参数的值默认为false：

<property>
   <name>dfs.ha.automatic-failover.enabled</name>
   <value>true</value>
</property>

       在core-site.xml文件中添加下面的参数，该参数的值为ZooKeeper服务器的地址，ZKFC将使用该地址。

<property>
   <name>ha.zookeeper.quorum</name> <value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value>
</property>

       在HA或者HDFS联盟中，上面的两个参数还需要以NameServiceID为后缀，比如dfs.ha.automatic-failover.enabled.mycluster。除了上面的两个参数外，还有其它几个参数用于自动故障转移，比如ha.zookeeper.session-timeout.ms，但对于大多数安装来说都不是必须的。

       在添加了上述的配置参数后，下一步就是在ZooKeeper中初始化要求的状态，可以在任一NameNode中运行下面的命令实现该目的，该命令将在ZooKeeper中创建znode：

$ hdfs zkfc -formatZK

       在启用自动故障转移的集群中，start-dfs.sh脚本将在任何运行NameNode的主机上自动启动ZKFC守护进程，一旦ZKFC启动完毕，它们将自动选择一个NameNode为现役NameNode。如果手动管理集群中的服务，需要在每台运行NameNode的主机上手动启动ZKFC，命令为：

hadoop-daemon.sh start zkfc
hdfs zkfc

       如果正在运行一个安全的集群，可能想确保存储在ZooKeeper中的信息也是安全的，这将阻止恶意的客户端修改ZooKeeper中的元数据或者潜在地触发一个错误的故障转移。为了保护ZooKeeper中的信息，首先在core-site.xml中添加下面的参数：

<property>
   <name>ha.zookeeper.auth</name>
   <value>@/path/to/zk-auth.txt</value>
 </property>
 <property>
   <name>ha.zookeeper.acl</name>
   <value>@/path/to/zk-acl.txt</value>
 </property>

       参数值中的@字符表示参数值保存在@后的硬盘文件中。第一个配置文件指定了ZooKeeper的认证列表，其格式与ZK CLI使用的相同，例如：digest:hdfs-zkfcs:mypassword，其中hdfs-zkfcs为ZooKeeper的用户名，mypassword为密码。其次使用下面的命令为该认证生成一个ZooKeeper访问控制列表：

$ java -cp $ZK_HOME/lib/*:$ZK_HOME/zookeeper-3.4.2.jar org.apache.zookeeper.server.auth.DigestAuthenticationProvider hdfs-zkfcs:mypassword
output: hdfs-zkfcs:mypassword->hdfs-zkfcs:P/OQvnYyU/nF/mGYvB/xurX8dYs= 

       拷贝->之后的字符串并添加digest:前缀，然后粘贴到zk-acls.txt中，例如：digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda。要想使ACLs生效，需要再次运行zkfc –formatZK。最后可能像下面这样在ZK CLI中验证ACLs：

[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=
: cdrwa

       在安装完成自动故障转移后，或许需要测试一下。首先定位现役NameNode，可以通过访问NameNode的web页面来确定哪个NameNode是active状态的。一旦确定了处于active状态的NameNode，就需要在该节点上制造点故障，比如使用命令kill -9 <pid of NN>模拟JVM崩溃，或重启主机或拔掉网线来模拟不同的中断。一旦触发了自动故障转移，另一个NameNode应该自动在几秒钟内变为active状态。检测到故障并触发故障转移由参数ha.zookeeper.session-timeout.ms控制，该参数为与core-site.xml中，默认为5秒。如果测试不成功，可能是配置问题，检查ZKFC和NameNode进程的日志以进一步诊断问题，通常错误都是很明显的。