【 Hadoop高可用集群介绍】

在一个典型的HA集群中，每个NameNode是一台独立的服务器。在任一时刻，只有一个NameNode处于active状态，另一个处于standby状态。其中，active状态的NameNode负责所有的客户端操作，standby状态的NameNode处于从属地位，维护着数据状态，随时准备切换。 

两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知大部分的JournalNodes进程。standby状态的NameNode有能力读取JNs中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间。standby可以确保在集群出错时，命名空间状态已经完全同步了

 

为了确保快速切换，standby状态的NameNode有必要知道集群中所有数据块的位置。为了做到这点，所有的datanodes必须配置两个NameNode的地址，发送数据块位置信息和心跳给他们两个。 

 

 

对于HA集群而言，确保同一时刻只有一个NameNode处于active状态是至关重要的。否则，两个NameNode的数据状态就会产生分歧，可能丢失数据，或者产生错误的结果。为了保证这点，JNs必须确保同一时刻只有一个NameNode可以向自己写数据。 

 

journalNode这个概念是在MR2也就是Yarn中新加的,journalNode的作用是存放EditLog的,在MR1中editlog是和fsimage存放在一起的然后SecondNamenode做定期合并,Yarn在这上面就不用SecondNamanode了.下面是目前的Yarn的架构图,重点关注一下JournalNode的角色.

 

 

 

利用共享存储来在两个NN间同步edits信息。

以前的HDFS是share nothing but NN，现在NN又share storage，这样其实是转移了单点故障的位置，但中高端的存储设备内部都有各种RAID以及冗余硬件包括电源以及网卡等，比服务器的可靠性还是略有提高。通过NN内部每次元数据变动后的flush操作，加上NFS的close-to-open，数据的一致性得到了保证。社区现在也试图把元数据存储放到BookKeeper上，以去除对共享存储的依赖，Cloudera也提供了Quorum Journal Manager的实现和代码，这篇中文的blog有详尽分析：基于QJM/Qurom Journal Manager/Paxos的HDFS HA原理及代码分析

 

DataNode(以下简称DN)同时向两个NN汇报块信息。

这是让Standby NN保持集群最新状态的必需步骤，不赘述。

 

用于监视和控制NN进程的FailoverController进程

显然，我们不能在NN进程内进行心跳等信息同步，最简单的原因，一次FullGC就可以让NN挂起十几分钟，所以，必须要有一个独立的短小精悍的watchdog来专门负责监控。这也是一个松耦合的设计，便于扩展或更改，目前版本里是用ZooKeeper(以下简称ZK)来做同步锁，但用户可以方便的把这个ZooKeeper FailoverController(以下简称ZKFC)替换为其他的HA方案或leader选举方案。

 

隔离(Fencing))，防止脑裂)，就是保证在任何时候只有一个主NN，包括三个方面：

共享存储fencing，确保只有一个NN可以写入edits。

客户端fencing，确保只有一个NN可以响应客户端的请求。

DataNode fencing，确保只有一个NN可以向DN下发命令，譬如删除块，复制块，等等。