1. Kubernetesクラスタ内のOracle Identity and Access Managementのためのエンタープライズ・デプロイメント・ガイド
  2. エンタープライズ・デプロイメントについて
  3. ディザスタ・リカバリ

5 ディザスタ・リカバリ

ディザスタ・リカバリ戦略は、製品ごとに異なります。この章では、各製品のディザスタ・リカバリ・プロセスについて説明します。

この章の内容は次のとおりです。

  • Kubernetesクラスタ
    各サイトに1つずつ、2つの独立したKubernetesクラスタが存在します。これらのKubernetesクラスタは、対称である必要はありません。ただし、どちらのクラスタにも、フェイルオーバーやスイッチオーバーの際に、アプリケーションを実行するための予備の容量が必要です。
  • Oracle HTTP Server
    Oracle HTTP Serverの構成は静的です。そのため、Oracle HTTP Serverは、プライマリ・サイトとスタンバイ・サイトに独立してインストールされます。
  • イングレス
    イングレス・コントローラ構成は静的です。そのため、イングレス・コントローラは、プライマリ・サイトとスタンバイ・サイトに独立してインストールされます。
  • WebLogic Operator
    Oracle WebLogic Operator構成は静的です。そのため、Operatorは、プライマリ・サイトとスタンバイ・サイトに独立してインストールされます。
  • Oracle Unified Directory
    Kubernetesで推奨される方法は、プライマリ・サイトからディザスタ・リカバリ・サイトに永続ボリュームをレプリケートすることです。これは、アクティブ/パッシブ・ソリューションです。
  • Oracle Access Manager
    Oracle Access Managerのディザスタ・リカバリは、アクティブ/パッシブ・モデルを使用して実現します。現在、Oracle Access Managerのマルチデータセンターの使用は、Kubernetes環境ではサポートされていません。
  • Oracle Identity Governance
    Oracle Identity Governance (OIG)のディザスタ・リカバリは、アクティブ/パッシブ・モデルを使用して実現します。
  • Oracle Identity Role Intelligence
    Oracle Identity Role Intelligence (OIRI)のディザスタ・リカバリは、アクティブ/パッシブ・モデルを使用して実現します。
  • Oracle Advanced Authentication、Oracle Adaptive Risk ManagementおよびOracle Universal Authenticator
    Oracle Advanced Authentication (OAA)およびOracle Adaptive Risk Management (OARM)のディザスタ・リカバリは、アクティブ/パッシブ・モデルを使用して実現します。
  • Prometheus、Grafana、Elastic SearchおよびGrafana
    これらは、オラクル製品ではありません。そのため、これらのディザスタ・リカバリの方法は、このドキュメントの対象外です。これらの製品のディザスタ・リカバリを有効にする方法の詳細は、該当する製品ドキュメントを参照してください。
  • ディザスタ・リカバリの設定のロードマップ
    この項では、Oracle Identity and Access Managementスイート全体のディザスタ・リカバリの設定に必要なステップの概要を示します。

親トピック: エンタープライズ・デプロイメントについて

Kubernetesクラスタ

各サイトに1つずつ、2つの独立したKubernetesクラスタが存在します。これらのKubernetesクラスタは、対称である必要はありません。ただし、どちらのクラスタにも、フェイルオーバーやスイッチオーバーの際に、アプリケーションを実行するための予備の容量が必要です。

各クラスタは、個別に作成および管理されます。クラスタ内でアプリケーションが起動していることの確認を担うのは、Kubernetesスケジューリングです。外部依存性はありません。すべての製品のディザスタ・リカバリ・ソリューションは、クラスタ内で実行されているプロセスに限定されます。

親トピック: ディザスタ・リカバリ

Oracle HTTP Server

Oracle HTTP Serverの構成は静的です。そのため、Oracle HTTP Serverは、プライマリ・サイトとスタンバイ・サイトに独立してインストールされます。

構成の変更は、各サイトに手動で個別に適用します。

親トピック: ディザスタ・リカバリ

イングレス

イングレス・コントローラ構成は静的です。そのため、イングレス・コントローラは、プライマリ・サイトとスタンバイ・サイトに独立してインストールされます。

構成の変更は、各サイトに手動で個別に適用します。

親トピック: ディザスタ・リカバリ

WebLogic Operator

Oracle WebLogic Operator構成は静的です。そのため、Operatorは、プライマリ・サイトとスタンバイ・サイトに独立してインストールされます。

構成の変更は、各サイトに手動で個別に適用します。

