5 クラスタでのロード・バランシング

Oracle WebLogic Serverクラスタは、様々なタイプのオブジェクトに対してロード・バランシングをサポートします。設計者および管理者向けの計画および構成に関する考慮事項を学習します。

ReadyAppフレームワークによるロード・バランシングについては、Oracle WebLogic ServerへのアプリケーションのデプロイReadyAppフレームワークの使用を参照してください。

この章の内容は次のとおりです。

サーブレットとJSPのロード・バランシング

サーブレットとJSPのロード・バランシングは、WebLogicプロキシ・プラグインに組み込まれたロード・バランシング機能を使用するか、またはロード・バランシング・ハードウェアまたはNGINXを別途用意することによって実現できます。

ノート:

HTTPトラフィックの分散に加えて、外部ロード・バランサは、t3とデフォルト・チャネルを介したJavaクライアントからの初期コンテキスト・リクエストを分散できます。WebLogic Serverでのオブジェクト・レベルのロード・バランシングの詳細は、「EJBとRMIオブジェクトのロード・バランシング」を参照してください。

プロキシ・プラグインによるロード・バランシング

WebLogicプロキシ・プラグインは、クラスタ化されたサーブレットまたはJSPのホストであるWebLogic Serverインスタンスのリストを保持し、ラウンドロビン方式でHTTPリクエストをそれらのインスタンスに転送します。このロード・バランシング方法の詳細は、「ラウンドロビン・ロード・バランシング」を参照してください。

このプラグインは、WebLogic Serverインスタンスで障害が発生した場合に、クライアントのHTTPセッション状態のレプリカを見つけるために必要なロジックも備えています。

WebLogic Serverは、次のWebサーバーおよび関連プロキシ・プラグインをサポートしています。

  • WebLogic ServerとHttpClusterServlet

  • Netscape Enterprise ServerとNetscape (プロキシ)プラグイン

  • ApacheとApache Server (プロキシ)プラグイン

  • Microsoft Internet Information ServerとMicrosoft-IIS (プロキシ)プラグイン

プロキシ・プラグインの設定方法については、「プロキシ・プラグインを構成する」を参照してください

プロキシ・プラグインによるセッションの接続とフェイルオーバーの仕組み

プロキシ・プラグインによるクラスタ内のHTTPセッションの接続およびフェイルオーバーの詳細は、「クラスタ化されたサーブレットとJSPへのプロキシ経由のアクセス」を参照してください

外部ロード・バランサによるHTTPセッションのロード・バランシング

ハードウェアによるロード・バランシング・ソリューションを利用するクラスタでは、ハードウェアが対応しているすべてのロード・バランシング・アルゴリズムを利用できます。この中には、個々のマシンの利用状況をモニターする負荷ベースの高度なバランシング戦略を採用しているものもあります。

ロード・バランサの構成要件

プロキシ・プラグインではなくロード・バランシング・ハードウェアを使用する場合、互換性のあるパッシブまたはアクティブなCookieの永続性メカニズムと、SSLの永続性にハードウェアが対応している必要があります。

  • パッシブなCookieの永続性

    パッシブなCookieの永続性を使用すると、WebLogic Serverは、ロード・バランサを介したクライアントへのセッション・パラメータ情報を含むCookieを記述できます。セッションCookieの詳細、およびロード・バランサがセッション・パラメータ・データを使用して、HTTPセッション状態をホストするプライマリWebLogic Serverとクライアントの関係を保持する仕組みについては、「ロード・バランサとWebLogicセッションCookie」を参照してください

  • アクティブなCookieの永続性

    ロード・バランサがWebLogic Server Cookieを変更しないのであれば、特定のアクティブなCookieの永続性メカニズムをWebLogic Serverクラスタで使用することもできます。WebLogic Serverクラスタでは、WebLogic HTTPセッションCookieを上書き、または変更するアクティブなCookieの永続性メカニズムはサポートされていません。ロード・バランサのアクティブなCookieの永続性メカニズムは、クライアント・セッションに独自のCookieを追加することによって機能する場合は、WebLogic Serverクラスタでロード・バランサを使用する際に、新たな構成は不要です。

  • SSL永続性

    SSL永続性を使用する場合、クライアントとWebLogic Serverクラスタの間でのデータの暗号化および復号化は、すべてロード・バランサが行います。そして、ロード・バランサは、WebLogic Serverがクライアントに挿入したプレーン・テキストのCookieを使用して、クライアントとクラスタ内の特定サーバー間の関連付けを維持します。

ロード・バランサとWebLogicセッションCookie

