5 ライフサイクル操作の管理

この章では、継続的な同期、パッチ適用、スケール・アウト操作など、障害保護システムにおいて特定の意味を持つ追加のメンテナンス・タスクについて説明します。

プライマリ・サイトとセカンダリ・サイトの間の継続的なレプリケーションのスケジューリング

スイッチオーバー・シナリオまたはフェイルオーバー・シナリオで一貫した動作を維持するには、プライマリ・サイトの変更をセカンダリ・サイトに伝播する必要があります。これは、検証や確認が本番サイトに変更を加えることなく現実的なデータを使用して行われていることを保証するために必要です。

  • 様々なアプローチと、Fusion Middlewareシステムで使用されるデータ・タイプごとにレプリケーション頻度を決定する方法の詳細は、「ファイル・システム・レプリケーション戦略の計画」を参照してください。

  • 通常の操作中、セカンダリ・サイトは本番サイトのストレージから定期的に転送されるコピーを受け取ります。説明したとおり、これはストレージ・スナップショット、rsync操作またはDBFSを使用して実行できます。コピーが作成された後、セカンダリ・サイトのストレージには、フェイルオーバーまたはスイッチオーバー前の本番サイトからの最後の転送に含まれていた、その時点までのすべてのデータが含まれます。

  • ストレージ・レプリケーションを非同期レプリケーション・モードで使用している場合、要求した頻度で(ほとんどのベンダーは手動、スケジュールどおり、継続的のオプションを提供)、本番サイトの共有ストレージで変更されたデータ・ブロック(前のスナップショット・コピーとの比較に基づく)が新しいスナップショット・コピーになります。スナップショット・コピーは、セカンダリ・サイトの共有ストレージに転送されます。

  • rsyncまたはDBFSを使用する場合は、cronジョブまたはスケジューラ・ソフトウェアを使用して定期的にコピーをトリガーし、セカンダリWebLogicドメインで使用されるようにします。初期設定で使用したものと同じスクリプトが継続的に同期を繰り返すようにスケジュールする必要があります。ステージング場所を使用したDBFSとrsyncのいずれにおいても、プライマリ・ノードからステージング場所へのコピーとステージング場所からセカンダリ・ノードへのコピーを行うデュアル・スケジューリングが必要です。rsyncのピアツーピア方式では、コピーは1ステップで実行されるため、スケジュールする必要がある操作は1つのみです。

  • コピーの頻度と発生するオーバーヘッドとのトレードオフが発生します。システムの正確なRTOによって、同期操作のスケジュール方法が決まります。

  • 本番サイトで中間層に変更を加えた場合は、必ず強制的に同期を実行します。たとえば、本番サイトに新しいアプリケーションまたはモジュールをデプロイした場合や、データ・ソースとJMS宛先の構成を変更した場合です。ストレージ・レプリケーション・テクノロジの使用時に同期を強制するか、セカンダリへの関連するrsyncコピーをトリガーするには、ベンダー固有の手順に従ってください。DBFSを使用する場合は、DBFSのステージング場所もプライマリからの更新で更新されるようにします。

  • スイッチオーバーまたはフェイルオーバーの後、レプリケーションが実行されている方向を元に戻す必要があります。セカンダリの場所がアクティブなサイトになったら、構成変更の継続的なレプリケーションを元に戻して、このセカンダリ・リージョンから元のプライマリへコピーが行われるようにする必要があります。そうしないと、プライマリの古い変更でアクティブなシステムを上書きしてしまう可能性があります。

rsyncスクリプトによる継続的なレプリケーションのスケジューリング

データ・タイプごとのレプリケーションの頻度を決定したら(「ファイル・システム・レプリケーション戦略の計画」を参照)、スケジューラ・ソフトウェアを使用してレプリケーション操作をプログラムできます。Linuxでは、このレプリケーションにcronジョブを使用できます。

ピアツーピア・モデルを使用している場合は、次のステップをガイドラインとして使用できます。

  1. セカンダリのWebLogic管理サーバー・ノードのrootユーザーとして、次を実行します。

    crontab -e

  2. cronファイルを編集し、https://github.com/oracle-samples/maa/tree/main/1412EDGにあるサンプル・スクリプトを使用して、次の行を追加します。

    ノート:

    172.11.2.111は、このドキュメントに示す例でWebLogic管理サーバーを実行しているプライマリ・ノードのIPです。これを、実際に使用している正確なIPに置き換えます。 
    
