| Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの使用 11g リリース1 (10.3.6) B60992-05 |
|
 前 |
 次 |
この章では、WebLogic Serverクラスタの2つの主要機能であるロード・バランシングとフェイルオーバーが実装される仕組みについて説明します。次の項では、設計者と管理者が、特定のWebアプリケーションに適したクラスタを構成するために役立つ情報を示します。
クラスタ内のWebLogic Serverインスタンスは、2つの基本的なネットワーク技術を利用して互いに通信します。
IPソケット - クラスタ化サーバー・インスタンス間でピア・ツー・ピア通信を行うための導管として機能します。
IPユニキャストまたはマルチキャスト - サーバー・インスタンスが、サービスの可用性と、継続的な可用性を示すハートビートをブロードキャストするために使用します。
新しいクラスタを作成する際は、クラスタ内のメッセージングにユニキャストを使用することをお薦めします。
|
注意: 構成ウィザードを使用してクラスタを作成するとき、デフォルトのクラスタ・メッセージング・モードはユニキャストです。WLSTを使用してクラスタを作成するとき、デフォルトのクラスタ・メッセージング・モードはマルチキャストです。 ユニキャスト・メッセージングのクラスタのためにJNDIツリーを更新するときに問題が発生した場合、新規プロパティ
詳細は、『Oracle Fusion Middlewareリリース・ノート』のユニキャスト・メッセージを順序とおりに処理させるための強制に関する項を参照してください。このプロパティではユニキャスト・メッセージングに関する問題を解決しない場合、マルチキャスト・メッセージング・モードに切替えます。 |
WebLogic ServerでのIPマルチキャストまたはユニキャスト、およびソケット通信の使用形態は、クラスタをどのように構成するかに影響します。
IPマルチキャストは、複数のアプリケーションが指定されたIPアドレスとポート番号を「サブスクライブ」して、メッセージをリスニングできるようにする単純なブロードキャスト技術です。
|
注意: 新しいクラスタを作成する際は、クラスタ内のメッセージングにユニキャストを使用することをお薦めします。WebLogic Server 9.2以前のバージョンでは、クラスタ間の通信にマルチキャストを使用する必要があります。 |
IPマルチキャストはアプリケーションに対してメッセージをブロードキャストしますが、メッセージが実際に届くことは保証されていません。アプリケーションのローカル・マルチキャスト・バッファがいっぱいの場合、新規のマルチキャスト・メッセージをそのバッファに書込めないので、アプリケーションにはメッセージが「届いた」ことがわかりません。この制約のため、WebLogic Serverインスタンスでは、IPマルチキャストに対してブロードキャストされたメッセージが届かない可能性を考慮しています。
|
注意: マルチキャスト・アドレスは、範囲が224.0.0.0 - 239.255.255.255のIPアドレスです。WebLogic Serverで使用されるデフォルトのマルチキャスト・アドレスは、239.192.0.0です。x.0.0.1の範囲内のマルチキャスト・アドレスを使用することはできません。 |
WebLogic Serverは、クラスタ内のサーバー・インスタンス間の1対多通信でIPマルチキャストを使用します。この通信には次が含まれます。
クラスタ全体のJNDIの更新 - クラスタ内の個々のWebLogic Serverインスタンスはマルチキャストを使用して、ローカルでデプロイされたり、削除されたりしたクラスタ化オブジェクトが使用可能かどうかを通知します。クラスタ内の各サーバー・インスタンスはこれらの通知をモニターし、クラスタ化されるオブジェクトの最新のデプロイメント状況に合わせてインスタンスのローカルJNDIツリーを更新します。詳細は、「クラスタ全体のJNDIネーミング・サービス」を参照してください。
クラスタの「ハートビート」 - WebLogic Serverは、マルチキャストを使用して、クラスタ内の個々のサーバー・インスタンスが使用可能であることを通知するために、定期的に「ハートビート」メッセージをブロードキャストします。クラスタ内のサーバー・インスタンスは、ハートビート・メッセージをモニターすることにより、どの時点でサーバー・インスタンスに障害が発生したかを特定します。(クラスタ化サーバー・インスタンスは、サーバー・インスタンスで障害が発生した時点を特定するためのより直接的な手段として、IPソケットのモニターも行います)。
複数のノードがあるクラスタ - 複数のノードがあるクラスタでは、オプションでマルチキャスト通信を使用できます。
マルチキャスト通信は、(「クラスタ全体のJNDIネーミング・サービス」で説明するように)障害の検出とクラスタ全体のJNDIツリーの保守に関わる重要な機能を制御するので、クラスタの構成もマルチキャスト通信とのネットワーク・トポロジ・インタフェースも重要ではありません。次の項では、クラスタ内でのマルチキャスト通信に伴う問題を回避するためのガイドラインを示します。
多くのデプロイメント構成で、クラスタ化されるサーバー・インスタンス群は単一のサブネットの内部に置かれます。これは、マルチキャスト・メッセージの確実な転送を保証するための構成です。ただし必要に応じて、ワイド・エリア・ネットワーク(WAN)内の複数のサブネット間にWebLogic Serverクラスタを分散させて冗長性を確保したり、あるいはクラスタ化されるサーバー・インスタンスをより広範な地理的領域に分散させることができます。
クラスタをWAN (または複数のサブネット)上に分散する場合、マルチキャスト・メッセージがクラスタ内のすべてのサーバー・インスタンスに必ず転送されるようにネットワーク・トポロジを計画および構成します。特に、ネットワークが次の要件を満たす必要があります。
IPマルチキャスト・パケットの伝播の完全サポート。つまり、すべてのルーターおよびその他のトンネリング技術がマルチキャスト・メッセージをクラスタ化されているサーバー・インスタンスに伝播するように構成されている必要があります。
大半のマルチキャスト・メッセージがその最終的な宛先に200から300ミリ秒以内に到達することを保証する、低いネットワーク・レイテンシ。
マルチキャスト・パケットが最終的な宛先に届くまでにルーターがパケットを破棄しないことを保証する、クラスタのマルチキャストTTL (Time-To-Live: 存続時間)の高い値。マルチキャストTTLパラメータの設定手順については、「マルチキャスト存続時間(TTL)を構成する」を参照してください。
|
注意: WAN上にWebLogic Serverクラスタを分散するには、上記のマルチキャスト要件を満たす以外にも、ネットワーク機能を追加しなければならない場合があります。たとえば、不要なネットワーク・ホップを経由せずにクライアント・リクエストを最短経路でサーバー・インスタンスに送るには、ロード・バランシング・ハードウェアを構成する必要があります。 |
マルチキャスト・トラフィックをファイアウォール内にトンネリングすることは可能ですが、WebLogic Serverクラスタではお薦めしません。個々のWebLogic Serverクラスタは、Webアプリケーションのクライアントに対して1つまたは複数の別個のサービスを提供する論理単位として扱うようにします。複数の異なったセキュリティ・ゾーン間にこの論理単位を分割しないでください。さらに、IPトラフィックの速度低下や中断につながる可能性のある技術は、ハートビートの不達が誤って障害として判断されることによって、WebLogic Serverクラスタを分断させることがあります。
複数のWebLogic Serverクラスタは単一のIPマルチキャスト・アドレスおよびポートを共有できますが、クラスタによって使用されているマルチキャスト・アドレスおよびポートは、他のアプリケーションでブロードキャストまたはサブスクライブしないでください。つまり、クラスタのホストとなっている1台または複数台のマシンが、マルチキャスト通信を使用する他のアプリケーションのホストも兼ねている場合、それらのアプリケーションでは必ず、クラスタが使用しているものと異なるマルチキャスト・アドレスおよびポートを使用してください。
クラスタのマルチキャスト・アドレスを他のアプリケーションと共有すると、クラスタ化サーバー・インスタンスは不必要なメッセージを処理しなければならなくなり、オーバーヘッドが増します。また、マルチキャスト・アドレスの共有は、IPマルチキャスト・バッファの過負荷と、WebLogic Serverハートビート・メッセージの送信遅延につながる可能性があります。ハートビートが適切なタイミングで受信されないため、こうした遅延によって、WebLogic Serverインスタンスがエラーとしてマークされる可能性があります。
こうした理由から、WebLogic Serverクラスタ用には専用のマルチキャスト・アドレスを割り当てて、そのアドレスを使用するすべてのクラスタのトラフィックをそのアドレスでブロードキャストできるようにします。
クラスタ内のサーバー・インスタンスで受信メッセージが適時に処理されない場合は、否定応答(NAK)メッセージやハートビートの再送信を含むネットワーク・トラフィックが増大します。ネットワーク上でマルチキャスト・パケットが繰り返し送信されることは、マルチキャスト・ストームと呼ばれ、それが発生するとネットワークとそのネットワークに接続されたステーションに負荷がかかり、エンドステーションでハングまたは障害が発生する可能性があります。マルチキャスト・バッファのサイズを増やすと、通知が送信および受信されるレートが改善されて、マルチキャスト・ストームを防止できます。「マルチキャスト・バッファのサイズを構成する」を参照してください。
WebLogic Serverでは、マルチキャスト以外の方法でクラスタのメッセージングおよび通信を処理することもできます。ユニキャストは、マルチキャストのようなネットワーク間構成を必要としない単純な構成です。加えて、マルチキャスト・アドレスの競合によって発生する可能性がある潜在的なネットワーク・エラーが低減されます。
ユニキャストはClusterMBean.isUnicastBasedClusterMessagingEnabled()を使用して構成します。このパラメータのデフォルト値はfalseです。このMBeanへの変更は動的には反映されません。変更を有効にするには、クラスタを再起動する必要があります。
特定のチャネルでのユニキャスト通信を定義する場合は、setNetworkChannelForUnicastMessaging(String NetworkChannelName)を使用します。ユニキャストを有効にすると、このBeanに定義した値に基づいてクラスタ間の通信が試行されます。ユニキャスト・チャネルが明示的に定義されていない場合は、デフォルトのネットワーク・チャネルが使用されます。
WebLogic Serverクラスタでユニキャスト通信を構成する場合は、サーバーが異なるマシンで実行している場合、それらのマシンのリスニング・アドレスまたはDNS名を明示的に指定する必要があります。
ユニキャストを使用してクラスタ通信を処理する場合は、次の点を考慮に入れてください。
クラスタのすべてのメンバーで同じメッセージ・タイプを使用する必要があります。メッセージングとしてマルチキャストとユニキャストを混在させることはできません。
クラスタ内で以前のバージョンのWebLogic Serverをサポートするには、マルチキャストを使用する必要があります。
個別のクラスタ・メンバーで、クラスタのメッセージング・タイプをオーバーライドすることはできません。
クラスタ全体を停止して、メッセージ・モードで再起動する必要があります。
JMSトピックは、クラスタ・アドレスに依存しない独自のマルチキャスト・アドレスに対してメッセージをパブリッシュするので、マルチキャスト向けに構成されたJMSトピックでもユニキャスト向けに構成されたWebLogicクラスタにアクセスできます。ただし、次の点を考慮に入れてください。
クラスタのユニキャスト通信を可能にするルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能しない場合があります。
JMSマルチキャスト・サブスクライバは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成を必要とします。
詳細は、『Oracle WebLogic Server JMSのプログラミング』のWebLogic JMSでのマルチキャストの使用に関する項を参照してください。
IPソケットは、2つのアプリケーション間でメッセージおよびデータを転送するための、シンプルでパフォーマンスの高いメカニズムです。クラスタ化されるWebLogic Serverインスタンスは、次の目的でIPソケットを使用します。
別のマシンでクラスタ化されている別のサーバー・インスタンスにデプロイされた、クラスタ化されていないオブジェクトへのアクセス。
HTTPセッション状態とステートフル・セッションEJBの状態の、プライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンス間でのレプリケーション。
リモート・サーバー・インスタンス上にあるクラスタ化オブジェクトへのアクセス。(これは一般に、「推奨複数層アーキテクチャ」で説明するような複数層クラスタ・アーキテクチャでのみ発生します。)
|
注意: WebLogic ServerでのIPソケットの使い方はクラスタ関連にとどまらず、たとえば、Javaクライアント・アプリケーションがリモート・オブジェクトにアクセスする場合など、すべてのRMI通信がソケットを使って行われます。 |
WebLogic Serverクラスタのパフォーマンスは、ソケットの構成によって大きく左右されます。WebLogic Serverでのソケット通信の効率は、次の2つの要因によって決まります。
サーバー・インスタンスのホスト・システムではネイティブ・ソケット・リーダー実装とpure-Javaソケット・リーダー実装のどちらを使用しているか
pure-Javaソケット・リーダーを使用しているシステムの場合は、サーバー・インスタンスが十分な数のソケット・リーダー・スレッドに対応するよう構成されているかどうか
ソケット・リーダー・スレッドのpure-Java実装は、ピア・ツー・ピア通信を行うための信頼性が高く移植可能な方法ですが、ソケットに大きな負荷がかかるWebLogic Serverクラスタで使用する場合には、最適なパフォーマンスを提供できません。pure-Javaソケット・リーダーを使用すると、スレッドは、ソケットにデータが入っているかどうかを調べるために、オープンしているソケットにポーリングする必要があります。つまり、ソケット・リーダー・スレッドはソケットのポーリングで常に「ビジー」となります。これはソケットがデータを持っていない場合でも変わりません。この不必要なオーバーヘッドにより、パフォーマンスが低下する可能性があります。
パフォーマンスの問題は、サーバー・インスタンスがソケット・リーダー・スレッドよりも多くのオープン・ソケットを持つとき(各リーダー・スレッドが複数のオープン・ソケットをポーリングしなければならないとき)に顕著になります。ソケット・リーダーはアクティブでないソケットに遭遇すると、別のソケットにサービスを提供する前にタイムアウトを待ちます。このタイムアウト待ちの間、図3-1に示すように、アクティブでないソケットをソケット・リーダーがポーリングする一方で、アクティブなソケットが未読のままになる場合があります。
図3-1 pure-Javaソケット・リーダー・スレッドがアクティブでないソケットをポーリングする
ソケットの最適なパフォーマンスを実現するには、pure-Java実装ではなく、オペレーティング・システムに対応したネイティブ・ソケット・リーダー実装を使用するようWebLogic Serverホスト・マシンを構成します。ネイティブ・ソケット・リーダーは、ソケット上のデータの有無を非常に効率的な手法で調べます。ネイティブ・ソケット・リーダー実装では、リーダー・スレッドはネイティブ・ソケットをポーリングする必要がなく、アクティブなソケットに対してだけサービスとして、特定のソケットがアクティブになった場合には、(割込みによって)直ちに通知されます。
|
注意: アプレットはネイティブ・ソケット・リーダー実装を使用できないので、ソケット通信では十分な効果が出ません。 |
オペレーティング・システムに対応したネイティブ・ソケット・リーダーの実装を使用するようにWebLogic Serverホスト・マシンを構成する方法については、「サーバー・インスタンスのホスト・マシン上でネイティブのIPソケット・リーダーを構成する」を参照してください。
pure-Javaソケット・リーダー実装を使用する場合は、サーバー・インスタンスごとにソケット・リーダー・スレッドの数を適切に構成することで、ソケット通信のパフォーマンスを向上できます。最適なパフォーマンスを実現するには、WebLogic Serverでのソケット・リーダー・スレッドの数を、同時にオープンするソケットの最大数に合わせる必要があります。この構成により、リーダー・スレッドが複数のソケットにサービスしなければならない状況が回避され、ソケット・データの即時読取りが保証されます。
クラスタ内のサーバー・インスタンスについて、リーダー・スレッドの適切な数を決定する方法については、次の項「ソケットの使用数を確定する」を参照してください。
ソケット・リーダー・スレッドを構成する手順については、「サーバー・インスタンスのホスト・マシン上のリーダー・スレッドの数を設定する」を参照してください。
個々のWebLogic Serverインスタンスは、クラスタ内で自身を除くすべてのサーバー・インスタンスに対してソケットをオープンする可能性があります。ただし、実際に使用されるソケットの最大数は、クラスタの構成によって異なります。実際には、クラスタ化されるシステムではオブジェクトが均一に(クラスタ内の各サーバー・インスタンスに)デプロイされるため、他のどのサーバー・インスタンスに対してもソケットがオープンされないのが一般的です。
クラスタでHTTPセッション状態のインメモリー・レプリケーションを使用しており、オブジェクトを均一にデプロイする場合、図3-2に示すように、各サーバー・インスタンスが最大で2個のソケットしかオープンしない可能性があります。
この例の2つのソケットは、プライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンスとの間でHTTPセッション状態をレプリケートするために使用されます。クラスタ化オブジェクトにアクセスする場合、WebLogic Serverが連結の最適化を行うために、ソケットは不要となります(これらの最適化については、 「連結されたオブジェクトの最適化」 で説明しています)。(この最適化は連結されたオブジェクトの最適化に記載されています)この構成では、デフォルトのソケット・リーダー・スレッド構成で十分です。
「固定」サービスのデプロイメント - サーバー・インスタンスは、固定オブジェクトにアクセスするために追加のソケットを開く必要があるので、一度に1つのみのサーバー上でアクティブになっている複数のサービスで、ソケット使用率が増加することがあります(これは、固定オブジェクトにリモート・サーバー・インスタンスが実際にアクセスする場合にのみ考慮する必要があります)。図3-3は、クラスタ化されていないRMIオブジェクトをサーバーAにデプロイすることによる影響を示しています。
この例では、各サーバー・インスタンスは、HTTPセッション状態をレプリケートするためと、サーバーA上の固定RMIオブジェクトにアクセスするために、最大で同時に3つのソケットをオープンする可能性があります。
クラスタのクライアントは、ソケット・リーダー・スレッドのJava実装を使用します。
WebLogic Serverでは、Javaクライアント・アプリケーションによって開かれるIPソケットの数を削減するサーバー・アフィニティ・ロード・バランシング・アルゴリズムを構成できます。サーバー・インスタンス上の複数のオブジェクトにアクセスするクライアントが、ソケットを1つだけ使用します。オブジェクトに障害が発生した場合、クライアントはソケットがすでに開かれているサーバー・インスタンスにフェイルオーバーします(可能な場合)。WebLogic Serverの旧バージョンでは、状況によっては、クライアントはクラスタ内の各サーバー・インスタンスでソケットを開きます。
最高のパフォーマンスを引き出すには、クライアントを実行するJava仮想マシン(JVM)において十分な数のソケット・リーダー・スレッドを構成します。手順については、「クライアント・マシン上のリーダー・スレッド数を設定する」を参照してください。
クラスタ化されないWebLogic Serverサーバー・インスタンスのクライアントは、JNDI準拠のネーミング・サービスを使用してオブジェクトとサービスにアクセスします。JNDIネーミング・サービスには、サーバー・インスタンスが提供する公開サービスの、ツリー構造のリストが含まれています。WebLogic Serverインスタンスは、そのサービスを表す名前をJNDIツリーにバインドすることによって新しいサービスを提供します。クライアントはサーバー・インスタンスに接続し、バインドされたサービス名をルックアップすることによってサービスを取得します。
クラスタ内のサーバー・インスタンスは、クラスタ全体のJNDIツリーを利用します。クラスタ全体のJNDIツリーは、ツリーが使用可能なサービスのリストを格納しているという点では、1つのサーバー・インスタンスのJNDIツリーと似ています。ただし、クラスタ全体のJNDIツリーは、ローカル・サービスの名前だけでなく、クラスタ内の他のサーバー・インスタンス上にあるクラスタ化オブジェクト(EJBやRMIクラス)が提供するサービスも格納します。
クラスタ内の各WebLogic Serverインスタンスは、クラスタ全体の論理JNDIツリーをローカルにコピーして保守します。次の項では、クラスタ全体のJNDIツリーが維持される方式と、クラスタ環境で発生しうる名前の競合を防ぐ方法について説明します。
|
警告: クラスタ全体のJNDIツリーは、アプリケーション・データの永続性メカニズムまたはキャッシング・メカニズムとして使用しないでください。WebLogic Serverは、クラスタ化サーバー・インスタンスのJNDIエントリをクラスタ内の他のサーバー・インスタンスにレプリケートしますが、元のインスタンスで障害が発生すると、これらのエントリはクラスタから削除されます。また、JNDIツリー内に大きなオブジェクトを格納すると、マルチキャスト・トラフィックまたはユニキャスト・トラフィックが過負荷状態になり、クラスタの通常の処理の妨げとなる場合があります。 |
クラスタ内の各WebLogic Serverは、クラスタのすべてのメンバーが提供するサービスが入ったクラスタ全体のJNDIツリーをローカルにコピーして保守します。クラスタ全体のJNDIツリーの作成では、まず各サーバー・インスタンスをローカルのJNDIツリーにバインドします。サーバー・インスタンスが起動する(または新規サービスが動作中のサーバー・インスタンスに動的にデプロイされる)と、サーバー・インスタンスはまず、それらのサービスの実装をローカルのJNDIツリーにバインドします。実装がJNDIツリーにバインドされるのは、名前が他のサービスと重複していない場合だけです。
|
注意: クラスタで管理対象サーバーを起動すると、サーバー・インスタンスは、 |
サーバー・インスタンスがサービスをローカルのJNDIツリーにバインドすると、レプリカ対応スタブを使用するクラスタ化オブジェクト向けに、次の手順が実行されます。クラスタ化オブジェクトの実装をローカルのJNDIツリーにバインドしたら、サーバー・インスタンスはそのオブジェクトのスタブを他のクラスタ・メンバーに送信します。クラスタの他のメンバーはマルチキャスト・アドレスまたはユニキャスト・アドレスをモニターして、リモート・サーバー・インスタンスが提供するサービスを追加したことを検出します。
図3-4は、JNDIをバインドするプロセスの一部を示しています。
図3-4 サーバーAがオブジェクトをそのJNDIツリーにバインドし、オブジェクトが使用可能であることをユニキャストする
前の図で、サーバーAはクラスタ化オブジェクトXの実装をローカルのJNDIツリーにバインドしました。オブジェクトXはクラスタ化されているので、このサービスはクラスタ内の他のすべてのメンバーに提供されます。サーバーCはオブジェクトXの実装をバインド中です。
クラスタ内でマルチキャスト・アドレスまたはユニキャスト・アドレスをリスニングしている他のサーバー・インスタンスは、サーバーAがクラスタ化オブジェクトXの新規サービスを提供し始めたことを検出します。これらのサーバー・インスタンスは、自身のローカルJNDIツリーを更新して、新規サービスをツリーに取り込みます。
ローカルのJNDIバインドは2つの方法のいずれかで更新されます。
クラスタ化されたサービスがローカルのJNDIツリーにバインドされていない場合、サーバー・インスタンスは、サーバーA上でオブジェクトXが使用可能であることを示す新規のレプリカ対応スタブをローカル・ツリーにバインドします。サーバーBとサーバーDは自身のローカルJNDIツリーをこの方法で更新します。これらのサーバー・インスタンスにはクラスタ化オブジェクトがまだデプロイされていないためです。
サーバー・インスタンスがクラスタ対応サービスをすでにバインドしている場合、サーバーはローカルのJNDIツリーを更新して、サービスのレプリカもサーバーA上で使用可能であることを示します。サーバーCはクラスタ化オブジェクトXをバインド済みなので、自身のJNDIツリーを更新してそれを反映させます。
この方法によって、クラスタ内の各サーバー・インスタンスはククラスタ全体のJNDIツリーのコピーを独自に作成します。サーバーCが、オブジェクトXがローカルのJNDIツリーにバインドされたことを通知する場合にも、処理順序は同じです。すべてのブロードキャスト・メッセージが受信されたら、クラスタ内の各サーバー・インスタンスのローカルJNDIツリーは図3-5のように、サーバーAとサーバーC上でオブジェクトが使用可能であることを同じように示します。
|
注意: 実際のクラスタでは、オブジェクトXは均一にデプロイされ、オブジェクトを呼び出すことのできる実装は4つのサーバー・インスタンスすべてで使用可能になります。 |
単純なJNDI名の競合は、サーバー・インスタンスがJNDIツリー内にバインド済みでクラスタ化されていないサービスと同じ名前を使って、別のクラスタ化されていないサービスをバインドしようとすると発生します。クラスタ・レベルのJNDI名の競合は、サーバー・インスタンスがJNDIツリー内にバインド済みでクラスタ化されていないサービスと同じ名前を使って、クラスタ化されているオブジェクトをバインドしようとしたときに発生します。
WebLogic Serverは、ローカルのJNDIツリーにサービスをバインドするときに、(クラスタ化されていないサービスの)単純な名前の競合を検出します。クラスタ・レベルのJNDIの競合は、マルチキャストまたはユニキャストを使って新規サービスの通知を行うときに発生します。たとえば、クラスタ内のあるサーバー・インスタンス上の固定RMIオブジェクトをデプロイする場合、同じオブジェクトでレプリカ対応のものを別のサーバー・インスタンス上にデプロイすることはできません。
クラスタ内の2つのサーバー・インスタンスが、クラスタ化された別々のオブジェクトを同じ名前を使ってバインドしようとした場合、どちらのバインドもローカルには成功します。ただし、JNDI名の競合が発生するので、各サーバー・インスタンスでは、他のサーバー・インスタンスのレプリカ対応スタブをJNDIツリーにバインドすることはできません。このタイプの競合は、2つのサーバー・インスタンスのどちらかが終了するか、どちらかのサーバー・インスタンスが競合の原因となったクラスタ化オブジェクトをアンデプロイするまで解決しません。これと同じ競合は、固定オブジェクトを両方のサーバー・インスタンスが同じ名前でデプロイしようとした場合にも発生します。
クラスタ・レベルのJNDIの競合を回避するには、すべてのレプリカ対応オブジェクトを、クラスタ内のすべてのWebLogic Serverインスタンスに均一にデプロイする必要があります。デプロイメントがWebLogic Serverインスタンス間でバランスを欠いていると、起動時または再デプロイメント時にJNDI名の競合が発生する可能性が高まります。また、クラスタ内の処理負荷のバランスも取れなくなることがあります。
特定のRMIオブジェクトまたはEJBを個々のサーバー・インスタンスに固定する必要がある場合は、そのオブジェクトのバインドをクラスタ間でレプリケートしないようにします。
クラスタ化オブジェクトが削除(サーバー・インスタンスからアンデプロイ)されるとき、JNDIツリーの更新は、新規サービスの追加時に行われる更新と似た方法で処理されます。アンデプロイされたサービスがあったサーバー・インスタンスは、そのサービスが提供されなくなったことを示すメッセージをブロードキャストします。すでに説明したように、マルチキャスト・メッセージまたはユニキャスト・メッセージを監視しているクラスタ内の他のサーバー・インスタンスは、JNDIツリーのローカル・コピーを更新して、オブジェクトをアンデプロイしたサーバー・インスタンス上でそのサービスが使用できなくなったことを反映させます。
クライアントがレプリカ対応スタブを取得すると、クラスタ内のサーバー・インスタンスは、クラスタ化オブジェクトのホスト・サーバーの追加と削除を続行できます。JNDIツリー内の情報が変更されると、クライアントのスタブも更新されます。その後のRMIリクエストには、クライアントのスタブが常に最新の情報を持つように、必要に応じて更新情報が含まれます。
WebLogic Serverクラスタに接続してクラスタ化オブジェクトをルックアップするクライアントは、そのオブジェクトのレプリカ対応スタブを取得します。このスタブには、そのオブジェクトの実装のホストとして使用可能なサーバー・インスタンスのリストが入っています。スタブには、ホスト・サーバー間で負荷を分散するためのロード・バランシング・ロジックも含まれています。
EJBおよびRMIクラス用のレプリカ対応スタブの詳細は、「EJBとRMIのレプリケーションとフェイルオーバー」を参照してください。
クラスタ環境でWebLogic JNDIを実施する方法およびユーザー固有のオブジェクトをJNDIクライアントで使用可能にする方法の詳細は、『Oracle WebLogic Server JNDIのプログラミング』のクラスタ環境でのWebLogic JNDIの使用に関する項を参照してください。
