構成プロセスについて

OCI Full Stack Disaster Recoveryを使用したJD Edwardsディザスタ・リカバリの構成は、基本的に3ステップのプロセスです。DR保護グループを作成してから、それらのグループを含むDR計画を作成する必要があります。これらのステップが完了したら、一連のスイッチオーバー後アクティビティを完了して計画を完全に実装する必要があります。この記事で説明する移動インスタンスと移動しないインスタンスの両方について、スイッチオーバー・プロセスの説明とともにDR計画を構成および実装できます。

インスタンスを移動するためのディザスタ・リカバリ保護グループおよびディザスタ・リカバリ計画の実装

コールドDRトポロジで一般的に使用される移行インスタンスをプライマリ・リージョンにデプロイします。ディザスタ・イベント中、インスタンスの移動はプライマリ・リージョンのDR保護グループからスタンバイ・リージョンのDR保護グループに移動されます。 スタンバイ・リージョン内のリソースは継続的に実行されないため、インスタンスの移動はコスト効率が高くなります。ただし、スタンバイ・リージョンでプロビジョニングおよび起動されることを確認する必要があるため、リカバリにかかる時間が長くなります。

次のトピックでは、DR保護グループの構成および実装のプロセス、およびインスタンスの移動の計画について説明します

ディザスタ・リカバリ保護 グループの作成

まず、DR保護グループを作成し、プライマリDRグループとセカンダリDRグループを関連付けて、グループにメンバーを追加します。次の手順を使用します。

1. OCIコンソールにログインし、プライマリ・リージョンを選択します。メイン・メニューから、「ディザスタ・リカバリ」、「DR保護グループ」、「DR保護グループの作成」の順にクリックします。ロギングの目的で前提条件の一部として「プライマリ」リージョンに作成されたオブジェクト・ストレージ・バケットを選択します。
2. OCIコンソールでスタンバイ・リージョンに切り替えます。別のDR保護グループを作成し、前提条件として設定したスタンバイで作成されたバケットに関連付けます。
3. プライマリ・リージョンに戻り、そこに作成されたDR保護グループを選択します。「関連付け」をクリックして、スタンバイ・リージョンのDRグループとのリンクを確立します。
4. OCIコンソールのDR保護グループのメイン・ページから、各DRグループのロール割当て(プライマリ/スタンバイ)を表示します。
5. プライマリ・リージョンのDRグループにメンバーを追加します。
   1. 必要なボリューム・グループをDR保護グループのメンバーとして含めます。
   2. 「VNICマッピングの追加」を選択して、コンピュート・リソースを追加し、VNICに必要な入力を指定します。JDEはマシン情報にホスト名を格納するため、VNIC設定はプライマリ・サイトと一致する必要があります。コンピュート・インスタンスのスピンアップ時に使用するDRリージョンの有効なIPアドレスを指定することもできます。
   3. 前提条件の一部として、スタンバイ・リージョンにロード・バランサを作成しました。作成後、DR保護グループのメンバーとして追加できます。プライマリ・リージョンとスタンバイ・リージョン間でバックエンド・セットを関連付けて、ディザスタ・リカバリ中にバックエンドが適切に遷移するようにします。
   4. プライマリ・リージョンにメンバーとしてデータベースを追加し、DR保護のメンバーとしてセカンダリ・リージョンおよびピア・データベースに切り替えます。

ディザスタ・リカバリ計画の作成

災害復旧計画は、スイッチオーバーまたはフェイルオーバーの際に実施される活動およびタスクのプライマリ・リージョンからスタンバイ・リージョンへのワークフローの概要です。この項では、以前に定義した保護グループのメンバーであるDR計画を作成するプロセスについて説明します。

DR計画を実行すると、リソース(保護グループのメンバー)がプライマリ・リージョンからスタンバイ・リージョンに遷移し、その逆も同様です。

DR計画を作成するには、次の手順を使用します。

1. 関連するDR保護グループに移動します。「リソース」タブで、「プランの作成」を選択します。

   ノート:

   • スイッチオーバー・シナリオの場合は、スタンバイ・リージョンに計画を作成します。
   • ロールバック・シナリオの場合は、「プライマリ」リージョンで計画を作成します。
2. 作成されたDR計画には、いくつかのデフォルトのステップが含まれています。デフォルトでは、終了ステップは無効になっています。要件に基づいて特定のステップを有効または無効にできます。
   「グループの追加」をクリックして、カスタム・アクションをプランに追加できます。これを使用して、カスタム・ステップ実行の一部として作成されたスクリプトを組み込みます。
3. グループ名を指定します。「前に追加」または「後に追加」を選択して正しい順序を選択し、新しいステップの前後に追加するグループを選択します。「ステップの追加」をクリックして、新しいアクションをプランに含めます。
4. カスタム・ステップごとに、グループ名およびステップ名を入力します。スクリプトの場所に応じて、正しい「ユーザー定義ステップ・タイプ」を選択します。必要なスクリプト・パラメータを指定し、「ステップの追加」をクリックします。必要に応じて、同じグループに複数のステップを追加できます。

   ノート:

   このシナリオでは、選択したリージョンは移動可能なFSDRシナリオであり、インスタンスはセカンダリ・リージョンに存在しないため、プライマリです。
