Oracle Cloud Infrastructureドキュメント

フル・スタック・障害時リカバリによって実行される事前チェック

フルスタック障害回復では、DR保護グループ、DRプラン、DRプラン実行などのリソースの事前チェックが実行されます。

コンピュート・インスタンスの事前チェック

フル・スタックDRでは、まずプライマリDRPGに存在するVMごとに次のストレージ事前チェックが実行されます。フル・スタックDRは、次のことを検証します。
  • ボリューム・グループ・レプリケーションが構成されているか、バックアップがバックアップ・ポリシーで構成されており、リージョン間コピーが有効です。
  • ボリューム・グループ・レプリカまたは少なくとも1つのボリューム・グループ・バックアップがスタンバイ・リージョンに存在します。フル・スタックDRが最新のボリューム・グループ・バックアップを使用するため、複数のバックアップが存在することもできます。
  • DRPGのメンバーのVMのすべてのブート・ボリュームとブロック・ボリュームがボリューム・グループに追加されます。
  • ボリューム・グループには、DRPGのメンバーのVMにアタッチされているブート・ボリュームおよびブロック・ボリュームのみが含まれます。
  • ユーザーが、移動中のコンピュート・インスタンスをスタンバイDR保護グループに追加しようとしているかどうか。これは許可されません。

ファイル・システムの事前チェック:

Full Stack DRは、まずファイル・システムの次の事前チェックを実行します。
  • スイッチオーバー/フェイルオーバー/ドリルの開始:
    • ソース・ファイル・システムが「アクティブ」状態であり、ファイル・システムをエクスポートする必要があることを検証します
    • ソース・ファイル・システムにカスタム暗号化キーがないことを検証します
    • ソース・ファイル・システムに存在するすべてのエクスポートが、ファイル・システム・メンバー・プロパティの一部として宛先マウント・ターゲットにマップされ、一意である必要があることを検証します(重複を回避します)。
    • ソース・ファイル・システムにアクティブなレプリケーション・ポリシーが少なくとも1つ設定されていることを検証します。
    • ファイル・システム・メンバー・プロパティ宛先可用性ドメインがピア・リージョンにあることを検証します
    • ソース・ファイル・システム・エクスポート用に構成されたすべての宛先マウント・ターゲットがピア・リージョンにあり、メンバー・プロパティ宛先可用性ドメインと同じ可用性ドメインにあることを検証します。
    • ターゲット・ファイル・システムが「アクティブ」状態であり、エクスポートされないファイル・システムであることを検証します
    • ターゲット・ファイル・システムに少なくとも1つのレプリケーション・スナップショットが存在することを検証します。
    • 宛先マウント・ターゲットに正しいTCP/UDPプロトコルが有効になっていることを検証します。ファイル・ストレージに対するVCNセキュリティ・ルールの構成を参照してください。
    • ファイル・システム・メンバー・プロパティ宛先スナップショット・ポリシーのOCIDを検証します。
    • ファイル・システム・メンバー・プロパティの宛先スナップショット・ポリシーが存在し、ライフサイクル状態がアクティブであることを検証します。
    • ファイル・システム・メンバー・プロパティの宛先ボールトおよび宛先暗号化キーが存在し、ライフサイクル状態がアクティブであることを検証します。
    • ファイル・システム・メンバー・プロパティの宛先暗号化キーが対称AES (Advanced Encryption Standard)暗号化キーであり、ライフサイクル状態が「有効」であることを検証します。
  • ストップ・ドリル
    • クローニングされたエクスポートされたファイル・システムがクリーン・アップのために存在することを検証します。
    • エクスポートがクリーン・アップのためにクローニングされたエクスポート済ファイル・システムに存在することを検証します

コンピュート・インスタンスでのファイル・システムのマウント/アンマウントの事前チェック:

Full Stack DRは、まずコンピュート・インスタンス上のマウント/アンマウント・ファイル・システムの次の事前チェックを実行します。
  • マウント/アンマウントの詳細メンバープロパティーの検証:
    • マウントの詳細:
      • マウント詳細のマウント・ターゲットがスタンバイ・リージョンと一致することを検証します。
      • マウント・ポイントとエクスポートの組合せが一意であることを検証します(同じマウント・ポイントに複数のマウントを使用しないでください)。
    • アンマウントの詳細:
      • アンマウント詳細のマウント・ターゲットがプライマリ・リージョンと一致することを検証します。
      • エクスポート・パスがマウント解除詳細のマウント・ターゲットに存在することを検証します。
    • マウント詳細の移動可能/移動不可のコンピュート・インスタンスおよびマウント・ターゲットで、正しいTCP/UDPプロトコルが有効になっていることを検証します。ファイル・ストレージに対するVCNセキュリティ・ルールの構成を参照してください。
    • 移動可能/移動不可のコンピュート・インスタンスを検証します。プライマリDR保護グループにマウント可能なファイル・システムがあるか、宛先マウント・ターゲットにマウントする正しいエクスポート・パスがある必要があります。
    • ノート

      フェイルオーバーの場合、プライマリ・リージョンが使用できないため、新しく起動されたコンピュート・インスタンスを含む「ファイル・システム – コンピュート・インスタンスへのマウント」ステップで次のチェックが実行されます

    • コンピュート・インスタンスのコンピュート・インスタンスの実行コマンド・プラグインが有効になっていることを検証します。
    • コンピュート・インスタンスにルート・アクセスがあることを検証します:
    • Linuxオペレーティング・システムの場合のみ、コンピュート・インスタンスにnfs-clientがインストールされていることを確認します。コンピュートにnfs-clientをインストールする方法の詳細は、UNIXスタイル・インスタンスからのファイル・システムのマウントを参照してください。
    • Linuxオペレーティング・システムの場合のみ、linuxオペレーティング・システムの/etc/fstab に、正しいマウント・ターゲットのIPアドレス/完全修飾ドメイン名およびマウント・ポイントを持つマウント詳細が存在することを検証します。
    • 両方のオペレーティング・システムで、マウント・ポイントがコンピュート・インスタンスに存在することを検証します

ボリューム・グループの事前チェック(ブロック・ストレージ)

フル・スタックDRでは、まずプライマリDRPGに追加されたすべてのボリューム・グループに対して次の事前チェックが実行されます。フル・スタックDRは、次のことを検証します。
  • ボリューム・グループはAvailable状態です。
  • ボリューム・グループには、スタンバイ・リージョンにレプリケーションまたはバックアップが構成されています。両方が構成されている場合、フル・スタックDRではレプリカが使用され、バックアップは無視されます。
  • リージョン内DRの場合、宛先(スタンバイ)リージョンのレプリカが同じ可用性ドメイン(AD)にありません。
  • スタンバイ・リージョンのレプリカはAvailable状態であるか、バックアップが使用されている場合は、少なくとも1つのバックアップが存在し、Availableです。
  • ソース・ボリューム・グループ内のボリュームのリストは、スタンバイ・リージョンのレプリカまたはバックアップ内のボリュームのリストと一致しています。
  • 宛先バックアップ・ポリシーは有効なバックアップ・ポリシーです。
  • 「共通宛先キー」で提供されるボールトと暗号化キーは両方とも有効です。
  • 「共通宛先キー」で提供されるボールトには、「アクティブ」ライフサイクル状態があります。
  • 「共通宛先キー」で提供される暗号化キーには、「有効」ライフサイクル状態があります
  • 「ソース・ボリュームから宛先への暗号化キー・マッピング」で提供されるソース・ボリューム、宛先ボールトおよび暗号化キーはすべて有効です。
  • 「共通宛先キー」または「ソース・ボリュームから宛先への暗号化キー」「マッピング」のいずれかが指定されている場合、両方のメンバー・プロパティを指定することはできません。

移動不可コンピュート・インスタンスのブロック・ボリュームの事前チェック

Full Stack DRは、まず、移動不可能なコンピュート・インスタンスのブロック・ボリュームに対して次の事前チェックを実行します。

コンピュート・インスタンスがロール「プライマリ」でDRPGにメンバーとして追加された場合、新しいメンバー・プロパティ・リストで指定されているブロック・ボリュームIDごとに次の検証を実行します:
  • ブロック・ボリュームIDは、ブロック・ボリュームの有効なOCIDである必要があります。
  • ブロック・ボリュームは、同じコンピュート・インスタンスのメンバー・プロパティに重複しないようにしてください。
  • ブロック・ボリュームはすでにコンピュート・インスタンスにアタッチされている必要があります。
  • ブロック・ボリュームは、DRPGの一部のボリューム・グループ・メンバーである必要があります。
  • アタッチメントの詳細にボリューム・アタッチメント参照インスタンスIDが指定されている場合、そのインスタンスはスタンバイDR保護グループのメンバーであり、ブロック・ボリュームIDをそのメンバー・プロパティに追加する必要があります。
  • アタッチメントの詳細にボリューム・アタッチメント参照インスタンスIDが指定されていない場合、スタンバイDRPG内の1つのコンピュート・インスタンスのみが、このブロック・ボリュームIDで定義されたメンバー・プロパティを持つ必要があります。
  • 定義されているマウントポイントは一意である必要があります。
コンピュート・インスタンスがロールスタンバイでDRPGにメンバーとして追加された場合は、新しいメンバー・プロパティ・リストで指定されているブロック・ボリュームIDごとに次の検証を実行します:
  • ブロック・ボリュームIDは、ブロック・ボリュームの有効なOCIDである必要があります。
  • ブロック・ボリュームは、同じコンピュート・インスタンスのメンバー・プロパティに重複しないようにしてください。
  • ブロック・ボリュームは、プライマリDRPGのリージョンからのものである必要があります。
  • ブロック・ボリュームは、プライマリDRPGの一部のボリューム・グループ・メンバーである必要があります。
  • ボリューム・グループの宛先/ターゲットAD (バックアップまたはレプリカがアクティブ化される場所)は、このスタンバイ・コンピュート・インスタンスのADと一致する必要があります。
  • アタッチメントの詳細にボリューム・アタッチメント参照インスタンスIDが指定されている場合、そのピア・インスタンスはプライマリDRPGのメンバーであり、ブロック・ボリュームをアタッチする必要があります。
  • アタッチメントの詳細にボリューム・アタッチメント参照インスタンスIDが指定されていない場合、プライマリDRPG内の1つのコンピュート・インスタンスのみがブロック・ボリュームをアタッチする必要があります。
  • 定義するマウントポイントは一意である必要があります。
  • 同じデバイス・パスを使用してアタッチするように2つのブロック・ボリュームを構成しないでください。
  • アタッチメントでデバイス・パスを使用する場合、デバイス・パスは使用中であってはなりません。
  • ブロック・ボリュームが複数のコンピュート・インスタンスにアタッチされるように構成されている場合、アタッチメントには共有可能なアクセス権が必要です。

スイッチオーバーおよびフェイルオーバーを使用したオブジェクト・ストレージの事前チェック

Full Stack DRは、オブジェクト・ストレージに対して次の事前チェックを実行します。

  • スイッチオーバー:

    • オブジェクト・ストレージ・バケット- レプリケーションの削除(プライマリ)事前チェック

      • ソース・バケットが存在することを検証します。

      • レプリケーション・ポリシーが存在することを検証します。

      • レプリケーション・ポリシーがピア・リージョンにあることを検証します。

    • オブジェクト・ストレージ・バケット- リバース・レプリケーションの設定(スタンバイ)事前チェック

      • ターゲット・バケットが存在することを検証します

      • ソース・バケットが存在することを検証します。

  • Failover:

    • オブジェクト・ストレージ・バケット- レプリケーションの削除(プライマリ)事前チェック

      • ソース・バケットが「アクティブ」状態であることを検証します。

      • レプリケーション・ポリシーが存在することを検証します。

      • レプリケーション・ポリシーがピア・リージョンにあることを検証します。

      • ターゲット・バケットが「アクティブ」状態であることを検証します。

    • オブジェクト・ストレージ・バケット- リバース・レプリケーションの設定(スタンバイ)事前チェック(エラー発生時に続行)

      • ターゲット・バケットが存在することを検証します。
      • ソース・バケットが存在することを検証します。

データベースの事前チェック(Oracle Base Database Service、Oracle Exadata Database Service on Dedicated Infrastructure、Oracle Exadata Database Service on Exascale Infrastructure、Oracle Exadata Database Service on Cloud@Customer)

データベース・メンバー(Oracle BaseDatabase Service、Oracle Exadata Database Service on Dedicated Infrastructure、Oracle Exadata Database Service on Exascale Infrastructure、Oracle Exadata Database Service on Cloud@Customer)がDRPGの一部である場合、Full Stack DRは次の事前チェックを実行します。Full Stack DRは、次のことを検証します。
  • データベース・メンバー・プロパティが空またはnullではなく、パスワード・シークレット・ボールトの場所がデータベース・メンバー・プロパティの一部です。
  • データベース・パスワードがデータベースに格納され、ピア・データベースがAvailable状態であるシークレット・ボールトにアクセスできます。
  • データベースとピア・データベースのData Guardは有効になり、相互にData Guardピアになります。
  • データベースおよびピア・データベースには、正しいData Guardロールがあります。
  • データベースとピア・データベースは、構成の一部である2つの関連するDR保護グループの一部です。プライマリ・データベースはプライマリDR保護グループの一部であり、スタンバイ・データベースはスタンバイDR保護グループの一部です。

Oracle Autonomous Database Serverlessの事前チェック

Autonomous Databaseサーバーレス・メンバーがDRPGの一部である場合は、Full Stack DRによって次の事前チェックが実行されます。Full Stack DRは、次のことを検証します。
  • Autonomous Databaseメンバー・プロパティが空またはnullではありません。
  • プライマリAutonomousデータベースには空のスタンバイ・データベース・リストがありません。
  • スタンバイAutonomous Databaseはプライマリ・データベース・リージョンと同じリージョンではなく、ローカル・ピアではありません。
  • Autonomous DatabaseおよびピアAutonomous Databaseは、構成の一部である2つの関連するDR保護グループの一部です。
  • リモートData Guardが構成されています。
  • リモート・ピア・データベースはリモートDRPGに属しています。
  • プライマリ・データベースのライフサイクル状態はAVAILABLEです。

    スイッチオーバー事前チェックの場合、Full Stack DRはスタンバイ・データベースで次の追加の検証を実行します。リモート・ピア・スタンバイが正しい(STANDBY)状態であることを確認します。

  • 「宛先暗号化キー」で提供されるボールトおよび暗号化キーが有効な場合。
  • 宛先暗号化キーのボールトIDのライフサイクル状態は「アクティブ」です。
  • 宛先暗号化キーの暗号化IDのライフサイクル状態は「有効」です。

Oracle Autonomous Container Databaseの事前チェック

Autonomous Container DatabaseメンバーがDRPGの一部である場合は、Full Stack DRによって次の事前チェックが実行されます。Full Stack DRは、次のことを検証します。
  • Autonomous Container Databaseメンバー・プロパティが空またはnullではありません。
  • プライマリAutonomous Container Databaseには空のスタンバイ・データベース・リストがありません。
  • 自律型データベースとピア自律型データベースは、構成の一部である2つの関連付けられたDR保護グループの一部です。
  • リモートData Guardが構成されています。
  • リモート・ピア・データベースはリモートDRPGに属しています。
  • プライマリおよびスタンバイAutonomous Containerデータベースのライフサイクル状態は、AVAILABLEです。

    スイッチオーバー事前チェックの場合、Full Stack DRはスタンバイ・データベースで次の追加の検証を実行します。リモート・ピア・スタンバイが正しい(STANDBY)状態であることを確認します。

Kubernetes Engine (OKE)の事前チェック

Full Stack DRは、Kubernetes Engine (OKE)の次の事前チェックを実行します。

プライマリ・クラスタ
  1. プライマリ・クラスタへの接続を確認します。
  2. バックアップが1日より古いかどうかを確認します。
  3. バックアップログをダウンロードして出力します。
  4. プライマリOKEクラスタのライフサイクル状態がアクティブであることを検証します。
  5. プライマリ・メンバー・プロパティのネームスペースおよびバケットが存在し、有効であることを検証します。
  6. プライマリ・メンバー・プロパティのバックアップ・スケジュールがRFC 5545形式であることを検証します。
    • サポートされていないルール部分を検証します。
    • 各ルール・パートの範囲を検証します。
  7. 次の制約について、プライマリ・メンバー・プロパティのロード・バランサ・マッピングを検証します。
    • SourceLoadBalancerIdおよびDestinationLoadBalancerIdには、LOADBALANCERのOCIDsがあります。
    • ロード・バランサ・マッピングは一意である必要があります。
      • A-B、C-B ->不可
      • A-B、A-D ->許可されていません
        ノート

        たとえば、プライマリ・リージョンに2つのロード・バランサのセットがある場合(load_balancer_A and load_balancer_Cなど)。スタンバイ・リージョンには、2つのロード・バランサの別のセットがあります(load_balancer_B and load_balancer_Dなど)。そのため、OKEクラスタをメンバーとして追加する際には、ロード・バランサ・マッピング・プロパティを追加する必要があります。このマップでは、次のマッピングのみが許可されます。 
        load_balancer_A <--> load_balancer_B & load_balancer_C <--> load_balancer_D 
or load_balancer_C <--> load_balancer_B & load_balancer_A <--> load_balancer_D
        .ただし、load_balancer_Bが両方のマッピングで宛先ロード・バランサとして設定されているため、次のマッピングは許可されません。 
        load_balancer_A <--> load_balancer_B & load_balancer_C <--> load_balancer_B
  8. プライマリ・メンバー・プロパティのネットワーク・ロード・バランサ・マッピングで、次の制約を検証します。
    • SourceNetworkLoadBalancerIdおよびDestinationNetworkLoadBalancerIdには、NETWORKLOADBALANCERのOCIDsがあります。
    • ネットワーク・ロード・バランサ・マッピングは一意である必要があります。
      • A-B、C-B ->不可
      • A-B、A-D ->許可されていません
        ノート

        たとえば、プライマリ・リージョンに2つのネットワーク・ロード・バランサのセットがある場合( network_load_balancer_A and network_load_balancer_Cなど)。スタンバイ・リージョンには、2つのネットワーク・ロード・バランサの別のセットがあります(network_load_balancer_B and network_load_balancer_Dなど)。そのため、OKEクラスタをメンバーとして追加する際には、ネットワーク・ロード・バランサ・マッピング・プロパティを追加する必要があります。このマップでは、次のマッピングのみが許可されます。 
        network_load_balancer_A <--> network_load_balancer_B & network_load_balancer_C <--> network_load_balancer_D 
or network_load_balancer_C <--> network_load_balancer_B & network_load_balancer_A <--> network_load_balancer_D
  9. 次の制約について、プライマリ・メンバー・プロパティのボールト・マッピングを検証します。
    • SourceVaultIdおよびDestinationVaultIdには、VAULTのOCIDsがあります。
    • Vaultマッピングは一意である必要があります。
      • A-B、C-B ->許可されていません。
      • A-B、A-D ->許可されていません。
        ノート

        たとえば、プライマリ・リージョンに2つのボールトのセットがある場合( vault_A and vault_Cなど)。スタンバイ・リージョンに2つのボールトの別のセット(vault_B and vault_Dなど)があります。そのため、OKEクラスタをメンバーとして追加する際には、ボールト・マッピング・プロパティを追加する必要があります。このマップでは、次のマッピングのみが許可されます。 
        vault_A  <--> vault_B & vault_C <--> vault_D 
or vault_C <--> vault_B & vault_A <--> vault_D
  10. プライマリメンバープロパティーのピアクラスタIDとバックアップの場所が空でないことを検証します。
  11. 次の制約について、プライマリ・メンバー・プロパティのジャンプ・ホストを検証します。
    • DR保護グループには、ジャンプ・ホストと同じOCIDのコンピュート・インスタンスが含まれている必要があります。
    • ジャンプ・ホストは、移動不可能なコンピュート・インスタンスである必要があります。
    • ジャンプ・ホストには、ライフサイクル状態がRUNNINGである必要があります。
  12. 次の制約について、プライマリメンバープロパティーのピアクラスタIDを検証します。
    • ピアDR保護グループにピア・クラスタIDを持つクラスタがあることを検証します。
    • メンバー・クラスタ自体がピア・クラスタとして追加されていないことを検証します。
    • メンバープロパティーに指定されたピアクラスタが、DR保護グループ内のほかの OKEクラスタのピアクラスタとして追加されていないことを検証します。
  13. 次の制約について、プライマリ・リージョンのOKEクラスタ内のノード・プールを検証します。
    • すべてのノード・プールのノード数が少なくとも1つであることを検証します。
    • すべてのノード・プールに少なくとも1つのアクティブ・ノードがあることを確認します。
    • 例: 2つのノード・プールがあり、1つのノードにアクティブなノードがなく、もう1つのノードにアクティブなノードがある場合、例外が発生します。
  14. 次の制約について、プライマリ・メンバー・プロパティのソース・ロード・バランサIDを検証します。
    • ライフサイクルはアクティブである必要があります。
    • ロード・バランサに含めることができるのはリージョナル・サブネットのみです。
  15. 次の制約について、プライマリ・メンバー・プロパティのソース・ネットワーク・ロード・バランサIDを検証します。
    • ライフサイクルはアクティブである必要があります。
    • ネットワーク・ロード・バランサに含めることができるのはリージョナル・サブネットのみです。
  16. プライマリ・メンバー・プロパティのソース・ボールトIDがアクティブであることを検証します。
  17. 次の制約について、プライマリ・メンバー・プロパティの管理対象ノード・プール構成を検証します。
    • メンバー・タイプはMANAGEDである必要があります。
    • ライフサイクルはACTIVEである必要があります。
    • クラスタ内のすべてのノード・プールのノード数の合計(管理対象ノード構成または既存のノード数のいずれか大きい方)が、制限を超えないようにする必要があります。
  18. 次の制約について、プライマリ・メンバー・プロパティの仮想ノード・プール構成を検証します。
    • メンバー・タイプは「仮想」である必要があります。
    • ライフサイクルはACTIVEである必要があります。
    • クラスタ内のすべてのノード・プールのノード数の合計(仮想ノード構成または既存のノード数のいずれか大きい方)が、制限を超えないようにする必要があります。

スタンバイ・クラスタ

  1. ネームスペースがバックアップの一部であるか、または一部であるかを確認します。
  2. 永続ボリュームで参照されるすべてのブロック・ボリュームがDR保護グループの一部かどうかを確認します。
  3. 永続ボリュームで参照されるすべてのファイル・システム/マウント・ターゲットがDR保護グループの一部であるかどうかを確認します。
  4. イングレス・クラスで参照されるすべてのロード・バランサがDR保護グループの一部であるかどうかを確認します。
  5. secretproviderclassesで参照されるすべてのボールトがDR保護グループの一部かどうかを確認します。
  6. カスタム・リソース定義がスタンバイ・クラスタ・バージョンと互換性があるかどうかを確認します。
  7. スタンバイOKEクラスタのライフサイクル状態がアクティブであることを検証します。
  8. スタンバイ・メンバー・プロパティのピア・クラスタIDおよびバックアップの場所が空でないことを検証します。
  9. 次の制約について、スタンバイ・メンバー・プロパティのジャンプ・ホストを検証します。
    • DR保護グループには、ジャンプ・ホストと同じOCIDのコンピュート・インスタンスが含まれている必要があります。
    • ジャンプ・ホストは、移動不可能なコンピュート・インスタンスである必要があります。
    • ジャンプ・ホストには、ライフサイクル状態がRUNNINGである必要があります。
  10. 次の制約について、スタンバイ・メンバー・プロパティのピア・クラスタIDを検証します。
    • ピアDR保護グループにピア・クラスタIDを持つクラスタがあることを確認します。
    • メンバー・クラスタ自体がピア・クラスタとして追加されていないことを検証します。
    • メンバープロパティーに指定されたピアクラスタが、DR保護グループ内のほかの OKEクラスタのピアクラスタとして追加されていないことを検証します。
  11. 次の制約について、プライマリ・メンバー・プロパティの宛先ロード・バランサIDを検証します。
    • ライフサイクルはアクティブである必要があります。
    • ロード・バランサに含めることができるのはリージョナル・サブネットのみです。
  12. 次の制約について、プライマリ・メンバー・プロパティの宛先ネットワーク・ロード・バランサIDを検証します。
    • ライフサイクルはアクティブである必要があります。
    • ネットワーク・ロード・バランサに含めることができるのはリージョナル・サブネットのみです。
    • プライマリ・メンバー・プロパティの宛先ボールトIDがアクティブであることを検証します。
  13. 次の制約について、スタンバイ・メンバー・プロパティの管理対象ノード・プール構成を検証します。
    • メンバー・タイプはMANAGEDである必要があります。
    • ライフサイクルはアクティブである必要があります。
    • クラスタ内のすべてのノード・プールのノード数の合計(管理対象ノード構成または既存のノード数のいずれか大きい方)が、制限を超えないようにする必要があります。
  14. 次の制約について、スタンバイ・メンバー・プロパティの仮想ノード・プール構成を検証します。
    • メンバー・タイプは「仮想」である必要があります。
    • ライフサイクルはアクティブである必要があります。
    • クラスタ内のすべてのノード・プールのノード数の合計(仮想ノード構成または既存のノード数のいずれか大きい方)が、制限を超えないようにする必要があります。
  15. 次の制約について、スタンバイ・リージョンのOKEクラスタのノード・プールを検証します。
    • すべてのノード・プールのノード数が少なくとも1つであることを検証します。
    • すべてのノード・プールに少なくとも1つのアクティブ・ノードがあることを確認します。
  16. 宛先クラスタ・ノード・プールが、FSS/ブロックをリストアする各ADに少なくとも1つのノードを持つ必要があることを検証します。
  17. 次のルールが設定されていることを確認して、クラスタで提供されるノード・プールおよび仮想ノード・プールのサブネット/ネットワーク・セキュリティ・グループで定義されたsecurityListおよびNSGルールを検証します。
    • ステートフル・イングレス・ルール
      • TCPポート111、2048、2049、2050、および
      • UDPポート111および2048
    • ステートフル・エグレス・ルール
      • TCPソース・ポート111、2048、2049および2050、および
      • UDPソースポート111。
        ノート

        検証は、OKEクラスタにファイル・システムのPVまたはPVCがある場合にのみ適用されます。Full Stack DRでは、次のシナリオのみが検証されます。
        • シナリオA: マウント・ターゲットとインスタンスは異なるサブネットにあります(推奨)。
        • シナリオB: マウント・ターゲットとインスタンスは、同じサブネットにあります。
          Full Stack DRでは、次のシナリオは検証されません。
          • シナリオC: マウント・ターゲットおよびインスタンスでは、TLS転送中暗号化を使用します。
          • シナリオD: マウント・ターゲットは認可にLDAPを使用します。

