NameNode维护了HDFS所有的元数据信息，当该节点所在服务器宕机或服务不可用时，整个HDFS都将处于不可用状态，那么怎么才能避免这个NameNode节点宕机呢？一个容易想到的解决方案是部署两台NameNode节点，形成主备模式（active/standby模式），这样一旦active节点宕机，standby节点立即切换到active模式。事实上HA机制就是采取的这种方案。但实现该机制，需要解决以下问题：
1）为什么选择主备模式，而不是主主模式（active/active模式）？也即让两个NameNode节点都响应客户端的请求，但前提是两个NameNode都需要保存致的元数据
2）怎么同步两个NameNode节点的元数据？响应客户端请求的是active节点保存了最新的元数据 ，元数据分为两部分：一是刚写入新的元数据 （edits），二是合并后的较旧的（fsimage）。HA机制解决同步问题的方法是将active节点新写入的edits元数据放在zookeeper集群上（zookeeper集群主要功能是实现少量数据的分布式同步管理），standby节点在active节点正常情况下只需要将zookeeper集群上edits文件同步到自己的fsimage中就可以。Hadoop框架为这个集群专门写了个分布式应用qjournal（依赖zookeeper实现），实现qjournal的节点称为JournalNode。
3）怎么感知Active节点是否宕机，并将standby节点快速切换到active状态？解决方案是专门在NameNode节点上启动一下监控进程，时刻监控NameNode的状态。对于处在active状态的NameNode，如果发现不正常就向zookeeper集群中写入一些数据。对于处在standby状态的namenode，监控进程从zookeeper集群中读数据，从而感知到active节点是否正常。如果发现异常，监控进程负责将standby状态切换到active状态。这个监控进程在hadoop中叫做ZKFC（依赖zookeeper实现）。
4）如何在状态切换时避免brain split（脑裂）？解决方案：standby NameNode感知到主节点出现异常后不会立即切换状态，ZKFC会首先通过ssh远程杀死active节点的NameNode进程（kill -9 进程号）。如果在一段时间内没有收到执行成功的回执，standby节点会执行一个自定义脚本，尽量保证不会出现脑裂问题。这个机制在Hadoop中称为fencing（包括ssh发送kill指令，执行自定义脚本两道保障），如下图：
2 HA架构
ZKFC
主要作用：作为一个ZK集群的客户端，用来监控NN的状态信息。
ZKFC即ZKFailoverController，作为独立进程存在，负责控制NameNode的主备切换，ZKFC会监测NameNode的健康状况，当发现Active NameNode出现异常时会通过Zookeeper集群进行一次主备选举，完成Active和Standby状态的切换；
HealthMonitor
定时调用NameNode的HAServiceProtocol RPC接口(monitorHealth和getServiceStatus)，监控NameNode的健康状态并向ZKFC反馈
ActiveStandbyElector
接收ZKFC的选举请求，通过Zookeeper自动完成主备选举，选举完成后回调ZKFC的主备切换方法对NameNode进行Active和Standby状态的切换；
JournalNode集群
共享存储系统，负责存储HDFS的元数据，Active NameNode（写入）和Standby NameNode（读取）通过共享存储系统实现元数据同步，在主备切换过程中，新的Active NameNode必须确保元数据同步完成才能对外提供服务。
Standby NameNode拥有之前Active NameNode的对外提供的所有服务信息，这就需要ZK维护一组守护进程JournalNode，处于工作状态的Active NameNode需要将自己对外提供的所有服务信息写在一半以上的JournalNode的目录里（这些信息被记为editlog），处于热备状态的Standby NameNode会随时监听JournalNode的工作目录，只要有所更新改变，热备状态下的Standby NameNode会读取这些信息，并更新自己内部的命名空间，此时Standby NameNode和Active NameNode都拥有对外提供的服务信息所有的DataNode都要向主NameNode和热备NameNode进行心跳报告，使得2个NameNode都了解DataNode的健康状态以及数据存放在哪个DataNode上。
