服务器之家:专注于服务器技术及软件下载分享
分类导航

PHP教程|ASP.NET教程|Java教程|ASP教程|编程技术|正则表达式|C/C++|IOS|C#|Swift|Android|VB|R语言|JavaScript|易语言|vb.net|

服务器之家 - 编程语言 - Java教程 - HDFS-Hadoop NameNode高可用机制

HDFS-Hadoop NameNode高可用机制

2021-11-29 13:31瘦风的南墙 Java教程

本文详细介绍了Hadoop NameNode高可用机制的各个方面内容,NameNode 的可用性直接决定了 Hadoop 集群的可用性,感兴趣的小伙伴可以参考本文章

 

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 的高可用架构

看图:

HDFS-Hadoop NameNode高可用机制

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 数据。

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 高可用组件简介

 

5.2.1 ZKFailoverController

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

 

5.2.2 HealthMonitor

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

 

5.2.3 ActiveStandbyElector

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

 

参考资料

http://www.zzvips.com/article/208139.html

http://www.zzvips.com/article/208140.html

以上就是Hadoop NameNode高可用机制的详细内容,更多关于Hadoop NameNode高可用的资料请关注服务器之家其它相关文章!

原文链接:https://www.cnblogs.com/shoufeng/p/15172108.html#版权声明

延伸 · 阅读

精彩推荐