第 7 章 已知问题
本节介绍了 Red Hat OpenShift Data Foundation 4.15 中已知的问题。
7.1. 灾难恢复
为受管集群创建应用程序命名空间
应用程序命名空间需要存在于 RHACM 受管集群中，用于灾难恢复 (DR) 相关的预部署操作，因此当应用程序部署在 RHACM hub 集群中时预先创建。但是，如果在 hub 集群中删除某个应用程序，并且在受管集群中删除对应的命名空间，则会在受管集群上重新应用。
临时解决方案：
openshift-dr在 RHACM hub 的受管集群命名空间中维护一个命名空间manifestwork资源。需要在应用程序删除后删除这些资源。例如，作为集群管理员，在 hub 集群中执行以下命令：$ oc delete manifestwork -n <managedCluster namespace> <drPlacementControl name>-<namespace>-ns-mw
当集群处于扩展模式时，Ceph
df会报告一个无效的 AVAIL 值当 Red Hat Ceph Storage 集群的 crush 规则具有多个"take"步骤时，
ceph df报告显示该映射的最大可用大小。这个问题将在即将推出的版本中解决。
这两个 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 资源管理，不会造成任何操作和数据不一致。
MongoDB pod 处于
CrashLoopBackoff，因为的权限错误读取cephrbd卷中的数据跨不同受管集群的 OpenShift 项目具有不同的安全性上下文约束 (SCC)，这在指定的 UID 范围和/或
FSGroups中有所不同。这会导致某些工作负载 pod 和容器无法在这些项目中启动后故障转移或重新定位操作，因为日志中的文件系统访问错误。临时解决方案：确保在所有带有同一项目级别的 SCC 标签的受管集群中创建工作负载项目，以便在通过或重新定位失败时使用相同的文件系统上下文。Pod 不再对文件系统相关的访问错误失败失败。
灾难恢复工作负载在删除时会卡住
当从集群中删除工作负载时，对应的 pod 可能无法与
FailedKillPod等事件终止。这可能会导致垃圾收集依赖的 DR 资源（如PVC、VolumeReplication和VolumeReplicationGroup）的延迟或失败。它还可防止以后将相同的工作负载部署到集群中，因为过时的资源还没有垃圾回收。临时解决方案：重启正在运行 pod 的 worker 节点，并处于终止状态。这会导致 pod 终止以及随后相关的 DR API 资源被收集垃圾回收。
当 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"}]'
当受管集群位于不同版本的 OpenShift Container Platform 和 OpenShift Data Foundation 时，应用程序故障切换会处于
FailingOver状态OpenShift Data Foundation 的灾难恢复解决方案除了持久性卷(PV)数据外，还保护并恢复持久性卷声明(PVC)数据。如果主集群位于旧的 OpenShift Data Foundation 版本，并且目标集群更新至 4.15，则故障转移将卡住，因为 S3 存储不会具有 PVC 数据。
临时解决方案：在升级灾难恢复集群时，必须首先升级主集群，然后必须运行升级后的步骤。
在 FailingOver 中将应用程序从 c1 故障转移到 c2 集群挂起。
当因为 s3 存储错误配置导致数据没有上传到 s3 存储时，Ramen 不会禁用故障转移操作。这意味着故障转移过程中在故障切换集群中无法使用集群数据。因此，无法完成故障转移。
临时解决方案：在初始部署后指定 Ramen 日志，以确保没有报告 s3 配置错误。
$ oc get drpc -o yaml
hub 恢复后数据丢失的潜在风险
因为旨在清理孤立资源而在 hub 恢复后存在潜在的数据丢失风险。这会识别并标识对于集合缺少对应
ManifestWorks的AppliedManifestWorks实例。提供了 1 小时的硬编码宽限期。在这个周期过后，与AppliedManifestWork关联的任何资源都会受到垃圾回收的影响。如果 hub 集群无法在初始一小时窗口中重新生成对应的
ManifestWorks，则可能会出现数据丢失。这重点介绍了及时解决可能防止在ManifestWorks后恢复 后重新创建的问题的重要性，以最大程度降低数据丢失的风险。
基于区域 DR Cephfs 的应用程序故障切换显示有关订阅的警告
应用程序故障转移或重新定位后，hub 订阅会显示错误，表示 "Some 资源无法部署。使用 View status YAML 链接来查看详情"。这是因为，使用 CephFS 作为后备存储置备程序的应用程序持久性卷声明(PVC)作为后备存储置备程序，使用 Red Hat Advanced Cluster Management for Kubernetes (RHACM)订阅部署，并且 DR 保护由对应的 DR 控制器所有。
临时解决方案：没有临时解决方案来重新显示订阅状态中的错误。但是，可以检查无法部署的订阅资源，以确保它们是 PVC。这样可确保其他资源没有问题。如果订阅中没有部署的唯一资源是 DR 保护的资源，则忽略这个错误。
禁用
PeerReady标志可防止将操作改为 FailoverDR 控制器根据需要执行完整的协调。当集群无法访问时，DR 控制器会执行健全性检查。如果工作负载已经重新定位，则此健全检查会导致禁用与工作负载关联的
PeerReady标志，并且因为集群离线而不会完成完整性检查。因此，禁用的PeerReady标志可防止您将操作改为 Failover。临时解决方案：尽管禁用了
PeerReady标志，使用命令行界面将 DR 操作更改为 Failover。
当连接在扩展集群的两个数据中心之间丢失时，Ceph 变得不可访问，IO 会暂停。
当两个数据中心相互丢失但仍然连接到 Arbiter 节点时，选举逻辑中有一个缺陷，这会导致监视器之间的无限选举。因此，监控器无法选举领导机，Ceph 集群变得不可用。另外，IO 会在连接丢失期间暂停。
临时解决方案：在 monitor 之外的一个数据中心中关闭 monitor （您可以通过运行 ceph -s 命令）并重置剩余的 monitor 的连接分数。
因此，监控器可以组成一个仲裁，Ceph 可以再次可用，IOs 可以恢复。
在故障转移后恢复旧的主受管集群后，对 ApplicationSet 工作负载的清理和数据同步会卡住
当 hub 集群失败时，基于 ApplicationSet 的工作负载部署到受管集群不会收集垃圾回收。它被恢复到一个备用的 hub 集群，而工作负载已切换到存活的受管集群。工作负载从中失败的集群，重新加入新的恢复的待机 hub。
受灾难恢复(DR)保护且区域 DRPolicy 开始触发
VolumeSynchronizationDelay警报的 ApplicationSets。另外，这种 DR 保护的工作负载无法切换到对等集群，或重新定位到对等集群，因为数据在两个集群之间没有同步。有关临时解决方案，请参阅为 OpenShift Workloads 配置 OpenShift Data Foundation 灾难恢复 中的 Regional-DR 的故障排除部分。