パッシブなCookieの永続性を使用するロード・バランサは、WebLogicセッションCookieに文字列を使用することで、クライアントをそのプライマリHTTPセッション状態のホストになるサーバーに関連付けることができます。文字列は、クラスタ内のサーバー・インスタンスを一意に識別します。ロード・バランサを構成する際に、文字列定数のオフセットと長さを指定する必要があります。オフセットと長さの正しい値は、セッションCookieの形式によって異なります。

セッションCookieの形式は次のとおりです。

sessionid!primary_server_id!secondary_server_id

説明:

  • sessionidは、HTTPセッションの識別子で、ランダムに生成されます。値の長さは、アプリケーションのweblogic.xmlファイルの<session-descriptor>要素にあるIDLengthパラメータで構成されます。デフォルトでは、sessionidの長さは52バイトです。

  • primary_server_idsecondary_server_idは、セッションのプライマリ・ホストとセカンダリ・ホストの10文字の識別子です。

    ノート:

    非レプリケート・メモリー、Cookieまたはファイル・ベースのセッション永続性を使用するセッションの場合、secondary_server_idはありません。インメモリー・レプリケーションを使用するセッションで、2番目のセッションが存在しない場合は、secondary_server_idは「NONE」になります。

ロード・バランサの一般的な構成手順については、「パッシブなCookieの永続性をサポートするロード・バランサを構成する」を参照してくださいBIG-IPの構成手順は、「クラスタに関するBIG-IPハードウェアの構成」を参照してください

関連するプログラミングの考慮事項

クラスタ化されるサーブレットおよびJSPを対象とした、プログラミング上の制約および考慮事項については、「クラスタ化されるサーブレットおよびJSPのプログラミング上の考慮事項」を参照してください

ロード・バランサでのセッション接続およびフェイルオーバーの仕組み

ロード・バランシング・ハードウェアによるクラスタ内のHTTPセッションの接続およびフェイルオーバーの詳細は、「クラスタ化されたサーブレットとJSPへのロード・バランシング・ハードウェアを利用したアクセス」を参照してください

NGINXオープン・ソースを使用したWebLogicクラスタ・サーバーのロード・バランシング

この項では、NGINXオープン・ソースを使用したWebLogicクラスタ管理対象サーバーのロード・バランシングについて説明します。

NGINXは、HTTP、リバース・プロキシ・サーバー、メール・プロキシ・サーバーおよび汎用TCP/UDPプロキシ・サーバーです。UNIX、Linux、Windowsなどの様々なオペレーティング・システムにインストールできます。

NGINXには、NGINXオープン・ソースとNGINX Plusの2つのバージョンがあります。

  • NGINXオープン・ソースはオープン・ソース・バージョンであり、FreeBSDライセンスで無料で利用できます。

  • NGINX Plusは、コミュニティ・サポートやその他の拡張機能を備えた商用バージョンです。

NGINXは、ユーザー・アプリケーションをホストするWebLogic管理対象サーバーに対する受信HTTPまたはHTTPSリクエストのロード・バランサとして機能します。これは、複数のアプリケーション・サーバーにトラフィックを分散し、Webアプリケーションのパフォーマンス、スケーラビリティおよび信頼性を向上させる、非常に効率的なHTTPロード・バランサです。詳細は、「Using nginx as HTTP load balancer」を参照してください。

NGINXの詳細は、「NGINX」を参照してください。

図5-1 NGINXを使用したWebLogic管理対象サーバーのロード・バランシング


NGINXを使用したWebLogic管理対象サーバーのロード・バランシング。

構成済または動的のいずれのWebLogicクラスタ・ドメインも、単一のVMまたは複数のVMに設定できます。HTTPおよびHTTPSポートでリスニングしている管理対象サーバーがあります。詳細は、「WebLogicクラスタの設定」を参照してください。

WebLogicクラスタ・ドメインは、セキュア・モードを有効にして構成することもできます。『Oracle WebLogic Server Administration Consoleオンラインヘルプ』本番ドメインの保護に関する項を参照してください。

NGINXロード・バランサは、WebLogic管理サーバーをホストしているVMまたは別のVMにインストールでき、HTTPトラフィックとHTTPSトラフィックの両方をロード・バランシングするように構成できます。NGINXインストールの詳細は、『Installing NGINX Open Source』を参照してください。