親トピック: ディザスタ・リカバリ

Oracle Unified Directory

従来のオンプレミス・デプロイメントでは、2つの独立したOracle Unified Directory (OUD)クラスタが、プライマリ・サイトとスタンバイ・サイトに設定されます。各サイトは別々のレプリケーション・グループに属し、両方のサイトをOUDレプリケーション承諾に統合することで結合されます。現時点では、このタイプの統合をKubernetesで行うことはできません。Kubernetesで推奨される方法は、プライマリ・サイトからディザスタ・リカバリ・サイトに永続ボリュームをレプリケートすることです。これは、アクティブ/パッシブ・ソリューションです。

図5-1 OUDのディザスタ・リカバリ


OUDのディザスタ・リカバリ

アクティブ/パッシブ・ソリューションを実現する方法は、いくつかあります:

  • ディスク・ベースのレプリケーション。
  • プロセス主導のレプリケーションでは、インスタンスのバックアップ・コピーがローカルに作成され、スタンバイ・システムに転送されてから、リモート・システムに再適用されます。このオプションでは、スタンバイ・システムで一部のデータを使用できない可能性のあるラグが発生する場合があります。

OUDのディザスタ・リカバリを設定する全体的なプロセスには、次のステップがあります:

  1. 標準的な手順で、プライマリ・サイトにOUDをインストールします。
  2. 標準的な手順で、セカンダリ・サイトにOUDをインストールします。
  3. スタンバイ・サイトからインスタンス・データを削除します。
  4. プライマリ・サイトとスタンバイ・サイト間の永続ボリュームのレプリケーションを有効にします。

詳細は、「Oracle Unified Directoryのディザスタ・リカバリの構成」を参照してください。

スイッチオーバーの場合は、次のステップを実行します:

  1. 永続ボリュームのレプリケーションを停止します。
  2. プライマリ・サイトでOUDを停止します。
  3. スタンバイ・サイトでOUDを起動します。
  4. 永続ボリュームの逆方向でのレプリケーションを有効にします。

フェイルオーバーの場合は、次のステップを実行します:

  1. 永続ボリュームのレプリケーション/アプリケーションを停止します。
  2. 可能な場合は、プライマリ・サイトでOUDを停止します。
  3. スタンバイ・サイトでOUDを起動します。
  4. サイトが使用可能な場合は、永続ボリュームの逆方向でのレプリケーションを有効にするか、前述のステップでプライマリ・サイトを再作成します。

親トピック: ディザスタ・リカバリ

Oracle Access Manager

Oracle Access Managerのディザスタ・リカバリは、アクティブ/パッシブ・モデルを使用して実現します。現在、Oracle Access Managerのマルチデータセンターの使用は、Kubernetes環境ではサポートされていません。

図5-2 OAMのディザスタ・リカバリ


OAMのディザスタ・リカバリ

ディザスタ・リカバリ・ソリューションに関する考慮事項:

  • 構成内のすべてのロード・バランサ(プライマリ/スタンバイ)に、同じSSL証明書が含まれます。
  • Oracle Access Managerのアプリケーション・データはOracle Database内に格納され、Oracle Data Guardを使用してスタンバイ・サイトにレプリケートされます。
  • 構成情報(ドメイン定義)は、ファイル・システム・レプリケーションを使用してレプリケートされます。このプロセスでは、永続ボリュームでrsyncなどのレプリケーション・ツールが使用されます。構成情報はほとんど変更されないため、頻繁なレプリケーションは必要ありません。
  • 構成情報がスタンバイ・サイトにレプリケートされると、スタンバイ・サイトのスタンバイ・データベースを指すよう、すべてのデータベース接続が変更されます。

詳細は、「Oracle Access Managerのディザスタ・リカバリの構成」を参照してください。

OAMのディザスタ・リカバリを設定する全体的なプロセスには、次のステップがあります:

  1. 標準的な手順で、プライマリ・サイトにOAMをインストールします。
  2. 標準的な手順でスタンバイ・サイトにOAMをインストールするか、プライマリKubernetesクラスタからKubernetesオブジェクトをバックアップして、スタンバイ・クラスタにリストアします。
  3. データベースがPRIMARYまたはSNAPSHOT STANDBYのロールで機能している場合にのみアクティブになるよう、データベース・サービスを変更します。
  4. スタンバイ・サイトから構成データを削除します(新しい環境を作成した場合)。
  5. スタンバイ・サイトからデータベースを削除します。
  6. プライマリ・サイトとスタンバイ・サイト間の永続ボリュームのレプリケーションを有効にします。
  7. プライマリ・サイトとスタンバイ・サイト間でData Guardのレプリケーションを有効にします。
  8. アプリケーション・データベース・サービスをスタンバイ・データベースにレプリケートします。
  9. スタンバイ・データベースを使用するよう、スタンバイ・サイトのデータベース接続の詳細を変更します。

