3 クラスタでの通信

この章では、WebLogic Server 12.1.3において、WebLogic Serverクラスタが、IPソケットおよびIPユニキャストまたはマルチキャストを使用してどのように通信するかについて説明します。

クラスタ内のWebLogic Serverインスタンスは、2つの基本的なネットワーク技術を利用して互いに通信します。

• IPユニキャストまたはマルチキャスト - サーバー・インスタンスが、サービスの可用性と、継続的な可用性を示すハートビートをブロードキャストするために使用します。ユニキャストかマルチキャストかの選択の詳細は、「ユニキャストかマルチキャストかを選択する際の考慮事項」を参照してください。

• IPソケット - クラスタ化サーバー・インスタンス間でピア・ツー・ピア通信を行うための導管として機能します。

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

• WebLogic Serverのクラスタ・メッセージング・プロトコルの選択

• IPソケットを使用したピア・ツー・ピア通信

• ソケット経由のクライアント通信

• クラスタ全体のJNDIネーミング・サービス

WebLogic Serverのクラスタ・メッセージング・プロトコルの選択

WebLogic Serverは、2つのクラスタ・メッセージング・プロトコルをサポートしています。

• マルチキャスト: このプロトコルは、UDPマルチキャストを使用します。WebLogic Server 4.0以降のWebLogic Serverクラスタでサポートされています。

• ユニキャスト: このプロトコルは、ポイント・ツー・ポイントTCP/IPソケットを使用します。WebLogic Server 10.0で追加されました。

この項には次のトピックが含まれます:

• IPマルチキャストの使用

• ユニキャストを使用した1対多通信

• ユニキャストかマルチキャストかを選択する際の考慮事項

IPマルチキャストの使用

マルチキャストは、複数のアプリケーションが指定されたIPアドレスとポート番号を「サブスクライブ」して、メッセージをリスニングできるようにする単純なブロードキャスト技術です。

注意: マルチキャスト・アドレスは、範囲が224.0.0.0 - 239.255.255.255のIPアドレスです。WebLogic Serverで使用されるデフォルトのマルチキャスト・アドレスは、239.192.0.0です。x.0.0.1の範囲内のマルチキャスト・アドレスを使用することはできません。マルチキャスト・ポートには、通常のUDPポート範囲(0から65535)がありますが、一部のUDPポートは、特定の目的のために予約されており、通常は回避する必要があります。

マルチキャストはアプリケーションに対してメッセージをブロードキャストしますが、メッセージが実際に届くことは保証されていません。アプリケーションのローカル・マルチキャスト・バッファがいっぱいの場合、新規のマルチキャスト・メッセージをそのバッファに書込めないので、アプリケーションにはメッセージが「届いた」ことがわかりません。この制約のため、WebLogic Serverインスタンスでは、マルチキャストに対してブロードキャストされたメッセージが届かない可能性を考慮しています。

WebLogic Serverのマルチキャストの実装では、標準のUDPマルチキャストを使用して、メッセージが送信されるマルチキャスト・アドレスおよびポートを明示的にリスニングしているグループにクラスタ・メッセージをブロードキャストします。UDPは、信頼性のあるプロトコルではないため、WebLogic Serverは、信頼性のある独自のメッセージング・プロトコルを、送信するメッセージに組み込み、失われたメッセージを検出して再送信します

ほとんどのオペレーティング・システムおよびスイッチは、同じサブネット内のマシン間でUDPマルチキャストをデフォルトでサポートしています。ただし、ほとんどのルーターは、サブネット間のUDPマルチキャスト・メッセージの伝播をデフォルトではサポートしていません。UDPマルチキャスト・メッセージの伝播をサポートしている環境では、UDPマルチキャストには、プロトコルに組み込まれた存続時間(TTL)メカニズムがあります。メッセージがルーターに到着するたびに、メッセージがルーティングされる前にTTLが1ずつ減ります。TTLがゼロになると、メッセージはネットワーク間で伝播されず、UDPマルチキャスト・メッセージの範囲に対する効率的な制御が行われます。WebLogic Serverでは、デフォルトで、マルチキャスト・クラスタ・メッセージのTTLは1に設定されます。これにより、メッセージが現在のサブネットに制限されます。

マルチキャストを使用している場合、ハートビート・メッセージが3回続けて届かないと、クラスタ・ハートビート・メカニズムにより、クラスタからサーバー・インスタンスが削除されます(つまり、UDPは信頼性のあるプロトコルであるとは見なされません)。デフォルトのハートビート頻度は、10秒ごとに1回のハートビートです。つまり、最大30秒で、あるサーバー・インスタンスがクラスタを離れたことを検出できるということです。ソケットの停止が検出されたり、接続の試行が失敗した場合も、サーバーがクラスタから離れたと認識されます。

要約すると、WebLogic Serverのマルチキャスト・クラスタ・メッセージング・プロトコルは、次のように動作します。

