第 8 章 已知问题

节点崩溃会导致 kubelet 服务失败，从而导致 Data Foundation 处于错误状态

OpenShift 集群中的意外节点崩溃可能会导致节点处于 NotReady 状态，并影响存储集群。

临时解决方案：

获取待处理的 CSR：

oc get csr | grep Pending

oc get csr | grep Pending

批准待处理的 CSR：

Approve the pending CSR

Approve the pending CSR

(DFBUGS-3636)

当对应节点停机时，CIDR 范围不会保留在 csiaddonsnode 对象中

当节点停机时，无类别域间路由(CIDR)信息会从 csiaddonsnode 对象中消失。当需要隔离隔离节点时，这会影响隔离机制。

临时解决方案：在创建 NetworkFenceClass 对象后立即收集 CIDR 信息。

(DFBUGS-2948)

节点替换后，新的 mon pod 无法调度

在节点替换后，新的 mon pod 无法在新添加的节点中调度自己。因此，mon pod 处于 Pending 状态，这会影响 storagecluster 状态，并带有 mon 不可用。

临时解决方案：使用正确的 nodeSelector 手动更新新的 mon 部署。

(DFBUGS-2918)

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

当 Red Hat Ceph Storage 集群中的 CRUSH 规则具有多个步骤时，ceph df 报告显示关联池的最大可用大小。

(DFBUGS-1748)

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

托管多个灾难恢复(DR)保护工作负载的命名空间保护 hub 集群上每个 DRPlacementControl 资源的所有持久性卷声明(PVC)，它们不会根据其 spec.pvcSelector 字段根据工作负载指定和隔离 PVC。

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

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

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

(DFBUGS-1749)

禁用 PeerReady 标志可防止将操作改为 Failover

DR 控制器根据需要执行完全协调。当集群无法访问时，DR 控制器会执行完整性检查。如果工作负载已重新定位，则此 sanity 检查会导致与工作负载关联的 PeerReady 标志被禁用，因为集群离线，sanity 检查不会完成。因此，禁用 PeerReady 标志可防止您将操作改为 Failover。

临时解决方案：即使禁用了 PeerReady 标志，使用命令行界面将 DR 操作改为 Failover。

(DFBUGS-665)

当连接在扩展集群的两个数据中心之间丢失连接时，Ceph 变得无法访问，并且 IO 暂停

当两个数据中心相互丢失但仍然连接到 Arbiter 节点时，在选择逻辑中存在一个会导致 Ceph 监控器中无限选举的漏洞。因此，监控器无法选举领导，Ceph 集群将不可用。另外，IO 在连接丢失过程中暂停。

临时解决方案：通过关闭区节点来关闭任何一个数据区的监控器。另外，您可以重置存活 monitor pod 的连接分数。

因此，监控器可以形成仲裁，Ceph 会再次可用，IOs 会恢复。

(DFBUGS-425)

在从替换集群中使用过时的 Ceph 池 ID 时，RBD 应用无法分配

对于在创建新对等集群之前创建的应用，无法挂载 RBD PVC，因为当替换对等集群时，无法更新 CSI configmap 中的 CephBlockPoolID 的映射。

临时解决方案：在未替换的对等集群中，将 rook-ceph-csi-mapping-config configmap 更新为 cephBlockPoolID 的映射。这将启用为应用挂载 RBD PVC。

(DFBUGS-527)

有关 lastGroupSyncTime 的信息会在 hub 恢复后丢失，这些工作负载在不可用受管集群上是主的

以前失败的应用程序不会报告 lastGroupSyncTime，从而导致警报 VolumeSynchronizationDelay 触发。这是因为当 ACM hub 和作为 DRPolicy 一部分的受管集群不可用时，从备份中重建新的 ACM hub 集群。

临时解决方案：如果工作负载失败的受管集群不可用，您仍可以切换到一个存活的受管集群。

(DFBUGS-376)

MCO operator 协调 veleroNamespaceSecretKeyRef 和 CACertificates 字段

当 OpenShift Data Foundation Operator 升级时，Ramen 配置中的 s3StoreProfiles 下的 CACertificates 和 veleroNamespaceSecretKeyRef 字段将会丢失。

临时解决方案：如果 Ramen 配置具有 CACertificates 和 veleroNamespaceSecretKeyRef 字段的自定义值，则在执行升级后如何设置这些自定义值。

