HDFS Multiple Standby的优化实践

前言

---

在前面的文章中，笔者介绍过一篇关于介绍HDFS Multiple Standby功能的原理文章（HDFS Multiple Standby原理分析）。从代码改动来看，HDFS Multiple Standby并没有对NameNode的核心机制做大的改动，而是进行了多Standby模式的一个适配。关于Multiple Standby这个功能本身，它确实能够增强NameNode服务的整体可靠性。假设我们使用普通性能的机器部署NameNode这样的核心服务时，这种对于服务的可靠性要求就很关键了，在这种情况下Multiple Standby无疑将会发挥很大的作用。从再长远的角度来看，我们甚至能够利用多Standby NN来提供对外的读请求服务，以此来减少主NN的压力。总的来讲， Multiple Standby这个功能还是有着恨着很高的使用价值，本文笔者来简单聊聊我们内部在这段时间对这个功能进行的一些实践分享，包括这个功能本身还存在的一些问题点。

Multiple Standby的checkpoint行为影响

---

之前文章也介绍过Multiple Standby相较于原先HA主备模式最大的一个区别是它内部的checkpoint行为的改动。在Multiple Standby下会有多个Standby NN能够同时向Active NN进行fsimage的传送。尽管Multiple Standby功能实现里通过新增checkpoint quiet的时间判断优化fsimage upload行为，但是为了避免依然潜在的频繁fsimage上传行为，我们内部对相关的checkpoint参数进行了调整。

目前Standby NN中控制checkpoint行为的影响条件有下面2个：

boolean needCheckpoint = lastCheckpointTime >= checkpoint period || uncheckpointed txn >= txn count

通常我们知道的是checkpoint的时间，往往忽略的是这里transaction的控制。尤其当集群RPC压力很大的时候，第二个条件往往会优先成为触发checkpoint的行为。在NN里会有下面的log表示checkpoint行为由transaction所触发。

org.apache.hadoop.hdfs.server.namenode.ha.StandbyCheckpointer: Triggering checkpoint because there have been 15431844 txns since the last checkpoint, which exceeds the configured threshold 15000000

我们内部按照Multiple Standby中Standby NN的数量，进行checkpoint时间和transaction数阈值的等倍放大,以此保证在Multiple Standby模式下，Standby NN向Active NN上传FSImage的频率基本保持不变。
相关配置如下：

<property>
<name>dfs.namenode.checkpoint.txns</name>
<value>xxx</value>
</property>

<property>
<name>dfs.namenode.checkpoint.period</name>
<value>xxx</value>
</property>

另外一个与checkpoint密切相关的行为是Active NN的log roll行为。我们知道，Active NN上的log roll行为是Standby NN定期所触发的。在Multiple Standby NN情况下，多个Standby NN会同时向Active NN发起log roll的命令ÿ