OCI Full Stack Disaster Recoveryを使用したJD Edwardsディザスタ・リカバリの構成について

JD Edwardsアーキテクチャ

この図は、プライマリ・リージョンとセカンダリ・リージョンの両方を備えたJD Edwardsアプリケーションのデプロイメント・アーキテクチャの概要を示しています。

プライマリ・リージョン

プライマリ・リージョンでは、JDE環境はVirtual Cloud Network (VCN)内にデプロイされ、3つの専用サブネットにセグメント化されます。このサブネットは、次に示すように、アプリケーション・リソース機能によって分離されます。

ロード・バランサ層
ロード・バランサ層は、エンド・ユーザーのJDE Webサービスへのアクセスを提供するOCIロード・バランサをホストします。
アプリケーション階層
アプリケーション層には、エンタープライズ・サーバー、Webサーバー、アプリケーション・インタフェース・サービス(AIS)サーバーなどのコア・アプリケーション・コンポーネントが含まれます。
管理層
管理層には、デプロイメント・サーバーやServer Managerコンソール・サーバーなど、JDEの管理用ツールおよびサービスが含まれます。
データベース階層
データベース・レイヤーでは、JDEデータベースはAutonomous Transaction Processing–Shared (ATP-S)にデプロイされます。アプリケーション・サーバーは、エンドポイントを使用してデータベースに接続します。Oracle Autonomous Data Guardが有効になり、セカンダリ・リージョンにスタンバイ・データベースが作成され、高可用性およびディザスタ・リカバリのためのリアルタイム・データ・レプリケーションが保証されます。
ストレージとデータ保護
コンピュート・インスタンスによって使用されるブロック・ボリューム・グループは、リージョン間ボリューム・グループ・レプリケーションによって保護され、セカンダリ・リージョンはレプリケーション・ターゲットとして構成されます。

セカンダリ・リージョン

セカンダリ・リージョンはディザスタ・リカバリ・サイトとして機能し、プライマリregion.Itの重要なコンポーネントには次が含まれます。

プライマリ・リージョンのネットワーク・レイアウトに一致するレプリケートされたVCN構造。
フェイルオーバー中のアクセスの継続性を確保するためのレプリカ・ロード・バランサ。
Autonomous Data Guardを使用してプライマリとの同期を維持するスタンバイATP-Sデータベース。
ボリューム・グループのレプリカ。プライマリ・リージョンに障害が発生した場合にデータの可用性を確保します。

JD Edwards構成関連ファイルの理解

JDEは、複数の構成ファイルを使用して、そのコンポーネントと、データベースや認証サービスなどの他の参加層間の接続を管理します。これらのファイルは、接続パラメータ、ランタイム設定および統合動作の定義において重要な役割を果たします。これらのファイルとその内容を適切に理解することは、シームレスなアプリケーション機能を確保するためにディザスタ・リカバリ(DR)シナリオを構成する際に不可欠です。

次に、主要な構成ファイルのサマリーを示します。

sqlnet.ora

目的:アプリケーションがデータベースへの安全な接続に使用するOracle Wallet構成を格納します。

場所: JDE Enterprise/Batchサーバー。借方

考慮事項: walletパスがDRデータベースの有効なwalletの場所を指していることを確認してください。

ファイル・パス: Oracle_ClientHome/network/admin

tnsnames.ora

目的:データベース・ネットワーク・アドレスの別名として機能するネット・サービス名を格納します。

場所: JDE Enterprise、BatchおよびWebサーバー。

DRの考慮事項: DRデータベースの正しいネットワーク・アドレス(FQDN/IP)で更新します。

エンタープライズ/バッチ・サーバーのファイル・パス: Oracle_ClientHome/network/admin

Webサーバーのファイル・パス: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jde.ini

目的:データベース接続の詳細やセキュリティ設定など、JDEアプリケーションのランタイム構成を格納します。

場所: JDE EnterpriseおよびBatchサーバー。

DRの考慮事項: DR環境の正しいサーバー名でDB SYSTEM SETTINGSセクションを更新します。

ファイル・パス: JDE_HOME/e920/ini

jdbj.ini

目的: JDEアプリケーションのJDBjドライバ設定およびデータベース接続パラメータが含まれます。

場所: JDE WebおよびAISサーバー。

DRの考慮事項: JDBj-BOOTSTRAP DATA SOURCEセクションに正しいサーバー名が指定されていることを確認します。

ファイル・パス: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jas.ini

目的: EnterpriseOne WebクライアントのHTMLサーバー・コンポーネントの構成を格納します。

場所: JDE Webサーバー。

DRの考慮事項: 次を更新します:

正しいAISホストおよびポートを含むFORMSERVICEセクション。
SSOが有効になっている場合は、適切なOracleAccessSSOSignOffURLを含むSecurityセクション。

ファイル・パス: SM_Agent_Home/SCFHA/Target/Managed Instance/config

rest.ini

目的: REST APIパス、認証設定、JASサーバー・リンクなど、AISサーバーの構成を保持します。

場所: JDE AISサーバー。

DRの考慮事項:次の内容を更新します。

正しいJASホストおよびポートを含むBASIC CONFIGセクション。
SSOが有効になっている場合は、更新されたIDCSSSOSignOffURLを含むSecurityセクション。

ファイル・パス: SM_Agent_Home/SCFHA/Target/Managed Instance/config

管理- console.xml

目的:このXMLファイルには、様々なサーバー、その構成およびユーザー・アクセス権限に関する情報があります。

場所: Server Managerサーバー

DRの考慮事項: management-console.xmlに正しいホスト名が指定されていることを確認します。

ファイル・パス: SM_Console_Home/SCFMC/targets/home

エージェント。プロパティ

目的:管理エージェントの設定を含む構成ファイル。管理コンソールと対話し、EnterpriseOneサーバーを管理するコンポーネントです。

場所: Server Managerサーバー

DRの考慮事項: agent.propertiesセクションに正しいサーバー名が指定されていることを確認します。

ファイル・パス: SM_Console_Home/ SCFMC/config

追加のシステム・レベルの更新

アプリケーション構成ファイルに加えて、DRの実装中に次のシステムファイルも確認および更新する必要があります。

Linuxホストおよびfstabファイル:有効なIPアドレスおよびFQDNが定義されていることを確認します。
Windowsホスト・ファイル:必要に応じて、現在のIPおよびFQDNマッピングで更新します。
WebLogic wallet files:データベースがAutonomousの場合に接続性を確保するために、DR固有のデータベースwalletを反映するように更新する必要があります。

これらの構成ファイルを適切に維持および更新することで、ディザスタ・リカバリ環境でJDEが正しく機能し続けることができ、ダウンタイムを最小限に抑え、セキュアで一貫性のあるアプリケーション接続を維持できます。

フル・スタック・ディザスタ・リカバリの概念

FSDRを構成および実装する場合、次の概念および用語を理解する必要があります。

