Hadoop系列-Hadoop高可用（三）

一、Hadoop高可用

在Hadoop 2.0以前的版本，NameNode面临单点故障风险（SPOF），也就是说，一旦NameNode节点挂了，整个集群就不可用了，而且需要借助辅助NameNode来手工干预重启集群，这将延长集群的停机时间。而Hadoop 2.0版本支持一个备用节点用于自动恢复NameNode故障，Hadoop 3.0则支持多个备用NameNode节点，这使得整个集群变得更加可靠。

什么是 Hadoop 高可用

Hadoop 2.0版本支持一个备用节点用于自动恢复NameNode故障，Hadoop 3.0则支持多个备用NameNode节点，这些都是针对NameNode单点故障问题比较可靠的解决方案。利用一个或者多个备用NameNode来达到故障时自动切换的目的，这就是我们所说的Hadoop高可用。

什么是故障切换

当系统中其中一项设备失效而无法运作时，另一项设备即可自动接手原失效系统所执行的工作，这就是故障切换。

故障切换可分成两种方式：

优雅的故障切换：这种需要系统管理员手动切换。通常在定期维护系统的时候使用这种故障切换方式，也就是说必须人工干预，把集群控制权切换到备用的NameNode。
自动故障切换：系统自动把集群控制器切换到备用NameNode，且切换过程不需要人工干预。

NameNode 高可用

Hadoop 实现自动故障切换需要用到下面的组件：

• ZooKeeper quorum
• ZKFailoverController 进程（ZKFC）

ZooKeeper quorum

ZooKeeper quorum 是一种集中式服务，主要为分布式应用提供协调、配置、命名空间等功能。它提供组服务和数据同步服务，它让客户端可以实时感知数据的更改，并跟踪客户端故障。HDFS故障自动切换的实现依赖下面两个方面：

• 故障监测：ZooKeeper维护一个和NameNode之间的会话。如果NameNode发生故障，该会话就会过期，会话一旦失效了，ZooKeeper将通知其他NameNode启动故障切换进程。

• 活动NameNode选举：ZooKeeper提供了一种活动节点选举机制。只要活动的NameNode发生故障失效了，其他NameNode将从ZooKeeper获取一个排它锁，并把自身声明为活动的NameNode。

ZKFailoverController（ZKFC）

ZKFC 是 ZooKeeper 的监控和管理 namenode 的一个客户端。所以每个运行 namenode 的机器上都会有 ZKFC。

那ZKFC具体作用是什么？主要有以下3点：

状态监控：ZKFC 会定期用 ping 命令监测活动的 NameNode，如果 NameNode 不能及时响应ping 命令，那么 ZooKeeper 就会判断该活动的 NameNode 已经发生故障了。

ZooKeeper会话管理：如果 NameNode 是正常的，那么它和 ZooKeeper 会保持一个会话，并持有一个 znode 锁。如果会话失效了，那么该锁将自动释放。

基于ZooKeeper的选举：如果 NameNode 是正常的，ZKFC 知道当前没有其他节点持有 znode 锁，那么 ZKFC 自己会试图获取该锁，如果锁获取成功，那么它将赢得选举，并负责故障切换工作。这里的故障切换过程其实和手动故障切换过程是类似的；先把之前活动的节点进行隔离，然后把 ZKFC 所在的机器变成活动的节点。

二、HDFS 高可用与容错

HDFS 是一个分布式文件系统，它会给文件创建副本并把副本分发到集群的节点上，因此，在读取数据的时候可以从多个节点上读取。这对数据的容错是非常有益的，在读取的时候，节点挂了，可以去其他节点读取相同的数据。HDFS 就是通过这种方式实现了数据的高可用和容错。

HDFS 如何实现高可用

一个 HDFS 集群一般有很多 Datanode 节点，并且会定期给 Namenode 发送心跳信息，如果 Namenode 在规定时间内没接收到 Datanode 的心跳信息，那么它就会认为该 Datanode 发生故障了。接着它会检查节点上的存在的数据，并给其他 Datanode（ 这些 Datanode 存储了损坏节点的数据 ） 发送指令，创建数据的拷贝并存储到另外的 Datanode。因此，数据总是保持可用的。

从 HDFS 读取数据时，Namenode 会先检查哪些 Datanode 的数据是可用的，再把存储数据的 Datanode 地址列表返回。客户端不需要遍历集群的所有节点查找数据，只需根据 Namenode 提供的 Datanode 地址列表，直接从对应的 Datanode 读取数据即可。

HDFS 数据容错

HDFS 容错指的是集群部分机器宕机了，集群依然可以正常提供服务的能力。HDFS 是具有很好的容错性的分布式存储系统，它利用复制技术实现数据容错能力，数据会被复制多份并存储在集群的不同节点。这样，集群中的某些机器宕机了，数据还可以从其他正常运行的机器获取。如果有一个机器宕机了，HDFS 会在其他可用的机器创建数据的副本，来保证该数据的副本数与集群的副本因子是一致的。

