Metro-DR 向け Advanced Cluster Management と OpenShift Data Foundation の設定

手順

1. ceph mon dump コマンドを使用して、モニターが使用している現在の選挙戦略を確認します。ceph クラスターのデフォルトでは、接続はクラシックに設定されています。

   ceph mon dump | grep election_strategy

   出力例:

   dumped monmap epoch 9
   election_strategy: 1

2. モニターの選択を接続に変更します。

   ceph mon set election_strategy connectivity

3. 前の cephmondump コマンドを再度実行して、election_strategy 値を確認します。

   $ ceph mon dump | grep election_strategy

   出力例:

   dumped monmap epoch 10
   election_strategy: 3

   さまざまな選択戦略の詳細については、Configuring monitor election strategy を参照してください。

4. すべての Ceph モニターの場所を設定します。

   ceph mon set_location ceph1 datacenter=DC1
   ceph mon set_location ceph2 datacenter=DC1
   ceph mon set_location ceph4 datacenter=DC2
   ceph mon set_location ceph5 datacenter=DC2
   ceph mon set_location ceph7 datacenter=DC3

5. 各モニターに適切な場所があることを確認します。

   $ ceph mon dump

   出力例:

   epoch 17
   fsid dd77f050-9afe-11ec-a56c-029f8148ea14
   last_changed 2022-03-04T07:17:26.913330+0000
   created 2022-03-03T14:33:22.957190+0000
   min_mon_release 16 (pacific)
   election_strategy: 3
   0: [v2:10.0.143.78:3300/0,v1:10.0.143.78:6789/0] mon.ceph1; crush_location {datacenter=DC1}
   1: [v2:10.0.155.185:3300/0,v1:10.0.155.185:6789/0] mon.ceph4; crush_location {datacenter=DC2}
   2: [v2:10.0.139.88:3300/0,v1:10.0.139.88:6789/0] mon.ceph5; crush_location {datacenter=DC2}
   3: [v2:10.0.150.221:3300/0,v1:10.0.150.221:6789/0] mon.ceph7; crush_location {datacenter=DC3}
   4: [v2:10.0.155.35:3300/0,v1:10.0.155.35:6789/0] mon.ceph2; crush_location {datacenter=DC1}

6. crushtool コマンドを使用するために ceph-base RPM パッケージをインストールして、この OSD クラッシュトポロジーを利用する CRUSH ルールを作成します。

   $ dnf -y install ceph-base

   CRUSH ルールセットの詳細については、Ceph CRUSH ruleset を参照してください。

7. コンパイルされた CRUSH マップをクラスターから取得します。

   $ ceph osd getcrushmap > /etc/ceph/crushmap.bin

8. CRUSH マップを逆コンパイルし、これをテキストファイルに変換して編集できるようにします。

   $ crushtool -d /etc/ceph/crushmap.bin -o /etc/ceph/crushmap.txt

9. ファイルの末尾にあるテキストファイル /etc/ceph/crushmap.txt を編集して、以下のルールを CRUSH マップに追加します。

   $ vim /etc/ceph/crushmap.txt

   rule stretch_rule {
           id 1
           type replicated
           min_size 1
           max_size 10
           step take DC1
           step chooseleaf firstn 2 type host
           step emit
           step take DC2
           step chooseleaf firstn 2 type host
           step emit
   }
   
   # end crush map

   注記

   ルール id は一意である必要があります。この例では、id 0 のクラッシュルールがもう 1 つしかないため、id 1 を使用しています。デプロイメントにさらにルールが作成されている場合は、次の空き ID を使用します。

   宣言された CRUSH ルールには、次の情報が含まれています。

   • Rule name:

     • 説明: ルールを識別する一意の完全な名前。
     • 値: stretch_rule

   • id:

     • 説明: ルールを識別する一意の整数。
     • 値: 1

   • type:

     • 説明: レプリケートまたはイレイジャーコーディングされたストレージドライブのルールを説明しています。
     • 値: replicated

   • min_size:

     • 説明: プールがこの数よりも小さいレプリカを使用する場合、CRUSH はこのルールを選択しません。
     • 値: 1

   • max_size:

     • 説明: プールがこの数よりも大きいレプリカを使用する場合、CRUSH はこのルールを選択しません。
     • 値: 10

   • step take DC1

     • 説明: バケット名 (DC1) を取り、ツリーを下ってイテレートを開始します。

   • step chooseleaf firstn 2 type host

     • 説明: 指定のタイプのバケット数を選択します。この例では、DC1 にある 2 つの異なるホストになります。

   • step emit

     • 説明: 現在の値を出力し、スタックを除算します。通常、ルールの最後に使用されますが、同じルール内の異なるツリーを選択する際に使用することもできます。

   • step take DC2

     • 説明: バケット名 (DC2) を取り、ツリーを下ってイテレートを開始します。

   • step chooseleaf firstn 2 type host

     • 説明: 指定のタイプのバケット数を選択します。この例では、DC2 にある 2 つの異なるホストになります。

   • step emit

     • 説明: 現在の値を出力し、スタックを除算します。通常、ルールの最後に使用されますが、同じルール内の異なるツリーを選択する際に使用することもできます。

