OCI File Storageレプリケーションの実装

この実装では、Oracle Cloud Infrastructure File Storageレプリケーション機能を使用します。この機能は、OCI File Storageファイル・システムの自動クロスリージョン・レプリカを提供します。

OCIファイル・ストレージ・レプリケーションを実装する利点は次のとおりです:

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

OCI File Storageを実装する際の考慮事項は次のとおりです:

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

OCIファイル・ストレージのレプリケーションの設定

OCIファイル・ストレージ・レプリケーションを実装するには、次のステップが必要です:

• OCIコンソールを使用して、セカンダリ・サイトにターゲットOCIファイル・システムを作成します。
• 適切なターゲットOCIファイル・システムをポイントして、プライマリOCIファイル・システムでレプリカを有効にします。
• セカンダリ・リージョンの中間層ホストに接続し、プライマリからレプリケートされるファイル・システムをアンマウントします。
• OCIコンソールUIを使用して、プライマリからレプリケートされるOCIファイル・システムをデタッチおよび破棄します。
• レプリカの後に適切な情報でサイト固有の情報を更新することによって、サイト固有の情報を管理する方法を実装します。

例1: OCI File Storageレプリケーションを使用した中間層構成およびランタイムのレプリケート

ノート:

この例は、すべての中間層システムに適用されます。参照として、Oracle Fusion Middlewareエンタープライズ・デプロイメント・ガイドのベスト・プラクティスに従ったOracle WebLogic Serverシステムを使用します。このシステムには、2つのOCIファイル・ストレージ・ファイル・システムがあります。1つは共有構成(WebLogic管理ドメイン、キーストアなど)用で、もう1つはランタイム・データ用です。ただし、同じステップに従って、中間層のOCI File Storageファイル・システムをレプリケートできます。

OCIファイル・ストレージ・ファイル・システムのリージョン間レプリカを設定するには、次を実行します:

1. 各サイトに固有の情報をバックアップします。
   ファイル・システムには、データベースまたはLDAPサーバーへの接続文字列など、各サイト固有の情報を含むファイルを含めることができます。OCIファイル・ストレージ・レプリカを使用する場合、レプリケートされたファイル・システムはプライマリの正確なコピーです。レプリカから特定のファイルまたはフォルダをスキップすることはできません。したがって、各サイトの情報を適応させることで、これらの違いを管理する必要があります。様々なアプローチがあります。

   • ファイルの文字列検索および置換は、サイト固有の情報を使用して実行できます。
   • この情報は、レプリカの前にバックアップして、後でリストアできます。

   この時点で、レプリカを有効にする前に、レプリケートされるブロック・ボリューム内のサイト固有の情報を含むファイルを識別してバックアップします。レプリケートされたブロック・ボリュームの下ではない場所にバックアップ・コピーを作成します。そうしないと、バックアップ・コピーはオーバーライドされます。

   ヒント :

   Oracle WebLogicの例

   たとえば、WebLogicドメインを含むファイル・システムをレプリケートする場合、データベースに接続するための情報を含むファイルがあります。この情報は、TNS管理フォルダにあります。フォルダを識別するには、WebLogicデータ・ソースのtns_adminプロパティを確認します。このドキュメントでは、シナリオに応じて適切なアプローチに従って、これを管理するためのスクリプトを提供します。

   • システムがOracle Base Database ServiceまたはOracle Exadata Database Serviceに接続する場合、スイッチオーバーおよびフェイルオーバー操作中に、セカンダリ中間層システムのtnsnames.oraファイル内のデータベース接続文字列を更新できます。このドキュメントでは、このスクリプトの例を示します。
   • システムがAutonomous Databaseに接続する場合、TNS管理フォルダにはさらに多くのアーティファクト(トラスト・ストアとキーストア)が含まれます。プライマリとスタンバイでは異なるため、単純な文字列置換で更新できません。このドキュメントでは、TNSフォルダのバックアップ・コピーをリストアするスクリプトを提供します。

   この時点では、TNSフォルダ情報のバックアップのみを実行する必要があります。

