Ozone OM Upgrade期间请求一致性处理的保证

前言

---

之前笔者讲过一篇关于Ozone Upgrade相关的文章(HDFS数据In-place Upgrade到Ozone的原型方案)，本文笔者继续围绕Ozone Upgrade这个主题，聊聊在Ozone Upgrade时，OM新旧版本之间，它是如何做到元数据的一致性的。倘若是Upgrade后的版本意为地执行了老版本留下的请求，亦或是老版本执行了新版本下发来的请求，这些都不是预期应该发生的情况。Ozone社区对这块的逻辑做了详细的设计。本文我们来聊聊这块的内容。

Ozone OM Upgrade的预期目标

---

在Ozone OM的HA模式下，会存在一个Leader和多个Follower的角色，这里面会涉及到请求的先后执行问题。Follower OM的请求执行会慢于Leader的执行，如果我们此时直接shutdown所有OM服务，然后替换新的Ozone版本，那么大概率会出现OM Follower在新版本模式下执行旧版本时OM同步来的老版本模式下的请求。这其中如果存在新老版本之间的请求处理兼容性问题的话，这种直接停所有OM的方式是存在隐患的。

因此这里我们对于Ozone OM Upgrade的一个核心目标，如下所示：

OM在Upgrade替换新版本运行启动之前，包括Leader/Follower都必须执行完老版本下发来的所有请求。

下面我们来看看，社区对于这块是如何设计的。

Ozone OM Upgrade的元数据一致性控制

---

社区目前设计对这部分的处理是分为两个阶段：

• 阶段1：OM Upgrade Prepare处理，包括对于元数据db transaction的snapshot take等。
• 阶段2：收集所有OM的Upgrade Prepare请求处理结果，然后执行后续对应的action操作。

阶段1：OM Upgrade Prepare处理

---

首先是阶段1，这个阶段用一句话来概括说就是client向所有OM发送OM Upgrade Prepare请求，然后去查询这些OM的执行结果是否成功。

那么问题来了，OM Upgrade Prepare到底会做哪些事情呢，下面是相关的流程图过程：

从上面可以看到，client在向OM发完Upgrade Prepare请求后，OM这边会执行此请求的以下步骤：

1）更新内存里的状态模式为Upgrade Prepare模式
2）新建当前最新的Snapshot并且purge之前执行过的transaction log（这里即Raft log）
3）新建一个附带有txn index信息的标记文件表明此OM已经执行完Upgrade Prepare请求
4）将当前请求的txn index返回到client端。

执行完上述操作后，OM这边的元数据就达到一个比较干净的状态了，首先它执行完了所有的请求，最后一个请求即Upgrade Prepare请求。然后take了一个最新的Snapshot，然后purge掉此Snapshot前的transaction log。然后Follower OM也会执行完同样的操作。

这里有个细节OM在处理完Upgrade Prepare后，预期应该停止RPC服务，以此拒绝接受后续的RPC请求，不过这块在设计文档中还未提及此细节。

OK，当这些都完成好了之后，就会来到第二个阶段的操作。

阶段2：OM Upgrade Prepare action处理

---

在阶段2中，因为client也保证Follower也得成功执行掉Upgrade Prepare请求，它需要有方式能够去查询执行的结果，因此在这里它通过写出了一个标记文件的方式，并且在里面写了transaction index用以后续做比较，此过程图如下：

如果所有的OM检查结果都成功的话，则继续往下upgrade action操作：

• stop OM服务
• 替换新版本的包
• 以upgrade option命令启动OM 服务

如果出现其中个别仍未执行成功的OM，client可以进行下面几种选项：

• 选择1，继续重试Upgrade Prepare请求。
• 选择2，发起cancel Upgrade Prepare请求处理，此请求会清理掉之前创建的标记文件，重置Upgrade Prepare模式。

这部分过程图如下所示：

经过了OM Upgrade Prepare的处理之后，它可以达到我们在上面提到的请求执行一致的控制，从而避免了跨版本请求被处理的情况。

参考资料

---

[1].https://issues.apache.org/jira/browse/HDDS-4470