0 0 * * * su oracle -c "/home/oracle/maa/1412EDG/rsync_for_WLS.sh 172.11.2.111 /u01/oracle/config/ /home/oracle/my_keys/SSH_KEY.priv"
0 0 * * * su oracle -c /home/oracle/maa/1412EDG/rsync_for_WLS.sh 172.11.2.111 /u02/oracle/config/ /home/oracle/my_keys/SSH_KEY.priv"
0 0 */7 * * su oracle -c "/home/oracle/maa/1412EDG/rsync_for_WLS.sh 172.11.2.111  /u01/oracle/products/ /home/oracle/my_keys/SSH_KEY.priv"

  3. セカンダリのWebLogic管理対象サーバーの各ノードのrootユーザーとして、次を実行します。 

    crontab -e
  4. cronファイルを編集し、https://github.com/oracle-samples/maa/tree/main/1412EDGにあるサンプル・スクリプトを使用して、次の行を追加します。

    ノート:

    172.11.2.112は、このドキュメントに示す例で2番目のWebLogic管理対象サーバーを実行しているプライマリ・ノードのIPです。これを、実際に使用している正確なIPに置き換えます) 
    
0 0 * * * su oracle -c /home/oracle/maa/1412EDG/rsync_for_WLS.sh 172.11.2.112 /u02/oracle/config/ /home/oracle/my_keys/SSH_KEY.priv"
0 0 * * *  su oracle -c "/home/oracle/maa/1412EDG/rsync_for_WLS.sh 172.11.2.112  /u01/oracle/products/ /home/oracle/my_keys/SSH_KEY.priv"

    ノート:

    EDGが(共有ストレージ上で) Oracleホームとして使用する物理的な場所は2つのみなので、3つ以上のノードがある場合は、最初の2つからの/u01/oracle/productsのコピーをスケジュールすれば十分です。

    これで、管理サーバーのドメイン・ディレクトリと管理対象サーバーのドメイン・ディレクトリを毎日午前0時にプライマリからプルするスケジュールと、OracleホームとJDKのインストールを毎週コピーするスケジュールが作成されました。RTO、RPOおよび変更規模のニーズに応じて頻度を調整してください。同様に、OHSノードにcronジョブを作成します(これまでの項で説明したように、OHS構成の変更頻度はWebLogicドメインより大幅に低くなるため、コピーの頻度が低くなるように調整しても構いません)。

ステージング・モデルを使用している場合は、次のステップをガイドラインとして使用できます。

  1. ステージング・ノードのrootユーザーとして、「rsyncレプリケーション用のプライマリ・ストレージの準備」で説明されているディレクトリ構造を使用して、次を実行します。 

    crontab -e
  2. cronファイルを編集し、https://github.com/oracle-samples/maa/tree/main/1412EDGにあるサンプル・スクリプトを使用して、次の行を追加します。

    ノート:

    172.11.2.111は、WebLogic管理サーバーを実行しているプライマリ・ノードのIPで、172.11.2.112は、このドキュメントに示す例で2番目のWebLogic管理対象サーバーを実行しているプライマリ・ノードのIPです。これを、実際に使用している正確なIPに置き換えます。 
    
0 0 * * * su oracle -c "export DEST_FOLDER=/staging_location/midtier/wls_shared_config/;/home/oracle/maa/1412EDG/rsync_for_WLS.sh 172.11.2.111 /u01/oracle/config/ /home/oracle/my_keys/SSH_KEY.priv "
0 0 * * * su oracle -c "export DEST_FOLDER=/staging_location/midtier/wls_private_config/wlsnode1_private_config;/home/oracle/maa/1412EDG/rsync_for_WLS.sh 172.11.2.111 /u02/oracle/config/ /home/oracle/my_keys/SSH_KEY.priv"
0 0 * * * su oracle -c "export DEST_FOLDER=/staging_location/midtier/wls_private_config/wlsnode2_private_config;/home/oracle/maa/1412EDG/rsync_for_WLS.sh 172.11.2.112 /u02/oracle/config/ /home/oracle/my_keys/SSH_KEY.priv"

0 0 */7 * * su oracle -c "export DEST_FOLDER=/staging_location/midtier/wls_products_home/wls_products_home1;/home/oracle/maa/1412EDG/rsync_for_WLS.sh 172.11.2.111  /u01/oracle/products/ /home/oracle/my_keys/SSH_KEY.priv"
0 0 */7 * * su oracle -c "export DEST_FOLDER=/staging_location/midtier/wls_products_home/wls_products_home2;/home/oracle/maa/1412EDG/rsync_for_WLS.sh 172.11.2.112  /u01/oracle/products/ /home/oracle/my_keys/SSH_KEY.priv"

    ノート:

    一方が破損しても構わないように、2つの異なるノードからOracleホームのコピーを2つ作成しておくことをお薦めします。

    これで、プライマリからのコピーを含むバックアップがステージング・ノード/場所に作成されました。ステージング・ノードからセカンダリのWebLogicノードへの転送をスケジュールする必要があります。プライマリからステージング・ノードへの転送の間に遅延が発生するため、この2番目の転送は遅らせることをお薦めします。たとえば、毎日午前2時などです。

  1. セカンダリのWebLogic管理サーバー・ノードのrootユーザーとして、次を実行します。

    crontab -e
  2. cronファイルを編集し、https://github.com/oracle-samples/maa/tree/main/1412EDGにあるサンプル・スクリプトを使用して、次の行を追加します。

    ノート:

    staging_node_ipは、ステージング・ノードのIPです。 
    
0 2 * * * su oracle -c "export DEST_FOLDER=/u01/oracle/config/;/home/oracle/maa/1412EDG/rsync_for_WLS.sh staging_node_ip /staging_location/midtier/wls_shared_config/ /home/oracle/my_keys/SSH_KEY.priv"
0 2 * * * su oracle -c "export DEST_FOLDER=/u02/oracle/config/;/home/oracle/maa/1412EDG/rsync_for_WLS.sh staging_node_ip /staging_location/midtier/wls_private_config/wlsnode1_private_config /home/oracle/my_keys/SSH_KEY.priv"
0 2 * * * su oracle -c "export DEST_FOLDER=/u01/oracle/products  ;/home/oracle/maa/1412EDG/rsync_for_WLS.sh staging_node_ip  /staging_location/midtier/wls_products_home/wls_products_home1 /home/oracle/my_keys/SSH_KEY.priv"

  3. セカンダリのWebLogic管理対象サーバーの各ノードのrootユーザーとして、次を実行します。 

    crontab -e
  4. cronファイルを編集し、https://github.com/oracle-samples/maa/tree/main/1412EDGにあるサンプル・スクリプトを使用して、次の行を追加します。

    ノート:

    staging_node_ipは、ステージング・ノードのIPです。 
    
0 2 * * * su oracle -c "export DEST_FOLDER=/u02/oracle/config; /home/oracle/maa/1412EDG/rsync_for_WLS.sh staging_node_ip / staging_location/midtier/wls_private_config/wlsnode2_private_config; /home/oracle/my_keys/SSH_KEY.priv"
0 2 * * * su oracle -c "export DEST_FOLDER=/u01/oracle/products; /home/oracle/maa/1412EDG/rsync_for_WLS.sh staging_node_ip / staging_location/midtier/wls_products_home/wls_products_home2 /home/oracle/my_keys/SSH_KEY.priv"

    ノート:

    EDGが(共有ストレージ上で) Oracleホームとして使用する物理的な場所は2つのみなので、3つ以上のノードがある場合は、最初の2つからの/u01/oracle/productsのコピーをスケジュールすれば十分です。

これで、管理サーバーのドメイン・ディレクトリと管理対象サーバーのドメイン・ディレクトリを毎日午前0時にプライマリからプルする(午前2時にセカンダリ・ノードにプッシュする)スケジュールと、OracleホームとJDKのインストールを毎週コピーするスケジュールが作成されました。RTO、RPOおよび変更規模のニーズに応じて頻度を調整してください。同様に、OHSノードにcronジョブを作成します(これまでの項で説明したように、OHS構成の変更頻度はWebLogicドメインより大幅に低くなるため、コピーの頻度が低くなるように調整しても構いません)。

すべてのケースで(ピアツーピア・モデルとステージング・モデルのどちらを使用する場合でも)、システムのcronログを定期的にチェックします。次に例を示します。

grep rsync /var/log/cron

https://github.com/oracle-samples/maa/tree/main/1412EDGで提供されているスクリプトを使用している場合は、cronジョブによって報告されるlogsディレクトリをチェックして、各定期コピーの結果を確認することもできます。

cronジョブの適切な実行に加えて、定期コピーがスケジュールされている場合は、セカンダリを定期的にテストおよび検証することをお薦めします。


