hadoop的高可用（HA）机制

一、HA简介

HA（High Available）即高可用，HA的目的是为了消除单点故障（SPOF）, 对hadoop而言，HA包含了Hdfs的HA和Yarn的HA。配置HA后，集群中Hdfs的NameNode或Yarn的ResourceManager在宕或升级维护等场景下可快速进行机器切换，保证集群可用。

二、 Hdfs的HA机制

1.1 Hdfs HA方案

为了解决Hdfs的SPOF问题，Hadoop提供Hdfs的HA方案是：提供两个NameNode，一个处于active状态，对位提供服务处理客户端的读写请求；另一个处于standby状态，不对外提供服务，仅仅同步active的NameNode的状态，以在其故障时快速进行快速转移。

基于QJM（Quorum Journal Node）的Hdfs HA方案：

image.png

• 集群启动后，standby NameNode和active NameNode同时与JournalNodes（JNS）进程保持通信。其中，active NameNode提供服务，处理客户端和DateNode的请求。active节点在namespace更新时将editlog写到本地和JNS(作为shared editlog)。而standby NameNode周期性的从JNS中获取editlog并应用到本地namespace，在failover发生时，standby节点会在转变为active之前从JNS中读取并处理所有editlog，以此保持与active NameNode的状态完全同步。

• 另一方面，为了failover后standy节点快速提供服务，所有的DateNode节点同时向主备两个NameNode报告block信息。

• 在任意时刻，为了防止“split-brain”（脑裂），集群中保持只有一个active NameNode，否则集群中两个NameNode会产生不同的状态数据导致数据丢失或异常。这里通过fencing实现，具体表现为：1）每个时刻只能有一个NameNode能够写JNS; 2）每个时刻只有一个NameNode能够向DateNode发送更新命令。3）每个时刻只有一个NameNode响应客户端请求

• 为了实现HA的自动failover，每个NameNode节点都开启一个FailoverController进程，FailoverController与zookeeper集群通信。FailoverController与zookeeper集群通信通过zookeeper选举机制选出active节点，并通过RPC发动命令让本机的NameNode转换为active或standby状态。

1.2 Hdfs HA的自动故障转移

上一节HA方案中的FailoverController（ZKFC）和zookeeper是为了实现HA的自动failover（如果没有需要手动failover）。看下ZKFC的架构设计：

image.png

ZKFC和NameNode部署在同一台宿主机器上（两者在不同的jvm进程），HealthMonitor、ActiveStandbyElector与ZKFailoverController处于同一个jvm进程（zkfc）

ZKFC主要的三个组件：

1. HealthMonitor
   定期检查本地NameNode的状态，状态变化时回调ZKFailoverController作相应处理。

2. ActiveStandbyElector
   管理NameNode在zookeeper上的状态，zookeeper上对应znode节点变化时回调ZKFailoverController作相应处理。

3. ZKFailoverController
   向HealthMonitor和ActiveStandbyElector注册回调方法，接收并处理两者的事件。

ZKFC实现的功能：

1. 健康监控（Health monitoring）

   通过HealthMonitor定期监控本地NameNode是否存活和健康。

2. zk session管理（ZooKeeper Session Management）

   当本地NameNode是健康的时候，zkfc在zookeeper中持有一个session。如果本地NameNode正好是active节点，zkfc还会在zookeeper中持有“ephemeral”的znode作为锁，如果本地NameNode失效，ephemeral的znode会自动删除。

3. 基于zk选主（ZooKeeper-based election ）

   • 对active节点，如果HealthMonitor健康到本地NameNode处于非健康状态，则先通过fence功能关闭它（关闭或不能提供服务），再从zookeeper中删除对应的znode节点；

   • 对standby节点，如果本地NameNode是健康的，zkfc发现没有其它节点持有ephemeral独占锁（ActiveStandbyElector会监控到该事件）, 则尝试去获取独占锁，如果获得该锁则进行failover：

     1）如果需要，则先对之前active的NameNode进行fence（可通过远程ssh强制杀死进程）；

     2）将本地NameNode转换为active状态。

二、 Yarn的HA机制

2.1 Yarn HA方案

ResourceManager（RM）负责Yarn集群资源的跟踪及应用调度。Yarn的HA方案：通过active/standby架构，提供多个ResourceManager，同一时刻只有一个RM处于active状态，其它一个或多个RM处于standby状态，以此在RM故障时快速转移（支持手动或自动的方式）。

image.png

• ResourceManager（RM）
  启动后尝试向zookeeper的/hadoop-ha节点写一个lock文件，获取lock成功则成为active节点，否则为standby节点。standby节点循环监控lock是否存在，如果不存在尝试获取，争取成为active节点。RM负责：接收client端任务请求，接收NodeManager节点的资源汇报，分配和调度NM的资源，启动和监控ApplicationMaster（AM）

• NodeManager（NM）
  NM负责节点资源管理，启动container容器并运行task，上报资源和container运行状态给RM，task处理状态上报给ApplicationMaster（AM）

• RMstatestore
  RM提供了多种RMstatestore的实现（可通过yarn.resourcemanager.store.class配置），如：MemoryRMStateStore、FileSystemRMStateStore、ZKRMStateStore，后两种实现是持久化的实现，其中，ZKRMStateStore在任意时间只允许单个RM的写入请求，防止脑裂，因此建议在HA方案中使用RMstatestore。

2.2 Yarn HA自动故障转移

ResourceManager中基于zookeeper的ActiveStandbyElector来选举哪个RM作为active RM。active RM关闭或故障时自动选举standby状态的RM作为新的active RM接管active RM的工作。

与HDFS的HA不同的是，YARN的HA方案不需要单独的ZKFC deamon程序， 基于zk的ActiveStandbyElector作为RM内部组件进行故障检测和active选举, zkfc仅仅作为RM的一个线程存在。

三、HA集群搭建

HA集群搭建，可参考另一篇博客：https://www.jianshu.com/p/e3b0afee4390