5. プランのステップを検証した後、「プランの実行」をクリックしてスイッチオーバーを開始します。
   事前チェックが成功すると、DR計画は各ステップを順番に実行します。
6. スイッチオーバー・プロセス中にエラーが発生した場合、失敗したステップで実行が一時停止します。失敗したステップをスキップして、プランの残りのステップを続行することを選択できます。
7. ロールバック・プロシージャの場合、この同じプロセスに従います。ただし、ロールバック時にプランがプライマリ・リージョンから実行されていることを確認してください。

非移動インスタンスに対するディザスタ・リカバリ保護グループおよびディザスタ・リカバリ計画の実装

アクティブ/パッシブDRトポロジで共通する、移動しないインスタンスをプライマリ・リージョンとスタンバイ・リージョンの両方にデプロイします。DR操作中、これらのインスタンスは、リージョン間でサービスを移行するために、必要に応じて起動または停止されます。この方法では、スタンバイ・リージョンに既存のインフラストラクチャがあるため、リカバリが高速になりますが、インフラストラクチャを両方のリージョンでメンテナンスする必要があるため、コストがかかる場合があります。

次のトピックでは、DR保護グループの構成および実装のプロセス、および移動しないインスタンスに対する計画について説明します。

ディザスタ・リカバリ保護 グループの作成

インスタンスの移動と同様に、移動しないインスタンスを使用している場合は、DR保護グループを作成し、プライマリDRグループとセカンダリDRグループを再関連付けして、メンバーをグループに追加する必要があります。次の手順を実行します。

1. OCIコンソールにログインし、「ムンバイ」リージョンを選択します。メイン・メニューから、「ディザスタ・リカバリ」、「DR保護グループ」、「DR保護グループの作成」の順にクリックします。ロギング目的の前提条件の一部として、ムンバイ・リージョンに作成されたオブジェクト・ストレージ・バケットを選択します。
2. プライマリ・リージョンのDRグループにメンバーを追加します。
3. OCIコンソールでセカンダリ・リージョンに切り替えます。別のDR保護グループを作成し、前提条件として設定されたセカンダリの場所で作成されたバケットに関連付けます。
4. セカンダリ・リージョンのDRグループにメンバーを追加します。これは移動しないタイプのDR設定であるため、必要なすべてのJDEデプロイメント、バッチおよびWebサーバーがセカンダリ・リージョンにすでにプロビジョニングされている必要があります。
5. ブロック・ボリュームのみがセカンダリ・サイトにレプリケートされます。ブロック・ボリュームでアプリケーションをホストすることをお薦めします。
6. プライマリおよびセカンダリの場所にあるサーバーでブート・ボリュームを同期するには、rsync/robocopyを使用して、必要に応じてプライマリ・サイトとセカンダリ・サイトの間でファイル・フォルダを同期します。
7. プライマリ・リージョンに戻り、そこに作成されたDR保護グループを選択します。「関連付け」をクリックして、セカンダリでDRグループとのリンクを確立します。
8. OCIコンソールのDR保護グループのメイン・ページから、各DRグループのロール割当て(プライマリ/セカンダリ)を表示できます。

ディザスタ・リカバリ計画の作成

インスタンスの移動のDR計画と同様に、非移動インスタンスのDR計画は、プライマリ・リージョンからスタンバイ・リージョンへのスイッチオーバーまたはフェイルオーバーが発生した場合に実行されるアクティビティおよびタスクのワークフローの概要を示します。前のステップで定義した保護グループのメンバーである非移動インスタンスのDR計画を作成するには、この手順を使用します。

1. 関連するDR保護グループに移動します。「リソース」タブで、「プランの作成」を選択します。

   ノート:

   • スイッチオーバー・シナリオの場合は、「セカンダリ」リージョンに計画を作成します。
   • ロールバック・シナリオの場合は、「プライマリ」リージョンで計画を作成します。
2. 「グループの追加」をクリックすると、カスタム・アクションをプランに追加できます。これを使用して、カスタム・ステップ実行の一部として作成されたスクリプトを組み込みます。
3. セカンダリ・リージョンでE1servicesを起動するカスタム・スクリプトを作成します。
4. プランのステップを検証した後、「プランの実行」をクリックしてスイッチオーバーを開始します。
5. 事前チェックが成功すると、DR計画は各ステップを順番に実行します。
6. スイッチオーバー・プロセス中にエラーが発生した場合、失敗したステップで実行が一時停止します。失敗したステップをスキップして、プランの残りのステップを続行することを選択できます。
7. ロールバックの場合、同じプロセスを使用しますが、ロールバック時に「プライマリ」リージョンからプランを実行する必要があります。

ディザスタ・リカバリ計画グループの理解

JD Edwards FDSRは、次の2つのDR計画グループに依存しています。

• 事前移入されたグループ。これは、メンバーおよびプランのタイプに応じて異なる順次グループです。
• カスタム・グループ。プライマリ・リージョンからセカンダリ・リージョンへのインスタンスのスイッチオーバー後にカスタム・スクリプトを使用して、JDEアプリケーションに対する構成変更を実行します。

次の各トピックでは、これらのグループの使用方法について説明します。

DR計画の事前移入済グループの理解

順次グループの事前移入は、DR保護グループに追加されたメンバーおよびプランのタイプによって異なります。ここでは、スイッチオーバー計画に従って移入されるステップについて説明します。

• 事前チェック- 組込み

  これらの事前チェックでは、実際のフェイルオーバー、フェイルバックまたはテスト中のエラーを防ぐために、必要なすべてのリソース、構成および権限が設定されていることを確認します。

• ロード・バランサ- ソース・バックエンド・セットの更新

  フェイルオーバー後に不要になったバックエンド・セットからバックエンド・サーバーを削除します。

• Computeインスタンス – 停止

  プライマリ・リージョンのDR保護グループの一部であるすべてのインスタンス・リソースを停止します。

• ボリューム・グループ- スイッチオーバー

  「プライマリ」リージョンから「セカンダリ」リージョンへのボリューム・グループのスイッチオーバー操作を開始し、セカンダリ・リージョンのボリュームは書込み可能でアクティブになります。

• Autonomous Databases– スイッチオーバー

  セカンダリ・リージョンのスタンバイ・インスタンスへのAutonomous Databasesのスイッチオーバーを実行します。

• Computeインスタンス – 起動

  事前定義された構成を使用して、セカンダリ・リージョンでコンピュート・インスタンスを起動します。

• ロード・バランサ- 宛先バックエンド・セットの更新

  セカンダリ・リージョンで起動されたバックエンドでロード・バランサ・バックエンド・セットを更新します。

• ボリュームグループ- リバースレプリケーション

  セカンダリ・リージョンがプライマリ・リージョンにデータをレプリケートして、フェイルオーバー後の継続性を確保できるように、ボリューム・グループ・レプリケーションの方向を逆にします。

• コンピュート・インスタンスの終了

  プライマリ・リージョンで不要になったコンピュート・インスタンスを終了します。これはオプションの手順で、手動で有効化する必要があります。

• コンピュート・インスタンスのDR保護グループからの削除

  DR保護グループからコンピュート・インスタンスを削除して、グループを更新したままにします。

• ボリュームグループ – 終了

  スイッチオーバーに成功した後、プライマリ・リージョンのボリューム・グループを削除します。これはオプションのステップであり、手動で有効化する必要があります。

• ボリューム・グループ- DR保護グループからの削除

  DR保護グループからボリューム・グループを削除して、グループを更新したままにします。

DR計画のカスタム・グループの理解

これらのカスタム・グループを追加して、プライマリ・リージョンからセカンダリ・リージョンへのインスタンスのスイッチオーバー後にカスタム・スクリプトを使用することで、JDEアプリケーションに対する構成変更を実行できます。このアプローチは、運用作業を最小限に抑え、ダウンタイムを短縮するのに役立ちます。

アーキテクチャの要件に基づいて、次のグループが含まれています。

• エンタープライズ・サーバーの更新。コンピュート・インスタンス – 起動の後にこのグループを追加します。
• Webサーバーの更新。エンタープライズ・サーバーの更新後にこのグループを追加します。
• Aisサーバーの更新。Webサーバーの更新後にこのグループを追加します。

前述の「ディザスタ・リカバリ計画の作成」のステップ2、3および4に従って、複数のカスタム・スクリプトを実行して、セカンダリ・リージョンのJDE構成ファイルを更新します。

スイッチオーバー後のアクティビティの完了

セカンダリ・サイトに正常にスイッチオーバーした後、次のアクティビティを実行して、すべてのサービスがリストアされて動作していることを確認します。

1. 秘密キーを使用してDRリージョンの仮想マシンにログインします。
2. /etc/hostsファイルを編集して、DR Web、Enterprise/batchおよびAISサーバーのIPアドレスを含めます。
3. エンタープライズ/バッチ・サーバーにログインし、tnspingを使用してデータベースへの接続をテストします。成功した場合は、JD Edwards (E1)サービスを起動します。アプリケーションの起動後にポート・テストを実行します。
4. WebおよびAISサーバーで、Weblogicサービスを停止および起動します。
5. WebLogicコンソールにログインし、関連するすべての管理対象サーバーを起動します。
6. セカンダリ・リージョン・ロード・バランサで、マップされたバックエンドがアクティブ状態であることを確認します。
7. JDE Webリンクの表面レベルのテストを実行します。確認したら、環境にリリースします。
8. AIS接続でのJD Edwardsのソフトコードの更新:
   1. JDEにログインし、P954000アプリケーションを開きます。
   2. <J**920>環境を確認し、DRリンクhttp://lb_address:port に更新します。