第 7 章 灾难恢复故障排除
7.1. 对 Metro-DR 进行故障排除 复制链接链接已复制到粘贴板!
7.1.1. 在故障切换后,有状态集应用程序会卡住 复制链接链接已复制到粘贴板!
- 问题
在重新定位到首选集群时,DRPlacementControl 会一直报告 PROGRESSION 为 "MovingToSecondary"。
在以前的版本中,在 Kubernetes v1.23 之前,Kubernetes control plane 不会清理为 StatefulSets 创建的 PVC。此活动由集群管理员或管理 StatefulSets 的软件操作员保留。因此,当 Pod 被删除时,StatefulSet 的 PVC 会保持不变。这可防止 Ramen 将应用程序重新定位到首选集群。
- 解决方案
如果工作负载使用 StatefulSets,且重新定位会卡住 PROGRESSION 为 "MovingToSecondary",则运行:
oc get pvc -n <namespace>
$ oc get pvc -n <namespace>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 对于属于该 StatefulSet 的命名空间的每个绑定的 PVC,请运行
oc delete pvc <pvcname> -n namespace
$ oc delete pvc <pvcname> -n namespace
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 删除所有 PVC 后,卷组复制组 (VRG) 过渡到 secondary,然后会被删除。
运行以下命令
oc get drpc -n <namespace> -o wide
$ oc get drpc -n <namespace> -o wide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 几分钟后,PROGRESSION 报告 "Completed" 并完成重新定位。
- 结果
- 工作负载重新定位到首选集群
BZ reference: [2118270]
7.1.2. DR 策略可保护同一命名空间中的所有应用程序 复制链接链接已复制到粘贴板!
- 问题
-
虽然只有单个应用程序被选择供 DR 策略使用,但同一命名空间中的所有应用程序都会受到保护。这会导致 PVC,与多个工作负载的
DRPlacementControl
spec.pvcSelector
匹配;或者,如果所有工作负载中没有选择器,复制管理可能会多次管理每个 PVC,并根据单独的DRPlacementControl
操作造成数据崩溃或无效操作。 - 解决方案
-
标签 PVC 属于唯一工作负载,并使用所选标签作为 DRPlacementControl
spec.pvcSelector
,以忽略哪个 DRPlacementControl 保护和管理命名空间中的哪些 PVC 子集。无法使用用户界面为 DRPlacementControl 指定spec.pvcSelector
字段,因此必须使用命令行删除并创建此类应用程序的 DRPlacementControl。
BZ 参考: [2111163]
7.1.3. 在应用程序故障时处于 Relocating 状态 复制链接链接已复制到粘贴板!
- 问题
-
这个问题可能会在执行故障转移和应用程序的故障后发生(所有节点或集群)。当执行故障恢复应用程序时,会停留在
Relocating
状态,并显示Waiting
for PV restore to complete。 - 解决方案
- 使用 S3 客户端或等同从 s3 存储清理重复的 PV 对象。仅保持接近故障转移或重新定位时间的时间戳的那一个。
BZ 参考: [2120201]