1、HA产生背景
在企业中，大多数公司都是采用cdh来部署集群，对于hadoop集群都是采用的完全分布式方式。在hadoop集群中肯定会有NN（Name Node）节点和SNN（Secondary Name Node）节点，而真正提供集群服务的则是NN节点，SNN节点会将NN的fsimage和editlog拷贝，然后合并成fsimage.ckpt。而且要说明的是:正常情况下，SNN会做一小时的备份。假如出现以下情况：
SNN在10点备份了NN的metadata,在10:30是NN出现故障（1、metadata出现损坏；2、某块物理磁盘挂了。。。），无法恢复自己的元数据，需要通过SNN最新的备份数据进行恢复，这时只能恢复到10点及之前的数据，10点到10:30的元数据就丢了。所以便出现了单点故障问题single point of failure (SPOF)，那么如如解决SPOF问题呢，HA便应运而生了。
Prior to Hadoop 2.0.0, the NameNode was a single point of failure (SPOF) in an HDFS cluster. Each cluster had a single NameNode, and if that machine or process became unavailable, the cluster as a whole would be unavailable until the NameNode was either restarted or brought up on a separate machine.
This impacted the total availability of the HDFS cluster in two major ways:
- In the case of an unplanned event such as a machine crash, the cluster would be unavailable until an operator restarted the NameNode.
- Planned maintenance events such as software or hardware upgrades on the NameNode machine would result in windows of cluster downtime.
The HDFS High Availability feature addresses the above problems by providing the option of running two (and as of 3.0.0 more than two) redundant NameNodes in the same cluster in an Active/Passive configuration with a hot standby. This allows a fast failover to a new NameNode in the case that a machine crashes, or a graceful administrator-initiated failover for the purpose of planned maintenance.
在Hadoop 2.0.0之前，NameNode是HDFS集群中的单点故障（SPOF）。每个群集只有一个NameNode，如果该机器或进程出现不可用，则整个群集将不可用，直到NameNode重新启动或在特定的机器上启动。
这从两个方面影响了HDFS群集的总可用性：
- 在发生意外事件（例如机器崩溃）的情况下，集群将不可用，直到执行重新启动NameNode操作。
- 计划的维护事件，例如NameNode机器上的软件或硬件升级，将导致群集停机时间的延长。
HDFS高可用性功能通过提供以下选项来解决上述问题：在具有热备用的主动/被动配置中，可以在同一群集中运行两个（自3.0.0起，超过两个）冗余NameNode。这样可以在机器崩溃的情况下快速故障转移到新的NameNode，或者出于计划维护的目的由管理员发起的正常故障转移。
2、HA是什么
HDFS HA主要提供了两个NN节点，一个处于Active状态，一个处于Stangby状态。那么与NN和SNN区别是什么呢？简单来说：
NN ：老大 SNN：老二
NN（Active）：孪生兄弟一 NN（StandBy）：孪生兄弟二无部署HA情况下，NN节点挂了，就不能对外继续提供读写服务了，所以需要两个NN，当Active NN挂了，StandBy NN实时替换转为Active状态，继续对外提供服务，那么对于外界来说，是无感知的，达到了平滑过渡的目的。
3、HA架构
1、Active NN:
接收client的rpc请求，同时自己的editlog文件写一条记录，也会同时向JN集群共享存储上写一条。也同时接收DN的hearbeat 、blockreport、block location updates.
2、StandBy NN:
同时会接受到从JN集群的这条记录，使自己的NN的元数据和active NN的元数据一致(重演)，说白了就是 active nn的一个实时热备份，一旦被切换为active状态，就能够立即马上对外提供服务。也同时接收DN的hearbeat blockreporBt block location updates.
3、jn Journal node:
用于active standby nn的同步数据的，本身由JN节点组成的集群，至少3台 2n+1 保证高可用
运行JournalNode的机器上，JournalNode守护程序相对较轻，因此可以合理地将这些守护程序与其他Hadoop守护程序（例如NameNode，JobTracker或YARN ResourceManager）并置在机器上。注意：必须至少有3个JournalNode守护程序，因为必须将编辑日志修改写入大多数JN中。这将允许系统容忍单个机器的故障。您可能还会运行3个以上的JournalNode，但是为了实际增加系统可以容忍的故障数量，您应该运行奇数个JN（即3、5、7等）。请注意，当与N个JournalNode一起运行时，系统最多可以容忍（N-1）/ 2个故障，并继续正常运行。
4、ZooKeeper：
ZooKeeper仲裁和ZKFailoverController进程（缩写为ZKFC）。
Apache ZooKeeper是一项高可用性服务，用于维护少量协调数据，将数据中的更改通知客户端并监视客户端的故障。HDFS自动故障转移的实现依赖ZooKeeper进行以下操作：
1）故障检测 -群集中的每个NameNode计算机都在ZooKeeper中维护一个持久会话。如果计算机崩溃，则ZooKeeper会话将终止，通知其他NameNode应该触发故障转移。
2）活动的NameNode选举 -ZooKeeper提供了一种简单的机制来专门选举一个节点为活动的节点。如果当前活动的NameNode崩溃，则另一个节点可能会在ZooKeeper中采取特殊的排他锁，指示它应成为下一个活动的NameNode。
5、ZKFC:
监控NN的健康状态；向ZK集群定期发送心跳，让自己被选举上，当被ZK选举为主 active角色的时候，zkfc进程通过rpc调用 ，让nn状态转换为active状态。 ZKFailoverController（ZKFC）是一个新组件，它是一个ZooKeeper客户端，还可以监视和管理NameNode的状态。运行NameNode的每台机器还运行ZKFC，该ZKFC负责：
运行状况监视
ZKFC使用运行状况检查命令定期ping通其本地NameNode。只要NameNode以健康状态及时响应，ZKFC就会认为该节点健康。如果该节点已崩溃，冻结或以其他方式进入不正常状态，则运行状况监视器将其标记为不正常。
ZooKeeper会话管理
当本地NameNode运行状况良好时，ZKFC会在ZooKeeper中保持打开的会话。如果本地NameNode处于活动状态，则它还将持有一个特殊的“锁定” znode。该锁使用ZooKeeper对“临时”节点的支持。如果会话到期，则锁定节点将被自动删除。
基于ZooKeeper的选举
如果本地NameNode运行状况良好，并且ZKFC看到当前没有其他节点持有锁znode，则它本身将尝试获取该锁。如果成功，则它“赢得了选举”，并负责运行故障转移以使其本地NameNode处于活动状态。故障转移过程类似于上述的手动故障转移：首先，如有必要，将先前的活动节点围起来，然后将本地NameNode转换为活动状态。
一般企业中大多使用两个NN，当然也可以配置多个，但是：
Note: The minimum number of NameNodes for HA is two, but you can configure more. Its suggested to not exceed 5 - with a recommended 3 NameNodes - due to communication overheads
