4.16. Red Hat Advanced Cluster Management を使用したハブのリカバリー

手順

1. RHACM Operator と MultiClusterHub がパッシブハブクラスターにインストールされていることを確認します。手順については、RHACM インストールガイド を参照してください。

   Operator が正常にインストールされると、Web console update is available というメッセージを含むポップアップがユーザーインターフェイスに表示されます。このポップアップから Refresh web console をクリックして、反映するコンソールを変更します。

2. ハブをリカバリーする前に、バックアップとリストアを設定します。RHACM ビジネス継続性 ガイドの バックアップおよび復元 を参照してください。
3. 復元の前に、マルチクラスターオーケストレーター (MCO) Operator を Red Hat OpenShift GitOps オペレーターとともにパッシブ RHACM ハブにインストールします。RHACM ハブを復元する手順は、OpenShift Data Foundation Multicluster Orchestrator Operator のインストール を参照してください。
4. Restore.cluster.open-cluster-management.io リソースの .spec.cleanupBeforeRestore が None に設定されていることを確認します。詳細は、RHACM ドキュメントの バックアップの確認中にパッシブリソースを復元する を参照してください。
5. 以前のセットアップ中にクラスター間の SSL アクセスが手動で設定されていた場合は、クラスター間の SSL アクセスを再設定します。手順については、クラスター間での SSL アクセスの設定 の章を参照してください。

6. パッシブハブで、このコマンドを使用して、openshift-operators namespace にラベルを追加し、VolumeSyncronizationDelay アラートの基本的な監視を有効にします。アラートの詳細は、障害復旧アラート を参照してください。

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

手順

1. 復元手順中に、ManifestWorks が正しく再生成されない場合にリソースのエビクションを回避するために、AppliedManifestWork のエビクション の猶予期間を延長することができます。パッシブハブクラスターで、既存のグローバル KlusterletConfig を確認します。

   • グローバルの KlusterletConfig が存在する場合は、appliedManifestWorkEvictionGracePeriod パラメーターの値を編集して、より大きな値に設定します。たとえば、24 時間以上などです。

   • グローバルの KlusterletConfig が存在しない場合は、次の yaml を使用して Klusterletconfig を作成します。

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

     設定はすべてのマネージドクラスターに自動的に伝播されます。

2. パッシブハブクラスターでバックアップを復元します。詳細は、バックアップからの ハブクラスターの復元 を参照してください。

   重要

   障害が発生したハブをパッシブインスタンスに復元すると、最後にスケジュールされたバックアップ時点のアプリケーションとその DR 保護状態のみが復元されます。最後のスケジュールされたバックアップの後に DR で保護されたアプリケーションは、新しいハブで再度保護する必要があります。

3. 復元が完了したことを確認します。

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

4. プライマリーおよびセカンダリーマネージドクラスターが RHACM コンソールに正常にインポートされ、アクセス可能であることを確認します。マネージドクラスターのいずれかがダウンしているか、アクセスできない場合は、正常にインポートされません。

   DR 操作を実行する前に、DRPolicy 検証が成功するまで待機します。

   注記

   マネージドクラスターがパッシブハブにインポートされると、Submariner が自動的にインストールされます。

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

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

   出力例:

   Succeeded

6. アクティブハブクラスターで DR 監視ダッシュボードタブが有効になっている場合は、RHACM コンソールを更新して、そのタブにアクセスできるようにします。

7. 新しいハブクラスターで以下のコマンドを使用して DRPC 出力を確認します。

   $ oc get drpc -A -o wide

   PROGRESSION が PAUSED のステータスを表示する場合、一時停止を解除するには管理者の介入が必要です。PROGRESSION は、以下の条件下で PAUSED 状態になります。

   • クラスタークエリー障害: DRPC の調整中に、クラスターのクエリーが正常に行われませんでした。この状況は、ハブの回復中に発生する可能性があります。
   • アクション不一致: DRPC アクションは、クエリーされた VRG アクションとは異なります。

   • クラスター不一致: DRPC アクションと VRG アクションは同じですが、プライマリー VRG は、DRPC によって予想されるクラスターとは異なるクラスターにあります。

     重要

     一時停止の原因を診断して解決できない場合は、Red Hat カスタマーサポート にお問い合わせください。

     PROGRESSION が Completed または Cleaning up のいずれかである場合、続行しても安全です。

8. 新しいハブでグローバル KlusterletConfig を編集し、appliedManifestWorkEvictionGracePeriod パラメーターとその値を削除します。

9. アクティブなハブクラスター、または両方のアクティブなハブクラスター、プライマリーマネージドクラスターが停止しているかどうかに応じて、シナリオに基づいて次の手順に従います。

   1. アクティブなハブクラスターのみがダウンしていて、マネージドクラスターがまだアクセス可能な場合は、それ以上のアクションは必要ありません。

   2. プライマリーマネージドクラスターがダウンしている場合は、アクティブなハブクラスターとともに、ワークロードをプライマリーマネージドクラスターからセカンダリーマネージドクラスターにフェイルオーバーする必要があります。

      ワークロードタイプに基づくフェイルオーバーの手順は、サブスクリプションベースのアプリケーション または ApplicationSet ベース のアプリケーション を参照してください。

10. プライマリーマネージドクラスターがアクティブハブクラスターとともにダウンしている場合は、プライマリーマネージドクラスターからセカンダリーマネージドクラスターにワークロードをフェイルオーバーする必要があります。

    フェイルオーバーの手順は、ワークロードの種類に応じて、サブスクリプションベースのアプリケーション または ApplicationSet ベースのアプリケーション を参照してください。

11. フェイルオーバーが成功したことを確認します。プライマリーマネージドクラスターもダウンしている場合は、ダウンしたマネージドクラスターがオンラインに戻り、RHACM コンソールに正常にインポートされるまで、ワークロードの PROGRESSION ステータスが Cleaning Up フェーズになります。

    パッシブハブクラスターで次のコマンドを実行して、PROGRESSION ステータスを確認します。

    $ oc get drpc -o wide -A