OpenShift ワークロード用の OpenShift Data Foundation Disaster Recovery の設定

1. DR ソリューションの一部であるハブ、プライマリー、およびセカンダリー Openshift Container Platform クラスターの要件が満たされていることを確認します。Metro-DR を有効にするための要件 を参照してください。
2. arbiter を使用して Red Hat Ceph Storage ストレッチクラスターをデプロイするための要件を満たしていることを確認してください。Red Hat Ceph Storage の導入の要件 を参照してください。
3. Red Hat Ceph Storage ストレッチモードをデプロイして設定します。拡張モード機能を使用して 2 つの異なるデータセンターで Ceph クラスターを有効にする手順については、Red Hat Ceph Storage のデプロイ を参照してください。
4. OpenShift Data Foundation operator をインストールし、プライマリーおよびセカンダリーのマネージドクラスターにストレージシステムを作成します。マネージドクラスターへの OpenShift Data Foundation のインストール を参照してください。
5. ハブクラスターに ODF マルチクラスターオーケストレーターをインストールします。ハブクラスターへの ODF Multicluster Orchestrator のインストール を参照してください。
6. ハブ、プライマリー、およびセカンダリークラスター間の SSL アクセスを設定します。クラスター間での SSL アクセスの設定 を参照してください。

7. プライマリークラスターとセカンダリークラスター全体で DR 保護を必要とするアプリケーションで使用する DRPolicy リソースを作成します。Creating Disaster Recovery Policy on Hub cluster を参照してください。

   注記

   Metro-DR ソリューションには、DRpolicy を 1 つだけ指定できます。

8. 以下を使用して災害復旧ソリューションをテストします。

   1. サブスクリプションベース のアプリケーション:

      • サンプルアプリケーションを作成します。サンプルアプリケーションの作成 を参照してください。
      • マネージドクラスター間でサンプルアプリケーションを使用して、フェイルオーバーと再配置操作をテストします。サブスクリプションベースのアプリケーションのフェイルオーバー と サブスクリプションベースのアプリケーションの再配置 を参照してください。

   2. ApplicationSet ベース のアプリケーション:

      • サンプルアプリケーションを作成します。ApplicationSet ベースのアプリケーションの作成 を参照してください。
      • マネージドクラスター間でサンプルアプリケーションを使用して、フェイルオーバーと再配置操作をテストします。ApplicationSet ベースのアプリケーションのフェイルオーバー と ApplicationSet ベースのアプリケーションの再配置 を参照してください。

手順

1. 各管理対象クラスターに最新の OpenShift Data Foundation クラスターをインストールして設定します。

