月度归档： 2023 年 2 月

Hadoop HA（High Available）经过同时配置两个处于Active/Passive模式的Namenode，分别叫Active Namenode和Standby Namenode。 Standby Namenode做为热备份，从而容许在机器发生故障时可以快速进行故障转移，同时在平常维护的时候使用优雅的方式进行Namenode切换。Namenode只能配置一主一备，不能多于两个Namenode。

Hadoop HA基本流程

集群总体上可以分为三部分：NameNode集群、JournalNode集群和Zookeeper集群。NameNode在某一时刻只有一个处于活跃状态，其他的都处于standby状态；JournalNode负责把edits文件传到standby的NameNode上；Zookeeper负责监控NameNode宕机情况，ZKFC(ZookeeperFailoverController)是专门监控NameNode健康的。

为了同步NameNode的元数据一致，有专门的JournalNode来同步元数据文件，活跃的NameNode的edits文件会写入journalnode集群，其他standby的结点会去读取journalnode上的edits文件，以此来同步自身的元数据。

1. ZKFC的HealthyMonitor是监控NameNode的进程，是专门监控NameNode将康情况的进程。
2. HealthyMonitor会定时想ZKFC进程报告NameNode情况。
3. 当HealthyMonitor出现汇报了NameNode，ZKFC就会向AcitveStandbyEloctor报告。
4. AcitveStandbyEloctor接到NameNode宕机报告就会通知zk集群选举出新的NameNode。
5. zk集群经过内部选举，返回一个standby的NameNode给AcitveStandbyEloctor。
6. AcitveStandbyEloctor想ZKFC报告选举结果。
7. ZKFC为了防止是网络原因导致NameNode假死，就会结束NameNode进程。
8. zk集群就会通知另一个ZKFC要求它修改它监控的NameNode的进程为活跃节点。

HA技术关键点

HA问题中需要解决的两个问题：

• 元数据一致性：Standby节点和Active节点的元数据一致性。
• 主备自动切换：Active节点服务中断时，Standby节点可以立即启动对外提供服务。

为了确保故障转移可以快速完成，Standby Namenode须要维护最新的Block位置信息，即每一个Block副本存放在集群中的哪些节点上。为了达到这一点，Datanode同时配置主备两个Namenode，并同时发送Block报告和心跳到两台Namenode。

确保任什么时候刻只有一个Namenode处于Active状态很是重要，不然可能出现数据丢失或者数据损坏。当两台Namenode都认为本身的Active Namenode时，会同时尝试写入数据（不会再去检测和同步数据）。为了防止这种脑裂现象，Journal Nodes只容许一个Namenode写入数据，内部经过维护epoch数来控制，从而安全地进行故障转移。

HA其本质上就是要保证主备NN元数据是保持一致的，即保证fsimage和editlog在备NN上也是完整的。元数据的同步很大程度取决于EditLog的同步，而这步骤的关键就是共享文件系统

有两种方式能够进行edit log共享：

1. 使用QJM（Quorum Journal Manager）共享edit log
2. 使用NFS（Network File System）共享edit log（存储在NAS/SAN）

NFS的方式

all name space edits logged to shared storage;Block reports are sent to both name nodes

显然NFS做为主备Namenode的共享存储。这种方案可能会出现脑裂（split-brain），即两个节点都认为本身是主Namenode并尝试向edit log写入数据，这可能会致使数据损坏。经过配置fencin脚原本解决这个问题，fencing脚本用于：

• 将以前的Namenode关机
• 禁止以前的Namenode继续访问共享的edit log文件

使用这种方案，管理员就能够手工触发Namenode切换，而后进行升级维护。但这种方式存在如下问题：

• 只能手动进行故障转移，每次故障都要求管理员采起措施切换。
• NAS/SAN设置部署复杂，容易出错，且NAS自己是单点故障。
• Fencing 很复杂，常常会配置错误。
• 没法解决意外（unplanned）事故，如硬件或者软件故障。oop
  所以须要另外一种方式来处理这些问题：
• 自动故障转移（引入ZooKeeper达到自动化）
• 移除对外界软件硬件的依赖（NAS/SAN）
• 同时解决意外事故及平常维护致使的不可用

Quorum Journal Manager

QJM（Quorum Journal Manager）是Hadoop专门为Namenode共享存储开发的组件，一般是奇数点结点组成。其集群运行一组Journal Node，每一个Journal 节点暴露一个简单的RPC接口，容许Namenode读取和写入数据，数据存放在Journal节点的本地磁盘。当Namenode写入edit log时，NameNode会同时向所有JournalNode并行写文件，当超过半数节点回复确认成功写入以后，edit log就认为是成功写入。

1、 QJM写过程

NameNode 会把 EditLog 同时写到本地和 JournalNode 中。写本地由配置中的参数dfs.namenode.name.dir来控制，写JN由参数dfs.namenode.shared.edits.dir控制，在写EditLog时会由两个不同的输出流来控制日志的写过程，分别是：

• EditLogFileOutputStream（本地输出流）
• QuorumOutputStream（JN输出流）

NameNode在写EditLog时，并不是直接写到磁盘中，为保证高吞吐，NameNode会分别为EditLogFileOutputStream和QuorumOutputStream定义两个同等大小的Buffer，大小大概是512KB，一个写Buffer（buffCurrent），一个同步Buffer（buffReady），这样可以一边写一边同步，所以EditLog是一个异步写过程，同时也是一个批量同步的过程，避免每写一笔就同步一次日志。

这个是怎么实现边写边同步的呢，这中间其实是有一个缓冲区交换的过程，即bufferCurrent和buffReady在达到条件时会触发交换，如bufferCurrent在达到阈值同时bufferReady的数据又同步完时，bufferReady数据会清空，同时会将bufferCurrent指针指向bufferReady以满足继续写，另外会将bufferReady指针指向bufferCurrent以提供继续同步EditLog。

flowchart TD
    A((Client)) --修改--> B(NameNode)
    B-->C(本地 \n EditLogFileOutputStream)
    B-->D(JournalNode \n QuorumOutputStream)
    C-->E(bufferCurrent)
    C-->F(bufferReady)
    D-->H(bufferCurrent)
    D-->I(bufferReady)
    E-->M(本地目录)
    F-->M
    H-->N(JournalNode)
    I-->N

这里有一个问题，既然EditLog是异步写的，怎么保证缓存中的数据不丢呢，其实这里虽然是异步,但实际所有日志都需要通过logSync同步成功后才会给client返回成功码，假设某一时刻NameNode不可用了，其内存中的数据其实是未同步成功的，所以client会认为这部分数据未写成功。

（1）隔离双写

在Active NN每次同步EditLog到JN时，先要保证不会有两个NN同时向JN同步日志。这涉及一个很重要的概念Epoch Numbers，很多分布式系统都会用到。

成为Active结点时，其会被赋予一个EpochNumber，每个EpochNumber是惟一的，不会有相同的EpochNumber出现。EpochNumber有严格顺序保证，每次NN切换后其EpochNumber都会自增1，后面生成的EpochNumber都会大于前面的EpochNumber。QJM是怎么保证上面特性的呢，主要有以下几点：

1. 在对EditLog作任何修改前，QJM(NameNode上)必须被赋予一个EpochNumber；
2. QJM把自己的EpochNumber通过newEpoch(N)的方式发送给所有JN结点；
3. 当JN收到newEpoch请求后，会把QJM的EpochNumber保存到一个lastPromisedEpoch变量中并持久化到本地磁盘；
4. ANN同步日志到JN的任何RPC请求（如logEdits(),startLogSegment()等），都必须包含ANN的EpochNumber；
5. JN在收到RPC请求后，会将之与lastPromisedEpoch对比，如果请求的EpochNumber小于lastPromisedEpoch,将会拒绝同步请求，反之，会接受同步请求并将请求的EpochNumber保存在lastPromisedEpoch；

这样就能保证主备NN发生切换时，就算同时向JN同步日志，也能保证日志不会写乱，因为发生切换后，原ANN的EpochNumber肯定是小于新ANN的EpochNumber，所以原ANN向JN的发起的所有同步请求都会拒绝，实现隔离功能，防止了脑裂。

（2）恢复in-process日志

如果在写过程中写失败了，可能各个JN上的EditLog的长度都不一样，需要在开始写之前将不一致的部分恢复。恢复机制如下：

