1. Oracle SOA SuiteのハイブリッドDRソリューションの構成
  2. ライフサイクル・タスク

ライフサイクル・タスク

セカンダリ・サイトとプライマリ・サイトの同期を維持するには、通常のライフサイクル・メンテナンスが必要です。ライフサイクル全体を通して、計画されたスイッチオーバーを実行して、プライマリ・サイトとセカンダリ・サイトの役割を切り替え、予期しない操作または計画外の操作に対応できる必要があります。

構成レプリケーションについて

ファイルシステムに常駐するコンテンツの初期レプリケーションは、DR設定中に実行されました。セカンダリ・サイトをプライマリ・サイトで最新の状態に保つには、ファイル・システムのレプリケーションを定期的に繰り返す必要があります。

DR設定中に作成したものと同じスクリプト「ファイル・システム・アーティファクトをOCIにレプリケート」を使用し、アーティファクトごとに次の考慮事項でファイル・システムのレプリカをスケジュールできます。

  • ライフサイクル中のOracleホームのレプリケーション

    これは静的アーティファクトです。頻繁に変更されないため、定期的にレプリケートする必要はありません。Oracle Homeで変更(パッチ適用アクティビティなど)を実行する場合にのみ、レプリケートする必要があります。

  • ライフサイクル中のWebLogicドメイン共有構成のレプリケーション

    これは動的アーティファクトです。特に、ASERVER_HOME (SOAドメイン構成のソース)と、アプリケーションがデプロイ、アンデプロイ、更新されるたびに更新されるAPPLICATION_HOMEが含まれます。

    このWebLogicドメインの共有構成は頻繁に変更されることが予想されます。このアーティファクトの通常のレプリカをスケジュールします。これは、システムで構成変更が発生する頻度に応じて増減します。もう1つの制御されたアプローチは、プライマリへの構成変更を実行するたびにレプリカを実行することです。

  • ライフサイクル中のWebLogicドメイン・プライベート構成のレプリケーション

    これは動的アーティファクトでもあり、MSERVER_HOMEおよびNM_HOMEが含まれます。初期設定後にnodemanagerホームで頻繁に更新されることは想定されていません。MSERVER_HOMEのコンテンツは、管理対象サーバーで使用されるドメイン・フォルダを含むため、ASERVER_HOMEと同じ頻度で変更されます。ただし、そのコンテンツのほとんど(ASERVER_HOME/config)は、管理対象サーバーの起動時、およびWebLogic Scripting Tool (WLST)またはOracle WebLogic Server管理コンソールを使用して構成変更が適用されたときに、AdminServerからリフレッシュおよびダウンロードされます。このアーティファクトを共有構成と同じ頻度でレプリケートすることは重要ではありません。これは、MSERVER_HOME内の他のフォルダ(MSERVER_HOME/binフォルダの変更など)に変更が実行される場合のみ、複製する必要があります。

  • 共有ランタイム・フォルダのレプリケーション

    このフォルダにランタイム・アーティファクトを格納する場合は、ビジネス・ニーズに応じてレプリカをスタンバイにスケジュールします。

    Oracle Cloud Infrastructure File Storageファイル・システムを使用してrsyncでレプリケートするかわりに、共有ランタイム・コンテンツにOracle Database File System (DBFS)マウントを使用できます。このように、コンテンツはデータベースに存在し、基礎となるOracle Data Guardレプリカを使用してセカンダリに自動的にレプリケートされます。DBFSの使用の詳細は、学習のOracle Databaseファイル・システムについてを参照してください。

次の表に、ライフサイクル中のファイル・システム・アーティファクトのレプリケーションに関する推奨事項のサマリーを示します。

アーティファクト 含む 推奨
Oracleホーム FMWホーム、JDK、インベントリ オンデマンドでのみ複製(パッチ適用後など)
WebLogicドメイン共有構成 ASERVER_HOME、アプリケーション、デプロイメント・プラン、キーストア レプリケーションをスケジュールします。高い頻度が必要な場合があります。頻度は、構成変更がSOAシステムに対して実行される頻度によって異なります。
WebLogicドメイン・プライベート構成 MSERVER_HOMES、nodemanager config レプリケーションをスケジュールします。通常、高い頻度は必要ありません。
共有ランタイム 顧客固有のランタイム・アーティファクト(TLOGSではなくJMS) 要件によって決定されます。DBFSマウントの場合、コンテンツはOracle Data Guardによって自動的にレプリケートされます。

