1 背景

在Hadoop 2.0.0之前，NN是HDFS集群中的单点故障(SPOF)。每一个集群只有一个NN,如果这个机器或进程不可用，整个集群就无法使用。
这主要从如下两个方面影响了HDFS集群的可用性:

• 在发生意外事件(如机器崩溃)时，集群将不可用，直到重新启动NN。
• 计划好的集群运维事件(如NN机器上的软件或硬件升级)将导致集群的窗口停机。

HDFS的高可用性解决了上述问题，通过在同一个集群中运行2个以上的NN，其中一个作为active, 其它作为standby。这允许在active NN的机器崩溃或进程不可用时快速故障转移到新的NN，或者在进行计划维护时，将NN转移到standby上。

HDFS的高可用，有2种方案：基于共享NFS的HA、基于QJM/Qurom Journal Manager的HA
HDFS的HA机制，主要分为两块：元数据同步和主备选举。

• 元数据同步依赖于NFS 或 QJM 的共享存储
• 主备选举依赖于ZKFC和Zookeeper

为了方便描述，文中针对一些名称使用缩写表示

2 HDFS HA

2.1 基于QJM的HA

hadoop2.x之后，Clouera提出了QJM/Qurom Journal Manager的HA方案。
这是一个基于Paxos算法（分布式一致性算法）实现的HDFS HA方案，主要优势如下：

• 不需要配置额外的高性能共享存储，降低了系统复杂度和维护成本。
• 消除SPOF(单点故障)
• 系统鲁棒性(Robust)的程度可配置、可扩展。

基本原理: 使用用2N+1台 JournalNode 存储EditLog，每次写数据操作有>=N+1返回成功时即认为该次写成功，保证数据不会丢失。

HA 架构图

• 高可用方案中NN有>=2个，只有一个是Active状态，表示正在对外提供服务的，是活跃的NN，其它的NN是StandBy状态，不对外提供服务的，随时准备替换Active NN.
• JournalNode（JN） : 高效的存储系统，能够实现数据的超快速写入与读取。JN是一个小的文件系统集群，节点数需要是2N+1台
• 当Active NN执行任何命名空间修改时，它会持续地将修改记录记录到大多数这些JN上。StandBy NN实时读取JN内部的数据，实现两个节点的实时元数据同步。
  
  配置参数
• dfs.namenode.shared.edits.dir: 配置JournalNodes 地址，由JournalNodes 集群提供共享的编辑存储，由Active NN写入，由Standby NN读取，以保持与Active NN所做的所有文件系统更改同步
• dfs.journalnode.edits.dir: JournalNode守护进程存储本地状态的路径。JournalNode机器上的绝对路径且只能配置一个路径。

<property>
  <name>dfs.namenode.shared.edits.dir</name>
  <value>qjournal://node1.example.com:8485;node2.example.com:8485;node3.example.com:8485/mycluster</value>
</property>
<property>
  <name>dfs.journalnode.edits.dir</name>
  <value>/path/to/journal/node/local/data</value>
</property>

2.2 基于共享NFS的HA

与QJM的区别是：使用高性能共享存储存储HDFS的元数据，但只有Active NN的才能写，Standby NN只能读

配置如下：

• dfs.namenode.shared.edits.dir : 远程共享编辑目录的路径，备用NN使用同一个目录，以保持与Active NN所做的所有文件系统更改同步。这个目录应该以r/w的方式挂载在NN机器上，且需要配置为绝对路径

<property>
  <name>dfs.namenode.shared.edits.dir</name>
  <value>file:///mnt/filer1/dfs/ha-name-dir-shared</value>
</property>

3 HDFS HA自动切换

HA自动切换NN, 需要增加了两个新的组件:ZooKeeper集群和ZKFailoverController进程(简称ZKFC)

• 集群启动 >= 2个NN, 每个NN都会有一个ZKFC,每个ZKFC到Zookeeper上lock节点下创建临时有序的子节点，节点最小的为Active NN, 其它变为standby的ZKFC会监控lock节点（若节点发生变化，表示Active出现异常）
• ZKFC的作用是监视和管理NN的状态，管理与ZK的会话，并在active NN不可用时，启动基于ZK的选举。

