官方文档翻译，官方链接。
翻译水平有限，且以学习为主，请谅解和提意见。
转载请注明出处！！！
自动failover
介绍
前面详细说明了如何配置手工failover。在那种模式下，系统不能自动地触发将NameNode从active状态failover到standby状态，即使active节点已经失败了。这部分将讲述如何配置、部署自动failover。
组件
自动failover需要增加两个新的组件到HDFS上：一个是Zookeeper quorum（仲裁），另一个是ZKFailoverController进程（简称ZKFC）。
Apache Zookeeper是一个高可用的服务，对于小规模数据协调，通知客户端数据变化，监控客户端失败。自动failover的实现是基于ZK以下的事实：
- Failure detection - 集群中的每个NameNode机器在ZK上保持持久化会话。如果机器崩溃，ZK会话过期，通知其它NameNode有一个failover将被触发。
- Active NameNode election - ZK提供一个简单机制，选举出唯一的一个节点作为active。如果当前的active NameNode崩溃，另一个节点可能在ZK持有特定的互斥型锁，表名它将成为下一个active。
ZKFC是一个新的组件，是一个ZK客户端，也监控和管理NameNode的状态。NameNode运行的所在的每个机器也要运行一个ZKFC，ZKFC负责：
- Health monitoring（健康监控） - ZKFC使用健康检查命令定期地ping本地NameNode。只要NameNode及时响应一个健康状态，ZKFC则确认节点健康。如果节点已经崩溃、冻结、其它不健康状态，健康监控器将标记它为不健康。
- ZooKeeper session management（ZK会话管理）- 当本地NameNode健康，ZKFC在ZK上持有一个打开的会话。如果本地NameNode是active的，它持有指定的znode锁。这个锁用于ZK支持“短暂”的节点，如果会话过期，锁节点将自动被删除。
- ZooKeeper-based election（基于ZK的选举） - 如果本地NameNode健康，ZKFC看到当前没有其它节点控制znode锁，它自己将尝试获取这个所有。如果成功，则它胜选，负责运行一个failover，使本地NameNode成为active。failover进程类似于上面描述的手工failover：首先，如果必要前一个active被fencing了，然后，本地的NameNode转换为active状态。
对应自动failover设计上的更多描述，到Apache HDFS JIRA上，参考设计文档HDFS-2185。
部署ZK
在典型的部署中，ZK守护进程被配置、运行在3或5个节点上。由于ZK自身资源需求，分配ZK节点的硬件资源可以与HDFS NameNode的机器配置一样。许多人选择在同一节点上部署3个ZK进程作为YARN ResourceManager。配置ZK节点将数据存储在独立磁盘驱动器上。
安装ZK超出本文档范围。
开始前
配置自动failover前，需要停掉集群。目前当集群运行时，还不能从一个手工failover转换到自动failover。
配置自动failover
自动failover需要增加两个新的配置参数。
在hdfs-site.xml中，增加：
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
</property>
在core-site.xml文中，为了自动failover需要集群设置这个：
<property>
<name>ha.zookeeper.quorum</name>
<value>zk1.example.com:2181,zk2.example.com:2181,zk3.example.com:2181</value>
</property>
这个主机端口对列表运行着ZK服务。
使用前文描述的参数，这些配置可以在每个nameservice上使用nameservice ID作为后缀进行设置。例如，集群使用联邦机制时，通过设置dfs.ha.automatic-failover.enabled.my-nameservice-id参数，可以准确地配置某一个nameservice使用自动failover。
在ZK中，初始化HA状态
这些配置键添加后，下一步是在ZK中初始化必要的状态。在其中一个NameNode主机，执行如下命令，完成这个初始化。
[hdfs]$ $HADOOP_PREFIX/bin/hdfs zkfc -formatZK
这个命令将在ZK中创建一个znode，用于存储自动failover所需要的数据。
使用start-dfs.sh启动集群
由于已经配置了自动failover，执行start-dfs.sh脚本将在运行NameNode的节点上启动一个ZKFC守护进程。当ZKFC启动，它们将自动选择一个NameNode成为active。
手工启动集群
如果手工管理集群，需要手工在运行NameNode的节点上启动ZFKC进程。使用如下命令启动：
[hdfs]$ $HADOOP_PREFIX/sbin/hadoop-daemon.sh --script $HADOOP_PREFIX/bin/hdfs start zkfc
安全访问ZK
如果运行一个带安全机制的集群，或许想确保存储在ZK上的信息也是安全的。阻止恶意客户端篡改ZK中的元数据，触发一个错误的failover。
为了在ZK中保护信息，需要在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>
请初一这些值里的'@'字符 - 这个表示配置不是内联的，而是指向磁盘上的文件。
第一个配置文件是指定一个ZK认证列表，与ZK CLI使用相同的格式，格式如下：
digest:hdfs-zkfcs:mypassword
hdfs-zkfcs是一个ZK用户名，mypassword使用密码串。
接下来，产生一个与这个认证一致的ZK ACL。使用如下命令：
[hdfs]$ 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=
复制'->'后面的字符串，粘贴到zk-acls.txt，前缀加上'digest:'。例如：
digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda
为了让这些ACL生效，需要重新运行zkfc -formatZK命令。
这样做之后，可以验证的acl，ZK CLI如下：
[zk: localhost:2181(CONNECTED) 1] getAcl /hadoop-ha
'digest,'hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=
: cdrwa
验证自动failover
自动failover部署完成，既可以测试了。
首先定位active NameNode。可以通过访问NameNode的Web页面，来得到active NameNode。
定位到active NameNode，可以在这个节点上制造一个失败。例如，可以执行kill -9 <pid of NN> 来模拟JVM崩溃。或者关机，或者拔掉网线模拟不同的故障。期望测试的故障触发后，其它的NameNode将在几秒内自动成为active的。故障检测和触发故障转移所需的时间取决于ha.zookeeper.session-timeout.ms**的配置，默认5秒。
如果测试没有成功，可能有一个错误配置存在。检查zkfc守护进程以及NameNode守护进程的日志，进一步诊断问题。
自动failover的FAQ
Is it important that I start the ZKFC and NameNode daemons in any particular order?（ZKFC和NameNode有启动顺序吗？）
没有，在指定的节点上，可以在相应的NameNode启动之前或之后，启动ZKFC。What additional monitoring should I put in place?（额外的监控我应该放在什么地方?）
需要将空运行NameNode的每台主机，确保ZKFC运行。例如ZKFC意外退出等ZK异常，需要重启ZKFC，确保系统的自动failover。
另外，还有监控每个ZK Quorum服务器。如果ZK崩溃，自动failover将不可用。What happens if ZooKeeper goes down?（如果ZK停了，发生什么？）
如果ZK崩溃，将没有自动failover可以触发了。然而，HDFS将继续运行，不受影响。当ZK重启，HDFS将重新连接。Can I designate one of my NameNodes as primary/preferred?（可以指派一个NameNode为首选active的吗？）
不可以，当前不支持。无论哪个NameNode首先启动都将成为active的。你可以选择启动集群的顺序，先启动你首选的节点。How can I initiate a manual failover when automatic failover is configured?（当自动failover配置了，如何进行一次手工failover？）
即使配置了自动failover，也可以使用hdfs haadmin命令进行一次手工failover，执行是一样的。
HA HDFS升级、终止、回滚
在HDFS版本之间迁移，有时新版本软件可以很简单的安装和重启集群。然而，有时升级HDFS版本需要更改磁盘数据。在这种情况下，安装新版本软件后，必须使用HDFS的升级/终止/回滚过程进行处理。在HA环境中，这个过程更复杂；因为NN依赖的磁盘元数据是分布定义的。
执行HA升级
过程如下：
- 正常关闭所有NameNode，安装新版软件。
- 启动所有JN。请注意，重要的是，当执行升级、回滚、终止操作时，所有的JN都在运行。如果在运行这些操作时，任何JN停止，操作将会失败。
- 使用'-upgrade'启动一个NN。
- 在启动中，这个NN不能进入standby状态。而是要立即进入active状态，在它的本地存储目录执行升级，且在共享的编辑日志执行升级。
- 此时另一个NN没有与已经升级的NN同步。为了使这个NN同步和再次进行HA设置，需要在这个NameNode节点上，使用'-bootstrapStandby'参数重新引导NameNode启动。第二个NN使用'-upgrade'将报错。
注意，如果在终止或者回滚这个升级前，任何时候打算重启NNs，比如正常启动NNs，不要有任何特殊的启动参数。
终止HA升级
当NNs正在运行且一个是active的时，使用`hdfs dfsadmin -finalizeUpgrade'进行终止升级。此时active NN将执行共享日志终止，NN的本地存储目录包含之前FS状态将删除它的本地状态。
执行回滚
首先，两个NN将关闭。在NN上运行回滚开始的升级过程，在本地目录、共享日志、NFS/JNs执行回滚。
之后，这个NN启动，另一个NN使用`-bootstrapStandby'启动，使两个NN同步到回滚之前的文件系统状态。