スイッチオーバーの場合は、次のステップを実行します:

  1. 永続ボリュームのレプリケーションを停止します。
  2. プライマリ・サイトでOAMを停止します。
  3. スタンバイ・データベースにスイッチ・オーバーします。
  4. スタンバイ・サイトでOAMを起動します。
  5. 永続ボリュームの逆方向でのレプリケーションを有効にします。
  6. Data Guardの逆方向でのレプリケーションを有効にします。

フェイルオーバーの場合は、次のステップを実行します:

  1. 永続ボリュームのレプリケーション/アプリケーションを停止します。
  2. プライマリ・サイトでOAMを停止します(可能な場合)。
  3. スタンバイ・サイトで、スタンバイ・データベースをアクティブ化/フェイルオーバーします。
  4. スタンバイ・サイトでOAMを起動します。
  5. サイトが使用可能な場合は、永続ボリュームの逆方向でのレプリケーションを有効にするか、前述のステップでプライマリ・サイトを再作成します。
  6. サイトが使用可能な場合は、Data Guardの逆方向でのレプリケーションを有効にするか、前述のステップで旧プライマリ・サイトにデータベースを再作成します。

親トピック: ディザスタ・リカバリ

Oracle Identity Governance

Oracle Identity Governance (OIG)のディザスタ・リカバリは、アクティブ/パッシブ・モデルを使用して実現します。

図5-3 OIGのディザスタ・リカバリ


OIGのディザスタ・リカバリ

ディザスタ・リカバリ・ソリューションに関する考慮事項:

  • OIGのアプリケーション・データはOracle Database内に格納され、Oracle Data Guardを使用してスタンバイ・サイトにレプリケートされます。
  • 構成情報(ドメイン定義)は、ファイル・システム・レプリケーションを使用してレプリケートされます。このプロセスでは、永続ボリュームでrsyncなどのレプリケーション・ツールが使用されます。構成情報はほとんど変更されないため、頻繁なレプリケーションは必要ありません。
  • 構成情報がスタンバイ・サイトにレプリケートされると、スタンバイ・サイトのスタンバイ・データベースを指すよう、すべてのデータベース接続が変更されます。

詳細は、「Oracle Identity Governanceのディザスタ・リカバリの構成」を参照してください。

OIGのディザスタ・リカバリを設定する全体的なプロセスには、次のステップがあります:

  1. 標準的な手順で、プライマリ・サイトにOIGをインストールします。
  2. 標準的な手順でスタンバイ・サイトにOIGをインストールするか、プライマリKubernetesクラスタからKubernetesオブジェクトをバックアップして、スタンバイ・クラスタにリストアします。
  3. データベースがPRIMARYまたはSNAPSHOT STANDBYのロールで機能している場合にのみアクティブになるよう、データベース・サービスを変更します。
  4. スタンバイ・サイトから構成データを削除します(新しい環境を作成した場合)。
  5. スタンバイ・サイトからデータベースを削除します。
  6. プライマリ・サイトとスタンバイ・サイト間の永続ボリュームのレプリケーションを有効にします。
  7. プライマリ・サイトとスタンバイ・サイト間でData Guardのレプリケーションを有効にします。
  8. アプリケーション・データベース・サービスをスタンバイ・データベースにレプリケートします。
  9. スタンバイ・データベースを使用するよう、スタンバイ・サイトのデータベース接続の詳細を変更します。

スイッチオーバーの場合は、次のステップを実行します:

  1. 永続ボリュームのレプリケーションを停止します。
  2. プライマリ・サイトでOIGを停止します。
  3. スタンバイ・データベースにスイッチ・オーバーします。
  4. スタンバイ・サイトでOIGを起動します。
  5. 永続ボリュームの逆方向でのレプリケーションを有効にします。
  6. Data Guardの逆方向でのレプリケーションを有効にします。

