翻译自： https://www.cloudera.com/documentation/enterprise/latest/topics/cdh_hag_hdfs_ha_intro.html
HDFS高可用性简介
本节假定读者对HDFS集群中的组件有一个大概的了解。有关详细信息，请参阅Apache HDFS体系结构指南。
背景
在标准配置中，NameNode是HDFS集群中的单点（SPOF）。每个群集都有一个NameNode，如果该主机或进程不可用，整个群集将不可用，直到NameNode重新启动或在新主机上启动为止。Secondary NameNode不提供故障转移功能。
标准配置在以下两个方面会降低HDFS集群的可用性：
- 在发生主机崩溃等意外事件时，直到操作员重新启动NameNode，集群才可用。
- 计划的维护事件（如NameNode机器上的软件或硬件升级）会导致群集停机。
HDFS HA通过在主动/被动配置中提供在同一集群中运行两个NameNode的来解决上述问题。这两个NameNode被称为活动NameNode和备用NameNode。与Secondary NameNode不同的是，备用NameNode是热备用，允许在主机崩溃的情况下或者有计划的停机维护情况下快速的自动的切换到新的NameNode。一个集群中不能有两个以上的NameNode。
实现方式
Cloudera Manager 5和CDH 5支持Quorum-based的存储来实施HA。
Quorum-based存储
Quorum-based 存储是指使用Quorum Journal Manager（QJM）来实现HA。
为使备用NameNode与活动NameNode同步，两个节点都与一组名为JournalNodes的独立守护进程进行通信。当活动的NameNode执行任何名称空间修改时，它会将修改记录到JournalNode。备用NameNode监视并读取JournalNodes上的修改日志。当备用节点读取到修改日志时，它将它们应用到它自己的名称空间。如果发生故障，备用NameNode会确保它在将自己变更为活动状态之前从JournalNodes中读取所有的修改日志。这保证了在故障转移发生之前命名空间状态已完全同步。
为了提供快速故障转移，备用NameNode还需要有群集中blocks的最新信息。为此，DataNode配置了两个NameNode的位置，并将块位置信息和心跳发送给两者。
HA群集中任何时刻有且只能有一个NameNode处于活动状态至关重要。否则，命名空间状态将很快在两者之间发生分歧，从而可能导致数据丢失或其他不正确的结果。这称为脑裂（split-brain scenario）。为防止脑裂，JournalNodes一次只允许一个NameNode作为writer。在故障转移期间，要成为活动状态的NameNode只需接管写入JournalNodes的角色，这有效地防止另一个NameNode继续处于活动状态。
注意：fencing功能不是必需的，但很有用; 请参阅启用HDFS HA。
自动故障转移
自动故障转移依赖于HDFS中的两个附加组件：ZooKeeper quorum，和 ZKFailoverController（缩写为ZKFC）。在Cloudera Manager中，ZKFC进程映射为HDFS故障切换控制器。
Apache ZooKeeper是一种高度可用的服务，它使用少量的协调数据，通知客户端数据发生变化，并监视客户端的故障。HDFS自动故障转移的实现依赖ZooKeeper提供以下功能：
- 失败检测Failure detection - 集群中的每个NameNode机器都在ZooKeeper中维护一个持久会话。如果机器崩溃，ZooKeeper会话将过期，它会通知其他NameNode触发故障转移。
- 活动NameNode选举 - ZooKeeper提供了一种简单的机制来选择一个节点为活动状态。如果当前活动的NameNode崩溃，另一个节点可以在ZooKeeper中使用一个特殊的独占锁，表明它应该成为下一个活动的NameNode。
ZKFailoverController（ZKFC）监视和管理NameNode的状态。每个运行NameNode的主机也运行一个ZKFC。ZKFC负责：
- 健康监控health monitoring - ZKFC定期使用health-check命令检查本地NameNode。只要NameNode以健康状态及时响应，ZKFC就认为NameNode健康。如果NameNode崩溃，冻结或以其他方式进入不健康状态，则将其标记为不健康。
- **ZooKeeper会话管理 session management ** - 当本地NameNode健康时，ZKFC在ZooKeeper中保持会话打开状态。如果本地NameNode处于活动状态，则它会有一个特殊的锁znode。该锁使用ZooKeeper定义的ephemeral节点; 如果会话过期，锁定节点会自动删除。
- **基于ZooKeeper的选举 ZooKeeper-based election ** - 如果本地NameNode健康，并且ZKFC检测到没有其他NameNode当前拥有该znode，它会试图获得锁。如果成功，则它“赢得选举”，并负责运行故障转移以使其本地NameNode处于活动状态。故障转移过程与上述手动故障转移类似：首先，如果需要，先前的活动NameNode将被隔离，然后本地NameNode转换为活动状态。
总结：
- 使用两个NameNode来实现HDFS HA ，这跟Secondary NameNode没关系。
- 实现机制是使用zk。
- 两个NameNode 同步问题：
a.任何时刻只有一个NN是活动的，另外一个是standby。
b. 两个NN都与一组独立守护进程JournalNodes通讯，活动NN的任何修改都会同步记录到JournalNodes的edit log中。
c. DataNodes需要同时配置这俩NN，并且将自身的blocks信息和心跳信息同时发送给两者。
d. 故障转移时，备用NN首先读取edit log ，将edit log记录的任何修改同步到自身的namespace中，然后更改为活动状态。
e. JournalNodes 写edit log 只提供了一个实例， 这也在另外一个方面避免了脑裂的发生。 - 故障的检测： 使用ZK实现，zkfc定期检测NN的健康状态， 不健康则会断开在zk服务器上的会话状态，其占有的znode也会自动被释放。 这时zk服务器会触发选举， 只要是有健康会话的节点都可以发起选举（即试图获取znode锁），选举成功，则成为新的活动节点，活动节点则开始进行故障转移。
