为 OpenShift Workloads 配置 OpenShift Data Foundation 灾难恢复

1. 确保满足作为 DR 解决方案的三个集群（Hub、Primary 和 Secondary Openshift Container Platform）集群的要求。请参阅启用 Metro-DR 的要求。
2. 确保您具有仲裁者部署 Red Hat Ceph Storage 扩展集群的要求。请参阅部署 Red Hat Ceph Storage 的要求。
3. 部署和配置 Red Hat Ceph Storage 扩展模式。有关使用扩展模式功能在两个不同数据中心启用 Ceph 集群的说明，请参阅部署 Red Hat Ceph Storage。
4. 安装 OpenShift Data Foundation operator，并在 Primary 和 Secondary 受管集群上创建存储系统。请参阅在受管集群中安装 OpenShift Data Foundation。
5. 在 Hub 集群上安装 ODF Multicluster Orchestrator。请参阅在 Hub 集群上安装 ODF 多集群编排器。
6. 配置 Hub、Primary 和 Secondary 集群之间的 SSL 访问。请参阅配置跨集群的 SSL 访问。

7. 创建 DRPolicy 资源，以用于在跨 Primary 和 Secondary 应用程序所需的 DR 保护的应用程序。请参阅在 Hub 集群上创建灾难恢复策略。

   注意

   Metro-DR 解决方案只能有一个 DRpolicy。

8. 测试您的灾难恢复解决方案：

   1. 基于订阅的应用程序 ：

      • 创建示例应用程序。请参阅 创建示例应用程序。
      • 在受管集群之间使用示例应用程序测试故障切换和重定位操作。请参阅基于订阅的应用程序故障切换 和 重新定位基于订阅的应用程序。

   2. 基于 ApplicationSet 的应用程序：

      • 创建示例应用程序。请参阅 创建基于 ApplicationSet 的应用程序。
      • 在受管集群之间使用示例应用程序测试故障切换和重定位操作。请参阅 基于 ApplicationSet 的应用程序故障切换和 重新定位基于 ApplicationSet 的应用程序。

流程

1. 在每个受管集群中，安装和配置最新的 OpenShift Data Foundation 集群。

2. 在安装 operator 后，创建一个 StorageSystem，使用选择 Full deployment 类型和 Connect with external storage platform，其中您的后端存储类型为 Red Hat Ceph Storage。

   具体步骤请参考 以外部模式部署 OpenShift Data Foundation。

   将以下标记与 ceph-external-cluster-details-exporter.py 脚本一起使用。

   1. 您在 ceph-external-cluster-details-exporter.py script 中需要最少使用以下三个标记：

      --rbd-data-pool-name

      使用在为 OpenShift Container Platform 部署 RHCS 时创建的 RBD 池的名称。例如，池的名称可能为 rbdpool。

      --rgw-endpoint

      以 <ip_address>:<port> 格式提供端点。它是与您要配置的 OpenShift Container Platform 集群相同的站点中运行的 RGW 守护进程的 RGW IP。

      --run-as-user

      每个站点使用不同的客户端名称。

   2. 如果在 RHCS 部署过程中使用了默认值，则以下标记是可选的 ：

      --cephfs-filesystem-name

      使用在为 OpenShift Container Platform 在 RHCS 部署期间创建的 CephFS 文件系统的名称，默认的文件系统名称是 cephfs。

      --cephfs-data-pool-name

      在用于 OpenShift Container Platform 的 RHCS 部署期间创建的 CephFS 数据池名称后，默认的池称为 cephfs.data。

      --cephfs-metadata-pool-name

      在用于 OpenShift Container Platform 的 RHCS 部署期间创建的 CephFS 元数据池的名称后，默认的池名为 cephfs.meta。

   3. 在 bootstrap 节点（ceph1）上运行以下命令，为 datacenter1 和 datacenter2 中的 RGW 端点获取 IP：

      ceph orch ps | grep rgw.objectgw

      输出示例：

      rgw.objectgw.ceph3.mecpzm  ceph3  *:8080       running (5d)     31s ago   7w     204M        -  16.2.7-112.el8cp
      rgw.objectgw.ceph6.mecpzm  ceph6  *:8080       running (5d)     31s ago   7w     204M        -  16.2.7-112.el8cp

      host ceph3.example.com
      host ceph6.example.com

      输出示例：

      ceph3.example.com has address 10.0.40.24
      ceph6.example.com has address 10.0.40.66

   4. 使用在 bootstrapped 节点 ceph1 上为第一个 OpenShift Container Platform 受管集群 cluster1 配置的参数，运行 ceph-external-cluster-details-exporter.py。

      python3 ceph-external-cluster-details-exporter.py --rbd-data-pool-name rbdpool --cephfs-filesystem-name cephfs --cephfs-data-pool-name cephfs.cephfs.data  --cephfs-metadata-pool-name cephfs.cephfs.meta --<rgw-endpoint> XXX.XXX.XXX.XXX:8080 --run-as-user client.odf.cluster1 > ocp-cluster1.json

      注意

      根据您的环境修改 <rgw-endpoint> XXX.XXX.XXX.XXX。

   5. 使用在 bootstrapped 节点 ceph1 上为第一个 OpenShift Container Platform 受管集群 cluster2 配置的参数，运行 ceph-external-cluster-details-exporter.py。

      python3 ceph-external-cluster-details-exporter.py --rbd-data-pool-name rbdpool --cephfs-filesystem-name cephfs --cephfs-data-pool-name cephfs.cephfs.data  --cephfs-metadata-pool-name cephfs.cephfs.meta --rgw-endpoint XXX.XXX.XXX.XXX:8080 --run-as-user client.odf.cluster2 > ocp-cluster2.json

      注意

      根据您的环境修改 <rgw-endpoint> XXX.XXX.XXX.XXX。

      • 将 bootstrap 集群 (ceph1) ocp-cluster1.json 和 ocp-cluster2.json 这两个文件保存到本地机器中。
      • 在部署外部 OpenShift Data Foundation 的 cluster1 上，使用 OpenShift Container Platform 控制台上的文件 ocp-cluster1.json 的内容。
      • 在部署外部 OpenShift Data Foundation 的 cluster2 上，使用 OpenShift Container Platform 控制台上的文件 ocp-cluster2.json 的内容。
3. 检查设置，然后选择 Create StorageSystem。

4. 使用以下命令验证每个受管集群中 OpenShift Data Foundation 部署是否成功：

   $ oc get storagecluster -n openshift-storage ocs-external-storagecluster -o jsonpath='{.status.phase}{"\n"}'

   对于 Multicloud 网关(MCG)：

   $ oc get noobaa -n openshift-storage noobaa -o jsonpath='{.status.phase}{"\n"}'

   等待在主受管集群和从受管集群上的查询的状态结果变为 Ready。

5. 在 OpenShift Web 控制台中，进入到 Installed Operators → OpenShift Data Foundation → Storage System → ocs-external-storagecluster-storagesystem → Resources。验证 StorageCluster 的 Status 是否为 Ready，其旁边有一个绿色勾号标记。

流程

1. 在 Hub 集群中，进入到 OperatorHub 并使用关键字过滤器搜索 ODF Multicluster Orchestrator。
2. 点 ODF Multicluster Orchestrator 标题。

3. 保留所有默认设置，然后点安装。

   确保 operator 资源安装在 openshift-operators 中，并可用于所有命名空间。

   注意

   ODF Multicluster Orchestrator 还会在 RHACM hub 集群上作为依赖项安装 Openshift DR Hub Operator。

4. 验证 Operator Pod 处于 Running 状态。OpenShift DR Hub operator 也安装在 openshift-operators 命名空间中。

   $ oc get pods -n openshift-operators

   输出示例：

   NAME                                        READY   STATUS       RESTARTS    AGE
   odf-multicluster-console-6845b795b9-blxrn   1/1     Running      0           4d20h
   odfmo-controller-manager-f9d9dfb59-jbrsd    1/1     Running      0           4d20h
   ramen-hub-operator-6fb887f885-fss4w         2/2     Running      0           4d20h

步骤

1. 提取主受管集群的入口证书，并将输出保存到 primary.crt。

   $ oc get cm default-ingress-cert -n openshift-config-managed -o jsonpath="{['data']['ca-bundle\.crt']}" > primary.crt

