HDFS HA支持多Standby节点机制

前言

---

在现有的HDFS中，为了保证其高可用性，社区在早些年就已经完成HDFS的HA机制，也就是One Active，One Standby。在此种情况下，HDFS能够容忍其中一个节点出现失败的情况。这套HA机制的实现的确给用户带来了很大的帮助，基于此特性，我们可以做很多集群上的热操作，比如热迁移NameNode，或者滚动升级HDFS等等。可能唯一让人感觉还不是最好的一点是，它不能容忍更多失败的情况，比如2个NameNode都发生失败的情况。在其他的一些分布式系统中，例如Zookeeper，它的内部就可以容忍其中2节点出现崩溃的情况，当它启动了5个节点的时候。在HDFS内部的block副本设计上，也是保证了3副本的设计理念，同样可以容忍2个副本损坏的情况。所以我们不禁开始联想，在HDFS中什么时候也能容忍更多的出错情况？更具体地说，就是在只有一个Active NameNode情况下，同时有多个Standby NameNode。这样的话，HDFS的HA特性看上去就非常的强大了。本文我们就来好好聊聊这个话题。

HDFS多Standby节点机制概述

---

前面的铺垫内容说了这么多，那么到底目前是否已经有多Standby节点的实现机制呢？答案是有的，但是它还没有发布，目标发布版本Hadoop 3.0.又是在3.0版本，之前本人介绍了许多很棒的特性都是在这个版本发布的（比如HDFS EC），大家敬请期待这个版本吧。社区JIRA HDFS-6440(Support more than 2 NameNodes)最终实现了HA中支持多Standby的特性。本文是我阅读完此JIRA上的设计文档以及代码实现后所写的总结性文章，更多设计细节可以查看原文档。

在之前HDFS的HA的设计实现中，其实已经帮我们实现了许多在未来可能有多Standby节点出现的情况。所以在这里，我们只需要在原来One Active，One Standby完善的机制下，做局部的修改，来满足多Standby的情况即可。以下为几个需要修改的点：

• Zkfc的Active选举，此时不是只有另外一个可选节点，而是很多个Standby节点。
• Checkpoint过程以及Active NameNode上的Fsimage同步问题，之前都是一个Standby NameNode定期发给Active NameNode，这个时候有多个Standby，怎么办。
• Bootstrap过程。之前都是向另外一个Active NameNode进行bootstrap，而现在有多个节点。
• Block token id的生成。

主要为以上4点，其中第2点最为重要，因为涉及到元数据的更新同步，逻辑也作为复杂。在下一小节中，我们将会针对这4点做详细的分析。

多Standby节点细节实现

---

此小节将会针对以上提出的4点展开分析，下面首先是zkfc相关的改造。

Zkfc的选举

---

与原先的HA机制相比，多Standby的情况会造成锁竞争的加剧，因为每个Standby节点上的zkfc进程都要尝试获取锁，然后才会将自己的状态切到Active。所以在此建议的Standby数量不宜过多，3~5个足够了。还有当进行手动切换的时候，这个时候要保证其他节点此时不发生切换动作。

Checkpoint元数据同步过程

---

先来回顾一下原先HA机制的元数据同步过程：

Standby节点周期性的读取JournalNode上的editlog，等到了一次checkpoint周期，然后做一次checkpoint，然后将新的fsimage同步到Active节点。

在这个如果是多个Standby节点的情况，这个处理过程就没有那么简单了，下面几个是主要要解决的问题：

• 这么多个Standby节点，每个节点上都有自己的fsimage，该选哪个作为最终上传镜像文件的节点呢？
  答：选择元数据最新的Standby，评判标准是看当前最新的txid。
• 如果Active节点当前已经同步了最新fsimage，而Standby节点又将稍老的fsimage同步过去，怎么办？
  答：Active节点会进行比较，如果的确是老的fsimage，会给出失败的回复应答。

以上两点在后面代码实现的部分会有具体的体现。

Bootstrap过程

---

我们知道bootstrap的用处一般是在集群开始搭建时，将Active上的fsimage等元数据同步到当前的节点上，然后启动当前节点。而在当前多Standby节点的变化是，由向原来另外一个Active获取元数据变为同时向多个其他节点抓取元数据，直到有一个节点能抓取到元数据为止。

Block token id的构造

---

在block token id的生成中，会根据当前NameNode index下标来生成serialNo序列号数字，然后将此数字应用到token id的生成。生成代码如下：

   public synchronized void setSerialNo(int serialNo) {
     this.serialNo = (serialNo & LOW_MASK) | (nnIndex << 31); 
   }

但是原先的处理逻辑，只适用于2个NameNode的情况，也就是下标0和1的情况。在多个Standby出现的情况，NameNode的下标就有可能出现2,3,4等情况。因此此逻辑也需要进行修改。具体改动可见HDFS-6440上的设计文档。

多Standby情况下的Checkpoint同步

---

因为在多Standby情况下的checkpoint,fsmage同步过程最为复杂，此节我们从源代码实现层面来学习一下其中的过程，主要涉及以下2个类的改造：

• StandbyCheckpointer：Standby NameNode上专门控制做checkpoint以及上传fsimage到Active NameNode的服务。
• ImageServlet：NameNode服务请求处理类，里面包含了fsimage上传请求的处理逻辑。

我们首先进入StandbyCheckpointer类，