|
|
WebLogic Server クラスタは、ロード バランシングとフェイルオーバの 2 つの重要な機能を実装しています。以下の節では、設計者と管理者が、特定の Web アプリケーションに適したクラスタをコンフィグレーションするために役立つ情報を示します。
クラスタ内の WebLogic Server インスタンスは、2 つの基本的なネットワーク技術を利用して互いに通信します。
新しいクラスタを作成する際は、クラスタ内でのメッセージングにユニキャストを使用することをお勧めします。以前のバージョンの WebLogic Server との互換性を維持する必要がある場合は、クラスタ間の通信にマルチキャストを使用する必要があります。
| 注意 : | コンフィグレーション ウィザードを使用してクラスタを作成する場合は、マルチキャストを使用するようにのみクラスタをコンフィグレーションできます。Administration Console でクラスタを作成または再コンフィグレーションする場合は、ユニキャストを使用するようにクラスタをコンフィグレーションできます。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 ネーミング サービス」で説明するように) 障害の検出とクラスタワイドの JNDI ツリーの保守に関わる重要な機能を制御するので、クラスタのコンフィグレーションもマルチキャスト通信とのネットワーク トポロジ インタフェースも重要ではありません。以下の節では、クラスタ内でのマルチキャスト通信に伴う問題を回避するためのガイドラインを示します。
多くのデプロイメント構成で、クラスタ化されるサーバ インスタンス群は単一のサブネットの内部に置かれます。これは、マルチキャスト メッセージの確実な転送を保証するための構成です。ただし必要に応じて、ワイド エリア ネットワーク (WAN) 内の複数のサブネット間に WebLogic Server クラスタを分散させて冗長性を確保したり、あるいはクラスタ化されるサーバ インスタンスをより広範な地理的領域に分散させることができます。
クラスタを WAN (または複数のサブネット) 上に分散する場合、マルチキャスト メッセージがクラスタ内のすべてのサーバ インスタンスに必ず転送されるようにネットワーク トポロジを計画およびコンフィグレーションします。特に、ネットワークが以下の要件を満たす必要があります。
| 注意 : | 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 JMS プログラマーズ ガイド』の「WebLogic JMS でのマルチキャストの使い方」を参照してください。
IP ソケットは、2 つのアプリケーション間でメッセージおよびデータを転送するための、シンプルでパフォーマンスの高いメカニズムです。クラスタ化される WebLogic Server インスタンスは、次の目的で IP ソケットを使用します。
| 注意 : | WebLogic Server での IP ソケットの使い方はクラスタ関連にとどまらず、たとえば、Java クライアント アプリケーションがリモート オブジェクトにアクセスする場合など、すべての RMI 通信がソケットを使って行われます。 |
WebLogic Server クラスタのパフォーマンスは、ソケットのコンフィグレーションによって大きく左右されます。WebLogic Server でのソケット通信の効率は、次の 2 つの要因によって決まります。
ソケット リーダー スレッドの pure-Java 実装は、ピア ツー ピア通信を行うための信頼性が高く移植可能な方法ですが、ソケットに大きな負荷がかかる WebLogic Server クラスタで使用する場合には、最適なパフォーマンスを提供できません。pure-Java ソケット リーダーを使用すると、スレッドは、ソケットにデータが入っているかどうかを調べるために、オープンしているソケットにポーリングする必要があります。つまり、ソケット リーダー スレッドはソケットのポーリングで常に「ビジー」となります。これはソケットがデータを持っていない場合でも変わりません。この不必要なオーバーヘッドにより、パフォーマンスが低下する可能性があります。
パフォーマンスの問題は、サーバ インスタンスがソケット リーダー スレッドよりも多くの開かれたソケットを持つとき (各リーダー スレッドが複数の開いたソケットをポーリングしなければならないとき) に顕著になります。ソケット リーダーはアクティブでないソケットに遭遇すると、別のソケットにサービスを提供する前にタイムアウトを待ちます。このタイムアウト待ちの間、次の図に示すように、アクティブでないソケットをソケット リーダーがポーリングする一方で、アクティブなソケットが未読のままになる場合があります。
ソケットの最適なパフォーマンスを実現するには、pure-Java 実装ではなく、オペレーティング システムに対応したネイティブ ソケット リーダー実装を使用するよう WebLogic Server ホスト マシンをコンフィグレーションします。ネイティブ ソケット リーダーは、ソケット上のデータの有無を非常に効率的な手法で調べます。ネイティブ ソケット リーダー実装では、リーダー スレッドはネイティブ ソケットをポーリングする必要がなく、アクティブなソケットに対してだけサービスとして、特定のソケットがアクティブになった場合には、(割り込みによって) 直ちに通知されます。
| 注意 : | アプレットはネイティブ ソケット リーダー実装を使用できないので、ソケット通信では十分な効果が出ません。 |
オペレーティング システムに対応したネイティブ ソケット リーダーの実装を使用するように WebLogic Server ホスト マシンをコンフィグレーションする方法については、「サーバ インスタンスのホスト マシン上でネイティブの IP ソケット リーダーをコンフィグレーションする」を参照してください。
pure-Java ソケット リーダー実装を使用する場合は、サーバ インスタンスごとにソケット リーダー スレッドの数を適切にコンフィグレーションすることで、ソケット通信のパフォーマンスを向上できます。最適なパフォーマンスを実現するには、WebLogic Server でのソケット リーダー スレッドの数を、同時にオープンするソケットの最大数に合わせる必要があります。このコンフィグレーションにより、リーダー スレッドが複数のソケットにサービスしなければならない状況が回避され、ソケット データの即時読み取りが保証されます。
クラスタ内のサーバ インスタンスについて、リーダー スレッドの適切な数を決定する方法については、次の節「ソケットの使用数を確定する」を参照してください。
ソケット リーダー スレッドをコンフィグレーションする手順については、「サーバ インスタンスのホスト マシン上のリーダー スレッドの数を設定する」を参照してください。
個々の WebLogic Server インスタンスは、クラスタ内で自身を除くすべてのサーバ インスタンスに対してソケットをオープンする可能性があります。ただし、実際に使用されるソケットの最大数は、クラスタのコンフィグレーションによって異なります。実際には、クラスタ化されるシステムではオブジェクトが均一に (クラスタ内の各サーバ インスタンスに) デプロイされるため、他のどのサーバ インスタンスに対してもソケットがオープンされないのが一般的です。
クラスタで HTTP セッション ステートのインメモリ レプリケーションを使用しており、オブジェクトを均一にデプロイする場合、次の図に示すように、各サーバ インスタンスが最大で 2 個のソケットしかオープンしない可能性があります。
この例の 2 つのソケットは、プライマリ サーバ インスタンスとセカンダリ サーバ インスタンスとの間で HTTP セッション ステートをレプリケートするために使用されます。クラスタ化されたオブジェクトにアクセスする場合、WebLogic Server が連結の最適化を行うために、ソケットは不要となります (これらの最適化については、「連結されたオブジェクトの最適化」で説明しています)。このコンフィグレーションでは、デフォルトのソケット リーダー スレッド コンフィグレーションで十分です。
「固定」サービスのデプロイメント - サーバ インスタンスは、固定オブジェクトにアクセスするために追加のソケットを開く必要があるので、一度に 1 つのみのサーバ上でアクティブになっている複数のサービスで、ソケット使用率が増加することがあります (これは、固定オブジェクトにリモート サーバ インスタンスが実際にアクセスする場合にのみ考慮する必要があります)。次の図は、クラスタ化されていない 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 ツリーにバインドしたら、サーバ インスタンスはそのオブジェクトのスタブを他のクラスタ メンバーに送信します。クラスタの他のメンバーはマルチキャスト アドレスまたはユニキャスト アドレスをモニタして、リモート サーバ インスタンスが提供するサービスを追加したことを検出します。
次の図は、JNDI をバインドするプロセスの一部を示しています。
前の図で、サーバ A はクラスタ化されたオブジェクト X の実装をローカルの JNDI ツリーにバインドしました。オブジェクト X はクラスタ化されているので、このサービスはクラスタ内の他のすべてのメンバーに提供されます。サーバ C はオブジェクト X の実装をバインド中です。
クラスタ内でマルチキャスト アドレスまたはユニキャスト アドレスをリスンしている他のサーバ インスタンスは、サーバ A がクラスタ化されたオブジェクト X の新規サービスを提供し始めたことを検出します。これらのサーバ インスタンスは、自身のローカル JNDI ツリーを更新して、新規サービスをツリーに取り込みます。
ローカルの JNDI バインドは次のいずれかの方法で更新されます。
この方法によって、クラスタ内の各サーバ インスタンスはクラスタワイドの JNDI ツリーのコピーを独自に作成します。サーバ C が、オブジェクト X がローカルの JNDI ツリーにバインドされたことを通知する場合にも、処理順序は同じです。すべてのブロードキャスト メッセージが受信されたら、クラスタ内の各サーバ インスタンスのローカル JNDI ツリーは次の図のように、サーバ 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 クライアントで使用可能にする方法については、『WebLogic JNDI プログラマーズ ガイド』の「クラスタ環境での WebLogic JNDI の使い方」を参照してください。
  
|