セントラル・ステージングの場所とのrsyncの実装

セントラル・ステージングの場所を使用した`rsync`の実装

この実装では、rsyncテクノロジを使用し、中央のステージング場所に基づいてモデルに従います。このモデルには、コーディネータとして機能する要塞ホスト・ノードがあります。レプリケートする必要がある各ホストに接続し、コンテンツを共通のステージング場所にコピーします。

ステージングの場所を中央に配置してrsyncを実装する利点は次のとおりです。

これは任意の中間層に適用可能な汎用ソリューションであるため、複数のシステムがある場合は、それらのすべてで同じアプローチを使用できます。
これは、基礎となるストレージ・タイプに依存しません。ブロック・ボリューム、NFSなどに存在するファイル・アーティファクトのレプリケートに有効です。
ストレージはセカンダリ・ノードにマウントされたままにできます。したがって、スイッチオーバーまたはフェイルオーバー操作ごとにセカンダリにストレージを接続またはマウントする追加の手順は必要ありません。
ピア・ツー・ピアの実装と比較して、スクリプトを実行するための中央ノードがあるため、メンテナンスが簡単になります。

中央のステージングの場所でrsyncを実装する際の考慮事項は次のとおりです。

各環境のカスタム・スクリプトを作成し、定期的に実行することはユーザーの責任です。
レプリカの方向を逆にする方法を実装するのはユーザーの責任です。
このモデルでは、中央のステージングの場所に追加のホストとストレージが必要です。

ピアツーピア・モデルと同様に、rsyncスクリプトではプル・モデルまたはプッシュ・モデルを使用できます。プル・モデルでは、リモート・ノードからローカル・ノードにファイルがコピーされます。"push"モデルでは、スクリプトはローカル・ノードからリモート・ノードにファイルをコピーします。Oracleでは、プル・モデルを使用してプライマリ・ホストからコンテンツを取得することをお薦めします。これは、プライマリ・ノードがコピーのオーバーヘッドからオフロードされるためです。

セントラル・ステージングを使用した`rsync`のレプリケーションの設定

中央のステージングの場所でrsyncを実装するには、次のことが必要です。

すべてのホスト(プライマリとセカンダリの両方)へのSSH接続を持つ要塞ホスト。
レプリケートされる中間層ファイル・システムの内容を格納するのに十分な領域がある、要塞ホスト内のステージング・フォルダ。
rsyncを使用して中間層ファイル・アーティファクトをこのステージング・フォルダとの間でコピーするスクリプト。rsyncスクリプトは、コピーから特定のフォルダ(ロック・ファイル、ログ、一時ファイルなど)をスキップできます。
サイト固有の情報を管理する方法。コピーからその情報を除外するか、レプリカの後に適切な情報で更新します。
これらのスクリプトを定期的に実行するようにスケジュールします。
スイッチオーバーまたはフェイルオーバー後にレプリカの方向を変更するメカニズム。このメカニズムは、サイトの役割を識別する動的チェック、またはスイッチオーバーまたはフェイルオーバー後の手動変更(たとえば、適切なスクリプトの無効化および有効化)である場合があります。

このドキュメントでは、このモデルの2つの異なる実装例について説明します。

例1: 『Oracle Fusion Middleware障害時リカバリ・ガイド』のスクリプトの使用
例2: WLS-HYDRフレームワークの使用

例1: Oracle Fusion Middleware障害時リカバリ・ガイド・スクリプトの使用

ノート:

この例は、すべての中間層システムに適用されます。参照として、『Oracle Fusion Middleware障害時リカバリ・ガイド』で提供されるスクリプトを使用して、Oracle WebLogic DRシステムの中間層レプリカ(rsync_for_WLS.shおよびrsync_copy_and_validate.sh)を実行します。しかし、これらのスクリプトは一般的に適用可能で、OCIの中間層ファイル・システム・アーティファクトを同期するのに十分な柔軟性を提供します。

『Oracle Fusion Middleware障害時リカバリ・ガイド』には、中間層システムでリモート・コピーを実行するためのrsyncスクリプトが用意されています。これらのスクリプトは、すべてのrsyncモデルに対して有効です。この特定の例は、中央ステージング・モデルで使用する方法を示しています。この実装では、2つのステップでプル操作を使用します。

要塞ホストは、すべてのプライマリ・ホストからコンテンツをプルし、中央のステージングに格納します。
次に、すべてのセカンダリ・ノードがプル操作を実行して、中央のステージングから内容を収集します。

これらのスクリプトを使用して中間層レプリケーションを設定するには、『Oracle Fusion Middleware障害時リカバリ・ガイド』のプライマリ・ファイル・システムのセカンダリ・サイトへのレプリケートに関する項、特にレプリケーションの再同期アプローチに関する項およびステージングの場所の使用に関する項のステップを参照してください。

図replica-rsync-scripts.pngの説明

レプリカ-rsync- スクリプト-oracle.zip

例2: WLS-HYDRフレームワークの使用

ノート:

この例は、Oracle WebLogic Serverシステムに適用されます。WLS-HYDRフレームワークのレプリケーション・モジュールを使用しますが、WLS-HYDRフレームワークを使用して作成されたかどうかに関係なく、Oracle WebLogic Server DR環境に適用されます。

このモデルでは、中央ホスト・ノードが合計コーディネータとして機能し、プル操作およびプッシュ操作を実行します。レプリケートする必要がある各ホストに接続し、コンテンツを共通のステージング場所にコピーします。このノードは、ステージングの場所から宛先ホストへのコピーも調整します。このアプローチでは、コピーのオーバーヘッドから個々のノードをオフロードします。

WLS-HYDRフレームワークは、DR設定時の初期コピーにこのアプローチを使用します。その後、フレームワークのレプリケーション・モジュールを再利用してプルを繰り返し、定期的にプッシュできます。WLS-HYDRフレームワークおよびその他のリソースへのリンクについては、このプレイブックの「詳細」を参照してください。

要塞ノードは、次の2つのステップでレプリカを実行します。

プル操作。この操作では、プライマリ・ホストに接続し、ファイル・システムのコンテンツを要塞ホストのステージング・フォルダにコピーします。
プッシュ操作。この操作では、内容が要塞のステージング・フォルダからすべてのセカンダリ・ホストにコピーされます。

中央ノードはすべての操作を実行するため、スケジューリング、ログ、メンテナンスなどはそのノードに一元化されます。システムに多数のノードがある場合、これはピアツーピア・モデルまたは前の例と比較して効率的です。

図replica-wls-hydr-framework.pngの説明

レプリカ-wls-hydr-framework-oracle.zip

WLS-HYDRフレームワークを使用してセカンダリ・システムを作成した場合、要塞ホストはレプリカを実行する準備が整っています。それ以外の場合は、この時点で構成できます。レプリカを設定するには、次のステップに従います。

要塞の準備

WLS-HYDRフレームワークを使用してセカンダリ・システムを作成した場合、要塞ホストはレプリカを実行する準備が整っています。そうでない場合は、WLS-HYDRフレームワークのGitHubリポジトリのREADMEをチェックして、要塞ホストを準備します。
WLS-HYDR構成ファイルを確認します。
WLS-HYDR構成ファイル(replication.properties、oci.envおよびprem.env)に、システムの正しい情報が含まれていることを確認します。
WLS-HYDRレプリケーション・モジュールを実行します。
フレームワークのレプリケーション・モジュールを使用して、すべてのアイテム(Oracle WebLogic Serverドメインおよび製品)を同期することも、これらのアイテムを個別に同期することもできます。いずれの場合も、完全同期は、2つの操作(プル操作、プライマリからコンテンツを取得する操作、およびコンテンツをセカンダリにコピーするプッシュ操作)で構成されます。

ノート:
PULL操作は、常にPUSHの前に実行します。そうしないと、コンテンツの最新バージョンはプッシュされません。
1. すべてのコンテンツを同期するには:
  - プライマリ・ホストから要塞ホストのステージングにすべてのコンテンツをプルするには:
```
WLS-HYDR_BASE/lib/DataReplication.py pull
```
  - 要塞ホストのステージングからセカンダリ・ホストにすべてのコンテンツをプッシュするには:
```
WLS-HYDR_BASE/lib/DataReplication.py push
```
2. 製品アーティファクトのみを同期するには:
  - プライマリ・ホストから要塞ホストのステージングに製品をプルするには:
```
WLS-HYDR_BASE/lib/DataReplication.py pull -d products
```
  - 要塞ホストのステージングからセカンダリ・ホストに製品をプッシュするには:
```
WLS-HYDR_BASE/lib/DataReplication.py push -d products
```
3. 構成(WebLogicドメイン)のみを同期するには。
  - プライマリ・ホストから要塞ホストのステージングに構成を取得するには、次のプル操作を実行します:
```
WLS-HYDR_BASE/lib/DataReplication.py pull -d private_config
```
  - 構成を要塞ホストのステージングからセカンダリ・ホストにコピーするには、次のプッシュ操作を実行します:
```
WLS-HYDR_BASE/lib/DataReplication.py push -d private_config
```
4. 共有構成フォルダ(OCIファイル・ストレージ・ファイル・システム内の共有Oracle WebLogicドメイン)がある場合:
  - プライマリ・ホストから要塞ホストのステージングへの共有構成を取得するには、次のプル操作を実行します:
```
WLS-HYDR_BASE/lib/DataReplication.py pull -d shared_config
```
  - 要塞ホストのステージングからセカンダリ・ホストに共有構成をコピーするには、次のプッシュ操作を実行します:
```
WLS-HYDR_BASE/lib/DataReplication.py push -d shared_config
```

データベース接続文字列の置換を準備します。

WebLogic構成をコピーする通常のWLS-HYDRプルおよびプッシュ操作では、コピーからtnsnames.oraファイルがスキップされるため、後続のすべてのレプリケーションでtnsnames.oraを更新する必要はありません。

ただし、データベースがAutonomous Databaseの場合、アプローチは異なります。自律型データベースに接続するために、TNS管理フォルダには、プライマリ・データベースとスタンバイ・データベースとは異なるキーストア・ファイルおよびトラスト・ストア・ファイルも含まれています。

次の表に、各シナリオでデータベース接続情報を管理する方法の概要を示します。

データベース・タイプ置換スクリプトとダウンロード手順使用状況

データベース・タイプ	置換スクリプトとダウンロード手順	使用状況
Oracle Base Database ServiceまたはOracle Exadata Database Service	`tnsnames.ora`を管理するスクリプトは、WLS-HYDRフレームワーク・レプリケーション・モジュールに含まれています。	`replication.properties`ファイルのJDBCセクションに正しいデータが含まれていることを確認します。この操作は要塞で実行され、`tnsnames.ora`ファイルのプル、更新およびプッシュを実行します。完全な操作を実行するには: `WLS-HYDR/lib/DataReplication.py tnsnames` `tnsnames.ora`に対する変更(別名の追加など)を実行しないかぎり、実行する必要はありません。
Autonomous Database	`fmwadb_switch_db_conn.sh` GitHub `https://github.com/oracle-samples/maa`のOracle MAAリポジトリに移動します。すべてのスクリプトを`app_dr_common`ディレクトリにダウンロードします。すべてのスクリプトを`fmw-wls-with-adb-dr`ディレクトリにダウンロードします。すべての中間層ホストにコピーします。スクリプトは相互にコールします。両方のディレクトリのすべてのスクリプトを同じフォルダに配置します。	このスクリプトは、すべてのスタンバイ中間層ホストで実行する必要があります。検証、スイッチオーバーまたはフェイルオーバー操作のために、スタンバイでWebLogicサーバーを起動する前に実行する必要があります。 WebLogicで使用されるTNS管理フォルダは、入力として指定されたフォルダに置き換えられます。また、データ・ソースのウォレット・パスワード・プロパティも更新されます。スクリプトを実行する構文: `fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD` ここで、WALLET_DIRは、ローカル・データベースに接続するための`tnsnames.ora`、キーストアおよびトラストストア・ファイルを含むフォルダです。レプリカでWALLET_DIRフォルダがオーバーライドされていないことを確認します。