• 非常に効率的でスケーラブルなピア・ツー・ピア・モデルを使用します。このモデルでは、サーバー・インスタンスは、各メッセージを直接ネットワークに1回送信し、各クラスタ・メンバーは、ネットワークから直接メッセージを受信します。

• クラスタ・メンバーが同じサブネット内に存在するほとんどの環境で、即時利用可能な状態で動作します。

• クラスタ・メンバーが複数のサブネットにまたがっている場合は、ルーターとWebLogic Serverの追加の構成(マルチキャストTTLなど)を行う必要があります。

• ハートビートが3回続けて届かないと、別のサーバーのクラスタ・メンバーシップ・リストからサーバー・インスタンスが削除されます。

ある環境でWebLogic Serverのマルチキャスト・メッセージング・プロトコルがサポートされているかどうかをテストするために、WebLogic Serverには、MulticastTestというJavaコマンド行ユーティリティが用意されています。

WebLogic Serverは、クラスタ内のサーバー・インスタンス間のすべての1対多通信でマルチキャストを使用します。この通信には次が含まれます。

• クラスタ全体のJNDIの更新 - クラスタ内の個々のWebLogic Serverインスタンスはマルチキャストを使用して、ローカルでデプロイされたり、削除されたりしたクラスタ化オブジェクトが使用可能かどうかを通知します。クラスタ内の各サーバー・インスタンスはこれらの通知をモニターし、クラスタ化されるオブジェクトの最新のデプロイメント状況に合わせてインスタンスのローカルJNDIツリーを更新します。詳細は、「クラスタ全体のJNDIネーミング・サービス」を参照してください。

• クラスタの「ハートビート」 - WebLogic Serverは、マルチキャストを使用して、クラスタ内の個々のサーバー・インスタンスが使用可能であることを通知するために、定期的に「ハートビート」メッセージをブロードキャストします。クラスタ内のサーバー・インスタンスは、ハートビート・メッセージをモニターすることにより、どの時点でサーバー・インスタンスに障害が発生したかを特定します。(クラスタ化サーバー・インスタンスは、サーバー・インスタンスで障害が発生した時点を特定するためのより直接的な手段として、IPソケットのモニターも行います。)

• 複数のノードがあるクラスタ - 複数のノードがあるクラスタでは、オプションでマルチキャスト通信を使用できます。

マルチキャストとクラスタの構成

マルチキャスト通信は、(「クラスタ全体のJNDIネーミング・サービス」で説明するように)障害の検出とクラスタ全体のJNDIツリーの保守に関わる重要な機能を制御するので、クラスタの構成もマルチキャスト通信とのネットワーク・トポロジ・インタフェースも重要ではありません。次の項では、クラスタ内でのマルチキャスト通信に伴う問題を回避するためのガイドラインを示します。

クラスタがWAN内の複数のサブネットにまたがる場合

多くのデプロイメント構成で、クラスタ化されるサーバー・インスタンス群は単一のサブネットの内部に置かれます。これは、マルチキャスト・メッセージの確実な転送を保証するための構成です。ただし必要に応じて、ワイド・エリア・ネットワーク(WAN)内の複数のサブネット間にWebLogic Serverクラスタを分散させて冗長性を確保したり、あるいはクラスタ化されるサーバー・インスタンスをより広範な地理的領域に分散させることができます。

クラスタをWAN (または複数のサブネット)上に分散する場合、マルチキャスト・メッセージがクラスタ内のすべてのサーバー・インスタンスに必ず転送されるようにネットワーク・トポロジを計画および構成します。特に、ネットワークが次の要件を満たす必要があります。

• IPマルチキャスト・パケットの伝播の完全サポート。つまり、すべてのルーターおよびその他のトンネリング技術がマルチキャスト・メッセージをクラスタ化されているサーバー・インスタンスに伝播するように構成されている必要があります。

• 大半のマルチキャスト・メッセージがその最終的な宛先に約10ミリ秒以内に到達することを保証する、低いネットワーク待機時間。

• マルチキャスト・パケットが最終的な宛先に届くまでにルーターがパケットを破棄しないことを保証する、クラスタのマルチキャスト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)メッセージやハートビートの再送信を含むネットワーク・トラフィックが増大します。ネットワーク上でマルチキャスト・パケットが繰り返し送信されることは、マルチキャスト・ストームと呼ばれ、それが発生するとネットワークとそのネットワークに接続されたステーションに負荷がかかり、エンドステーションでハングまたは障害が発生する可能性があります。マルチキャスト・バッファのサイズを増やすと、通知が送信および受信されるレートが改善されて、マルチキャスト・ストームを防止できます。「マルチキャスト・バッファのサイズを構成する」を参照してください。

ユニキャストを使用した1対多通信

WebLogic Serverのユニキャスト・プロトコルは、標準のTCP/IPソケットを使用して、クラスタ・メンバー間でメッセージを送信します。すべてのネットワークおよびネットワーク・デバイスでTCP/IPソケットがサポートされているため、ユニキャストでは、初期状態のクラスタ構成が容易になります。通常、クラスタ・メンバー間のネットワーク・トポロジに関係なく、追加の構成は不要です。加えて、ユニキャストでは、マルチキャスト・アドレスの競合によって発生する可能性がある潜在的なネットワーク・エラーが低減されます。WebLogic Serverでは、ユニキャストをデフォルトのクラスタ・プロトコルとして使用します。

WebLogic Serverユニキャスト・グループ

TCP/IPソケットはポイント・ツー・ポイント・メカニズムであるため、すべてのクラスタ・メンバーがメッセージを直接受信します。クラスタの拡大につれて必要になるソケット数を制限するために、WebLogic Serverのユニキャスト実装ではグループ・リーダー・メカニズムを使用します。このメカニズムでは、次のようになります。

• WebLogic Serverは、クラスタ内のサーバー・インスタンスを固定数のグループに分割します。

• 各グループには、グループ・リーダーとしても機能する1つのサーバー・インスタンスが含まれます。グループ・リーダーに障害が発生すると、そのグループは別のグループ・リーダーを選択します。

• クラスタ・メッセージを送受信するために、グループ内の各サーバー・インスタンスはグループ・リーダーにのみTCP/IPソケット接続を行います。グループ・リーダーは、そのすべてのグループ・メンバーおよびクラスタ内の他のすべてのグループ・リーダーに接続します。

• グループ・リーダーは、そのグループ内のサーバー・インスタンスからクラスタ・メッセージを受信すると、そのメッセージをグループ内の他のすべてのメンバーおよびクラスタ内の他のすべてのグループ・リーダーに再送信します。他のグループ・リーダーは、そのすべてのグループ・メンバーにメッセージを再送信します。これにより、各サーバー・インスタンスは、そのサーバーがクラスタ内の他のすべてのサーバー・インスタンスへの接続を確立する必要なしに、クラスタ内のすべてのメッセージを受信できます。

ユニキャストを使用する場合、サーバー・インスタンスはハートビートを送信して、その可用性を通知します。これはマルチキャストと同様です。サーバー・インスタンスは、ハートビート・メッセージをモニターすることにより、どの時点で別のサーバー・インスタンスに障害が発生したかを特定します。ただし、ユニキャストでは、ハートビート・メッセージが1回でも届かないと、クラスタ・ハートビート・メカニズムにより、クラスタからサーバー・インスタンスが削除されます(TCP/IPは信頼性のあるプロトコルであると見なされているため)。

マルチキャストでは10秒ごとにハートビートの喪失がチェックされるのに対し、ユニキャストでは15秒ごとにチェックされます。この追加の5秒により、メッセージがリモート・グループのメンバーからリモート・グループのリーダー、さらにローカル・グループのリーダーに移動し、最終的にローカル・グループのメンバーに届くための十分な時間が確保されます。デフォルトのハートビート頻度は、10秒ごとに1回のハートビートです。つまり、15秒以内に、あるサーバー・インスタンスがクラスタを離れたことが検出されるということです。ソケットの停止が検出されたり、接続の試行が失敗した場合も、サーバーがクラスタから離れたと認識されます。

グループへのサーバー・インスタンスの割当て

注意: グループへのサーバー・インスタンスへの割当てに使用されるアルゴリズムは、WebLogic Server 12.1.2およびそれ以前のバージョンで使用されていたアルゴリズムから変更されました。新しいアルゴリズムについて、次の項で説明します。これは、実行中のクラスタの拡張の柔軟性を向上させ、クラスタの実行中に管理対象サーバーがWebLogic Serverクラスタに追加されるユースケースのサポートを向上させるように最適化されています。

WebLogic Serverのユニキャスト実装は、クラスタのサーバー・インスタンスを10グループに内部的に編成します。WebLogic Serverは、サーバー・インスタンスをグループに割り当て、サーバーのネーミング・パターンに従って各グループ内のサーバー・インスタンスをソートします。グループに含まれるサーバー・インスタンス数は動的であるため、クラスタ・サーバー・インスタンスの数と名前によっては非対称または空のグループが存在することがあります。

サーバー・インスタンスをグループに割り当てるために、WebLogic Serverは各サーバー名を接頭辞と整数の2つの部分に分離します。たとえば、server1という名前のサーバー・インスタンスは接頭辞<server>と整数<1>に分離されます。

サーバー・インスタンスには任意の名前を使用できます。構成されるサーバーでは、サーバー名が整数で終わらない場合に、WebLogic Serverは初期値を計算し、サーバー・インスタンスに割り当てます。この値を使用して、サーバー・インスタンスを自動的に割り当てる適切なグループを特定します。たとえば、サーバー・インスタンスserverAおよびserverBには名前に整数がありません。WebLogic Serverは、接頭辞に名前全体を使用し、serverAには728、serverBには729など、整数に使用する値を計算します。

動的クラスタはサーバー・テンプレート設定を使用し、接頭辞と整数の連番を使用して動的サーバーに自動的に名前を付けるため、動的サーバーは常にこのパターンに従います。

整数を各サーバー名に関連付けた後で、WebLogic Serverはアルゴリズムを使用し、その整数に基づいてサーバー・インスタンスをグループに割り当てます。各グループ内で、サーバー・インスタンスは最初に接頭辞のアルファベット順にソートされてから、整数でソートされます。

各グループ内の最初のサーバー・インスタンスはグループ・リーダーとして機能します。この割当てモデルでは、クラスタ内のすべてのサーバー・インスタンスは、既存の実行中サーバーと新規に追加されたサーバーのどちらであるかにかかわらず、グループ・メンバーシップとグループ・リーダー・ロールで一貫性のあるビューを共有します。

次の表に、ユニキャスト・ネーミング・パターンと、WebLogic Serverがサーバー・インスタンスをグループにどのように割り当て、ソートするかを示します。この例では、10個のグループを使用します。クラスタには、server1からserver15までの15個のサーバー・インスタンスと、serverAからserverEまでの5つの追加サーバー・インスタンスが含まれます。

表3-1 サーバー名の接頭辞と整数への分離

サーバー名	接頭辞	Integer
server1	server	1
server2	server	2
server3	server	3
server4	server	4
server5	server	5
server6	server	6
server7	server	7
server8	server	8
server9	server	9
server10	server	10
server11	server	11
server12	server	12
server13	server	13
server14	server	14
server15	server	15
serverA	serverA	計算結果は728
serverB	serverB	計算結果は729
serverC	serverC	計算結果は730
serverD	serverD	計算結果は731
serverE	serverE	計算結果は732

表3-2 グループへのサーバー・インスタンスの割当て

グループ	グループ内のサーバー・インスタンス
group0	server10 (group leader), serverC
group1	server1 (group leader), server11, serverD
group2	server2 (group leader), server12, severE
group3	server3 (group leader), server13
group4	server4 (group leader), server14
group5	server5 (group leader), server15
group6	server6 (group leader)
group7	server7 (group leader)
group8	server8 (group leader), serverA
group9	server9 (group leader), serverB

server16という新規サーバー・インスタンスを追加した場合、WebLogic Serverは、それをgroup6のserver6の後に割り当てます。

group6: server6 (group leader), server 16

server20という新規サーバー・インスタンスを追加した場合、WebLogic Serverは、それをgroup0のserver10の後、serverCの前に割り当てます。

group0: server10 (group leader), server20, serverC

接頭辞は整数より前にソートされるため、clonedServer16という新規サーバーを追加した場合、WebLogic Serverはそれをgroup6のserver6の前に割り当てます。clonedServer16がグループ内の最初のサーバー・インスタンスになったため、グループ・リーダーはclonedServer16に変更されます。

group6: clonedServer16 (new group leader), server6, server16

ユニキャストの構成

ユニキャストは、ClusterMBean.setClusterMessagingMode MBean属性を使用して構成します。このパラメータのデフォルト値はunicastです。このMBeanへの変更は動的には反映されません。変更を有効にするには、クラスタを再起動する必要があります。

特定のユニキャスト・チャネルを定義するには、最初にcluster-broadcastまたはcluster-broadcast-secureプロトコルとのユニキャスト通信用のカスタム・ネットワーク・チャネルを定義します。このカスタム・ネットワーク・チャネルを定義した後、ClusterMBean.ClusterBroadcastChannel MBean属性でチャネル名を指定することで、このチャネルをクラスタに関連付けることができます。ユニキャストが有効になると、サーバーはこのMBean属性で定義された値をクラスタ間の通信に使用しようとします。ユニキャスト・チャネルが明示的に定義されていない場合は、デフォルトのネットワーク・チャネルが使用されます。

注意: ClusterMBean.ClusterBroadcastChannel属性の使用は、ユニキャストでのみサポートされます。

WebLogic Serverクラスタでユニキャスト通信を構成する場合は、サーバーが異なるマシンで実行している場合、それらのマシンのリスニング・アドレスまたはDNS名を明示的に指定する必要があります。

ユニキャストを使用する場合の考慮事項

WebLogic Server 12.1.3でユニキャストを使用してクラスタ通信を処理する場合は、次の点を考慮に入れてください。

• クラスタのすべてのメンバーで同じメッセージ・タイプを使用する必要があります。メッセージングとしてマルチキャストとユニキャストを混在させることはできません。

• 個別のクラスタ・メンバーで、クラスタのメッセージング・タイプをオーバーライドすることはできません。

• クラスタ全体を停止し、再起動してメッセージ・モードを変更する必要があります。

• JMSトピックは、クラスタ・アドレスに依存しない独自のマルチキャスト・アドレスに対してメッセージをパブリッシュするので、マルチキャスト向けに構成されたJMSトピックでもユニキャスト向けに構成されたWebLogicクラスタにアクセスできます。ただし、次の点を考慮に入れてください。

  • クラスタのユニキャスト通信を可能にするルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能しない場合があります。

  • JMSマルチキャスト・サブスクライバは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成を必要とします。

    詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のWebLogic JMSでのマルチキャストの使用に関する項を参照してください。

ユニキャストかマルチキャストかを選択する際の考慮事項

ユニキャストは、初期状態のクラスタ構成を容易にし、ほとんどのユーザー要件を満たす可能性が高いので、デフォルトのプロトコルとなっています。ただし、Oracleでは、両方のプロトコルを同じように完全にサポートしています。いずれのプロトコルでも、クラスタ・メンバーには、クラスタ・メッセージの送受信をタイムリーに行うための十分な処理時間があることが必要です。これにより、クラスタ・メンバーシップの不要な変更を回避し、クラスタから離れたりクラスタに再参加したりすることに伴う固有の再同期コストの発生を防ぐことができます。使用可能なリソースの過度な利用を招くため、クラスタ・メンバーシップの不要な変更が行われないようにすることをお薦めします。

ユニキャストの使用時は特に、グループ・リーダーがリソース面の制約を受けることがないようにしてください。グループ・リーダーは、メッセージ・リレーを行って、クラスタの他のメンバーにクラスタ・メッセージを配信する役目を担うからです。グループ・リーダーになんらかの遅延が生じると、複数のクラスタ・メンバーが影響を受け、そのグループ内で新しいグループ・リーダーが選出されるという結果を招くこともあります。

これに対して、マルチキャストでは、速度の遅いメンバーが実際に影響を及ぼす可能性があるのは、そのクラスタの固有のメンバーシップに対してのみです。マルチキャスト・クラスタは通常、クラスタ・メッセージの伝播に関してはより効率的であり、そのため、リソースのオーバーサブスクリプションに対する抵抗力がより高い傾向があります。これらの理由から、ネットワーク環境でWebLogic ServerクラスタUDP要件がサポートされている場合、マルチキャストはスループット要件の高い非常に大きなクラスタに適したオプションとなる可能性があります。

各プロトコルには固有の利点があります。表3-3に、マルチキャストとユニキャストの違いをいくつか示します。

表3-3 マルチキャストとユニキャストの違いのサマリー

マルチキャスト	ユニキャスト
UDPマルチキャストを使用します。	TCP/IPを使用します。
複数のサブネットにまたがるクラスタリングでは、ルーターへの追加の構成(TTL)が必要です。	ネットワーク・トポロジのための追加の構成は不要です。
マルチキャストのリスニング・アドレスおよびリスニング・ポートを構成する必要があります。複数のNICが搭載されているマシン上では、使用するネットワーク・インタフェースを指定する必要がある場合があります。	必要なのは、リスニング・アドレスの指定のみです。クラスタ通信でのデフォルト・チャネルまたはカスタム・ネットワーク・チャネルの使用をサポートしています。
各メッセージは、ネットワークに直接配信され、ネットワークから直接受信されます。	各メッセージは、グループ・リーダーに配信されます。グループ・リーダーは、そのメッセージを、他のグループ・メンバー(N - 1)および他のグループ・リーダー(M - 1) (存在する場合)に再送信します。他のグループ・リーダーはその後、各自のグループ・メンバーにメッセージを再送信します。この結果、すべてのクラスタ・メッセージについて最大でN x M個のネットワーク・メッセージが存在することになります。各クラスタ・メンバーへのメッセージ配信は、1つから3つのネットワーク・ホップを経由して行われます。
すべてのサーバーは、他のすべてのサーバーの存在を認識しています。	グループ・リーダーは、メッセージ・リレー・ポイントとして機能し、そのグループ・メンバーおよび他のグループ・リーダーにメッセージを再送信します。
ハートビート・メッセージが3回続けて届かないと、クラスタ・メンバーシップの変更が発生し、クラスタ・リストからメンバーが削除されます。	ハートビート・メッセージが1回でも届かないと、クラスタ・メンバーシップの変更が発生し、クラスタからメンバーが削除されます。

IPソケットを使用したピア・ツー・ピア通信

IPソケットは、2つのアプリケーション間でメッセージおよびデータを転送するための、シンプルでパフォーマンスの高いメカニズムです。クラスタ化されるWebLogic Serverインスタンスは、次の目的でIPソケットを使用します。

• 別のマシンでクラスタ化されている別のサーバー・インスタンスにデプロイされた、クラスタ化されていないオブジェクトへのアクセス。

• HTTPセッション状態とステートフル・セッションEJBの状態の、プライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンス間でのレプリケーション。

• リモート・サーバー・インスタンス上にあるクラスタ化オブジェクトへのアクセス。(これは一般に、「推奨複数層アーキテクチャ」で説明するような複数層クラスタ・アーキテクチャでのみ発生します。)

  
  

  注意: WebLogic ServerでのIPソケットの使用方法はクラスタ関連にとどまらず、たとえば、Javaクライアント・アプリケーションがリモート・オブジェクトにアクセスする場合など、すべてのRMI通信がソケットを使用して行われます。

  
  

WebLogic Serverクラスタのパフォーマンスは、ソケットの構成によって大きく左右されます。WebLogic Serverでのソケット通信の効率は、次の2つの要因によって決まります。

• サーバー・インスタンスのホスト・システムではネイティブ・ソケット・リーダー実装とpure-Javaソケット・リーダー実装のどちらを使用しているか

• pure-Javaソケット・リーダーを使用しているシステムの場合は、サーバー・インスタンスが十分な数のソケット・リーダー・スレッドに対応するよう構成されているかどうか

pure-Javaとネイティブ・ソケット・リーダーの実装の比較

ソケット・リーダー・スレッドのpure-Java実装は、ピア・ツー・ピア通信を行うための信頼性が高く移植可能な方法ですが、ソケットに大きな負荷がかかるWebLogic Serverクラスタで使用する場合には、最適なパフォーマンスを提供できません。pure-Javaソケット・リーダーを使用すると、スレッドは、ソケットにデータが入っているかどうかを調べるために、オープンしているソケットにポーリングする必要があります。つまり、ソケット・リーダー・スレッドはソケットのポーリングで常に「ビジー」となります。これはソケットがデータを持っていない場合でも変わりません。この不必要なオーバーヘッドにより、パフォーマンスが低下する可能性があります。

パフォーマンスの問題は、サーバー・インスタンスがソケット・リーダー・スレッドよりも多くのオープン・ソケットを持つとき(各リーダー・スレッドが複数のオープン・ソケットをポーリングしなければならないとき)に顕著になります。ソケット・リーダーはアクティブでないソケットに遭遇すると、別のソケットにサービスを提供する前にタイムアウトを待ちます。このタイムアウト待ちの間、図3-1に示すように、アクティブでないソケットをソケット・リーダーがポーリングする一方で、アクティブなソケットが未読のままになる場合があります。

図3-1 pure-Javaソケット・リーダー・スレッドがアクティブでないソケットをポーリングする

「図3-1 pure-Javaソケット・リーダー・スレッドがアクティブでないソケットをポーリングする」の説明

ソケットの最適なパフォーマンスを実現するには、pure-Java実装ではなく、オペレーティング・システムに対応したネイティブ・ソケット・リーダー実装を使用するようWebLogic Serverホスト・マシンを構成します。ネイティブ・ソケット・リーダーは、ソケット上のデータの有無を非常に効率的な手法で調べます。ネイティブ・ソケット・リーダー実装では、リーダー・スレッドはネイティブ・ソケットをポーリングする必要がなく、アクティブなソケットに対してだけサービスとして、特定のソケットがアクティブになった場合には、(割込みによって)直ちに通知されます。

注意: アプレットはネイティブ・ソケット・リーダー実装を使用できないので、ソケット通信では十分な効果が出ません。

オペレーティング・システムに対応したネイティブ・ソケット・リーダーの実装を使用するようにWebLogic Serverホスト・マシンを構成する方法については、「サーバー・インスタンスのホスト・マシン上でネイティブのIPソケット・リーダーを構成する」を参照してください。

Javaソケット実装用にリーダー・スレッドを構成する

pure-Javaソケット・リーダー実装を使用する場合は、サーバー・インスタンスごとにソケット・リーダー・スレッドの数を適切に構成することで、ソケット通信のパフォーマンスを向上できます。最適なパフォーマンスを実現するには、WebLogic Serverでのソケット・リーダー・スレッドの数を、同時にオープンするソケットの最大数に合わせる必要があります。この構成により、リーダー・スレッドが複数のソケットにサービスしなければならない状況が回避され、ソケット・データの即時読取りが保証されます。

クラスタ内のサーバー・インスタンスについて、リーダー・スレッドの適切な数を決定する方法については、次の項「ソケットの使用数を確定する」を参照してください。

ソケット・リーダー・スレッドを構成する手順については、「サーバー・インスタンスのホスト・マシン上のリーダー・スレッドの数を設定する」を参照してください。

ソケットの使用数を確定する

個々のWebLogic Serverインスタンスは、クラスタ内で自身を除くすべてのサーバー・インスタンスに対してソケットをオープンする可能性があります。ただし、実際に使用されるソケットの最大数は、クラスタの構成によって異なります。実際には、クラスタ化されるシステムではオブジェクトが均一に(クラスタ内の各サーバー・インスタンスに)デプロイされるため、他のどのサーバー・インスタンスに対してもソケットがオープンされないのが一般的です。

クラスタでHTTPセッション状態のインメモリー・レプリケーションを使用しており、オブジェクトを均一にデプロイする場合、図3-2に示すように、各サーバー・インスタンスが最大で2個のソケットしかオープンしない可能性があります。

図3-2 均一なデプロイメントによってソケットの必要数が最小限に抑えられる

「図3-2 均一なデプロイメントによってソケットの必要数が最小限に抑えられる」の説明

この例の2つのソケットは、プライマリ・サーバー・インスタンスとセカンダリ・サーバー・インスタンスとの間でHTTPセッション状態をレプリケートするために使用されます。クラスタ化オブジェクトにアクセスする場合、WebLogic Serverが連結の最適化を行うために、ソケットは不要となります。(これらの最適化については「連結されたオブジェクトの最適化」で説明しています。) この構成では、デフォルトのソケット・リーダー・スレッド構成で十分です。

「固定」サービスのデプロイメント - サーバー・インスタンスは、固定オブジェクトにアクセスするために追加のソケットを開く必要があるので、一度に1つのみのサーバー上でアクティブになっている複数のサービスで、ソケット使用率が増加することがあります。(これは、固定オブジェクトにリモート・サーバー・インスタンスが実際にアクセスする場合にのみ考慮する必要があります。)図3-3は、クラスタ化されていないRMIオブジェクトをサーバーAにデプロイすることによる影響を示しています。

図3-3 クラスタ化されていないオブジェクトがソケットの潜在的な必要数を増加させる

「図3-3 クラスタ化されていないオブジェクトがソケットの潜在的な必要数を増加させる」の説明

この例では、各サーバー・インスタンスは、HTTPセッション状態をレプリケートするためと、サーバーA上の固定RMIオブジェクトにアクセスするために、最大で同時に3つのソケットをオープンする可能性があります。

注意: 「複数層アーキテクチャの構成に関する注意」で説明するように、複数層クラスタ・アーキテクチャのサーブレット・クラスタでは、さらにソケットが必要な場合があります。

ソケット経由のクライアント通信

クラスタのクライアントは、ソケット・リーダー・スレッドのJava実装を使用します。

WebLogic Serverでは、Javaクライアント・アプリケーションによって開かれるIPソケットの数を削減するサーバー・アフィニティ・ロード・バランシング・アルゴリズムを構成できます。サーバー・インスタンス上の複数のオブジェクトにアクセスするクライアントが、ソケットを1つだけ使用します。オブジェクトに障害が発生した場合、クライアントはソケットがすでに開かれているサーバー・インスタンスにフェイルオーバーします(可能な場合)。WebLogic Serverの旧バージョンでは、状況によっては、クライアントはクラスタ内の各サーバー・インスタンスでソケットを開きます。

最高のパフォーマンスを引き出すには、クライアントを実行するJava仮想マシン(JVM)において十分な数のソケット・リーダー・スレッドを構成します。手順については、「クライアント・マシン上のリーダー・スレッド数を設定する」を参照してください。

クラスタ全体のJNDIネーミング・サービス

クラスタ化されない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ツリー作成の仕組み

クラスタ内の各WebLogic Serverは、クラスタのすべてのメンバーが提供するサービスが入ったクラスタ全体のJNDIツリーをローカルにコピーして保守します。クラスタ全体のJNDIツリーの作成では、まず各サーバー・インスタンスをローカルのJNDIツリーにバインドします。サーバー・インスタンスが起動する(または新規サービスが動作中のサーバー・インスタンスに動的にデプロイされる)と、サーバー・インスタンスはまず、それらのサービスの実装をローカルのJNDIツリーにバインドします。実装がJNDIツリーにバインドされるのは、名前が他のサービスと重複していない場合だけです。

注意: クラスタで管理対象サーバーを起動すると、サーバー・インスタンスは、ClusterMBeanのMemberWarmupTimeoutSecondsパラメータで指定したウォームアップ時間の後で、ハートビートをリスニングしてクラスタ内で実行されている他のサーバー・インスタンスを識別します。デフォルトのウォームアップ時間は30秒です。

サーバー・インスタンスがサービスをローカルのJNDIツリーにバインドすると、レプリカ対応スタブを使用するクラスタ化オブジェクト向けに、次の手順が実行されます。クラスタ化オブジェクトの実装をローカルのJNDIツリーにバインドしたら、サーバー・インスタンスはそのオブジェクトのスタブを他のクラスタ・メンバーに送信します。クラスタの他のメンバーはマルチキャスト・アドレスまたはユニキャスト・アドレスをモニターして、リモート・サーバー・インスタンスが提供するサービスを追加したことを検出します。

図3-4は、JNDIをバインドするプロセスの一部を示しています。

図3-4 サーバーAがオブジェクトをその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上でオブジェクトが使用可能であることを同じように示します。

図3-5 ユニキャスト・メッセージの受信後は各サーバーのJNDIツリーの内容は同じ

「図3-5 ユニキャスト・メッセージの受信後は各サーバーのJNDIツリーの内容は同じ」の説明

注意: 実際のクラスタでは、オブジェクトXは均一にデプロイされ、オブジェクトを呼び出すことのできる実装は4つのサーバー・インスタンスすべてで使用可能になります。

JNDI名の競合が発生する仕組み

単純なJNDI名の競合は、サーバー・インスタンスがJNDIツリー内にバインド済でクラスタ化されていないサービスと同じ名前を使用して、別のクラスタ化されていないサービスをバインドしようとすると発生します。クラスタ・レベルのJNDI名の競合は、サーバー・インスタンスがJNDIツリー内にバインド済でクラスタ化されていないサービスと同じ名前を使用して、クラスタ化されているオブジェクトをバインドしようとしたときに発生します。

WebLogic Serverは、ローカルのJNDIツリーにサービスをバインドするときに、(クラスタ化されていないサービスの)単純な名前の競合を検出します。クラスタ・レベルのJNDIの競合は、マルチキャストまたはユニキャストを使用して新規サービスの通知を行うときに発生します。たとえば、クラスタ内のあるサーバー・インスタンス上の固定RMIオブジェクトをデプロイする場合、同じオブジェクトでレプリカ対応のものを別のサーバー・インスタンス上にデプロイすることはできません。

クラスタ内の2つのサーバー・インスタンスが、クラスタ化された別々のオブジェクトを同じ名前を使用してバインドしようとした場合、どちらのバインドもローカルには成功します。ただし、JNDI名の競合が発生するので、各サーバー・インスタンスでは、他のサーバー・インスタンスのレプリカ対応スタブをJNDIツリーにバインドすることはできません。このタイプの競合は、2つのサーバー・インスタンスのどちらかが終了するか、どちらかのサーバー・インスタンスが競合の原因となったクラスタ化オブジェクトをアンデプロイするまで解決しません。これと同じ競合は、固定オブジェクトを両方のサーバー・インスタンスが同じ名前でデプロイしようとした場合にも発生します。

均一なデプロイメントによってクラスタ・レベルのJNDIの競合を回避する

クラスタ・レベルのJNDIの競合を回避するには、すべてのレプリカ対応オブジェクトを、クラスタ内のすべてのWebLogic Serverインスタンスに均一にデプロイする必要があります。デプロイメントがWebLogic Serverインスタンス間でバランスを欠いていると、起動時または再デプロイメント時にJNDI名の競合が発生する可能性が高まります。また、クラスタ内の処理負荷のバランスも取れなくなることがあります。

特定のRMIオブジェクトまたはEJBを個々のサーバー・インスタンスに固定する必要がある場合は、そのオブジェクトのバインドをクラスタ間でレプリケートしないようにします。

WebLogic ServerによるJNDIツリー更新の仕組み

クラスタ化オブジェクトが削除(サーバー・インスタンスからアンデプロイ)されるとき、JNDIツリーの更新は、新規サービスの追加時に行われる更新と似た方法で処理されます。アンデプロイされたサービスがあったサーバー・インスタンスは、そのサービスが提供されなくなったことを示すメッセージをブロードキャストします。すでに説明したように、マルチキャスト・メッセージまたはユニキャスト・メッセージを監視しているクラスタ内の他のサーバー・インスタンスは、JNDIツリーのローカル・コピーを更新して、オブジェクトをアンデプロイしたサーバー・インスタンス上でそのサービスが使用できなくなったことを反映させます。

クライアントがレプリカ対応スタブを取得すると、クラスタ内のサーバー・インスタンスは、クラスタ化オブジェクトのホスト・サーバーの追加と削除を続行できます。JNDIツリー内の情報が変更されると、クライアントのスタブも更新されます。その後のRMIリクエストには、クライアントのスタブが常に最新の情報を持つように、必要に応じて更新情報が含まれます。

クライアントとクラスタ全体のJNDIツリーとの対話

WebLogic Serverクラスタに接続してクラスタ化オブジェクトをルックアップするクライアントは、そのオブジェクトのレプリカ対応スタブを取得します。このスタブには、そのオブジェクトの実装のホストとして使用可能なサーバー・インスタンスのリストが入っています。スタブには、ホスト・サーバー間で負荷を分散するためのロード・バランシング・ロジックも含まれています。

EJBおよびRMIクラス用のレプリカ対応スタブの詳細は、「EJBとRMIのレプリケーションとフェイルオーバー」を参照してください。

WebLogic JNDIがクラスタ環境に実装される仕組み、およびユーザー固有のオブジェクトをJNDIクライアントで使用可能にする方法については、『Oracle WebLogic Server JNDIアプリケーションの開発』のクラスタ環境でのWebLogic JNDIの使用方法に関する項を参照してください。