2. プライマリ・サイトのOCI File Storageファイル・システムの情報を識別します。
   • レプリケートされるOCIファイル・ストレージ・ファイル・システムの場合、プライマリ中間層ホストの名前、マウント・ターゲット、エクスポートおよびマウント・ポイントを識別します。
   • OCIコンソールに移動し、プライマリ・リージョンを選択してから、コンパートメントを選択します。
   • 「ストレージ」、「ファイル・ストレージ」、「ファイル・システム」の順にナビゲートし、ファイル・システムを識別します。
   • name、export、mount target、およびそれらが存在する ADを保存します。

   ホストの/etc/fstabをチェックして、エクスポートおよびマウント・ポイントをマウントするホストを識別します。

   ヒント :

   Oracle WebLogicの例

   たとえば、エンタープライズ・デプロイメント・ガイドに従うOracle WebLogic Serverシステムでは、次のようになります。

   OCIファイル・システム	マウント・ターゲット	エクスポート・パス	AD	ホストとマウントポイント
   configFS	mt1_region1	/exports/configFS	AD1	apphost1, /u01/oracle/config apphost2, /u01/oracle/config
   runtimeFS	mt1_region1	/exports/runtimeFS	AD1	apphost1, /u01/oracle/runtime apphost2,/u01/oracle/runtime

3. セカンダリ・サイトのOCI File Storageファイル・システムの情報を識別します。
   前のステップで説明したステップを繰り返して、セカンダリ・サイトで同じ情報を収集します。

   ヒント :

   Oracle WebLogicの例

   たとえば、エンタープライズ・デプロイメント・ガイドに従うWebLogicシステムでは、次のようにします。

   OCIファイル・システム	マウント・ターゲット	エクスポート・パス	AD	ホストとマウントポイント
   configFS	mt1_region2	/exports/configFS	AD1	apphost1, /u01/oracle/config apphost2, /u01/oracle/config
   runtimeFS	mt1_region2	/exports/runtimeFS	AD1	apphost1, /u01/oracle/runtime apphost2, /u01/oracle/runtime

4. セカンダリ中間層ホストから元のOCIファイル・ストレージ・ファイル・システムをアンマウントします。
   セカンダリ内の各中間層ホストの場合、プライマリからレプリケートされるファイル・システムをアンマウントします。たとえば:

   [opc@host ~]$ sudo umount  /u01/oracle/config
   [opc@host ~]$ sudo umount  /u01/oracle/runtime

   oracleプロセスが実行されていないことを確認します。実行されていない場合、アンマウントは失敗します。セカンダリのすべての中間層ノードでこれらのステップを繰り返します。

   これらのマウントのエントリを/etc/fstabファイルから削除しないでください。レプリケートされたファイル・システムのマウント・ターゲットおよびエクスポート名に常に同じ値を使用する場合、エントリはライフサイクル全体を通して有効になります。

5. セカンダリ内の元のOCIファイル・ストレージ・ファイル・システムを削除するか、名前を変更します。
   OCIファイル・ストレージ・レプリケーションのターゲット・ファイル・システムとして設定できるのは、エクスポートされたことがないファイル・システムのみです。したがって、セカンダリ中間層ホストにマウントされた元のファイル・システムをレプリケーション・ターゲットとして使用することはできません。これらは使用されなくなります。エクスポートを削除してファイル・システムを終了することで、今すぐ削除(または後で名前変更および削除)します。

   ノート:

   マウント・ターゲットは削除しないでください。これらは、レプリケートされたファイル・システムのエクスポートに使用されます。
6. プライマリ・ファイル・システムでレプリカを有効にします。
   プライマリで、レプリケートする必要がある各OCIファイル・ストレージ・ファイル・システムのレプリカを有効にします。
   1. OCIコンソールに移動し、プライマリ・リージョンを選択してコンパートメントを選択します。
   2. 「ストレージ」、「ファイル・ストレージ」、「ファイル・システム」の順に選択します。
   3. ファイル・システム名をクリックし、「レプリケーション」に移動して「レプリケーションの作成」をクリックします。
      レプリケーションの名前を指定します。
   4. 「新規ターゲット・ファイル・システムの作成」を選択し、次の詳細を指定します:
      • 名前: セカンダリ・リージョンに作成されるファイル・システム・レプリカの名前。レプリカとして明確に識別する名前を使用します(例: configFS_replica)。
      • ターゲット・リージョン: セカンダリ・システムのリージョン。
      • 可用性ドメイン: ターゲット・ファイル・システムの可用性ドメイン。エクスポートするマウント・ターゲットと同じである必要があります。
      • コンパートメント: ターゲット・ファイル・システムのコンパートメント。
      • レプリケーション間隔: データ・レプリケーション頻度を決定する分単位の間隔。

   ノート:

   または、事前にセカンダリでターゲット・ファイル・システムを作成し、ここでOCIDを指定できます。
7. 必要に応じて、各サイトに固有の情報を置き換えるスクリプトを準備します。

   このアクションは、OCIファイル・ストレージ・ファイル・システムに各サイトに固有の情報が含まれている場合にのみ適用されます。それ以外の場合は、処置は必要ありません。

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

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

   ヒント :

   Oracle WebLogicの例

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

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

OCIファイル・システム・レプリケーションの準備ができました。

