第 7 章 已知问题

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

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

(BZ#2007376)

故障转移操作报告 pod 上 RADOS 块设备镜像挂载在具有 RPC 错误 fsck 的 pod 上失败

如果出现灾难恢复(DR)受保护的工作负载，则可能会导致 pod 启动掉状态为文件系统一致性检查(fsck)错误的卷挂载错误。这可防止工作负载切换到故障转移集群。

(BZ#2021460)

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

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

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

(BZ#2059669)

对于某些镜像，RBD 镜像调度已停止

Ceph 管理器守护进程会因为不同的原因而获得 blocklist，这会导致在镜像的主集群中触发调度的 RBD 镜像快照。当使用 rbd mirror snapshot schedule status -p ocs-storagecluster-cephblockpool 检查时，镜像启用了 DR 保护的所有 RBD 镜像都不会被列出，因此不会主动镜像到对等站点。

临时解决方案：在镜像为主的受管集群中重启 Ceph 管理器部署，可以针对当前运行的实例克服 blocklist，这可以通过缩减并稍后扩展 ceph 管理器部署来实现：

$ oc -n openshift-storage scale deployments/rook-ceph-mgr-a  --replicas=0
$ oc -n openshift-storage scale deployments/rook-ceph-mgr-a  --replicas=1

结果：在使用 rbd mirror snapshot schedule status -p ocs-storagecluster-cephblockpool 检查时，受管集群上启用 DR 的镜像开始报告镜像调度

(BZ#2067095)

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

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

(BZ#2100920)

Ceph 无法识别 Globalnet 分配的全局 IP

Ceph 不识别 Globalnet 分配的全局 IP，因此无法使用 Globalnet 在带有重叠服务 CIDR 的集群间配置灾难恢复解决方案。由于当服务 CIDR 重叠时，这个灾难恢复解决方案无法正常工作。

(BZ#2102397)

这两个 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)

当一个区出现问题时，应用程序会处于 FailingOver 状态

在故障转移或重新定位时，如果没有 s3 存储，则故障转移或重新定位进程挂起。如果 DR 日志指出 S3 存储无法访问，那么故障排除并获取 s3 存储操作将使得 DR 能够继续故障转移或重新定位操作。

(BZ#2121680)

当工作负载通过或重新定位到对等集群时，PeerReady 状态被设置为 true，直到从中清理或重新定位的集群为止

启动灾难恢复 (DR) 操作后，当工作负载故障转移或重新定位到对等集群时，PeerReady 条件会在持续时间内最初设置为 true。当它被设置为 false 后，直到从中清理或重新定位的集群才会从其中清理或重新定位到将来的操作。查看 DRPlacementControl 状态条件的用户，用于将来的操作可能会将这个中间 PeerReady 状态识别为对等状态，以进行操作并执行。这将导致操作等待或失败，并可能需要用户干预才能从中恢复。

临时解决方案：在执行任何操作前检查 Available 和 PeerReady 状态。对于工作负载的健康的 DR 状态，两者都为 true。当两个状态都为 true 时执行的操作将导致请求的操作进度

(BZ#2138855)

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

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

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

(BZ#2159791)

阻塞列表可能会导致 Pod 处于错误状态

防止网络问题或大量过载或具有大量尾部延迟激增的集群阻止列表。因此，Pods 会停留在 CreateContainerError，并带有信息 Error: relabel failed /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7610bb613/mount: lsetxattr /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7610bb613/mount/#ib_16384_0.dblwr: read-only file system。

临时解决方案：重新引导将这些 pod 被调度到的节点，并参照以下步骤：

(BZ#2094320)