WebLogic Server クラスタは、ロード バランシングとフェイルオーバの 2 つの重要な機能を実装しています。以下の節では、設計者と管理者が、特定の Web アプリケーションに適したクラスタをコンフィグレーションするために役立つ情報を示します。
クラスタ内の WebLogic Server インスタンスは、2 つの基本的なネットワーク技術を利用して互いに通信します。
IP ソケット。クラスタ化されたサーバ インスタンス間でピア ツー ピア通信を行うための導管として機能します。
IP ユニキャストまたはマルチキャスト。サーバ インスタンスが、サービスの可用性と、継続的な可用性を示すハートビートをブロードキャストするために使用します。
新しいクラスタを作成する際は、クラスタ内でのメッセージングにユニキャストを使用することをお勧めします。以前のバージョンの WebLogic Server との互換性を維持する必要がある場合は、クラスタ間の通信にマルチキャストを使用する必要があります。
注意 : コンフィグレーション ウィザードを使用してクラスタを作成する場合は、マルチキャストを使用するようにのみクラスタをコンフィグレーションできます。Administration Console でクラスタを作成または再コンフィグレーションする場合は、ユニキャストを使用するようにクラスタをコンフィグレーションできます。Oracle Fusion Middleware Oracle WebLogic Server の Administration Console オンライン ヘルプの「クラスタの作成とコンフィグレーション」を参照してください。 |
WebLogic Server での IP マルチキャストまたはユニキャスト、およびソケット通信の使用形態は、クラスタをどのようにコンフィグレーションするかに影響します。
IP マルチキャストは、複数のアプリケーションが指定された IP アドレスとポート番号を「サブスクライブ」して、メッセージをリスンできるようにする単純なブロードキャスト技術です。
注意 : 新しいクラスタを作成する際は、クラスタ内でのメッセージングにユニキャストを使用することをお勧めします。以前のバージョンの WebLogic Server との互換性を維持する必要がある場合は、クラスタ間の通信にマルチキャストを使用する必要があります。 |
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 をサポートするには、マルチキャストを使用する必要がある。
個別のクラスタ メンバーで、クラスタのメッセージング タイプをオーバーライドすることはできない。
クラスタ全体を停止して、メッセージ モードで再起動する必要がある。
マルチキャスト用にコンフィグレーションされた JMS トピックから、ユニキャスト用にコンフィグレーションされた WebLogic クラスタにアクセスすることは可能。これは、JMS トピックでは、JMS トピック自体の (クラスタ アドレスとは無関係な) マルチキャスト アドレスにメッセージがパブリッシュされるためです。ただし、以下の点を考慮に入れてください。
クラスタのユニキャスト通信を可能にするルータ ハードウェア コンフィグレーションでは、JMS マルチキャスト サブスクライバが機能しない場合がある。
JMS マルチキャスト サブスクライバは、マルチキャスト アクセスが可能なネットワーク ハードウェア コンフィグレーションを必要とする。
詳細については、『Oracle Fusion Middleware 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 ツリーにバインドされるのは、名前が他のサービスと重複していない場合だけです。
注意 : クラスタで管理対象サーバを起動すると、サーバ インスタンスは、ClusterMBean の MemberWarmupTimeoutSeconds パラメータで指定したウォームアップ時間の後で、ハートビートをリスンしてクラスタ内で実行されている他のサーバ インスタンスを識別します。デフォルトのウォームアップ時間は 30 秒です。 |
サーバ インスタンスがサービスをローカルの JNDI ツリーにバインドすると、レプリカ対応スタブを使用するクラスタ化されたオブジェクト向けに、次の手順が実行されます。クラスタ化されたオブジェクトの実装をローカルの JNDI ツリーにバインドしたら、サーバ インスタンスはそのオブジェクトのスタブを他のクラスタ メンバーに送信します。クラスタの他のメンバーはマルチキャスト アドレスまたはユニキャスト アドレスをモニタして、リモート サーバ インスタンスが提供するサービスを追加したことを検出します。
図 3-4 は、JNDI をバインドするプロセスの一部を示しています。
図 3-4 サーバ A がオブジェクトをその JNDI ツリーにバインドし、オブジェクトが使用可能であることをユニキャストする
前の図で、サーバ A はクラスタ化されたオブジェクト X の実装をローカルの JNDI ツリーにバインドしました。オブジェクト X はクラスタ化されているので、このサービスはクラスタ内の他のすべてのメンバーに提供されます。サーバ C はオブジェクト X の実装をバインド中です。
クラスタ内でマルチキャスト アドレスまたはユニキャスト アドレスをリスンしている他のサーバ インスタンスは、サーバ A がクラスタ化されたオブジェクト X の新規サービスを提供し始めたことを検出します。これらのサーバ インスタンスは、自身のローカル JNDI ツリーを更新して、新規サービスをツリーに取り込みます。
ローカルの JNDI バインドは次のいずれかの方法で更新されます。
クラスタ化されたサービスがローカルの JNDI ツリーにバインドされていない場合、サーバ インスタンスは、サーバ A 上でオブジェクト X が使用可能であることを示す新規のレプリカ対応スタブをローカル ツリーにバインドする。これらのサーバ インスタンスにはクラスタ化されたオブジェクト 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 Fusion Middleware Oracle WebLogic Server JNDI プログラマーズ ガイド』の「クラスタ環境での WebLogic JNDI の使い方」を参照してください。