1. Oracle WebLogic Serverのための継続的可用性
  2. アクティブ/アクティブ・ストレッチ・クラスタ・トポロジの設計に関する考慮事項

6 アクティブ/アクティブ・ストレッチ・クラスタ・トポロジの設計に関する考慮事項

アクティブ/アクティブ・ストレッチ・クラスタ・トポロジでは、クラスタ・ノードは地理的に近い範囲内のデータ・センターを拡張でき、通常はサイト間の比較的に低遅延のネットワーキングが保証されています。

「一般設計に関する考慮事項および継続的可用性」に説明されているように、すべてのOracle WebLogic Server継続的可用性MAAアーキテクチャに対してお薦めする一般的なベスト・プラクティスに加えて、次の項では、「アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタ」に示されたMAAアーキテクチャに適用される設計に関する考慮事項および障害シナリオについて説明します。

アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタの設計に関する考慮事項

アクティブ/パッシブ・データベース層とともに動作するアクティブ/アクティブ・ストレッチ・クラスタ・トポロジでの継続的可用性のためには、Oracleのベスト・プラクティスを考慮してください。

アクティブ/アクティブ・ストレッチ・クラスタで継続的可用性の機能を最大限に利用するには、次を考慮してください。

  • マルチデータ・センターでは、アクティブ/アクティブ・ストレッチ・クラスタ環境のデータ・センター間のセッション・レプリケーションによってシステムで重大なパフォーマンス低下が引き起こされる可能性があります。異なる2つのレプリケーション・グループ(各サイトに1つ)を定義して、2つのサイト間で発生するレプリケーションの可能性を最小限にすることをお薦めします。

    ノート:

    レプリケーション・グループの使用は、同一サイト内のサーバーのみに状態をレプリケートするために最良の方法ですが、決定的な方法ではありません。1つのサーバーが一方のサイトで使用でき、その他のサーバーはもう一方のサイトで使用できる場合、MANの間でレプリケーションが発生し、そのセッションの間はサーバーが同じサイトで元のようにオンラインになっても継続します。

  • アクティブ/アクティブ型ストレッチ・クラスタはメトロ遅延モデルでのみ機能します。遅延は10ミリ秒のラウンド・トリップ時間(RTT)以下にする必要があります。

  • 競合およびセキュリティの理由で、サイト間の共有ストレージの使用はお薦めしません。

  • 各サイトは個別の共有ストレージを使用します。これを使用してランタイム・データを格納する場合、サイト1からサイト2(およびその逆)へのディスク・ミラーリングおよびレプリケーションを使用して、各サイトのこれらのアーティファクトのリカバリ可能なコピーを提供できます。

  • JMSログおよびトランザクション・ログ(TLog)をデータベース・ベースのストアに格納することをお薦めします。これにより、JMSおよびJTAサービスのクロスサイト・サービス移行が可能になります。これは、クラスタ内のすべてのサーバーに対してTLogおよびJMSメッセージがデータベースで使用できるためです。また、完全なサイト・スイッチオーバーの場合、TlogおよびJMSメッセージは、基礎となるData Guardレプリケーションを使用して他のサイトに自動的にレプリケートされます。

  • 両方のサイトが、2つのサイトのいずれかにある単一の管理サーバーで管理されます。一意のWebLogic Server管理コンソールが、両方のサイトで稼働しているサーバーを構成およびモニターするために使用されます。WebLogic Serverのインフラストラクチャは、ドメインで使用されているすべての異なるドメイン・ディレクトリに構成の変更をコピーする責任があります。

  • 管理サーバー障害の場合、単一データ・センター・トポロジでの管理サーバー障害に適用される同じ考慮事項がマルチデータ・センターのアクティブ/アクティブ・ストレッチ・クラスタ・トポロジにも適用されます。高可用性ガイドの管理サーバーのフェイルオーバーまたはフェイルバックに説明されている標準のフェイルオーバー・プロシージャを使用してノード障害に対処します(管理サーバー・ドメイン・ディレクトリをホストしていた共有ストレージを指す同じデータ・センターにある別のノードで管理サーバーを再起動します)。また、適切なバックアップおよびリストア・プロシージャをデプロイして管理サーバーのドメイン・ディレクトリを定期的にコピーします。管理サーバーをホストしているサイト(ノードを含む)に影響を及ぼす障害がある場合、異なるサイトでサーバーを再起動する必要があります。そのためには、既存のストレージ・レプリケーション・テクノロジを使用して、フェルオーバー・サイトで使用可能な管理サーバーのドメイン・ディレクトリをコピーする必要があります。フェイルオーバー・サイトのサーバー/ディレクトリを(ドメインおよびアプリケーション・ディレクトリの両方を含めて)、元のサイトとまったく同一のドメイン・ディレクトリ構造が管理サーバーのドメイン・ディレクトリに対して作成されるようにリストアします。管理サーバーがリストアされるノードでノード・マネージャを再起動します。

    同様に、管理サーバーは異なるサブネットにフェイルオーバーされ、その他のノードによりアクセス可能な異なるIP (VIP)の使用が必要になります。このサブネットのホスト名解決システムに適切な変更を加えて、このVIPが管理サーバーがサイト1でリスニング・アドレスとして使用した元の仮想ホスト名にマップするようにします。たとえば、サイト1でADMINHOSTVHN1が10.10.10.1にマップし、一方、サイト2でローカルの/etc/hostsまたはDNSサーバーのいずれかをADMINHOSTVHN1が20.20.20.1にマップされるように更新する必要があります。すべてのサーバーがADMINHOSTVHN1を管理サーバーにアクセスするアドレスとして使用します。管理サーバーがOracle HTTP ServerおよびLBRのフロント・エンドの場合、クライアントはこの変更に依存しません。クライアントが管理サーバーのリスニング・ホスト名に直接アクセスする場合、DNS解決でも更新する必要があります。

    また、管理サーバーに対してホスト名検証が有効になっている場合、適切な信頼ストアとキー・ストアも新規証明書で更新する必要があります。『Oracle Fusion Middleware Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』の手順を使用します。

    Oracle WebLogic Server管理コンソールとOracle Enterprise Manager Fusion Middleware Controlの両方にアクセスして、管理サーバーが正常に機能していることを確認します。

  • 管理サーバーに対してリモートのサーバーは、配置されているサーバーよりも再起動が長くかかります。その理由は、管理サーバーとのすべての通信(起動時にドメイン構成を取得するためのもの)および最初の通信プール作成およびデータベース・アクセスがサイト間の遅延の影響を受けるためです。高可用性ガイドの管理サーバーの高可用性トポロジを参照してください。

  • サイト間でのサーバーまたはサービスの自動移行は、データベースがJMSおよびTLogの永続性のために使用されていないかぎりお薦めしません。それ以外の場合は、適切な永続ストアの一定のレプリカをサイト間で設定する必要があります。

  • サーバーの移行ではなく、サービスの移行を使用することをお薦めします。サーバーの移行では仮想IPが使用されますが、ほとんどのシナリオでは、一方のサイトで使用されている仮想IPは、もう一方のサイトへの移行には無効です。最初にサイト1で使用可能なリスニング・アドレスをサイト2で(あるいはその逆で)有効にするためには、追加の操作が必要です。この操作は移行前スクリプトで自動化できますが、(単一データ・センターの範囲内で発生する)標準の自動化サーバー移行と比較するとRTOは増加します。比較すると、サービスの移行は仮想IPを必要とせず、RTOはサーバーの移行よりもはるかに優れています。

  • サイト間のJMSおよびトランザクション・リカバリは、WebLogic Serverストレッチ・クラスタ内部のサービスまたはサーバーの移行を使用して処理されます。一般設計に関する考慮事項: WebLogic Serverの項で説明したように、サーバーの移行ではなく、サービスの移行を使用することをお薦めします。JMSまたはJTAのサーバーまたはサービス移行の場合、高可用性データベース上でリースしているデータベースの使用をお薦めします。コンセンサス非データベース・リースで構成されている場合、ストレッチ・クラスタ内のサーバーがリブートに失敗し、環境でネットワークの分断障害が発生したときにドメイン全体の再起動が必要になる可能性があります。

  • アクティブ/アクティブ・ストレッチ・クラスタ・トポロジでのゼロ・ダウンタイム・パッチ適用では、ストレッチ・クラスタ内のすべてのサーバーに対する更新が両方のサイト間で編成されます。ゼロ・ダウンタイム・パッチ適用を参照してください。

  • アクティブ/アクティブ・ストレッチ・クラスタ・トポロジでは、2つのサイト間でWebLogic Serverクラスタのみを拡張します。Coherenceでは、2つのアクティブなサイト間でデータをレプリケートするためにフェデレーテッド・キャッシュを使用して各サイトにCoherenceクラスタを持つ必要があります。Coherenceクラスタがサイト間で拡張されると、スプリット・ブレインの影響を受けやすくなります。

  • Oracle Site Guardはアクティブ/パッシブ・トポロジまたはコンポーネントでのみ機能しますアクティブ/アクティブ・ストレッチ・クラスタ・トポロジでは、Oracle Site Guardはデータベースのフェイルオーバー/スイッチオーバーのみを実行できます。

  • 表6-1は、ストレッチ・クラスタ・トポロジでのデータベース・リースに構成するお薦めの設定のリストを示しています。Oracle WebLogic Server MBeanリファレンスのMBeanに関する次の説明を参照してください。

    表6-1 ストレッチ・クラスタでのデータベース・リースにお薦めする設定

    構成プロパティ MBean/コマンド 説明 お薦めする設定

    DatabaseLeasingBasisConnectionRetryCount

    ClusterMBean

    データベース・リースがデータソースから有効な接続を取得するための最大試行回数。

    5 (デフォルト値は1)

    DatabaseLeasingBasisConnectionRetryDelay

    ClusterMBean

    接続が失敗したときに、データベース・リースがデータソースから新規接続の取得を試行する前に待機する時間の長さ(ミリ秒)。

    2000 (デフォルト値は1000)

    TestConnectionOnReserve

    JDBCConnectionPoolParamsBean

    接続をクライアントに渡す前にWebLogic Serverでテストできるようにします。

    有効。データソースのリース用。サーバーはスイッチオーバー中は稼働状態のままです。

    -Dweblogic.cluster.jta.SingletonMasterRetryCount

    サーバーの起動コマンド

    シングルトン・マスターが選択されてそのリスニング・ポートをオープンするための試行カウントを指定します。シングルトン・マスターは、JTAを非アクティブ化する最初の試行時にすぐに使用可能にならない場合があります。

    4 (デフォルト値は20)

    DatabaseLeasingBasisConnectionRetryCountが5に設定されているため、このプロパティは4に減らせます。この設定はデータベース・サーバーのブート中の時間コストを減らせます。

  • 図6-1および図6-2は、ベンチマーク・テスト中に見つかった、異なる遅延に対するシステム全体のスループット(両方のサイトは一緒に稼働しています)で見られる低下を示す結果を表しています。図6-1は、約20ミリ秒のラウンド・トリップ時間(RTT)の遅延中にスループットが25%程度低下することを示しています。図6-2は、SOAアクティブ/アクティブ・ストレッチ・クラスタ内のサイト間の遅延(ミリ秒単位のRTT)の増加とともにSOAコンポジットをデプロイするために消費される追加時間(ミリ秒単位) (同じサイトのすべてのサーバーおよびデータベースのデプロイメントと比較した場合)を示しています。

    多くのテストで見られる提供データとパフォーマンスのペナルティを考慮して、アクティブ/アクティブ・ストレッチ・クラスタ・トポロジで遅延が2つのサイト間の通信に影響を及ぼす場合は10ミリ秒の遅延(RTT)を超えないことをお薦めします。

    図6-1 ストレッチ・クラスタにおける遅延によるスループット低下

    図6-1の説明が続きます
    「図6-1 ストレッチ・クラスタにおける遅延によるスループット低下」の説明

    図6-2 デプロイメントの遅れ対ストレッチ・クラスタにおける遅延

    図6-2の説明が続きます
    「図6-2 デプロイメントの遅れ対ストレッチ・クラスタにおける遅延」の説明

アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタの障害シナリオ

アクティブ/アクティブ・ストレッチ・クラスタ・トポロジに対する異なる障害シナリオのそれぞれで継続的可用性の機能がどのように使用されているかについて学習します。

表6-2 では、様々な障害シナリオを説明し、継続可用性機能がどのように適用されるかを説明します。様々な障害シナリオの説明については、「潜在的な障害シナリオ」を参照してください。

表6-2 アクティブ/アクティブ・ストレッチ・クラスタおよびアクティブ/パッシブ・データベース層の障害シナリオ

継続的可用性の機能 完全サイト障害 部分サイト/中間層障害(WebLogic Server/Coherence/OTD) メンテナンス機能停止 ネットワークの分断障害

サイト間のトランザクション・リカバリ

Oracle Site GuardがOracle Data Guardブローカと統合されてデータベースのフェイルオーバー/スイッチオーバーを実行します。Site GuardがOracle Data Guardブローカを呼び出してフェイルオーバーを実行し、Site Guardがロールをプライマリからセカンダリに切り替えます。

JMSおよびTlogの永続ストアは、サイト2のデータベースにレプリケートされます。

サーバーおよびサービスをWebLogic Serverのサーバーおよびサービスの移行の機能を使用して移行します。サービスの移行を使用することをお薦めします。