DR保護グループ
- 定義: DR保護グループには、完全なアプリケーション・スタックを形成するコンピュート・インスタンス、ボリューム・グループ、ロード・バランサ、データベースなど、必要なすべてのOCIリソースが含まれます。
- 利点: DR保護グループは、フェイルオーバー、フェイルバックおよびテスト・シナリオの単一ユニットとして扱われます。これにより、すべてのリソースがまとめてリカバリされるため、ダウンタイムとデータ損失が最小限に抑えられます。
DR計画
DR計画は、FSDRによって作成される自動ランブックで、プライマリDR保護グループ内のすべてのリソースのディザザスタ・リカバリを実行します。これは、プライマリDR保護グループ・リージョン内のすべてのリソースをそのピア・セカンダリDR保護グループ・リージョンに遷移する方法を定義するステップで構成されます。様々なタイプのDR計画を次に示します。
- フェイルオーバー(計画外):プライマリ・リージョンのサービスの停止を試行せずに、スタンバイ・リージョンのアプリケーション・スタックを起動することで即時遷移を実行する場合は、フェイルオーバー計画を使用します。フェイルオーバー計画は通常、停止または障害がプライマリ・リージョンに影響する場合にDR遷移を実行するために使用されます。
- スイッチオーバー(計画):プライマリ・リージョン内のアプリケーション・スタックを停止してから、スタンバイ・リージョンでそれを起動することで、順次遷移を実行する場合は、スイッチオーバー計画を使用します。スイッチオーバー計画は通常、計画済サイト・メンテナンス、ソフトウェアのパッチ適用、DRテストおよび検証の目的で使用されます。
- 開始ドリル:開始ドリルは、プライマリDR保護グループ・リソースを中断することなく、DRドリルを実行する計画を生成します。スタンバイDR保護グループにリソースのレプリカを作成します。
- ストップ・ドリル: このDR計画は、スタート・ドリルによって作成されたリソースのレプリカを削除することで、DRドリルを停止します。
移動インスタンス
- 定義: プライマリ・リージョンにのみデプロイされるインスタンス。
- ユース・ケース: コールドDRトポロジで共通。アプリケーションまたはサービスの一部または全員のコンポーネントがスタンバイ・リージョンに事前デプロイされる必要のないDRトポロジ。
- 動作: 障害イベント中、インスタンスの移動は、プライマリ・リージョンのDR保護グループからスタンバイ・リージョンのDR保護グループに移動します。
- 利点:スタンバイ・リージョンのリソースが継続的に稼働していないため、コスト効率が高くなります。
- 考慮事項:この方法では、スタンバイ・リージョンでインスタンスをプロビジョニングおよび起動する必要があるため、リカバリ時間が長くなります。
非移動インスタンス
- 定義:プライマリ・リージョンとスタンバイ・リージョンの両方に事前にデプロイされたインスタンス。
- ユース・ケース: アクティブ/パッシブDRトポロジで共通です。このトポロジでは、アプリケーションまたはサービスの一部または全部のコンポーネントがスタンバイ・リージョンに事前デプロイされ、今後のDR遷移に備えます。
- 動作: DR操作中に、これらのインスタンスは、リージョン間でサービスを遷移するために、必要に応じて起動または停止されます。
- 利点:この方法では、スタンバイ・リージョンに既存のインフラストラクチャがあるため、リカバリが高速になります。
- 考慮事項:インフラストラクチャを両方のリージョンでメンテナンスする必要があるため、コストが高くなる可能性があります。

フル・スタック・ディザスタ・リカバリの前提条件

FSDRプロセスに進む前に、次の前提条件を満たす必要があります。

DRリージョンにVCN、サブネット、ルート表、セキュリティ・リストおよびネットワーク・ゲートウェイをプロビジョニングします。フェイルオーバー機能および接続をサポートするには、ネットワーク構成がプライマリ・リージョンのものと同じであることを確認します。
DR環境の一部として作成されたインスタンスに管理者権限を付与するポリシーを許可する動的グループを定義します。
コンピュート・インスタンスでスクリプトを実行するには、管理者権限が必要です。実行コマンド・プラグインは、ocarunユーザーを使用してこれらのスクリプトを実行します。このユーザーに適切な権限があることを確認します。
1. oracle-cloud-agent-run-commandを開いて編集します。
```
 vi ./101-oracle-cloud-agent-run-command
```
2. 構成ファイルに次の行を追加します。
```
ocarun ALL=(ALL) 
NOPASSWD:ALL
```
3. その後、次を実行します。
```
vi sudo -cf ./101-oracle-cloud-agent-run-command
```
4. 構成ファイルを/etc/sudoers.dに追加します:
```
sudo cp ./101-oracle-cloud-agent-run-command /etc/sudoers.d/
```
ボリューム・グループのリージョン間バックアップ機能をアクティブ化します。
セカンダリ・リージョンにロード・バランサをデプロイします。FSDR構成の一部として、バックエンド・セット(インスタンス)のみがプライマリ・リージョンからスタンバイ・リージョンに移動されます。ロード・バランサ自体は、事前にスタンバイ・リージョンに手動で作成する必要があります。
アプリケーション・フェイルオーバーをサポートするために、DRリージョンで対応する(ピア)データベース・インスタンスを設定します。
プライマリ・リージョンにログ用のオブジェクト・ストレージ・バケットを作成します。このバケットには、環境に固有のDRログおよびアーティファクトが格納されます。
スタンバイ・リージョンに追加のオブジェクト・ストレージ・バケットを作成します。このバケットは、スタンバイ・リージョンでのDR準備状況を確保するために、レプリケーションまたはロギング目的で使用されます。
次のカスタム・スクリプトを適切な場所に配置します。

