| Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの使用 12cリリース1(12.1.1) B65915-02 |
|
 前 |
 次 |
この章では、各種のオブジェクトを対象としたWebLogic Serverクラスタでのロード・バランシングのサポートについて説明し、設計者および管理者向けに、ロード・バランシングに関連する計画および構成上の考慮事項を示します。
この章の内容は以下のとおりです。
クラスタのレプリケーションとフェイルオーバーについては、「クラスタのフェイルオーバーとレプリケーション」を参照してください。
サーブレットとJSPのロード・バランシングは、WebLogicプロキシ・プラグインに組み込まれたロード・バランシング機能を使用するか、またはロード・バランシング・ハードウェアを別途用意することによって実現できます。
|
注意: HTTPトラフィックの分散に加えて、外部ロード・バランサは、 |
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へのプロキシ経由のアクセス」を参照してください。
ハードウェアによるロード・バランシング・ソリューションを利用するクラスタでは、ハードウェアが対応しているすべてのロード・バランシング・アルゴリズムを利用できます。この中には、個々のマシンの利用状況をモニターする負荷ベースの高度な調整方式を採用しているものもあります。
プロキシ・プラグインではなくロード・バランシング・ハードウェアを使用する場合、互換性のあるパッシブまたはアクティブな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を使用して、クライアントとクラスタ内の特定サーバー間の関連付けを維持します。
パッシブなCookieの永続性を使用するロード・バランサは、WebLogicセッションCookieに文字列を使用することで、クライアントをそのプライマリHTTPセッション状態のホストになるサーバーに関連付けることができます。文字列は、クラスタ内のサーバー・インスタンスを一意に識別します。ロード・バランサを構成する際に、文字列定数のオフセットと長さを指定する必要があります。オフセットと長さの正しい値は、セッションCookieの形式によって異なります。
セッションCookieの形式は次のとおりです。
sessionid!primary_server_id!secondary_server_id
説明:
sessionidは、HTTPセッションの識別子で、ランダムに生成されます。値の長さは、アプリケーションのweblogic.xmlファイルの<session-descriptor要素にあるIDLengthパラメータで構成されます。デフォルトでは、sessionidの長さは52バイトです。
primary_server_idとsecondary_server_idは、セッションのプライマリ・ホストとセカンダリ・ホストの10文字の識別子です。
|
注意: 非レプリケート・メモリー、Cookieまたはファイル・ベースのセッション永続性を使用するセッションの場合、 |
ロード・バランサの一般的な構成手順については、「パッシブなCookieの永続性をサポートするロード・バランサを構成する」を参照してください。BIG-IPの構成手順については、「クラスタに関するBIG-IPハードウェアの構成」を参照してください。
クラスタ化されるサーブレットおよびJSPを対象とした、プログラミング上の制約および考慮事項については、「クラスタ化されるサーブレットおよびJSPのプログラミング上の考慮事項」を参照してください。
ロード・バランシング・ハードウェアによるクラスタ内のHTTPセッションの接続およびフェイルオーバーの詳細は、「クラスタ化されたサーブレットとJSPへのロード・バランシング・ハードウェアを利用したアクセス」を参照してください。
次の項では、EJBとRMIオブジェクトの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を使用し、セッションIDに基づいてリクエストの適切なルーティングを可能にするためのセッション・ベースのルーティングを実行するロード・バランサでは、SSLを終了する必要があります。
WebLogic Serverは、特定のアルゴリズムが指定されていない場合には、クラスタ化オブジェクト・スタブのロード・バランシング方式としてデフォルトでラウンドロビン・アルゴリズムを使用します。このアルゴリズムは、RMIオブジェクトおよびEJB用にサポートされています。また、WebLogicプロキシ・プラグインで使用される手法でもあります。
このアルゴリズムは、WebLogic Serverインスタンスのリストを順番に循環します。クラスタ化オブジェクトの場合、サーバー・リストはそのオブジェクトのホストとなるWebLogic Serverインスタンスからなります。プロキシ・プラグインの場合、リストは、クラスタ化されたサーブレットまたはJSPのホストとなるすべてのWebLogic Serverインスタンスからなります。
ラウンドロビン・アルゴリズムの長所は、シンプルで、動作コストの面で有利で、非常に予測しやすいということです。主な短所は、コンボイの可能性が若干あることです。コンボイは、あるサーバーがその他のサーバーよりも著しく速度が低下したときに発生します。レプリカ対応スタブまたはプロキシは同じ順序でサーバーにアクセスするので、速度の遅いサーバーがあると、リクエストがそのサーバー上で「同期」するため、その他のサーバーが将来のリクエストに備えて停滞する可能性があります。
このアルゴリズムは、EJBおよびRMIオブジェクトのクラスタリングだけに適用されます。
重みベース・ロード・バランシングは、ラウンドロビンアルゴリズムを向上させたもので、各サーバーにあらかじめ割り当てられた重みを考慮します。管理コンソールの「サーバー」>「構成」>「クラスタ」ページを使用して、「クラスタの重み」フィールドで1から100の数値を設定してクラスタ内の各サーバーに重みを割り当てることができます。この値は、他のサーバーとの比較で、あるサーバーにかかる負荷の割合を決定します。すべてのサーバーの重みが同じ場合、各サーバーには等しい割合の負荷がかかります。1つのサーバーの重みが50で、他のすべてのサーバーの重みは100の場合、重み50があるサーバーに他のサーバーにかかる負荷の半分の負荷がかかります。このアルゴリズムを使用すると、均一でないクラスタにラウンドロビン・アルゴリズムの利点をもたらすことができます。
重みベースのアルゴリズムを使用する場合、各サーバー・インスタンスに割り当てる相対的な重みを慎重に決定してください。考慮すべき要因には、次のものがあります。
他のサーバーと比較したサーバーのハードウェアの処理能力(WebLogic Server専用のCPUの数と性能など)
各サーバーをホストとする、クラスタ化されていない(「固定された」)オブジェクトの数
サーバーに指定した重みを変更してサーバーを再起動すると、レプリカ対応スタブ経由で新しい重みの情報がクラスタ全体に伝播されます。詳細は、「クラスタ全体のJNDIネーミング・サービス」を参照してください。
|
注意: WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。詳細は、「連結されたオブジェクトの最適化」を参照してください。 このバージョンのWebLogic Serverでは、RMI/IIOPプロトコルを使用して通信するオブジェクトに対して、重みベースのロード・バランシングはサポートされていません。 |
ランダム方式のロード・バランシングは、EJBおよびRMIオブジェクトのクラスタリングにのみ適用されます。
ランダム・ロード・バランシングでは、リクエストは無作為にサーバーに振り分けられます。ランダム・ロード・バランシングは、同様の構成がなされたマシン上で各サーバー・インスタンスが動作する、均一なクラスタ・デプロイメント環境でのみ推奨されます。リクエストを無作為に割り当てる方式では、サーバー・インスタンスが動作するマシン間で処理能力に差があることは問題となります。クラスタ内でサーバーをホストしているマシンの処理能力が、クラスタ内の他のマシンよりも著しく劣っているような場合、ランダム・ロード・バランシングによって、より強力なマシンに割り当てられるのと同じ分量のリクエストが能力の低いマシンに割り当てられてしまいます。
ランダム・ロード・バランシングでは、クラスタ内のサーバー・インスタンス間で均等にリクエストが分配され、累計のリクエスト数の増加とともに個別の分配量も増します。リクエストの数が少ない場合、負荷は厳密には均等に配分されない場合があります。
ランダム・ロード・バランシングの欠点としては、リクエストごとにランダムな番号を生成するため、プロセスに多少のオーバーヘッドが発生するということがあります。また、リクエストの数が少ない場合は、負荷が均等に分散されない可能性もあります。
WebLogic Serverでは、サーバー・アフィニティを実現する、RMIオブジェクトの新しい3つのロード・バランシング・アルゴリズムが提供されています。サーバー・アフィニティは外部クライアント接続のロード・バランシングを無効にしますが、そのかわりに、クライアント側でオブジェクトにアクセスするサーバー・インスタンスを選択するときにWebLogic Serverインスタンスとの既存の接続が尊重されます。オブジェクトがサーバー・アフィニティ対応に構成されている場合、クライアント側スタブではすでに接続されているサーバー・インスタンスを選択しようとし、メソッド呼出しに同じサーバー・インスタンスを使い続けます。そのクライアントのすべてのスタブが同じサーバー・インスタンスを使用しようとします。そのサーバー・インスタンスが利用不可になると、スタブはクライアントがすでに接続しているサーバー・インスタンスに可能であればフェイルオーバーします。
サーバー・アフィニティの目的は、外部Javaクライアントとクラスタ内のサーバー・インスタンスの間で開かれるIPソケットの数を最小限に抑えることです。WebLogic Serverはそのために、利用可能なサーバー・インスタンスの間でロード・バランシングを行うのではなく、オブジェクトに対するメソッド呼出しを既存の接続に「固定」します。サーバー・アフィニティ・アルゴリズムを使用する場合でも、低コストのサーバー間接続は構成されているロード・バランシング・アルゴリズムに従ってロード・バランシングされます。ロード・バランシングが無効になるのは、外部クライアント接続だけです。
サーバー・アフィニティは、標準のロード・バランシング方法(ラウンドロビン、重みベース、ランダム)のいずれか1つと組み合わせて使用されます。
ラウンドロビン・アフィニティ - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理します。ラウンドロビン・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。
重みベース・アフィニティ - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、重みベース・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。
ランダム・アフィニティ - サーバー・アフィニティが外部Javaクライアントとサーバー・インスタンスの接続を管理し、ランダム・ロード・バランシングがサーバー・インスタンス間の接続に使用されます。
クライアントは、クラスタ内の特定のサーバー・インスタンスまたはクラスタ(URLでクラスタのアドレスを指定)から初期コンテキストを取得できます。接続プロセスは、コンテキストの取得方法によって異なります。
初期コンテキストを特定の管理対象サーバーからリクエストする場合、コンテキストは指定されたサーバー・インスタンスとの新しい接続を使用して取得されます。
初期コンテキストをクラスタから取得する場合、デフォルトで、コンテキスト・リクエストはクラスタ化サーバー・インスタンスの間でラウンドロビンに基づいてロード・バランシングされます。特定のJVMとクラスタ間の既存の接続を再利用するには、コンテキストを取得するときに指定するweblogic.jndi.WLContextプロパティのハッシュ表でENABLE_SERVER_AFFINITYをtrueに設定します。利用可能な接続がない場合は、新しい接続が作成されます。ENABLE_SERVER_AFFINITYは、コンテキストをクラスタのアドレスから取得する場合のみサポートされています。
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-1の例では、クライアントがクラスタからコンテキストを取得します。コンテキストのルックアップとオブジェクトの呼出しは1つの接続に固定されます。新しい初期コンテキストのリクエストは、ラウンドロビンに基づいてロード・バランシングされます。
クライアントがクラスタに新しい初期コンテキストをリクエストし(Provider_URL=clusteraddress)、MS1からコンテキストを取得します。
クライアントがそのコンテキストでオブジェクトAをルックアップします。そのルックアップはMS1へ向かいます。
クライアントがオブジェクトAに呼出しを発行します。その呼出しは、クライアントがすでに接続しているMS1に向かいます。オブジェクトAに対する以降のメソッド呼出しはMS1に固定されます。
クライアントがクラスタに新しい初期コンテキストをリクエストし(Provider_URL=clusteraddress)、MS2からコンテキストを取得します。
クライアントがそのコンテキストでオブジェクトBをルックアップします。呼出しは、クライアントがすでに接続されているMS2に向かいます。オブジェクトBに対する以降のメソッド呼出しはMS2に固定されます。
例2 - サーバー・アフィニティとフェイルオーバー
図5-2の例は、サーバー・アフィニティがオブジェクトのフェイルオーバーに与える影響を示しています。管理対象サーバーがダウンすると、クライアントはそれがすでに接続している別の管理対象サーバーにフェイルオーバーします。
クライアントがMS1に新しい初期コンテキストをリクエストします。
クライアントがそのコンテキストでオブジェクトAをルックアップします。そのルックアップはMS1へ向かいます。
クライアントがオブジェクトAに呼出しを行います。その呼出しは、クライアントがすでに接続しているMS1に向かいます。オブジェクトAに対する以降の呼出しはMS1に固定されます。
クライアントがMS3に固定されているオブジェクトCのスタブを取得します。クライアントはMS3との接続を開きます。
MS1に障害が発生します。
クライアントがオブジェクトAに対して呼出しを行います。クライアントはもはやMS1への接続を保持していません。クライアントがMS3と接続されているため、MS3上のオブジェクトAのレプリカにフェイルオーバーされます。
例3 - サーバー・アフィニティとサーバー間接続
図5-3の例は、サーバー・アフィニティがサーバー・インスタンス間の接続に影響しないことを示しています。
MS4上のJSPがオブジェクトBのスタブを取得します。
JSPがMS1上のレプリカを選択します。メソッド呼出しごとに、JSPはオブジェクトBにアクセスできる管理対象サーバーをラウンドロビンに基づいて巡回します。
パラメータベースのルーティングを使用すると、ロード・バランシング動作をより詳細なレベルで制御できます。クラスタ化された任意のオブジェクトにCallRouterを割り当てることができます。これは、パラメータにより各呼出しの前に呼び出されるクラスです。CallRouterは、パラメータを自由に調べて、呼出しをルーティングする必要のあるネーム・サーバーを戻します。カスタムCallRouterクラスの作成の詳細は、『Oracle WebLogic Server RMIのプログラミング』のクラスタ化オブジェクトのパラメータベースのルーティングに関する項を参照してください。
WebLogic Serverでは、オブジェクトのメソッド呼出しに対して常にロード・バランシングが実行されるわけではありません。ほとんどの場合は、リモート・サーバーにあるレプリカを使用するよりも、スタブ自体と連結しているレプリカを使用する方が効率的です。図5-4は、このことを示します。
この例では、クライアントは、クラスタ内の最初のWebLogic Serverインスタンスにあるサーブレットに接続します。クライアントの動作に対するレスポンスとして、サーブレットはオブジェクトAのレプリカ対応スタブを取得します。オブジェクトAのレプリカは同じサーバー・インスタンス上にもあるので、そのオブジェクトはクライアントのスタブと連結していると判断されます。
WebLogic Serverでは、クラスタ内のオブジェクトAの他のレプリカにクライアントの呼出しを分散しないで、常に、ローカルにある連結されたオブジェクトAのコピーを使用します。クラスタ内の他のサーバーとのピア接続を確立するネットワーク・オーバーヘッドが避けられるので、ローカル・コピーを使用した方が効率的です。
この最適化は、WebLogic Serverクラスタの設計段階でよく見過ごされます。連結の最適化は、各メソッド呼出しでのロード・バランシングを必要としている管理者や開発者にとって混乱の元になることもよくあります。Webアプリケーションが単一のクラスタにデプロイされる場合、連結の最適化は、レプリカ対応スタブに固有のどのロード・バランシング・ロジックよりも優先されます。
クラスタ化オブジェクトに対する各メソッド呼出しでロード・バランシングが必要な場合、そのようにWebLogic Serverクラスタを設計する方法については、「推奨複数層アーキテクチャ」を参照してください。
基本的な連結方式の拡張として、WebLogic Serverでは、同じトランザクションの一部として登録されている連結されたクラスタ化オブジェクトの使用も試みられます。クライアントによってUserTransactionオブジェクトが作成されると、WebLogic Serverではそのトランザクションと連結されているオブジェクトのレプリカが使用されます。図5-5は、この最適化の仕組みを表しています。
この例では、クライアントがクラスタ内の最初のWebLogic Serverインスタンスに接続し、UserTransactionオブジェクトを取得します。新しいトランザクションが開始された後、クライアントはトランザクションを処理するためにオブジェクトAとオブジェクトBをルックアップします。この場合は、AおよびBのスタブによるロード・バランシングに関係なく、WebLogic Serverは、常にUserTransactionオブジェクトと同じサーバーにあるAおよびBのレプリカを使用しようとします。
このようなトランザクションの連結方式は、「連結されたオブジェクトの最適化」で説明されている基本的な最適化よりも重要です。AとBのリモート・レプリカが使用される場合は、トランザクションが終了するまでの間、余計なネットワーク・オーバーヘッドが生じることになります。なぜなら、トランザクションがコミットされるまでAとBのピア接続がロックされるからです。トランザクションの間にクラスタ化オブジェクトを連結すると、WebLogic Serverでは個々のオブジェクトにアクセスするためのネットワーク負荷が削減されます。
WebLogic Server JMSでは、分散JMS宛先およびクライアント接続のサーバー・アフィニティがサポートされています。
デフォルトのWebLogic Serverクラスタでは、ラウンドロビンでオブジェクトのロード・バランシングが行われます。JMSオブジェクトのサーバー・アフィニティを実現するロード・バランシング・アルゴリズムを使用するには、クラスタ全体に対して目的の方法を構成する必要があります。ロード・バランシング・アルゴリズムを構成するには、管理コンソールを使用してweblogic.cluster.defaultLoadAlgorithmを設定します。手順については、「EJBとRMIのロード・バランシング方式を構成する」を参照してください。
|
注意: JMSおよびJTAの固定サービスのフェイルオーバーに対して永続ストアを提供するために、VERITAS Cluster Serverなどの高可用性クラスタリング・ソフトウェアを使用できます。このソフトウェアは、WebLogic Serverベースのアプリケーション用のすぐ使用できる統合ソリューションを提供します。推奨される高可用性ソフトウェア・ソリューションには、上記の他にも、SunClusterやIBM HACMPなどがあります。 |
サーバー・アフィニティは、分散宛先機能を使用する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に関する項を参照してください。
アプリケーションでは、Java Naming and Directory Interface (JNDI)を使用して接続ファクトリをルックアップし、JMSサーバーとの通信を確立するための接続を作成します。各JMSサーバーでは、複数の宛先に対するリクエストが処理されます。JMSサーバーによって処理されない宛先に対してのリクエストは、適切なサーバーに転送されます。
WebLogic Serverでは、クライアント接続のサーバー・アフィニティが提供されています。アプリケーションが特定のサーバー・インスタンスと接続されている場合、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と接続され、サーバー・アフィニティ・ルールが施行されます。 |
