在 Hadoop 1.0 时代，Hadoop 的两大核心组件 HDFS NameNode 和 JobTracker 都存在着单点问题，这其中以 NameNode 的单点问题尤为严重。因为 NameNode 保存了整个 HDFS 的元数据信息，一旦 NameNode 挂掉，整个 HDFS 就无法访问，同时 Hadoop 生态系统中依赖于 HDFS 的各个组件，包括 MapReduce、Hive、Pig 以及 HBase 等也都无法正常工作，并且重新启动 NameNode 和进行数据恢复的过程也会比较耗时。这些问题在给 Hadoop 的使用者带来困扰的同时，也极大地限制了 Hadoop 的使用场景，使得 Hadoop 在很长的时间内仅能用作离线存储和离线计算，无法应用到对可用性和数据一致性要求很高的在线应用场景中。

所幸的是，在 Hadoop2.0 中，HDFS NameNode 和 YARN ResourceManger(JobTracker 在 2.0 中已经被整合到 YARN ResourceManger 之中) 的单点问题都得到了解决，经过多个版本的迭代和发展，目前已经能用于生产环境。HDFS NameNode 和 YARN ResourceManger 的高可用 (High Availability，HA) 方案基本类似，两者也复用了部分代码，但是由于 HDFS NameNode 对于数据存储和数据一致性的要求比 YARN ResourceManger 高得多，所以 HDFS NameNode 的高可用实现更为复杂一些，本文从内部实现的角度对 HDFS NameNode 的高可用机制进行详细的分析。（补充：NN的ha用到了zkfc，而RM的ha直接是将zk嵌入到代码中）

NameNode 高可用整体架构

NameNode高可用机构图如下所示：

1、Active NameNode 和 Standby NameNode：两台 NameNode 形成互备，一台处于 Active 状态，为主 NameNode，另外一台处于 Standby 状态，为备 NameNode，只有主 NameNode 才能对外提供读写服务。

2、主备切换控制器 ZKFailoverController：ZKFailoverController 作为独立的进程运行，对 NameNode 的主备切换进行总体控制。ZKFailoverController 能及时检测到 NameNode 的健康状况，在主 NameNode 故障时借助 Zookeeper 实现自动的主备选举和切换，当然 NameNode 目前也支持不依赖于 Zookeeper 的手动主备切换。

3、Zookeeper 集群：为主备切换控制器提供主备选举支持。

4、共享存储系统：共享存储系统是实现 NameNode 的高可用最为关键的部分，共享存储系统保存了 NameNode 在运行过程中所产生的 HDFS 的元数据。主 NameNode 和Standby NameNode 通过共享存储系统实现元数据同步。在进行主备切换的时候，新的主 NameNode 在确认元数据完全同步之后才能继续对外提供服务。

QJM（Quorum Journal Manager）是实现共享存储的常用手段,即通过JournalNode实现active和standby 节点之间元数据的一致性。当 active NameNode 执行了修改命名空间的操作时，它会定期的将执行的操作记录在editLog中，standby 会一直监听 JNS上的editlog的变化。当editlog发生变化的时候，standby会读取editlog的变化并与当前命名空间合并。

当发生错误切换的时候，standby 会保证读取了JNS 上面所有的 editlog 的变化，然后才切换为active节点。

5、DataNode 节点：除了通过共享存储系统共享 HDFS 的元数据信息之外，active NameNode 和standby NameNode 还需要共享 HDFS 的数据块和 DataNode 之间的映射关系。DataNode 会同时向active NameNode 和standby NameNode 上报数据块的位置信息。

ResourceManager 高可用整体架构

ResourceManager高可用架构如下图所示：

1、active ResourceManager和Standby ResourceManager : RMs HA通过master/standby这种结构实现，一个master是active的，其它standby是inactive的。可能通过命令行切换主备节点，也可以在遇到问题时自动切换。

2、手动切换：管理员可以执行手动切换。通过yarn rmadmin命令实现。

3、zookeeper: 通过zookeeper实现rm的自动切换和state-store(状态存储)。

通过zookeeper可以实现RM的自动切换。注意：在RM上运行一个ZKFC线程来监控RM的运行状态，RM中已经内嵌了ActiveStandbyElector 进程来检查RM的运行状态。

recovering prevous active-RM status（恢复之前的RM状态）：如果启用了RM restart，在active的RM宕机后，standby的RM会接管之前active-RM的职责并加载其状态。在有多个RM的情况下，保存RM元数据的state-store必须可以被每个RM访问。有两种方式实现state-store,filesystem和zookeeper，但是只有zookeeper支持任意时刻任意一个RM都可以读写statue-store，这样就解决了多个RM同时读写statu-store的问题(inacitve RM可能会干扰active RM)。因此，RM HA的应用使用zookeeper来实现。使用zookeeper state-store时，不要设置zookeeper.DigestAuthenticationProvider.superDigest(zookeeper权限相关)。

好文链接

评论可见，请评论后查看内容，谢谢！！！评论后请刷新页面。