7.2. 对 Regional-DR 进行故障排除
7.2.1. rbd-mirror 守护进程健康状态
- 问题
当 mirror 服务
::get_mirror_service_status调用Cephmonitor 来获取rbd-mirror的服务状态，会有多种情况会报告 WARNING。在网络连接网络连接后，
rbd-mirror守护进程健康状态在警告状态，同时两个受管集群间的连接都正常。- 解决方案
在 toolbox 中运行以下命令并查找
leader:falserbd mirror pool status --verbose ocs-storagecluster-cephblockpool | grep 'leader:'
如果您在输出中看到以下内容：
leader: false这表示存在守护进程启动问题，最有可能的根本原因是由于问题可靠地连接到 secondary 集群。
临时解决方案：通过删除 pod 并验证它已重新调度到另一节点上，将
rbd-mirrorpod 移到另一个节点。leader: true或没有输出
BZ 参考： [2118627]
7.2.2. volsync-rsync-src pod 处于错误状态，因为它无法解析目标主机名
- 问题
VolSync源 pod 无法解析 VolSync 目标 pod 的主机名。VolSync Pod 的日志在延长时间内显示错误消息，类似于以下日志片断。$ oc logs -n busybox-workloads-3-2 volsync-rsync-src-dd-io-pvc-1-p25rz
输出示例
VolSync rsync container version: ACM-0.6.0-ce9a280 Syncing data to volsync-rsync-dst-dd-io-pvc-1.busybox-workloads-3-2.svc.clusterset.local:22 ... ssh: Could not resolve hostname volsync-rsync-dst-dd-io-pvc-1.busybox-workloads-3-2.svc.clusterset.local: Name or service not known
- 解决方案
在这两个节点上，重启
submariner-lighthouse-agent。$ oc delete pod -l app=submariner-lighthouse-agent -n submariner-operator
7.2.3. 在恢复旧的主受管集群后，对 ApplicationSet 工作负载的清理和数据同步会卡住
- 问题
当 hub 集群失败时，基于 ApplicationSet 的工作负载部署到受管集群不会收集垃圾回收。它被恢复到一个备用的 hub 集群，而工作负载已切换到存活的受管集群。工作负载失败的集群，重新加入新的恢复的待机 hub。
使用区域 DRPolicy 进行 DR 保护的 ApplicationSets 开始触发 VolumeSynchronizationDelay 警报。另外，这种 DR 保护的工作负载无法切换到对等集群，或重新定位到对等集群，因为数据在两个集群之间没有同步。
- 解决方案
这个临时解决方案要求
openshift-gitopsoperator 可以拥有受管集群上孤立的工作负载资源，这些资源会从新的恢复的 hub 故障转移后重新加入 hub。要实现此目的，可以执行以下步骤：-
确定由
openshift-gitops命名空间中的 hub 集群上的 ArgoCD ApplicationSet 资源使用的放置。 在此字段中检查 ApplicationSet 的放置标签值：
spec.generators.clusterDecisionResource.labelSelector.matchLabels这将是放置资源 < placement-name> 的名称
确保 ApplicationSet 引用的
Placement存在PlacemenDecision。$ oc get placementdecision -n openshift-gitops --selector cluster.open-cluster-management.io/placement=<placement-name>
这会导致单个
PlacementDecision将工作负载放在当前所需的故障转移集群中。为 ApplicationSet 创建新的
PlacementDecision，指向应清理的集群。例如：
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: PlacementDecision metadata: labels: cluster.open-cluster-management.io/decision-group-index: "1" # Typically one higher than the same value in the esisting PlacementDecision determined at step (2) cluster.open-cluster-management.io/decision-group-name: "" cluster.open-cluster-management.io/placement: cephfs-appset-busybox10-placement name: <placemen-name>-decision-<n> # <n> should be one higher than the existing PlacementDecision as determined in step (2) namespace: openshift-gitops使用 status 子资源 更新新创建的
PlacementDecision。decision-status.yaml: status: decisions: - clusterName: <managedcluster-name-to-clean-up> # This would be the cluster from where the workload was failed over, NOT the current workload cluster reason: FailoverCleanup$ oc patch placementdecision -n openshift-gitops <placemen-name>-decision-<n> --patch-file=decision-status.yaml --subresource=status --type=merge
监控并确保 ApplicationSet 的 Application 资源已放在所需的集群中
$ oc get application -n openshift-gitops <applicationset-name>-<managedcluster-name-to-clean-up>
在输出中，检查 SYNC STATUS 是否显示为
Synced，并且 HEALTH STATUS 显示为Healthy。删除在第 3 步中创建的 PlacementDecision，以便 ArgoCD 可以垃圾回收 <managedcluster-name-to-clean-up> 上的工作负载资源
$ oc delete placementdecision -n openshift-gitops <placemen-name>-decision-<n>
受 DR 保护的 ApplicationSets （带有区域 DRPolicy）停止触发
VolumeSynchronizationDelay警报。-
确定由
BZ 参考： [2268594]