スイッチオーバーの実行

スイッチオーバーは、管理者が2つのサイトのロールを元に戻す計画操作です。スイッチオーバー後、プライマリ・システムはセカンダリになり、セカンダリ・システムはプライマリになります。スイッチオーバーを実行すると、プライマリ・サイトで停止時間が発生します。
SOAハイブリッドDR構成でスイッチオーバーを実行する前に、保留中の構成変更を伝播します。保留中のセカンダリ・サイトへのレプリケートされた変更がないことを確認します。
  1. スイッチオーバーの実行中にスケジュールされたレプリケーションを無効にします。これは、フェイルオーバーが発生し、スイッチオーバー操作自体が妨げられる可能性があるためです。
  2. プライマリ・サイトでOracle HTTP Serverシステムを停止します。
  3. プライマリ・サイトのサーバーを停止します。
    WebLogic管理サーバー・コンソールまたはスクリプトを使用して、プライマリ・サイトのWebLogicサーバーを停止します。

    ノート:

    プライマリ・サイトの管理サーバーは、スイッチオーバー中に稼働状態を維持できます。ただし、サイトがスタンバイ・ロールの場合は、ライフサイクル中にスタンバイ・サイトのドメイン構成がプライマリ構成によってオーバーライドされることが予期されるため、このサイトを停止することをお薦めします。これが発生したときに管理サーバーが稼働している場合は、古い構成で実行されます。
  4. フロントエンドDNS名をスイッチオーバーします。

    システムで使用される名前をホストしているDNSサーバーで必要なDNSプッシュを実行するか、クライアントのファイル・ホスト解決を変更して、システムのフロントエンド仮想名をセカンダリ・サイトのロード・バランサによって使用されるパブリックIPにポイントします。

    DNSが外部フロント・エンド解決(OCI DNSや商用DNSなど)に使用されるシナリオでは、APIを使用して変更をプッシュできます。この変更をOCI DNSでプッシュする例を確認するには、GitHub (スクリプトの例)に移動します。

    DNSエントリのTTL値はスイッチオーバーのRTOに影響を与えます。たとえば、TTLが高い場合(たとえば、20分)、DNSの変更はクライアント内で有効になるまでにかかることに注意してください。低いTTL値を使用すると、より高速になりますが、キャッシュ名を使用する代わりにクライアントが DNSに頻繁にアクセスするため、オーバーヘッドが発生する可能性があります。DNSを変更する前に、TTLを一時的に低い値(1分など)に設定することをお薦めします。次に、変更を実行し、スイッチオーバー手順が完了したら、TTLを元の値に戻します。

  5. oracleユーザーとして、プライマリ・データベース・ホストでOracle Data Guardブローカを使用してデータベースのスイッチオーバーを実行します。
    システム・パスワードとプライマリ・データベースの一意の名前が必要です。
    [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
  6. まだ起動していない場合は、セカンダリ・サイト(新しいプライマリ)でOracle HTTP Serverシステムを起動します。
  7. セカンダリ・サイト(新しいプライマリ)で管理サーバーを起動するか、すでに起動されている場合はサーバーを再起動します。
    管理サーバーを起動すると、これがスタンバイだった間に複製された構成の変更が有効になります。
  8. セカンダリ・サイトでセカンダリ管理対象サーバーを起動します(新しいプライマリ)。
    WebLogicコンソールまたはスクリプトを使用して、セカンダリ管理対象サーバーを起動します。

フェイルオーバーの実行

フェイルオーバー操作は、通常、プライマリ・サイトが使用できなくなったときに実行される計画外の操作です。スタンバイ・データベースをプライマリ・データベース・ロールにロール移行できるのは、元のプライマリ・データベースで障害が発生し、適切なタイミングでリカバリできない場合です。プライマリ・データベースに障害が発生したときにプライマリ・データベースとターゲット・スタンバイ・データベースが一致していたかどうかによって、データが失われる場合があります。
  1. 可能な場合は、保留中の構成変更を伝播します。
    セカンダリ・サイトに変更をレプリケートするには、ファイル・システム・アーティファクトをOCIにレプリケートを参照してください。
  2. スイッチオーバーの実行中にスケジュールされたレプリケーションを無効にします。これは、フェイルオーバーが発生し、スイッチオーバー操作自体が妨げられる可能性があるためです。
  3. プライマリ・サイトでOracle HTTP Serverシステムを停止します。
  4. 可能であれば、プライマリ・サイトの管理対象サーバーを停止します。

    WebLogic管理サーバー・コンソールまたはスクリプトを使用して、プライマリの管理対象サーバーを停止します。

  5. フロントエンドDNS名をスイッチオーバーします。

    システムで使用される名前をホストしているDNSサーバーで必要なDNSプッシュを実行するか、クライアントのファイル・ホスト解決を変更して、システムのフロントエンド仮想名をセカンダリ・サイトのロード・バランサによって使用されるパブリックIPにポイントします。

    DNSが外部フロント・エンド解決(OCI DNS、商用DNSなど)に使用されるシナリオでは、適切なAPIを使用して変更をプッシュします。この変更をOCI DNSでプッシュする例を確認するには、こちらを参照してください。

    ノート:

    DNSエントリのTTL値は、スイッチオーバーのRTOに影響を与えます。TTLが高い場合(たとえば、20分)、DNSの変更では、その時間がクライアントで有効になります。低いTTL値を使用するとこの処理が速くなりますが、キャッシュ名を使用する代わりにクライアントが DNSにより頻繁にヒットするため、オーバーヘッドが発生する可能性があります。DNSを変更する前に、TTLを一時的に低い値(1分など)に設定することをお薦めします。次に、変更を実行し、スイッチオーバー手順が完了したら、TTLを元の値に戻します。
  6. oracleユーザーとして、セカンダリ・データベース・ホストのOracle Data Guardブローカを使用してフェイルオーバーを実行します。
    システム・パスワードとプライマリ・データベースの一意の名前が必要です。
    [oracle@hydrdb1 ~]$ dgmgrl sys/your_sys_password@secondary_db_unqname
DGMGRL> failover to secondary_db_unqname
  7. まだ起動していない場合は、セカンダリ・サイト(新しいプライマリ)でOracle HTTP Serverシステムを起動します。
  8. セカンダリ・サイト(新しいプライマリ)で管理サーバーを起動するか、すでに起動されている場合はサーバーを再起動します。
    管理サーバーを起動すると、これがスタンバイだった間に複製された構成の変更が有効になります。
  9. セカンダリ・サイトでセカンダリ管理対象サーバーを起動します(新しいプライマリ)。
    WebLogicコンソールまたはスクリプトを使用して、セカンダリ管理対象サーバーを起動します。

検証用のセカンダリのオープン

スタンバイ・データベースをスナップショット・スタンバイに変換することで、完全なスイッチオーバーを実行せずにスタンバイ・サイトを検証できます。これにより、セカンダリSOAサーバーをスタンバイ・サイトで起動し、セカンダリ・システムを検証できます。スナップショット・スタンバイ・モード中にスタンバイ・サイト・データベースで実行された変更は、再度物理スタンバイに変換されると破棄されます。プライマリ・データはセカンダリ・サイト検証の影響を受けません。

ノート:

この操作は注意して実行する必要があります: スナップショットに変換された時点でデータベースに保留中のメッセージまたはコンポジットがある場合、スタンバイ・サイトのSOAサーバーは起動時にそれらを処理します。スナップショット・スタンバイへの変換時に、プライマリ・データベースに保留中のアクションがないことを確認します。それ以外の場合は、スナップショット・スタンバイ・データベースへの変換後、セカンダリ・サイトのSOAサーバーの起動前に、スタンバイ・データベースのランタイムSOA表からレコードを削除します。スイッチオーバーを実行せずにスタンバイ・サイトを検証するステップは、表削除なしでの実行時表からのレコードの削除を参照してください。
  1. oracleユーザーとして、プライマリ・データベース・ホストでOracle Data Guardブローカを使用して、セカンダリをスナップショット・スタンバイに変換します。
    [oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
    コマンドshow configurationを使用して、変換が正しく実行されたことを確認します。
  2. セカンダリ環境に保留中のアクションがないことを確認します。
    スタンバイがスナップショットに変換されるときにプライマリDBに保留中のアクション(トランザクション、メッセージ)がある場合、セカンダリSOAサーバーは、セカンダリ・サーバーを起動する前に、セカンダリ・データベースのSOAランタイム表からレコードを消去するために、start.YouでSOA切捨てスクリプトを使用してセカンダリ・データベースのSOAランタイム表からレコードを削除できるときに処理を試みます。このアクションは注意して実行してください。プライマリ・データベースの表を切り捨てないでください。表削除なしでの実行時表からのレコードの削除に関する項を参照してください。
  3. まだ起動していない場合は、セカンダリ・サイトでOracle HTTP Serverシステムを起動します。
  4. セカンダリ・サイトで管理サーバーを起動します。
  5. セカンダリ・サイトでセカンダリ管理対象サーバーを起動します。
    WebLogicコンソールまたはスクリプトを使用して、セカンダリ管理対象サーバーを起動します。
  6. セカンダリ・サイトを検証します。

    これはスイッチオーバーではなく、プライマリ・サイトがまだアクティブであるため、仮想フロントエンド名はプライマリ・サイトのロード・バランサIPアドレスに解決されるため、ブラウザ・アクセスはデフォルトでアクティブなプライマリ・サイトにリダイレクトされます。

    セカンダリ・サイトのSOAサービスに直接アクセスするには、制御されたクライアント(ラップトップなど)で/etc/hostsファイルを更新し、仮想フロントエンド名を設定してセカンダリ・サイトのフロントエンド・ロード・バランサのIPアドレスに解決し、このクライアントから検証を実行する必要があります。

    ノート:

    検証に使用されるクライアントがHTTPプロキシを介してシステムにアクセスしないことを確認します。これは、HTTPプロキシがクライアントの/etc/hostsにある名前に関係なく、プライマリ・サイトのロード・バランサIPアドレスを使用して仮想フロントエンド名を解決し続ける可能性があるためです。

    Linux以外のクライアントでは、ブラウザがカスタマイズされたホストファイルエントリを使用してIPアドレスを解決する前に、ローカル DNSキャッシュのリセットが必要になる場合があります。

    セカンダリ・サイトが検証されたら、次のステップに進み、スタンバイ・ロールに戻します。

    ノート:

    セカンダリ・サイトの検証には時間がかかる場合があります。
  7. セカンダリ・サイトで管理対象サーバーおよび管理サーバーを停止します。
    セカンダリ・サイトで管理対象サーバーと管理サーバーを停止するには、セカンダリWebLogicコンソールを使用します。
  8. oracleユーザーとして、プライマリ・データベース・ホストでOracle Data Guardブローカを使用して、セカンダリをフィジカル・スタンバイに再変換します。
    システム・パスワードとプライマリ・データベースの一意の名前が必要です。
    [oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
    show configurationを使用して、変換を確認します。
  9. 更新された/etc/hostsファイルを元に戻します。
    検証のためにセカンダリ・サイトを指すようにクライアント内の/etc/hostsファイルを更新した場合、仮想フロントエンド名がプライマリ・フロントエンドIPアドレスを再度指すように元に戻します。

ノート:

ORA-01403: ORA-06512エラーのデータが見つかりません。

ここで説明するセカンダリ・サイトの検証中(完全なスイッチオーバーを実行しない、つまり、スナップショット・スタンバイ・モードでスタンバイをオープンするのみ)、ORA-01403:スタンバイSOAサーバーのログにORA-06512エラーが表示されない場合があります。これらのエラーは、SOA自動パージ・ジョブに関連しています。データベース内のジョブにdbロールの依存関係がある可能性があるため、これらのエラーが発生します(データベースはプライマリ・ロールの場合にのみ有効にするように定義されています)。これは、ジョブが2回(プライマリとスタンバイで1回)実行されることを防ぐ、予期された望ましい動作です。SOA自動パージ・ジョブはプライマリ・ロールで定義されるため、データベースがスナップショット・スタンバイ・モードの場合はDBA_SCHEDULER_JOBSビューに表示されません。各ジョブに定義されている database_roleは、ビューDBA_SCHEDULER_JOB_ROLEに表示されます。要するに、これらのエラーは、スタンバイシステムに表示されるかぎり無視できます。SOA自動パージのスケジューラ・ジョブは、インスタンスがそのロールをPRIMARYに変更した場合にのみ、データベースで実行されます。

OCI上の管理サーバーのローカル・フェイルオーバー

管理サーバーが最初に実行されていたホストに障害が発生した場合、同じサイトの別のノードで管理サーバーを起動できます。他のサイトへのシステムの完全なスイッチオーバーは必要ありません。

ノート:

このライフサイクル・タスクは、WebLogic管理サーバーでローカルの高可用性のためにVIPを使用し、管理サーバー構成フォルダ(ASERVER_HOME)が共有の場所にある場合にのみ適用できます。

これを行う手順は、「管理サーバーの手動フェイルオーバーの確認」を参照してください。これにより、管理サーバーのローカル・フェイルオーバー保護が提供されます。これは、自動サービス移行機能に基づくローカル高可用性保護を持つ管理対象サーバーには必要ありません。

プライマリがOCIサイトで実行されているときに、管理サーバーの別のホストへのフェイルオーバーを実行する必要がある場合は、その手順に従います。ただし、「ADMINVHN仮想IPアドレスを2番目のホストに移行する」ステップに関連する追加アクションが必要です。

次のステップを実行して、管理サーバーが実行されていたSOAホストからVIPをデタッチし、管理が移動されているSOAホストにそれをアタッチします(VIPをSOAHOST1からデタッチし、OCIサイトのSOAHOST2にアタッチします)。

  1. rootユーザーとして、SOAHOST1で次のコマンドを実行して、ネットワーク・インタフェースから管理サーバーのVIPを削除します。
    1. 管理サーバーが実行されている場合は停止します。
    2. VIPが実行されている場所を確認します。
      ip addr show dev ens3
    3. ネットワーク・インタフェースからIPを削除します。
      ip addr del 100.70.8.120/20 dev ens3
  2. 管理サーバーのVIPをSOAHOST1からデタッチします。
    1. OCIコンソールに接続し、適切なリージョンとコンパートメントを選択します。
    2. コンピュート・インスタンスに移動します。「コンピュート」、「インスタンス」、「SOAHOST」1の順にクリックします。
    3. 「アタッチされたVNIC」をクリックし、管理サーバーVIPがアタッチされているVNICを選択します。
    4. 「IPv4アドレス」をクリックし、管理サーバーが使用するVIPを編集します。
    5. VIPのIPアドレスおよびfqdn名をノートに保存します(たとえば、100.70.8.120、hydrsoa- VIP.midtiersubnet.hydrvcn.oraclevcn.com)。
    6. 「プライベートIPの削除」をクリックします。
  3. 管理サーバーのVIPをSOAHOST2にアタッチします。
    1. コンピュート・インスタンスに移動します。「コンピュート」、「インスタンス」、「SOAHOST」2の順にクリックします。
    2. 「アタッチされたVNIC」をクリックし、管理サーバーVIPがアタッチされているVNICを選択します。
    3. 「セカンダリ・プライベートIPアドレスの割当て」をクリックします。
    4. 「IPv4アドレス」をクリックし、「セカンダリ・プライベートIPアドレスの割当て」をクリックします。
    5. 以前使用されたプライベートIPアドレスおよびホスト名の値を入力します。たとえば、IPの場合は100.70.8.120、ホスト名の場合はhydrsoa-vipです。
  4. rootユーザーとしてSOAHOST2にログインし、次のコマンドを実行して、管理サーバーのVIPをネットワーク・インタフェースに接続します。
    1. ネットワークインタフェースが実行されている場所を確認します。
      ip addr show dev ens3
    2. 管理サーバーのVIPをネットワーク・インタフェースに追加します。
      ip addr add 100.70.8.120/20 dev ens3 label ens3:1
  5. 「管理サーバーの手動フェイルオーバーの確認」の説明に従って、残りのステップを実行します。