3.1 ZK集群的作用

• 失败保护——集群中的每个NN机器在ZooKeeper中维护一个持久的会话。如果机器崩溃，ZooKeeper会话将过期，通知其他NN应该触发故障转移。
• NN主动选举——ZooKeeper提供了一种简单的机制，专门选举一个节点为Active。如果当前Active NN崩溃，另一个节点可能会在ZooKeeper中获得一个特殊的排他锁，指示它应该成为下一个Active NN。
• 防脑裂： ZK本身是强一致和高可用的，可以用它来保证同一时刻只有一个活动节点

3.2 ZKFC的作用

• 健康检测: ZKFC使用健康检查命令定期ping其本地NN。只要NN以健康状态及时响应，ZKFC就认为该节点是健康的。如果节点已崩溃、冻结或以其他方式进入不正常状态，运行状况监视器将将其标记为不正常状态，并触发回调ZKFailoverController进行自动主备切换
• ZK会话管理 : 当本地NN处于健康状态时，ZKFC在ZooKeeper中保持一个会话打开。如果本地NN是Active，它还持有一个特殊的“锁”znode。这个锁使用了ZooKeeper对临时节点的支持;如果会话超时，锁节点将被自动删除。
• 基于ZK的选举：如果本地NN是健康的，并且ZKFC看到当前没有其他节点持有锁znode，它自己将尝试获取锁。如果它成功了，那么它就“赢得了选举”，并负责运行故障转移以使其本地NN处于Active。

3.3 故障转移过程

• 当Active NN出现异常【崩溃、假死】，Active NN的ZKFC得知异常后断开与Zookeeper的连接，此时Zokeeper上的临时节点就会消失
• Standby 的ZKFC收到Zokeeper的断开信息，通知standby NN, standby NN远程登录到原始Active NN节点，强行kill NN进程。
• 通知standby ZKFC抢占Zookeeper上的临时节点，抢占成功，将状态从standby变为active
• 当原始Active NN重新恢复后，ZKFC到Zookeeper上lock节点下创建临时有序的子节点, 但因为节点不是最小的，所以作为standby NN.
  
  

3.4 触发HDFS NN自动切换的场景

• Active NN JVM崩溃： Active NN不能及时响应ZKFC的健康检测命令，HealthMonitor会触发状态迁移SERVICE_NOT_RESPONDING, 然后Active NN上的ZKFC会断开与ZK的连接，Standby NN上的ZKFC会获得Active Lock, 作相应隔离后成为Active NN。
• Active NN JVM冻结：这个是JVM没崩溃，但也无法响应，同崩溃一样，会触发自动切换。
• Active NN 机器宕机：此时ActiveStandbyElector会失去同ZK的心跳，会话超时，Standby NN上的ZKFC会通知ZK删除Active NN的活动锁，作相应隔离后完成主备切换。
• Active NN 健康状态异常： 此时HealthMonitor会收到一个HealthCheckFailedException，并触发自动切换。
• Active ZKFC崩溃：虽然ZKFC是一个独立的进程，但因设计简单也容易出问题，一旦ZKFC进程挂掉，虽然此时NN是OK的，但系统也认为需要切换，此时Standby NN会发一个请求到Active NN要求Active NN放弃主结点位置，Active NN收到请求后，会触发完成自动切换。
• ZooKeeper崩溃：如果ZK崩溃了，主备NN上的ZKFC都会感知断连，此时主备NN会进入一个中立模式【NeutralMode】，同时不改变主备NN的状态，继续发挥作用，只不过此时，如果ANN也故障了，那集群无法发挥Failover, 也就不可用了，所以对于此种场景，ZK一般是不允许挂掉到多台，至少要有N/2+1台保持服务才算是安全的。

参考

HDFS High Availability
HDFS High Availability Using the Quorum Journal Manager
Introduction to HDFS High Availability