2. 提取二级受管集群的入口证书，并将输出保存到 secondary.crt。

   $ oc get cm default-ingress-cert -n openshift-config-managed -o jsonpath="{['data']['ca-bundle\.crt']}" > secondary.crt

3. 创建新的 ConfigMap 文件，以使用文件名 cm-clusters-crt.yaml 来保存远程集群的证书捆绑包。

   注意

   如本示例文件所示，每个集群可能有超过三个证书。另外，请确保在从之前创建的 primary.crt 和 secondary.crt 文件中复制并粘贴后，证书内容会被正确缩进。

   apiVersion: v1
   data:
     ca-bundle.crt: |
       -----BEGIN CERTIFICATE-----
       <copy contents of cert1 from primary.crt here>
       -----END CERTIFICATE-----
   
       -----BEGIN CERTIFICATE-----
       <copy contents of cert2 from primary.crt here>
       -----END CERTIFICATE-----
   
       -----BEGIN CERTIFICATE-----
       <copy contents of cert3 primary.crt here>
       -----END CERTIFICATE----
   
       -----BEGIN CERTIFICATE-----
       <copy contents of cert1 from secondary.crt here>
       -----END CERTIFICATE-----
   
       -----BEGIN CERTIFICATE-----
       <copy contents of cert2 from secondary.crt here>
       -----END CERTIFICATE-----
   
       -----BEGIN CERTIFICATE-----
       <copy contents of cert3 from secondary.crt here>
       -----END CERTIFICATE-----
   kind: ConfigMap
   metadata:
     name: user-ca-bundle
     namespace: openshift-config

4. 在 Primary 受管集群, Secondary 受管集群, 和 Hub 集群 中创建 ConfigMap。

   $ oc create -f cm-clusters-crt.yaml

   输出示例：

   configmap/user-ca-bundle created

5. 对主受管集群、二级受管集群和 Hub 集群上的默认代理资源进行补丁。

   $ oc patch proxy cluster --type=merge  --patch='{"spec":{"trustedCA":{"name":"user-ca-bundle"}}}'

   输出示例：

   proxy.config.openshift.io/cluster patched

流程

1. 在 OpenShift 控制台中，进入到 All Clusters → Data Services → Data policies。
2. 点 Create DRPolicy。
3. 输入 Policy name。确保每个 DRPolicy 都有一个唯一名称（例如： ocp4perf1-ocp4perf2）。
4. 从与此新策略关联的受管集群列表中选择两个集群。
5. 复制策略根据所选的 OpenShift 集群自动设置为 sync。
6. 点 Create。

7. 验证 DRPolicy 是否已成功创建。在 Hub 集群中，为创建的每个 DRPolicy 资源运行这个命令，使用您的唯一名称替换 <drpolicy_name>。

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

   输出示例：

   Succeeded

   创建 DRPolicy 时，也会创建两个 DRCluster 资源。验证所有三个资源并且状态显示为 Succeeded 最多需要 10 分钟。

   注意

   DRPolicy 不支持编辑 SchedulingInterval、ReplicationClassSelector、VolumeSnapshotClassSelector 和 DRClusters 字段值。

8. 验证对象存储桶可以从 Hub 集群、Primary 受管集群和 Secondary 受管集群访问。

   1. 获取 Hub 集群上的 DRClusters 的名称。

      $ oc get drclusters

      输出示例：

   2. 检查 S3 访问每个受管集群上创建的每个存储桶。使用 DRCluster 验证命令，使用您的唯一名称替换 <drcluster_name>。

      注意

      DRClusters 不支持编辑 Region 和 S3ProfileName 字段值。

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

      输出示例：

      Succeeded

      注意

      确保为在 Hub 集群中的两个 DRClusters 运行命令。

9. 验证 OpenShift DR Cluster operator 已成功在 Primary 受管集群和 Secondary 受管集群上成功安装。

   $ oc get csv,pod -n openshift-dr-system

   输出示例：

   NAME                                                                            DISPLAY                         VERSION        REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/odr-cluster-operator.v4.15.0         Openshift DR Cluster Operator   4.15.0                    Succeeded
   clusterserviceversion.operators.coreos.com/volsync-product.v0.8.0               VolSync                         0.8.0                     Succeeded
   
   NAME                                             READY   STATUS    RESTARTS   AGE
   pod/ramen-dr-cluster-operator-6467cf5d4c-cc8kz   2/2     Running   0          3d12h

   您还可以验证 OpenShift DR Cluster Operator 是否在每个受管集群的 OperatorHub 上成功安装。

10. 验证 secret 是否在主受管集群和次受管集群中正确传播。

    oc get secrets -n openshift-dr-system | grep Opaque

    将输出与 Hub 集群的 s3SecretRef 匹配：

    oc get cm -n openshift-operators ramen-hub-operator-config -oyaml

流程

1. 在 Hub 集群上启用隔离。

   1. 打开 CLI 终端并编辑 DRCluster 资源，其中 <drcluster_name> 是您的唯一名称。

      小心

      在隔离了受管集群后，所有 从应用程序到 OpenShift Data Foundation 外部存储集群的通信将失败，一些 Pod 都将处于不健康状态（例如： CreateContainerError,CrashLoopBackOff）现已被隔离的集群。

      $ oc edit drcluster <drcluster_name>

      apiVersion: ramendr.openshift.io/v1alpha1
      kind: DRCluster
      metadata:
      [...]
      spec:
        ## Add this line
        clusterFence: Fenced
        cidrs:
        [...]
      [...]

      输出示例：

      drcluster.ramendr.openshift.io/ocp4perf1 edited

   2. 为主受管集群验证 Hub 集群上的隔离状态，使用您的唯一标识符替换 <drcluster_name>。

      $ oc get drcluster.ramendr.openshift.io <drcluster_name> -o jsonpath='{.status.phase}{"\n"}'

      输出示例：

      Fenced

   3. 验证属于 OpenShift Container Platform 集群节点的 IP 现在是否在 blocklist 中。

      $ ceph osd blocklist ls

      输出示例

      cidr:10.1.161.1:0/32 2028-10-30T22:30:03.585634+0000
      cidr:10.1.161.14:0/32 2028-10-30T22:30:02.483561+0000
      cidr:10.1.161.51:0/32 2028-10-30T22:30:01.272267+0000
      cidr:10.1.161.63:0/32 2028-10-30T22:30:05.099655+0000
      cidr:10.1.161.129:0/32 2028-10-30T22:29:58.335390+0000
      cidr:10.1.161.130:0/32 2028-10-30T22:29:59.861518+0000

2. 在 Hub 集群中，进入到 Applications。
3. 点应用程序行末尾的 Actions 菜单，以查看可用操作的列表。
4. 点 Failover application。
5. 在显示了 Failover 应用程序 模态后，选择策略和目标集群，相关的应用程序将在出现灾难时故障转移。

6. 点选择订阅组下拉菜单，验证默认选择或修改此设置。

   默认情况下，选择为应用程序资源复制的订阅组。

7. 检查 Failover readiness 的状态。

   • 如果状态是 Ready 且带有一个绿色勾号，这表示目标集群已就绪，可启动故障转移。继续执行第 7 步。
   • 如果状态是 Unknown 或 Not ready，请等待到状态变为 Ready。
8. 点 Initiate。busybox 应用程序现在故障转移到 Secondary-managed 集群。
9. 关闭模态窗口，并使用 Applications 页面中的 Data policies 列跟踪状态。

10. 验证活动状态是否为应用的 FailedOver。

    1. 进入 Applications → Overview 选项卡。
    2. 在 Data policy 列中，点您要将策略应用到的应用程序的策略链接。
    3. 在 Data policy 弹出窗口中，点 View more details 链接。

流程