(DFBUGS-440)

对于使用 CephFS 发现的应用程序，在故障切换后同步停止

对于基于 CephFS 的工作负载，发现的应用同步可能会在故障转移或重新定位后在某个点停止。这可能会出现在 ReplicationSource 状态中报告的 Permission Denied 错误。

临时解决方案：

在虚拟机页面中发现的应用程序无法使用 remove DR 选项

在 Virtual Machines 页面中列出的应用程序无法使用 Remove DR 选项。

临时解决方案：

在 Virtual Machines 页面中，未为发现的应用程序显示 DR 状态

在 Virtual Machines 页面中列出的已发现的应用程序不会显示 DR 状态 。

临时解决方案：

故障切换后取消选择 PVC 不会清理二级 VRG 中的过时的条目，从而导致后续重新定位失败

如果在工作负载故障切换后取消选择 PVC，且后续的重新定位操作将执行回 preferredCluster，则过时的 PVC 仍可在 VRG 中报告。因此，DRPC 可能会将其 Protected 条件报告为 False，并显示类似如下的消息：

集群中的 VolumeReplicationGroup (/)没有报告任何 lastGroupSyncTime 作为主，满足重试 till 状态。

临时解决方案：

要解决这个问题，请从 VRG 状态手动清理过时的 PVC （即，在故障切换后取消选择的 PVC）。

当为发现的应用程序移除 DR 保护时，辅助 PVC 不会被删除

在辅助集群中，链接到工作负载的 CephFS PVC 通常由 VolumeReplicationGroup (VRG)管理。但是，当使用 Discovered Applications 功能发现工作负载时，关联的 CephFS PVC 不会被标记为 VRG-owned。因此，当禁用工作负载时，这些 PVC 不会被自动清理并变为孤立。

临时解决方案： 要在为发现的工作负载禁用 DR 保护后清理孤立的 CephFS PVC，请使用以下命令手动删除它们：

oc delete pvc <pvc-name> -n <pvc-namespace>

$ oc delete pvc <pvc-name> -n <pvc-namespace>

(DFBUGS-2827)

在次版本升级后，处于 Relocating 状态的 DRPC

从 4.19 升级到 4.20 后，DRPC (Disaster Recovery Placement Control)可能会进入 Relocating 状态。在此过程中，使用不同的命名约定创建新的 VGR (VolumeGroupReplication)，从而导致两个 VGR 尝试声明同一 PVC。这种冲突可能会导致 DRPC 状态出现临时不稳定。

临时解决方案：删除旧的 VGR （使用前面的命名约定）。然后，新的 VGR 将成功声明 PVC，DRPC 会在一段时间后返回健康状态。

(DFBUGS-4450)

在向集群添加容量后，Ceph 处于警告状态

在设备替换或添加容量后，观察到 Ceph 处于 HEALTH_WARN 状态，并带有 mon 报告缓慢的 ops。但是，对集群的可用性没有影响。

(DFBUGS-1273)

OSD pod 在添加容量过程中重启

在执行集群扩展后，OSD pod 会重启，方法是向集群添加容量。但是，除了 pod 重启外，不会对集群造成影响。

(DFBUGS-1426)

在 PVC 取消选择后同步会停止

当将 PersistentVolumeClaim (PVC)添加到组中或通过修改其标签以匹配或不匹配组条件时，同步操作可能会意外停止。这是因为 VolumeReplicationGroup (VRG)状态中剩余的过时受保护的 PVC 条目。

临时解决方案：

手动编辑 VRG 的 status 字段以删除过时的受保护的 PVC：

oc edit vrg <vrg-name> -n <vrg-namespace> --subresource=status

$ oc edit vrg <vrg-name> -n <vrg-namespace> --subresource=status

(DFBUGS-4012)

在工作负载删除后，PV Remain Stuck in Released State

最终同步后，所有临时 PV/PVC 都会被删除；但是，对于某些 PV，persistentVolume ReclaimPolicy 会保留为 Retain，从而导致 PV 处于 Released 状态。

临时解决方案：

使用以下命令编辑 PV persistentVolumeReclaimPolicy ：

oc edit pv <pv-name>

$ oc edit pv <pv-name>

将 persistentVolumeReclaimPolicy 更改为 Delete。卡住 PV 将消失。

(DFBUGS-4535)