Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

5.8. 恢复 OpenShift Data Foundation 扩展集群

鉴于具有扩展集群灾难恢复解决方案是为环境出现完全或部分故障时为环境提供抗压性，因此了解应用程序及其存储的不同恢复方法非常重要。

应用程序的机构决定了它在一个活动区域中再次可用的速度。

当区域出现问题时，有不同的方法来恢复应用及其存储。恢复时间取决于应用程序的架构。不同的恢复方法如下：

5.8.1. 了解区失败
复制链接

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

重要

安装示例应用程序时，请关闭 OpenShift Container Platform 节点（至少使用 OpenShift Data Foundation 设备的节点），以测试数据区的故障，以验证您的 file-uploader 应用程序是否可用，您可以上传新文件。

使用 topologyKey: topology.kubernetes.io/zone 部署的应用程序，在每个数据区中调度一个或多个副本，并使用共享存储，即 ReadWriteMany (RWX) CephFS 卷，在几分钟后，在几分钟后，新 pod 会被推出部署并处于待处理状态，直到区域恢复为止。

此类型的应用示例在 Install Zone Aware Sample Application 部分中进行了详细说明。

重要

在区域恢复期间，如果应用容器集在挂载 CephFS 卷时进入 CrashLoopBackOff (CLBO) 状态，然后重启调度 Pod 的节点。等待一段时间，然后检查 pod 是否再次运行。

5.8.3. 恢复具有 RWX 存储的 HA 应用程序
复制链接

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

注意

即使 Pod spec 中有 podAntiAffinity 和 topologyKey: kubernetes.io/hostname 也会发生，因为此反关联性规则基于主机且不是基于区域的规则。

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

5.8.4. 使用 RWO 存储恢复应用程序
复制链接

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

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

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

解决方案示例：

  • 使用带外管理系统在确认的情况下关闭节点，以确保进程终止。

  • 撤回节点在故障站点使用的网络路由与存储通信。

    注意

    在将服务恢复到失败的区域或节点前，请确认所有带有 PV 的 pod 已被成功终止。

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

强制删除 pod

强制删除不会等待来自 kubelet 的确认，但不会等待 pod 已终止。 

$ oc delete pod <PODNAME> --grace-period=0 --force --namespace <NAMESPACE>
Copy to Clipboard Toggle word wrap
<PODNAME>
是 pod 的名称
<NAMESPACE>
是项目的命名空间
删除关联的 PV 上的终结器

找到由 Terminating pod 挂载的持久性卷声明(PVC)关联的 PV，并使用 oc patch 命令删除终结器。 

$ oc patch -n openshift-storage pv/<PV_NAME> -p '{"metadata":{"finalizers":[]}}' --type=merge
Copy to Clipboard Toggle word wrap
<PV_NAME>

是 PV 的名称

查找关联的 PV 的一种简单方法是描述 Terminating pod。如果您看到多附件警告，在警告中应具有 PV 名称（例如： pvc-0595a8d2-683f-443b-aee0-6e547f5f5a7c）。 

$ oc describe pod <PODNAME> --namespace <NAMESPACE>
Copy to Clipboard Toggle word wrap
<PODNAME>
是 pod 的名称
<NAMESPACE>

是项目的命名空间

输出示例： 

[...]
Events:
  Type     Reason                  Age   From                     Message
  ----     ------                  ----  ----                     -------
  Normal   Scheduled               4m5s  default-scheduler        Successfully assigned openshift-storage/noobaa-db-pg-0 to perf1-mz8bt-worker-d2hdm
  Warning  FailedAttachVolume      4m5s  attachdetach-controller  Multi-Attach error for volume "pvc-0595a8d2-683f-443b-aee0-6e547f5f5a7c" Volume is already exclusively attached to one node and can't be attached to another
Copy to Clipboard Toggle word wrap

5.8.5. StatefulSet pod 的恢复
复制链接

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

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

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat