Hadoop High Availability高可用

HDFS HA

Namenode HA  详解　　

　　hadoop2.x 之后，Clouera 提出了 QJM/Qurom Journal Manager，这是一个基于 Paxos 算法（分布式一致性算法）实现的 HDFS HA 方案，它给出了一种较好的解决思路和方案,QJM 主要优势如下：

　　不需要配置额外的高共享存储，降低了复杂度和维护成本。

　　消除 spof(单点故障)。

　　系统鲁棒性(Robust)的程度可配置、可扩展。

 

　　基本原理就是用 2N+1 台 JournalNode 存储 EditLog，每次写数据操作有>=N+1 返回成功时即认为该次写成功，数据不会丢失了。当然这个算法所能容忍的是最多有 N台机器挂掉，如果多于 N 台挂掉，这个算法就失效了。这个原理是基于 Paxos 算法。

　　在 HA 架构里面 SecondaryNameNode 已经不存在了，为了保持 standby NN 时时的与 Active NN 的元数据保持一致，他们之间交互通过 JournalNode 进行操作同步。

　　任何修改操作在 Active NN 上执行时，JournalNode 进程同时也会记录修改 log到至少半数以上的 JN 中，这时 Standby NN 监测到 JN 里面的同步 log 发生变化了会读取 JN 里面的修改 log，然后同步到自己的目录镜像树里面，如下图：

 

 

　　当发生故障时，Active 的 NN 挂掉后，Standby NN 会在它成为 Active NN 前，读取所有的 JN 里面的修改日志，这样就能高可靠的保证与挂掉的 NN 的目录镜像树一致，然后无缝的接替它的职责，维护来自客户端请求，从而达到一个高可用的目的。

　　在 HA 模式下，datanode 需要确保同一时间有且只有一个 NN 能命令 DN。为此：每个 NN 改变状态的时候，向 DN 发送自己的状态和一个序列号。

　　DN 在运行过程中维护此序列号，当 failover 时，新的 NN 在返回 DN 心跳时会返回自己的 active 状态和一个更大的序列号。DN 接收到这个返回则认为该 NN 为新的 active。

　　如果这时原来的 active NN 恢复，返回给 DN 的心跳信息包含 active 状态和原来的序列号，这时 DN 就会拒绝这个 NN 的命令。

 

---

 

 

Failover Controller

 

　　HA 模式下，会将 FailoverController 部署在每个 NameNode 的节点上，作为一个单独的进程用来监视 NN 的健康状态。 r FailoverController 主要包括三个组件: 

　　　　HealthMonitor: 监控 NameNode 是否处于 unavailable 或 unhealthy 状态。当前通过RPC 调用 NN 相应的方法完成。

　　　　ActiveStandbyElector: 监控 NN 在 ZK 中的状态。

　　　　ZKFailoverController: 订阅 HealthMonitor 和 ActiveStandbyElector 的事件，并管理 NN 的状态,另外 zkfc 还负责解决 fencing（也就是脑裂问题）。

　　上述三个组件都在跑在一个 JVM 中，这个 JVM 与 NN 的 JVM 在同一个机器上。但是两个独立的进程。一个典型的 HA 集群，有两个 NN 组成，每个 NN 都有自己的 ZKFC 进程。

 

 

 

ZKFailoverController 主要职责：

• 健康监测：周期性的向它监控的 NN 发送健康探测命令，从而来确定某个 NameNode是否处于健康状态，如果机器宕机，心跳失败，那么 zkfc 就会标记它处于一个不健康的状态

• 会话管理：如果 NN 是健康的，zkfc 就会在 zookeeper 中保持一个打开的会话，如果 NameNode 同时还是 Active 状态的，那么 zkfc 还会在 Zookeeper 中占有一个类型为短暂类型的znode，当这个 NN 挂掉时，这个 znode 将会被删除，然后备用的NN 将会得到这把锁，升级为主 NN，同时标记状态为 Active

• 当宕机的 NN 新启动时，它会再次注册 zookeper，发现已经有 znode 锁了，便会自动变为 Standby 状态，如此往复循环，保证高可靠，需要注意，目前仅仅支持最多配置 2 个 NN

• master 选举：通过在 zookeeper 中维持一个短暂类型的 znode，来实现抢占式的锁机制，从而判断那个 NameNode 为 Active 状态

 

---

---

 

 

 Yarn HA

 

　　Yarn 作为资源管理系统，是上层计算框架（如 MapReduce,Spark）的基础。在 Hadoop2.4.0 版本之前，Yarn 存在单点故障（即 ResourceManager 存在单点故障），一旦发生故障，恢复时间较长，且会导致正在运行的 Application 丢失，影响范围较大。从 Hadoop 2.4.0版本开始，Yarn 实现了 ResourceManager HA，在发生故障时自动 failover，大大提高了服务的可靠性。

　　ResourceManager（简写为 RM）作为 Yarn 系统中的主控节点，负责整个系统的资源管理和调度，内部维护了各个应用程序的 ApplictionMaster 信息、NodeManager（简写为 NM）信息、资源使用等。由于资源使用情况和 NodeManager 信息都可以通过 NodeManager 的心跳机制重新构建出来，因此只需要对 ApplicationMaster 相关的信息进行持久化存储即可。

　　在一个典型的 HA 集群中，两*立的机器被配置成 ResourceManger。在任意时间，有且只允许一个活动的 ResourceManger,另外一个备用。切换分为两种方式：

　　　　手动切换：在自动恢复不可用时，管理员可用手动切换状态，或是从 Active 到 Standby,或是从 Standby 到 Active。

　　　　自动切换：基于 Zookeeper，但是区别于 HDFS 的 HA，2 个节点间无需配置额外的 ZFKC守护进程来同步数据。