NameNode HA实现原理

Posted 2023-04-20

参考技术A

前言 ：在Hadoop 1.x版本，HDFS集群的NameNode一直存在单点故障问题：集群只存在一个NameNode节点，它维护了HDFS所有的元数据信息，当该节点所在服务器宕机或者服务不可用，整个HDFS集群都将处于不可用状态，极大限制了HDFS在生产环境的应用场景。直到Hadoop 2.0版本才提出了高可用 (High Availability, HA) 解决方案，并且经过多个版本的迭代更新，已经广泛应用于生产环境。
解决方案 ：在同一个HDFS集群，运行两个互为主备的NameNode节点。一台为主Namenode节点，处于Active状态，一台为备NameNode节点，处于Standby状态。其中只有Active NameNode对外提供读写服务，Standby NameNode会根据Active NameNode的状态变化，在必要时切换成Active状态。

【NameNode HA架构图】

HealthMonitor
定时调用NameNode的HAServiceProtocol RPC接口(monitorHealth和getServiceStatus)，监控NameNode的健康状态并向ZKFC反馈；

ActiveStandbyElector
接收ZKFC的选举请求，通过Zookeeper自动完成主备选举，选举完成后回调ZKFC的主备切换方法对NameNode进行Active和Standby状态的切换；

JouranlNode集群
共享存储系统，负责存储HDFS的元数据，Active NameNode(写入)和Standby NameNode(读取)通过共享存储系统实现元数据同步，在主备切换过程中，新的Active NameNode必须确保元数据同步完成才能对外提供服务;

ZKFailoverController在启动时同时会初始化HealthMonitor和ActiveStandbyElector服务，同时也会向HealthMonitor和ActiveStandbyElector注册相应的回调方法：

HealthMonitor检测NameNode的两类状态，HealthMonitor.State和HealthMonitor.HAServiceStatus。在程序上启动一个线程循环调用NameNode的HAServiceProtocol RPC接口的方法来检测NameNode 的状态，并将状态的变化通过回调的方式来通知ZKFailoverController。

当HealthMonitor检测到NameNode的健康状态或角色状态发生变化时，ZKFC会根据状态的变化决定是否需要进行主备选举。

HealthMonitor.State状态变化导致的不同后续措施：

HAServiceStatus在状态检测之中仅起辅助的作用，当HAServiceStatus发生变化时，ZKFC会判断NameNode返回的HAServiceStatus与ZKFC所期望的是否相同，如果不相同，ZKFC会调用ActiveStandbyElector的quitElection方法删除当前已经在ZK上建立的临时节点退出主备选举。

ZKFC通过ActiveStandbyElector的joinElection方法发起NameNode的主备选举，这个过程通过Zookeeper的写一致性和临时节点机制实现:
a. 当发起一次主备选举时，Zookeeper会尝试创建临时节点 /hadoop-ha/$dfs.nameservices/ActiveStandbyElectorLock ，Zookeeper的写一致性保证最终只会有一个ActiveStandbyElector创建成功，创建成功的 ActiveStandbyElector对应的NameNode就会成为主NameNode，ActiveStandbyElector回调ZKFC的方法将对应的NameNode切换为Active状态。而创建失败的ActiveStandbyElector对应的NameNode成为备NameNode，ActiveStandbyElector回调ZKFC的方法将对应的NameNode切换为Standby状态;

b. 不管是否选举成功，所有ActiveStandbyElector都会向Zookeeper注册一个Watcher来监听这个节点的状态变化事件;

c. 如果Active NameNode对应的HealthMonitor检测到NameNode状态异常时，ZKFC会删除在Zookeeper上创建的临时节点ActiveStandbyElectorLock，这样处于Standby NameNode的ActiveStandbyElector注册的Watcher就会收到这个节点的 NodeDeleted事件。收到这个事件后，会马上再次创建ActiveStandbyElectorLock，如果创建成功，则Standby NameNode被选举为Active NameNode。