sudo grep rsync /var/log/cron | grep log
May 6 00:00:02 bastion-vcnpho80 CROND[497562]: (root) CMDOUT ((You can check rsync command and exclude list in /home/oracle/maa/1412EDG/logs/rsync_u02_oracle_products__06-06-2025-00-00-02.log))
May 6 00:00:02 bastion-vcnpho80 CROND[497563]: (root) CMDOUT ((You can check rsync command and exclude list in /home/oracle/maa/1412EDG/logs/rsync_u02_oracle_config__06-06-2025-00-00-02.log))
May 6 00:00:02 bastion-vcnpho80 CROND[497564]: (root) CMDOUT ((You can check rsync command and exclude list in /home/oracle/maa/1412EDG/logs/rsync_u02_oracle_config__06-06-2025-00-00-02.log))
May 6 00:00:02 bastion-vcnpho80 CROND[497565]: (root) CMDOUT ((You can check rsync command and exclude list in /home/oracle/maa/1412EDG/logs/rsync_u02_oracle_config__06-06-2025-00-00-02.log))
May 6 00:00:02 bastion-vcnpho80 CROND[497566]: (root) CMDOUT ((You can check rsync command and exclude list in /home/oracle/maa/1412EDG/logs/rsync_u02_oracle_config__06-06-2025-00-00-02.log))
May 6 00:00:02 bastion-vcnpho80 CROND[497561]: (root) CMDOUT ((You can check rsync command and exclude list in /home/oracle/maa/1412EDG/logs/rsync_u02_oracle_products__06-06-2025-00-00-02.log))
May 6 00:00:02 bastion-vcnpho80 CROND[497567]: (root) CMDOUT ((You can check rsync command and exclude list in /home/oracle/maa/1412EDG/logs/rsync_u01_oracle_config__06-06-2025-00-00-02.log))

アプリケーション層での望まない上書き(セカンダリがアクティブ・サイトの場合に、誤ってプライマリからセカンダリに構成を同期させるなど)を回避するには、レプリケーションの方向(構成、バイナリおよびランタイムを元のプライマリからセカンダリにコピーするのか、逆の方向にコピーするのか)を各サイトでのデータベース・ロールに基づいて決定することをお薦めします。Web層の構成の変更頻度は、アプリケーション層の構成の変更頻度より低くなります。また、Web層からデータベースへのアクセスを提供する場合は、アプリケーション層からの場合よりも注意が必要になります。したがって、アプリケーション層のrsyncスクリプトにロジックを追加し、データベースで検出されたロールに基づいてコピーの方向を決定することをお薦めします。ローカル・データベースがPHYSICAL STANDBYまたはSNAPTHOT STANDBYロールの場合、スクリプトはリモート・ピアから情報をプルする必要があり、PRIMARY ROLEの場合は、そのリモート・ピアに情報をプッシュする必要があります。このロジックを実装する例については、https://github.com/oracle-samples/maa/tree/main/app_dr_commonにあるスクリプトを参照してください。

Oracle Fusion Middlewareディザスタ・リカバリ・サイトへのパッチの適用

適切なディザスタ・リカバリ戦略は、Oracle Fusion Middlewareパッチを適用して、Oracle Fusion Middlewareディザスタ・リカバリ・サイトに含まれるOracleホームをアップグレードする方法に対応している必要があります。

プライマリ・システムでパッチを適用するOracle Fusion MiddlewareインスタンスのOracle中央インベントリが、本番サイトの共有ストレージまたはrsyncの対象となる場所に配置されていて、パッチが適用されたインスタンスのOracle中央インベントリをセカンダリ・サイトにレプリケートできるようになっている必要があります。

Oracle Fusion Middlewareパッチを適用するには、次のステップを実行します。

  1. 開始時の状態が保持されるように、本番サイトのバックアップを実行します。
  2. パッチ・セットを適用して、本番サイトのインスタンスをアップグレードします。
  3. パッチ・セットを適用した後、本番サイトの共有ストレージとセカンダリ・サイトの共有ストレージを手動で強制的に同期させます。これによって、本番サイトのパッチが適用されたインスタンスとOracle中央インベントリがセカンダリ・サイトの共有ストレージにレプリケートされます。
  4. パッチ・セットを適用した後、セカンダリ・データベースが(スナップショット・スタンバイではなく)フィジカル・スタンバイであることを確認し、Oracle Data GuardによってOracleプライマリ・データベースとセカンダリ・データベースが同期されるようにします。リポジトリを更新するOracle Fusion Middlewareパッチ・セットがいくつかある場合は、このステップを必ず実行して、本番サイトのデータベースの変更をセカンダリ・サイトのデータベースに同期させます。
    これでアップグレードは完了です。ディザスタ・リカバリ・トポロジで処理を再開できます。

ノート:

パッチは、Oracle Fusion Middlewareディザスタ・リカバリ・トポロジの本番サイトでのみ適用する必要があります。Oracle Fusion MiddlewareインスタンスまたはOracle中央インベントリのパッチの場合、本番サイトの共有ストレージがセカンダリ・サイトの共有ストレージにレプリケートされるときに、パッチがコピーされます。本番サイトでパッチをインストールした場合は、同期操作を実行する必要があります。

データベースにパッチを適用する場合は、Data Guardトポロジでパッチを適用する方法について、その特定のパッチのドキュメントを確認してください。

ディザスタ・リカバリ・トポロジを使用すると、(場合によっては)プライマリ・システムにおけるパッチ適用のための停止時間を短縮できます。パッチの影響を受けるコンポーネントによって違いがあります。

  • データベース・パッチ

    Oracle Fusion Middlewareディザスタ・リカバリでは、Data Guardが使用されます。プライマリDBシステムのみを持つかわりにData Guardを使用する利点は、まず一方のサイトにパッチを適用してから、もう一方のサイトにパッチを適用できることです。ただし、すべてのデータベース・パッチでこの方法を利用できるわけではありません。データベースにパッチを適用する際の停止時間と手順は、パッチのタイプによって異なります。データベース・パッチには次のタイプがあります。

    • Data Guard Standby-First

      これらは、まずスタンバイで適用してから、プライマリで適用できます。このタイプのパッチを適用する際には、様々なオプションを利用できます。Oracle Patchの保証 - Data Guard Standby-First Patch適用(ドキュメントID 1265700.1)を参照してください。

    • Data Guard Standby-First以外

      この種のパッチは、プライマリ・データベースとスタンバイ・データベースの両方で同時に適用する必要があり、停止を必要とします。

      データベース・パッチがStandby-Firstの場合、停止時間を最小限に抑えるか、スイッチオーバーまで減らすことができます。そうでない場合は、プライマリとスタンバイを停止して、両方で適用する必要があります。

  • 中間層のみのパッチ(中間層のバイナリのみを変更するパッチ)

    • いくつかのFusion Middlewareパッチは、readmeでFMW_ROLLING_ORACLE_HOMEとしてマークされています。このタイプのパッチの場合、ディザスタ・リカバリの使用の有無にかかわらず、停止時間は発生しません。

    • その他のパッチはFMW_ROLLING_ORACLE_HOMEが有効になっておらず、中間層を停止する必要があります。このような場合、ディザスタ・リカバリ・トポロジを使用すると、次の手順に従って停止時間を最小限に抑えることができます。

      1. セカンダリ・データベースをスナップショット・スタンバイに変換します。

      2. まず、セカンダリ中間層ドメインにパッチを適用します。

      3. パッチを適用したセカンダリ・ドメインをテストします。

      4. セカンダリですべてが検証されたら、セカンダリ・データベースをフィジカル・スタンバイに戻します。

      5. セカンダリにスイッチオーバーします(この時点でセカンダリ・リージョンがプライマリになり、業務が実行されます)。

      6. 古いプライマリ・データベースをスナップショットに変換します。

      7. 古いプライマリ中間層にパッチを適用し、テストします。

      8. データベースをフィジカル・スタンバイに戻します。

      9. 元のサイトにスイッチバックします。

        このような場合、停止時間はスイッチオーバー操作に費やされた時間のみです。スタンバイ・システムがない場合、停止時間にはパッチ適用にかかった時間とシステムの停止および起動にかかった時間が含まれます。

  • DBスキーマの変更を含む中間層パッチ

    FMW_ROLLING_ORACLE_HOMEが有効になっていないパッチの場合、データベースの変更が失われないようにする方法は少し異なります(DBスキーマを変更するには、中間層とDBに同時にパッチを適用する必要があります)。次のステップを実行します。

    1. セカンダリ・データベースをスナップショット・スタンバイに変換します。

    2. まず、セカンダリ中間層ドメインにパッチを適用します。

    3. パッチを適用したセカンダリ・ドメインをテストします。

    4. セカンダリですべてが検証されたら、セカンダリ・データベースをフィジカル・スタンバイに戻します。この時点で、セカンダリWebLogicドメインの整合性が取れていません。中間層のバージョンよりスキーマのバージョンの方が古くなっています。

    5. プライマリにパッチを適用します

      この方法での停止時間はセカンダリがない場合と同じですが、前述の手順には、プライマリでパッチを適用する前にセカンダリでパッチの動作を確認できるという利点があります。

Fusion Middlewareディザスタ・リカバリ・システムでのスケール操作

<<このセクション/トピックの入力待ち>>