| Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理 12c (12.1.2) E48070-02 |
|
 前 |
 次 |
この章では、WebLogic Serverクラスタが、IPソケットおよびIPユニキャストまたはマルチキャストを使用してどのように通信するかについて説明します。
クラスタ内のWebLogic Serverインスタンスは、2つの基本的なネットワーク技術を利用して互いに通信します。
IPユニキャストまたはマルチキャスト - サーバー・インスタンスが、サービスの可用性と、継続的な可用性を示すハートビートをブロードキャストするために使用します。ユニキャストかマルチキャストかの選択の詳細は、「ユニキャストかマルチキャストかを選択する際の考慮事項」を参照してください。
IPソケット - クラスタ化サーバー・インスタンス間でピア・ツー・ピア通信を行うための導管として機能します。
この章の内容は次のとおりです。
WebLogic Serverは、2つのクラスタ・メッセージング・プロトコルをサポートしています。
マルチキャスト: このプロトコルは、UDPマルチキャストを使用します。WebLogic Server 4.0以降のWebLogic Serverクラスタでサポートされています。
ユニキャスト: このプロトコルは、ポイント・ツー・ポイントTCP/IPソケットを使用します。WebLogic Server 10.0で追加されました。
この項には次のトピックが含まれます:
マルチキャストは、複数のアプリケーションが指定された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)内の複数のサブネット間に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では、マルチキャスト以外の方法でクラスタのメッセージングおよび通信を処理することもできます。ユニキャストは、マルチキャストのようなネットワーク間構成を必要としない単純な構成です。加えて、マルチキャスト・アドレスの競合によって発生する可能性がある潜在的なネットワーク・エラーが低減されます。
WebLogic Serverのユニキャスト・プロトコルは、標準のTCP/IPソケットを使用して、クラスタ・メンバー間でメッセージを送信します。すべてのネットワークおよびネットワーク・デバイスでTCP/IPソケットがサポートされているため、ユニキャストでは、クラスタ構成が容易になります。通常、クラスタ・メンバー間のネットワーク・トポロジに関係なく、追加の構成は不要です。ユニキャストは、WebLogic Serverのデフォルトのクラスタ・プロトコルです。
TCP/IPソケットはポイント・ツー・ポイント・メカニズムであるため、WebLogic Serverのユニキャスト実装は、グループ・リーダー戦略を使用して、クラスタのサイズが増大するにつれて必要となるソケット数の増加を制限します。クラスタは1つ以上のグループに分割され、各グループにはグループ・リーダーがいます。グループ・メンバーはグループ・リーダーと通信し、グループ・リーダーは、クラスタ内の他のグループ・リーダーとも通信します。グループ・リーダーに障害が発生すると、そのグループは別のグループ・リーダーを選択します。
管理対象サーバーが10台以下の小さなクラスタの場合、クラスタに含まれているグループは1つです。したがって、グループ・リーダーは1台です。グループ内の他のサーバー・インスタンスは、クラスタ・メッセージの送受信に使用するグループ・リーダーへのTCP/IPソケット接続を実行します。グループ・リーダーは、あるサーバー・インスタンスからクラスタ・メッセージを受信すると、そのメッセージをグループの他のすべてのメンバーに再送信します。グループ・リーダーは、メッセージ・リレーを行って、クラスタ内でメッセージを伝播します。
大規模なクラスタの場合、クラスタは、10台の管理対象サーバーがある複数のグループに分割されます。たとえば、16台の管理対象サーバーがあるクラスタには、2つのグループ(10台のメンバーのグループと6台のメンバーのグループ)があることになります。複数のグループを持つそれらのクラスタ内では、グループ・リーダーは、互いに直接接続されます。グループ・リーダーは、クラスタ・メッセージを受信すると、そのメッセージを自身のグループの他のメンバーに再送信するだけでなく、他のすべてのグループ・リーダーにも再送信します。これにより、クラスタ全体で、すべてのクラスタ・メッセージを受信することが可能になります。
ユニキャストを使用している場合、ハートビート・メッセージが1回でも届かないと、クラスタ・ハートビート・メカニズムにより、クラスタからサーバー・インスタンスが削除されます(TCP/IPは信頼性のあるプロトコルであると見なされているため)。ユニキャストは、15秒ごとに、ハートビートが届いたかどうかを確認します。(10秒より長い)この5秒により、メッセージが3つのホップ(リモート・グループのメンバー→リモート・グループのリーダー→ローカル・グループのリーダー)を移動し、最終的にローカル・グループのメンバーに届くための十分な時間が確保されます。デフォルトのハートビート頻度は、10秒ごとに1回のハートビートです。つまり、15秒以内に、あるサーバー・インスタンスがクラスタを離れたことが検出されるということです。ソケットの停止が検出されたり、接続の試行が失敗した場合も、サーバーがクラスタから離れたと認識されます。
ユニキャスト・メッセージングを使用する実行中のクラスタを展開または縮小する方法を理解するには、管理対象サーバーが内部的にどのようにグループに編成されるかを理解することが重要です。WebLogic Serverクラスタ内の管理対象サーバーには、それぞれ名前があります。ユニキャスト・クラスタの場合、WebLogic Serverは、それらの管理対象サーバー名を読み取り、英数字の順にソートされたリストを作成します。リスト内の最初の10台の管理対象サーバー(最大で10台の管理対象サーバー)が、最初のユニキャスト・クラスタリング・グループになります。次の10台の管理対象サーバーのセット(該当する場合)が2番目のグループになり、クラスタ内のすべての管理対象サーバーが10台またはそれ以下の管理対象サーバーのグループに編成されるまで同様の処理が行われます。各グループの最初の管理対象サーバーが、そのグループ内の他の(最大)9台の管理対象サーバーのグループ・リーダーになります。
管理対象サーバーを、実行中の既存のユニキャスト・クラスタに追加する場合、管理対象サーバー・リストの最後に来る管理対象サーバー名を使用して、それらの管理対象サーバーを追加することをお薦めします。リストの最初に来る管理対象サーバー名を追加すると、クラスタ内のクラスタ・グループ・メンバーシップの再ネゴシエーションが起こり、パフォーマンスの低下やサービスの中断が発生します。このような状況を避けるには、実行中のユニキャスト・クラスタに新しい管理対象サーバーを追加する場合、管理対象サーバー名のリストの最後に来るような管理対象サーバー名を指定します。通常、server1、server2、… serverNといった単純な命名規則を使用すると、このような問題を回避できます。管理対象サーバーの命名規則に関するこの制約は、動的クラスタ構成(第11章「動的クラスタの作成」を参照してください)、管理対象サーバーが追加されるとシャットダウンされて再起動されるクラスタ、およびマルチキャスト・クラスタには適用されません。
さらに、管理対象サーバーを、実行中のユニキャスト・クラスタに追加する場合、別のユニキャスト・グループおよびグループ・リーダーが作成される台数の管理対象サーバーを追加すると(たとえば、クラスタ構成に11台目または21台目の管理対象サーバーを追加するなど)、グループおよびグループ・リーダー・メンバーシップに変更が起こります。これにより、クラスタ間の通信の問題が発生し、パフォーマンスの低下やサービスの中断が発生するおそれがあります。構成済のユニキャスト・クラスタや動的ユニキャスト・クラスタなど、実行中のユニキャスト・クラスタに、それほどの数の管理対象サーバーを追加しないことをお薦めします(第11章「動的クラスタの作成」を参照)。この制限は、管理対象サーバーの追加時に停止および再起動されるクラスタ、またはマルチキャスト・クラスタには該当しません。
要約すると、ユニキャスト・クラスタ・メッセージング・プロトコルは、次のように動作します。
グループ・リーダー・モデルを使用します。このモデルでは、サーバー・インスタンスは各メッセージをグループ・リーダーに直接送信します。グループ・リーダーは、他のすべてのグループ・メンバーおよび他のすべてのグループ・リーダー(該当する場合)にメッセージを再送信します。
ほぼすべての環境で、追加設定なしで動作します。
ネットワーク・トポロジに関係なく、追加の構成は不要です。
ハートビートが1回でも届かないと、別のサーバーのクラスタ・メンバーシップ・リストからサーバー・インスタンスが削除されます。
実行中のユニキャスト・クラスタに動的に追加できるサーバーの数に関する制限があります。
ユニキャストはClusterMBean.isUnicastBasedClusterMessagingEnabled()を使用して構成します。このパラメータのデフォルト値はfalseです。このMBeanへの変更は動的には反映されません。変更を有効にするには、クラスタを再起動する必要があります。
特定のチャネルでのユニキャスト通信を定義する場合は、setNetworkChannelForUnicastMessaging(String NetworkChannelName)を使用します。ユニキャストを有効にすると、このBeanに定義した値に基づいてクラスタ間の通信が試行されます。ユニキャスト・チャネルが明示的に定義されていない場合は、デフォルトのネットワーク・チャネルが使用されます。
WebLogic Serverクラスタでユニキャスト通信を構成する場合は、サーバーが異なるマシンで実行している場合、それらのマシンのリスニング・アドレスまたはDNS名を明示的に指定する必要があります。
ユニキャストを使用してクラスタ通信を処理する場合は、次の点を考慮に入れてください。
クラスタのすべてのメンバーで同じメッセージ・タイプを使用する必要があります。メッセージングとしてマルチキャストとユニキャストを混在させることはできません。
クラスタ内で以前のバージョンのWebLogic Serverをサポートするには、マルチキャストを使用する必要があります。
個別のクラスタ・メンバーで、クラスタのメッセージング・タイプをオーバーライドすることはできません。
クラスタ全体を停止して、メッセージ・モードで再起動する必要があります。
JMSトピックは、クラスタ・アドレスに依存しない独自のマルチキャスト・アドレスに対してメッセージをパブリッシュするので、マルチキャスト向けに構成されたJMSトピックでもユニキャスト向けに構成されたWebLogicクラスタにアクセスできます。ただし、次の点を考慮に入れてください。
クラスタのユニキャスト通信を可能にするルーター・ハードウェア構成では、JMSマルチキャスト・サブスクライバが機能しない場合があります。
JMSマルチキャスト・サブスクライバは、マルチキャスト・アクセスが可能なネットワーク・ハードウェア構成を必要とします。
詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のWebLogic JMSでのマルチキャストの使用に関する項を参照してください。
ユニキャストは、追加設定なしで使用できるクラスタ構成であり、ほとんどのユーザー要件を満たすように思われるため、デフォルトのプロトコルとなっています。ただし、Oracleでは、両方のプロトコルを同じように完全にサポートしています。いずれのプロトコルでも、クラスタ・メンバーには、クラスタ・メッセージの送受信をタイムリーに行うための十分な処理時間があることが必要です。これにより、クラスタ・メンバーシップの不要な変更を回避し、クラスタから離れたりクラスタに再参加したりすることに伴う固有の再同期コストの発生を防ぐことができます。使用可能なリソースの過度な利用を招くため、クラスタ・メンバーシップの不要な変更が行われないようにすることをお薦めします。
ユニキャストの使用時は特に、グループ・リーダーがリソース面の制約を受けることがないようにしてください。グループ・リーダーは、メッセージ・リレーを行って、クラスタの他のメンバーにクラスタ・メッセージを配信する役目を担うからです。グループ・リーダーになんらかの遅延が生じると、複数のクラスタ・メンバーが影響を受け、そのグループ内で新しいグループ・リーダーが選出されるという結果を招くこともあります。
これに対して、マルチキャストでは、速度の遅いメンバーが実際に影響を及ぼす可能性があるのは、そのクラスタの固有のメンバーシップに対してのみです。マルチキャスト・クラスタは通常、クラスタ・メッセージの伝播に関してはより効率的であり、そのため、リソースのオーバーサブスクリプションに対する抵抗力がより高い傾向があります。これらの理由から、高いスループットが求められるクラスタ、より大規模なクラスタ(10台を超える管理対象サーバー)、または複雑なWebLogic Server構成を必要とするクラスタでは、マルチキャストの方がより望ましいオプションとなることがあります(ネットワーク環境がWebLogic ServerクラスタUDPの要件をサポートしている場合)。
各プロトコルには固有の利点があります。表3-1に、マルチキャストとユニキャストの違いをいくつか示します。
表3-1 マルチキャストとユニキャストの違いのサマリー
| マルチキャスト | ユニキャスト |
|---|---|
|
UDPマルチキャストを使用します。 |
TCP/IPを使用します。 |
|
複数のサブネットにまたがるクラスタリングでは、ルーターへの追加の構成(TTL)が必要です。 |
ネットワーク・トポロジのための追加の構成は不要です。 |
|
マルチキャストのリスニング・アドレスおよびリスニング・ポートを構成する必要があります。複数のNICが搭載されているマシン上では、使用するネットワーク・インタフェースを指定する必要がある場合があります。 |
必要なのは、リスニング・アドレスの指定のみです。クラスタ通信でのデフォルト・チャネルまたはカスタム・ネットワーク・チャネルの使用をサポートしています。 |
|
各メッセージは、ネットワークに直接配信され、ネットワークから直接受信されます。 |
各メッセージは、グループ・リーダーに配信されます。グループ・リーダーは、そのメッセージを、他のグループ・メンバー(N - 1)および他のグループ・リーダー(M - 1) (存在する場合)に再送信します。他のグループ・リーダーはその後、各自のグループ・メンバーにメッセージを再送信します。この結果、すべてのクラスタ・メッセージについて最大でN x M個のネットワーク・メッセージが存在することになります。各クラスタ・メンバーへのメッセージ配信は、1つから3つのネットワーク・ホップを経由して行われます。 |
|
すべてのサーバーは、他のすべてのサーバーの存在を認識しています。 |
グループ・リーダーは、メッセージ・リレー・ポイントとして機能し、そのグループ・メンバーおよび他のグループ・リーダーにメッセージを再送信します。 |
|
ハートビート・メッセージが3回続けて届かないと、クラスタ・メンバーシップの変更が発生し、クラスタ・リストからメンバーが削除されます。 |
ハートビート・メッセージが1回でも届かないと、クラスタ・メンバーシップの変更が発生し、クラスタからメンバーが削除されます。 |
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の使用方法に関する項を参照してください。
