大数据开发利器：Hadoop（11） Hadoop2 HA(High Availability)

本节主要介绍了HDFS HA(High Availability)的原理、主备切换过程以及基于JournalNode的共享存储系统。

1. 前言

在当初介绍Hadoop2.0时，我们简单提到了Hadoop框架中MapReduce的不足与改进。（即设计了新的资源管理框架YARN）。
那么，Hadoop2.0针对HDFS在Hadoop1.0的存在的问题如何改进了呢？
HDFS在Hadoop1.0中主要存在以下两个问题：
① 单一名称节点，所以可能产生单点失效问题。
② 单一名称节点，所以无法实现资源隔离。

所以针对HDFS以上两个问题，Hadoop2.0进行以下改进：
① 设计了HDFS HA，提供名称节点热备机制。
② 设计了HDFS Federation，管理多个命名空间。

本节主要对HDFS HA进行介绍。

2. HDFS HA(Availability)

2.1 HDFS1.0 组件及其功能回顾

① Namenode

• 名称节点namenode负责管理分布式文件系统的命名空间namespace，保存了两个核心的数据结构：FsImage和EditLog。
  
  • FsImage用于维护文件系统树以及文件树中所有文件和文件夹的元数据。
  • 操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作。
• 名称节点记录了每个文件中各个块所在的数据节点中的位置信息。

② Datanode

• 数据节点datanode是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送所存储的块的列表。
• 每个数据节点中的数据都会被保存在各自节点的本地Liunx文件系统中。

两者功能如下图：

2.2 HDFS 1.0 单点故障问题

HDFS运行原理如下图：

① 第二名称节点SecondaryNameNode会定期和Namenode通信。
② 从Namenode上获取到FsImage和EditLog文件，并下载到本地的相应目录下。
③ 执行EditLog和FsImage文件合并。
④ 将新的FsImage文件发送到Namenode节点上。
⑤ Namenode使用新的FsImage和EditLog（缩小了）。

所以，我们可以发现，SecondaryNameNode不是热备份，主要是防止日志文件EditLog过大，导致名称节点失败恢复时消耗过多时间，同时附带冷备份功能。
可以得出结论，SecondaryNameNode无法解决单点故障问题。
因此，HDFS2.0提供了HDFS HA的解决方案。

2.3 HDFS HA 原理

HDFS HA(High Availability)如其名，高可用性，是为了解决单点故障问题。
主要用以下方法进行解决：
① HA集群设置了两个名称节点：Active和Standby，即活跃和待命。
② 两种名称节点的状态同步，可以借助一个共享存储系统来实现。
③ 一旦活跃名称节点Active出现故障，就可以立即切换到待命名称节点Standby。
④ Zookeeper确保一个名称节点在对外服务。（主备切换控制）
⑤ 名称节点维护映射信息，数据节点同时向两个名称节点汇报信息。

HDFS HA架构如以下两个图：

---

2.4 HDFS HA组件介绍

主要就是以下几个组件：

① Active Namenode

这是主Namenode，处于Active状态。只有主名称节点才能对外提供读写服务。

② Standby Namenode

这是备Namenode，处于Standby状态。

③ ZKFailoverController

这是主备切换器，作为独立的进程运行。对Namenode的主备切换进行整体控制。ZKFC能够及时监测到节点的健康状况。在主Namenode故障的时候，借助Zookeeper这个集群去实现自动的主备选举和切换。

④ Zookeeper集群

⑤ 共享存储系统

这是实现Namenode高可用性的关键。它把一部分元数据存储在这里面。主Namenode和备Namenode通过它实现共享元数据的同步。

⑥ Datanode

数据节点功能和之前类似。唯一的区别是之前只需要向一个Namenode汇报信息，现在需要向主备namenode都汇报信息。

2.5 Namenode的主备切换

以下是Namenode的主备切换流程图：

• Namenode主要是由ZKFailoverControllar、HealthMonitor和ActiveStandByElector这三个组件协同完成的。
• ZKFC这个进程作为Namenode机器上的一个独立进程启动，启动时候会创建HealthMonitor和ActiveStandbyElector这两个主要的内部组件。ZKFC在创建这两个组件的同时也会向HealthMonitor和ActiveStandByElector注册相应的回调方法。

---

HealthMonitor主要负责监测namenode健康状态，可以理解为ZKFC直接去监测namenode的健康状态。如果namenode状态发生变化，它会回调ZKFC的相应方法，进行自动的主备选举。
ActiveStandbyElector主要负责完成自动的主备选举，它内部封装了Zookeeper的处理逻辑，一旦Zookeeper主备选举完成，就会回调ZKFC的相应方法来进行namenode的主备切换。

2.6 基于JournalNode的共享存储系统

作用主要为：
共享存储把一部分元数据存储在这里面，主、备Namenode通过它实现共享元数据的同步。

参看前面介绍的架构图。

---

① Namenode执行原理介绍

Namenode在执行HDFS的客户端提交、创建文件或者移动文件这样操作的时候。会首先把这些操作日志写入EditLog，然后在更新内存中的文件系统镜像。
文件系统镜像用于namenode向客户端提供读服务，而EditLog只是在数据恢复时候起作用。
Namenode也会定期对内存中的文件系统镜像进行Checkpoint，在磁盘上生成FsImage文件。
在namenode启动的时候，会进行数据恢复，首先把FsImage文件加载到内存中，形成文件系统镜像。

② 共享存储介绍

基于JournalNode的共享存储主要用于保存EditLog，并不保存Fsimage文件，FsImage还是在本地磁盘上。
JournalNode集群共享存储的基本思想是来自Paxos算法。采用多个成为JournalNode节点组成，JouranlNode集群来存储EditLog，每个JournalNode保存同样的EditLog副本，每个JouranlNode写EditLog的时候除了向本地磁盘写EditLog之外，也会并行的向JournalNode集群之中的每一个JournalNode发送写请求。只要大多数的节点返回成功，就认为向Journalnode集群写入EditLog成功。
一般，Journalnode建立配置奇数个。如果Journal有2n+1台，那么根据大多数的原则，最多容忍n台journalnode节点挂掉。

③ Active和Standby状态原理

当处于Active状态的namenode会同时向本地磁盘目录和journalnode集群的共享存储目录写入EditLog。写入JournalNode集群通过并行调用每个Journal的RPC接口和方法去实现的。如果大多数写成功了，即提交EditLog成功，否则说明提交失败。

---

当Namenode进入Standby状态时候，会定期地调用从JournalNode集群上同步的EditLog，是并行地去调用，然后把同步的EditLog放回内存中文件系统镜像上，虽然Active nodenode向Journalnode集群上提交EditLog是同步的，但Standbynamenode采用的是定时的从Journalnode集群上同步EditLog。

---

那么Standbynamenode内存中的文件系统镜像就很大可能会落后于Activenamenode，所以当Standbynamenode切换为Activenamenode的时候，就需要把落后的EditLog补上来。同时，由于主备切换，有可能Activenamenode发生异常退出，那么Journalnode的数据很可能处于不一致状态，所以首先让Journalnode上的EditLog恢复成一致，这样，就需要补齐落后的EditLog。
这两步完成之后，这样才能正式成为一个Active，从而对外提供服务。

3. 总结

本节主要介绍了HDFS HA(High Availability)的原理、主备切换过程以及基于JournalNode的共享存储系统。
概念性的定义较多，需要进一步的熟悉。下一节介绍搭建企业级的Hadoop。

参考资料

林子雨 - 大数据技术原理和应用
王滨 - 网易云课程
Hadoop NameNode 高可用 (High Availability) 实现解析- https://www.ibm.com/developerworks/cn/opensource/os-cn-hadoop-name-node/