前言
Hadoop2.0之前，NameNode是单个集群的故障点，NameNode作为集群首脑，存放着集群中所有的元数据，一旦节点出错，将导致整个集群不可用。为了解决这个问题，HA（高可用）就被引入了。
HA中的角色如下
1.ZKFC
ZKFC即ZKFailoverController，作为独立进程存在，负责控制NameNode的主备切换，ZKFC会监测NameNode的健康状况，当发现Active NameNode出现异常时会通过Zookeeper集群进行一次主备选举，完成Active和Standby状态的切换；
2.HealthMonitor
定时调用NameNode的HAServiceProtocol RPC接口(monitorHealth和getServiceStatus)，监控NameNode的健康状态并向ZKFC反馈；
3.ActiveStandbyElector
接收ZKFC的选举请求，通过Zookeeper自动完成主备选举，选举完成后回调ZKFC的主备切换方法对NameNode进行Active和Standby状态的切换；
4.JouranlNode集群
共享存储系统，负责存储HDFS的元数据，Active NameNode(写入)和Standby NameNode(读取)通过共享存储系统实现元数据同步，在主备切换过程中，新的Active NameNode必须确保元数据同步完成才能对外提供服务;
一.Namenode HA的思考**
为什么要Namenode HA？
解决NameNode单点故障问题，NameNode 很重要，挂掉会导致存储停止服务，无法进行数据的读写，基于此NameNode的计算（MR，Hive等）也无法完成。
Namenode HA 如何实现，关键技术难题是什么？
1.数据同步问题
如何保持主和备NameNode的状态同步，并让Standby在Active挂掉后迅速提供服务，namenode启动比较耗时，包括加载fsimage和editlog（获取file to block信息），处理所有datanode第一次blockreport（获取block to datanode信息），保持NN的状态同步，需要这两部分信息同步。
防止脑裂
指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。NameNode切换对外透明
主Namenode切换到另外一台机器时，不应该导致正在连接的客户端失败，主要包括Client，Datanode与NameNode的链接。
二.数据同步解决方案
1.客户端的增删改的元数据
数据在两个NameNode间同步的过程中，不能因为追求强一致性，而采用同步,阻塞的方式，如果standby节点挂了，或者因为网络通信阻塞的缘故，不能及时的返回，那么NameNode将长时间都处于阻塞状态，高可用性就受到了破坏。
但是如果采用异步方式处理，数据的一致性又无法得到保障，因为可能元数据同步到一半，Active NameNode挂了，这时进行故障转移，两台NN的数据是不一致的。
这种问题可以使用类似于消息队列中的解决方案，在HDFS中，我们常用以下两种方式解决：
1）基于NFS共享存储解决方案
Active NN与Standby NN通过NFS实现共享数据，但如果Active NN与NFS之间或Standby NN与NFS之间，其中一处有网络故障的话，那就会造成数据同步问题
2）基于Qurom Journal Manager(QJM)解决方案
这是一个基于Paxos算法实现的HDFS HA方案，它给出了一种较好的解决思路和方案。在这里主要介绍一下QJM解决方案。
①Active NN、Standby NN有主备之分，NN Active是主的，NN Standby备用的，集群启动之后，一个NameNode是Active状态，来处理client的请求；
②Active NN与Standby NN之间是通过一组JN（JournalNodes）共享数据（JN一般为奇数个，ZK一般也为奇数个，过半写成功策略），Active NN会把日志文件EditLog写到JN中去，只要JN中有一半写成功（并行的），那就表明Active NN向JN中写成功，数据不会丢失了。当然这个算法所能容忍的是多有N台机器挂掉，如果多于N台挂掉，这个算法就失效了。这个原理是基于Paxos算法。
③在HA架构里面SecondaryNameNode这个冷备角色已经不存在了，为了保持standbyNN时时的与主ActiveNN的元数据保持一致，他们之间交互通过一系列守护的轻量级进程JournalNode。Standby NN开始从JN中读取数据，来实现与Active NN数据同步。
④当发生故障时，Active的NN挂掉后，StandbyNN会在它成为ActiveNN前，读取所有的JN里面的修改日志，这样就能高可靠的保证与挂掉的NN的目录镜像树一致，然后无缝的接替它的职责，维护来自客户端请求，从而达到一个高可用的目的。
⑤JN不会因为其中一台的延迟而影响整体的延迟，而且也不会因为JN的数量增多而影响性能(因为NN向JN发送日志是并行的)
2.block的location信息
为了实现Standby NN在Active NN挂掉之后，能迅速的再提供服务，需要DN不仅需要向Active NN汇报，同时还要向Standby NN汇报，这样就使得Standby NN能保存数据块在DN上的位置信息，因为在NameNode在启动过程中最费时工作，就是处理所有DN上的数据块的信息。
三.如何避免脑裂问题
1.ZKFC处理的机制
在分布式系统中脑裂又称为双主现象，由于Zookeeper的“假死”，长时间的垃圾回收或其它原因都可能导致双Active NameNode现象，此时两个NameNode都可以对外提供服务，无法保证数据一致性。对于生产环境，这种情况的出现是毁灭性的，必须通过自带的隔离（Fencing）机制预防这种现象的出现。
ActiveStandbyElector为了实现fencing隔离机制，在成功创建hadoop-ha/dfs.nameservices/ActiveStandbyElectorLock临时节点后，会创建另外一个/hadoop−ha/dfs.nameservices/ActiveBreadCrumb持久节点，这个持久节点保存了Active NameNode的地址信息。
当Active NameNode在正常的状态下断开Zookeeper 回话(注意由于ActiveStandbyElectorLock是临时节点，也会随之删除)，会一起删除持久节点ActiveBreadCrumb。但是如果ActiveStandbyElector在异常的状态下关闭Zookeeper Session，那么由于ActiveBreadCrumb是持久节点，会一直保留下来。当另一个NameNode选主成功之后，会注意到上一个Active NameNode遗留下来的ActiveBreadCrumb节点，从而会回调ZKFailoverController的方法对旧的Active NameNode进行fencing。
① 首先ZKFC会尝试调用旧Active NameNode的HAServiceProtocol RPC接口的transitionToStandby方法，看能否将状态切换为Standby；
② 如果调用transitionToStandby方法切换状态失败，那么就需要执行Hadoop自带的隔离措施，Hadoop目前主要提供两种隔离措施：
sshfence：SSH to the Active NameNode and kill the process；
shellfence：run an arbitrary shell command to fence the Active NameNode；
只有在成功地执行完成fencing之后，选主成功的ActiveStandbyElector才会回调ZKFC的becomeActive方法将对应的NameNode切换为Active，开始对外提供服务。
2.JournalNodes的Fencing机制
简单地理解如下：每个NameNode 与 JournalNodes通信时，需要带一个 epoch numbers(epoch numbers 是唯一的且只增不减)。而每个JournalNode 都有一个本地的promised epoch。
拥有值大的epoch numbers 的NameNode会使得JournalNode提升自己的 promised epoch，从而占大多数，而epoch numbers较小的那个NameNode就成了少数派(Paxos协议思想)。
从而epoch number值大的NameNode才是真正的Active NameNode，拥有写JournalNode的权限。注意：（任何时刻只允许一个NameNode拥有写JournalNode权限）
3.datanode的fencing
确保只有一个NN能命令DN
（1）每个NN改变状态的时候，向DN发送自己的状态和一个序列号
（2）DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回则认为该NN为新的active
（3）如果这时原来的activeNN恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时DN就会拒绝这个NN的命令。
4.客户端fencing
（1）确保只有一个NN能响应客户端请求，让访问standby 的NN的客户端直接失败。
（2）在RPC层封装了一层，通过FailoverProxyProvider以重试的方式连接NN。通过若干次连接一个NN失败后尝试连接新的NN，对客户端的影响是重试的时候增加一定的延迟。客户端可以设置重试此时和时间。
四.ZKFC简介
Hadoop提供了ZKFailoverController角色，作为一个deamon进程,简称zkfc。zkfc是Zookeeper的客户端，部署在每个NameNode的节点上。
ZKFC的作用如下：
1、健康监测：周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机器宕机，心跳失败，那么zkfc就会标记它处于一个不健康的状态。
2、会话管理：如果NN是健康的，zkfc就会在zookeeper中保持一个打开的会话，如果NameNode同时还是Active状态的，那么zkfc还会在Zookeeper中占有一个类型为短暂类型的znode，当这个NN挂掉时，这个znode将会被删除，然后备用的NN，将会得到这把锁，升级为主NN，同时标记状态为Active。
3、当宕机的NN新启动时，它会再次注册zookeper，发现已经有znode锁了，便会自动变为Standby状态，如此往复循环，保证高可靠，需要注意，目前仅仅支持多配置2个NN
4、master选举：如上所述，通过在zookeeper中维持一个短暂类型的znode，来实现抢占式的锁机制，从而判断那个NameNode为Active状态。
