HDFS的高可用(HA)--------通俗易懂的分析

Posted 2023-04-11

参考技术A 前言:
(NN:NameNode ; DN:DataNode)

那么我们详细讲解下他们之间是怎么完成实时同步,怎么完成切换工作?

在一个HDFS高可用集群中,配置两个独立的NN在运行,在任意时刻,都能保持由一个NN作为活动节点,一个作为备用节点,为了使两个节点之间保持数据实时同步,因此他们需要同一组独立运行的节点(journalNode , JNS)进行通信,活动的NN在进行数据命名空间或DN操作数据等情况下,操作流程会写入JNS中,同步到EditLog中,备用节点会实时监听JN中EditLog中的数据变化,一旦检测到有新操作更新,Standby NN(备份节点)就会将EditLog合并,更新自己的命名空间,完成数据同步.但是发生错误时, 他们的状态就会发生转变,切换流程是备份NN先将监听JNS中EditLog的变化合并到本地数据中,并对自身状态进行变更,变更为Active NN,通过这种机制,才保证了Active NN 和 Standby NN之间的数据保持统一,也就是第一关系的一致性.
其中对于状态立即转变起到关键作用的就是热备准备. DN对于数据统一起着重要作用,他们将自身的数据变化同时传输到两个NN中,这样他们的元数据就实时保持一致,后续的读取EditLog操作就节省了一大部分时间,更快速的完成两个状态之间的转变.
这里需要注意一个问题,在一个高可用的HDFS集群中,要始终保持只有一个活动的NN,否则就会出现"脑裂"问题(fancing) , "脑裂"会导致数据不一致,部分数据丢失,为了预防fancing的发生,需要注意一下两个机制:
HDFS的三个隔离级别:

a. 共享存储隔离:同一时间只允许一个NN向JNS中的EditLog进行数据写入
b.客户端隔离:同一时间只允许一个NN响应客户端的请求
c.DataNode隔离:同一时间,只允许一个NN给DN发送修改命名空间,修改数据等操作

Active NN 和 Standby NN的实时同步:
需要注意的是Active NN会将自身的日志文件写入到共享存储上,这时Standby NN会读取共享存储上的EditLog与自身的命名空间进行合并,这样才能在Active NN 发生错误时迅速进行状态转变.

在这个高可用集群中,Quorum Journal方案中有两个重要的组件:
1 Journal Nodes(JN):他将EditLog文件保存到Journal node的本地磁盘上,同时还对外开放了QJournalProtocol接口以方便执行远程读写EditLog的功能.
2 QuorumJournalManager(QJM):运行在namenode上,为其提供了RPC的调用接口,QJournalProtocol方法向JournalNode发送同步EditLog的操作

转自： https://blog.csdn.net/weixin_45678465/article/details/105334412

Hadoop高可用（HA机制）详解
见 https://www.pianshen.com/article/82051730014/

Hadoop (HDFS) HA架构通信机制

 HA高可用架构体系

首先，HDFS HA架构，一般指的是namenode的高可用，即：

1、一主一备两个namenode，他们通过Journalnode集群实现元数据等状态保持一致，一个出现健康问题，另一个就切换成新主，保证namenode稳定局面是保证hdfs集群稳定的关键所在

2、通过ZKFC持续监听两个namenode健康状态监控，若活跃节点出现健康问题，将由zookeeper对namenode锁释放，实现namenode高可用切换。

通过一张图我们除了看看namenode高可用通信机制，也同时看看datanode与namenode的通信情况：

如上图所示：

1. NameNode一主一备，当然是在不考虑联邦模式（Federation，联邦模式说白了也就是namenode的水平化伸缩，目的就是别把元数据和RPC操作都集中到一个地方，变成瓶颈，适合超大规模数据存储）的情况下。两个namenode通过对zookeeper集群目录的活跃锁争夺，来明确谁是活跃的（active）。

2. FailoverControllerActive（ZKFC）每个namenode上都有一个这样的服务，就是监控namenode健康，并把健康心跳不断报告给zookeeper，活动namenode不心跳了，zookeeper就把锁给另一个备着的namenode，那么它就成为Active namenode状态了。

3. 由多个Journalnode组成QJM高可用集群，提供active namenode各项元数据的状态信息存储服务，并为备用namenode提供这些信息状态同步服务，因此备用namenode就可以随时等待active namenode故障时，zookeeper对活跃锁的释放，使其切换成新的活动首领。

---

namenode和datanode直接通信关系

它们两个之间一种是直接通信的情况，另一种是客户端与它们两者建立直接通信（相当于两者是间接通信关系了）。

直接通信很好理解，分成了两个阶段

1. datanode初始化阶段，会创建namenode的代理对象，通过RPC调用，将datanode注册给namenode，包括存储信息、主机地址、UUID、端口、版本等等...，而namenode接收到datanode信息后，会记录到自己的网络拓扑数据结构中，namenode也是根据网络拓扑结构为客户端提供最佳位置（最近）的datanode副本。

2. 注册好以后，datanode通过namenode代理向其发送心跳（heartbeat），一般3秒建立一次心跳连接，如果在超过约定间隔，namenode探测到没与datanode的建立心跳，namende会认为这个datanode节点挂了，然后寻求一个新的datanode数据节点，根据相应挂掉节点的副本数据，为新的节点增加副本数据。

---

namenode和datanode间接通信的关系

由客户端主导并参与其中的通信机制——namenode和datanode之间没有直接通信关系，始终通过客户端保持一种间接通信的关系。

主要是通过客户端来实现数据的上传和下载

HDFS客户端读取流程概括图

如上图所示：

1. 客户端向hdfs namenode节点发送Path文件路径的数据访问的请求

2.  Namenode会根据文件路径收集所有数据块（block）的位置信息，并根据数据块在文件中的先后顺序，按次序组成数据块定位集合（located blocks），回应给客户端。

3. 客户端拿到数据块定位集合后，创建HDFS输入流，定位第一个数据块所在的位置，并读取datanode的数据流。之后根据读取偏移量定位下一个datanode并创建新的数据块读取数据流，以此类推，完成对HDFS文件的整个读取。

HDFS客户端写入流程概括图

如上图所示：

1. 客户端先通过namenode代理，请求namenode创建数据块和分配datanode。

2. 客户端通过HDFS输出流的方式将dfs包写入namenode指定的datanode数据块中，datanode通过写入链的方式完成其他副本的数据块写入，并依次返回完成确认。

3. 客户端的HDFS输出流在得到完成确认（ACK）之后，关闭HDFS文件流，并向namenode汇报完成。