支持控制台（Console）开发人员开始试用联系人

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

6.2.1. 为某些镜像停止 RBD 镜像调度

问题

对于某些镜像，需要一些常见原因来进行 RBD 镜像调度停止。

在为镜像标记应用程序后，出于某种原因（如果不复制），请使用 toolbox pod 并运行它，以查看哪些镜像调度已停止。 

$ rbd snap ls <poolname/imagename> –all
解决方案
  • 在主集群中重启 manager 守护进程
  • 在主集群中禁用并立即重新启用受影响镜像的 mirroring

BZ 参考： [2067095 和 2121514]

6.2.2. 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]

6.2.3. 在故障切换后，有状态集应用程序会卡住

问题

在重新定位到首选集群时，DRPlacementControl 会一直报告 PROGRESSION 为 "MovingToSecondary"。

在以前的版本中，在 Kubernetes v1.23 之前，Kubernetes control plane 不会清理为 StatefulSets 创建的 PVC。此活动由集群管理员或管理 StatefulSets 的软件操作员保留。因此，当 Pod 被删除时，StatefulSet 的 PVC 会保持不变。这可防止 Ramen 将应用程序重新定位到首选集群。

解决方案

  1. 如果工作负载使用 StatefulSets，且重新定位会卡住 PROGRESSION 为 "MovingToSecondary"，则运行： 

    $ oc get pvc -n <namespace>

  2. 对于属于该 StatefulSet 的命名空间的每个绑定的 PVC，请运行 

    $ oc delete pvc <pvcname> -n namespace

    删除所有 PVC 后，卷组复制组 (VRG) 过渡到 secondary，然后会被删除。

  3. 运行以下命令 

    $ oc get drpc -n <namespace> -o wide

    几分钟后，PROGRESSION 报告 "Completed" 并完成重新定位。

结果
工作负载重新定位到首选集群

BZ reference: [2118270]

6.2.4. 故障转移后应用程序没有运行

问题
在应用程序失败时，工作负载 pod 无法访问运行状态，并带有错误 MountVolume.MountDevice failed for volume <PV name> : rpc error: code = Internal desc = fail to check rbd image status: (cannot map image <image description> it is not primary)
注意

在工作负载失败的集群中执行这些步骤。

解决方案

  1. 将 RBD 镜像守护进程部署缩减为 0，直到应用 pod 可以从上述错误中恢复。 

    $ oc scale deployment rook-ceph-rbd-mirror-a -n openshift-storage --replicas=0

  2. 在恢复后，将 RBD 镜像守护进程部署重新调度到 1。 

    $ oc scale deployment rook-ceph-rbd-mirror-a -n openshift-storage --replicas=1

BZ 参考： [2134936]

6.2.5. volsync-rsync-src pod 处于错误状态

问题

volsync-rsync-src pod 处于错误状态，因为它们无法连接到 volsync-rsync-dst。VolSync 源 pod 日志可能会在与日志片断类似的延长持续时间内显示持久性错误消息。

运行以下命令来检查日志。 

$ oc logs volsync-rsync-src-<app pvc name>-<suffix>

输出示例 

VolSync rsync container version: ACM-0.6.0-ce9a280
Syncing data to volsync-rsync-dst-busybox-pvc-9.busybox-workloads-1.svc.clusterset.local:22
Syncronization failed. Retrying in 2 seconds. Retry 1/5.
rsync: connection unexpectedly closed (7 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.3]
解决方案

您可以按照以下步骤重新配置最大传输单元 (MTU) 大小来解决这个问题：

  1. 注解具有 submariner 网关标签的节点。 

    $ oc annotate node -l submariner.io/gateway submariner.io/tcp-clamp-mss=1340 --overwrite

    输出示例 

    node/compute-0 annotated
node/compute-2 annotated

  2. 删除 submariner 路由代理 pod。 

    $ oc delete pods -n submariner-operator -l app=submariner-routeagent

    输出示例 

    pod "submariner-routeagent-4r66z" deleted
pod "submariner-routeagent-4tn6d" deleted
pod "submariner-routeagent-9r42l" deleted
pod "submariner-routeagent-bg5wq" deleted
pod "submariner-routeagent-gzqdj" deleted
pod "submariner-routeagent-j77jq" deleted

  3. 检查 vol-sync-src pod 中是否存在任何错误。 

    $ oc logs volsync-rsync-src-dd-io-pvc-3-nwn8h

    输出示例 

    VolSync rsync container version: ACM-0.6.0-ce9a280
Syncing data to volsync-rsync-dst-dd-io-pvc-3.busybox-workloads-8.svc.clusterset.local:22 …
.d..tp..... ./
<f+++++++++ 07-12-2022_13-03-04-dd-io-3-5d6b4b84df-v9bhc

BZ 参考： [2136864]

6.2.6. 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

6.2.7. 无法使用 RHACM 2.8 将 DRPolicy 应用到订阅工作负载

问题
Red Hat Advanced Cluster Management (RHACM) 2.8 控制台已弃用 PlacementRule 类型，并移到 Subscription 应用程序的 放置类型。因此，当用户使用 RHACM 2.8 控制台创建 Subscription 应用程序时，只会使用 Placement 创建应用程序。由于 OpenShift Data Foundation 4.12 灾难恢复用户界面和 Ramen 操作器不支持订阅应用程序的放置，所以灾难恢复用户界面无法检测应用程序并显示分配策略的详情。
解决方案

由于 RHACM 2.8 控制台仍能够检测 PlacementRule （使用命令行界面(CLI)创建的 PlacementRule），请执行以下步骤，以使用 PlacementRule 在 RHACM 2.8 中创建 Subscription 应用程序：

  1. 使用应用程序命名空间创建一个新项目。（例如： busybox-application）
  2. 找到要部署应用的受管集群的标签（例如： drcluster1-jul-6）

  3. 使用上一步中创建的受管集群标签在 application-namespace 上创建 PlacementRule CR： 

    apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  labels:
    app: busybox-application
  name: busybox-application-placementrule-1
  namespace: busybox-application
spec:
  clusterSelector:
    matchLabels:
      name: drcluster1-jul-6
  4. 在使用 Subscription 应用程序页面中的 RHACM 控制台创建应用程序时，请选择此新的 PlacementRule。
  5. 从 YAML 编辑器删除 PlacementRule，以便可以重新使用所选编辑器。

BZ 参考： [2216190]

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.