【防止脑裂】
在分布式系统中脑裂又称为双主现象，由于Zookeeper的“假死”，长时间的垃圾回收或其它原因都可能导致双Active NameNode现象，此时两个NameNode都可以对外提供服务，无法保证数据一致性。对于生产环境，这种情况的出现是毁灭性的，必须通过自带的隔离（Fencing）机制预防这种现象的出现。
ActiveStandbyElector为了实现fencing隔离机制，在成功创建 hadoop-ha/dfs.nameservices/ActiveStandbyElectorLock 临时节点 后，会创建另外一个 /hadoop−ha/dfs.nameservices/ActiveBreadCrumb 持久节点 ，这个持久节点保存了Active NameNode的地址信息。当Active NameNode在正常的状态下断开Zookeeper Session (注意由于 /hadoop-ha/dfs.nameservices/ActiveStandbyElectorLock 是临时节点，也会随之删除)，会一起删除持久节点 /hadoop−ha/dfs.nameservices/ActiveBreadCrumb 。但是如果ActiveStandbyElector在异常的状态下关闭Zookeeper Session，那么由于 /hadoop-ha/$dfs.nameservices/ActiveBreadCrumb 是持久节点，会一直保留下来。当另一个NameNode （standy => active） 选主成功之后，会注意到上一个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，开始对外提供服务。

博客主页： https://www.jianshu.com/u/e97bb429f278

Hadoop的HA原理

一、概述

Hadoop的HA应该分为HDFS 的 HA 和 YARN 的 HA，主要是解决NameNode和ResourceManager的单点故障问题，所以HA就是通过配置 Active/Standby 两个 实例来解决单点故障

二、HDFS-HA 工作机制

2.1HDFS-HA 工作要点

（1）元数据管理方式改变

两个NameNode内存中各自保存一份元数据，Edits 日志只有 Active 状态的 NameNode 节点可以做写操作， 两个 NameNode 都可以读取 Edits，共享的 Edits 放在一个共享存储中JounalNode

（2） 增加一个状态管理功能模块

Zkfailover（hadoop的模块），常驻在每一个 namenode 所在的节点，每一个 zkfailover 负责监控自己所在 NameNode 节点，和ZooKeeper通信利用 zk 进行状态标识，当需要进行状态切换时，由 zkfailover 来负责切换，切换时需要防止 brain split 现象的发生。

（3） 必须保证两个 NameNode 之间能够 ssh 无密码登录（为了防止脑裂，远程登录进行kill）

（4）隔离（Fence），即同一时刻仅仅有一个 NameNode 对外提供服务

2.2、 HDFS-HA 自动故障转移工作机制

1）故障检测：集群中的每个NameNode在ZooKeeper 中维护了一个持久会话，如果机器崩溃，ZooKeeper 中的会话将终止，ZooKeeper 通知另一个 NameNode 需要触发故障转移。

2）现役 NameNode 选择：ZooKeeper 提供了一个简单的机制用于唯一的选择一个节点为 active 状态。如果目前现役 NameNode 崩溃，另一个节点可能从 ZooKeeper 获得特殊的排外锁以表明它应该成为现役 NameNode。

3）ZKFC工作原理： 

（1）健康监测：ZKFC 使用一个健康检查命令定期地 ping 与之在相同主机的 NameNode，只要该 NameNode 及时地回复健康状态，ZKFC 认为该节点是健康的。如果该节点崩溃，冻结或进入不健康状态，健康监测器标识该节点为非健康的。

（2）ZooKeeper 会话管理：当本地 NameNode 是健康的，ZKFC 保持一个在 ZooKeeper中打开的会话。如果本地 NameNode 处于 active 状态，ZKFC 也保持一个特殊的 znode 锁，该锁使用了 ZooKeeper 对短暂节点的支持，如果会话终止，锁节点将自动删除。

（3）基于 ZooKeeper 的选择：如果本地 NameNode 是健康的，且 ZKFC 发现没有其它的节点当前持有 znode 锁，它将为自己获取该锁。如果成功，则它已经赢得了选择，并负责运行故障转移进程以使它的本地 NameNode 为 Active。

三、YARN-HA 工作机制

yarn的高可只依赖于zookeeper即可，所以只需要配置一下高可用参数和zookeeper参数即可

 可以参考官网