WebLogic管理対象サーバーへの受信トラフィックのロード・バランシングには、次のNGINXロード・バランシング・アルゴリズムが使用されます。
  • ラウンドロビン・ロード・バランシング・アルゴリズム: リクエストはサーバー全体に均等に分散され、サーバーの重みが考慮されます。ロード・バランシング・メソッドが特定のものに対して構成されていない場合、デフォルトでラウンドロビン・ロード・バランシング・アルゴリズムになります。「Configuring Basic Load Balancing」を参照してください。

  • IPHash (セッション固定性)ロード・バランシング・アルゴリズム: 同じクライアントからのリクエストは、常に同じサーバーに送信されます(そのサーバーが使用できない場合を除く)。そのハッシュを持つすべてのリクエストがそのサーバーに送信されるため、セッションの永続性が確立されます。「Configuring Basic Session Persistence」を参照してください。

ロード・バランシング・アルゴリズムの詳細は、「Choosing a Load-Balancing Method」を参照してください。

クライアント・アプリケーションまたはブラウザとNGINXサーバー間のトラフィックを保護するには、NGINXでSSL終端を有効にできます。詳細は、「NGINX SSL Termination」を参照してください。

大量のトラフィックをサポートするために、NGINXではパフォーマンス・チューニングが必要になる場合があります。詳細は、「Tuning NGINX for Performance」を参照してください。

EJBとRMIオブジェクトのロード・バランシング

EJBとRMIオブジェクトのWebLogic Serverロード・バランシング・アルゴリズムを学習します。オブジェクトのロード・バランシング・アルゴリズムは、クラスタ化オブジェクトで取得されるレプリカ対応スタブに保持されます。

デフォルトでは、WebLogic Serverクラスタはラウンドロビン・ロード・バランシングを使用します。詳細は、「ラウンドロビン・ロード・バランシング」を参照してください。WebLogic Server管理コンソールを使用してweblogic.cluster.defaultLoadAlgorithmを設定することで、クラスタで別のデフォルトのロード・バランシング・メソッドを構成できます。手順については、「EJBとRMIのロード・バランシング方式を構成する」を参照してくださいまた、rmic-loadAlgorithmオプションを使用するか、またはEJBのデプロイメント記述子のhome-load-algorithmまたはstateless-bean-load-algorithmを使用して、特定のRMIオブジェクト用のロード・バランシング・アルゴリズムを指定できます。オブジェクトに構成したロード・バランシング・アルゴリズムは、クラスタのデフォルトのロード・バランシング・メソッドをオーバーライドします。

標準のロード・バランシング・アルゴリズムだけでなく、WebLogic Serverではパラメータ・ベースのカスタム・ルーティングもサポートされます。「クラスタ化オブジェクトのパラメータ・ベースのルーティング」を参照してください。

また、外部ロード・バランサはt3およびデフォルト・チャネル全体のJavaクライアントからの初期コンテキスト・リクエストを分散できます。ただし、EJBおよびRMIオブジェクトのWebLogic Serverロード・バランシングは、サーバー・アフィニティが採用される状況を含むレプリカ認識スタブを使用して制御されるため、初期コンテキスト・リクエストに続いてロード・バランサを通してクライアント・リクエストをルーティングしません。外部ロード・バランサとt3プロトコルを併用するとき、初期コンテキスト・リクエストのみがロード・バランサを通してルーティングされ、後続のリクエストがWebLogic Serverのロード・バランシングを使用してルーティングおよび制御されていることを確認する必要があります。

t3sプロトコルと外部ロード・バランサの併用はお薦めしません。t3やSSLを外部ロード・バランサと併用する必要がある場合、HTTPSを介したt3トンネリングの使用をお薦めします。サーバー・アフィニティが必要な場合、リクエストのルーティングにHTTPセッションIDを使用し、ロード・バランサでSSLを終了する必要があります。これで、セッションベースのルーティングが実行され、セッションIDに基づいたリクエストの適切なルーティングが実現します。

ラウンドロビン・ロード・バランシング

WebLogic Serverは、特定のアルゴリズムが指定されていない場合には、クラスタ化オブジェクト・スタブのロード・バランシング戦略としてデフォルトでラウンドロビン・アルゴリズムを使用します。このアルゴリズムは、RMIオブジェクトおよびEJB用にサポートされています。また、WebLogicプロキシ・プラグインで使用される手法でもあります。

このアルゴリズムは、WebLogic Serverインスタンスのリストを順番に循環します。クラスタ化オブジェクトの場合、サーバー・リストはそのオブジェクトのホストとなるWebLogic Serverインスタンスからなります。プロキシ・プラグインの場合、リストは、クラスタ化されたサーブレットまたはJSPのホストとなるすべてのWebLogic Serverインスタンスからなります。

