Hadoop HA

Hadoop HA

概述

HA(High Available), 高可用，是保证业务连续性的有效解决方案，一般有两个或两个以上的节点，分为活动节点（Active）及备用节点（Standby）。通常把正在执行业务的称为活动节点，而作为活动节点的一个备份的则称为备用节点。
当活动节点出现问题，导致正在运行的业务（任务）不能正常运行时，备用节点此时就会侦测到，并立即接续活动节点来执行业务。从而实现业务的不中断或短暂中断。
Hadoop1.X 版本，NN 是 HDFS 集群的单点故障点，每一个集群只有一个 NN,如果这个机器或进程不可用，整个集群就无法使用。为了解决这个问题，出现了一堆针对 HDFS HA 的解决方案（如：Linux HA, VMware FT, shared NAS+NFS, BookKeeper, QJM/Quorum Journal Manager, BackupNode 等）。
在 HA 具体实现方法不同情况下，HA 框架的流程是一致的, 不一致的就是如何存储、管理、同步 edits 编辑日志文件。
在 Active NN 和 Standby NN 之间要有个共享的存储日志的地方，Active NN 把 edit Log 写到这个共享的存储日志的地方，Standby NN 去读取日志然后执行，这样 Active 和 Standby NN 内存中的 HDFS 元数据保持着同步。一旦发生主从切换 Standby NN 可以尽快接管 Active NN 的工作。

Namenode 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 的命令。

架构上的修改：

1. namenode之间需要通过高可用共享存储实现编辑日志的共享。当备用namenode接管工作之后，它将通读共享编辑日志直至末尾，以实现与活动namenode的状态同步，并继续读取由活动namenode写入的新条目。
2. datanode需要同时向两个namenode发送数据块处理报告，因为数据块的映射信息存储在namenode的内存中，而非磁盘。
   ·客户端需要使用特定的机制来处理namenode的失效问题，这一机制对用户是透明的。
3. 辅助namenode的角色被备用namenode所包含，备用namenode为活动的namenode命名空间设置周期性检查点。
4. 可以从两种高可用性共享存储做出选择：NFS过滤器或群体日志管理器（QJM，quorum journal manager）。QJM是一个专用的HDFS实现，为提供一个高可用的编辑日志而设计，被推荐用于大多数HDFS部署中。QJM以一组日志节点（journalnode）的形式运行，每一次编辑必须写入多数日志节点。典型的，有三个journal节点，所以系统能够忍受其中任何一个的丢失。这种安排与ZooKeeper的工作方式类似，当然必须认识到，QJM的实现并没使用ZooKeeper。（然而，值得注意的是，HDFSHA在选取活动的namenode时确实使用了ZooKeeper技术。

Failover Controller

HA 模式下，会将 FailoverController 部署在每个 NameNode 的节点上，作为一个单独的进程用来监视 NN 的健康状态。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 主要职责：

1. 健康监测：周期性的向它监控的 NN 发送健康探测命令，从而来确定某个 NameNode是否处于健康状态，如果机器宕机，心跳失败，那么 zkfc 就会标记它处于一个不健康的状态
2. 会话管理：如果 NN 是健康的，zkfc 就会在 zookeeper 中保持一个打开的会话，如果 NameNode 同时还是 Active 状态的，那么 zkfc 还会在 Zookeeper 中占有一个类型为短暂类型的 znode，当这个 NN 挂掉时，这个 znode 将会被删除，然后备用的NN 将会得到这把锁，升级为主 NN，同时标记状态为 Active
3. 当宕机的 NN 新启动时，它会再次注册 zookeper，发现已经有 znode 锁了，便会自动变为 Standby 状态，如此往复循环，保证高可靠，需要注意，目前仅仅支持最多配置 2 个 NN
4. master 选举：通过在 zookeeper 中维持一个短暂类型的 znode，来实现抢占式的锁机制，从而判断那个 NameNode 为 Active 状态

YARN HA

Yarn 作为资源管理系统，是上层计算框架（如 MapReduce,Spark）的基础。在 Hadoop 2.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 守护进程来同步数据。