2. Operator をインストールした後、オプション Full デプロイメント タイプおよび Connect with external storage platform を使用して、バッキングストレージタイプ が Red Hat Ceph Storage である StorageSystem を作成します。

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

   ceph-external-cluster-details-exporter.py スクリプトで次のフラグを使用します。

   1. 少なくとも、ceph-external-cluster-details-exporter.py script で次の 3 つのフラグを使用する必要があります。

      --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 の展開中にデフォルト値が使用された場合、次のフラグは optional です。

      --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. ブートストラップノード 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. ブートストラップされたノード 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. ブートストラップされたノード 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 を変更します。

      • ブートストラップクラスター (ceph1) で生成された 2 つのファイル 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 Gateway (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. ハブクラスター で OperatorHub に移動し、キーワードフィルターを使用して ODF Multicluster Orchestrator を検索します。
2. ODF Multicluster Orchestrator タイルをクリックします。

3. すべてのデフォルト設定をそのままにして、Install をクリックします。

   Operator のリソースが openshift-operators プロジェクトにインストールされ、すべてのnamespace で利用できることを確認してください。

   注記

   ODF Multicluster Orchestrator レーターは、依存関係として RHACM ハブクラスターに Openshift DR ハブ Operator もインストールします。

4. Operator Pod が Running 状態であることを確認します。OpenShift DR Hub Operator も同時に openshift-operators namespace にインストールされます。

   $ 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. プライマリーマネージドクラスター の Ingress 証明書をデプロイメントし、出力を primary.crt に保存します。

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

2. セカンダリーマネージドクラスターの Ingress 証明書を抽出し、出力を 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 で作成します。

   注記

   この例のように、クラスターごとに 3 つ以上の証明書が存在する可能性があります。また、以前作成した 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. プライマリーマネージドクラスター、セカンダリーマネージドクラスター、ハブクラスター で ConfigMap を作成します。

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

   出力例:

   configmap/user-ca-bundle created

5. プライマリーマネージドクラスター、セカンダリーマネージドクラスター、および ハブクラスター 上のデフォルトのプロキシーリソースにパッチを適用します。

   $ 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. DR ポリシーの作成 をクリックします。
3. ポリシー名 を入力します。各 DRPolicy に一意の名前が付けられていることを確認します (例: ocp4perf1-ocp4perf2)。
4. この新しいポリシーが関連付けられる管理対象クラスターのリストから 2 つのクラスターを選択します。
5. レプリケーションポリシー は、選択した OpenShift クラスターに基づいて sync するように自動的に設定されます。
6. Create をクリックします。

7. DRPolicy が正常に作成されたことを確認します。作成された各 DRPolicy リソースごとに ハブクラスター でこのコマンドを実行します。<drpolicy_name> は、一意の名前に置き換えてください。

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

   出力例:

   Succeeded

   DRPolicy が作成されると、それに伴って 2 つの DRCluster リソースも作成されます。3 つのリソースすべてが検証され、ステータスが Succeeded と表示されるまで、最大 10 分かかる場合があります。

   注記

   DRPolicy では、SchedulingInterval、ReplicationClassSelector、VolumeSnapshotClassSelector、および DRClusters フィールドの値の編集はサポートされていません。

8. ハブクラスター から プライマリーマネージドクラスター と セカンダリーマネージドクラスター の両方へのオブジェクトバケットアクセスを確認します。

   1. ハブクラスター上の DRClusters の名前を取得します。

      $ oc get drclusters

      出力例:

   2. 各マネージドクラスター上に作成された各バケットへの S3 アクセスを確認します。DRCluster 検証コマンドを使用します。<drcluster_name> は一意の名前に置き換えてください。

      注記

      DRCluster では、Region および S3ProfileName フィールド値の編集はサポートされていません。

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

      出力例:

      Succeeded

      注記

      Hub cluster の両方の DRClusters に対してコマンドを実行してください。

9. OpenShift DR Cluster Operator のインストールが プライマリー管理対象クラスター および セカンダリー管理対象 クラスターで成功したことを確認します。

   $ 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

   各管理対象クラスターの OperatorHub に OpenShift DR Cluster Operator が正常にインストールされていることを確認することもできます。

10. シークレットがプライマリーマネージドクラスターとセカンダリーマネージドクラスターに正しく伝播されていることを確認します。

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

    出力をハブクラスターからの s3SecretRef と照合します。

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

手順

1. Hub cluster でフェンシングを有効にします。

   1. CLI ターミナルを開き、DRCluster resource を編集します。<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 cluster 上の プライマリーマネージドクラスター のフェンシングステータスを確認します。<drcluster_name> は、一意の識別子に置き換えます。

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

      出力例:

      Fenced

   3. OpenShift Container Platform クラスターノードに属する IP がブロックリストにあることを確認します。

      $ 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. ハブクラスターで、Applications に移動します。
3. アプリケーション行の最後にある Actions メニューをクリックして、使用可能なアクションのリストを表示します。
4. Failover application をクリックします。
5. Failover application モーダルが表示されたら、障害時に関連付けられたアプリケーションがフェイルオーバーする ポリシー と ターゲットクラスター を選択します。

6. Select subscription group ドロップダウンをクリックして、デフォルトの選択を確認するか、この設定を変更します。

   デフォルトでは、アプリケーションリソースをレプリケートするサブスクリプショングループが選択されています。

7. フェイルオーバーの準備 状況を確認します。

   • ステータスが Ready で緑色のチェックマークが付いている場合は、ターゲットクラスターでフェイルオーバーを開始する準備ができていることを示しています。手順 7 に進みます。
   • ステータスが Unknown または Not ready の場合は、ステータスが Ready に変わるまで待ちます。
8. Initiate をクリックします。busybox アプリケーションが現在、セカンダリーで管理されているクラスター にフェイルオーバーしています。
9. モーダルウィンドウを閉じ、Applications ページの Data policy 列を使用してステータスを追跡します。

10. アプリケーションのアクティビティーステータスが FailedOver と表示されていることを確認します。

    1. Applications → Overview タブに移動します。
    2. Data policy 列で、ポリシーを適用したアプリケーションの policy リンクをクリックします。
    3. Data policy ポップオーバーで、View more details リンクをクリックします。

手順

1. Hub cluster でフェンシングを有効にします。

   1. CLI ターミナルを開き、DRCluster resource を編集します。<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 cluster 上の プライマリーマネージドクラスター のフェンシングステータスを確認します。<drcluster_name> は、一意の識別子に置き換えます。

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

      出力例:

      Fenced

   3. OpenShift Container Platform クラスターノードに属する IP がブロックリストにあることを確認します。

      $ 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. ハブクラスターで、Applications に移動します。
3. アプリケーション行の最後にある Actions メニューをクリックして、使用可能なアクションのリストを表示します。
4. Failover application をクリックします。
5. フェイルオーバーアプリケーション モーダルが表示されたら、表示された詳細が正しいことを確認し、フェイルオーバーの 準備状況 のステータスを確認します。ステータスが Ready で緑色のチェックマークが付いている場合は、ターゲットクラスターでフェイルオーバーを開始する準備ができていることを示しています。
6. Initiate をクリックします。busybox リソースがターゲットクラスターに作成されました。
7. モーダルウィンドウを閉じ、Applications ページの Data policy 列を使用してステータスを追跡します。

8. アプリケーションのアクティビティーステータスが FailedOver と表示されていることを確認します。

   1. Applications → Overview タブに移動します。
   2. Data policy 列で、ポリシーを適用したアプリケーションの policy リンクをクリックします。
   3. Data policy ポップオーバーで、1 つ以上のポリシー名と、アプリケーションで使用されているポリシーに関連付けられた進行中のアクティビティーが表示されていることを確認します。

手順

1. ハブクラスターでフェンシングを無効にします。

   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

      次のステップに進む前に、このクエリーの出力は 0 Pod である必要があります。

      重要

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

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

   4. Unfenced クラスターが正常な状態であることを確認します。<drcluster_name> は、一意の名前に置き換えて、プライマリー管理クラスターのハブクラスターのフェンシングステータスを検証します。

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

      出力例:

      Unfenced

   5. OpenShift Container Platform クラスターノードに属する IP がブロックリストに含まれていないことを確認します。

      $ ceph osd blocklist ls

      フェンシング中に追加された IP が表示されていないことを確認します。

2. ハブクラスターで、Applications に移動します。
3. アプリケーション行の最後にある Actions メニューをクリックして、使用可能なアクションのリストを表示します。
4. Relocate application をクリックします。
5. Relocate application モーダルが表示されたら、障害時に関連付けられたアプリケーションを再配置する ポリシー と ターゲットクラスター を選択します。
6. デフォルトでは、アプリケーションリソースをデプロイするサブスクリプショングループが選択されています。Select subscription group ドロップダウンをクリックして、デフォルトの選択を確認するか、この設定を変更します。

7. 再配置の準備 状況を確認します。

   • ステータスが Ready で緑色のチェックマークが付いている場合は、ターゲットクラスターで再配置を開始する準備ができていることを示しています。手順 7 に進みます。
   • ステータスが Unknown または Not ready の場合は、ステータスが Ready に変わるまで待ちます。
8. Initiate をクリックします。busybox リソースがターゲットクラスターに作成されました。
9. モーダルウィンドウを閉じ、Applications ページの Data policy 列を使用してステータスを追跡します。

10. アプリケーションのアクティビティーステータスが Relocated と表示されていることを確認します。

    1. Applications → Overview タブに移動します。
    2. Data policy 列で、ポリシーを適用したアプリケーションの policy リンクをクリックします。
    3. Data policy ポップオーバーで、View more details リンクをクリックします。

手順

1. ハブクラスターでフェンシングを無効にします。

   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

      次のステップに進む前に、このクエリーの出力は 0 Pod である必要があります。

      重要

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

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

   4. Unfenced クラスターが正常な状態であることを確認します。<drcluster_name> は、一意の名前に置き換えて、プライマリー管理クラスターのハブクラスターのフェンシングステータスを検証します。

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

      出力例:

      Unfenced

   5. OpenShift Container Platform クラスターノードに属する IP がブロックリストに含まれていないことを確認します。

      $ ceph osd blocklist ls

      フェンシング中に追加された IP が表示されていないことを確認します。

2. ハブクラスターで、Applications に移動します。
3. アプリケーション行の最後にある Actions メニューをクリックして、使用可能なアクションのリストを表示します。
4. Relocate application をクリックします。
5. Relocate application モーダルが表示されたら、障害時に関連付けられたアプリケーションを再配置する ポリシー と ターゲットクラスター を選択します。
6. Initiate をクリックします。busybox リソースがターゲットクラスターに作成されました。
7. モーダルウィンドウを閉じ、Applications ページの Data policy 列を使用してステータスを追跡します。

8. アプリケーションのアクティビティーステータスが Relocated と表示されていることを確認します。

   1. Applications → Overview タブに移動します。
   2. Data policy 列で、ポリシーを適用したアプリケーションの policy リンクをクリックします。
   3. Data policy ポップオーバーで、1 つ以上のポリシー名と、アプリケーションで使用されているポリシーに関連付けられた再配置ステータスが表示されていることを確認します。

手順

1. ハブクラスター で以下の手順を実行します。

   1. CLI 端末を使用して DRCluster リソースを編集し、置換クラスターをフェンスします。<drcluster_name> は置換クラスター名に置き換えます。

      oc edit drcluster <drcluster_name>

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

   2. RHACM コンソールを使用して、アプリケーション に移動し、障害が発生したクラスターから存続しているクラスターに保護されたすべてのアプリケーションをフェイルオーバーします。

   3. すべての保護されたアプリケーションが存続しているクラスター上で実行されていることを確認してください。

      注記

      各アプリケーションの PROGRESSION 状態は Cleaning Up として表示されます。代替クラスターがオフラインまたはダウンしている場合に、これは想定の動作です。。

2. 代替クラスターのフェンスを解除します。

   CLI 端末を使用して、DRCluster リソースを編集します。<drcluster_name> は置換クラスター名です。

   $ 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

   注記

   DRCluster は後のステップまで削除されないため、--wait=false を使用します。

4. 存続しているクラスター上の保護されたアプリケーションごとに、ハブクラスター の障害復旧を無効にします。

   1. アプリケーションごとに配置を編集し、存続したクラスターが選択されていることを確認します。

      注記

      サブスクリプションベースのアプリケーションの場合、関連する配置は、マネージドクラスターと同様に、ハブクラスター上の同じ namespace にあります。ApplicationSets ベースのアプリケーションの場合、関連する配置はハブクラスター上の openshift-gitops namespace にあります。

      $ 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. 保護されたアプリケーションの Placement リソースが、保護されたアプリケーションから削除された存続クラスターと代替クラスター s3Profile を使用するようにすべて設定された後に、すべての DRPlacementControl リソースを ハブクラスター から削除する必要があります。

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

      注記

      サブスクリプションベースのアプリケーションの場合、関連する DRPlacementControl は、ハブクラスター上の管理対象クラスターと同じ namespace にあります。ApplicationSets ベースのアプリケーションの場合、関連付けられた DRPlacementControl はハブクラスターの openshift-gitops namespace にあります。

   4. 次の手順に進む前に、すべての DRPlacementControl リソースが削除されていることを確認してください。このコマンドは、すべての namespace を対象にするクエリーです。リソースが見つからないはずです。

      $ oc get drpc -A

   5. 最後のステップでは、各アプリケーション Placement を編集し、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. ハブクラスターで、次のスクリプトを実行して、存続するクラスター と ハブクラスター からすべての障害復旧設定を削除します。

   #!/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 を使用して、ハブクラスター上のこの namespace にある Disaster Recovery (DR) Operator を削除しました。この namespace に他の DR 以外の Operator がある場合は、OperatorHub から再度インストールする必要があります。

7. openshift-operators namespace が再び作成された後に、障害復旧メトリクスを収集するために monitoring ラベルを追加します。

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

8. 存続クラスターで、DR のインストール中に作成されたオブジェクトバケットが削除されていることを確認します。スクリプトによって削除されなかった場合は、オブジェクトバケットを削除します。DR に使用されるオブジェクトバケットの名前は、odrbucket で始まります。

   $ oc get obc -n openshift-storage

9. RHACM コンソールで、Infrastructure → Clusters ビュー に移動します。

   1. 代替クラスターの割り当てを解除します。
   2. 新しい OpenShift クラスター (リカバリークラスター) を作成し、その新しいクラスターを RHACM コンソールにインポートします。手順は、クラスターの作成 および ハブクラスターへのターゲット管理対象クラスターのインポート を参照してください。

10. リカバリークラスターに OpenShift Data Foundation Operator をインストールし、それを存続クラスターと同じ外部 Ceph Storage システムに接続します。詳しい手順は、外部モードでの OpenShift Data Foundation のデプロイ を参照してください。

    注記

    OpenShift Data Foundation のバージョンが 4.15 (またはそれ以降) であり、同じバージョンの OpenShift Data Foundation が存続クラスター上にあることを確認してください。

11. ハブクラスターで、OperatorHub から ODF Multicluster Orchestrator Operator をインストールします。手順は、OpenShift Data Foundation Multicluster Orchestrator Operator のインストール の章を参照してください。

12. RHACM コンソールを使用して、Data Services → Data policies に移動します。

    1. Create DRPolicy を選択し、ポリシーに名前を付けます。
    2. recovery cluster と surviving cluster を選択します。
    3. ポリシーを作成します。手順は、ハブクラスターでの障害復旧ポリシーの作成 の章を参照してください。

    DRPolicy のステータスが Validated に変更された後にのみ、次の手順に進みます。

13. 代替クラスターに障害が発生する前に元々保護されていた、存続クラスター上のアプリケーションに DRPolicy を適用します。
14. 存続クラスター上で新しく保護されたアプリケーションを新しい回復 (プライマリー) クラスターに再配置します。RHACM コンソールを使用して、Applications メニューに移動して再配置を実行します。

1. DR ソリューションの一部であるハブ、プライマリー、およびセカンダリー Openshift Container Platform クラスターの 3 つの要件が満たされていることを確認します。Regional-DR を有効にするための要件を参照してください。
2. OpenShift Data Foundation operator をインストールし、プライマリーおよびセカンダリーのマネージドクラスターにストレージシステムを作成します。管理対象クラスターでの OpenShift Data Foundation クラスターの作成 を参照してください。
3. ハブクラスターに ODF マルチクラスターオーケストレーターをインストールします。ハブクラスターへの ODF Multicluster Orchestrator のインストール を参照してください。
4. ハブ、プライマリー、およびセカンダリークラスター間の SSL アクセスを設定します。クラスター間での SSL アクセスの設定 を参照してください。

5. プライマリークラスターとセカンダリークラスター全体で DR 保護を必要とするアプリケーションで使用する DRPolicy リソースを作成します。Creating Disaster Recovery Policy on Hub cluster を参照してください。

   注記

   複数のポリシーが存在する場合があります。

6. 以下を使用して災害復旧ソリューションをテストします。

   1. サブスクリプションベース のアプリケーション:

      • サブスクリプションベースのアプリケーションを作成します。サンプルアプリケーションの作成 を参照してください。
      • サンプルのサブスクリプションベースのアプリケーションを使用して、マネージドクラスター間でフェイルオーバーと再配置操作をテストします。サブスクリプションベースのアプリケーションのフェイルオーバー と サブスクリプションベースのアプリケーションの再配置 を参照してください。

   2. ApplicationSet ベース のアプリケーション:

      • サンプルアプリケーションを作成します。ApplicationSet ベースのアプリケーションの作成 を参照してください。
      • マネージドクラスター間でサンプルアプリケーションを使用して、フェイルオーバーと再配置操作をテストします。ApplicationSet ベースのアプリケーションのフェイルオーバー と ApplicationSet ベースのアプリケーションの再配置 を参照してください。

手順

1. 各管理対象クラスターに最新の OpenShift Data Foundation クラスターをインストールして設定します。

   OpenShift Data Foundation のデプロイメントについては、インフラストラクチャー固有のデプロイメントガイド (AWS、VMware、ベアメタル、Azure など) を参照してください。

   注記

   ストレージクラスターの作成中に、Data Protection ステップで、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 Gateway (MCG) の場合:

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

   ステータス結果が Primary managed cluster と Secondary managed cluster の両方のクエリーに対して 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 を編集します。

   警告

   Submariner のインストール時に Globalnet を有効にしていない限り、StorageCluster でこの変更を行わないでください。

   $ 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. ハブクラスター で OperatorHub に移動し、キーワードフィルターを使用して ODF Multicluster Orchestrator を検索します。
2. ODF Multicluster Orchestrator タイルをクリックします。

3. すべてのデフォルト設定をそのままにして、Install をクリックします。

   Operator のリソースが openshift-operators プロジェクトにインストールされ、すべてのnamespace で利用できることを確認してください。

   注記

   ODF Multicluster Orchestrator レーターは、依存関係として RHACM ハブクラスターに Openshift DR ハブ Operator もインストールします。

4. Operator Pod が Running 状態であることを確認します。OpenShift DR Hub Operator も同時に openshift-operators namespace にインストールされます。

   $ 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. プライマリーマネージドクラスター の Ingress 証明書をデプロイメントし、出力を primary.crt に保存します。

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

2. セカンダリーマネージドクラスターの Ingress 証明書を抽出し、出力を 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 で作成します。

   注記

   この例のように、クラスターごとに 3 つ以上の証明書が存在する可能性があります。また、以前作成した 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. プライマリーマネージドクラスター、セカンダリーマネージドクラスター、ハブクラスター で ConfigMap を作成します。

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

   出力例:

   configmap/user-ca-bundle created

5. プライマリーマネージドクラスター、セカンダリーマネージドクラスター、および ハブクラスター 上のデフォルトのプロキシーリソースにパッチを適用します。

   $ 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. DR ポリシーの作成 をクリックします。
3. ポリシー名 を入力します。各 DRPolicy に一意の名前があることを確認します (例: ocp4bos1-ocp4bos2-5m)。

4. この新しいポリシーが関連付けられる管理対象クラスターのリストから 2 つのクラスターを選択します。

   注記

   クラスターを選択した後に "OSDs not migrated" というエラーメッセージが表示された場合は、次のステップに進む前に Migration of existing OSD to the optimized OSD in OpenShift Data Foundation for Regional-DR cluster のナレッジベース記事の手順に従ってください。

5. レプリケーションポリシー は、選択した OpenShift クラスターに基づいて自動的に 非同期 (async) に設定され、同期スケジュール オプションが使用可能になります。

6. 同期スケジュール を設定します。

   重要

   必要なレプリケーション間隔ごとに、新しい DRPolicy を一意の名前 (例: ocp4bos1-ocp4bos2-10m) で作成する必要があります。同じクラスターを選択できますが、同期スケジュール は、分/時間/日単位の異なるレプリケーション間隔で設定できます。最小値は 1 分です。

7. Create をクリックします。

8. DRPolicy が正常に作成されたことを確認します。作成された各 DRPolicy リソースごとに ハブクラスター でこのコマンドを実行します。<drpolicy_name> は、一意の名前に置き換えてください。

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

   出力例:

   Succeeded

   DRPolicy が作成されると、それに伴って 2 つの DRCluster リソースも作成されます。3 つのリソースすべてが検証され、ステータスが Succeeded と表示されるまで、最大 10 分かかる場合があります。

   注記

   DRPolicy では、SchedulingInterval、ReplicationClassSelector、VolumeSnapshotClassSelector、および DRClusters フィールドの値の編集はサポートされていません。

9. ハブクラスター から プライマリーマネージドクラスター と セカンダリーマネージドクラスター の両方へのオブジェクトバケットアクセスを確認します。

   1. ハブクラスター上の DRClusters の名前を取得します。

      $ oc get drclusters

      出力例:

      NAME        AGE
      ocp4bos1   4m42s
      ocp4bos2   4m42s

   2. 各マネージドクラスター上に作成された各バケットへの S3 アクセスを確認します。DRCluster 検証コマンドを使用します。<drcluster_name> は一意の名前に置き換えてください。

      注記

      DRCluster では、Region および S3ProfileName フィールド値の編集はサポートされていません。

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

      出力例:

      Succeeded

      注記

      Hub cluster の両方の DRClusters に対してコマンドを実行してください。

10. OpenShift DR Cluster Operator のインストールが プライマリー管理対象クラスター および セカンダリー管理対象 クラスターで成功したことを確認します。

    $ 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

    各管理対象クラスターの OperatorHub に OpenShift DR Cluster Operator が正常にインストールされていることを確認することもできます。

    注記

    最初の実行時に、VolSync Operator が自動的にインストールされます。VolSync は、CephFs ベースの PVC を保護するために、2 つのクラスター間でボリュームのレプリケーションを設定するために使用されます。レプリケーション機能はデフォルトで有効になっています。

11. 1 次管理対象クラスター および 2 次管理 対象クラスター上の OpenShift Data Foundation ミラーリング デーモン の正常性の状況を確認します。

    $ 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. ハブクラスターで、Applications に移動します。
2. アプリケーション行の最後にある Actions メニューをクリックして、使用可能なアクションのリストを表示します。
3. Failover application をクリックします。
4. Failover application モーダルが表示されたら、障害時に関連付けられたアプリケーションがフェイルオーバーする ポリシー と ターゲットクラスター を選択します。

5. Select subscription group ドロップダウンをクリックして、デフォルトの選択を確認するか、この設定を変更します。

   デフォルトでは、アプリケーションリソースをレプリケートするサブスクリプショングループが選択されています。

6. フェイルオーバーの準備 状況を確認します。

   • ステータスが Ready で緑色のチェックマークが付いている場合は、ターゲットクラスターでフェイルオーバーを開始する準備ができていることを示しています。手順 7 に進みます。
   • ステータスが Unknown または Not ready の場合は、ステータスが Ready に変わるまで待ちます。
7. Initiate をクリックします。busybox アプリケーションが現在、セカンダリーで管理されているクラスター にフェイルオーバーしています。
8. モーダルウィンドウを閉じ、Applications ページの Data policy 列を使用してステータスを追跡します。

9. アプリケーションのアクティビティーステータスが FailedOver と表示されていることを確認します。

   1. Applications → Overview タブに移動します。
   2. Data policy 列で、ポリシーを適用したアプリケーションの policy リンクをクリックします。
   3. Data policy ポップオーバーで、View more details リンクをクリックします。
   4. アプリケーションで使用されているポリシーに関連付けられている 1 つ以上のポリシー名と進行中のアクティビティー (最終同期時間とアクティビティーステータス) が表示されることを確認します。

手順

1. ハブクラスターで、Applications に移動します。
2. アプリケーション行の最後にある Actions メニューをクリックして、使用可能なアクションのリストを表示します。
3. Failover application をクリックします。
4. フェイルオーバーアプリケーション モーダルが表示されたら、表示された詳細が正しいことを確認し、フェイルオーバーの 準備状況 のステータスを確認します。ステータスが Ready で緑色のチェックマークが付いている場合は、ターゲットクラスターでフェイルオーバーを開始する準備ができていることを示しています。
5. Initiate をクリックします。busybox リソースがターゲットクラスターに作成されました。
6. モーダルウィンドウを閉じ、Applications ページの Data policy 列を使用してステータスを追跡します。

7. アプリケーションのアクティビティーステータスが FailedOver と表示されていることを確認します。

   1. Applications → Overview タブに移動します。
   2. Data policy 列で、ポリシーを適用したアプリケーションの policy リンクをクリックします。
   3. Data policy ポップオーバーで、1 つ以上のポリシー名と、アプリケーションで使用されているポリシーに関連付けられた進行中のアクティビティーが表示されていることを確認します。

手順

1. ハブクラスターで、Applications に移動します。
2. アプリケーション行の最後にある Actions メニューをクリックして、使用可能なアクションのリストを表示します。
3. Relocate application をクリックします。
4. Relocate application モーダルが表示されたら、障害時に関連付けられたアプリケーションを再配置する ポリシー と ターゲットクラスター を選択します。
5. デフォルトでは、アプリケーションリソースをデプロイするサブスクリプショングループが選択されています。Select subscription group ドロップダウンをクリックして、デフォルトの選択を確認するか、この設定を変更します。

6. 再配置の準備 状況を確認します。

   • ステータスが Ready で緑色のチェックマークが付いている場合は、ターゲットクラスターで再配置を開始する準備ができていることを示しています。手順 7 に進みます。
   • ステータスが Unknown または Not ready の場合は、ステータスが Ready に変わるまで待ちます。
7. Initiate をクリックします。busybox リソースがターゲットクラスターに作成されました。
8. モーダルウィンドウを閉じ、Applications ページの Data policy 列を使用してステータスを追跡します。

9. アプリケーションのアクティビティーステータスが Relocated と表示されていることを確認します。

   1. Applications → Overview タブに移動します。
   2. Data policy 列で、ポリシーを適用したアプリケーションの policy リンクをクリックします。
   3. Data policy ポップオーバーで、View more details リンクをクリックします。
   4. アプリケーションで使用されているポリシーに関連付けられている 1 つ以上のポリシー名と進行中のアクティビティー (最終同期時間とアクティビティーステータス) が表示されることを確認します。

手順

1. ハブクラスターで、Applications に移動します。
2. アプリケーション行の最後にある Actions メニューをクリックして、使用可能なアクションのリストを表示します。
3. Relocate application をクリックします。
4. Relocate application モーダルが表示されたら、障害時に関連付けられたアプリケーションを再配置する ポリシー と ターゲットクラスター を選択します。
5. Initiate をクリックします。busybox リソースがターゲットクラスターに作成されました。
6. モーダルウィンドウを閉じ、Applications ページの Data policy 列を使用してステータスを追跡します。

7. アプリケーションのアクティビティーステータスが Relocated と表示されていることを確認します。

   1. Applications → Overview タブに移動します。
   2. Data policy 列で、ポリシーを適用したアプリケーションの policy リンクをクリックします。
   3. Data policy ポップオーバーで、1 つ以上のポリシー名と、アプリケーションで使用されているポリシーに関連付けられた再配置ステータスが表示されていることを確認します。

手順

1. ハブクラスターで、Applications → Overview タブに移動します。

2. Data policy 列で、ポリシーを適用したアプリケーションの policy リンクをクリックします。

   Data Policies モーダルページが表示され、各アプリケーションに適用されている障害復旧ポリシーの数と、フェイルオーバーおよび再配置の状況が示されます。

3. Data Policies モーダルページで、View more details リンクをクリックします。

   詳細な Data policies モーダルページが表示され、アプリケーションに適用されるポリシーに関連付けられたポリシー名と進行中のアクティビティー (最終同期、アクティビティーステータス) が表示されます。

   モーダルページで報告される Last sync time は、アプリケーションに対して DR 保護されているすべてのボリュームの最新の同期時間を表します。

手順

1. OpenShift Web コンソールにログインします。
2. Operators → OperatorHub をクリックします。
3. Filter by keyword ボックスに local storage を入力し、Operator の一覧から Local Storage Operator を見つけ、これをクリックします。

4. Install Operator ページで、以下のオプションを設定します。

   1. Channel を 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. スクロールするか、OpenShift Data Foundation を Filter by keyword ボックスに入力し、OpenShift Data Foundation Operator を検索します。
4. Install をクリックします。

5. Install Operator ページで、以下のオプションを設定します。

   1. チャネルを stable-4.15 に更新します。
   2. Installation Mode オプションに A specific namespace on the cluster を選択します。
   3. Installed Namespace に Operator recommended namespace openshift-storage を選択します。namespace openshift-storage が存在しない場合、これは Operator のインストール時に作成されます。

   4. 承認ストラテジー を Automatic または Manual として選択します。

      Automatic (自動) 更新を選択した場合、Operator Lifecycle Manager (OLM) は介入なしに、Operator の実行中のインスタンスを自動的にアップグレードします。

      Manual 更新を選択した場合、OLM は更新要求を作成します。クラスター管理者は、Operator を新しいバージョンに更新できるように更新要求を手動で承認する必要があります。

6. Console プラグイン に Enable オプションが選択されていることを確認します。
7. Install をクリックします。

手順

1. OpenShift Web コンソールで、Operators → Installed Operators をクリックし、インストールされた Operator を表示します。

   選択された Project が openshift-storage であることを確認します。

2. OpenShift Data Foundation Operator をクリックした後、Create StorageSystem をクリックします。
3. Backing storage ページで、Create a new StorageClass using the local storage devices オプションを選択します。

4. Next をクリックします。

   重要

   Local Storage Operator がまだインストールされていない場合は、インストールするように求められます。Install をクリックし、ローカルストレージ Operator のインストールで説明されているように手順に従います。

5. Create local volume set ページで、以下の情報を提供します。

   1. LocalVolumeSet および StorageClass の名前を入力します。

      デフォルトで、ローカルボリュームセット名がストレージクラス名について表示されます。名前を変更できます。

   2. 以下のいずれかを選択します。

      • Disks on all nodes

        すべてのノードにある選択したフィルターに一致する利用可能なディスクを使用します。

      • Disks on selected nodes

        選択したノードにある選択したフィルターにのみ一致する利用可能なディスクを使用します。

        重要

        選択したノードが集約された 30 CPU および 72 GiB の RAM の OpenShift Data Foundation クラスターの要件と一致しない場合は、最小クラスターがデプロイされます。

        ノードの最小要件については、プランニングガイドのリソース要件セクションを参照してください。

   3. SSD または NVMe を選択して、サポートされる設定を構築します。サポート対象外のテストインストールに HDD を選択できます。

   4. Advanced セクションを拡張し、以下のオプションを設定します。

      ボリュームモード	デフォルトではブロックが選択されます。
      デバイスタイプ	ドロップダウンリストから 1 つ以上のデバイスタイプを選択します。
      ディスクサイズ	デバイスの最小サイズ 100GB と、含める必要のあるデバイスの最大サイズを設定します。
      ディスクの最大数の制限	これは、ノードで作成できる PV の最大数を示します。このフィールドが空のままの場合、PV は一致するノードで利用可能なすべてのディスクに作成されます。

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

      LocalVolumeSet の作成を確認するポップアップが表示されます。

   6. Yes をクリックして続行します。

6. Capacity and nodes ページで、以下を設定します。

   1. Available raw capacity には、ストレージクラスに関連付けられた割り当てられたすべてのディスクに基づいて容量の値が設定されます。これには少し時間がかかります。

      Selected nodes リストには、ストレージクラスに基づくノードが表示されます。

   2. ストレッチクラスターを使用する必要がある場合は、Enable arbiter チェックボックスを選択します。このオプションは、arbiter のすべての前提条件が満たされ、選択されたノードが設定される場合にのみ利用できます。詳細は、ストレッチクラスターを有効にするための要件 のarbiter ストレッチクラスターの要件を参照してください。

      ドロップダウンリストから arbiter ゾーン を選択します。

7. Configure performance でパフォーマンスプロファイルを選択します。

   StorageSystems タブのオプションメニューから Configure performance オプションを使用して、デプロイ後にパフォーマンスプロファイルを設定することもできます。

   重要

   リソースプロファイルを選択する前に、クラスター内のリソースの現在の可用性を必ず確認してください。リソースが不十分なクラスターでより高いリソースプロファイルを選択すると、インストールが失敗する可能性があります。リソース要件の詳細は、パフォーマンスプロファイルのリソース要件 を参照してください。

   1. Next をクリックします。

8. オプション: Security and network ページで、要件に応じて以下を設定します。

   1. 暗号化を有効にするには、Enable data encryption for block and file storage を選択します。

   2. 以下の Encryption level (暗号化レベル) のいずれかを選択します。

      • Cluster-wide encryption: クラスター全体 (ブロックおよびファイル) を暗号化します。
      • StorageClass 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 or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号および Token を入力します。

         • Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

           • OpenShift Data Foundation 専用で固有のキーと値のシークレットパスを Backend Path に入力します。
           • オプション: TLS Server Name および Vault Enterprise Namespace を入力します。
           • PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA 証明書、クライアント証明書、および クライアントの秘密鍵 を指定します。
           • Save をクリックして、手順 iv に進みます。

         Kubernetes 認証方式の使用

         • Vault ('https://<hostname or ip>') サーバーの一意の Connection Name、ホストの Address、Port 番号および Role 名を入力します。

         • Advanced Settings をデプロイメントして、Vault 設定に基づいて追加の設定および証明書の詳細を入力します。

           • OpenShift Data Foundation 専用で固有のキーと値のシークレットパスを Backend Path に入力します。
           • 該当する場合は、TLS Server Name および Authentication Path を入力します。
           • PEM でエンコードされた、該当の証明書ファイルをアップロードし、CA 証明書、クライアント証明書、および クライアントの秘密鍵 を指定します。
           • Save をクリックして、手順 iv に進みます。

      3. Thales CipherTrust Manager (using KMIP) を KMS プロバイダーとして使用するには、次の手順に従います。

         1. プロジェクト内のキー管理サービスの一意の Connection Name を入力します。

         2. Address および Port セクションで、Thales CipherTrust Manager の IP と、KMIP インターフェイスが有効になっているポートを入力します。以下に例を示します。

            • Address: 123.34.3.2
            • Port: 5696
         3. クライアント証明書、CA 証明書、および クライアント秘密鍵 をアップロードします。
         4. StorageClass 暗号化が有効になっている場合は、上記で生成された暗号化および復号化に使用する一意の識別子を入力します。
         5. TLS Server フィールドはオプションであり、KMIP エンドポイントの DNS エントリーがない場合に使用します。たとえば、kmip_all_<port>.ciphertrustmanager.local などです。

   4. 単一のネットワークを使用している場合、Network はデフォルト (OVN) に設定されます。

      複数のネットワークインターフェイスを使用している場合は、カスタム (Multus) に切り替えて、次のいずれかを選択できます。

      1. ドロップダウンメニューから Public Network Interface を選択します。
      2. ドロップダウンメニューから Cluster Network Interface を選択します。
   注記

   1 つの追加ネットワークインターフェイスのみを使用する場合は、パブリックネットワークインターフェイス (例: ocs-public-cluster) の単一の NetworkAttachementDefinition を選択し、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. アプリケーションを 4 つのレプリカにスケーリングし、そのサービスを公開して、アプリケーションゾーンを認識して使用できるようにします。

   $ 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

   数分後には、4 つの file-uploader Pod が必要です。4 つの file-uploader Pod が 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 を作成します。
   • ボリューム定義を含めるようにアプリケーションデプロイメントを更新します。
   • アプリケーションのデプロイメントを更新して、ボリュームマウントを指定されたマウントパスに割り当てます。
   • 4 つのアプリケーション 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 に設定されている点に注意してください。

   4 つの file-uploader Pod はすべて同じ RWX ボリュームを使用しています。このアクセスモードがないと、OpenShift は複数の Pod を同じ永続ボリューム (PV) に確実にアタッチしようとしません。ReadWriteOnce (RWO) PV を使用するデプロイメントをスケールアップしようとすると、Pod は同じノードに配置される可能性があります。

手順

1. ハブクラスターでターミナルウィンドウを開きます。

2. 以下のラベルを openshift-operator namespace に追加します。

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

手順

1. ハブクラスターでターミナルウィンドウを開き、次の手順を実行します。

2. observability-metrics-custom-allowlist.yaml という名前の configmap ファイルを作成します。

   次の YAML を使用して、ハブクラスターの障害復旧メトリックをリスト表示できます。詳細は、カスタム指標の追加 を参照してください。ramen のメトリクスの詳細は、障害復旧のメトリクス を参照してください。

   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 namespace で次のコマンドを実行します。

   $ 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. ハブクラスターで、すべてのクラスター オプションが選択されていることを確認します。
2. コンソールを更新して、DR 監視ダッシュボードタブにアクセスできるようにします。
3. Data Services に移動し、データポリシー をクリックします。
4. 概要タブでは、operator、クラスター、アプリケーションの正常性ステータスを表示できます。緑色のチェックマークは、operator が実行中であり、使用可能であることを示します。
5. 障害復旧 タブをクリックして、DR ポリシーの詳細と接続されているアプリケーションのリストを表示します。