Oracle Base Database ServiceまたはOracle Exadata Database Service

tnsnames.oraを管理するスクリプトは、WLS-HYDRフレームワーク・レプリケーション・モジュールに含まれています。

replication.propertiesファイルのJDBCセクションに正しいデータが含まれていることを確認します。

この操作は要塞で実行され、tnsnames.oraファイルのプル、更新およびプッシュを実行します。完全な操作を実行するには: WLS-HYDR/lib/DataReplication.py tnsnames

tnsnames.oraに対する変更(別名の追加など)を実行しないかぎり、実行する必要はありません。

Autonomous Database

fmwadb_switch_db_conn.sh

GitHub https://github.com/oracle-samples/maaのOracle MAAリポジトリに移動します。

すべてのスクリプトをapp_dr_commonディレクトリにダウンロードします。

すべてのスクリプトをfmw-wls-with-adb-drディレクトリにダウンロードします。

すべての中間層ホストにコピーします。スクリプトは相互にコールします。両方のディレクトリのすべてのスクリプトを同じフォルダに配置します。

このスクリプトは、すべてのスタンバイ中間層ホストで実行する必要があります。検証、スイッチオーバーまたはフェイルオーバー操作のために、スタンバイでWebLogicサーバーを起動する前に実行する必要があります。

WebLogicで使用されるTNS管理フォルダは、入力として指定されたフォルダに置き換えられます。また、データ・ソースのウォレット・パスワード・プロパティも更新されます。

スクリプトを実行する構文:

fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD

ここで、WALLET_DIRは、ローカル・データベースに接続するためのtnsnames.ora、キーストアおよびトラストストア・ファイルを含むフォルダです。レプリカでWALLET_DIRフォルダがオーバーライドされていないことを確認します。

セントラル・ステージングを使用した`rsync`のレプリケーションの検証

スイッチオーバーまたはフェイルオーバー操作では、プロセスが起動される前に、レプリケートされた情報がスタンバイ・サイトで使用可能である必要があります。これは、(スタンバイ・データベースをスナップショット・モードでオープンして)セカンダリ・システムを検証する場合にも必要です。

この実装では、ストレージはセカンダリ・サイトで常に使用可能であるため、ボリュームをアタッチまたはマウントする必要はありません。必要な唯一のアクションは、コンテンツの最新バージョンが含まれていることを確認することです。

レプリケーションを実行します。
スクリプトを実行して、コンテンツの最新バージョンをレプリケートします。
定期レプリケーションを無効にします。
最後のレプリカの終了後、すべてのレプリカ・スクリプトを無効にします。それ以外の場合は、スイッチオーバー、フェイルオーバー、または検証手順を妨げる可能性があります。操作後、適切な方向でスクリプトを再度有効にします。
セカンダリ中間層ホストでサイト固有の情報を置き換えます。
レプリケートするファイル・システム・アーティファクトにサイト固有の情報が含まれている場合は、コピーによって上書きされないか、レプリカ後に更新されることを確認してください。

