1 HA机制

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

• HealthMonitor

• ActiveStandbyElector

• JournalNode集群