1. 在 Hub 集群上启用隔离。

   1. 打开 CLI 终端并编辑 DRCluster 资源，其中 <drcluster_name> 是您的唯一名称。

      小心

      在隔离了受管集群后，所有 从应用程序到 OpenShift Data Foundation 外部存储集群的通信将失败，一些 Pod 都将处于不健康状态（例如： CreateContainerError,CrashLoopBackOff）现已被隔离的集群。

      $ oc edit drcluster <drcluster_name>

      apiVersion: ramendr.openshift.io/v1alpha1
      kind: DRCluster
      metadata:
      [...]
      spec:
        ## Add this line
        clusterFence: Fenced
        cidrs:
        [...]
      [...]

      输出示例：

      drcluster.ramendr.openshift.io/ocp4perf1 edited

   2. 为主受管集群验证 Hub 集群上的隔离状态，使用您的唯一标识符替换 <drcluster_name>。

      $ oc get drcluster.ramendr.openshift.io <drcluster_name> -o jsonpath='{.status.phase}{"\n"}'

      输出示例：

      Fenced

   3. 验证属于 OpenShift Container Platform 集群节点的 IP 现在是否在 blocklist 中。

      $ ceph osd blocklist ls

      输出示例

      cidr:10.1.161.1:0/32 2028-10-30T22:30:03.585634+0000
      cidr:10.1.161.14:0/32 2028-10-30T22:30:02.483561+0000
      cidr:10.1.161.51:0/32 2028-10-30T22:30:01.272267+0000
      cidr:10.1.161.63:0/32 2028-10-30T22:30:05.099655+0000
      cidr:10.1.161.129:0/32 2028-10-30T22:29:58.335390+0000
      cidr:10.1.161.130:0/32 2028-10-30T22:29:59.861518+0000

2. 在 Hub 集群中，进入到 Applications。
3. 点应用程序行末尾的 Actions 菜单，以查看可用操作的列表。
4. 点 Failover application。
5. 显示 Failover 应用程序 模态时，验证显示的详细信息是否正确并检查 Failover readiness 的状态。如果状态是 Ready 且带有绿色勾号，这表示目标集群已准备好故障转移启动。
6. 点 Initiate。busybox 资源现在在目标集群上创建。
7. 关闭模态窗口，并使用 Applications 页面中的 Data policies 列跟踪状态。

8. 验证活动状态是否为应用的 FailedOver。

   1. 进入 Applications → Overview 选项卡。
   2. 在 Data policy 列中，点您要将策略应用到的应用程序的策略链接。
   3. 在 Data policy 弹出窗口中，验证您可以看到一个或多个策略名称以及与应用程序中使用的策略关联的持续活动。

流程

1. 在 Hub 集群中禁用隔离功能。

   1. 编辑此集群的 DRCluster 资源，将 <drcluster_name> 替换为唯一名称。

      $ oc edit drcluster <drcluster_name>

      apiVersion: ramendr.openshift.io/v1alpha1
      kind: DRCluster
      metadata:
      [...]
      spec:
        cidrs:
        [...]
        ## Modify this line
        clusterFence: Unfenced
        [...]
      [...]

      输出示例：

      drcluster.ramendr.openshift.io/ocp4perf1 edited

   2. 正常重新引导了 Fenced 的 OpenShift Container Platform 节点。重启后，需要重启来恢复 I/O 操作，以避免进一步恢复编配失败。按照正常重新引导节点 的步骤 ，重新引导集群中的所有节点。

      注意

      先确保所有节点已被封锁和排空，然后再重新引导并在节点上执行 uncordon 操作。

   3. 在所有 OpenShift 节点被重新引导并处于 Ready 状态后，通过在主受管集群中运行此命令（或任何集群是 Unfenced），验证所有 Pod 都处于健康状态。

      oc get pods -A | egrep -v 'Running|Completed'

      输出示例：

      NAMESPACE                                          NAME                                                              READY   STATUS      RESTARTS       AGE

      此查询的输出应该为零个 Pod，然后继续下一步。

      重要

      如果因为严重的存储通信导致 pod 仍然处于不健康状态，请在继续操作前进行故障排除并解决。由于存储集群位于 OpenShift 的外部，因此在 OpenShift 应用正常运行的站点中断后，还必须正确恢复它。

      另外，您可以使用 OpenShift Web 控制台仪表板和 Overview 选项卡来评估应用程序和外部 ODF 存储集群的健康状态。详细的 OpenShift Data Foundation 仪表板可通过 Storage → Data Foundation 找到。

   4. 验证 Unfenced 集群是否处于健康状态。为 Primary-managed 集群验证 Hub 集群中的隔离状态，将 <drcluster_name> 替换为唯一名称。

      $ oc get drcluster.ramendr.openshift.io <drcluster_name> -o jsonpath='{.status.phase}{"\n"}'

      输出示例：

      Unfenced

   5. 验证属于 OpenShift Container Platform 集群节点的 IP 不在 blocklist 中。

      $ ceph osd blocklist ls

      确保您没有看到隔离过程中添加的 IP。

2. 在 Hub 集群中，进入到 Applications。
3. 点应用程序行末尾的 Actions 菜单，以查看可用操作的列表。
4. 点 Relocate application。
5. 当 Relocate application 模态显示时，选择 policy 和 target cluster，在出现灾难时相关的应用程序将重新定位到其中。
6. 默认情况下，选择部署应用程序资源的订阅组。点选择订阅组下拉菜单，验证默认选择或修改此设置。

7. 检查 Relocation readiness 的状态。

   • 如果状态是 Ready 且带有一个绿色勾号，这表示目标集群已准备好重定位来进行启动。继续执行第 7 步。
   • 如果状态是 Unknown 或 Not ready，请等待到状态变为 Ready。
8. 点 Initiate。busybox 资源现在在目标集群上创建。
9. 关闭模态窗口，并使用 Applications 页面中的 Data policies 列跟踪状态。

10. 验证应用程序的活动状态是否显示为 Relocated。

    1. 进入 Applications → Overview 选项卡。
    2. 在 Data policy 列中，点您要将策略应用到的应用程序的策略链接。
    3. 在 Data policy 弹出窗口中，点 View more details 链接。

流程

1. 在 Hub 集群中禁用隔离功能。

   1. 编辑此集群的 DRCluster 资源，将 <drcluster_name> 替换为唯一名称。

      $ oc edit drcluster <drcluster_name>

      apiVersion: ramendr.openshift.io/v1alpha1
      kind: DRCluster
      metadata:
      [...]
      spec:
        cidrs:
        [...]
        ## Modify this line
        clusterFence: Unfenced
        [...]
      [...]

      输出示例：

      drcluster.ramendr.openshift.io/ocp4perf1 edited

   2. 正常重新引导了 Fenced 的 OpenShift Container Platform 节点。重启后，需要重启来恢复 I/O 操作，以避免进一步恢复编配失败。按照正常重新引导节点 的步骤 ，重新引导集群中的所有节点。

      注意

      先确保所有节点已被封锁和排空，然后再重新引导并在节点上执行 uncordon 操作。

   3. 在所有 OpenShift 节点被重新引导并处于 Ready 状态后，通过在主受管集群中运行此命令（或任何集群是 Unfenced），验证所有 Pod 都处于健康状态。

      oc get pods -A | egrep -v 'Running|Completed'

      输出示例：

      NAMESPACE                                          NAME                                                              READY   STATUS      RESTARTS       AGE

      此查询的输出应该为零个 Pod，然后继续下一步。

      重要

      如果因为严重的存储通信导致 pod 仍然处于不健康状态，请在继续操作前进行故障排除并解决。由于存储集群位于 OpenShift 的外部，因此在 OpenShift 应用正常运行的站点中断后，还必须正确恢复它。

      另外，您可以使用 OpenShift Web 控制台仪表板和 Overview 选项卡来评估应用程序和外部 ODF 存储集群的健康状态。详细的 OpenShift Data Foundation 仪表板可通过 Storage → Data Foundation 找到。

   4. 验证 Unfenced 集群是否处于健康状态。为 Primary-managed 集群验证 Hub 集群中的隔离状态，将 <drcluster_name> 替换为唯一名称。

      $ oc get drcluster.ramendr.openshift.io <drcluster_name> -o jsonpath='{.status.phase}{"\n"}'

      输出示例：

      Unfenced

   5. 验证属于 OpenShift Container Platform 集群节点的 IP 不在 blocklist 中。

      $ ceph osd blocklist ls

      确保您没有看到隔离过程中添加的 IP。

