HDFS Decommission改进设计

前言

---

在大型HDFS集群中，每天个别节点由于硬件问题导致掉线是常用发生的事情。因此很多时候，我们会对集群中的故障节点做下线操作，就是我们常说的Decommission操作。简单地来说，DataNode节点的Decommission操作在大规模体量的集群下是日常维护行为。因此Decommission行为会涉及到上面数据拷贝的情况，因此下线操作效率的好坏在一定程度上也会影响到集群的处理性能。现有HDFS Decommission方式从某些角度来看并不是高效的，本文笔者来聊聊社区目前在实现的另外一套Decommission的实现方式。

现有Decommission机制以及不足之处

---

这里首先我们需要有对现有Decommission机制有一个大致地了解，现有Decommission的流程可简单概括为如下：

• 将目标下线节点加入到下线列表中
• Decommission Monitor程序逐一处理待下线节点，将待下线节点中的块加入到副本队列内
• 另外Decommission Monitor程序还将检查待下线节点内的block副本数是否都已经达到预期大小，如果达到则标志节点下线成功，否则继续等待节点下线。

在以上3个步骤内，笔者省略了许多的细节实现描述，其中部分细节实现存在以下的问题：

• 每次新加节点进行decommission时，Monitor程序会持有较长时间的锁去处理下线节点中的所有的块。当目标下线节点中含有大量block块时，就有可能出现持NN锁时间过长的问题。
• HDFS副本队列replication queue在处理块时的方式是FIFO方式的。而下线节点在添加副本块时的顺序是按照一个接单一个个disk来添加的。这意味着会