カスタム・スクリプトは適用

これらのカスタム・スクリプトは、FSDRプロセス中に実行されます。

update_rest

適用可能なサーバー: AIS

#Define the old and new file names
old_file1="rest_dr.ini"
new_file1="rest.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"
 # Copy the new second file back to the original name, preserving attributes
 cp -p "$new_file1" "$old_file1"
 echo "Copied $new_file1 back to $old_file1 (preserving attributes)"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_tnsnames_jdbj

適用可能なサーバー: JAS、AIS

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="jdbj_dr.ini"
old_file3="jas_dr.ini"
new_file1="tnsnames.ora"
new_file2="jdbj.ini"
new_file3="jas.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"

 # Rename the third file
 mv "$old_file3" "$new_file3"
 echo "Renamed $old_file3 to $new_file3"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_wallet

適用可能なサーバー: すべてのJDEサーバー(Enterprise、AIS、JAS、Fatclient、Integrationsなど)

# Define old and new wallet folder names
old_wallet="Wallet_jdeorcl_hyderabad"
new_wallet="Wallet_jdeorcl"

# Check if the old wallet directory exists
if [ -d "$old_wallet" ]; then
  # Remove any existing new_wallet directory to avoid conflict
  if [ -d "$new_wallet" ]; then
    echo "Removing existing $new_wallet directory..."
    rm -rf "$new_wallet"
  fi

  # Rename the old wallet to the new name
  mv "$old_wallet" "$new_wallet"
  echo "Renamed $old_wallet to $new_wallet"

  # Copy the new wallet back to the old wallet directory for reuse
  cp -r "$new_wallet" "$old_wallet"
  echo "Copied $new_wallet back to $old_wallet for reuse"

else
  echo "Directory $old_wallet does not exist. Aborting operation."
fi

update_ini

適用可能なサーバー: Enterprise

# Define the old and new file names
old_file2="JDE_DR.INI"
old_file3="jdbj_dr.ini"
new_file2="JDE.INI"
new_file3="jdbj.ini"

# Check if the old files exist in the folder
if [ -e "$old_file2" ] && [ -e "$old_file3" ] ; then
    # Rename the second file
    mv "$old_file2" "$new_file2"
    echo "Renamed $old_file2 to $new_file2"

    # Rename the third file
    mv "$old_file3" "$new_file3"
    echo "Renamed $old_file3 to $new_file3"
else
    echo "Old files do not exist in the folder."
fi

update_tnsnames_sqlnet

適用可能なサーバー:エンタープライズ、デプロイメント、Fatclients

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="sqlnet_dr.ora"
new_file1="tnsnames.ora"
new_file2="sqlnet.ora"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"
else
 echo "One or both of the old files do not exist in the folder."
fi

update_agent_properties

適用可能なサーバー: Server Managerによって管理されるすべてのサーバー

# Define the old and new file names
old_file1="agent.properties"
new_file1="agent_dr.properties"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi

update_management_console

適用可能なサーバー:サーバー・マネージャ

# Define the old and new file names
old_file1="management-console_dr.xml"
new_file1="management-console.xml"

# Check if the old files exist in the folder
if [ -e "$old_file1" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi