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