フェイルオーバーの場合は、次のステップを実行します:

  1. 永続ボリュームのレプリケーション/アプリケーションを停止します。
  2. プライマリ・サイトでOIGを停止します(可能な場合)。
  3. スタンバイ・サイトで、スタンバイ・データベースをアクティブ化/フェイルオーバーします。
  4. スタンバイ・サイトでOIGを起動します。
  5. サイトが使用可能な場合は、永続ボリュームの逆方向でのレプリケーションを有効にするか、前述のステップでプライマリ・サイトを再作成します。
  6. サイトが使用可能な場合は、Data Guardの逆方向でのレプリケーションを有効にするか、前述のステップで旧プライマリ・サイトにデータベースを再作成します。

親トピック: ディザスタ・リカバリ

Oracle Identity Role Intelligence

Oracle Identity Role Intelligence (OIRI)のディザスタ・リカバリは、アクティブ/パッシブ・モデルを使用して実現します。

図5-4 OIRIのディザスタ・リカバリ


OIRIのディザスタ・リカバリ

ディザスタ・リカバリ・ソリューションに関する考慮事項:

  • OIRIのアプリケーション・データはOracle Database内に格納され、Oracle Data Guardを使用してスタンバイ・サイトにレプリケートされます。
  • 構成情報(ドメイン定義)は、ファイル・システム・レプリケーションを使用してレプリケートされた永続ボリュームに格納されます。このプロセスでは、永続ボリュームでrsyncなどのレプリケーション・ツールが使用されます。構成情報はほとんど変更されないため、頻繁なレプリケーションは必要ありません。
  • 構成情報がスタンバイ・サイトにレプリケートされると、スタンバイ・サイトのスタンバイ・データベースを指すよう、すべてのデータベース接続が変更されます。
  • OIGデータベースなどのデータベースがスイッチ・オーバーされた場合は、スタンバイ・バージョンを指すようにデータベース接続を更新します。
  • OIRIはKubernetesフレームワークと密接に統合されているため、クラスタと直接やり取りして、データ収集タスクを実行できます。デプロイ後、OIRIには、実行されているクラスタに関する情報が格納されます。別のKubernetesクラスタからOIRIを実行する場合は、データベース接続情報だけでなく、Kubernetesクラスタ情報も更新する必要があります。

詳細は、「Oracle Identity Role Intelligenceのディザスタ・リカバリの構成」を参照してください。

OIRIのディザスタ・リカバリを設定する全体的なプロセスには、次のステップがあります:

  1. 標準的な手順で、プライマリ・サイトにOIRIをインストールします。
  2. 標準的な手順でスタンバイ・サイトにOIRIをインストールするか、プライマリKubernetesクラスタからKubernetesオブジェクトをバックアップして、スタンバイ・クラスタにリストアします。
  3. データベースがPRIMARYまたはSNAPSHOT STANDBYのロールで機能している場合にのみアクティブになるよう、データベース・サービスを変更します。
  4. スタンバイ・サイトから構成データを削除します(新しい環境を作成した場合)。
  5. スタンバイ・サイトからデータベースを削除します。
  6. プライマリ・サイトとスタンバイ・サイト間の永続ボリュームのレプリケーションを有効にします。
  7. プライマリ・サイトとスタンバイ・サイト間でData Guardのレプリケーションを有効にします。
  8. アプリケーション・データベース・サービスをスタンバイ・データベースにレプリケートします。
  9. スタンバイ・データベースを使用するよう、スタンバイ・サイトのデータベース接続の詳細を変更します。
  10. スタンバイKubernetesクラスタを使用するよう、スタンバイ・サイトのKubernetesクラスタ接続の詳細を変更します。

スイッチオーバーの場合は、次のステップを実行します:

  1. 永続ボリュームのレプリケーションを停止します。
  2. プライマリ・サイトでOIRIを停止します。
  3. スタンバイ・データベースにスイッチ・オーバーします。
  4. スタンバイ・サイトでOIRIを起動します。
  5. 永続ボリュームの逆方向でのレプリケーションを有効にします。
  6. Data Guardの逆方向でのレプリケーションを有効にします。

フェイルオーバーの場合は、次のステップを実行します:

  1. 永続ボリュームのレプリケーション/アプリケーションを停止します。
  2. プライマリ・サイトでOIRIを停止します(可能な場合)。
  3. スタンバイ・サイトで、スタンバイ・データベースをアクティブ化します。
  4. スタンバイ・サイトでOIRIを起動します。
  5. サイトが使用可能な場合は、永続ボリュームの逆方向でのレプリケーションを有効にするか、前述のステップでプライマリ・サイトを再作成します。
  6. サイトが使用可能な場合は、Data Guardの逆方向でのレプリケーションを有効にするか、前述のステップで旧プライマリ・サイトにデータベースを再作成します。

