第 7 章 已知问题

故障转移操作报告 pod 上的 RADOS 块设备镜像挂载在仍然在使用中的 RPC 错误时失败

在灾难恢复(DR)受保护的工作负载时，可能会导致在故障转移集群中使用卷处于卡住的 pod，报告 RADOS 块设备(RBD)镜像仍在使用。这可防止 pod 在很长时间内启动（最多几个小时）。

(BZ#2007376)

为受管集群创建应用程序命名空间

应用程序命名空间需要存在于 RHACM 受管集群中，用于灾难恢复 (DR) 相关的预部署操作，因此当应用程序部署在 RHACM hub 集群中时预先创建。但是，如果在 hub 集群中删除某个应用程序，并且在受管集群中删除对应的命名空间，则会在受管集群上重新应用。

临时解决方案： openshift-dr 在 RHACM hub 的受管集群命名空间中维护一个命名空间 manifestwork 资源。需要在应用程序删除后删除这些资源。例如，作为集群管理员，在 hub 集群上执行以下命令： oc delete manifestwork -n <managedCluster namespace> <drPlacementControl name>-<namespace>-ns-mw。

(BZ#2059669)

当集群处于扩展模式时，Ceph df 会报告一个无效的 AVAIL 值

当 Red Hat Ceph Storage 集群的 crush 规则具有多个"take"步骤时，ceph df 报告显示该映射的最大可用大小。这个问题将在即将推出的版本中解决。

(BZ#2100920)

这两个 DRPC 都保护在同一命名空间中创建的所有持久性卷声明

托管多个灾难恢复(DR)保护工作负载的命名空间，保护 hub 集群上每个 DRPlacementControl 资源的命名空间，该命名空间不根据 spec.pvcSelector 字段在工作负载上指定并隔离 PVC。

这会生成 PVC，它与多个工作负载的 DRPlacementControl spec.pvcSelector 匹配。或者，如果所有工作负载都缺少选择器，复制管理可能会多次管理每个 PVC，并根据单独的 DRPlacementControl 操作造成数据崩溃或无效操作。

临时解决方案：标签 PVC 属于唯一工作负载，并使用所选标签作为 DRPlacementControl spec.pvcSelector，以忽略哪个 DRPlacementControl 保护和管理命名空间中的哪些 PVC 子集。无法使用用户界面为 DRPlacementControl 指定 spec.pvcSelector 字段，因此必须使用命令行删除并创建此类应用程序的 DRPlacementControl。

结果： PVC 不再由多个 DRPlacementControl 资源管理，不会造成任何操作和数据不一致。

(BZ#2111163)

MongoDB pod 处于 CrashLoopBackoff，因为的权限错误读取 cephrbd 卷中的数据

跨不同受管集群的 OpenShift 项目具有不同的安全性上下文约束 (SCC)，这在指定的 UID 范围和/或 FSGroups 中有所不同。这会导致某些工作负载 pod 和容器无法在这些项目中启动后故障转移或重新定位操作，因为日志中的文件系统访问错误。

临时解决方案：确保在所有带有同一项目级别的 SCC 标签的受管集群中创建工作负载项目，以便在通过或重新定位失败时使用相同的文件系统上下文。Pod 不再对文件系统相关的访问错误失败失败。

(BZ#2114573)

应用程序在重新定位过程中处于 Relocating 状态

Multicloud Object Gateway 允许将相同名称或命名空间的多个持久性卷 (PV) 对象添加到同一路径的 S3 存储中。因此，Ramen 不会恢复 PV，因为它检测到指向同一 claimRef 的多个版本。

临时解决方案：使用 S3 CLI 或等同于从 S3 存储清理重复的 PV 对象。仅保持接近故障转移或重新定位时间的时间戳的那一个。

结果：恢复操作将继续完成，故障切换或重新定位操作会继续下一步。

(BZ#2120201)

灾难恢复工作负载在删除时会卡住

当从集群中删除工作负载时，对应的 pod 可能无法与 FailedKillPod 等事件终止。这可能会导致垃圾收集依赖的 DR 资源（如 PVC、VolumeReplication 和 VolumeReplicationGroup）的延迟或失败。它还可防止以后将相同的工作负载部署到集群中，因为过时的资源还没有垃圾回收。

临时解决方案：重启正在运行 pod 的 worker 节点，并处于终止状态。这会导致 pod 终止以及随后相关的 DR API 资源被收集垃圾回收。

(BZ#2159791)

当受管集群位于不同版本的 OpenShift Container Platform 和 OpenShift Data Foundation 时，应用程序故障切换会处于 FailingOver 状态

使用 OpenShift Data Foundation 4.14 的灾难恢复解决方案除了持久性卷(PV)数据外，还保护并恢复持久性卷声明(PVC)数据。如果主集群位于旧的 OpenShift Data Foundation 版本，并且目标集群更新至 4.14，则故障转移将卡住，因为 S3 存储不会具有 PVC 数据。

临时解决方案：在升级灾难恢复集群时，必须首先升级主集群，然后必须运行升级后的步骤。

(BZ#2214306)

当 DRPolicy 应用到同一命名空间中的多个应用程序时，不会创建卷复制组

当为与命名空间中的其他应用程序在一起的应用程序创建 DRPlacementControl (DRPC)时，DRPC 没有为应用设置标签选择器。如果对标签选择器进行任何更改，OpenShift Data Foundation Hub 控制器中的验证准入 Webhook 会拒绝更改。

临时解决方案：更改准入 Webhook 以允许此类更改，DRPC validatingwebhookconfigurations 可以修补以删除 Webhook。

$ oc patch validatingwebhookconfigurations vdrplacementcontrol.kb.io-lq2kz --type=json --patch='[{"op": "remove", "path": "/webhooks"}]'

(BZ#2210762)

在 FailingOver 中将应用程序从 c1 故障转移到 c2 集群挂起。

当因为 s3 存储错误配置导致数据没有上传到 s3 存储错误配置时，Ramen 不会禁用故障转移操作。这意味着故障转移过程中在故障转移集群中无法使用集群数据。因此，无法完成故障转移。

临时解决方案：在初始部署后检查日志以确保没有报告 s3 配置错误。

$ oc get drpc -o yaml

(BZ#2248723)

hub 恢复后数据丢失的潜在风险

因为旨在清理孤立资源而在 hub 恢复后存在潜在的数据丢失风险。这会识别并标识对于集合缺少对应 ManifestWorks 的 AppliedManifestWorks 实例。提供了 1 小时的硬编码宽限期。在这个周期过后，与 AppliedManifestWork 关联的任何资源都会受到垃圾回收的影响。

如果 hub 集群无法在初始一小时窗口中重新生成对应的 ManifestWorks，则可能会出现数据丢失。这重点介绍了及时解决可能防止在 ManifestWorks 后恢复 后重新创建的问题的重要性，以最大程度降低数据丢失的风险。

(BZ-2252933)