1. Active NN先向所有JN发送getJournalState请求；
2. JN会向ANN返回一个Epoch（lastPromisedEpoch)；
3. Active NN收到大多数JN的Epoch后，选择最大的一个并加1作为当前新的Epoch，然后向JN发送新的newEpoch请求，把新的Epoch下发给JN；
4. JN收到新的Epoch后，和lastPromisedEpoch对比，若更大则更新到本地并返回给Active NN自己本地一个最新EditLogSegment起始事务Id,若小则返回NN错误；
5. Active NN收到多数JN成功响应后认为Epoch生成成功，开始准备日志恢复；
6. Active NN会选择一个最大的EditLogSegment事务ID作为恢复依据，然后向JN发送prepareRecovery； RPC请求，对应Paxos协议2p阶段的Phase1a，若多数JN响应prepareRecovery成功，则可认为Phase1a阶段成功；
7. Active NN选择进行同步的数据源，向JN发送acceptRecovery RPC请求，并将数据源作为参数传给JN。
8. JN收到acceptRecovery请求后，会从JournalNodeHttpServer下载EditLogSegment并替换到本地保存的EditLogSegment，对应Paxos协议2p阶段的Phase1b，完成后返回Active NN请求成功状态。
9. Active NN收到多数JN的响应成功请求后，向JN发送finalizeLogSegment请求，表示数据恢复完成，这样之后所有JN上的日志就能保持一致。 数据恢复后，Active NN上会将本地处于in-process状态的日志更名为finalized状态的日志，形式如editsstart-txidstop-txid。

（3）日志同步

1. 执行logSync过程，将ANN上的日志数据放到缓存队列中
2. 将缓存中数据同步到JN，JN有相应线程来处理logEdits请求
3. JN收到数据后，先确认EpochNumber是否合法，再验证日志事务ID是否正常，将日志刷到磁盘，返回ANN成功码
4. ANN收到JN成功请求后返回client写成功标识，若失败则抛出异常

通过上面一些步骤，日志能保证成功同步到JN，同时保证JN日志的一致性，进而备NN上同步日志时也能保证数据是完整和一致的。

2、QJM读过程

读过程是面向备NN(Standby NN)的，Standby NN定期检查JournalNode上EditLog的变化，然后将EditLog拉回本地。Standby NN上有一个线程StandbyCheckpointer，会定期将Standby NN上FSImage和EditLog合并，并将合并完的FSImage文件传回主NN（Active NN）上，就是所说的Checkpointing过程。下面我们来看下Checkpointing是怎么进行的。

在2.x版本中，已经将原来的由SecondaryNameNode主导的Checkpointing替换成由Standby NN主导的Checkpointing。

1. 在Standby NN上先检查前置条件，前置条件包括两个方面：距离上次Checkpointing的时间间隔和EditLog中事务条数限制。
2. 前置条件任何一个满足都会触发Checkpointing，然后SNN会将最新的NameSpace数据即SNN内存中当前状态的元数据保存到一个临时的fsimage文件( fsimage.ckpt）
3. 然后比对从JN上拉到的最新EditLog的事务ID，将fsimage.ckpt_中没有，EditLog中有的所有元数据修改记录合并一起并重命名成新的fsimage文件，同时生成一个md5文件。
4. 将最新的fsimage再通过HTTP请求传回ANN。

通过定期合并fsimage有什么好处？

1. 可以避免EditLog越来越大，合并成新fsimage后可以将老的EditLog删除
2. 可以避免主NN（ANN）压力过大，合并是在SNN上进行的
3. 可以保证fsimage保存的是一份最新的元数据，故障恢复时避免数据丢失

三、主备自动切换
Hadoop的主备选举依赖于ZooKeeper。
整个切换过程是由ZKFC来控制的，ZKFC是实现主备切换的组件。每个运行的NameNode上都会有一个ZKFC进程（实际是一个Hadoop进程）。主要的功能如下：

1. 健康检测：ZKFC会使用健康检测命令定期的ping同节点中的NameNode，只要该NameNode及时的回复健康，则任务当前NameNode是健康的；
2. Zookeeper会话管理: 当本地NameNode是健康的，ZKFC会保持一个在Zookeeper中打开的会话。如果本地NameNode处于Active状态，ZKFC会保持一个特殊的znode锁，如果回话中断，锁节点讲自动删除；
3. 基于Zookeeper的选举: 如果本地的NameNode是健康的，且ZKFC发现没有其他的节点持有当前的znode锁，它会为自己获取该锁。如果成功则进行故障切换，并且确保之前的NameNode的进程中断，将本地NameNode切换为Active；

在故障切换期间，ZooKeeper主要是发挥什么作用有以下几点：

1. 失败保护：集群中每一个NameNode都会在ZooKeeper维护一个持久的session，机器一旦挂掉，session就会过期，故障迁移就会触发；
2. Active NameNode选择：ZooKeeper有一个选择ActiveNN的机制，一旦现有的ANN宕机，其他NameNode可以向ZooKeeper申请排他成为下一个Active节点；
3. 防脑裂： ZK本身是强一致和高可用的，可以用它来保证同一时刻只有一个活动节点；

参考链接：
https://blog.csdn.net/weixin_43854618/article/details/108808274

https://blog.csdn.net/shan19920501/article/details/124911283