2. 在 Hub 集群中，进入到 Applications。
3. 点应用程序行末尾的 Actions 菜单，以查看可用操作的列表。
4. 点 Relocate application。
5. 当 Relocate application 模态显示时，选择 policy 和 target cluster，在出现灾难时相关的应用程序将重新定位到其中。
6. 点 Initiate。busybox 资源现在在目标集群上创建。
7. 关闭模态窗口，并使用 Applications 页面中的 Data policies 列跟踪状态。

8. 验证应用程序的活动状态是否显示为 Relocated。

   1. 进入 Applications → Overview 选项卡。
   2. 在 Data policy 列中，点您要将策略应用到的应用程序的策略链接。
   3. 在 Data policy 弹出窗口中，验证您可以看到一个或多个策略名称以及与应用程序一起使用的策略关联的重新定位状态。

流程

1. 在 Hub 集群中 执行以下步骤：

   1. 使用 CLI 终端编辑 DRCluster 资源来隔离替换集群，其中 < drcluster_name&gt; 是替换集群名称。

      oc edit drcluster <drcluster_name>

      apiVersion: ramendr.openshift.io/v1alpha1
      kind: DRCluster
      metadata:
      [...]
      spec:
        ## Add or modify this line
        clusterFence: Fenced
        cidrs:
        [...]
      [...]

   2. 使用 RHACM 控制台，进入到 Applications，并将所有受保护的应用程序从故障集群故障转移到存活的集群。

   3. 验证并确保所有受保护的应用程序现在都在存活的集群中运行。

      注意

      每个应用程序 DRPlacementControl 的 PROGRESSION 状态将显示为 Cleaning Up。如果替换集群离线或关闭，则这是预期的。

2. 取消隔离替换群集。

   使用 CLI 终端，编辑 DRCluster 资源，其中 &lt ;drcluster_name& gt; 是替换集群名称。

   $ oc edit drcluster <drcluster_name>

   apiVersion: ramendr.openshift.io/v1alpha1
   kind: DRCluster
   metadata:
   [...]
   spec:
     ## Modify this line
     clusterFence: Unfenced
     cidrs:
     [...]
   [...]

3. 删除替换集群的 DRCluster。

   $ oc delete drcluster <drcluster_name> --wait=false

   注意

   使用 --wait=false，因为 DRCluster 在稍后的步骤前不会删除。

4. 在 Surviving 集群中为每个受保护的应用程序禁用 Hub 集群上的灾难恢复。

   1. 对于每个应用程序，编辑放置并确保选择了 Surviving 集群。

      注意

      对于基于 Subscription 的应用程序，相关的放置可以在与受管集群类似的 hub 集群上的同一命名空间中找到。对于基于 ApplicationSets 的应用程序，相关的放置可在 hub 集群的 openshift-gitops 命名空间中找到。

      $ oc edit placement <placement_name> -n <namespace>

      apiVersion: cluster.open-cluster-management.io/v1beta1
      kind: Placement
      metadata:
      annotations:
        cluster.open-cluster-management.io/experimental-scheduling-disable: "true"
      [...]
      spec:
      clusterSets:
      - submariner
      predicates:
      - requiredClusterSelector:
          claimSelector: {}
          labelSelector:
            matchExpressions:
            - key: name
              operator: In
              values:
              - cluster1  <-- Modify to be surviving cluster name
      [...]

   2. 在每个受保护的应用程序的 VolumeReplicationGroup 上运行以下命令来验证为替换集群删除了 s3Profile。

      $ oc get vrg -n <application_namespace> -o jsonpath='{.items[0].spec.s3Profiles}' | jq

   3. 在将受保护的应用程序 放置资源 配置为使用 Surviving 集群，并替换集群 s3Profile (s)从受保护的应用程序中删除后，所有 DRPlacementControl 资源都必须从 Hub 集群中删除。

      $ oc delete drpc <drpc_name> -n <namespace>

      注意

      对于基于 Subscription 的应用程序，相关的 DRPlacementControl 可以在与 hub 集群上的受管集群相同的命名空间中找到。对于基于 ApplicationSets 的应用程序，相关的 DRPlacementControl 可以在 hub 集群的 openshift-gitops 命名空间中找到。

   4. 验证所有 DRPlacementControl 资源是否已删除，然后继续下一步。此命令是所有命名空间的查询。应该没有找到资源。

      $ oc get drpc -A

   5. 最后一步是编辑每个应用程序 放置 并删除注解 cluster.open-cluster-management.io/experimental-scheduling-disable: "true "。

      $ oc edit placement <placement_name> -n <namespace>

      apiVersion: cluster.open-cluster-management.io/v1beta1
      kind: Placement
      metadata:
      annotations:
        ## Remove this annotation
        cluster.open-cluster-management.io/experimental-scheduling-disable: "true"
      [...]

5. 在存活集群中，重复上一步中详述的流程，以及每个受保护应用程序的子步骤。为受保护的应用程序禁用 DR 现已完成。

6. 在 Hub 集群中，运行以下脚本从 存活 集群和 hub 集群中删除所有灾难恢复配置。

   #!/bin/bash
   secrets=$(oc get secrets -n openshift-operators | grep Opaque | cut -d" " -f1)
   echo $secrets
   for secret in $secrets
   do
       oc patch -n openshift-operators secret/$secret -p '{"metadata":{"finalizers":null}}' --type=merge
   done
   mirrorpeers=$(oc get mirrorpeer -o name)
   echo $mirrorpeers
   for mp in $mirrorpeers
   do
       oc patch $mp -p '{"metadata":{"finalizers":null}}' --type=merge
       oc delete $mp
   done
   drpolicies=$(oc get drpolicy -o name)
   echo $drpolicies
   for drp in $drpolicies
   do
       oc patch $drp -p '{"metadata":{"finalizers":null}}' --type=merge
       oc delete $drp
   done
   drclusters=$(oc get drcluster -o name)
   echo $drclusters
   for drp in $drclusters
   do
       oc patch $drp -p '{"metadata":{"finalizers":null}}' --type=merge
       oc delete $drp
   done
   oc delete project openshift-operators
   managedclusters=$(oc get managedclusters -o name | cut -d"/" -f2)
   echo $managedclusters
   for mc in $managedclusters
   do
       secrets=$(oc get secrets -n $mc | grep multicluster.odf.openshift.io/secret-type | cut -d" " -f1)
       echo $secrets
       for secret in $secrets
       do
           set -x
           oc patch -n $mc secret/$secret -p '{"metadata":{"finalizers":null}}' --type=merge
           oc delete -n $mc secret/$secret
       done
   done
   
   oc delete clusterrolebinding spoke-clusterrole-bindings

   注意

   此脚本使用 oc delete project openshift-operators 命令来删除 hub 集群上的这个命名空间中的灾难恢复(DR) Operator。如果在这个命名空间中存在其他非DR operator，则必须从 OperatorHub 再次安装它们。

7. 再次创建命名空间 openshift-operators 后，添加监控标签以收集灾难恢复指标。

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

8. 在 Surviving 集群中，确保删除在 DR 安装期间创建的对象存储桶。如果对象存储桶没有被脚本删除，请删除它。用于 DR 的对象存储桶的名称以 odrbucket 开始。

   $ oc get obc -n openshift-storage

9. 在 RHACM 控制台中，进入到 Infrastructure → Clusters 视图。

   1. 分离替换集群。
   2. 创建新的 OpenShift 集群（恢复集群），并将新集群导入到 RHACM 控制台。具体步骤请参阅创建集群并将 目标受管集群导入到 hub 集群。

10. 在恢复集群中安装 OpenShift Data Foundation 操作器，并将它连接到与存活集群相同的外部 Ceph 存储系统。具体步骤请参考 以外部模式部署 OpenShift Data Foundation。

    注意

    确保 OpenShift Data Foundation 版本为 4.15 （或更高），并且同一版本的 OpenShift Data Foundation 位于存活集群中。

11. 在 hub 集群中，从 OperatorHub 安装 ODF Multicluster Orchestrator operator。具体步骤，请参阅安装 OpenShift Data Foundation Multicluster Orchestrator operator 的章节。

12. 使用 RHACM 控制台，导航到 Data Services → Data policies。

    1. 选择 Create DRPolicy 并为您的策略命名。
    2. 选择 恢复 群集和 存活集群。
    3. 创建策略。具体步骤请查看在 Hub 集群上创建灾难恢复策略 一章。

    只有在 DRPolicy 状态变为 Validated 后，继续下一步。

