WebLogic Server クラスタ ユーザーズ ガイド
|
 |
 |
|
この章では、各種のオブジェクトを対象とした WebLogic Server クラスタでのロード バランシングのサポートについて説明し、設計者および管理者向けに、ロード バランシングに関連する計画およびコンフィグレーション上の考慮事項を示します。説明する内容は以下のとおりです。
クラスタのレプリケーションとフェイルオーバについては、「クラスタのフェイルオーバとレプリケーション」を参照してください。
サーブレットと JSP のロード バランシングは、WebLogic プロキシ プラグインに組み込まれたロード バランシング機能を使用するか、またはロード バランシング ハードウェアを別途用意することによって実現できます。
注意 : HTTP トラフィックの分散に加えて、外部ロード バランサは、t3 とデフォルト チャネルを介した Java クライアントからの初期コンテキスト リクエストを分散することができます。WebLogic Server でのオブジェクトレベルのロード バランシングについては、「EJB と RMI オブジェクトのロード バランシング」を参照してください。
WebLogic Server プラグイン、HttpClusterServlet、またはサードパーティ製のロード バランサを使用して WebLogic Server クラスタに接続するクライアントで T3 トンネリングが使用されている場合、クライアントはクラスタの他のメンバー間でセッション内のリクエストのロード バランシングを試み、クラスタ内の他のサーバ インスタンスに直接接続しようとします。
クライアントがトンネリング接続を介してのみ接続を行うようにするには、クラスタのデフォルトのロード バランシング アルゴリズムをサーバ アフィニティ アルゴリズムのいずれか 1 つに設定します (「ラウンドロビン アフィニティ、重みベース アフィニティ、およびランダム アフィニティ」を参照)。ロード バランシング アルゴリズムは、Administration Console の [クラスタ｜コンフィグレーション｜全般] タブで設定します。
WebLogic プロキシ プラグインは、クラスタ化されたサーブレットまたは JSP のホストである WebLogic Server インスタンスのリストを維持し、ラウンドロビン方式で HTTP リクエストをそれらのインスタンスに転送します。このロード バランシング方法については、「ラウンドロビンのロード バランシング」で説明します。
このプラグインは、WebLogic Server インスタンスで障害が発生した場合に、クライアントの HTTP セッション ステートのレプリカを見つけるために必要なロジックも備えています。
WebLogic Server は、以下の Web サーバおよび関連プロキシ プラグインをサポートしています。
HttpClusterServletプロキシ プラグインの設定方法については、「プロキシ プラグインをコンフィグレーションする」を参照してください。
プロキシ プラグインによるクラスタ内の HTTP セッションの接続およびフェイルオーバの詳細については、「クラスタ化されたサーブレットと JSP へのプロキシ経由のアクセス」を参照してください。
ハードウェアによるロード バランシング ソリューションを利用するクラスタでは、ハードウェアが対応しているすべてのロード バランシング アルゴリズムを利用できます。この中には、個々のマシンの利用状況をモニタする負荷ベースの高度な調整方式を採用しているものもあります。
プロキシ プラグインではなくロード バランシング ハードウェアを使用する場合、互換性のあるパッシブまたはアクティブなクッキーの永続性メカニズムと、SSL の永続性にハードウェアが対応している必要があります。
パッシブなクッキーの永続性を使用すると、WebLogic Server は、ロード バランサを介したクライアントへのセッション パラメータ情報を含むクッキーを記述できます。セッション クッキーの詳細、およびロード バランサがセッション パラメータ データを使用して、HTTP セッション ステートをホストするプライマリ WebLogic Server とクライアントの関係を保持する仕組みについては、「ロード バランサと WebLogic セッション クッキー」を参照してください。
ロード バランサが WebLogic Server クッキーを変更しないのであれば、特定のアクティブなクッキーの永続性メカニズムを WebLogic Server クラスタで使用することもできます。WebLogic Server クラスタでは、WebLogic HTTP セッション クッキーを上書きするか、または変更するアクティブなクッキーの永続性メカニズムはサポートされていません。ロード バランサのアクティブなクッキーの永続性メカニズムが、クライアント セッションに独自のクッキーを追加するものである場合は、WebLogic Server クラスタでロード バランサを使用するにあたって、新たなコンフィグレーションは不要です。
パッシブなクッキーの永続性を使用するロード バランサは、WebLogic セッション クッキーに文字列を使用することで、クライアントをそのプライマリ HTTP セッション ステートのホストになるサーバに関連付けることができます。文字列は、クラスタ内のサーバ インスタンスをユニークに識別します。ロード バランサをコンフィグレーションする際に、文字列定数のオフセットと長さを指定する必要があります。オフセットと長さの正しい値は、セッション クッキーの形式によって異なります。
sessionid!primary_server_id!secondary_server_id
sessionid は、HTTP セッションの識別子で、ランダムに生成されます。値の長さは、アプリケーションの weblogic.xml ファイルの <session-descriptor> 要素にある IDLength パラメータでコンフィグレーションします。デフォルトでは、sessionid の長さは 52 バイトです。primary_server_id と secondary_server_id は、セッションのプライマリ ホストとセカンダリ ホストの 10 文字の識別子です。 注意 : 非レプリケート メモリ、クッキー、JDBC、またはファイルベースのセッション永続性を使用するセッションの場合、secondary_server_id はありません。インメモリ レプリケーションを使用するセッションで、2 番目のセッションが存在しない場合は、secondary_server_id は「NONE」になります。
ロード バランサの一般的なコンフィグレーション手順については、「パッシブなクッキーの永続性をサポートするロード バランサをコンフィグレーションする」を参照してください。BIG-IP のコンフィグレーション手順については、「クラスタに関する BIG-IPTM ハードウェアのコンフィグレーション」を参照してください。
クラスタ化されるサーブレットおよび JSP を対象とした、プログラミング上の制約および考慮事項については、「クラスタ化されるサーブレットおよび JSP のプログラミング上の考慮事項」を参照してください。
ロード バランシング ハードウェアによるクラスタ内の HTTP セッションの接続およびフェイルオーバの詳細については、「クラスタ化されたサーブレットと JSP へのロード バランシング ハードウェアを利用したアクセス」を参照してください。
この節では、EJB と RMI オブジェクトの WebLogic Server ロード バランシングアルゴリズムについて説明します。
オブジェクトのロード バランシング アルゴリズムは、クラスタ化されたオブジェクトで取得されるレプリカ対応スタブに保持されます。
デフォルトでは、WebLogic Server クラスタはラウンドロビン ロード バランシングを使用します (「ラウンドロビンのロード バランシング」を参照)。Administration Console を使用して weblogic.cluster.defaultLoadAlgorithm を設定すれば、クラスタに別のデフォルト ロード バランシングをコンフィグレーションできます。手順については、「EJB と RMI のロード バランシング方式をコンフィグレーションする」を参照してください。特定の RMI オブジェクトに対してロード バランシング アルゴリズムを指定することもできます。そのためには、rmic の -loadAlgorithm オプションを使用するか、EJB のデプロイメント記述子で home-load-algorithm または stateless-bean-load-algorithm を使用します。オブジェクトにコンフィグレーションしたロード バランシング アルゴリズムは、クラスタのデフォルトのロード バランシング アルゴリズムをオーバーライドします。
WebLogic Server 8.1 では、サーバ アフィニティを実現する、RMI オブジェクトの新しい 3 つのロード バランシング アルゴリズムが導入されます。詳細については、「サーバ アフィニティ ロード バランシング アルゴリズム」を参照してください。
標準のロード バランシング アルゴリズムだけでなく、WebLogic Server ではパラメータ ベースのカスタム ルーティングもサポートされます。詳細については、「クラスタ化されたオブジェクトのパラメータベースのルーティング」を参照してください。
WebLogic Server は、オブジェクト レベルで特定のアルゴリズムが指定されていない場合には、クラスタ化されたオブジェクト スタブのロード バランシング方式としてデフォルトでラウンドロビン アルゴリズムを使用します。このアルゴリズムは、RMI オブジェクトおよび EJB 用にサポートされています。また、WebLogic プロキシ プラグインで使用される手法でもあります。
このアルゴリズムは、WebLogic Server インスタンスのリストを順番に循環します。クラスタ化されたオブジェクトの場合、サーバ リストはそのオブジェクトのホストとなる WebLogic Server インスタンスからなります。プロキシ プラグインの場合、リストは、クラスタ化されたサーブレットまたは JSP のホストとなるすべての WebLogic Server インスタンスからなります。
ラウンドロビン アルゴリズムの長所は、シンプルで、動作コストの面で有利で、非常に予測しやすいということです。主な短所は、コンボイの可能性が若干あることです。コンボイは、あるサーバがその他のサーバよりも著しく速度が低下したときに発生します。レプリカ対応スタブまたはプロキシは同じ順序でサーバにアクセスするので、速度の遅いサーバがあると、リクエストがそのサーバ上で「同期」するため、その他のサーバが将来のリクエストに備えて停滞する可能性があります。
注意 : WebLogic Server では、オブジェクトのメソッド呼び出しに対して常にロード バランシングが実行されるわけではありません。詳細については、「連結されたオブジェクトの最適化」を参照してください。
このアルゴリズムは、EJB および RMI オブジェクトのクラスタ化だけに適用されます。
重みベースのロード バランシングは、各サーバに事前に割り当てられる重みを考慮することによって、ラウンドロビン アルゴリズムを改良したものです。Administration Console の [サーバ｜コンフィグレーション｜クラスタ] タブの [クラスタの重み] フィールドで、1 ～ 100 の範囲の数値を設定し、クラスタ内の各サーバに重みを割り当てることができます。この値は、あるサーバにかかる負荷の割合を他のサーバとの相対比較で決定します。すべてのサーバの重みが同じ場合、各サーバには等しい割合の負荷がかかります。あるサーバの重みが 50 で、他のサーバがすべて重み 100 の場合、重み 50 のサーバへの割り当ては、他のサーバの半分になります。このアルゴリズムを使うと、均一でないクラスタに対してラウンドロビン アルゴリズムの利点を活かすことができます。
重みベースのアルゴリズムを使用する場合、各サーバ インスタンスに割り当てる相対的な重みを慎重に決定してください。考慮すべき要因には、以下のものがあります。
サーバに指定した重みを変更してサーバを再起動すると、レプリカ対応スタブ経由で新しい重みの情報がクラスタ全体に伝播されます。詳細については、「クラスタワイドの JNDI ネーミング サービス」を参照してください。
注意 : WebLogic Server では、オブジェクトのメソッド呼び出しに対して常にロード バランシングが実行されるわけではありません。 詳細については、「連結されたオブジェクトの最適化」を参照してください。
このバージョンの WebLogic Server では、RMI/IIOP プロトコルを使用して通信するオブジェクトに対して、重みベースのロード バランシングはサポートされていません。
ランダム方式のロード バランシングは、EJB および RMI オブジェクトのクラスタ化にのみ適用されます。
ランダム ロード バランシングでは、リクエストは無作為にサーバに振り分けられます。ランダム ロード バランシングは、同様のコンフィグレーションがなされたマシン上で各サーバ インスタンスが動作する、均一なクラスタ デプロイメント環境でのみ推奨されます。リクエストを無作為に割り当てる方式では、サーバ インスタンスが動作するマシン間で処理能力に差があることは問題となります。クラスタ内でサーバをホストしているマシンの処理能力が、クラスタ内の他のマシンよりも著しく劣っているような場合、ランダム ロード バランシングによって、より強力なマシンに割り当てられるのと同じ分量のリクエストが能力の低いマシンに割り当てられてしまいます。
ランダム ロード バランシングでは、クラスタ内のサーバ インスタンス間で均等にリクエストが分配され、累計のリクエスト数の増加とともに個別の分配量も増します。リクエストの数が少ない場合、負荷は厳密には均等に配分されない場合があります。
ランダム ロード バランシングの欠点としては、リクエストごとにランダムな番号を生成するため、プロセスに多少のオーバーヘッドが発生するということがあります。また、リクエストの数が少ない場合は、負荷が均等に分散されない可能性もあります。
WebLogic Server では、オブジェクトのメソッド呼び出しに対して常にロード バランシングが実行されるわけではありません。詳細については、「連結されたオブジェクトの最適化」を参照してください。
WebLogic Server 8.1 では、サーバ アフィニティを実現する、RMI オブジェクトの新しい 3 つのロード バランシング アルゴリズムが導入されます。サーバ アフィニティは外部クライアント接続のロード バランシングを無効にしますが、その代わりに、クライアント側でオブジェクトにアクセスするサーバ インスタンスを選択するときに WebLogic Server インスタンスとの既存の接続が尊重されます。オブジェクトがサーバ アフィニティ対応にコンフィグレーションされている場合、クライアント側スタブではすでに接続されているサーバ インスタンスを選択しようとし、メソッド呼び出しに同じサーバ インスタンスを使い続けます。そのクライアントのすべてのスタブが同じサーバ インスタンスを使用しようとします。そのサーバ インスタンスが利用不可になると、スタブはクライアントがすでに接続しているサーバ インスタンスに可能であればフェイルオーバします。
サーバ アフィニティの目的は、外部 Java クライアントとクラスタ内のサーバ インスタンスの間で開かれる IP ソケットの数を最小限に抑えることです。WebLogic Server はそのために、利用可能なサーバ インスタンスの間でロード バランシングを行うのではなく、オブジェクトに対するメソッド呼び出しを既存の接続に「固定」します。サーバ アフィニティ アルゴリズムを使用する場合でも、低コストのサーバ間接続はコンフィグレーションされているロード バランシング アルゴリズムに従ってロード バランシングされます。ロード バランシングが無効になるのは、外部クライアント接続だけです。
サーバ アフィニティは、標準のロード バランシング方法 (ラウンドロビン、重みベース、ランダム) のいずれかと組み合わせて使用されます。
クライアントは、クラスタ内の特定のサーバ インスタンスまたはクラスタ (URL でクラスタのアドレスを指定) から初期コンテキストを取得できます。接続プロセスは、コンテキストの取得方法によって異なります。
weblogic.jndi.WLContext プロパティのハッシュテーブルで ENABLE_SERVER_AFFINITY を true に設定します。利用可能な接続がない場合は、新しい接続が作成されます。ENABLE_SERVER_AFFINITY は、コンテキストをクラスタのアドレスから取得する場合のみサポートされています。 WebLogic Server の CSIv2 (Common Secure Interoperability) 機能を使用して WebLogic Server の J2EE アプリケーション クライアント (「シン クライアント」) とのステートフルな対話をサポートする場合は、アフィニティベースのロード バランシング アルゴリズムを使用して、メソッド呼び出しがサーバ インスタンスに固定されるようにする必要があります。そうしないと、すべてのリモート呼び出しが認証されます。ステートフルな CSIv2 クライアントの冗長な認証を防ぐには、「ラウンドロビン アフィニティ、重みベース アフィニティ、およびランダム アフィニティ」で説明するロード バランシング アルゴリズムのいずれかを使用します。
サーバ アフィニティを実現する WebLogic Server 8.1 のロード バランシング アルゴリズムは以下のとおりです。
サーバ アフィニティは、JMS オブジェクト、すべての EJB ホーム インタフェース、およびステートレス EJB リモート インタフェースを含むあらゆるタイプの RMI オブジェクトでサポートされています。
サーバ アフィニティ アルゴリズムでは、WebLogic サーバ インスタンス間のクライアント負荷をロード バランシングする上で外部 Java クライアントとサーバ インスタンス間の既存の接続が尊重されます。サーバ アフィニティは次のように機能します。
以下の例は、さまざまな環境でのサーバ アフィニティの影響を示しています。各例で、デプロイされているオブジェクトはラウンドロビン アフィニティ対応にコンフィグレーションされています。
この例では、クライアントがクラスタからコンテキストを取得します。コンテキストのルックアップとオブジェクトの呼び出しは 1 つの接続に固定されます。新しい初期コンテキストのリクエストは、ラウンドロビンに基づいてロード バランシングされます。
この例は、サーバ アフィニティがオブジェクトのフェイルオーバに与える影響を示しています。管理対象サーバがダウンすると、クライアントはそれがすでに接続している別の管理対象サーバにフェイルオーバします。
この例は、サーバ アフィニティがサーバ インスタンス間の接続に影響しないことを示しています。
パラメータベースのルーティングでは、ロード バランシング動作をより詳細なレベルで制御できます。クラスタ化されたオブジェクトを CallRouter に割り当てることができます。これはパラメータにより各呼び出しの前に呼び出されるクラスです。CallRouter はそのパラメータを自由に調べ、呼び出しの送り先となるネーム サーバを返します。カスタムの CallRouter クラスを作成する手順については、「WebLogic クラスタの API」を参照してください。
WebLogic Server では、オブジェクトのメソッド呼び出しに対して常にロード バランシングが実行されるわけではありません。ほとんどの場合は、リモート サーバにあるレプリカを使用するよりも、スタブ自体と連結しているレプリカを使用する方が効率的です。次の図では、このことを示します。
図 4-4 連結の最適化はメソッド呼び出しに対してロード バランサが備えるロジックよりも優先する
この例では、クライアントは、クラスタ内の最初の WebLogic Server インスタンスにあるサーブレットに接続します。クライアントの動作に対する応答として、サーブレットはオブジェクト A のレプリカ対応スタブを取得します。オブジェクト A のレプリカは同じサーバ インスタンス上にもあるので、そのオブジェクトはクライアントのスタブと連結していると判断されます。
WebLogic Server では、クラスタ内のオブジェクト A の他のレプリカにクライアントの呼び出しを分散しないで、常に、ローカルにある連結されたオブジェクト A のコピーを使用します。クラスタ内の他のサーバとのピア接続を確立するネットワーク オーバーヘッドが避けられるので、ローカル コピーを使用した方が効率的です。
この最適化は、WebLogic Server クラスタの設計段階でよく見過ごされます。連結の最適化は、各メソッド呼び出しでのロード バランシングを必要としている管理者や開発者にとって混乱の元になることもよくあります。Web アプリケーションが単一のクラスタにデプロイされる場合、連結の最適化は、レプリカ対応スタブに固有のどのロード バランシング ロジックよりも優先されます。
クラスタ化されたオブジェクトに対する各メソッド呼び出しでロード バランシングが必要な場合、そのように WebLogic Server クラスタを設計する方法については、「推奨多層アーキテクチャ」を参照してください。
基本的な連結方式の拡張として、WebLogic Server では、同じトランザクションの一部として登録されている連結されたクラスタ化オブジェクトの使用も試みられます。クライアントによって UserTransaction オブジェクトが作成されると、WebLogic Server ではそのトランザクションと連結されているオブジェクトのレプリカが使用されます。次の図は、この最適化の仕組みを表しています。
図 4-5 連結の最適化がトランザクション内のその他のオブジェクトへと拡張する
この例では、クライアントは、クラスタ内の最初の WebLogic Server インスタンスに接続し、UserTransaction オブジェクトを取得します。新しいトランザクションが開始された後、クライアントはトランザクションの処理を実行するためにオブジェクト A とオブジェクト B をルックアップします。この状況では、A と B のスタブによるロード バランシングとは関係なく、WebLogic Server は常に UserTransaction オブジェクトと同じサーバにある A と B のレプリカを使用します。
このようなトランザクションの連結方式は、「連結されたオブジェクトの最適化」で説明されている基本的な最適化よりも重要です。A と B のリモート レプリカが使用される場合は、トランザクションが終了するまでの間、余計なネットワーク オーバーヘッドが生じることになります。なぜなら、トランザクションがコミットされるまで A と B のピア接続がロックされるからです。その上、WebLogic Server ではトランザクションをコミットするために多層 JDBC 接続を利用しなければならないため、さらにネットワーク オーバーヘッドが生じることになります。
トランザクションの間にクラスタ化されたオブジェクトを連結すると、WebLogic Server では個々のオブジェクトにアクセスするためのネットワーク負荷が削減されます。また、サーバでは多層接続ではなく単一層の JDBC 接続を利用してトランザクションの処理を実行できます。
WebLogic Server JMS では、分散 JMS 送り先およびクライアント接続のサーバ アフィニティがサポートされています。
デフォルトの WebLogic Server クラスタでは、ラウンドロビンでオブジェクトのロード バランシングが行われます。JMS オブジェクトのサーバ アフィニティを実現するロード バランシング アルゴリズムを使用するには、クラスタ全体に対して目的の方法をコンフィグレーションする必要があります。ロード バランシング アルゴリズムをコンフィグレーションするには、Administration Console を使用して weblogic.cluster.defaultLoadAlgorithm を設定します。手順については、「EJB と RMI のロード バランシング方式をコンフィグレーションする」を参照してください。
サーバ アフィニティは、分散送り先機能を使用する JMS アプリケーションでサポートされています。この機能は、スタンドアロンの送り先ではサポートされていません。JMS 接続ファクトリのサーバ アフィニティをコンフィグレーションした場合、分散送り先の複数のメンバー間でコンシューマまたはプロデューサをロード バランシングしているサーバ インスタンスはまず、同じサーバ インスタンスで動作しているすべての送り先メンバー間でロード バランシングを試みます。
JMS 接続ファクトリの [サーバ アフィニティを有効化] オプションが分散送り先メンバーのロード バランシングの優先順位にどのような影響を与えるかについては、『WebLogic JMS プログラマーズ ガイド』の「[サーバ アフィニティを有効化] 属性を使用した場合の分散送り先ロード バランシングへの影響」を参照してください。
分散送り先のサーバ アフィニティをコンフィグレーションする手順については、Administration Console オンライン ヘルプの「分散送り先のチューニング」を参照してください。
システム管理者は、複数の JMS サーバをコンフィグレーションし、対象を使用してそれらを定義済みの WebLogic Server に割り当てることで、クラスタ内の複数の JMS サーバ間での送り先のロード バランシングを確立できます。各 JMS サーバは、厳密に 1 つの WebLogic Server にデプロイされ、送り先の集合に対するリクエストを処理します。コンフィグレーションの段階で、システム管理者が JMS サーバの対象を指定してロード バランシングを有効にします。対象の設定手順については、「固定サービスの移行可能対象をコンフィグレーションする」を参照してください。JMS サーバを移行可能対象にデプロイする手順については、「移行可能サービスをデプロイ、アクティブ化、および移行する」を参照してください。
システム管理者は、複数の接続ファクトリをコンフィグレーションし、対象を使用してそれらを WebLogic Server に割り当てることで、クラスタ内のあらゆるサーバから送り先への透過的なアクセスをクラスタ全体にわたって確立できます。各接続ファクトリは、複数の WebLogic Server にデプロイできます。接続ファクトリの詳細については、『WebLogic JMS プログラマーズ ガイド』の「ConnectionFactory オブジェクト」を参照してください。
アプリケーションでは、Java Naming and Directory Interface (JNDI) を使用して接続ファクトリをルックアップし、JMS サーバとの通信を確立するための接続を作成します。各 JMS サーバでは、複数の送り先に対するリクエストが処理されます。JMS サーバによって処理されない送り先に対してのリクエストは、適切なサーバに転送されます。
WebLogic Server 8.1 では、クライアント接続のサーバ アフィニティが提供されます。アプリケーションが特定のサーバ インスタンスと接続されている場合、JMS は同じサーバ インスタンスと新しい JMS 接続を確立しようとします。
接続の作成時に、JMS はまず初期コンテキスト アフィニティの実現を試みます。クライアントが初期コンテキストを取得するために接続した同じサーバに接続しようとします。その際、サーバ インスタンスが接続ファクトリでコンフィグレーションされているものと仮定します。たとえば、接続ファクトリがサーバ A および B に対してコンフィグレーションされているが、クライアントはサーバ C の InitialContext を持っている場合、接続ファクトリは A との新しい接続は確立しませんが、サーバ B と C から選択します。
接続ファクトリが初期コンテキスト アフィニティを実現できない場合は、クライアントがすでに接続しているサーバとのアフィニティを提供しようとします。たとえば、クライアントがサーバ A の InitialContext を持ち、サーバ B との他の種類の接続を確立しているとします。クライアントがサーバ B および C に対してコンフィグレーションされた接続ファクトリを使用する場合、初期コンテキスト アフィニティは実現されません。接続ファクトリは代わりに、サーバ C ではなく、すでに接続されているサーバ B との接続を作成してサーバ アフィニティを実現しようとします。
接続ファクトリが初期コンテキスト アフィニティまたはサーバ アフィニティを提供できない場合、接続ファクトリは可能な限り自由に接続を行うことができます。たとえば、クライアントがサーバ A の初期コンテキストを持ち、他の接続はなく、サーバ B および C に対して接続ファクトリがコンフィグレーションされているものとします。接続ファクトリはいかなるアフィニティも提供することができず、サーバ B または C のいずれかと新しい接続を自由に確立することができます。
注意 : 最後のケースで、クライアントが同じ接続ファクトリを使用して 2 回目の接続を行おうとすると、初回と同じサーバに接続されます。つまり、最初の接続にサーバ B を選択している場合、2 回目の接続を行うと、クライアントはサーバ B と接続され、サーバ アフィニティ ルールが施行されます。
JDBC 接続のロード バランシングでは、ロード バランシング用にコンフィグレーションされたマルチプールを使用する必要があります。ロード バランシング サポートは、マルチプールのコンフィグレーション時にユーザが選択できるオプションです。
ロード バランシング マルチプールは、「フェイルオーバと JDBC 接続」で説明する機能を提供することに加えて、マルチプール内の接続プール間で負荷を分散します。マルチプールには、含まれている接続プールのリストがあります。ロード バランシング用にマルチプールをコンフィグレーションしていない場合は、必ずリスト内の最初の接続プールから接続が試行されます。ロード バランシング マルチプールでは、マルチプール内の各接続プールにラウンドロビン方式でアクセスします。マルチプール接続に対するクライアント リクエストがあるたびに、リストの先頭のプールが交代し、プールがリスト内でサイクルを作ります。
JDBC オブジェクトのクラスタ化の手順については、「クラスタ化された JDBC をコンフィグレーションする」を参照してください。
|
|
|
