恢复 Metro-DR 扩展集群

Red Hat OpenShift Data Foundation 4.9

有关如何在发生地区灾难时如何从 Red Hat OpenShift Data Foundation 中恢复应用程序及其存储的说明。

摘要

本文档解释了如何在发生灾难时从 Red Hat OpenShift Data Foundation 中恢复。
重要
Recovering a Metro-DR stretch cluster is a technology preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

前言

鉴于具有区域灾难恢复功能的集群是在一个区域出现完全或部分中断的情况下提供弹性，因此了解应用程序及其存储的不同恢复方法非常重要。

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

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

第 1 章 了解区失败

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

第 2 章 恢复使用 RWX 存储的区域感知 HA 应用程序

使用 topologyKey: topology.kubernetes.io/zone 部署、在每个数据区域中有一个或多个副本并且使用共享存储的应用（即 ReadWriteMany(RWX)CephFS 卷），可在 30-60 秒内恢复用于新连接。当路由器 Pod 现在在失败的数据区中离线时，短暂暂停用于 HAProxy 刷新连接。

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

重要

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

第 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 秒）。

第 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>
<PODNAME>
是 pod 的名称
<NAMESPACE>
是项目的命名空间
删除关联的 PV 上的终结器

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

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

是 PV 的名称

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

$ oc describe pod <PODNAME> --namespace <NAMESPACE>
<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

第 5 章 StatefulSet pod 的恢复

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

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