HDFS 09 - HDFS NameNode 的高可用机制

目录

• 1 - 为什么要高可用
• 2 - NameNode 的高可用发展史
• 3 - HDFS 的高可用架构
  • 3.1 Standby 和 Active 的命名空间保持一致
  • 3.2 同一时刻只有一个 Active NameNode
• 4 - HDFS 高可用的实现原理
  • 4.1 隔离（Fencing）- 预防脑裂
  • 4.2 Qurom Journal Manager 共享存储
• 5 - 其他补充
  • 5.1 QJM 的 Fencing 方案
  • 5.2 - HDFS 高可用组件简介
    • ZKFailoverController
    • HealthMonitor
    • ActiveStandbyElector
• 参考资料
• 版权声明

1 - 为什么要高可用

在 Hadoop 中，NameNode 扮演着至关重要的角色 —— 整个 HDFS 文件系统的元数据信息都由 NameNode 管理，一旦 NameNode 进程出现异常，或者维护 NameNode 所在节点的时候，都会导致 HDFS 集群不可用。

所以 NameNode 的可用性直接决定了 Hadoop 集群的可用性。

2 - NameNode 的高可用发展史

在 Hadoop 2.0 以前，每个 HDFS 集群只有一个 NameNode，一旦这个节点不可用，则整个 HDFS 集群将处于不可用状态 —— 即，HDFS 2.0 以前，NameNode 存在单点故障风险。

与典型的 HA（High Availability，高可用）方案一样（参考：常见的六种容错机制），HDFS 2.0 开始支持的 HA，就是 在 HDFS 集群中同时运行两个 NameNode。

一个处于 Active（活跃）状态：负责集群中所有客户端的操作（修改命名空间、删除备份数据块等操作）；

另一个处于 Standby（备份）状态：充当从服务器，和 Active NameNode 有相同的命名空间和元数据。

当 Active NameNode 停止服务时，Standby NameNode 能够快速进行故障切换，以保证 HDFS 集群服务不受影响。

3 - HDFS 的高可用架构

看图：

Standby NemeNode 是如何做到故障切换的？换句话说，它和 Active NameNode 之间的数据是如何保持一致的？

3.1 Standby 和 Active 的命名空间保持一致

它们存储着一样的元数据，可以把集群恢复到系统奔溃时的状态 —— 这是实现自动故障切换的基础。

为了使备份节点与活动节点的数据保持同步，两个节点都需要同一组独立运行的节点来通信，HDFS 中把这样的节点称为 JournalNode。

1）第一关系链的一致性，即 Active NameNode 和 Standby NameNode 的命名空间状态的一致性：

a）Active NameNode 会定期地把 修改命名空间或删除备份数据块等操作 记录到 EditLog，同时写到 JN 的多数节点中。

b）Standby NameNode 会一直监听 JN 上 EditLog的变化，如果 editlog 有改动，Standby NameNode 就会读取 editlog 并与当前的命名空间合并。

c）Active NameNode 出现故障时，Standby NameNode 会保证已经从 JN 上读取了所有 editlog 并与命名空间合并，然后才会从 Standby 切换为 Active。

2）第二关系链的一致性，即数据块的存储信息的一致性：

为了使故障切换能够尽快执行成功，就要保证 Standby NameNode 也 实时保存了数据块的存储信息，HDFS 中是这样做的：

DataNode 会同时向两个 NameNode 发送心跳以及块的存储信息。

这样以来，发生故障切换时，Standby NameNode 就可以直接切换到 Active 状态（它和旧 Active 节点的元数据完全一致），而不需要等待所有的 DataNode 汇报全量数据块信息 —— 这也是热备功能。

需要注意：Standby NameNode 只会更新数据块的存储信息，并不会向 DataNode 发送复制或删除数据块的指令，这些指令只能由 Active NameNode 发送。

3.2 同一时刻只有一个 Active NameNode

如果两个 NameNode 都是活跃状态，那么这个集群就会被分成2个小集群，它们都认为自己是唯一活动的集群。这就是著名的“脑裂”现象。

脑裂的 HDFS 集群很可能造成数据错乱、丢失数据块，还可能向 DataNode 下发错误的指令，这些错误都很难恢复。

4 - HDFS 高可用的实现原理

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

4.1 隔离（Fencing）- 预防脑裂

预防脑裂的常见方案就是 Fencing，即隔离，思路是把旧的 Active NameNode 隔离起来，使它不能正常对外提供服务，使集群在任何时候都只有一个 Active NameNode。

HDFS 提供了 3 个级别的隔离（Fencing）：

1）共享存储隔离：同一时间只允许一个 NameNode 向 JournalNode 写入 EditLog 数据。

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

2）客户端隔离：同一时间只允许一个 NameNode 可以响应客户端的请求。

3）DataNode 隔离：同一时间只允许一个 NameNode 向 DataNode 下发命名空间相关的命令，例如删除块，复制块等。

4.2 Qurom Journal Manager 共享存储

在 HDFS 的 HA 架构中还有一个非常重要的部分：Active NameNode 和 Standby NameNode 之间如何共享 EditLog 文件。

解决思路是：Active NameNode 将日志文件写到共享存储上，Standby NameNode 实时地从共享存储读取 EditLog 文件，然后合并到 Standby NameNode 的命名空间中。一旦 Active NameNode 发生错误，Standby NameNode 就可以立即切换到Active状态。

HDFS 2.6 开始，提供了一个叫做 Qurom Journal Manager（QJM）的共享存储方案，来解决 HA 架构中元数据的共享存储问题。

QJM 基于 Paxos 算法实现，基本原理是：HDFS 集群中有 2n+1 台 JournalNode，EditLog 保存在 JN 的本地磁盘上；

每个 JournalNode 都允许 NmaeNode 通过它的 RPC 接口读写 EditLog 文件；

当 NmaeNode 向共享存储写入 EditLog 文件时，它会通过 QJM 向集群中所有的 JournalNode 并行发送写 EditLog 文件的请求，当有一半以上（>=n+1）的 JN 返回写操作成功时，就认为这次写操作成功了。

每次写数据操作有多数（>=n+1）JN 返回成功，就认为这次写操作成功了。

由此我们可以知道，这个 QJM 必须也是高可用的，否则 HDFS 的高可用就无法保障。

QJM 实现 HA 的主要好处：

• 不存在单点故障问题；
• 不需要配置额外的共享存储，降低了复杂度和维护成本；
• 不需要单独配置 Fencing 实现（见文末#5.1节），因为 QJM 本身就内置了 Fencing 的功能；
• 系统的鲁棒性程度是可配置的（ QJM 基于 Paxos 算法，配置 2n+1 台 JournalNode，最多能容忍 n 台机器同时挂掉）；
• QJM 中存储日志的 JournalNode 不会因为其中一台的延迟而影响整体的延迟，而且也不会因为 JournalNode 的数量增多而影响性能（因为 NameNode 向 JournalNode 发送日志是并行的）。

关于 QJM 的具体工作原理，后面有机会了专门讲讲。

5 - 其他补充

5.1 QJM 的 Fencing 方案

QJM 的 Fencing 只能让原来的 Active NN 失去对 JN 的写权限，但是原来的 Active NN 还是可以响应客户端的请求，对 DataNode 进行读操作。

对客户端和 DataNode 的隔离是通过配置 dfs.ha.fencing.methods 实现的，Hadoop 公共库中有两种 Fencing 实现：

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

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

5.2 - HDFS 高可用组件简介

ZKFailoverController

是基于 ZooKeeper 的故障转移控制器，它负责控制 NameNode 的主备切换，ZKFailoverController 会监测NameNode 的健康状态，当发现 Active NameNode 出现异常时会通过 ZooKeeper 进行一次新的选举，完成 Active 和 Standby 状态的切换。

HealthMonitor

周期性调用 NameNode 的 HAServiceProtocol RPC 接口（monitorHealth 和 getServiceStatus），监控NameNode 的健康状态并向 ZKFailoverController 反馈。

ActiveStandbyElector

接收 ZKFailoverController 的选举请求，通过 ZooKeeper 自动完成主备选举，选举完成后回调ZKFailoverController 的主备切换方法对 NameNode 进行 Active 和 Standby 状态的切换。

参考资料

https://hadoopdoc.com/hdfs/hdfs-namenode-ha

https://blog.csdn.net/u012736748/article/details/79534019

版权声明

作者：瘦风(https://healchow.com)

出处：博客园-瘦风的南墙(https://www.cnblogs.com/shoufeng)

感谢阅读，公众号 「瘦风的南墙」 ，手机端阅读更佳，还有其他福利和心得输出，欢迎扫码关注

本文版权归博主所有，欢迎转载，但 [必须在页面明显位置标明原文链接]，否则博主保留追究相关人士法律责任的权利。