OCI Block Volumesレプリケーションの実装

この実装では、OCIブロック・ボリューム・クロスリージョン・レプリケーション機能を使用してブロック・ボリュームをレプリケートします。

OCIブロック・ボリューム・レプリケーションを実装する利点は次のとおりです:

他のレプリケーションの場合と同様に、スクリプトを定期的に作成および実行する必要はありません。レプリケーションを設定すると、Oracle Cloud Infrastructureによって自動的に実行されます。
これは、任意のコンピュート・インスタンスの任意のブロック・ボリューム(ブート・ボリュームを除く)に適用可能な汎用ソリューションです。複数のシステムがある場合は、すべてのシステムで同じアプローチを使用できます。
レプリケートされたブロック・ボリュームに関する情報は、プライマリ・ブロック・ボリュームの正確なコピーであり、ブロック・ボリューム内のすべてのファイルがレプリケートされます。

OCIブロック・ボリューム・レプリケーションを使用する前に、次のことを考慮してください:

レプリケートされたブロック・ボリュームをセカンダリ・システムにマウントするステップが必要です。ブロック・ボリュームのレプリカを直接マウントすることはできません。まずブロック・ボリュームをアクティブ化して、マウント可能なクローン・ブロック・ボリュームを作成する必要があります。ノードが少ないシステムでは複雑ではありませんが、ノードが多いと複雑さが増します。特に、プライマリとスタンバイの可用性ドメインに同じノード分散がないシステムの場合。
ただし、Oracle Cloud Infrastructure Full Stack Disaster Recoveryサービスを使用して、スイッチオーバー、フェイルオーバーおよび検証操作でこれらのステップを自動化することで、この複雑さを克服できます。
この技術は多くのシステムには不十分かもしれません。システムにさらにタイプのストレージ(共有OCIファイル・ストレージ・ファイル・システムなど)がある場合は、別のレプリカ・テクノロジを使用する必要があります。

OCIブロック・ボリュームのレプリケーションの設定

OCIブロック・ボリューム・レプリケーションを実装するには、次のステップが必要です:

OCIコンソールを使用して、プライマリ・リージョンでボリューム・グループを定義し、レプリケートする必要があるブロック・ボリュームをグループ化します。
ボリューム・グループには、同じ可用性ドメイン(AD)にあるブロック・ボリュームのみを含めることができ、グループ内のすべてのブロック・ボリュームは、1つの宛先ADにのみレプリケートされます。ブロック・ボリュームが複数のADにある場合は、ソースADと宛先ADの組合せごとにブロック・ボリューム・グループを作成します。
ボリューム・グループ内のレプリカを、セカンダリ・リージョンの適切なADに対して有効にします。
セカンダリ・システムの中間層ホストに接続し、プライマリからレプリケートされるブロック・ボリュームをアンマウントします。
OCIコンソールを使用して、プライマリ・システムからレプリケートされるすべてのブロック・ボリュームをデタッチおよび破棄します。それらはもはや使用されません。
レプリカの後に適切な情報でブロック・ボリュームを更新することで、ブロック・ボリュームに存在するサイト固有の情報を管理する方法を実装します。

この実装は、ブート・ボリュームを除くすべてのブロック・ボリュームに適用されます。ブート・ボリューム・レプリケーションにはその他の影響があり、この実装の範囲外です。

例1: OCIブロック・ボリューム・レプリケーションを使用した中間層構成ブロック・ボリュームのレプリケート

ノート:

この例は、すべての中間層システムに適用されます。ここでは、Oracle WebLogic Server for OCIスタックのOracle WebLogic構成を含むブロック・ボリュームをレプリケートする方法について説明します。ただし、同じステップに従って、ブート・ボリュームを除き、中間層システムで他のブロック・ボリュームをレプリケートできます。

次の図は、OCI Block Volumesクロスリージョン・レプリカを使用するOracle WebLogic Serverシステムの例です。

図WLSs-bv-cross-replica.pngの説明

wls-bv-cross-replica-oracle.zip

ブロック・ボリュームのリージョン間レプリカを設定するには、次のステップに従います。

各サイトに固有の情報をバックアップします。
ブロック・ボリュームには、データベースまたはLDAPサーバーへの接続文字列など、各サイト固有の情報を含むファイルを含めることができます。

ブロック・ボリューム・レプリカを使用する場合、レプリケートされたブロック・ボリュームはプライマリ・ブロック・ボリュームの正確なコピーです。レプリカから特定のファイルまたはフォルダをスキップすることはできません。したがって、各サイトの情報を適応させることで、これらの違いを管理する必要があります。様々なアプローチがあります。
- ファイルの文字列検索および置換は、サイト固有の情報を使用して実行できます。
- この情報は、レプリカの前にバックアップして、後でリストアできます。
この時点で、レプリカを有効にする前に、レプリケートされるブロック・ボリュームに存在するサイト固有の情報を含むファイルを識別してバックアップします。レプリケートされたブロック・ボリュームの下ではない場所にバックアップ・コピーを作成します。そうしないと、バックアップ・コピーはオーバーライドされます。
ヒント :
Oracle WebLogic Serverの例
たとえば、WebLogicドメインを含むブロック・ボリュームをレプリケートする場合、データベースに接続するための情報を含むファイルがあります。この情報は、TNS管理フォルダにあります。フォルダを識別するには、WebLogicデータ・ソースのtns_adminプロパティを確認します。このドキュメントでは、シナリオに応じて適切なアプローチに従って、これを管理するためのスクリプトを提供します。
- システムがOracle Base Database ServiceまたはOracle Exadata Database Serviceに接続する場合、スイッチオーバーおよびフェイルオーバー操作中に、セカンダリ中間層システムのtnsnames.oraファイル内のデータベース接続文字列を更新できます。このドキュメントでは、このスクリプトの例を示します。
- システムがOracle Autonomous Databaseに接続する場合、TNS管理フォルダには、より多くのアーティファクト(トラスト・ストアおよびキーストア)が含まれます。プライマリとスタンバイでは異なるため、単純な文字列置換で更新できません。このドキュメントでは、TNSフォルダのバックアップ・コピーをリストアするスクリプトを提供します。
この時点では、TNSフォルダ情報のバックアップのみを実行する必要があります。

プライマリ中間層ホストのブロック・ボリュームを識別します。

OCIコンソールに移動し、「プライマリ」リージョンを選択して、コンパートメントを選択します。
「ストレージ」、「ブロック・ボリューム」の順に移動します。ブロック・ボリュームとマウント・ポイントを特定します。
名前、それらが配置されているAD、接続されているホストおよびマウント・ポイントを書き留めます。

ヒント :

Oracle WebLogicの例

たとえば、Oracle WebLogic Server for OCIおよびOracle SOA Suite on MarketplaceスタックにWebLogicドメインを含むブロック・ボリュームは、データ・ブロック・ボリュームです。これらの名前は、prefix-data-block-N (Nはホスト・ノードの番号)で、各ホストの/u01/dataにマウントされます。

プライマリのブロック・ボリューム	AD	ホスト	マウント・ポイント
`prefix-data-block-0`	AD1	`prefix-wls-0`	`/u01/data`
`prefix-data-block-1`	AD2	`prefix-wls-1`	`/u01/data`

Oracle製品ホームを格納する追加のブロック・ボリュームがある場合があります。たとえば、Oracle WebLogic Server for OCIスタックでは、計算にも/u01/appにマウントされたprefix-mw-block-Nブロック・ボリュームがあります。

プライマリ・スタックのWLS-HYDRフレームワークを使用してセカンダリを作成する場合、ブロック・ボリュームではなくOracle製品を格納するための2つの冗長OCI File Storageファイル・システムがあります。したがって、製品の場合、プライマリはブロック・ボリュームとセカンダリOCI File Storageを使用します。必要に応じて、mwブロック・ボリュームの進行中のレプリケーションも構成できます。プライマリでブロック・ボリューム・レプリカを構成し、セカンダリ製品のOCIファイル・ストレージ・ファイル・システムを除外するだけです。ただし、これらのアイテムにはOracle製品ホームが含まれているため、継続的にこれらのアイテムをレプリケートする必要はありません。詳細は、「中間層ファイル・アーティファクト」を参照してください。

セカンダリ中間層ホストでブロック・ボリュームを識別します。

前のステップで説明したステップを繰り返して、セカンダリ中間層ホストのブロック・ボリュームの名前と可用性ドメイン(AD)を取得します。

ヒント :

Oracle WebLogicの例

WLS-HYDRフレームワークを使用してセカンダリ・システムを作成する場合、ホストおよびブロック・ボリューム名には、プライマリと異なる接尾辞番号を付けることができます。マーケットプレイス・スタックでは接尾辞0,1,2,3が使用され、WLS-HYDRフレームワークで作成されたシステムでは接尾辞1,2,3,4が使用されます。ピアノードとボリュームを正しく識別してください。たとえば:

セカンダリでのブロック・ボリューム	AD	ホスト	マウント・ポイント
`prefixBV1`	AD1	`prefixhost-1`	`/u01/data`
`prefixBV2`	AD2	`prefixhost-2`	`/u01/data`

プライマリでブロック・ボリューム・グループを作成し、リージョン間のレプリカを有効にします。
プライマリにブロック・ボリューム・グループを作成し、特定のADからセカンダリ内の特定のADにレプリケートされるすべてのブロック・ボリュームをグループ化します。レプリカはボリューム・グループ・レベルで有効になっているため、そのグループ内のすべてのブロック・ボリュームに適用されます。ボリューム・グループには、同じAD内のブロック・ボリュームのみを含めることができ、グループ内のすべてのブロック・ボリュームは、1つの宛先ADにのみレプリケートされます。そのため、コンピュート・インスタンスが複数のADに配置されている場合は、ソースADと宛先ADの組合せごとにブロック・ボリューム・グループを作成します。
次のステップを実行して、ブロック・ボリューム・グループを作成し、リージョン間レプリカを有効にします。
1. プライマリ・リージョンのOCIコンソールにログオンします。
2. 「ストレージ」→「ボリューム・グループ」に移動します。
3. ブロック・ボリューム・グループを作成します。
  例: prefix-BVGroup-region1AD1-region2AD1
4. ボリューム・グループ内でレプリケートするブロック・ボリュームを追加します。
  
  ノート:
  ブート・ボリュームを追加しないでください。これらはレプリケートされません。
5. ボリューム・グループのクロス・リージョン・レプリケーションを有効にします。
  - ターゲット・リージョン: セカンダリ・リージョンを選択します。
  - 可用性ドメイン: レプリケートされたボリュームをマウントするコンピュータが存在するセカンダリ・リージョンでADを選択します。
  - Volume Group Replica Name: レプリカ・ブロック・ボリューム・グループの名前を入力します。わかりやすくするために、プライマリと同じブロック・ボリューム・グループを使用します。
6. 変更内容を保存します。
レプリカがセカンダリ・リージョンに作成されていることを確認します。
1. OCIコンソールで、セカンダリ・リージョンを選択します。
2. 「ストレージ」に移動し、「ブロック・ストレージ」、「ボリューム・グループ・レプリカ」の順にクリックします。
プライマリ・コンピュート・インスタンスが複数のADに存在する場合は、ステップを繰り返して追加のブロック・ボリューム・グループを作成します。
ヒント :

Oracle WebLogicの例

プライマリがマーケットプレイス・スタックで、セカンダリがWLS-HYDRを使用して作成された場合:

Oracle WebLogic Server for OCIおよびOracle SOA Suite on Marketplaceスタック: リージョンに複数の可用性ドメインがある場合(3)、コンピュート・インスタンスがそれら全体に分散されます。For example, node0 in AD1, node1 in AD2, node2 in AD3, node3 in AD1.

WLS-HYDRによって作成されたシステム: リージョンに複数のアベイラビリティ・ドメインがある場合(3)、ユーザーはコンピュート・インスタンスをそれら全体に分散するかどうかを選択できます。はいの場合、2つのADにコンピュート・インスタンスを分散します。For example, node1 in AD1, node2 in AD2, node3 in AD1, node4 in AD2.

宛先の同じADにレプリケートされるブロック・ボリュームをグループ化するには、BVグループを適切に定義する必要があります。ボリューム・グループには、同じAD内のブロック・ボリュームのみを含めることができ、グループ内のすべてのブロック・ボリュームは、1つの宛先ADにのみレプリケートできます。ミックス(OCI Block Volumesが同じオリジンADで異なる宛先AD、またはその逆)がある場合は、すべてのレプリカの組合せを管理するために、必要な数のブロック・ボリューム・グループを作成する必要があります。次にいくつかのシナリオの例を示します:
- 例2、2つのノード、プライマリとセカンダリで1つのADのみ
  - プライマリ・リージョン: AD1のnode0、AD1のnode1
  - セカンダリ・リージョン: AD1のnode1、AD1のnode2
  解決方法
  
  プライマリの1つのボリューム・グループ、セカンダリで1つのボリューム・グループにレプリケート
- 例3、2つのノード、1つ以上のAD(プライマリおよびセカンダリ)
  - プライマリ・リージョン: AD1のnode0、AD2のnode1
  - セカンダリ・リージョン: AD1のnode1、AD2のnode2
  解決方法
  
  プライマリには次のボリューム・グループがあります。
  - volume-group-AD1 (node0のBVを使用)をセカンダリAD1にレプリケート(セカンダリnode1の場合)
  - volume-group-AD2 (node1のBVを使用)をセカンダリAD2にレプリケート(セカンダリnode2の場合)
- 例4、6つのノード、1つ以上のAD(プライマリおよびセカンダリ)
  - プライマリ・リージョン: AD1のnode0、AD2のnode1、AD3のnode2、AD1のnode3、AD2のnode4、AD3のnode5
  - セカンダリ・リージョン: AD1のnode1、AD2のnode2、AD1のnode3、AD2のnode4、AD1のnode5、AD2のnode6
  解決方法
  
  プライマリには複数のボリューム・グループが必要です(スイッチオーバー後も同じです)。
  - node0のBVがセカンダリAD1にレプリケートされたvolume-group-reg1AD1-reg2AD1 (セカンダリnode1の場合)
  - node1のBVがセカンダリAD2にレプリケートされたvolume-group-reg1AD2-reg2AD2 (セカンダリnode2の場合)
  - node2のBVがセカンダリAD1にレプリケートされたvolume-group-reg1AD3-reg2AD1 (セカンダリnode3の場合)
  - node3のBVがセカンダリAD2にレプリケートされたvolume-group-reg1AD1-reg2AD2 (セカンダリnode4の場合)
  - node4のBVがセカンダリAD1にレプリケートされたvolume-group-reg1AD2-reg2AD1 (セカンダリnode5の場合)
  - node5のBVがセカンダリAD2にレプリケートされたvolume-group-reg1AD3-reg2AD2 (セカンダリnode6の場合)
セカンダリ中間層ホストから元のブロック・ボリュームをデタッチします。

ノート:

ブート・ボリュームをアンマウントまたはデタッチしないでください。

セカンダリ内の各中間層ホストに対して次の手順を実行します。
1. プライマリからレプリケートされたデータ・ブロック・ボリュームをアンマウントします。
  oracleプロセスが実行されていないことを確認します。実行されていない場合、アンマウントは失敗します。
  例
```
[opc@host ~]$ sudo umount /u01/data
```
2. rootユーザーとして、/etc/fstabファイルを編集し、アンマウントされたブロック・ボリュームのエントリを削除します。
  これにより、次回のリブート時に元のブロック・ボリュームのマウントが試行されなくなります。/u01/dataにマウントされたボリュームのエントリの例:
```
..
#Remove this entry:
#UUID=9e87cf72-a75c-4dff-9825-432f1668d8f9 /u01/data ext4 auto,defaults,_netdev,nofail 0 2
```
3. OCIコンソールからブロック・ボリュームをデタッチします。
  各ブロック・ボリューム、アタッチされたインスタンス、インスタンスからのデタッチの順に移動します。OCIコンソールは、デタッチを完了する前に、一部のISCSIコマンドの実行を要求します。
4. セカンダリのすべての中間層ノードでこれらのステップを繰り返します。
セカンダリ内のデタッチされたOCIブロック・ボリュームを削除するか、名前を変更します。
セカンダリ中間層ホストからデタッチされた元のデータ・ブロック・ボリュームは使用されなくなりました。今すぐ削除することも、後で名前変更および削除することもできます。
セカンダリ中間層ホストでsystemdデーモンを再起動します。
以前にマウントされたデバイスへのキャッシュされた参照をリフレッシュするには、次のコマンドを実行します。
```
sudo systemctl daemon-reload
```

必要に応じて、各サイトに固有の情報を置き換えるスクリプトを準備します。

このアクションは、ブロック・ボリュームに各サイト固有の情報が含まれている場合にのみ適用されます。それ以外の場合は、処置は必要ありません。

特定の要件に従って、ローカル・サイト情報を置き換えるスクリプトを作成します。たとえば、サイト固有データの検索および置換の実行、バックアップ・コピーのリストアなどです。これらのスクリプトを、レプリケートされないフォルダに格納してください。

この時点ではスクリプトを実行しないでください。このスクリプトは、次回検証、スイッチオーバーまたはフェイルオーバーを実行するときに使用します。

ヒント :

Oracle WebLogicの例

たとえば、WebLogicドメインを含むブロック・ボリュームをレプリケートする場合です。スイッチオーバーまたはフェイルオーバー中に、ローカル・データベースを指すように構成で置換を実行する必要があります。このドキュメントでは、この置換を自動化するスクリプトの例を示します。

データベース・タイプ置換スクリプトとダウンロード手順ステップの準備

データベース・タイプ	置換スクリプトとダウンロード手順	ステップの準備
Oracle Base Database ServiceまたはOracle Exadata Database Service	`replacement_script_BVmodel.sh` GitHub `https://github.com/oracle-samples/maa`のMAAリポジトリに移動します。すべてのスクリプトを wls_mp_drディレクトリにダウンロードします。このスクリプトは、`wls_mp_dr/Block_Volume_Replica_Method`フォルダにあります。すべての中間層ホストにコピーします。	このスクリプトは、データベース接続文字列を置き換えます。また、クリーンな起動のために、WebLogicサーバーの状態ファイル(`.lck`および`.state`)もクリーンアップされます。各サイトでデータベースのローカル値とリモート値を指定して、各ホストで編集およびカスタマイズします。値はサイトによって異なります。site1ホストでカスタマイズすると、LOCAL値はsite1の値を参照し、REMOTE値はsite2の値を参照します。site2ホストでスクリプトをカスタマイズする場合、LOCAL値はsite2を参照し、REMOTE値はsite1を参照します。
Autonomous Database	`fmwadb_switch_db_conn.sh` GitHub `https://github.com/oracle-samples/maa`のMAAリポジトリに移動します。すべてのスクリプトを`app_dr_common`ディレクトリにダウンロードします。すべてのスクリプトを`fmw-wls-with-adb-dr`ディレクトリにダウンロードします。すべての中間層ホストにコピーします。スクリプトは相互にコールします。両方のディレクトリのすべてのスクリプトを同じフォルダに配置します。	スクリプトを編集する必要はありません。フォルダおよびパスワードの値は入力として渡されます。スクリプトを実行するには: `./fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD` ここで、WALLET_DIRは、ローカル・データベースに接続するための`tnsnames.ora`、キーストアおよびトラストストア・ファイルを含むフォルダです。レプリカでWALLET_DIRフォルダがオーバーライドされていないことを確認します。この時点では、このスクリプトを実行しないでください。

Oracle Base Database ServiceまたはOracle Exadata Database Service

replacement_script_BVmodel.sh

GitHub https://github.com/oracle-samples/maaのMAAリポジトリに移動します。
すべてのスクリプトを wls_mp_drディレクトリにダウンロードします。
このスクリプトは、wls_mp_dr/Block_Volume_Replica_Methodフォルダにあります。
すべての中間層ホストにコピーします。

このスクリプトは、データベース接続文字列を置き換えます。また、クリーンな起動のために、WebLogicサーバーの状態ファイル(.lckおよび.state)もクリーンアップされます。

各サイトでデータベースのローカル値とリモート値を指定して、各ホストで編集およびカスタマイズします。

値はサイトによって異なります。site1ホストでカスタマイズすると、LOCAL値はsite1の値を参照し、REMOTE値はsite2の値を参照します。site2ホストでスクリプトをカスタマイズする場合、LOCAL値はsite2を参照し、REMOTE値はsite1を参照します。

Autonomous Database

fmwadb_switch_db_conn.sh

GitHub https://github.com/oracle-samples/maaのMAAリポジトリに移動します。
すべてのスクリプトをapp_dr_commonディレクトリにダウンロードします。
すべてのスクリプトをfmw-wls-with-adb-drディレクトリにダウンロードします。
すべての中間層ホストにコピーします。
スクリプトは相互にコールします。
両方のディレクトリのすべてのスクリプトを同じフォルダに配置します。

スクリプトを編集する必要はありません。フォルダおよびパスワードの値は入力として渡されます。

スクリプトを実行するには:

./fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD

ここで、WALLET_DIRは、ローカル・データベースに接続するためのtnsnames.ora、キーストアおよびトラストストア・ファイルを含むフォルダです。

レプリカでWALLET_DIRフォルダがオーバーライドされていないことを確認します。

この時点では、このスクリプトを実行しないでください。

OCIブロック・ボリュームのレプリケーションの検証

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

画像は、アクティブ化によってレプリカからアタッチ可能なOCI Block Volumesがどのように作成されるかを示しています。

図activation-create-bv.pngの説明

アクティベーション-create-bv-oracle.zip

次の手順を実行して、レプリケートされたボリュームをスタンバイ・システムで使用可能にします。

スタンバイ・サイトでレプリカをアクティブ化します。
OCI Block Volumesレプリカを直接マウントすることはできません。最初にアクティブ化する必要があります。ブロック・ボリューム(BV)レプリカをアクティブ化すると、アタッチ可能なBVがレプリケートされたBVのクローンとして作成されます。その後、クローニングされたBVをコンピュート・インスタンスにアタッチできます。

次のステップを実行して、スタンバイ・サイトでレプリカをアクティブ化します。
1. OCIコンソールで、スタンバイ・サイトのリージョンに移動します。「ブロック・ストレージ」、「ボリューム・グループ・レプリカ」の順に選択します。
2. ボリューム・グループ・レプリカをクリックし、「アクティブ化」をクリックします。
3. このアクティブ化の結果として作成されたボリューム・グループに名前を付けます。わかりやすくするために、プライマリ・リージョンと同じ名前を使用します。
4. スタンバイ・サイトのすべてのボリューム・グループ・レプリカに対して同じステップを繰り返します。
レプリケートされたブロック・ボリュームをスタンバイ・サイトの中間層ホストにアタッチします。
1. OCIコンソールで、「ストレージ」、「ブロック・ボリューム」の順に選択し、スタンバイ・サイトでのアクティブ化の結果として作成されたアタッチ可能なOCIブロック・ボリュームを見つけます。
2. 適切なブロック・ボリュームを適切なホストにアタッチします。「ブロック・ボリューム」、「アタッチされたインスタンス」、「インスタンスにアタッチ」の順にクリックします。この手順を簡略化するには、「Oracle Cloud Agentを使用して、iSCSIでアタッチされたボリュームに自動的に接続します」を選択します。
  クラウド・エージェントはiSCSIコマンドを自動的に実行するため、実行する必要はありません。これを使用するには、ホストでブロック・ボリューム管理プラグインを有効にしてください。
3. Oracle Cloud Agentを使用しない場合は、iSCSIコマンドを手動で実行します。アタッチされているブロック・ボリュームの「ISCSIコマンドおよび情報」をクリックし、中間層ホストで「接続用のコマンド」に用意されているISCSIコマンドを実行します。
レプリケートされたブロック・ボリュームをスタンバイ・ホストにマウントします。
ブロック・ボリュームごとに次を実行します。
1. アタッチされた新しいブロック・ボリュームのUUIDを取得します。
  これは、ブロック・ボリュームがプライマリ・サイトにあるのと同じUUIDです。たとえば:
```
[root@prefix-wls-0 opc]# sudo blkid
/dev/sda3: UUID="974147f5-d731-41de-bba8-56ff78ed1c9c" TYPE="xfs"    PARTUUID="4a95c68a-bc70-4be9-bce8-b15e995fcf46"
/dev/sda1: SEC_TYPE="msdos" UUID="593B-B893" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="c5ac3089-6a91-40e0-bcc1-212ba0b43418"
/dev/sda2: UUID="9ca12daa-d7ea-44a2-8680-5b676488b054" TYPE="swap" PARTUUID="682a63d1-d3ec-4019-b372-43720aaae717"
/dev/sdb: UUID="35e72262-979a-4d84-85ce-a6f91e3b1250" TYPE="ext4" 
/dev/sdc: UUID="c293b5b5-005c-43e9-8c2f-02e873b76926" TYPE="ext4" 
```
2. まだない場合は、ホストの/etc/fstabファイルに適切なUUIDのエントリを追加して、マウントし、再起動後にマウントを保持します。
  プライマリ・サイトと同じファイル・システム形式(ext4など)を使用してください。たとえば:
```
UUID=c293b5b5-005c-43e9-8c2f-02e873b76926 /u01/data ext4  auto,defaults,_netdev,nofail
```
  レプリケートされた各ブロック・ボリュームのUUIDは同じ値のままです。Oracleでは、新しく追加したエントリを将来のために/etc/fstabファイルに保持することをお薦めします。したがって、systemdデーモンは、スイッチオーバーまたはフェイルオーバー操作中に次回アタッチされるときに、ブロック・ボリュームを自動的にマウントします。
3. 新しいアタッチされたブロック・ボリュームをマウントします。デバイスがアタッチされているときに適切なエントリが/etc/fstabファイルにすでに存在する場合、ブロック・ボリュームはアタッチされた後に自動的にマウントされます。
  次の例は、アタッチされた新しいブロック・ボリュームをマウントする方法を示しています。
```
[root@prefix-wls-0 opc]# mount -a
[root@prefix-wls-0 opc]# df -h| grep /u01/data
/dev/sdb 49G 1.4G 46G 3% /u01/data
```
4. このステップを繰り返して、アクティブ化されたすべてのブロック・ボリュームをアタッチします。
セカンダリ中間層ホストでサイト固有の情報を置き換えます。
置換スクリプトは、セカンダリ中間層ホスト内のサイト固有の情報を置き換えます。
ヒント :
WebLogicドメインを含むブロック・ボリュームの例
すべてのスタンバイ中間層ホストで置換スクリプトを実行して、ローカル・データベースを指すようにデータベース接続情報を更新します。
1. システムでOracle Base Database ServiceまたはOracle Exadata Database Serviceを使用する場合は、replacement_script_BVmodel.shスクリプトを実行します。
  適切な値を使用していることを確認してください。
2. システムでOracle Autonomous Databaseが使用されている場合は、fmwadb_switch_db_conn.shスクリプトを実行します。
  スクリプトでは、入力として、セカンダリ・オリジナルのウォレットがあるパスおよびウォレット・パスワードが必要です。
  
  tns_adminフォルダがDOMAIN_HOME/configフォルダの下にある場合は、管理ホストでのみスクリプトを実行できます。残りのノードは、管理対象サーバーの起動時に、更新されたtnsnames.oraをダウンロードします。それ以外の場合は、すべての中間層ホストでスクリプトを実行します。
サーバーのロックファイルをクリーンアップします。
レプリケートされたブロック・ボリュームには、プライマリ・プロセスの起動中にレプリカが実行されるため、中間層プロセスのロック・ファイルが含まれる場合があります。セカンダリでプロセスを開始する前に、これらのファイルをクリーンアップする必要がある場合があります。そうしないと、中間層プロセスの起動を防ぐことができます。
ヒント :
WebLogicドメインを含むブロック・ボリュームの例
プライマリから転送される${DOMAIN_HOME}/servers/*/data/nodemanagerフォルダには、.lck、.pidまたは.stateファイルがある場合があります。ノード・マネージャおよびサーバーを起動する前に、これらのファイルがクリーンアップされていることを確認してください。例
```
rm -f ${DOMAIN_HOME}/servers/*/data/nodemanager/*.lck
rm -f ${DOMAIN_HOME}/servers/*/data/nodemanager/*.state
rm -f ${DOMAIN_HOME}/servers/*/data/nodemanager/*.pid
```
このアクションは、置換スクリプトに、またはOracle WebLogicの起動の前のステップとして含めることができます。
前のイメージに示すように、アクティブ化によってレプリカからアタッチ可能なブロック・ボリュームが作成されます。
スイッチオーバーまたはフェイルオーバーが完了したら、スタンバイ・ロールを持つサイトのブロック・ボリュームをデタッチして削除する必要があります。これは、(スタンバイ・データベースをスナップショット・モードでオープンして)スタンバイ・サイトで検証を完了し、スタンバイ・ロールに戻す場合にも必要です。
1. プライマリからレプリケートされるスタンバイ・サイト内のすべてのブロック・ボリュームをアンマウントします。
```
[root@prefix-wls-0 opc]# umount /u01/data
```
2. スタンバイのブロック・ボリュームをデタッチします。
  OCIコンソールUI (またはAPI)を使用して、アンマウントされたブロック・ボリュームをスタンバイ中間層ホストからデタッチし、将来に備えます。Oracle Cloud Agentを使用してブロック・ボリュームをアタッチした場合、エージェントはiSCSIコマンドを実行してiSCSIターゲットからログオフします。
3. スタンバイのブロック・ボリュームおよびグループを削除します。
  
  スタンバイ中間層ホストからデタッチされたボリュームを削除または名前変更して、誤ってマウントされないようにします。
  
  スタンバイ・サイトの未使用のボリューム・グループを削除します。それらは使用されなくなります。

OCIブロック・ボリュームの進行中のレプリケーションの実行

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

OCIは、バックグラウンドでOCI Block Volumesレプリケーションを自動的に実行します。システムのライフサイクル中に行う必要がある唯一のことは、プライマリ・ロールを持つシステムのボリューム・グループでリージョン間レプリカが有効になっていることを確認することです。
OCI Full Stack Disaster Recoveryを使用してスイッチオーバーおよびフェイルオーバーのタスクを自動化することを検討してください。OCIコンソールを使用して、1回のクリックでスイッチオーバーまたはフェイルオーバー計画を実行できます。ブロック・ボリューム・レプリカに関連するすべてのタスクの実行を簡略化すると非常に便利です。
レプリケーション機能は、バックアップ機能を補完するものであり、代替する機能ではありません。レプリケートするブロック・ボリュームのバックアップ・ポリシーを有効にしてください。これにより、リージョン間のレプリカに加えてデータ保護が提供され、ポイントインタイムにリストアできます。
各サイトに固有の情報を保持し、最新の状態に保ちます。たとえば、ファイル・システムに、Oracle Autonomous Databaseに接続するためのアーティファクトを含むフォルダが含まれている場合は、このフォルダのバックアップ・コピーを保持します。ウォレットで更新を実行する場合は、フォルダのバックアップを更新してください。このようにして、後続のスイッチオーバーおよびフェイルオーバーで正しくリストアされます。
スイッチオーバーまたはフェイルオーバー操作後に、レプリカの方向を変更します。このためには、次を実行します。
- 新しいプライマリのOCIブロック・ボリューム・グループで、新しいスタンバイ・サイトのレプリカを有効にします。
- 元のプライマリから前のレプリケーションを無効にし、未使用のブロック・ボリュームを削除します。