ラウンドロビン・アルゴリズムの長所は、シンプルで、動作コストの面で有利で、非常に予測しやすいということです。主な短所は、コンボイの可能性が若干あることです。コンボイは、あるサーバーがその他のサーバーよりも著しく速度が低下したときに発生します。レプリカ対応スタブまたはプロキシは同じ順序でサーバーにアクセスするので、速度の遅いサーバーがあると、リクエストがそのサーバー上で「同期」するため、その他のサーバーが将来のリクエストに備えて停滞する可能性があります。

ノート:

WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。「連結されたオブジェクトの最適化」を参照してください。

重みベースのロード・バランシング

このアルゴリズムは、EJBおよびRMIオブジェクトのクラスタリングだけに適用されます。

重みベースのロード・バランシングは、各サーバーにあらかじめ割り当てられた重みを考慮することで、ラウンドロビン・アルゴリズムよりも優れています。WebLogic Server管理コンソールで、「サーバー」「構成」「クラスタ」を選択して「クラスタ」ページに移動し、「クラスタの重み」フィールドで、1から100の重みを表す数値をクラスタ内の各サーバーに割り当てることができます。この値によって、サーバーにかかる負荷の割合が他のサーバーと相対的に決まります。すべてのサーバーの重みが同じ場合、等しい割合の負荷が各サーバーにかかります。1つのサーバーの重みが50で、他のすべてのサーバーの重みが100の場合、重みが50のサーバーの負荷は他のサーバーの半分になります。このアルゴリズムを使用すると、均一でないクラスタにラウンドロビン・アルゴリズムの利点をもたらすことができます。

重みベースのアルゴリズムを使用する場合、各サーバー・インスタンスに割り当てる相対的な重みを慎重に決定してください。考慮すべき要因には、次のものがあります。

  • 他のサーバーと比較したサーバーのハードウェアの処理能力(WebLogic Server専用のCPUの数と性能など)

  • 各サーバーをホストとする、クラスタ化されていない(「固定された」)オブジェクトの数

サーバーに指定した重みを変更してサーバーを再起動すると、レプリカ対応スタブ経由で新しい重みの情報がクラスタ全体に伝播されます。詳細は、「クラスタ全体のJNDIネーミング・サービス」を参照してください

ノート:

WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。「連結されたオブジェクトの最適化」を参照してください。

このバージョンのWebLogic Serverでは、RMI/IIOPプロトコルを使用して通信するオブジェクトに対して、重みベースのロード・バランシングはサポートされていません。

ランダム・ロード・バランシング

ランダム方式のロード・バランシングは、EJBおよびRMIオブジェクトのクラスタリングにのみ適用されます。

ランダム・ロード・バランシングでは、リクエストは無作為にサーバーに振り分けられます。ランダム・ロード・バランシングは、同様の構成がなされたマシン上で各サーバー・インスタンスが動作する、均一なクラスタ・デプロイメント環境でのみ推奨されます。リクエストを無作為に割り当てる方式では、サーバー・インスタンスが動作するマシン間で処理能力に差があることは問題となります。クラスタ内でサーバーをホストしているマシンの処理能力が、クラスタ内の他のマシンよりも著しく劣っているような場合、ランダム・ロード・バランシングによって、より強力なマシンに割り当てられるのと同じ分量のリクエストが能力の低いマシンに割り当てられてしまいます。

ランダム・ロード・バランシングでは、クラスタ内のサーバー・インスタンス間で均等にリクエストが分配され、累計のリクエスト数の増加とともに個別の分配量も増します。リクエストの数が少ない場合、負荷は厳密には均等に配分されない場合があります。

ランダム・ロード・バランシングの欠点としては、リクエストごとにランダムな番号を生成するため、プロセスに多少のオーバーヘッドが発生するということがあります。また、リクエストの数が少ない場合は、負荷が均等に分散されない可能性もあります。

ノート:

WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。「連結されたオブジェクトの最適化」を参照してください。

サーバー・アフィニティ・ロード・バランシング・アルゴリズム

WebLogic Serverでは、サーバー・アフィニティを実現する、RMIオブジェクトの新しい3つのロード・バランシング・アルゴリズムが提供されています。サーバー・アフィニティによって外部クライアント接続のロード・バランシングが無効になります。そのかわり、クライアントがオブジェクトにアクセスするサーバー・インスタンスを選択するときに、それ自体の既存の接続をWebLogic Serverインスタンスとみなします。オブジェクトがサーバー・アフィニティ対応に構成されている場合、クライアント側スタブではすでに接続されているサーバー・インスタンスを選択しようとし、メソッド呼出しに同じサーバー・インスタンスを使い続けます。そのクライアントのすべてのスタブが同じサーバー・インスタンスを使用しようとします。そのサーバー・インスタンスが利用不可になると、スタブはクライアントがすでに接続しているサーバー・インスタンスに可能であればフェイルオーバーします。

サーバー・アフィニティの目的は、外部Javaクライアントとクラスタ内のサーバー・インスタンスの間で開かれるIPソケットの数を最小限に抑えることです。WebLogic Serverはそのために、利用可能なサーバー・インスタンスの間でロード・バランシングを行うのではなく、オブジェクトに対するメソッド呼出しを既存の接続に「固定」します。サーバー・アフィニティ・アルゴリズムを使用する場合でも、低コストのサーバー間接続は構成されているロード・バランシング・アルゴリズムに従ってロード・バランシングされます。

ノート:

ロード・バランシングが無効になるのは、外部クライアント接続だけです。

サーバー・アフィニティは、標準のロード・バランシング方法(ラウンドロビン、重みベース、ランダム)のいずれか1つと組み合せて使用されます。

  • ラウンドロビン・アフィニティ: サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理します。ラウンドロビン・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

  • 重みベース・アフィニティ: サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、重みベース・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

  • ランダム・アフィニティ: サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、ランダム・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。

サーバー・アフィニティを提供するロード・バランシング・アルゴリズムの詳細は、ラウンドロビン・アフィニティ、重みベース・アフィニティ、およびランダム・アフィニティを参照してください。

サーバー・アフィニティと初期コンテキスト

クライアントは、クラスタ内の特定のサーバー・インスタンスまたはクラスタ(URLでクラスタのアドレスを指定)から初期コンテキストを取得できます。接続プロセスは、コンテキストの取得方法によって異なります。

  • 初期コンテキストを特定の管理対象サーバーからリクエストする場合、コンテキストは指定されたサーバー・インスタンスとの新しい接続を使用して取得されます。

  • 初期コンテキストをクラスタから取得する場合、デフォルトで、コンテキスト・リクエストはクラスタ化サーバー・インスタンスの間でラウンドロビンに基づいてロード・バランシングされます。特定のJVMとクラスタ間の既存の接続を再利用するには、コンテキストを取得するときに指定するweblogic.jndi.WLContextプロパティのハッシュ表でENABLE_SERVER_AFFINITYtrueに設定します。(利用可能な接続がない場合は、新しい接続が作成されます。)ENABLE_SERVER_AFFINITYは、コンテキストをクラスタのアドレスから取得する場合のみサポートされています。

サーバー・アフィニティとCSIv2を使用したIIOPクライアント認証

WebLogic ServerのCSIv2 (Common Secure Interoperability)機能を使用してWebLogic ServerのJava EEアプリケーション・クライアント(シン・クライアント)とのステートフルな対話をサポートする場合は、アフィニティ・ベースのロード・バランシング・アルゴリズムを使用して、メソッド呼出しがサーバー・インスタンスに固定されるようにする必要があります。そうしないと、すべてのリモート呼出しが認証されます。ステートフルなCSIv2クライアントの冗長な認証を防ぐには、「ラウンドロビン・アフィニティ、重みベース・アフィニティおよびランダム・アフィニティ」で説明するロード・バランシング・アルゴリズムのいずれかを使用します

ラウンドロビン・アフィニティ、重みベース・アフィニティ、およびランダム・アフィニティ

サーバー・アフィニティを実現するWebLogic Serverの3つのロード・バランシング・アルゴリズムは次のとおりです:

  • ラウンドロビン・アフィニティ

  • 重みベース・アフィニティ

  • ランダム・アフィニティ

サーバー・アフィニティは、JMSオブジェクト、すべてのEJBホーム・インタフェース、およびステートレスEJBリモート・インタフェースを含むあらゆるタイプのRMIオブジェクトでサポートされています。

サーバー・アフィニティ・アルゴリズムでは、WebLogic Serverインスタンス間のクライアント負荷をロード・バランシングするときに外部Javaクライアントとサーバー・インスタンス間の既存の接続が尊重されます。サーバー・アフィニティは:

  • 外部Javaクライアントとサーバー・インスタンス間のロード・バランシングを無効にします

  • 外部Javaクライアントからのメソッド呼出しを接続がすでに開かれているサーバー・インスタンスに固定します(その接続で必要なプロトコルとQOSがサポートされているものと見なします)

  • 障害が発生したときには、接続がすでに開かれているサーバー・インスタンスにクライアントがフェイルオーバーされるようにします(その接続で必要なプロトコルとQOSがサポートされているものと見なします)

  • サーバー間の接続で実行されるロード・バランシングに影響しません

サーバー・アフィニティの例

次の例は、様々な環境でのサーバー・アフィニティの影響を示しています。各例で、デプロイされているオブジェクトはラウンドロビン・アフィニティ対応に構成されています。

例1: クラスタからコンテキスト取得

図5-2の例では、クライアントがクラスタからコンテキストを取得します。コンテキストのルックアップとオブジェクトの呼出しは1つの接続に固定されます。新しい初期コンテキストのリクエストは、ラウンドロビンに基づいてロード・バランシングされます。

図5-2 クラスタからコンテキストを取得するクライアント

図5-2の説明が続きます
「図5-2 クラスタからコンテキストを取得するクライアント」の説明
  1. クライアントがクラスタに新しい初期コンテキストをリクエストし(Provider_URL=clusteraddress)、MS1からコンテキストを取得します。

  2. クライアントがそのコンテキストでオブジェクトAをルックアップします。そのルックアップはMS1へ向かいます。

  3. クライアントがオブジェクトAに呼出しを発行します。その呼出しは、クライアントがすでに接続しているMS1に向かいます。オブジェクトAに対する以降のメソッド呼出しはMS1に固定されます。

  4. クライアントがクラスタに新しい初期コンテキストをリクエストし(Provider_URL=clusteraddress)、MS2からコンテキストを取得します。

  5. クライアントがそのコンテキストでオブジェクトBをルックアップします。呼出しは、クライアントがすでに接続されているMS2に向かいます。オブジェクトBに対する以降のメソッド呼出しはMS2に固定されます。

例2: サーバー・アフィニティとフェイルオーバー

図5-3の例は、サーバー・アフィニティがオブジェクトのフェイルオーバーに与える影響を示しています。管理対象サーバーがダウンすると、クライアントはそれがすでに接続している別の管理対象サーバーにフェイルオーバーします。

図5-3 サーバー・アフィニティとフェイルオーバー

図5-3の説明が続きます
「図5-3 サーバー・アフィニティとフェイルオーバー」の説明
  1. クライアントがMS1に新しい初期コンテキストをリクエストします。

  2. クライアントがそのコンテキストでオブジェクトAをルックアップします。そのルックアップはMS1へ向かいます。

  3. クライアントがオブジェクトAに呼出しを行います。その呼出しは、クライアントがすでに接続しているMS1に向かいます。オブジェクトAに対する以降の呼出しはMS1に固定されます。

  4. クライアントがMS3に固定されているオブジェクトCのスタブを取得します。クライアントはMS3との接続を開きます。

  5. MS1に障害が発生します。

  6. クライアントがオブジェクトAに呼出しを行います。クライアントはもうMS1には接続されていません。クライアントがMS3と接続されているため、MS3上のオブジェクトAのレプリカにフェイルオーバーされます。

例3: サーバー・アフィニティとサーバー間接続

図5-4の例は、サーバー・アフィニティがサーバー・インスタンス間の接続に影響しないことを示しています。

図5-4 サーバー・アフィニティとサーバー間接続

図5-4の説明が続きます
「図5-4 サーバー・アフィニティとサーバー間接続」の説明
  1. MS4上のJSPがオブジェクトBのスタブを取得します。

  2. JSPがMS1上のレプリカを選択します。メソッド呼出しごとに、JSPはオブジェクトBにアクセスできる管理対象サーバーをラウンドロビンに基づいて巡回します。

クラスタ化オブジェクトのパラメータ・ベースのルーティング

パラメータベースのルーティングを使用すると、ロード・バランシング動作をより詳細なレベルで制御できます。クラスタ化された任意のオブジェクトにCallRouterを割り当てることができます。これは、パラメータにより各呼出しの前に呼び出されるクラスです。CallRouterは、パラメータを自由に調べて、呼出しをルーティングする必要のあるネーム・サーバーを戻します。カスタムのCallRouterクラスの作成については、Oracle WebLogic Server RMIアプリケーションの開発クラスタ化オブジェクトのパラメータ・ベースのルーティングを参照してください。

連結されたオブジェクトの最適化

WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。ほとんどの場合は、リモート・サーバーにあるレプリカを使用するよりも、スタブ自体と連結しているレプリカを使用する方が効率的です。図5-5は、このことを示します。

図5-5 連結の最適化はメソッド呼出しに対してロード・バランサのロジックをオーバーライドする

図5-5の説明が続きます
「図5-5 連結の最適化はメソッド呼出しに対してロード・バランサのロジックをオーバーライドする」の説明

この例では、クライアントは、クラスタ内の最初のWebLogic Serverインスタンスにあるサーブレットに接続します。クライアントの動作に対するレスポンスとして、サーブレットはオブジェクトAのレプリカ対応スタブを取得します。オブジェクトAのレプリカは同じサーバー・インスタンス上にもあるので、そのオブジェクトはクライアントのスタブと連結していると判断されます。

WebLogic Serverでは、クラスタ内のオブジェクトAの他のレプリカにクライアントの呼出しを分散しないで、常に、ローカルにある連結されたオブジェクトAのコピーを使用します。クラスタ内の他のサーバーとのピア接続を確立するネットワーク・オーバーヘッドが避けられるので、ローカル・コピーを使用した方が効率的です。

この最適化は、WebLogic Serverクラスタの設計段階でよく見過ごされます。連結の最適化は、各メソッド呼出しでのロード・バランシングを必要としている管理者や開発者にとって混乱の元になることもよくあります。Webアプリケーションが単一のクラスタにデプロイされる場合、連結の最適化は、レプリカ対応スタブに固有のあらゆるロード・バランシング・ロジックをオーバーライドします。

クラスタ化オブジェクトに対する各メソッド呼出しのロード・バランシングが必要な場合は、そのようにWebLogic Serverクラスタを計画する方法について、「推奨複数層アーキテクチャ」を参照してください。

トランザクションの連結

基本的な連結戦略の拡張として、WebLogic Serverでは、同じトランザクションの一部として登録されている連結されたクラスタ化オブジェクトの使用も試みられます。クライアントによってUserTransactionオブジェクトが作成されると、WebLogic Serverではそのトランザクションと連結されているオブジェクトのレプリカが使用されます。図5-6は、この最適化の仕組みを表しています。

図5-6 連結の最適化がトランザクション内のその他のオブジェクトへと拡張する

図5-6の説明が続きます
「図5-6 連結の最適化がトランザクション内のその他のオブジェクトへと拡張する」の説明

この例では、クライアントがクラスタ内の最初のWebLogic Serverインスタンスに接続し、UserTransactionオブジェクトを取得します。新しいトランザクションが開始された後、クライアントはトランザクションを処理するためにオブジェクトAとオブジェクトBをルックアップします。この場合は、AおよびBのスタブによるロード・バランシングに関係なく、WebLogic Serverは、常にUserTransactionオブジェクトと同じサーバーにあるAおよびBのレプリカを使用しようとします。

このようなトランザクションの連結方式は、「連結されたオブジェクトの最適化」で説明されている基本的な最適化よりも重要です。AとBのリモート・レプリカが使用される場合は、トランザクションが終了するまでの間、余計なネットワーク・オーバーヘッドが生じることになります。なぜなら、トランザクションがコミットされるまでAとBのピア接続がロックされるからです。WebLogic Server。トランザクションの間にクラスタ化オブジェクトを連結すると、WebLogic Serverでは個々のオブジェクトにアクセスするためのネットワーク負荷が削減されます。

XAトランザクション・クラスタ・アフィニティ

XAトランザクション・クラスタ・アフィニティにより、グローバル・トランザクションに参加しているサーバー・インスタンスが、関連リクエストを他のメンバー・サーバーにロード・バランシングせずに、処理することが可能になります。Enable Transaction Affinity=trueの場合、クラスタのスループットは次の理由で高くなります。

  • サーバー間のトランザクション調整トラフィックの削減

  • JDBC接続の削減など、リソース使用率の向上

  • トランザクションの非同期処理の簡素化

クラスタ内にトランザクションに参加しているメンバーがない場合、リクエストは使用可能なクラスタ・メンバーにロード・バランシングされます。選択したクラスタ・メンバーで障害が発生した場合、「JTAトランザクション・リカバリ・サービスの自動移行を構成する手順」を使用して、JTAトランザクション・リカバリ・サービスを移行できます

クラスタの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプ「クラスタの構成」を参照してください。-Dweblogic.cluster.TxnAffinityEnabled=trueを使用して、コマンド行でXAトランザクション・アフィニティを有効にすることも可能です。

JMSのロード・バランシング

WebLogic Server JMSでは、分散JMS宛先およびクライアント接続のサーバー・アフィニティがサポートされています。

デフォルトのWebLogic Serverクラスタでは、ラウンドロビンでオブジェクトのロード・バランシングが行われます。JMSオブジェクトのサーバー・アフィニティを実現するロード・バランシング・アルゴリズムを使用するには、クラスタ全体に対して目的の方法を構成する必要があります。ロード・バランシング・アルゴリズムを構成するには、WebLogic Server管理コンソールを使用してweblogic.cluster.defaultLoadAlgorithmを設定します。手順については、「EJBとRMIのロード・バランシング方式を構成する」 を参照してください