HDFS 如何实现容错

HDFS 通过复制进程来保证容错机制。在文件写入 HDFS 时，HDFS 会首先把文件分割成块，并把这些数据块存储在集群不同机器上，然后在其他机器创建各个块的副本，默认情况下，HDFS 会在其他机器创建3个文件的副本。所以，HDFS 集群任意机器挂了，我们依然能从其他保存数据副本的机器上读取数据，由于这种独特的分布式存储特性，HDFS 给我们提供了更快的文件读写机制。

三、HDFS Namenode 高可用

在 Hadoop 2.0.0 之前，一个集群只有一个Namenode，这将面临单点故障问题。如果 Namenode 机器挂掉了，整个集群就用不了了。只有重启 Namenode ，才能恢复集群。另外正常计划维护集群的时候，还必须先停用整个集群，这样没办法达到 7 * 24小时可用状态。Hadoop 2.0 及之后版本增加了 Namenode 高可用机制，下面详细介绍。

Hadoop Namenode 高可用架构

Hadoop 2.0 克服了 Namenode 单点故障问题，即在一个集群中有2个 Namenode 节点，一个是活动的Namenode节点（Active Namenode），即主节点，一个是备用 Namenode（Passive Namenode），即备用节点，而且支持热备份和故障切换。

活动 Namenode：负责处理集群中所有客户端请求。
备用 Namenode：备用节点，拥有和活动的 Namenode 一样的元数据。在活动 Namenode 失效后，会接管它的工作。

活动 Namenode 和备用 Namenode 之间是如何同步数据的呢？即他们是怎么保持一致性的，主要有下面几点：

• 活动和备用 Namenode 两者总是同步的，例如，他们存储着一样的元数据，这可以把集群恢复到系统奔溃时的状态。而且基于此还能实现自动故障切换。

• 同一时间，集群只能有一个活动的 Namenode 节点，否则，两个 Namenode 会导致数据发生错乱并且无法恢复。我们把这种情况称为“脑裂”现象，即一个集群被分成两个小集群，并且两边都认为自己是唯一活动的集群。Zookeeper 社区对这种问题的解决方法叫做 fencing，中文翻译为隔离，也就是想办法把旧的 活动 NameNode 隔离起来，使它不能正常对外提供服务，使集群始终只有一个活动的 Namenode。

了解完 Hadoop 高可用架构之后，让我们来看一下 Hadoop Namenode 高可用是怎么实现的。

Namenode 高可用的实现

这里主要介绍通过隔离（fencing）和Quorum Journal Manager（QJM）共享存储实现的 HDFS 高可用。

隔离（Fencing）

隔离（Fencing）是为了防止脑裂，就是保证在任何时候HDFS只有一个Active NN，主要包括三个方面：

• 共享存储fencing：确保只有一个NN可以写入edits。QJM中每一个JournalNode中均有一个epochnumber，匹配epochnumber的QJM才有权限更新 JN。当 Namenode 由 standby 状态切换成 active 状态时，会重新生成一个 epochnumber，并更新 JN 中的 epochnumber，以至于以前的 Active Namenode 中的QJM 中的 epoch number 和 JN 的 epochnumber 不匹配，故而原 Active Namenode上的 QJM 没法往 JN 中写入数据（后面会介绍源码），即形成了 fencing。

• 客户端f encing：确保只有一个 Namenode 可以响应客户端的请求。

• DataNode fencing：确保只有一个 Namenode 可以向 Datanode 下发命令，譬如删除块，复制块，等等。

QJM 的 Fencing 方案只能让原来的 Active Namenode 失去对 JN 的写权限，但是原来的 Active Namenode 还是可以响应客户端的请求，对 Datanode 进行读。对客户端和 DataNode 的 fence 是通过配置 dfs.ha.fencing.methods 实现的。

Hadoop 公共库中有两种Fencing实现：sshfence、shell

• sshfence：ssh到原Active NN上，使用fuser结束进程（通过tcp端口号定位进程 pid，该方法比 jps 命令更准确）。

• shell：即执行一个用户事先定义的shell命令（脚本）完成隔离。

QJM共享存储

Qurom Journal Manager（QJM）是一个基于 Paxos 算法实现的 HDFS 元数据共享存储的方案。QJM 的基本原理就是用 2N+1 台 JournalNode 存储 EditLog，每次写数据操作有大多数（>=N+1）返回成功时即认为该次写成功，数据不会丢失。这个算法所能容忍的是最多有 N 台机器挂掉，如果多于 N 台挂掉，这个算法就失效了。这个原理是基于 Paxos 算法的。

用QJM的方式来实现HA的主要好处有：

• 不需要配置额外的高共享存储，这样对于基于商用硬件的云计算数据中心来说，降低了复杂度和维护成本；