13. 将 DRPolicy 应用到最初在替换集群失败前保护的存活集群中的应用程序。
14. 将新受保护的应用重新定位到存活群集上，返回到新的恢复（主）集群。使用 RHACM 控制台，进入到 Applications 菜单来执行重新定位。

1. 确保满足作为 DR 解决方案的三个集群（Hub、Primary 和 Secondary Openshift Container Platform）集群的要求。请参阅启用区域DR 的要求。
2. 安装 OpenShift Data Foundation operator，并在 Primary 和 Secondary 受管集群上创建存储系统。请参阅 在受管集群上创建 OpenShift Data Foundation 集群。
3. 在 Hub 集群上安装 ODF Multicluster Orchestrator。请参阅在 Hub 集群上安装 ODF 多集群编排器。
4. 配置 Hub、Primary 和 Secondary 集群之间的 SSL 访问。请参阅配置跨集群的 SSL 访问。

5. 创建 DRPolicy 资源，以用于在跨 Primary 和 Secondary 应用程序所需的 DR 保护的应用程序。请参阅在 Hub 集群上创建灾难恢复策略。

   注意

   可以有多个策略。

6. 测试您的灾难恢复解决方案：

   1. 基于订阅的应用程序 ：

      • 创建基于订阅的应用程序。请参阅 创建示例应用程序。
      • 使用受管集群之间的基于订阅的示例应用程序测试故障切换和重新定位操作。请参阅基于订阅的应用程序故障切换 和 重新定位基于订阅的应用程序。

   2. 基于 ApplicationSet 的应用程序：

      • 创建示例应用程序。请参阅 创建基于 ApplicationSet 的应用程序。
      • 在受管集群之间使用示例应用程序测试故障切换和重定位操作。请参阅 基于 ApplicationSet 的应用程序故障切换和 重新定位基于 ApplicationSet 的应用程序。

流程

1. 在每个受管集群中，安装和配置最新的 OpenShift Data Foundation 集群。

   如需有关 OpenShift Data Foundation 部署的信息，请参阅基础架构特定的部署指南 （如 AWS、VMware、Bare metal、Azure）。

   注意

   在创建存储集群时，在 数据保护 步骤中，您必须选择 Prepare cluster for disaster recovery (Regional-DR only) 复选框。

2. 使用以下命令验证每个受管集群中 OpenShift Data Foundation 部署是否成功：

   $ oc get storagecluster -n openshift-storage ocs-storagecluster -o jsonpath='{.status.phase}{"\n"}'

   对于 Multicloud 网关(MCG)：

   $ oc get noobaa -n openshift-storage noobaa -o jsonpath='{.status.phase}{"\n"}'

   如果状态结果是 Ready，用于主受管集群和二级受管集群上的查询，则继续执行下一步。

3. 在 OpenShift Web 控制台中，进入到 Installed Operators → OpenShift Data Foundation → Storage System → ocs-storagecluster-storagesystem → Resources，并验证 StorageCluster 的 Status 是否为 Ready，并在其旁边有一个绿色勾号标记。

4. [可选] 如果在安装 Submariner 时启用了 Globalnet，然后在 OpenShift Data Foundation 安装完成后编辑 StorageCluster。

   对于 Globalnet 网络，手动编辑 StorageCluster yaml 以添加 clusterID 并将 enabled 设置为 true。将 <clustername> 替换为您的 RHACM 导入或新创建的受管集群名称。在主受管集群和次受管集群中编辑 StorageCluster。

   警告

   不要在 StorageCluster 中进行这个更改，除非您在安装 Submariner 时启用了 Globalnet。

   $ oc edit storagecluster -o yaml -n openshift-storage

   spec:
     network:
       multiClusterService:
         clusterID: <clustername>
         enabled: true

5. 进行上述更改后，

   1. 等待 OSD pod 重启，并且创建 OSD 服务。
   2. 等待所有 MONS 故障转移。

   3. 确保已导出 MONS 和 OSD 服务。

      $ oc get serviceexport -n openshift-storage

      NAME              AGE
      rook-ceph-mon-d   4d14h
      rook-ceph-mon-e   4d14h
      rook-ceph-mon-f   4d14h
      rook-ceph-osd-0   4d14h
      rook-ceph-osd-1   4d14h
      rook-ceph-osd-2   4d14h

   4. 确保集群处于 Ready 状态，集群健康状态有一个绿色勾号表示 Health ok。使用第 3 步进行验证。

流程

1. 在 Hub 集群中，进入到 OperatorHub 并使用关键字过滤器搜索 ODF Multicluster Orchestrator。
2. 点 ODF Multicluster Orchestrator 标题。

3. 保留所有默认设置，然后点安装。

   确保 operator 资源安装在 openshift-operators 中，并可用于所有命名空间。

   注意

   ODF Multicluster Orchestrator 还会在 RHACM hub 集群上作为依赖项安装 Openshift DR Hub Operator。

4. 验证 Operator Pod 处于 Running 状态。OpenShift DR Hub operator 也安装在 openshift-operators 命名空间中。

   $ oc get pods -n openshift-operators

   输出示例：

   NAME                                        READY   STATUS       RESTARTS    AGE
   odf-multicluster-console-6845b795b9-blxrn   1/1     Running      0           4d20h
   odfmo-controller-manager-f9d9dfb59-jbrsd    1/1     Running      0           4d20h
   ramen-hub-operator-6fb887f885-fss4w         2/2     Running      0           4d20h

步骤

1. 提取主受管集群的入口证书，并将输出保存到 primary.crt。

   $ oc get cm default-ingress-cert -n openshift-config-managed -o jsonpath="{['data']['ca-bundle\.crt']}" > primary.crt

2. 提取二级受管集群的入口证书，并将输出保存到 secondary.crt。

   $ oc get cm default-ingress-cert -n openshift-config-managed -o jsonpath="{['data']['ca-bundle\.crt']}" > secondary.crt

3. 创建新的 ConfigMap 文件，以使用文件名 cm-clusters-crt.yaml 来保存远程集群的证书捆绑包。

   注意

   如本示例文件所示，每个集群可能有超过三个证书。另外，请确保在从之前创建的 primary.crt 和 secondary.crt 文件中复制并粘贴后，证书内容会被正确缩进。

   apiVersion: v1
   data:
     ca-bundle.crt: |
       -----BEGIN CERTIFICATE-----
       <copy contents of cert1 from primary.crt here>
       -----END CERTIFICATE-----
   
       -----BEGIN CERTIFICATE-----
       <copy contents of cert2 from primary.crt here>
       -----END CERTIFICATE-----
   
       -----BEGIN CERTIFICATE-----
       <copy contents of cert3 primary.crt here>
       -----END CERTIFICATE----
   
       -----BEGIN CERTIFICATE-----
       <copy contents of cert1 from secondary.crt here>
       -----END CERTIFICATE-----
   
       -----BEGIN CERTIFICATE-----
       <copy contents of cert2 from secondary.crt here>
       -----END CERTIFICATE-----
   
       -----BEGIN CERTIFICATE-----
       <copy contents of cert3 from secondary.crt here>
       -----END CERTIFICATE-----
   kind: ConfigMap
   metadata:
     name: user-ca-bundle
     namespace: openshift-config

4. 在 Primary 受管集群, Secondary 受管集群, 和 Hub 集群 中创建 ConfigMap。

   $ oc create -f cm-clusters-crt.yaml

   输出示例：

   configmap/user-ca-bundle created

5. 对主受管集群、二级受管集群和 Hub 集群上的默认代理资源进行补丁。

   $ oc patch proxy cluster --type=merge  --patch='{"spec":{"trustedCA":{"name":"user-ca-bundle"}}}'

   输出示例：

   proxy.config.openshift.io/cluster patched

流程

1. 在 OpenShift 控制台中，进入到 All Clusters → Data Services → Data policies。
2. 点 Create DRPolicy。
3. 输入 Policy name。确保每个 DRPolicy 都有一个唯一名称（例如： ocp4bos1-ocp4bos2-5m）。

