5 アクティブ/パッシブ・データベース層を使用するアクティブ/アクティブ・ストレッチ・クラスタ
アクティブ/アクティブ・ストレッチ・クラスタ・トポロジでは、クラスタ・ノードは地理的に近い範囲内のデータ・センターを拡張でき、通常はサイト間の比較的に低遅延のネットワーキングが保証されています。
内容は次のとおりです:
- アクティブ/アクティブ・ストレッチ・クラスタ・トポロジのアーキテクチャの説明
サポートされているこのMAAアーキテクチャは、アクティブ/アクティブ・ストレッチ・クラスタ・アプリケーション・インフラストラクチャ層とアクティブ/パッシブ・データベース層で構成され、この2つの層が2つのサイトにまたがっています。両方のサイトがWebLogic Serverストレッチ・クラスタとともに構成され、それぞれのクラスタのすべてのサーバー・インスタンスがアクティブです。データベース層は、最初のサイトではアクティブで、2番目のサイトではスタンバイです。 - アクティブ/アクティブ・ストレッチ・クラスタ・トポロジの設計に関する考慮事項
アクティブ/パッシブ・データベース層を含むアクティブ/アクティブ・ストレッチ・クラスタ・トポロジにおける、設計に関するOracleのベスト・プラクティスの推奨事項を考慮してください。
アクティブ/アクティブ・ストレッチ・クラスタ・トポロジのアーキテクチャの説明
サポートされているこのMAAアーキテクチャは、アクティブ/アクティブ・ストレッチ・クラスタ・アプリケーション・インフラストラクチャ層とアクティブ/パッシブ・データベース層で構成され、この2つの層が2つのサイトにまたがっています。両方のサイトがWebLogic Serverストレッチ・クラスタとともに構成され、それぞれのクラスタのすべてのサーバー・インスタンスがアクティブです。データベース層は、最初のサイトではアクティブで、2番目のサイトではスタンバイです。
図5-1は、アクティブ/アクティブ・ストレッチ・クラスタ・アプリケーション・インフラストラクチャ層をアクティブ/パッシブ・データベース層とともに使用した、推奨されるアーキテクチャを示しています。
図5-1 アクティブ/アクティブ・ストレッチ・クラスタとアクティブ/パッシブ・データベース層からなるアーキテクチャ図
「図5-1 アクティブ/アクティブ・ストレッチ・クラスタとアクティブ/パッシブ・データベース層からなるアーキテクチャ図」の説明
このトポロジの主な特徴は次のとおりです。
-
グローバル・ロード・バランサ。
-
各サイトにあるOracle HTTP Server (OHS)の2つのアクティブ・インスタンス。OHSは、WebLogic Serverクラスタに対するリクエストを均衡化できます。
-
2つの異なるデータ・センター(サイト1およびサイト2)間まで拡張するクラスタとして構成されたWebLogic Server。クラスタ内のすべてのサーバーがアクティブです。クラスタは、静的にも動的にもなります。「クラスタリング」を参照してください。
-
ドメインには次のものが含まれます:
-
サイト1の管理対象サーバー(MS1、MS2およびMS3)のグループと、もう1つのサイト2の管理対象サーバー(MS4、MS5およびMS6)のグループで構成される、WebLogic Serverクラスタ。管理対象サーバーはサイト1にあるWebLogic Server管理サーバーによって管理されます。この例では、管理対象サーバーをプライマリ・データベースに接続するためにActive Gridlink (AGL)が使用されています。(汎用データ・ソースやマルチ・データ・ソースを使用できますが、高可用性とパフォーマンス向上を実現できるため、Active Gridlinkをお薦めします。)
ゼロ・ダウンタイム・パッチ適用(ZDT)によって、ローリング方式による管理対象サーバーのパッチ適用の提示が可能です。クラスタ内のすべてのサーバーがアクティブであるため、「WebLogic Serverゼロ・ダウンタイム・パッチ適用」で説明されているように、この機能の全要素を使用できます。
すべてのサーバーが同じクラスタ内に存在するため、WebLogic Serverシングルトン・サービス移行を使用してトランザクションをリカバリできます。
-
ドメイン内のWebLogic Server管理サーバーによって管理されている、各サイト(COH1、COH2およびCOH3)のCoherenceクラスタ。Coherence永続キャッシュは、クラスタで障害が発生した場合に、キャッシュ済データのリカバリに使用されます。Read-ThroughキャッシングまたはCoherence GoldenGate Hot Cacheが、データベースからのキャッシュの更新に使用されます。このアーキテクチャでは、「Coherence GoldenGate Hot Cache」で説明されているように、Coherence HotCacheの全要素を使用できます。
Coherenceフェデレーテッド・キャッシュは、2つのサイト間で非同期的にキャッシュ・データをレプリケートします。このアーキテクチャでは、「Coherenceフェデレーテッド・キャッシュ」で説明されているように、この機能の全要素を使用できます。
-
-
構成データ、ローカル・バイナリ、ログ、ドメイン・ホーム、ノード・マネージャ・ディレクトリ、共有アプリケーション固有ファイルおよび共有クラスタ・ファイル用のファイル・ストレージ。これはストレッチ・クラスタであるため、共有クラスタ・ファイル(TLog、JMSストア、リース表)はすべて、クラスタ内のサーバー間で共有できるようにデータベースに格納する必要があります。
-
2つの異なるデータ・センター内にある2つの別個のOracle RACデータベース・クラスタ。プライマリ・アクティブのOracle RACデータベース・クラスタはサイト1にあります。サイト2にはスタンバイ(パッシブ)読取り専用モードでOracle RACデータベース・クラスタが含まれます。クラスタにはトランザクション・ログ、JMSストアおよびアプリケーション・データが含まれる場合があります。データは、Oracle Data GuardまたはActive Data Guardを使用してレプリケートされます。(最高レベルの高可用性が提供されることからOracle RACデータベース・クラスタの使用が推奨されていますが、これは必須ではありません。単一データベースまたはマルチテナント・データベースも使用できます。)
-
Oracle WebLogic Server構成は、Oracle WebLogic Serverインフラストラクチャによって、同じドメインの複数のノードにわたり同期されます。この構成の大半は通常、管理サーバーのドメイン・ディレクトリにあります。この構成は同じドメインでOracle WebLogic Serverを格納する他のノードに自動的に伝播されます。このため、アクティブ-アクティブ・ストレッチ・クラスタ・システムの管理オーバーヘッドは、WebLogicの構成変更を絶えずレプリケートする必要があるアクティブ-パッシブのアプローチに比べ、小さくなります。
アクティブ/アクティブ・ストレッチ・クラスタ・トポロジの設計に関する考慮事項
アクティブ/パッシブ・データベース層を含むアクティブ/アクティブ・ストレッチ・クラスタ・トポロジにおける、設計に関するOracleのベスト・プラクティスの推奨事項を考慮してください。
ここで説明する設計上の考慮事項に加えて、サポートされるすべてのWebLogic ServerおよびCoherence MAAアーキテクチャについて推奨されるベスト・プラクティスにも従う必要があります。「高可用性およびディザスタ・リカバリのための設計に関する一般的な考慮事項」を参照してください
アクティブ/アクティブ・ストレッチ・クラスタで高可用性機能を最大限に利用するには、次のことを考慮してください:
-
マルチ・データ・センターでは、アクティブ/アクティブ・ストレッチ・クラスタ環境のデータ・センター間のセッション・レプリケーションによって、システムで重大なパフォーマンス低下が引き起こされる可能性があります。異なる2つのレプリケーション・グループ(各サイトに1つ)を定義して、2つのサイト間で発生するレプリケーションの可能性を最小限にすることをお薦めします。
ノート:
レプリケーション・グループの使用は、同一サイト内のサーバーのみに状態をレプリケートするために最良の方法ですが、決定的な方法ではありません。1つのサーバーが一方のサイトで使用でき、その他のサーバーはもう一方のサイトで使用できる場合、MANの間でレプリケーションが発生し、そのセッションの間はサーバーが同じサイトで元のようにオンラインになっても継続します。
-
ストレッチ・クラスタでは、(OHSプラグインにより提供される、単一の場所の標準的なデプロイメントで使用される動的リストではなく)各サイトのサーバーの固定リストに基づいたOracle HTTP Server (OHS)構成が使用されます。サーバーの固定リストを使用することで、サイト間の不要なルーティングを省略できます。しかし、Oracle WebLogic Serversの障害に対する反応時間が遅くなるというデメリットがあります。
-
アクティブ/アクティブ型ストレッチ・クラスタはメトロ遅延モデルでのみ機能します。遅延は10ミリ秒のラウンド・トリップ時間(RTT)以下にする必要があります。
-
競合およびセキュリティの理由で、サイト間の共有ストレージの使用はお薦めしません。各サイトがJMSおよびトランザクション・ログ(TLog)用に個別の共有ストレージを使用するか、データベースが永続ストアとして使用されます。共有ストレージにより提供される保護のレベルはデータベースにより保証される保護よりもはるかに低いため、システムに共有ストレージではなくデータベース・ストアを使用するほうが適しているかどうかは、JMSおよびトランザクション・データがどれだけ重要かによって決まります。JMS、TLogおよびリース表がData Guardデータベースにある場合、クロスサイトの同期が簡素化され、NASやSANなどの共有ストレージ・サブシステムの必要性は中間層で軽減されます。ただし、TLogおよびJMSストアをデータベースで使用すると、システム・パフォーマンスが低下するというペナルティがあります。サイトの1つが他のサイトのデータベースと相互通信する必要がある場合は、このペナルティが増加します(サイト間のネットワーク・ラグによって異なります)。
- 各サイトは個別の共有ストレージを使用します。これを使用してランタイム・データを格納する場合、サイト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でADMINHOSTVHN1が20.20.20.1にマップされるようにローカルの/etc/hostsまたはDNSサーバーのいずれかを更新する必要があります。すべてのサーバーがADMINHOSTVHN1を管理サーバーにアクセスするアドレスとして使用します。管理サーバーがOracle HTTP Serverおよびロード・バランサのフロント・エンドの場合、クライアントはこの変更に依存しません。クライアントが管理サーバーのリスニング・ホスト名に直接アクセスする場合、DNS解決でもそれらを更新する必要があります。また、管理サーバーに対してホスト名検証が有効になっている場合、適切な信頼ストアとキー・ストアも新規証明書で更新する必要があります。『ディザスタ・リカバリ・ガイド』のスタンバイ・サイトでの自己署名証明書とキーストアの更新に関する項に示された手順を使用してください。
Oracle WebLogic Server管理コンソールにアクセスして、管理サーバーが適切に動作していることを確認します。
-
管理サーバーに対してリモートのサーバーは、配置されているサーバーよりも再起動が長くかかります。その理由は、管理サーバーとのすべての通信(起動時にドメイン構成を取得するためのもの)および最初の通信プール作成およびデータベース・アクセスがサイト間の遅延の影響を受けるためです。高可用性ガイドの管理サーバーの高可用性トポロジを参照してください。
-
サイト間でのサーバーまたはサービスの自動移行は、データベースがJMSおよびTLogの永続性のために使用されていないかぎりお薦めしません。それ以外の場合は、適切な永続ストアの一定のレプリカをサイト間で設定する必要があります。
-
サーバーの移行ではなく、サービスの移行を使用することをお薦めします。サーバーの移行では仮想IPが使用されますが、ほとんどのシナリオでは、一方のサイトで使用されている仮想IPは、もう一方のサイトへの移行には無効です。最初にサイト1で使用可能なリスニング・アドレスをサイト2で(あるいはその逆で)有効にするためには、追加の操作が必要です。この操作は移行前スクリプトで自動化できますが、(単一データ・センターの範囲内で発生する)標準の自動化サーバー移行と比較するとRTOは増加します。比較すると、サービスの移行は仮想IPを必要とせず、RTOはサーバーの移行よりもはるかに優れています。
-
サイト間のJMSおよびトランザクション・リカバリは、WebLogic Serverストレッチ・クラスタ内部のサービスまたはサーバーの移行を使用して処理されます。一般設計に関する考慮事項: WebLogic Serverの項で説明したように、サーバーの移行ではなく、サービスの移行を使用することをお薦めします。JMSまたはJTAのサーバーまたはサービス移行の場合、高可用性データベース上でリースしているデータベースの使用をお薦めします。コンセンサス非データベース・リースで構成されている場合、ストレッチ・クラスタ内のサーバーがリブートに失敗し、環境でネットワークの分断障害が発生したときにドメイン全体の再起動が必要になる可能性があります。
-
アクティブ/アクティブ・ストレッチ・クラスタ・トポロジでのゼロ・ダウンタイム・パッチ適用では、ストレッチ・クラスタ内のすべてのサーバーに対する更新が両方のサイト間で編成されます。ストレッチ・クラスタでは、各サイトのサーバーがそれぞれのOracleホームを持つ必要があります。各サーバーが同じOracleホームを共有していると、そのOracleホームが更新されたときに、すべてのサーバーを停止して同時に更新する必要があります。各サーバーがそれぞれのOracleホームを持っている場合は、各サーバーに個別にパッチを適用でき、ストレッチ・クラスタ内の他のサーバーは引き続きリクエストを処理できます。ゼロ・ダウンタイム・パッチ適用を参照してください。
-
アクティブ/アクティブ・ストレッチ・クラスタ・トポロジでは、2つのサイト間でWebLogic Serverクラスタのみを拡張します。Coherenceでは、2つのアクティブなサイト間でデータをレプリケートするためにフェデレーテッド・キャッシュを使用して各サイトにCoherenceクラスタを持つ必要があります。Coherenceクラスタがサイト間で拡張されると、スプリット・ブレインの影響を受けやすくなります。
-
表5-1は、ストレッチ・クラスタ・トポロジでのデータベース・リースに構成するお薦めの設定のリストを示しています。Oracle WebLogic Server MBeanリファレンスのMBeanに関する次の説明を参照してください。
表5-1 ストレッチ・クラスタでのデータベース・リースにお薦めする設定
構成プロパティ MBean/コマンド 説明 推奨設定 DatabaseLeasingBasisConnectionRetryCountClusterMBeanデータベース・リースがデータソースから有効な接続を取得するための最大試行回数。
5 (デフォルト値は1)
DatabaseLeasingBasisConnectionRetryDelayClusterMBean接続が失敗したときに、データベース・リースがデータ・ソースからの新しい接続の取得を試行するために待機する時間(ミリ秒)。
2000 (デフォルト値は1000)
TestConnectionOnReserveJDBCConnectionPoolParamsBean接続をクライアントに渡す前にWebLogic Serverでテストできるようにします。
有効。データ・ソースのリース用。サーバーはスイッチオーバー中は稼働状態のままです。
-Dweblogic.cluster.jta.SingletonMasterRetryCountサーバーの起動コマンド
シングルトン・マスターが選択されてそのリスニング・ポートをオープンするための試行カウントを指定します。シングルトン・マスターは、JTAを非アクティブ化する最初の試行時にすぐに使用可能にならない場合があります。
4 (デフォルト値は20)
DatabaseLeasingBasisConnectionRetryCountが5に設定されているため、このプロパティは4に減らせます。この設定はデータベース・サーバーのブート中の時間コストを減らせます。 -
図5-2および図5-3は、ベンチマーク・テスト中に見つかった、異なる遅延に対するシステム全体のスループット(両方のサイトは一緒に稼働しています)で見られる低下を示す結果を表しています。図5-2は、約20ミリ秒のラウンド・トリップ時間(RTT)の遅延中にスループットが25%程度低下することを示しています。図5-3は、SOAアクティブ/アクティブ・ストレッチ・クラスタ内のサイト間の遅延(ミリ秒単位のRTT)の増加とともにSOAコンポジットをデプロイするために消費される追加時間(ミリ秒単位) (同じサイトのすべてのサーバーおよびデータベースのデプロイメントと比較した場合)を示しています。
多くのテストで見られる提供データとパフォーマンスのペナルティを考慮して、アクティブ/アクティブ・ストレッチ・クラスタ・トポロジで遅延が2つのサイト間の通信に影響を及ぼす場合は10ミリ秒の遅延(RTT)を超えないことをお薦めします。
