hadoop集群HDFS集群之自动故障转移

1 自动故障转移原理

前面学习了使用命令hdfs haadmin -failover手动进行故障转移，在该模式下，即使现役NameNode已经失效，系统也不会自动从现役NameNode转移到待机NameNode，防止脑裂问题

下面学习如何配置部署HA自动进行故障转移。自动故障转移为HDFS部署增加了两个新组件：ZooKeeper和ZKFailoverController（ZKFC）进程。

如上图所示。ZooKeeper是维护少量协调数据，通知客户端这些数据的改变和监视客户端故障的高可用服务。HA的自动故障转移依赖于ZooKeeper的以下功能：

1. 故障检测
   集群中的每个NameNode在ZooKeeper中维护了一个持久会话，如果机器崩溃，ZooKeeper中的会话将终止，ZooKeeper通知另一个NameNode需要触发故障转移。

2. 现役NameNode选择：
   ZooKeeper提供了一个简单的机制用于唯一的选择一个节点为active状态。如果目前现役NameNode崩溃，另一个节点可能从ZooKeeper获得特殊的排外锁以表明它应该成为现役NameNode。
   ZKFC是自动故障转移中的另一个新组件，是ZooKeeper的客户端，也监视和管理NameNode的状态。每个运行NameNode的主机也运行了一个ZKFC进程，ZKFC负责：

3. 健康监测
   ZKFC使用一个健康检查命令定期地ping与之在相同主机的NameNode，只要该NameNode及时地回复健康状态，ZKFC认为该节点是健康的。如果该节点崩溃，冻结或进入不健康状态，健康监测器标识该节点为非健康的。

4. ZooKeeper会话管理
   当本地NameNode是健康的，ZKFC保持一个在ZooKeeper中打开的会话。如果本地NameNode处于active状态，ZKFC也保持一个特殊的znode锁，该锁使用了ZooKeeper对短暂节点的支持，如果会话终止，锁节点将自动删除。

5. 基于ZooKeeper的选择
   如果本地NameNode是健康的，且ZKFC发现没有其它的节点当前持有znode锁，它将为自己获取该锁。如果成功，则它已经赢得了选择，并负责运行故障转移进程以使它的本地NameNode为Active。故障转移进程与前面描述的手动故障转移相似，首先如果必要保护之前的现役NameNode，然后本地NameNode转换为Active状态。

2 修改配置文件

打开官网，我们看到自动化故障转移，我们需要配置两个配置文件分别如下：

根据官网描述的我们需要修改两个配置为文件core-site.xml和hdfs-site.xml

# core-site.xml 的配置文件
[root@wyl01 hadoop]# vim core-site.xml 
#追加下面的内容到文件中
<property>
   <name>ha.zookeeper.quorum</name>
   <value>wyl01:2181,wyl02:2181,wyl03:2181</value>
 </property>

# hdfs-site.xml的配置文件
[root@wyl01 hadoop]# vim hdfs-site.xml 
#追加下面的内容到文件中
<property>
   <name>dfs.ha.automatic-failover.enabled</name>
   <value>true</value>
 </property>

3启动服务：

上一篇我们用的手动转移模式，所以启动了这些进程，下面我们把这些服务给停止，发现已经提示zkfc服务了。

3.1 启动zk服务

# 每台服务都要启动，启动完查看进程jps
./zkServer.sh start

3.2 初始化HA在Zookeeper中状态

[root@wyl01 hadoop]# bin/hdfs zkfc -formatZK

我们可以看到zookeeper中已经创建了node节点了。

3.3 启动HDFS服务

先在哪台机器启动，哪个机器的NameNode就是Active NameNode

[root@wyl01 sbin]# ./start-dfs.sh 
Starting namenodes on [wyl01 wyl02]
wyl02: starting namenode, logging to /opt/HA/hadoop-2.9.2/logs/hadoop-root-namenode-wyl02.out
wyl01: starting namenode, logging to /opt/HA/hadoop-2.9.2/logs/hadoop-root-namenode-wyl01.out
wyl03: starting datanode, logging to /opt/HA/hadoop-2.9.2/logs/hadoop-root-datanode-wyl03.out
wyl01: starting datanode, logging to /opt/HA/hadoop-2.9.2/logs/hadoop-root-datanode-wyl01.out
wyl02: starting datanode, logging to /opt/HA/hadoop-2.9.2/logs/hadoop-root-datanode-wyl02.out
Starting journal nodes [wyl01 wyl02 wyl03]
wyl02: starting journalnode, logging to /opt/HA/hadoop-2.9.2/logs/hadoop-root-journalnode-wyl02.out
wyl03: starting journalnode, logging to /opt/HA/hadoop-2.9.2/logs/hadoop-root-journalnode-wyl03.out
wyl01: starting journalnode, logging to /opt/HA/hadoop-2.9.2/logs/hadoop-root-journalnode-wyl01.out
Starting ZK Failover Controllers on NN hosts [wyl01 wyl02]
wyl02: starting zkfc, logging to /opt/HA/hadoop-2.9.2/logs/hadoop-root-zkfc-wyl02.out
wyl01: starting zkfc, logging to /opt/HA/hadoop-2.9.2/logs/hadoop-root-zkfc-wyl01.out

[root@wyl01 sbin]# jps.sh
==================wyl01======================
28530 DataNode
28998 Jps
28425 NameNode
28921 DFSZKFailoverController
26923 QuorumPeerMain
28735 JournalNode
==================wyl02======================
30273 JournalNode
29651 QuorumPeerMain
30103 NameNode
30393 DFSZKFailoverController
30445 Jps
30174 DataNode
==================wyl03======================
13362 JournalNode
12787 QuorumPeerMain
13428 Jps
13263 DataNode

我们呢打开浏览器输入ip：端口访问，效果图如下：

nn2节点的角色就是standby角色

实验证明：
当我们把nn1给停了，查看结果如何，主要看nn2是否切换成active


结果证明：当我们把nn1给停了，会自动切换到nn2上。

当我们再把nn1给起起来，发现服务也正常启动了，但是已经变成standby角色了