4. 从与此新策略关联的受管集群列表中选择两个集群。

   注意

   如果您在选择集群后收到错误消息 "OSD not migrate"，请按照 将现有 OSD 迁移到 OpenShift Data Foundation for Regional-DR 集群中优化 OSD 的知识库文章进行操作，然后再继续下一步。

5. 复制策略根据所选的 OpenShift 集群自动设置为 Asynchronous(async)，一个 Sync schedule 选项变为可用。

6. 设置同步调度。

   重要

   对于每个需要的复制间隔，必须使用唯一名称（如 ocp4bos1-ocp4bos2-10m）创建新的 DRPolicy。可以选择同一集群，但 Sync 调度 可以用分钟/小时/天内使用不同的复制间隔配置。最小值为一分钟。

7. 点 Create。

8. 验证 DRPolicy 是否已成功创建。在 Hub 集群中，为创建的每个 DRPolicy 资源运行这个命令，使用您的唯一名称替换 <drpolicy_name>。

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

   输出示例：

   Succeeded

   创建 DRPolicy 时，也会创建两个 DRCluster 资源。验证所有三个资源并且状态显示为 Succeeded 最多需要 10 分钟。

   注意

   DRPolicy 不支持编辑 SchedulingInterval、ReplicationClassSelector、VolumeSnapshotClassSelector 和 DRClusters 字段值。

9. 验证对象存储桶可以从 Hub 集群、Primary 受管集群和 Secondary 受管集群访问。

   1. 获取 Hub 集群上的 DRClusters 的名称。

      $ oc get drclusters

      输出示例：

      NAME        AGE
      ocp4bos1   4m42s
      ocp4bos2   4m42s

   2. 检查 S3 访问每个受管集群上创建的每个存储桶。使用 DRCluster 验证命令，使用您的唯一名称替换 <drcluster_name>。

      注意

      DRClusters 不支持编辑 Region 和 S3ProfileName 字段值。

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

      输出示例：

      Succeeded

      注意

      确保为在 Hub 集群中的两个 DRClusters 运行命令。

10. 验证 OpenShift DR Cluster operator 已成功在 Primary 受管集群和 Secondary 受管集群上成功安装。

    $ oc get csv,pod -n openshift-dr-system

    输出示例：

    NAME                                                                            DISPLAY                         VERSION        REPLACES   PHASE
    clusterserviceversion.operators.coreos.com/odr-cluster-operator.v4.15.0         Openshift DR Cluster Operator   4.15.0                    Succeeded
    clusterserviceversion.operators.coreos.com/volsync-product.v0.8.0               VolSync                         0.8.0                     Succeeded
    
    NAME                                             READY   STATUS    RESTARTS   AGE
    pod/ramen-dr-cluster-operator-6467cf5d4c-cc8kz   2/2     Running   0          3d12h

    您还可以验证 OpenShift DR Cluster Operator 是否在每个受管集群的 OperatorHub 上成功安装。

    注意

    在初始运行时，会自动安装 VolSync operator。VolSync 用于在两个集群之间设置卷复制，以保护基于 CephF 的 PVC。复制功能默认为启用。

11. 验证 OpenShift Data Foundation 镜像 Primary 受管集群和 Secondary 受管集群中的 daemon 健康的状态。

    $ oc get cephblockpool ocs-storagecluster-cephblockpool -n openshift-storage -o jsonpath='{.status.mirroringStatus.summary}{"\n"}'

    输出示例：

    {"daemon_health":"OK","health":"OK","image_health":"OK","states":{}}

    小心

    daemon_health 和 health 从 Warning 变为 OK 可能需要最多 10 分钟。如果状态最终未变为 OK，则使用 RHACM 控制台验证受管集群之间的 Submariner 连接是否仍然处于健康状态。在所有值都变为 OK 之前不要继续。

流程

1. 在 Hub 集群中，进入到 Applications。
2. 点应用程序行末尾的 Actions 菜单，以查看可用操作的列表。
3. 点 Failover application。
4. 在显示了 Failover 应用程序 模态后，选择策略和目标集群，相关的应用程序将在出现灾难时故障转移。

5. 点选择订阅组下拉菜单，验证默认选择或修改此设置。

   默认情况下，选择为应用程序资源复制的订阅组。

6. 检查 Failover readiness 的状态。

   • 如果状态是 Ready 且带有一个绿色勾号，这表示目标集群已就绪，可启动故障转移。继续执行第 7 步。
   • 如果状态是 Unknown 或 Not ready，请等待到状态变为 Ready。
7. 点 Initiate。busybox 应用程序现在故障转移到 Secondary-managed 集群。
8. 关闭模态窗口，并使用 Applications 页面中的 Data policies 列跟踪状态。

9. 验证活动状态是否为应用的 FailedOver。

   1. 进入 Applications → Overview 选项卡。
   2. 在 Data policy 列中，点您要将策略应用到的应用程序的策略链接。
   3. 在 Data policy 弹出窗口中，点 View more details 链接。
   4. 验证您能否看到一个或多个策略名称以及与应用程序中使用的策略关联的持续活动（同步时间和活动状态）。

流程

1. 在 Hub 集群中，进入到 Applications。
2. 点应用程序行末尾的 Actions 菜单，以查看可用操作的列表。
3. 点 Failover application。
4. 显示 Failover 应用程序 模态时，验证显示的详细信息是否正确并检查 Failover readiness 的状态。如果状态是 Ready 且带有绿色勾号，这表示目标集群已准备好故障转移启动。
5. 点 Initiate。busybox 资源现在在目标集群上创建。
6. 关闭模态窗口，并使用 Applications 页面中的 Data policies 列跟踪状态。

7. 验证活动状态是否为应用的 FailedOver。

   1. 进入 Applications → Overview 选项卡。
   2. 在 Data policy 列中，点您要将策略应用到的应用程序的策略链接。
   3. 在 Data policy 弹出窗口中，验证您可以看到一个或多个策略名称以及与应用程序中使用的策略关联的持续活动。

流程

1. 在 Hub 集群中，进入到 Applications。
2. 点应用程序行末尾的 Actions 菜单，以查看可用操作的列表。
3. 点 Relocate application。
4. 当 Relocate application 模态显示时，选择 policy 和 target cluster，在出现灾难时相关的应用程序将重新定位到其中。
5. 默认情况下，选择部署应用程序资源的订阅组。点选择订阅组下拉菜单，验证默认选择或修改此设置。

6. 检查 Relocation readiness 的状态。

   • 如果状态是 Ready 且带有一个绿色勾号，这表示目标集群已准备好重定位来进行启动。继续执行第 7 步。
   • 如果状态是 Unknown 或 Not ready，请等待到状态变为 Ready。
7. 点 Initiate。busybox 资源现在在目标集群上创建。
8. 关闭模态窗口，并使用 Applications 页面中的 Data policies 列跟踪状态。

9. 验证应用程序的活动状态是否显示为 Relocated。

   1. 进入 Applications → Overview 选项卡。
   2. 在 Data policy 列中，点您要将策略应用到的应用程序的策略链接。
   3. 在 Data policy 弹出窗口中，点 View more details 链接。
   4. 验证您能否看到一个或多个策略名称以及与应用程序中使用的策略关联的持续活动（同步时间和活动状态）。

流程

1. 在 Hub 集群中，进入到 Applications。
2. 点应用程序行末尾的 Actions 菜单，以查看可用操作的列表。
3. 点 Relocate application。
4. 当 Relocate application 模态显示时，选择 policy 和 target cluster，在出现灾难时相关的应用程序将重新定位到其中。
5. 点 Initiate。busybox 资源现在在目标集群上创建。
6. 关闭模态窗口，并使用 Applications 页面中的 Data policies 列跟踪状态。

7. 验证应用程序的活动状态是否显示为 Relocated。

   1. 进入 Applications → Overview 选项卡。
   2. 在 Data policy 列中，点您要将策略应用到的应用程序的策略链接。
   3. 在 Data policy 弹出窗口中，验证您可以看到一个或多个策略名称以及与应用程序一起使用的策略关联的重新定位状态。

流程

1. 在 Hub 集群中，进入到 Applications → Overview 选项卡。

2. 在 Data policy 列中，点您要将策略应用到的应用程序的策略链接。

   Data policies modal 页面会出现，每个应用程序所应用的灾难恢复策略数量以及故障转移和重新定位状态。

3. 在 Data policies 模态页面中，点 View more details 链接。

   此时会显示一个详细的 数据策略 模态页面，其中显示策略名称和与应用到应用程序的策略关联的持续活动(Last sync、Activity 状态)。

   在模态页面中报告的 Last sync 时间 代表，表示所有针对应用程序保护的 DR 的卷的最新同步时间。

流程

1. 登录 OpenShift Web 控制台。
2. 点 Operators → OperatorHub。
3. 在 Filter by keyword 框中键入 local storage，从操作器列表中搜索 Local Storage operator 并单击它。

4. 在 Install Operator 页面中设置以下选项：

   1. 将频道更新为 stable。
   2. 安装模式是 A specific namespace on the cluster。
   3. Installed Namespace 为 Operator recommended namespace openshift-local-storage。
   4. 将批准更新为 Automatic。
5. 点 Install。

流程

1. 登录 OpenShift Web 控制台。
2. 点 Operators → OperatorHub。
3. 在 Filter by keyword 框中滚动或键入 OpenShift Data Foundation，以查找 OpenShift Data Foundation Operator。
4. 点 Install。

5. 在 Install Operator 页面中设置以下选项：

   1. 将频道更新为 stable-4.15。
   2. 安装模式是 A specific namespace on the cluster。
   3. Installed Namespace 为 Operator recommended namespace openshift-storage。如果命名空间 openshift-storage 不存在，它会在 Operator 安装过程中创建。

   4. 将 Approval Strategy 选为 Automatic 或 Manual。

      如果选择 Automatic 更新，Operator Lifecycle Manager(OLM)将自动升级 Operator 的运行实例，而无需任何干预。

      如果选择了 手动 更新，则 OLM 会创建一个更新请求。作为集群管理员，您必须手动批准该更新请求，才能将 Operator 更新至更新的版本。

6. 确保为 Console 插件 选择了 Enable 选项。
7. 点 Install。

流程

1. 在 OpenShift Web 控制台中，点 Operators → Installed Operators 查看所有已安装的 Operator。

   确保所选 项目 为 openshift-storage。

2. 单击 OpenShift Data Foundation 操作器，然后单击 Create StorageSystem。
3. 在 Backing storage 页面中，选择 Create a new StorageClass using the local storage devices 选项。

4. 点击 Next。

   重要

   如果还没有安装，系统会提示您安装 Local Storage Operator。点 Install 并按照 Installing Local Storage Operator 中所述的步骤进行操作。

5. 在 Create local volume set 页面中，提供以下信息：

   1. 为 LocalVolumeSet 和 StorageClass 输入一个名称。

      默认情况下，存储类名称会出现本地卷集名称。您可以更改名称。

   2. 选择以下任意一项：

      • 所有节点上的磁盘

        使用与所有节点上所选过滤器匹配的可用磁盘。

      • 所选节点上的磁盘

        仅在所选节点上使用与所选过滤器匹配的可用磁盘。

        重要

        如果选择的节点与 OpenShift Data Foundation 的一个聚合的 30 个 CPU 和 72 GiB RAM 的要求不匹配，则会部署一个最小的集群。

        如需最低起始节点要求，请参阅 规划指南中的资源要求部分。

   3. 选择 SSD 或 NVMe 来构建受支持的配置。您可以为不支持的测试安装选择 HDD。

   4. 展开 Advanced 部分并设置以下选项：

      卷模式	默认会选择块。
      设备类型	从下拉列表中选择一个或多个设备类型。
      磁盘大小	为设备设置最小 100GB 大小，以及需要包含的设备的最大可用大小。
      磁盘限制上限	这表示节点上可以创建的 PV 数量上限。如果此字段留空，则为匹配节点上的所有可用磁盘创建 PV。

   5. 点击 Next。

      此时会显示一个用于确认创建 LocalVolumeSet 的弹出窗口。

   6. 单击 Yes 以继续。

6. 在 Capacity 和 nodes 页面中，配置以下内容：

   1. 可用的原始容量会根据与存储类关联的所有附加磁盘填充容量值。这将需要一些时间才能出现。

      Selected nodes 列表根据存储类显示节点。

   2. 如果要使用扩展集群，选择 Enable arbiter 复选框。这个选项只有在满足仲裁程序的所有先决条件并且填充了所选节点时才可用。如需更多信息，请参阅启用扩展集群 的要求中的 Arbiter 扩展集群 要求。

      从下拉列表中选择 arbiter 区域。

7. 为 配置性能选择性能配置集。

   您还可以使用 StorageSystems 选项卡的选项菜单中的 Configure performance 选项，在部署后配置性能配置集。

   重要

   在选择资源配置集前，请确保检查集群中资源的当前可用性。在资源不足的集群中选择较高的资源配置集可能会导致安装失败。有关资源要求的更多信息，请参阅 性能配置集的资源要求。

   1. 点击 Next。

8. 可选：在 Security and network 页面中，根据您的要求进行配置：

   1. 若要启用加密，可选择为块存储和文件存储启用数据加密。

   2. 选择以下加密级别之一：

      • Cluster-wide encryption 来加密整个集群（块存储和文件存储）。
      • Storage class encryption 以使用加密启用的存储类创建加密的持久性卷（仅限块）。

   3. 可选：选择 Connect to an external key management service 复选框。这是集群范围加密的可选选项。

      1. 从 Key Management Service Provider 下拉列表中，选择 Vault 或 Thales CipherTrust Manager (using KMIP)。如果选择了 Vault，请进入下一步。如果您选择了 Thales CipherTrust Manager （using KMIP），请转到步骤 iii。

      2. 选择身份验证方法。

         使用令牌验证方法

         • 输入唯一的连接名称 , Vault 服务器的主机地址（'https://<hostname 或 ip>'），端口号和令牌。

         • 展开 Advanced Settings，以根据您的 Vault 配置输入其他设置和证书详情：

           • 在后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
           • （可选）输入 TLS 服务器名称和 Vault Enterprise 命名空间。
           • 上传对应的 PEM 编码证书文件，以提供 CA 证书、客户端证书和客户端私钥。
           • 点 Save 并跳过步骤 iv。

         使用 Kubernetes 验证方法

         • 输入唯一的 Vault Connection Name, Vault 服务器的主机地址（'https://<hostname 或 ip>'）、端口号和角色名称。

         • 展开 Advanced Settings，以根据您的 Vault 配置输入其他设置和证书详情：

           • 在后端路径中输入为 OpenShift Data Foundation 专用且唯一的 Key Value secret 路径。
           • 可选：输入 TLS Server Name 和 Authentication Path （如果适用）。
           • 上传对应的 PEM 编码证书文件，以提供 CA 证书、客户端证书和客户端私钥。
           • 点 Save 并跳过步骤 iv。

      3. 要使用 Thales CipherTrust Manager (using KMIP) 作为 KMS 供应商，请按照以下步骤执行：

         1. 在项目中输入密钥管理服务的唯一连接名称。

         2. 在 Address 和 Port 部分中，输入 Thales CipherTrust Manager 的 IP 以及在其中启用了 KMIP 接口的端口。例如：

            • 地址: 123.34.3.2
            • 端口 ：5696
         3. 上传 客户端证书、CA 证书和 客户端私钥。
         4. 如果启用了 StorageClass 加密，请输入用于加密和解密的唯一标识符。
         5. TLS Server 字段是可选的，并在没有 KMIP 端点的 DNS 条目时使用。例如，kmip_all_<port>.ciphertrustmanager.local。

   4. 如果您使用 单个网络，则 network 设置为 Default (OVN)。

      如果您使用多个网络接口，您可以切换到 Custom (Multus)，然后选择以下任一网络接口：

      1. 从下拉菜单中选择公共网络接口。
      2. 从下拉菜单中选择集群网络接口。
   注意

   如果您只使用一个额外网络接口，请选择单个 NetworkAttachementDefinition，即 ocs-public-cluster 用于公共网络接口，并将 Cluster Network Interface 留空。

   1. 点击 Next。
9. 在 Data Protection 页面中，点 Next。