OCIファイル・ストレージのレプリケーションの検証

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

レプリケートされたOCIファイル・ストレージ・ファイル・システムをスタンバイ・システムで使用可能にするには、ファイル・システムごとに次のアクションに従います。

スタンバイでレプリケートされたファイル・システムを使用するには、次のステップを実行します。

1. ターゲット・ファイル・システムのクローンを作成します。
   ターゲット・ファイル・システムを直接マウントすることはできません。最初にクローニングする必要があります。
   1. セカンダリで、「ストレージ」、「ファイル・ストレージ」、「ファイル・システム」の順に移動します。
   2. ターゲット・ファイル・システム名をクリックします。
   3. 「ファイル・システム情報」の「レプリケーション」セクションで、「レプリケーション・ターゲット」の名前リンクをクリックします。
   4. 「最終スナップショット」名前リンクをクリックします。
   5. 「クローン」をクリックして、このスナップショットから通常のファイル・システムを作成します。
   6. 詳細を編集して、クローンの名前を指定します。
      一貫性を保つには、プライマリと同じ名前(たとえば、configFS)を使用します。
2. クローン・ファイル・システムのエクスポートを作成します。
   1. クローニングされたファイル・システムで、「エクスポート」に移動します。
   2. セカンダリでマウント・ターゲットを選択します。
   3. エクスポート名を選択します。
      スイッチオーバー管理を容易にするには、プライマリのエクスポートと同じ名前を使用します。たとえば: /exports/configFS。
3. スタンバイ・ホストからファイル・システムをマウントします。
   1. ファイル・システムに同じエクスポート名と同じマウント・ターゲットを常に使用する場合、/etc/fstabファイルのマウントのエントリはライフサイクル中に変更されません。
   2. ファイル・システムに同じエクスポート名とマウント・ターゲットを使用しない場合は、/etc/fstabファイルを編集し、スイッチオーバー、フェイルオーバーおよび検証のたびにエントリを変更する必要があります。
      次に、/etc/fstabエントリの例を示します。

      10.1.80.131:/exports/configFS    /u01/oracle/config  nfs  defaults,nofail,nosuid,resvport 0 0

   3. /etc/fstabファイルに適切なマウント・エントリが含まれている場合は、ファイル・システムをホストにマウントします。
      たとえば:

      [opc@host opc]# sudo mount -a

   4. ファイル・システムをマウントするすべてのスタンバイ・ホストで繰り返します。
4. すべてのスタンバイ中間層ホストで置換スクリプトを実行して、セカンダリ中間層ホスト内のサイト固有の情報を置換します。

   ヒント :

   Oracle WebLogicの例

   たとえば、Oracle WebLogicドメインを含むファイル・システムでは、すべてのスタンバイ中間層ホストで置換スクリプトを実行して、ローカル・データベースを指すようにデータベース接続情報を更新します。

   • システムでOracle Base Database ServiceまたはOracle Exadata Database Serviceが使用されている場合、スクリプトはreplacement_script_BVmodel.shです。適切な値を使用していることを確認してください。
   • システムでOracle Autonomous Databaseが使用されている場合、スクリプトはfmwadb_switch_db_conn.shです。これには、入力として、セカンダリ・オリジナルのウォレットがあるパスおよびウォレット・パスワードが必要です。
5. サーバーのロックファイルをクリーンアップします。

   プライマリ・プロセスが稼働している間にレプリカが実行されるため、レプリケートされたファイル・システムには中間層プロセスのロック・ファイルが含まれる場合があります。セカンダリでプロセスを開始する前に、これらのファイルをクリーンアップする必要がある場合があります。そうしないと、中間層プロセスが開始されないようにできます。

   ヒント :

   Oracle WebLogicの例

   たとえば、Oracle 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の起動の前のステップとして含めることができます。

6. スイッチオーバーまたはフェイルオーバー操作が完了したら、スタンバイ・ロールを持つサイトのOCIファイル・ストレージ・ファイル・システムをアンマウントして削除する必要があります。次のステップを実行して、スタンバイ・ロールに戻ります。
   これは、(スタンバイ・データベースをスナップショット・モードでオープンして)スタンバイ・サイトで検証を完了し、スタンバイ・ロールに戻す場合にも必要です。
   1. プライマリからレプリケートされるスタンバイ・サイトでOCIファイル・ストレージ・ファイル・システムをアンマウントします。
      たとえば:

      [opc@host opc]# sudo umount /u01/oracle/config

   2. アンマウントされたファイル・システムを削除します。
      スタンバイ・サイトでアンマウントされたファイル・システムを終了します。それらは使用されなくなりました。

OCI File Storageの進行中のレプリケーションの実行

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

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