10. ファイル /etc/ceph/crushmap.txt から新しい CRUSH マップをコンパイルし、これを /etc/ceph/crushmap2.bin というバイナリーファイルに変換します。

    $ crushtool -c /etc/ceph/crushmap.txt -o /etc/ceph/crushmap2.bin

11. 作成した新しいクラッシュマップをクラスターに注入します。

    $ ceph osd setcrushmap -i /etc/ceph/crushmap2.bin

    出力例:

    17

    注記

    数字の 17 はカウンターであり、クラッシュマップに加えた変更に応じて増加します (18、19 など)。

12. 作成したストレッチルールが使用可能になったことを確認します。

    ceph osd crush rule ls

    出力例:

    replicated_rule
    stretch_rule

13. ストレッチクラスターモードを有効にします。

    $ ceph mon enable_stretch_mode ceph7 stretch_rule datacenter

    この例では、ceph7 がアービターノード、stretch_rule が前の手順で作成したクラッシュルール、datacenter が分割バケットです。

14. すべてのプールが、Ceph クラスターに作成した stretch_rule CRUSH ルールを使用していることを確認します。

    $ for pool in $(rados lspools);do echo -n "Pool: ${pool}; ";ceph osd pool get ${pool} crush_rule;done

    出力例:

    Pool: device_health_metrics; crush_rule: stretch_rule
    Pool: cephfs.cephfs.meta; crush_rule: stretch_rule
    Pool: cephfs.cephfs.data; crush_rule: stretch_rule
    Pool: .rgw.root; crush_rule: stretch_rule
    Pool: default.rgw.log; crush_rule: stretch_rule
    Pool: default.rgw.control; crush_rule: stretch_rule
    Pool: default.rgw.meta; crush_rule: stretch_rule
    Pool: rbdpool; crush_rule: stretch_rule

    これは、アービターモードで稼働中の Red Hat Ceph Storage ストレッチクラスターが利用可能になったことを示しています。

1. 各マネージドクラスターに最新の OpenShift Data Foundation をインストールします。

2. Operator のインストール後に、外部ストレージプラットフォームとの接続オプションを使用して StorageSystem を作成します。

   詳しい手順は、外部モードでの OpenShift Data Foundation のデプロイ を参照してください。

3. OpenShift Data Foundation の正常なデプロイメントを検証します。

   1. 各マネージドクラスターで以下のコマンドを実行します。

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

   2. Multicloud Gateway (MCG) の場合:

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

   ステータス結果が Primary managed cluster と Secondary managed cluster の両方のクエリーに対して Ready である場合は、次の手順に進みます。

手順

1. ハブクラスターで OperatorHub に移動し、OpenShift-DR Hub Operator の検索フィルターを使用します。
2. 画面の指示に従って、Operator をプロジェクト openshift-dr-system にインストールします。

3. 次のコマンドを使用して、オペレーター Pod が Running 状態にあることを確認します。

   $ oc get pods -n openshift-dr-system

   出力例:

   NAME                                 	READY   STATUS    RESTARTS   AGE
   ramen-hub-operator-898c5989b-96k65   	2/2     Running   0          4m14s

手順

1. ハブクラスターで、openshift-dr-system プロジェクトで Installed Operators に移動し、OpenShift DR Hub Operator をクリックします。2 つの利用可能な API (DRPolicy と DRPlacementControl) が表示されるはずです。
2. DRPolicy の Create instance をクリックし、YAML view をクリックします。

3. <cluster1> および <cluster2> を RHACM のマネージドクラスターの正しい名前に置き換えてから、以下の YAML を、ファイル名 drpolicy.yaml に保存します。<string_value> を任意の値 (つまり metro) に置き換えます。

   apiVersion: ramendr.openshift.io/v1alpha1
   kind: DRPolicy
   metadata:
     name: odr-policy
   spec:
     drClusterSet:
     - name: <cluster1>
       region: <string_value>
       s3ProfileName: s3-primary
       clusterFence: Unfenced
     - name: <cluster2>
       region: <string_value>
       s3ProfileName: s3-secondary
       clusterFence: Unfenced

   注記

   DRPolicy はクラスタースコープのリソースであるため、このリソースを作成するために namespace を指定する必要はありません。

4. 一意の drpolicy.yaml ファイルの内容を YAML ビューにコピーします。元のコンテンツを完全に置き換える必要があります。
5. YAML ビュー画面の Create をクリックします。

6. DRPolicy が正常に作成され、前に作成したシークレットを使用して MCG オブジェクトバケットにアクセスできることを検証するには、ハブクラスターで次のコマンドを実行します。

   $ oc get drpolicy odr-policy -n openshift-dr-system -o jsonpath='{.status.conditions[].reason}{"\n"}'

   出力例:

   Succeeded

手順

1. ハブクラスターで ConfigMag ramen-hub-operator-config を編集し、次のように deploymentAutomationEnabled=false の値を true に変更します。

   $ oc edit configmap ramen-hub-operator-config -n openshift-dr-system

   apiVersion: v1
   data:
     ramen_manager_config.yaml: |
     [...]
       drClusterOperator:
         deploymentAutomationEnabled: true  ## <-- Change value to "true" if it is set to "false"
         channelName: stable-4.10
         packageName: odr-cluster-operator
         namespaceName: openshift-dr-system
         catalogSourceName: redhat-operators
         catalogSourceNamespaceName: openshift-marketplace
         clusterServiceVersionName: odr-cluster-operator.v4.10.0
   [...]

2. プライマリーマネージドクラスターでインストールが成功したことを確認し、セカンダリーマネージドクラスターで次のコマンドを実行します。

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

   出力例:

   NAME                                                                      DISPLAY                         VERSION   REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/odr-cluster-operator.v4.10.0   Openshift DR Cluster Operator   4.10.0               Succeeded
   
   NAME                                             READY   STATUS    RESTARTS   AGE
   pod/ramen-dr-cluster-operator-5564f9d669-f6lbc   2/2     Running   0          5m32s

   各マネージドクラスターの Operator Hub に移動して、OpenShift DR Cluster Operator がインストールされているかどうかを確認することもできます。

手順

1. 次のように、ハブクラスターの ConfigMag ramen-hub-operator-config 設定を編集して、s3SecretDistributionEnabled=true を追加します。

   $ oc edit configmap ramen-hub-operator-config -n openshift-dr-system

   apiVersion: v1
   data:
     ramen_manager_config.yaml: |
       apiVersion: ramendr.openshift.io/v1alpha1
       drClusterOperator:
         deploymentAutomationEnabled: true
         s3SecretDistributionEnabled: true  ## <-- Add to enable automatic transfer of s3secrets
         catalogSourceName: redhat-operators
         catalogSourceNamespaceName: openshift-marketplace
         channelName: stable-4.10
         clusterServiceVersionName: odr-cluster-operator.v4.10.0
         namespaceName: openshift-dr-system
         packageName: odr-cluster-operator
   [...]

2. 両方のマネージドクラスターでこのコマンドを実行して、シークレットの転送が成功したことを確認します。

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

   出力例:

   8b3fb9ed90f66808d988c7edfa76eba35647092   Opaque        2      11m
   af5f82f21f8f77faf3de2553e223b535002e480   Opaque        2      11m

手順

1. busybox サンプルアプリケーションの ハブクラスター で namespace または プロジェクト を作成します。

   $ oc new-project busybox-sample

   注記

   必要に応じて、busybox-sample 以外のプロジェクト名を使用できます。Advanced Cluster Manager コンソールでサンプルアプリケーションをデプロイする場合は、この手順で作成したものと同じプロジェクト名を使用するようにしてください。

2. DRPlacementControl リソースを作成します。

   DRPlacementControl は、ハブクラスターに OpenShift DR Hub Operator をインストールした後に利用可能な API です。これは、概説としては、DRPolicy の一部であるクラスター間でのデータ可用性に基づいて配置の決定をオーケストレーションする Advanced Cluster Manager PlacementRule リコンサイラーです。

   1. ハブクラスターで、busybox-sample プロジェクトで Installed Operators に移動し、OpenShift DR Hub Operator をクリックします。2 つの利用可能な API (DRPolicy と DRPlacementControl) が表示されるはずです。
   2. DRPlacementControl のインスタンスを作成してから、YAML ビューに移動します。busybox-sample プロジェクトが選択されていることを確認します。

   3. <cluster1> を Advanced Cluster Manager のマネージドクラスターの正しい名前に置き換えたあと、以下の YAML をファイル名 busybox-drpc.yaml にコピーして保存します。

      apiVersion: ramendr.openshift.io/v1alpha1
      kind: DRPlacementControl
      metadata:
        labels:
          app: busybox-sample
        name: busybox-drpc
      spec:
        drPolicyRef:
          name: odr-policy
        placementRef:
          kind: PlacementRule
          name: busybox-placement
        preferredCluster: <cluster1>
        pvcSelector:
          matchLabels:
            appname: busybox

   4. 一意の busybox-drpc.yaml ファイルの内容を YAML ビューにコピーします (元のコンテンツを完全に置き換え)。

   5. YAML ビュー画面の Create をクリックします。

      以下の CLI コマンドを使用してこのリソースを作成することもできます。

      $ oc create -f busybox-drpc.yaml -n busybox-sample

      出力例:

      drplacementcontrol.ramendr.openshift.io/busybox-drpc created

      重要

      このリソースは、busybox-sample namespace (または先に作成した namespace) に作成する必要があります。

3. リソーステンプレートのデプロイ先のターゲットクラスターを定義する Placement Rule リソースを作成します。配置ルールを使用すると、アプリケーションのマルチクラスターデプロイメントが容易になります。

   1. 以下の YAML をファイル名 busybox-placementrule.yaml にコピーし、保存します。

      apiVersion: apps.open-cluster-management.io/v1
      kind: PlacementRule
      metadata:
        labels:
          app: busybox-sample
        name: busybox-placement
      spec:
        clusterConditions:
        - status: "True"
          type: ManagedClusterConditionAvailable
        clusterReplicas: 1
        schedulerName: ramen

   2. busybox-sample アプリケーションの PlacementRule リソースを作成します。

      $ oc create -f busybox-placementrule.yaml -n busybox-sample

      出力例:

      placementrule.apps.open-cluster-management.io/busybox-placement created

      重要

      このリソースは、busybox-sample namespace (または先に作成した namespace) に作成する必要があります。

4. RHACM コンソールを使用した サンプルアプリケーション の作成

   1. まだログインしていない場合は、OpenShift 認証情報を使用して RHACM コンソールにログインします。

      $ oc get route multicloud-console -n open-cluster-management -o jsonpath --template="https://{.spec.host}/multicloud/applications{'\n'}"

      出力例:

      https://multicloud-console.apps.perf3.example.com/multicloud/applications

   2. Applications に移動し、Create application をクリックします。
   3. 種類は Subscriptionを選択します。
   4. アプリケーションの Name (busybox など) および Namespace (busybox-sample など) を入力します。
   5. Repository location for resources セクションで Repository type Git を選択します。

   6. サンプルアプリケーションの github Branch および Path で、 Git リポジトリー URL を入力します。リソース busybox Pod および PVC が作成されます。

      Branch が main で、Path は busybox-odr-metro である https://github.com/RamenDR/ocm-ramen-samples として、サンプルアプリケーションリポジトリーを使用します。

   7. Select clusters to deploy to セクションまでフォームを下にスクロールして、Select an existing placement configuration をクリックします。
   8. ドロップダウンリストから Existing Placement Rule (busybox-placement など) を選択します。

   9. Save をクリックします。

      次に表示される画面で下部までスクロールします。アプリケーショントポロジーのチェックマークがすべて緑であることが確認できるはずです。

      注記

      詳細な情報を表示するには、トポロジー要素のいずれかをクリックすると、トポロジービューの右側にウィンドウが表示されます。

5. サンプルアプリケーションのデプロイメントおよびレプリケーションを確認します。

   busybox アプリケーションが (DRPlacementControl で指定された) preferredCluster にデプロイされたので、デプロイメントを検証できるようになりました。

   1. busybox が RHACM によってデプロイされたマネージドクラスターにログオンします。

      $ oc get pods,pvc -n busybox-sample

      出力例:

      NAME          READY   STATUS    RESTARTS   AGE
      pod/busybox   1/1     Running   0          6m
      
      NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
      persistentvolumeclaim/busybox-pvc   Bound    pvc-a56c138a-a1a9-4465-927f-af02afbbff37   1Gi        RWO            ocs-storagecluster-ceph-rbd   6m

   2. レプリケーションリソースも busybox PVC に作成されていることを確認します。

      $ oc get volumereplicationgroup -n busybox-sample

      出力例:

      NAME                                                       AGE
      volumereplicationgroup.ramendr.openshift.io/busybox-drpc   6m

手順

1. NetworkFence リソースを作成し、フェンシングを有効にします。

   ネットワークフェンシング操作が実行される CIDR ブロックまたは IP アドレスのリストを指定します。この場合は、外部 RHCS クラスターの使用からフェンスする必要があるクラスター内にあるすべての OpenShift ノードの EXTERNAL-IP になります。

   1. このコマンドを実行して、プライマリーマネージドクラスター の IP アドレスを取得します。

      $ oc get nodes -o jsonpath='{range .items[*]}{.status.addresses[?(@.type=="ExternalIP")].address}{"\n"}{end}'

      出力例:

      10.70.56.118
      10.70.56.193
      10.70.56.154
      10.70.56.242
      10.70.56.136
      10.70.56.99

      注記

      サイトが停止する前に、すべての OpenShift ノードの現在の IP アドレスを収集します。ベストプラクティスは、NetworkFence YAML ファイルを作成し、それを障害回復イベントに使用できるようにして最新の状態にすることです。

      以下に示すように、すべてのノードの IP アドレスが NetworkFence サンプルリソースに追加されます。この例は 6 つのノードを対象としていますが、クラスター内にさらに多くのノードが存在する可能性があります。

      apiVersion: csiaddons.openshift.io/v1alpha1
      kind: NetworkFence
      metadata:
        name: network-fence-<cluster1>
      spec:
        driver: openshift-storage.rbd.csi.ceph.com
        cidrs:
          -  <IP_Address1>/32
          -  <IP_Address2>/32
          -  <IP_Address3>/32
          -  <IP_Address4>/32
          -  <IP_Address5>/32
          -  <IP_Address6>/32
          [...]
        secret:
          name: rook-csi-rbd-provisioner
          namespace: openshift-storage
        parameters:
          clusterID: openshift-storage

   2. 上記の YAML ファイルの例では、IP アドレスを変更し、プライマリーマネージドクラスターの RHACM で検出されるクラスター名となる正しい <cluster1> を指定します。これをファイル名 network-fence-<cluster1>.yaml に保存します。

      重要

      NetworkFence は、フェイルオーバーの前に、アプリケーションが現在実行されている反対側のマネージドクラスターから作成する必要があります。この場合はセカンダリーマネージドクラスターです。

      $ oc create -f network-fence-<cluster1>.yaml

      出力例:

      networkfences.csiaddons.openshift.io/network-fence-ocp4perf1 created

      重要

      NetworkFence が作成されると、アプリケーションから OpenShift Data Foundation ストレージへのすべての通信が失敗し、一部の Pod は、現在フェンスでされているクラスター上で異常な状態 (CreateContainerError、CrashLoopBackOff など) になります。

   3. NetworkFence が作成された場所と同じクラスターで、ステータスが Succeeded であることを確認します。<cluster1> を正しく変更します。

      export NETWORKFENCE=network-fence-<cluster1>
      oc get networkfences.csiaddons.openshift.io/$NETWORKFENCE -n openshift-dr-system -o jsonpath='{.status.result}{"\n"}'

      出力例:

      Succeeded

2. fenced クラスターの DRPolicy を変更します。

   1. ハブクラスターの DRPolicy を編集し、<cluster1> (例: ocp4perf1) を Unfenced から ManuallyFenced に変更します。

      $ oc edit drpolicy odr-policy

      出力例:

      [...]
      spec:
        drClusterSet:
        - clusterFence: ManuallyFenced  ## <-- Modify from Unfenced to ManuallyFenced
          name: ocp4perf1
          region: metro
          s3ProfileName: s3-primary
        - clusterFence: Unfenced
          name: ocp4perf2
          region: metro
          s3ProfileName: s3-secondary
      [...]

      出力例:

      drpolicy.ramendr.openshift.io/odr-policy edited

   2. ハブクラスターの DRPolicy ステータスが、プライマリーマネージドクラスターで Fenced に変更されていることを確認します。

      $ oc get drpolicies.ramendr.openshift.io odr-policy -o yaml | grep -A 6 drClusters

      出力例:

        drClusters:
          ocp4perf1:
            status: Fenced
            string: ocp4perf1
          ocp4perf2:
            status: Unfenced
            string: ocp4perf2

3. failover するように DRPlacementControl を変更します

   1. ハブクラスターで Installed Operators に移動し、Openshift DR Hub Operator をクリックします。
   2. DRPlacementControl タブをクリックします。
   3. DRPC busybox-drpc をクリックしてから、YAML ビューをクリックします。

   4. 以下のスクリーンショットのように、action および failoverCluster の詳細を追加します。failoverCluster はセカンダリーマネージドクラスターの ACM クラスター名である必要があります。

      DRPlacementControl add action Failover

      

   5. Save をクリックします。

4. アプリケーションの busybox がセカンダリーマネージドクラスター (YAML ファイルに指定されるフェイルオーバークラスター ocp4perf2) で実行されていることを確認します。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   NAME          READY   STATUS    RESTARTS   AGE
   pod/busybox   1/1     Running   0          35s
   
   NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
   persistentvolumeclaim/busybox-pvc   Bound    pvc-79f2a74d-6e2c-48fb-9ed9-666b74cfa1bb   5Gi        RWO            ocs-storagecluster-ceph-rbd   35s

5. busybox がプライマリーマネージドクラスターで実行していないことを確認します。

   $ oc get pods,pvc -n busybox-sample

   出力例:

   No resources found in busybox-sample namespace.

手順

1. NetworkFence リソースを削除し、Fencing を無効にします。

   フォールバックまたは再配置アクションを成功させる前に、プライマリーマネージドクラスターの NetworkFence を削除する必要があります。

   1. セカンダリーマネージドクラスターでこのコマンドを実行し、前のセクションで作成した NetworkFenceYAML ファイル名に合わせて <cluster1> を変更します。

      $ oc delete -f network-fence-<cluster1>.yaml

      出力例:

      networkfence.csiaddons.openshift.io "network-fence-ocp4perf1" deleted

   2. Fenced になっている OpenShift Container Platform ノードを再起動します。

      以前のフェンスされたクラスター (この場合はプライマリーマネージドクラスター) 上の一部のアプリケーション Pod が異常な状態にあるため (例: CreateContainerError、CrashLoopBackOff)、この手順が必要です。これは、すべてのワーカー OpenShift ノードを一度に 1 つずつ再起動することで最も簡単に修正できます。

      注記

      OpenShift Web Console ダッシュボードと 概要 ページを使用して、アプリケーションと外部ストレージの正常性を評価することもできます。OpenShiftDataFoundation ダッシュボードの詳細は、Storage → Data Foundation に移動すると表示されます。

   3. すべての OpenShift ノードが再起動されてステータスが Ready になった後、プライマリーマネージドクラスターでこのコマンドを実行して、すべての Pod が正常な状態にあることを確認します。このクエリーの出力はゼロ Pod である必要があります。

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

      出力例:

      NAMESPACE                                          NAME                                                              READY   STATUS      RESTARTS       AGE

      重要

      ストレージ通信が切断されたために Pod がまだ異常な状態にある場合は、続行する前にトラブルシューティングを行って解決してください。ストレージクラスターは OpenShift の外部にあるため、OpenShift アプリケーションを正常に動作させるには、サイトの停止後にストレージクラスターを適切に復元する必要もあります。

2. DRPolicy を Unfenced ステータスに変更します。

   ODR HUB 演算子が、プライマリーマネージドクラスターの NetworkFence が削除されたことを知るには、新しい Unfenced クラスターの DRPolicy を変更する必要があります。

   1. ハブクラスターの DRPolicy を編集し、<cluster1> (例: ocp4perf1) を ManuallyFenced から Unfenced に変更します。

      $ oc edit drpolicy odr-policy

      出力例:

      [...]
      spec:
        drClusterSet:
        - clusterFence: Unfenced  ## <-- Modify from ManuallyFenced to Unfenced
          name: ocp4perf1
          region: metro
          s3ProfileName: s3-primary
        - clusterFence: Unfenced
          name: ocp4perf2
          region: metro
          s3ProfileName: s3-secondary
      [...]

      出力例:

      drpolicy.ramendr.openshift.io/odr-policy edited

   2. プライマリーマネージドクラスターのハブクラスターで、DRPolicy のステータスが Unfenced に変更されていることを確認します。

      $ oc get drpolicies.ramendr.openshift.io odr-policy -o yaml | grep -A 6 drClusters

      出力例:

        drClusters:
          ocp4perf1:
            status: Unfenced
            string: ocp4perf1
          ocp4perf2:
            status: Unfenced
            string: ocp4perf2

3. DRPlacementControl を failback に変更します

   1. ハブクラスターで Installed Operators に移動し、Openshift DR Hub Operator をクリックします。
   2. DRPlacementControl タブをクリックします。
   3. DRPC busybox-drpc をクリックしてから、YAML ビューをクリックします。

   4. action を Relocate に変更します

      DRPlacementControl modify action to Relocate

      

   5. Save をクリックします。

   6. アプリケーション busybox がプライマリーマネージドクラスターで実行されているかどうかを確認します。フェイルオーバー操作の前にアプリケーションが実行していた YAML ファイルで指定されている preferredCluster ocp4perf1 へのフェイルバックが行われます。

      $ oc get pods,pvc -n busybox-sample

      出力例:

      NAME          READY   STATUS    RESTARTS   AGE
      pod/busybox   1/1     Running   0          60s
      
      NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
      persistentvolumeclaim/busybox-pvc   Bound    pvc-79f2a74d-6e2c-48fb-9ed9-666b74cfa1bb   5Gi        RWO            ocs-storagecluster-ceph-rbd   61s

   7. busybox がセカンダリーマネージドクラスターで実行しているかどうかを確認します。busybox アプリケーションは、このマネージドクラスターでは実行しないようにしてください。

      $ oc get pods,pvc -n busybox-sample

      出力例:

      No resources found in busybox-sample namespace.