3.18. 使用 Red Hat Advanced Cluster Management 进行 hub 恢复 [技术预览]

流程

1. 确保在被动 hub 集群上安装了 RHACM operator 和 MultiClusterHub。具体步骤请查看 RHACM 安装指南。

   成功安装 Operator 后，用户界面中会显示一个带有 Web 控制台更新可用消息的弹出窗口。点此弹出窗口中的 Refresh Web 控制台来反映控制台更改。

2. 在 hub 恢复前，配置备份和恢复。请参阅 RHACM 业务连续性 指南的 备份和恢复 主题。
3. 在恢复前，在被动 RHACM hub 上安装多集群编配器(MCO) Operator 和 Red Hat OpenShift GitOps operator。有关恢复 RHACM hub 的说明，请参阅安装 OpenShift Data Foundation Multicluster Orchestrator operator。
4. 确保 Restore.cluster.open-cluster-management.io 资源将 .spec.cleanupBeforeRestore 设置为 None。详情请参阅在 检查 RHACM 文档的备份时恢复被动资源。
5. 如果在设置过程中手动配置了跨集群的 SSL 访问，请在集群间重新配置 SSL 访问。具体步骤请参阅 在集群间配置 SSL 访问 部分。

6. 在被动 hub 上，为 openshift-operators 命名空间添加标签，以便使用以下命令启用 VolumeSyncronizationDelay 警报的基本监控。如需警报详情，请参阅 灾难恢复警报 章节。

   $ oc label namespace openshift-operators openshift.io/cluster-monitoring='true'

流程

1. 在恢复过程中，为了避免正确重新生成 ManifestWorks 时资源驱除，您可以放大 AppliedManifestWork 驱除 宽限期。在被动 hub 集群中，检查现有的全局 KlusterletConfig。

   • 如果存在全局 KlusterletConfig，则编辑 appliedManifestWorkEvictionGracePeriod 参数的值。例如，24 小时或更多。

   • 如果全局 KlusterletConfig 不存在，则使用以下 yaml 创建 Klusterletconfig ：

     apiVersion: config.open-cluster-management.io/v1alpha1
     kind: KlusterletConfig
     metadata:
       name: global
     spec:
       appliedManifestWorkEvictionGracePeriod: "24h"

     配置将自动传播到所有受管集群。

2. 恢复被动 hub 集群上的备份。如需更多信息，请参阅 从备份中恢复 hub 集群。

   重要

   将失败的 hub 恢复到其被动实例只会将应用程序及其 DR 保护状态恢复到其最后一个调度的备份。在最后一次调度的备份后任何受 DR 保护的应用程序都需要在新 hub 上再次保护。

3. 验证恢复是否已完成。

   $ oc -n <restore-namespace> wait restore <restore-name> --for=jsonpath='{.status.phase}'=Finished --timeout=120s

4. 验证 Primary 和 Secondary 受管集群是否已成功导入到 RHACM 控制台，并可以访问它们。如果有任何受管集群停机或无法访问，则无法成功导入。
5. 等待 DRPolicy 验证成功。

6. 验证 DRPolicy 是否已成功创建。对创建的每个 DRPolicy 资源在 Hub 集群中 运行此命令，其中 < drpolicy_name& gt; 替换为唯一名称。

   $ oc get drpolicy <drpolicy_name> -o jsonpath='{.status.conditions[].reason}{"\n"}'

   输出示例：

   Succeeded

7. 刷新 RHACM 控制台，以便在 Active hub 集群上启用了 DR 监控仪表板标签页。

8. 在新 hub 集群中使用以下命令验证 DRPC 输出：

   $ oc get drpc -A -o wide

   如果 PROGRESSION 显示 PAUSED 状态，则需要管理干预才能取消暂停它。PROGRESSION 在以下条件下进入 PAUSED 状态：

   • Cluster Query Failure: 在 DRPC 协调过程中成功查询任何集群。在 hub 恢复过程中可能会出现这种情况。
   • action Mismatch: DRPC 操作与查询的 VRG 操作不同。

   • Cluster Mismatch: DRPC 操作和 VRG 操作相同，但 Primary VRG 存在于与 DRPC 所期望的不同集群中。

     重要

     如果您无法诊断并解决暂停的原因，请联系红帽客户支持。

     如果 PROGRESSION 处于 Completed 或 Cleaning up，则可以安全地继续。

9. 编辑新 hub 上的全局 KlusterletConfig，并删除 appliedManifestWorkEvictionGracePeriod 及其值的参数。

10. 根据活跃 hub 集群还是活跃 hub 集群以及主受管集群是否已停机，根据您的场景按照以下步骤操作：

    1. 如果只有活跃的 hub 集群停机，且受管集群仍然可以访问，则不需要进一步的操作。

    2. 如果主受管集群与活跃 hub 集群一起停机，则需要将工作负载从主受管集群切换到二级受管集群。

       有关故障转移说明，根据您的工作负载类型，请参阅 基于订阅的应用程序或基于 ApplicationSet 的应用程序。

11. 验证故障转移是否成功。如果主受管集群也停机，则工作负载的 PROGRESSION 状态将处于 Cleaning Up 阶段，直到主受管集群恢复在线并成功导入到 RHACM 控制台。

    在被动 hub 集群中，运行以下命令来检查 PROGRESSION 状态。

    $ oc get drpc -o wide -A