ヒント :
たとえば、『Oracle Fusion Middleware障害時リカバリ・ガイド』およびWLS-HYDRレプリケーション・モジュールのrsyncスクリプトでは、コピーからファイルtnsnames.oraがスキップされるため、すべてのレプリケーション後に変更する必要はありません。
システムでOracle Autonomous Databaseが使用されている場合は、セカンダリ・リージョンのデータベースに接続するために必要なウォレット・フォルダをセカンダリにリストアします。置換スクリプトfmwadb_switch_db_conn.shは、すべてのスタンバイ中間層ホストで使用できます。これには、入力として、セカンダリ・オリジナルのウォレットが存在するパスおよびウォレット・パスワードが必要です。

その後、システムの検証に必要な追加のステップを実行できます。

セントラル・ステージングの場所を使用した`rsync`の進行中のレプリケーションの実行

レプリケーション・スクリプトを定期的に実行して、セカンダリ・ドメインとプライマリの同期を維持します。

この実装を使用する場合は、進行中のレプリケーションに関する次の推奨事項に従ってください。

OS crontabまたは別のスケジューリング・ツールを使用して、レプリケーション・スクリプトを定期的に実行します。たとえば、ディザスタ・リカバリ・ガイドで提供されるrsyncスクリプトを使用する場合は、『Oracle Fusion Middlewareディザスタ・リカバリ・ガイド』のRsyncスクリプトを使用した進行中のレプリケーションのスケジュールに関する項のステップに従います。これらのリソースやその他のリソースへのリンクについては、このプレイブックの「詳細」を参照してください。レプリケーションの頻度については、このプレイブックの前述の中間層ファイル・アーティファクトで説明されているガイドラインに従ってください。
中間層プロセスをスタンバイ・サイトで停止したままにします。変更のレプリケート中にサーバーがスタンバイ・サイトで稼働している場合、その変更は次回起動時に有効になります。スタンバイ・サイトを検証する場合、またはスイッチオーバーまたはフェイルオーバーの手順中にのみ起動します。
各サイトに固有の情報を最新の状態に維持します。たとえば、ファイル・システムにAutonomous Databaseに接続するためのアーティファクトを含むフォルダが含まれている場合は、このフォルダのバックアップ・コピーを保持します。ウォレットで更新を実行する場合は、ウォレット・フォルダのバックアップを更新してください。このようにして、後続のスイッチオーバーおよびフェイルオーバーで正しくリストアされます。
スイッチオーバーまたはフェイルオーバー後、レプリカの方向を逆にします。これは、特定の実装によって異なります。これは、アクティブ・サイトのユーザーを識別する動的チェックを使用するか、スイッチオーバーまたはフェイルオーバー後の手動変更を使用して、適切なスクリプトを無効化および有効化することで実行できます。
ヒント :
- DRガイドで提供されているrsyncスクリプト(例1)を使用する場合は、レプリカをもう一方の方向で実行するための同等のスクリプトを作成してください。crontabまたはスケジュール済ツールで、実際のロールに適したスクリプトのみを有効にします。
- WLS-HYDR (例2)を使用する場合は、WLS-HYDRフレームワークでプライマリの役割を変更し、次のレプリケーションが別の方向に進むようにします。このため、WLS-HYRDR/lib/DataReplication.pyを編集し、次から変更します。
```
if True:
       PRIMARY = PREM 
       STANDBY = OCI
      	 else:
	        PRIMARY = OCI
               STANDBY = PREM
```
  次のようになります。
```
if False:
	        PRIMARY = PREM
                STANDBY = OCI
       	else:
                PRIMARY = OCI
                STANDBY = PREM
```

セントラル・ステージングの場所を使用したrsyncの実装

セントラル・ステージングを使用したrsyncのレプリケーションの設定

セントラル・ステージングを使用したrsyncのレプリケーションの検証

セントラル・ステージングの場所を使用したrsyncの進行中のレプリケーションの実行

セントラル・ステージングの場所を使用した`rsync`の実装

セントラル・ステージングを使用した`rsync`のレプリケーションの設定

セントラル・ステージングを使用した`rsync`のレプリケーションの検証

セントラル・ステージングの場所を使用した`rsync`の進行中のレプリケーションの実行