親トピック: ディザスタ・リカバリ

Oracle Advanced Authentication、Oracle Adaptive Risk ManagementおよびOracle Universal Authenticator

Oracle Advanced Authentication (OAA)およびOracle Adaptive Risk Management (OARM)のディザスタ・リカバリは、アクティブ/パッシブ・モデルを使用して実現します。

図5-5 OAAのディザスタ・リカバリ


OAAのディザスタ・リカバリ

ディザスタ・リカバリ・ソリューションに関する考慮事項:

  • 構成内のすべてのロード・バランサ(プライマリ/スタンバイ)に、同じSSL証明書が含まれます。
  • OAAのアプリケーション・データはOracle Database内に格納され、Oracle Data Guardを使用してスタンバイ・サイトにレプリケートされます。
  • 構成情報とボールトは、ファイル・システム・レプリケーションを使用してレプリケートされます。このプロセスでは、永続ボリュームでrsyncなどのレプリケーション・ツールが使用されます。構成情報はほとんど変更されないため、頻繁なレプリケーションは必要ありません。
  • 構成情報がスタンバイ・サイトにレプリケートされると、スタンバイ・サイトのスタンバイ・データベースを指すよう、すべてのデータベース接続が変更されます。
  • OAAでは、複数のKubernetesオブジェクトに構成情報が格納されます。そのため、Kubernetesオブジェクトをバックアップしてリストアするよりも、更新された接続情報でスタンバイ・サイトにアプリケーションを再デプロイする方が簡単です。
  • OAAはKubernetesフレームワークと密接に統合されているため、クラスタと直接やり取りして、データ収集タスクを実行できます。デプロイ後、OAAには、実行されているクラスタに関する情報が格納されます。別のサイトからOAAを実行する場合は、データベース接続情報だけでなく、Kubernetesクラスタ情報も更新する必要があります。これは、サイト間でレプリケートしないでください。
  • OAAは、OAuth検証のために、Oracle Access Manager (OAM)と密接に関連付けられています。そのため、OAAはいつでも、OAMにアクセスできる必要があります。OAMマルチデータセンター構成を使用している場合は、各OAMデプロイメントにOAuthドメインが必要です。アクティブ/パッシブのOAMディザスタ・リカバリ・ソリューションを使用している場合は、アクティブなOAAが、アクティブなOAMサイトにアクセスする必要があります。

OAAのディザスタ・リカバリを設定する全体的なプロセスには、次のステップがあります:

  1. 標準的な手順で、プライマリ・サイトにOAAをインストールします。
  2. スタンバイ・システムにOAA管理コンテナを作成します。
  3. プライマリ・サイトとスタンバイ・サイト間の永続ボリュームのレプリケーションを有効にします(Kubernetes構成は除く)。
  4. プライマリ・サイトとスタンバイ・サイト間でData Guardのレプリケーションを有効にします。
  5. アプリケーション・データベース・サービスをスタンバイ・データベースにレプリケートします。
  6. データベースがPRIMARYまたはSNAPSHOT STANDBYのロールで機能している場合にのみアクティブになるよう、データベース・サービスを変更します。
  7. Data GuardデータベースをSNAPSHOT STANDBYデータベースに変換します。
  8. installOAA.propertiesファイルのデータベース接続情報を更新し、database.createschema=falseを設定します。
  9. OAA.shを再実行してアプリケーションを再デプロイし、スタンバイ・サイトにOAAをインストールします。このコマンドを実行する前に、ファイル・システム(ログ永続ボリュームを含む)をプライマリからスタンバイにレプリケートすることが重要です。このコマンドにより、スタンバイ・サイトにKubernetesオブジェクトが作成されます。
  10. 構成を検証します。
  11. OAAデプロイメントを停止し、Data Guardデータベースをフィジカル・スタンバイに戻します。

詳細は、「Oracle Advanced Authenticationのディザスタ・リカバリの構成」を参照してください。

スイッチオーバーの場合は、次のステップを実行します:

  1. 永続ボリュームのレプリケーションを停止します。
  2. プライマリ・サイトでOAAを停止します。
  3. スタンバイ・データベースにスイッチ・オーバーします。
  4. スタンバイ・サイトでOAAを起動します。
  5. 永続ボリュームの逆方向でのレプリケーションを有効にします。
  6. Data Guardの逆方向でのレプリケーションを有効にします。

フェイルオーバーの場合は、次のステップを実行します:

  1. 永続ボリュームのレプリケーション/アプリケーションを停止します。
  2. プライマリ・サイトでOAAを停止します(可能な場合)。
  3. スタンバイ・サイトで、スタンバイ・データベースをアクティブ化します。
  4. スタンバイ・サイトでOAAを起動します。
  5. サイトが使用可能な場合は、永続ボリュームの逆方向でのレプリケーションを有効にするか、前述のステップでプライマリ・サイトを再作成します。
  6. サイトが使用可能な場合は、Data Guardの逆方向でのレプリケーションを有効にするか、前述のステップで旧プライマリ・サイトにデータベースを再作成します。

親トピック: ディザスタ・リカバリ

Prometheus、Grafana、Elastic SearchおよびGrafana

これらは、オラクル製品ではありません。そのため、これらのディザスタ・リカバリの方法は、このドキュメントの対象外です。これらの製品のディザスタ・リカバリを有効にする方法の詳細は、該当する製品ドキュメントを参照してください。

親トピック: ディザスタ・リカバリ

ディザスタ・リカバリの設定のロードマップ

この項では、Oracle Identity and Access Managementスイート全体のディザスタ・リカバリの設定に必要なステップの概要を示します。

  1. プライマリ・サイトとスタンバイ・サイト間の通信を有効にします。
  2. ローカル・インストールを指すよう、各サイトでロード・バランサを設定します。
  3. ロード・バランサが同じSSL証明書を使用していることを確認します。
  4. Oracleデータベース用のData Guardをスタンバイ・サイトに設定します。
  5. スタンバイ・サイトにOracle HTTP Server (OHS)をインストールします。
  6. OHS構成をプライマリ・サイトからスタンバイ・サイトにコピーし、スタンバイ・サイトへのルーティングを変更します。
  7. スタンバイ・サイトにイングレス・コントローラをインストールします(使用している場合)。
  8. スタンバイ・サイトにOracle WebLogic Operatorをインストールします。
  9. Kubernetesスナップショットを使用するか、フレッシュ・インストールとデータの削除を実行して、スタンバイ・サイトにOUDをデプロイします。
  10. プライマリ・サイトとスタンバイ・サイト間のOUD永続ボリューム同期を有効にします。
  11. スタンバイ・データベースをスナップショット・スタンバイに変換します。
  12. Kubernetesスナップショットを使用するか、フレッシュ・インストールとデータの削除を実行して、スタンバイ・サイトにOAMをデプロイします。
  13. プライマリ・サイトとスタンバイ・サイト間のOAM永続ボリューム同期を有効にします。
  14. 必要に応じて、スタンバイ・サイトのOAMデータベース接続設定を変更します。
  15. プライマリ・サイトのWebGateアーティファクトを使用して、OHSにWebGateをデプロイします。
  16. Kubernetesスナップショットを使用するか、フレッシュ・インストールとデータの削除を実行して、スタンバイ・サイトにOIGをデプロイします。
  17. プライマリ・サイトとスタンバイ・サイト間のOIG永続ボリューム同期を有効にします。
  18. 必要に応じて、スタンバイ・サイトのOIGデータベース接続設定を変更します。
  19. Kubernetesスナップショットを使用するか、フレッシュ・インストールとデータの削除を実行して、スタンバイ・サイトにOIGをデプロイします。
  20. プライマリ・サイトとスタンバイ・サイト間のOIRI永続ボリューム同期を有効にします。
  21. 必要に応じて、スタンバイ・サイトのOIRIデータベース接続設定を変更します。
  22. スタンバイ・サイトのOIRI Kubernetesクラスタ接続設定を変更します。
  23. まだ起動していない場合は、スナップショット・スタンバイ・データベースに対してOAMを起動します。
  24. OAA管理コンテナを起動し、ローカル・クラスタ用に構成します。
  25. プライマリ・サイトとスタンバイ・サイト間のOAA永続ボリューム同期を有効にします。
  26. 必要に応じて、スタンバイ・サイトのinstallOAA.propertiesのOAAデータベース接続設定を変更します。
  27. OAA.shを使用して、スタンバイ・サイトにOAAを再デプロイします。
  28. 必要に応じて、環境が機能していることを確認します。
  29. デプロイされた製品ごとに、通常のファイル・システムのレプリケーションを有効にします。
  30. スタンバイ・データベースをフィジカル・スタンバイに戻します。

親トピック: ディザスタ・リカバリ