5.8. 恢复 OpenShift Data Foundation 扩展集群

在本小节中，区失败代表区中的所有 OpenShift Container Platform、master 和 worker 节点不再与第二个数据区中的资源通信（例如，关闭节点）。如果数据区域之间的通信仍处于部分工作状态（不正常启动或关闭），集群、存储和网络管理员应断开数据区域之间的通信路径，以便成功恢复。

使用 topologyKey: topology.kubernetes.io/zone 部署的应用程序在每个数据区中调度了一个或多个副本，并使用共享存储，即 ReadWriteMany (RWX) CephFS 卷，在几分钟后终止自身，并处于待处理状态并处于待处理状态。

此类型的应用程序示例在 Install Zone Aware Sample Application 部分中进行了详细介绍。

使用 topologyKey: kubernetes.io/hostname 或没有拓扑配置的应用程序对同一区域中的所有应用副本没有保护。

如果发生这种情况，且所有副本都位于失败的区域中，则使用 ReadWriteMany (RWX)存储的应用程序需要 6-8 分钟在活跃区域中恢复。此暂停时间用于故障区域中的 OpenShift Container Platform 节点变为 NotReady (60 秒)，然后让默认 pod 驱除超时过期(300 秒)。

使用 ReadWriteOnce (RWO)存储的应用程序具有在此 Kubernetes 问题 中描述的已知行为。由于这个问题，如果数据区失败，挂载 RWO 卷（例如，基于 cephrbd 的卷）的区中的任何应用程序 pod 在 6-8 分钟后会一直处于 Terminating 状态，在没有手动干预的情况下不会在活动区域中重新创建。

检查 OpenShift Container Platform 节点，其状态为 NotReady。可能会出现阻止节点与 OpenShift 控制平面通信的问题。但是，节点可能仍然是针对持久性卷(PV)执行 I/O 操作。

如果两个 pod 同时写入同一 RWO 卷，则存在数据崩溃的风险。确保 NotReady 节点上的进程被终止或阻止，直到它们终止为止。

解决方案示例：

要让 Terminating pod 在活跃区中重新创建，您可以强制删除 pod 或删除关联的 PV 上的终结器。完成这两个操作之一后，应用程序 Pod 应在活跃区域中重新创建，并成功挂载其 RWO 存储。

作为 StatefulSet 一部分的 Pod 的问题与 pod 挂载 ReadWriteOnce (RWO)卷类似。Kubernetes 资源 StatefulSet 注意事项 中会引用更多信息。

要让 StatefulSet 的 pod 部分在 6-8 分钟后在活跃区中重新创建，您需要强制删除与带有 RWO 卷的 pod 相同的要求（即，关闭或断开连接通信）的 pod。