MySQL HeatWave DB Systemの事前チェック

フル・スタックDRは、MySQL DB Systemに対して次の事前チェックを実行します:

  • スイッチオーバー:
    • プライマリおよびスタンバイのMySQL HeatWave DBシステムのライフサイクル状態がアクティブ状態であることを検証します。
    • ターゲットDB SystemがピアDR保護グループにメンバーとして存在することを検証します。メンバーには、プライマリMySQL DB System OCIDに一致するターゲットDB Systemプロパティも含まれます。
    • プライマリMySQL DB Systemが読取り/書込みモードであることを検証します。
    • ターゲットMySQL DB Systemが読取り専用モードであることを検証します。
    • 管理者およびレプリケーション・ユーザーに提供されるプライマリMySQL DB Systemボールト・シークレットが「使用可能」状態であることを検証します。
    • 管理者およびレプリケーション・ユーザーに指定されたスタンバイMySQL DB Systemボールト・シークレットが「使用可能」状態であることを検証します。
    • プライマリMySQL DB SystemとターゲットMySQL DB Systemの間にアクティブ・チャネルが存在することを検証します。
      ノート

      障害が発生した場合、フル・スタックDRに警告が表示されます。
    • コンテナ・インスタンスとMySQL DBノードの両方の間の接続性を検証します。
    • プライマリDBシステムとターゲットDBシステムの両方に対してGTID実行が存在することを検証します。
  • フェイルオーバー :
    • スタンバイMySQL DB Systemのライフサイクル状態が「アクティブ」状態であることを検証します。
    • ターゲットDB Systemが、プライマリMySQL DB System OCIDに一致するターゲットDB Systemプロパティを持つメンバーとしてピアDR保護グループに存在することを検証します。
    • ターゲットMySQL DB Systemが「読取り」モードであることを検証します。
    • 管理およびレプリケーション・ユーザーに提供されるスタンバイMySQL DB Systemボールト・シークレットがAvailabe状態であることを検証します。
    • プライマリMySQL DB SystemとターゲットMySQL DBシステムの間にアクティブ・チャネルが存在することを検証します。
    • コンテナ・インスタンスと両方のMySQL DBノード間の接続性を検証します。
    • GTID実行がプライマリDBシステムとターゲットDBシステムの両方に存在することを検証します。
  • 開始ドリル:
    • プライマリおよびスタンバイDB Systemの両方のMySQL DB Systemのライフサイクル状態がアクティブ状態であることを検証します。
    • ターゲットDB Systemが、プライマリMySQL DB System OCIDに一致するターゲットDB Systemプロパティを持つメンバーとしてピアDR保護グループに存在することを検証します。
    • プライマリMySQL DB Systemが読取り/書込みモードであることを検証します。
    • ターゲットMySQL DB Systemが読取りモードであることを検証します。
    • リストアするターゲットMySQL DB Systemにバックアップが存在することを検証します。
    • プライマリMySQL DB SystemとターゲットMySQL DBシステムの間にアクティブ・チャネルが存在することを検証します。
  • ドリルの停止:

    リストアされたMySQL DBがピア・リージョンに存在し、クリーン・アップされていることを確認します。

親トピック: リファレンス