3.16.4.2. 障害復旧により保護された検出対象アプリケーションの再配置


このセクションでは、障害復旧により保護された検出対象アプリケーションを再配置する方法を説明します。

手順

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

    1. このクラスターの DRCluster resource を編集し、<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 ストレージクラスターの正常性を評価することもできます。OpenShift Data Foundation ダッシュボードの詳細は、Storage Data Foundation に移動すると表示されます。

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

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

      出力例:

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

      $ ceph osd blocklist ls

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

  2. RHACM コンソールで、Disaster Recovery Protected applications タブに移動します。
  3. アプリケーション行の最後で、Actions メニューをクリックし、再配置 の開始を選択します。
  4. Relocate application モーダルウィンドウで、アプリケーションとターゲットクラスターのステータスを確認します。
  5. Initiate をクリックします。
  6. 結果が WaitOnUserToCleanup になるまで、再配置の進行状況を確認します。DRPC 名は、前の手順で設定した一意の名前 (例: busybox-rbd) によって識別できます。

    $ oc get drpc {drpc_name} -n openshift-dr-ops -o jsonpath='{.status.progression}{"\n"}'
    WaitOnUserToCleanUp
  7. プライマリーマネージドクラスター への 再配置 が完了する前に、セカンダリーマネージドクラスター から busybox アプリケーションを削除します。

    busybox のクローンリポジトリーに移動し、再配置 元の セカンダリーマネージドクラスター で次のコマンドを実行します。アプリケーションの作成に使用したのと同じディレクトリー (odr-metro-rbd など) を使用します。

    $ cd ~/ocm-ramen-samples/
    $ git branch
    * main
    $ oc delete -k workloads/deployment/odr-metro-rbd -n busybox-discovered
    persistentvolumeclaim "busybox-pvc" deleted
    deployment.apps "busybox" deleted
  8. アプリケーションを削除した後、Protected applications タブに移動し、busybox リソースが両方とも Healthy 状態であることを確認します。
  9. プライマリーマネージドクラスターbusybox アプリケーションが実行されていることを確認します。

    $ oc get pods,pvc -n busybox-discovered
    NAME                           READY   STATUS    RESTARTS   AGE
    pod/busybox-796fccbb95-qmxjf   1/1     Running   0          2m46s
    
    
    NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  VOLUMEATTRIBUTESCLASS   AGE
    persistentvolumeclaim/busybox-pvc   Bound    pvc-b20e4129-902d-47c7-b962-040ad64130c4   1Gi        RWO            ocs-storagecluster-ceph-rbd   <unset>                 2m57s
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る