分散JMS宛先のサーバー・アフィニティ

サーバー・アフィニティは、分散宛先機能を使用するJMSアプリケーションでサポートされています。この機能は、スタンドアロンの宛先ではサポートされていません。JMS接続ファクトリのサーバー・アフィニティを構成した場合、分散宛先の複数のメンバー間でコンシューマまたはプロデューサをロード・バランシングしているサーバー・インスタンスはまず、同じサーバー・インスタンスで動作しているすべての宛先メンバー間でロード・バランシングを試みます。

JMS接続ファクトリの「サーバー・アフィニティの有効化」オプションが分散宛先メンバーのロード・バランシングのプリファレンスに与える影響の詳細は、Oracle WebLogic Server JMSリソースの管理サーバー・アフィニティの有効化属性を使用した分散宛先ロード・バランシングへの影響を参照してください。

クライアント接続の初期コンテキスト・アフィニティとサーバー・アフィニティ

システム管理者は、複数のJMSサーバーを構成し、ターゲットを使用してそれらを定義済のWebLogic Serverに割り当てることで、クラスタ内の複数のJMSサーバー間での宛先のロード・バランシングを確立できます。各JMSサーバーは、厳密に1つのWebLogic Serverにデプロイされ、宛先の集合に対するリクエストを処理します。構成の段階で、システム管理者がJMSサーバーのターゲットを指定してロード・バランシングを有効にします。ターゲットの設定手順については、「固定サービスの移行可能ターゲットを構成する」を参照してくださいJMSサーバーを移行可能ターゲットにデプロイする手順については、「移行可能サービスをデプロイ、アクティブ化、および移行する」を参照してください

システム管理者は、複数の接続ファクトリを構成し、ターゲットを使用してそれらをWebLogic Serverに割り当てることで、クラスタ内のあらゆるサーバーから宛先へのクラスタ全体にわたる透過的なアクセスを確立できます。各接続ファクトリを複数のWebLogic Server上でデプロイできます。接続ファクトリの詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』「ConnectionFactory」を参照してください。

アプリケーションでは、JNDIを使用して接続ファクトリをルックアップし、JMSサーバーとの通信を確立するための接続を作成します。各JMSサーバーでは、複数の宛先に対するリクエストが処理されます。JMSサーバーによって処理されない宛先に対してのリクエストは、適切なサーバーに転送されます。

WebLogic Serverでは、クライアント接続のサーバー・アフィニティが提供されています。アプリケーションが特定のサーバー・インスタンスと接続されている場合、JMSは同じサーバー・インスタンスと新しいJMS接続を確立しようとします。

接続の作成時に、JMSはまず初期コンテキスト・アフィニティの実現を試みます。クライアントが初期コンテキストを取得するために接続した同じサーバーに接続しようとします。その際、サーバー・インスタンスが接続ファクトリで構成されているものと仮定します。たとえば、接続ファクトリがサーバーAおよびBに対して構成されているが、クライアントはサーバーCのInitialContextを持っている場合、接続ファクトリはAとの新しい接続は確立しませんが、サーバーBとCから選択します。

接続ファクトリが初期コンテキスト・アフィニティを実現できない場合は、クライアントがすでに接続しているサーバーとのアフィニティを提供しようとします。たとえば、クライアントがサーバーAの初期コンテキストを持ち、サーバーBとの他の種類の接続を確立しているとします。クライアントがサーバーBおよびCに対して構成された接続ファクトリを使用する場合、初期コンテキスト・アフィニティは実現されません。接続ファクトリは代わりに、サーバーCではなく、すでに接続されているサーバーBとの接続を作成してサーバー・アフィニティを実現しようとします。

接続ファクトリが初期コンテキスト・アフィニティまたはサーバー・アフィニティを提供できない場合、接続ファクトリは可能な限り自由に接続を行うことができます。たとえば、クライアントがサーバーAの初期コンテキストを持ち、他の接続はなく、サーバーBおよびCに対して接続ファクトリが構成されているものとします。接続ファクトリはいかなるアフィニティも提供することができず、サーバーBまたはCのいずれかと新しい接続を自由に確立することができます。

ノート:

最後のケースで、クライアントが同じ接続ファクトリを使用して2回目の接続を行おうとすると、初回と同じサーバーに接続されます。つまり、最初の接続にサーバーBを選択している場合、2回目の接続を行うと、クライアントはサーバーBと接続され、サーバー・アフィニティ・ルールが施行されます。