Ozone Decommission原理过程

前言

---

在大规模的分布式集群节点中，出现机器损坏的现象是十分常见的。但为了保证数据的高可用性，系统在设计上往往采用多副本的形式来达到冗余的效果。对于那些“损坏”了的机器，正常的逻辑是走正常下线过程，即decommission流程。Decommission最为核心的一点是，它要保证节点内的数据完好无恙的复制到其它健康的节点上，然后最后将此节点标记为Decommissioned状态，随后就可以从集群中移除了。Decommission过程能够减小因为坏节点下线对于集群产生的不利影响。在我们所熟知的HDFS里面，就有相当完整的Decommission过程以及命令使用方式。本文笔者不聊HDFS的Decommission，而是聊聊新一代对象存储系统Ozone的Decommission原理过程。尽管Ozone在底层数据存储原理上与HDFS差异较大，但是在Decommission部分逻辑上还是有许多共通之处的，笔者会在下文中具体阐述其中的一些区别点。

Ozone Decommission原理过程

---

Ozone Decommission过程用更为具体清晰的解释：Ozone基于Container的Decommission过程。Ozone在数据replication是在Datanode的Container level来做的，那么Decommission过程也就自然同样是根据Container来做的。

在Ozone Decommission的整个过程里，它需要保证以下3点核心要求：

1. Datanode Decommission过程中, 其节点上的数据不能被允许再写，读还是可以的。
2. Datanode Decommission过程意外中断，下次可再次进行Decommission恢复继续。
3. Datanode