10. 在 Review and create 页面中，检查配置详情。

    若要修改任何配置设置，请单击 Back 以返回到上一配置页面。

11. 单击 Create StorageSystem。

1. 创建一个新项目。

   $ oc new-project my-shared-storage

2. 部署名为 file-uploader 的示例 PHP 应用。

   $ oc new-app openshift/php:latest~https://github.com/mashetty330/openshift-php-upload-demo --name=file-uploader

   输出示例：

   Found image 4f2dcc0 (9 days old) in image stream "openshift/php" under tag "7.2-ubi8" for "openshift/php:7.2-
   ubi8"
   
   Apache 2.4 with PHP 7.2
   -----------------------
   PHP 7.2 available as container is a base platform for building and running various PHP 7.2 applications and frameworks. PHP is an HTML-embedded scripting language. PHP attempts to make it easy for developers to write dynamically generated web pages. PHP also offers built-in database integration for several commercial and non-commercial database management systems, so writing a database-enabled webpage with PHP is fairly simple. The most common
   use of PHP coding is probably as a replacement for CGI scripts.
   
   Tags: builder, php, php72, php-72
   
   * A source build using source code from https://github.com/christianh814/openshift-php-upload-demo will be cr
   eated
   * The resulting image will be pushed to image stream tag "file-uploader:latest"
   * Use 'oc start-build' to trigger a new build
   
   --> Creating resources ...
       imagestream.image.openshift.io "file-uploader" created
       buildconfig.build.openshift.io "file-uploader" created
       deployment.apps "file-uploader" created
       service "file-uploader" created
   --> Success
       Build scheduled, use 'oc logs -f buildconfig/file-uploader' to track its progress.
   
       Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
        'oc expose service/file-uploader'
   
       Run 'oc status' to view your app.

3. 查看构建日志并等待应用部署好。

   $ oc logs -f bc/file-uploader -n my-shared-storage

   输出示例：

   Cloning "https://github.com/christianh814/openshift-php-upload-demo" ...
   
       [...]
       Generating dockerfile with builder image image-registry.openshift-image-regis
   try.svc:5000/openshift/php@sha256:d97466f33999951739a76bce922ab17088885db610c
   0e05b593844b41d5494ea
   STEP 1: FROM image-registry.openshift-image-registry.svc:5000/openshift/php@s
   ha256:d97466f33999951739a76bce922ab17088885db610c0e05b593844b41d5494ea
   STEP 2: LABEL "io.openshift.build.commit.author"="Christian Hernandez <christ
   ian.hernandez@yahoo.com>"       "io.openshift.build.commit.date"="Sun Oct 1 1
   7:15:09 2017 -0700"       "io.openshift.build.commit.id"="288eda3dff43b02f7f7
   b6b6b6f93396ffdf34cb2"       "io.openshift.build.commit.ref"="master"       "
   io.openshift.build.commit.message"="trying to modularize"       "io.openshift
   .build.source-location"="https://github.com/christianh814/openshift-php-uploa
   d-demo"       "io.openshift.build.image"="image-registry.openshift-image-regi
   stry.svc:5000/openshift/php@sha256:d97466f33999951739a76bce922ab17088885db610
   c0e05b593844b41d5494ea"
   STEP 3: ENV OPENSHIFT_BUILD_NAME="file-uploader-1"     OPENSHIFT_BUILD_NAMESP
   ACE="my-shared-storage"     OPENSHIFT_BUILD_SOURCE="https://github.com/christ
   ianh814/openshift-php-upload-demo"     OPENSHIFT_BUILD_COMMIT="288eda3dff43b0
   2f7f7b6b6b6f93396ffdf34cb2"
   STEP 4: USER root
   STEP 5: COPY upload/src /tmp/src
   STEP 6: RUN chown -R 1001:0 /tmp/src
   STEP 7: USER 1001
   STEP 8: RUN /usr/libexec/s2i/assemble
   ---> Installing application source...
   => sourcing 20-copy-config.sh ...
   ---> 17:24:39     Processing additional arbitrary httpd configuration provide
   d by s2i ...
   => sourcing 00-documentroot.conf ...
   => sourcing 50-mpm-tuning.conf ...
   => sourcing 40-ssl-certs.sh ...
   STEP 9: CMD /usr/libexec/s2i/run
   STEP 10: COMMIT temp.builder.openshift.io/my-shared-storage/file-uploader-1:3
   b83e447
   Getting image source signatures
   
   [...]

   当您看到 Push successful 后，命令提示符会从 tail 模式返回。

   注意

   new-app 命令直接从 git 存储库部署应用，而不使用 OpenShift 模板，因此默认情况下不创建 OpenShift 路由资源。您需要手动创建路线。

扩展应用程序

1. 将应用缩放为四个副本，并公开其服务，使应用区域了解和可用。

   $ oc expose svc/file-uploader -n my-shared-storage

   $ oc scale --replicas=4 deploy/file-uploader -n my-shared-storage

   $ oc get pods -o wide -n my-shared-storage

   几分钟后，您应该有四个 file-uploader pod。重复上述命令，直到有 4 个文件加载程序容器集处于 Running 状态。

2. 创建 PVC 并将其附加到应用程序中。

   $ oc set volume deploy/file-uploader --add --name=my-shared-storage \
   -t pvc --claim-mode=ReadWriteMany --claim-size=10Gi \
   --claim-name=my-shared-storage --claim-class=ocs-storagecluster-cephfs \
   --mount-path=/opt/app-root/src/uploaded \
   -n my-shared-storage

   这个命令：

   • 创建 PVC。
   • 更新应用部署，以包含卷定义。
   • 更新应用部署，将卷挂载附加到指定的 mount-path 中。
   • 使用四个应用 pod 创建一个新部署。

3. 检查添加卷的结果。

   $ oc get pvc -n my-shared-storage

   输出示例：

   NAME                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                AGE
   my-shared-storage   Bound    pvc-5402cc8a-e874-4d7e-af76-1eb05bd2e7c7   10Gi       RWX            ocs-storagecluster-cephfs   52s

   注意 ACCESS MODE 已设置为 RWX。

   所有四个 file-uploader pod 都使用相同的 RWX 卷。如果没有这种访问模式，OpenShift 不会尝试可靠地将多个容器集附加到同一持久卷(PV)。如果您试图扩展正在使用 ReadWriteOnce(RWO) PV 的部署，则 pod 可能会在同一节点上在一起。

流程

1. 在 Hub 集群中，打开一个终端窗口

2. 将以下标签添加到 openshift-operator 命名空间。

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

流程

1. 在 Hub 集群中，打开终端窗口并执行以下步骤。

2. 创建名为 observability-metrics-custom-allowlist.yaml 的 configmap 文件。

   您可以使用以下 YAML 列出 Hub 集群上的灾难恢复指标。详情请参阅 添加自定义指标。要了解有关帧指标的更多信息，请参阅 灾难恢复指标。

   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: observability-metrics-custom-allowlist
     namespace: open-cluster-management-observability
   data:
     metrics_list.yaml: |
       names:
         - ceph_rbd_mirror_snapshot_sync_bytes
         - ceph_rbd_mirror_snapshot_snapshots
       matches:
         - __name__="csv_succeeded",exported_namespace="openshift-dr-system",name=~"odr-cluster-operator.*"
         - __name__="csv_succeeded",exported_namespace="openshift-operators",name=~"volsync.*"

3. 在 open-cluster-management-observability 命名空间中运行以下命令：

   $ oc apply -n open-cluster-management-observability -f observability-metrics-custom-allowlist.yaml

4. 创建 observability-metrics-custom-allowlist yaml 后，RHACM 将开始从所有受管集群收集列出的 OpenShift Data Foundation 指标。

   要排除特定受管集群来收集可观察性数据，请在集群中添加以下集群标签 clusters: observability: disabled。

流程

1. 在 Hub 集群中，确保选择了 All Clusters 选项。
2. 刷新控制台，使 DR 监控仪表板标签页可以访问。
3. 进入 Data Services 并点 Data policies。
4. 在 Overview 选项卡中，您可以查看 operator、集群和应用程序的健康状态。绿色勾号表示操作器正在运行且可用。
5. 点 Disaster recovery 选项卡查看 DR 策略详情和连接的应用程序列表。