• 不在需要单独配置 fencing 实现，因为 QJM 本身内置了 fencing 的功能；

• 不存在单点故障问题；

• 系统鲁棒性的程度是可配置的（ QJM 基于 Paxos 算法，所以如果配置 2N+1 台 JournalNode 组成的集群，能容忍最多 N 台机器挂掉）；

• QJM 中存储日志的 JournalNode 不会因为其中一台的延迟而影响整体的延迟，而且也不会因为 JournalNode 的数量增多而影响性能（因为 Namenode 向 JournalNode 发送日志是并行的）。

四、Yarn高可用

在Hadoop 2.4之前，ResourceManager是YARN群集中的单点故障。 高可用性功能以“活动/备用ResourceManager”对的形式添加了冗余，以消除此否则的单点故障。这节我们就学习一下YARN ResourceManager的高可用性，并详细介绍了如何配置和使用此功能。

实现原理

ResourceManager HA通过Active / Standby架构实现，在任何时间，多个RM中都只有一个是处于Active状态，并且有一个或多个RM处于Standby模式。

启用自动故障转移策略后，就可以在RM 发生故障之后完成故障转移，其他的备用RM将会选出一个处于Active 状态，然后接管故障的RM。

当然你也可以通过yarn rmadmin 命令来手动切换RM，自动转移通过ZK 实现的

重启

ResourceManager是管理资源和调度在YARN上运行的应用程序的中央机构。因此，它在整个Apache YARN群集中有潜在单点故障风险。本文档概述了ResourceManager重新启动，此功能可以增强ResourceManager使其在重新启动后仍能正常运行，并且还可以使用户感知不到ResourceManager的重启。ResourceManager 支持两种重启策略

不保留工作的RM重新启动，此重新启动增强了RM，以将应用程序/尝试程序 状态和其他凭据信息保留在可插拔状态存储中。 RM将在重新启动时从状态存储中重新加载此信息，并重新启动以前运行的应用程序。不需要用户重新提交应用程序。

保留工作的RM重新启动：此操作着重于通过结合NodeManagers的容器状态和重新启动时来自ApplicationMaster的容器请求来重建RM的运行状态。与不保留工作的RM重新启动的主要区别在于，RM重新启动后，先前运行的应用程序不会被杀死，因此应用程序不会因为RM中断而失去工作。

不保留工作的RM重新启动

RM将在客户端提交应用程序时将应用程序元数据（即ApplicationSubmissionContext）保存在可插拔状态存储中，并保存应用程序的最终状态，例如完成状态（失败，中止或终止）。完成），并在应用程序完成时进行诊断。

此外，RM还保存凭据（如安全密钥，令牌）以在安全环境中工作。当RM关闭时，只要状态存储中提供了所需的信息（即，应用程序元数据和在安全环境中运行的并列凭证），那么RM重新启动时，它就可以从状态存储中提取应用程序元数据，存储并重新提交应用程序。如果RM在停机之前已经完成（即失败，中止或完成），则它们不会重新提交申请。

在RM停机期间，NodeManager和客户端将继续轮询RM，直到RM出现为止。 RM启动时，它将通过心跳向正在与之通信的所有NodeManager和ApplicationMaster发送重新同步命令。

NM将杀死其所有托管容器并向RM重新注册。这些重新注册的NodeManager与新加入的NM相似。 AM（例如MapReduce AM）收到重新同步命令后，预计会关闭。 RM重新启动并从状态存储加载所有应用程序元数据，凭据并将其填充到内存后，它将为每个尚未完成的应用程序创建新的尝试（即ApplicationMaster），并照常重新踢该应用程序。如前所述，以前运行的应用程序的工作以这种方式丢失，因为它们实际上是在重新启动时通过re-sync命令被RM杀死的。

保留工作的RM重新启动

在保留工作的RM重新启动中，RM确保应用程序状态的持久性并在恢复时重新加载该状态，此重新启动主要着重于重建YARN群集的整个运行状态，其中大部分是RM内部中央调度程序的状态。跟踪所有容器的生命周期，应用程序的净空和资源请求，队列的资源使用情况等等。这样，RM无需终止AM并从头开始重新运行应用程序，因为它是在不保留工作的RM重新启动中完成的。应用程序可以简单地与RM重新同步，并从上次停止的地方恢复。

RM通过利用从所有NM发送的容器状态来恢复其运行状态。与重新启动的RM重新同步时，NM将不会杀死容器。它继续管理容器，并在重新注册时将容器状态发送给RM。 RM通过吸收这些容器的信息来重建容器实例和关联的应用程序的调度状态。同时，由于RM可能会在关闭时丢失未完成的请求，因此AM需要将未完成的资源请求重新发送给RM。使用AMRMClient库与RM进行通信的应用程序编写者不必担心AM重新发送资源请求到重新同步到RM的部分，因为库本身会自动处理。