Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

9.2. 对 Regional-DR 进行故障排除

9.2.1. rbd-mirror 守护进程健康状态
复制链接

问题

当 mirror 服务 ::get_mirror_service_status 调用 Ceph monitor 来获取 rbd-mirror 的服务状态，会有多种情况会报告 WARNING。

在网络连接网络连接后，rbd-mirror 守护进程健康状态在 警告 状态，同时两个受管集群间的连接都正常。

解决方案

在 toolbox 中运行以下命令并查找 leader:false 

rbd mirror pool status --verbose ocs-storagecluster-cephblockpool | grep 'leader:'

如果您在输出中看到以下内容：

leader: false

这表示存在守护进程启动问题，最有可能的根本原因是由于问题可靠地连接到 secondary 集群。

临时解决方案：通过删除 pod 并验证它已重新调度到另一节点上，将 rbd-mirror pod 移到另一个节点。

leader: true 或没有输出

联系红帽支持。

BZ 参考： [2118627]

问题

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
问题

当 hub 集群失败时，基于 ApplicationSet 的工作负载部署不会垃圾回收。它被恢复到备用 hub 集群，而工作负载已故障转移到存活的受管集群。工作负载从中失败的集群，重新加入新的恢复的待机 hub。

ApplicationSets 是 DR 保护的，带有区域 DRPolicy，因此开始触发 VolumeSynchronizationDelay 警报。进一步的 DR 保护工作负载无法故障转移到对等集群，或者重新定位到对等集群，因为数据在两个集群之间没有同步。

解决方案

临时解决方案要求 openshift-gitops operator 可以拥有在受管集群中孤立的工作负载资源，这些资源在重新加入 hub 后从新的恢复的 hub 执行。要达到此目的，可以执行以下步骤：

  1. 确定 openshift-gitops 命名空间中的 hub 集群上的 ArgoCD ApplicationSet 资源使用的放置。

  2. 在此字段中检查 ApplicationSet 的放置标签值： spec.generators.clusterDecisionResource.labelSelector.matchLabels

    这将是放置资源 < placement-name> 的名称

  3. 确保 ApplicationSet 引用的 Placement 有一个 PlacemenDecision。 

    $ oc get placementdecision -n openshift-gitops --selector cluster.open-cluster-management.io/placement=<placement-name>

    这会导致单个 PlacementDecision 将工作负载放置在当前所需的故障切换集群中。

  4. 为 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

  5. 使用状态 子资源 更新新创建的 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

  6. 监控并确保 ApplicationSet 的应用程序资源已放在所需的集群中 

    $ oc get application -n openshift-gitops  <applicationset-name>-<managedcluster-name-to-clean-up>

    在输出中，检查 SYNC STATUS 是否显示为 Synced，并且 HEALTH STATUS 显示为 Healthy。

  7. 删除在第 3 步中创建的 PlacementDecision，以便 ArgoCD 可以垃圾回收 <managedcluster-name-to-clean-up> 上的工作负载资源 

    $ oc delete placementdecision -n openshift-gitops <placemen-name>-decision-<n>

ApplicationSets 是 DR 保护的，带有区域 DRPolicy 的 ApplicationSet 会停止触发 VolumeSynchronizationDelay 警报。

BZ 参考： [2268594]

Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2026 Red Hat返回顶部