Ozone Upgrade模型框架分析

前言

---

最近Ozone社区刚刚发布了Ozone 1.1版本，这也是Ozone发布GA版本以来的第二个版本release了。当越来越多Ozone版本release后，这里就会有个版本升级的问题。可能有同学会好奇：目前Ozone支持版本Upgrade功能吗？据社区目前的进展，这个功能第一阶段实现已经基本完成，预计会在Ozone 1.2版本中和大家见面。在Ozone第一阶段Upgrade功能的实现里，一个基本的Upgrade框架模型基本成型，不过目前是non-rolling upgrade的升级，是需要集群downtime升级的。本文就简单和大家聊聊Ozone Upgrade的一个整体实现思路，比之前笔者写过的Ozone Upgrade文章会更加详细一些。

Ozone Upgrade相关要素关系

---

首先我们要清楚涉及到一次完整的Ozone Upgrade升级，这里面会牵扯到哪些要素。

如果论Upgrade的状态来说，这里会有Upgrade不同阶段的不同状态，比如before Upgrade， finalize upgrade和finalized阶段。

说服务的话，毫无疑问OM, SCM和Datanode服务当然是首当其冲的服务，这是第一层我们直接能够联想到的东西。

那么再往下深入一层呢，还有什么？这里我们要提到的东西有版本，version的概念。

然后在一个version里，还会有2个与其紧密相关的要素：1）每个version对应的可用的feature。2）每个version对应的layout，layout可理解为数据的一种分布方式。

然后我们再来看feature这个概念，这里就不得不提feature compatible的问题了。新老feature的compatible问题绝对也是Upgrade过程需要特别关注的。

综合上面提及到的种种要素，我们大体可以得出下面的一个Ozone Upgrade关系要素图(下图中还未提及到的概念在下文中会再进行具体阐述)。

Ozone Upgrade的执行器模型

---

分析完Ozone Uggrade相关要素后，我们再具体了解Ozone Upgrade的整个执行过程。

一个复杂集群的升级并不是一个简单的Upgrade命令的事情，往往里面还会涉及到Upgrade前后需要依赖执行的各种操作。Ozone在这边对整个Upgrade的动作进行了如下步骤的拆分执行，

...
  public void execute(T component, BasicUpgradeFinalizer finalizer)
      throws IOException {
   
    try {
   
      finalizer.emitStartingMsg();
      finalizer.getVersionManager()
          .setUpgradeState(FINALIZATION_IN_PROGRESS);
      // 升级前需要完成的步骤
      finalizer.preFinalizeUpgrade(component);
      // 升级时需要做的事情
      finalizer.finalizeUpgrade(component);
      // 升级后需要做的操作
      finalizer.postFinalizeUpgrade(component);

      finalizer.emitFinishedMsg();
    } catch (Exception e) {
   
      LOG.warn("Upgrade Finalization failed with following Exception. ", e);
      if (finalizer.getVersionManager().needsFinalization()) {
   
        finalizer.getVersionManager()
            .setUpgradeState(FINALIZATION_REQUIRED);
        throw (e);