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

ライフサイクル・タスク

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

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

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

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

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

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

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

    これは動的アーティファクトです。特に、ASERVER_HOME (WebLogicサーバー・ドメイン構成のソース)と、アプリケーションがデプロイ、アンデプロイ、更新されるたびに更新される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、アプリケーション、デプロイメント・プラン、キーストア レプリケーションをスケジュールします。高い頻度が必要な場合があります。頻度は、構成の変更が WebLogic Serverシステムに対して実行される頻度によって異なります。
WebLogicドメインのプライベート構成 MSERVER_HOMES、nodemanager config レプリケーションをスケジュールします。通常、高い頻度は必要ありません。
共有ランタイム 顧客固有のランタイム・アーティファクト(TLOGSではなくJMS) 要件によって決定されます。DBFSマウントの場合、コンテンツはOracle Data Guardによって自動的にレプリケートされます。

スイッチオーバーの実行

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

    ノート:

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

    システムで使用される名前をホストしているDNSサーバーで必要なDNSプッシュを実行するか、クライアントのファイル・ホスト解決を変更して、システムのフロントエンド仮想名をセカンダリ・サイトのLoad Balancerで使用されるパブリック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プッシュを実行するか、クライアントのファイル・ホスト解決を変更して、システムのフロントエンド仮想名をセカンダリ・サイトのLoad Balancerで使用されるパブリック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コンソールまたはスクリプトを使用して、セカンダリ管理対象サーバーを起動します。

セカンダリを検証用に開く

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

ノート:

この操作は注意して実行する必要があります: スナップショットへの変換時にデータベースに保留中のJMSメッセージがある場合、スタンバイ・サイトのサーバーは起動時にそれらを処理します。スナップショット・スタンバイへの変換時に、プライマリ・データベースに保留中のアクションがないことを確認します。
  1. oracleユーザーとして、プライマリdbホストで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. まだ起動していない場合は、セカンダリ・サイトでOracle HTTP Serverシステムを起動します。
  3. セカンダリ・サイトで管理サーバーを起動します。
  4. セカンダリ・サイトでセカンダリ管理対象サーバーを起動します。
    WebLogicコンソールまたはスクリプトを使用して、セカンダリ管理対象サーバーを起動します。
  5. セカンダリ・サイトを検証します。

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

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

    ノート:

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

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

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

    ノート:

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

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

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

ノート:

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

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

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

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

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