トランザクションが発生してストレッチ・クラスタで使用可能なサーバーにリカバリできるようになるか、サーバー移行が発生してトランザクションが移行済サーバーにリカバリされます。

サービスの移行を使用することをお薦めします。

サイト1のアプリケーション・インフラストラクチャは、停止する前にサーバーが作業を完了できるように段階的に停止されます。

Oracle Site GuardがOracle Data Guardと統合されてデータベースおよびアプリケーション・インフラストラクチャのスイッチオーバーを編成します。

JMSおよびTlogの永続ストアは、サイト2のデータベースにレプリケートされます。

トランザクションが発生してストレッチ・クラスタで使用可能なサーバーにリカバリできるようになるか、サーバー移行が発生してトランザクションが移行済サーバーにリカバリされます。サービスの移行を使用することをお薦めします。

データベースとともに配置されたサイトはトランザクションの処理を続行します。データベースに対してリモートのサイトは接続例外およびトランザクション障害を取得します。

サイト2はデータベースと通信できないためトランザクションは失敗します。

イントラ・サーバーのトランザクション分断がある場合、トランザクションが失敗してトランザクションの状態に応じてロールバックするかコミットを再試行します。通信が再開すると、トランザクションが最終的にコミット/ロールバックします。

Oracle Traffic Director

サイト2のOracle Traffic Directorは、そのサイト上のサーバーへのトラフィックのルーティングを続行します。

サイト2のOracle Traffic Directorは、そのサイト上のサーバーへのトラフィックのルーティングを続行します。

サイト1上のOracle Traffic Directorは停止します。

サイト2のOracle Traffic Directorは、そのサイト上のサーバーへのトラフィックのルーティングを続行します。

サイト1およびサイト2の両方のOracle Traffic Directorは、それぞれのサイト上のサーバーへのトラフィックのルーティングを続行します。

Oracle Site Guard

Oracle Site Guardはデータベースのフェイルオーバーを編成します

何もしません。

Oracle Site Guardはデータベースのスイッチオーバーを編成します

何もしません。

ゼロ・ダウンタイム・パッチ適用

動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールバックが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。

動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールアウトが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。

動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールバックが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。

動作はZDTロールバックの設定に依存します。ロールバックが有効になっている場合は、ワークフローがロールバックされます。ロールバックが有効になっていない場合は、ZDTロールアウトが停止してエンド・ユーザーからの手動操作を待機します。

Coherenceフェデレーテッド・キャッシュ

レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。

レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。

レプリケーションは非同期のため、キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはもう一方のサイトが稼働状態に戻ったときに整合します。

キャッシュ・データは最終的にCoherence Hot CacheまたはRead-Through Cacheのいずれかを介して、あるいはネットワーク接続が2つのサイト間で再確立されたときに整合します。