(57)【要約】【課題】サーバアフィニティをサポートするサーバロードバランシングのためのシステム及び方法を提供する。【解決手段】サーバアフィニティを含むサーバロードバランシングのためのシステム及び方法。システムは、サーバアフィニティを提供するＲＭＩオブジェクトに対するロードバランシングアルゴリズムをサポートするためにアプリケーションサーバに組み込むことができる。サーバアフィニティは、それが事前の接続を使用してオーバーヘッドを低減するような方法で外部クライアント接続に対してスマートロードバランシングを使用し、クライアントは、その上でサービスにアクセスするサーバインスタンスを選択する時に、アプリケーションサーバインスタンスに対するその既存の接続を考慮する。サービスがサーバアフィニティに対して設定される場合、クライアント側のスタブは、それが既に接続されているサーバインスタンスを選択するように試み、方法呼び出しに対して同じサーバインスタンスの使用を継続する。そのクライアント上の全てのスタブは、そのサーバインスタンスの使用を試みることになる。そのサーバインスタンスが利用不能になった場合、スタブは、可能であればクライアントが既に接続しているサーバインスタンスにフェイルオーバーする。
2006519441.tif 000002
【特許請求の範囲】
【請求項１】
サーバアフィニティを含むサーバロードバランシングのためのシステムであって、
複数のサーバインスタンスを含むクラスタと、
クライアントからのサービス要求の形式のサービスクライアント要求に対して前記クラスタからサーバを割り当てるロードバランシング及びアフィニティプロセッサと、
既に接続されているサーバインスタンスを選択しようと試み、サービス要求に対してその同じサーバインスタンスを使用し続けるクライアント側スタブと、
を含むことを特徴とするシステム。
【請求項２】
前記クライアント上の全てのスタブは、前記サーバインスタンスを使用しようと試みることを特徴とする請求項１に記載のシステム。
【請求項３】
前記サーバインスタンスが利用不能になった場合は、前記スタブは、可能であれば前記クライアントが既に接続されているサーバインスタンスにフェイルオーバーすることを特徴とする請求項１に記載のシステム。
【請求項４】
前記ロードバランシングの方法は、総当たり、重みベース、又はランダムのいずれかであることを特徴とする請求項１に記載のシステム。
【請求項５】
前記ロードバランシングの方法は、内部及び外部接続の両方に対して使用される総当たりロードバランシングを含むことを特徴とする請求項４に記載のシステム。
【請求項６】
前記ロードバランシングの方法は、内部及び外部接続の両方に対して使用される重みベースロードバランシングを含むことを特徴とする請求項４に記載のシステム。
【請求項７】
前記ロードバランシングの方法は、内部及び外部接続の両方に対して使用されるランダムロードバランシングを含むことを特徴とする請求項４に記載のシステム。
【請求項８】
前記ロードバランシングの方法は、外部Ｊａｖａ（登録商標）クライアント及びサーバインスタンスの間の接続を支配するサーバアフィニティを含み、
総当たりロードバランシングは、サーバインスタンス間の接続のために使用される、
ことを特徴とする請求項４に記載のシステム。
【請求項９】
前記ロードバランシングの方法は、外部Ｊａｖａ（登録商標）クライアントとサーバインスタンスの間の接続を支配するサーバアフィニティを含み、
重みベースロードバランシングは、サーバインスタンス間の接続のために使用される、
ことを特徴とする請求項４に記載のシステム。
【請求項１０】
前記ロードバランシングの方法は、外部Ｊａｖａ（登録商標）クライアントとサーバインスタンスの間の接続を支配するサーバアフィニティを含み、
ランダムロードバランシングは、サーバインスタンス間の接続のために使用される、
ことを特徴とする請求項４に記載のシステム。
【請求項１１】
サーバアフィニティを含むサーバロードバランシングの方法であって、
複数のサーバインスタンスをクラスタとして準備する段階と、
クライアントからの方法呼び出しの形のサービスクライアント要求に対して前記クラスタからサーバを割り当てる段階と、
を含み、
前記割り当てる段階は、既に接続されているサーバインスタンスを選択しようと試みて方法呼び出しに対してその同じサーバインスタンスを使用し続けるクライアント側スタブを使用する段階を含む、
ことを特徴とする方法。
【請求項１２】
前記クライアント上の全てのスタブは、前記サーバインスタンスを使用しようと試みることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記サーバインスタンスが利用不能になった場合は、前記スタブは、可能であれば前記クライアントが既に接続されているサーバインスタンスにフェイルオーバーすることを特徴とする請求項１１に記載の方法。
【請求項１４】
前記ロードバランシングの方法は、総当たり、重みベース、又はランダムのいずれかであることを特徴とする請求項１１に記載の方法。
【請求項１５】
前記ロードバランシングの方法は、内部及び外部接続の両方に対して使用される総当たりロードバランシングを含むことを特徴とする請求項１４に記載の方法。
【請求項１６】
前記ロードバランシングの方法は、内部及び外部接続の両方に対して使用される重みベースロードバランシングを含むことを特徴とする請求項１４に記載の方法。
【請求項１７】
前記ロードバランシングの方法は、内部及び外部接続の両方に対して使用されるランダムロードバランシングを含むことを特徴とする請求項１４に記載の方法。
【請求項１８】
前記ロードバランシングの方法は、外部Ｊａｖａ（登録商標）クライアント及びサーバインスタンスの間の接続を支配するサーバアフィニティを含み、
総当たりロードバランシングは、サーバインスタンス間の接続のために使用される、
ことを特徴とする請求項１４に記載の方法。
【請求項１９】
前記ロードバランシングの方法は、外部Ｊａｖａ（登録商標）クライアントとサーバインスタンスの間の接続を支配するサーバアフィニティを含み、
重みベースロードバランシングは、サーバインスタンス間の接続のために使用される、
ことを特徴とする請求項１４に記載の方法。
【請求項２０】
前記ロードバランシングの方法は、外部Ｊａｖａ（登録商標）クライアントとサーバインスタンスの間の接続を支配するサーバアフィニティを含み、
ランダムロードバランシングは、サーバインスタンス間の接続のために使用される、
ことを特徴とする請求項１４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
著作権表示
この特許文書の開示の一部分は、著作権保護を受ける内容を含んでいる。著作権の所有者は、特許商標局の特許ファイル又は記録に現れるような特許文書又は特許開示の何人による複製に対しても異議を唱えないが、それ以外は全ての著作権を留保するものである。
【０００２】
優先権の主張
本出願は、本明細書において引用により組み込まれる、２００３年２月２４日出願の米国特許仮出願第６０／４４９，７７５号（代理人ドケット番号ＢＥＡＳ−０１３４５ＵＳ０）に対する優先権を主張するものである。
【０００３】
本発明は、一般的に、アプリケーションサーバ及びサーバクラスタリングに関し、具体的には、サーバアフィニティをサポートするサーバロードバランシングのためのシステム及び方法に関する。
【背景技術】
【０００４】
アプリケーションサーバと分散システムの分野では、高度に利用可能で拡張可能なリソースを提供するためにサーバのクラスタが使用されることが多い。アプリケーションサーバの一例は、ＢＥＡ・システムズ・インコーポレーテッドの「ＷｅｂＬｏｇｉｃサーバ」である。クラスタ（「ＷｅｂＬｏｇｉｃサーバ」クラスタなど）は、同時に実行されて一緒に機能して拡張容易性と信頼性を向上させる複数のサーバインスタンスを含む。クライアントに対して、クラスタは単一のサーバに見える。クラスタを構成するサーバインスタンスは、同一のマシン上で実行することができ、又は異なるマシン上に配置することができる。クラスタの容量は、既存のマシン上のクラスタに付加的なサーバインスタンスを追加するか又はクラスタにマシンを追加して増分サーバインスタンスをホストすることにより増すことができる。クラスタ内の各サーバインスタンスは、一般的にサーバ製品の同じバージョンを実行すべきである。
【０００５】
アプリケーションサーバが存在する環境にクラスタがどのように関連するかという面では、通常、クラスタは、特定サーバ（例えば、「ＷｅｂＬｏｇｉｃサーバ」）ドメインの一部である。ドメインは、ユニットとして管理されるリソースの相互関連セットである。ドメインは、クラスタ又は非クラスタ、又はクラスタと非クラスタの組合せのインスタンスとすることができる１つ又はそれ以上のサーバインスタンスを含む。ドメインは、複数のクラスタを含むことができる。ドメインはまた、ドメイン内に配置されたアプリケーションコンポーネントと、それらのアプリケーションコンポーネントによって要求されるリソース及びサービスと、ドメイン内のサーバインスタンスとを包含する。アプリケーション及びサーバインスタンスによって使用されるリソース及びサービスの例は、マシン定義、任意的なネットワークチャンネル、Ｊ２ＥＥコンポーネント、ＥＪＢ、コネクタ、及び始動クラスを含む。管理者は、サーバインスタンスをドメインに編成するための様々な判断基準を使用することができる。例えば、管理者は、ホストされたアプリケーションの論理的分割、地理的な配慮、及び管理下にあるリソースの数又は複雑さに基づいて、リソースを複数のドメインに割り当てるように選択するであろう。
【０００６】
「ＷｅｂＬｏｇｉｃ」ドメインでは、１つの「ＷｅｂＬｏｇｉｃサーバ」インスタンスは、一般的に、「アドミニストレーションサーバ」として、すなわち、ドメイン内の他の全てのサーバインスタンスとリソースを設定し、管理し、モニタするサーバインスタンスとして作用する。各「アドミニストレーションサーバ」は、１つのドメインだけを管理する。ドメインが複数のクラスタを包含する場合、ドメイン内の各クラスタは、同一の「アドミニストレーションサーバ」を有する。クラスタ内の全てのサーバインスタンスは、同一のドメイン内に存在しなければならず、すなわち、クラスタを複数のドメインに亘って「分割する」ことはできない。同様に、ドメイン間で設定されたリソース又はサブシステムは共有することができない。例えば、１つのドメイン内でＪＤＢＣ接続プールを作成する場合に、別のドメイン内のサーバインスタンス又はクラスタと共にそれを使用することができない。（代わりに、第２のドメイン内で同様の接続プールを作らなければならない）。
【０００７】
クラスタサーバインスタンスは、それらがフェイルオーバーとロードバランシングを提供する以外は、非クラスタインスタンスと同様に挙動する。クラスタサーバインスタンスを設定するために使用される処理とツールは、非クラスタインスタンスを設定するために使用されるものと同一である。サーバクラスタは、次の利点と特徴を提供する。
拡張容易性−クラスタ上に配置されたアプリケーションの容量は、要求に合致するように動的に増すことができる。サーバインスタンスは、サービスを中断しないでクラスタに追加することができ、すなわち、アプリケーションは、クライアントとエンドユーザに影響を与えることなく実行を続けることができる。
高利用可能性−クラスタでは、サーバインスタンスが機能しない時にアプリケーションの処理を続けることができる。アプリケーションコンポーネントは、クラスタ内の複数のサーバインスタンス上にそれらを配置することによって「クラスタリングされる」ので、コンポーネントが実行されているサーバインスタンスが機能しない場合には、そのコンポーネントが配置されている別のサーバインスタンスがアプリケーション処理を続けることができる。
フェイルオーバー−フェイルオーバーは、特定の「ジョブ」、すなわち処理タスクの何らかのセットを実行しているアプリケーションコンポーネント（一般的に、次の節で「サービス」と呼ぶ）が何らかの理由で利用不能になる時に、機能しないサービスのコピーがジョブを終了させることを意味する。機能しないサービスに取って代わることができる新しいサービスに対して、ジョブに取って代わるのに利用可能な機能しないサービスのコピーがなければならない。そのジョブを終了する前に第１のサービスが機能しなかったことを判断することができるように全てのサービスの位置と作動ステータスとを定める、他のサービス及びフェイルオーバーを管理するプログラムに利用可能な情報もなければならない。中断されたジョブに取って代わるサービスが第１のサービスが機能不良になる前にジョブのどれだけを終了したか、例えば、どのデータが変更され、処理のどの段階が終了したかを知るための処理中のジョブの進展に関する、他のサービス及びフェイルオーバーを管理するプログラムに利用可能な情報もあるべきである。「ＷｅｂＬｏｇｉｃサーバ」を含めた多くのアプリケーションサーバは、標準ベースの通信技術及び装置、すなわち、マルチキャスト、ＩＰソケット、及び「Ｊａｖａ（登録商標）  Ｎａｍｉｎｇ  ａｎｄ  Ｄｉｒｅｃｔｏｒｙ  Ｉｎｔｅｒｆａｃｅ」（ＪＮＤＩ）を使用してクラスタ内のサービスの利用可能性に関する情報を共有して維持する。これらの技術により、サーバは、サービスがそのジョブを完了する前に停止したこと、及び中断されたジョブを終了させるためのサービスのコピーがどこにあるかを判断することができる。ジョブ上で何が行われたかに関する情報は、呼び出し状態である。「ＷｅｂＬｏｇｉｃサーバ」は、セッションレプリケーション及びレプリカ意識スタブと呼ばれる技術を使用して状態に関する情報を保持する。特定のサービスがそのジョブの実行を予期せずに停止する時に、レプリケーション技術は、サービスのコピーが、機能しないサービスがどこで停止したかをピックアップしてそのジョブを終了することを可能にするものである。
ロードバランシング−ロードバランシングは、アプリケーションサーバ環境内のコンピュータ及びネットワークリソースに亘るジョブと関連する通信との均一な分配である。ロードバランシングが行われるためには、特定のジョブを行うことのできるサービスの複数のコピーがなければならない。全てのサービスの位置と作動ステータスに関する情報もまた利用可能でなければならない。更に、「ＷｅｂＬｏｇｉｃサーバ」は、同一ジョブを行うための代替サービスがあるようにサービスがクラスタリングされる、すなわち、複数のサーバインスタンス上に配置されることを可能にする。「ＷｅｂＬｏｇｉｃサーバ」は、マルチキャスト、ＩＰソケット、及びＪＮＤＩを使用して、配置されたサービスの利用可能性と位置を共有して維持する。
【０００８】
クラスタプリケーション又はアプリケーションコンポーネントは、クラスタ内の複数のサーバインスタンス上で利用可能なものである。サービスがクラスタリングされた場合、そのサービスに対するフェイルオーバーとロードバランシングが利用可能である。ウェブアプリケーションは、「Ｅｎｔｅｒｐｒｉｓｅ  Ｊａｖａ（登録商標）  Ｂｅａｎ」（ＥＪＢ）、サーブレット、及び「Ｊａｖａ（登録商標）  Ｓｅｒｖｅｒ  Ｐａｇｅ」（ＪＳＰ）を含む異なるタイプのサービスで構成することができる。各サービスタイプは、制御、呼び出し、及びアプリケーション内でそれが機能する方法に関連した挙動の固有のセットを有する。この理由により、クラスタリングをサポートし、従ってロードバランシングとフェイルオーバーを提供するために「ＷｅｂＬｏｇｉｃサーバ」が使用する方法は、異なるタイプのサービスに対して変えることができる。以下のサービスのタイプ、すなわち、サーブレット、ＪＳＰ、ＥＪＢ、「Ｒｅｍｏｔｅ  Ｍｅｔｈｏｄ  Ｉｎｖｏｃａｔｉｏｎ」（ＲＭＩ）オブジェクト、「Ｊａｖａ（登録商標）  Ｍｅｓｓａｇｉｎｇ  Ｓｅｒｖｉｃｅ」（ＪＭＳ）宛先、及び「Ｊａｖａ（登録商標）  Ｄａｔａｂａｓｅ  Ｃｏｎｎｅｃｔｉｖｉｔｙ」（ＪＤＢＣ）接続は、「ＷｅｂＬｏｇｉｃサーバ」配置にクラスタリングすることができる。
【０００９】
異なるサービスタイプは、共通したある一定の挙動を有することができる。これが該当する場合、これらの同様のサービスタイプに対するクラスタリングサポート及び実施の考えは同じであろう。以下の節では、次のタイプのサービス、すなわち、サーブレット及びＪＳＰと、ＥＪＢ及びＲＭＩオブジェクトとに対する説明と教示は一般的に組み合わせられる。以下の節は、「ＷｅｂＬｏｇｉｃサーバ」が異なるタイプのサービスに提供するクラスタリング、フェイルオーバー、及びロードバランシングのサポートを簡単に説明するものである。
【００１０】
サーブレット及びＪＳＰ
「ＷｅｂＬｏｇｉｃサーバ」は、クラスタサーブレットとＪＳＰにアクセスするクライアントのＨＴＴＰセッション状態を複製することにより、サーブレットとＪＳＰに対してクラスタリングサポートを提供する。「ＷｅｂＬｏｇｉｃサーバ」は、メモリ、ファイルシステム、又はデータベースにＨＴＴＰセッション状態を保持することができる。
【００１１】
ＥＪＢ及びＲＭＩオブジェクト
ＥＪＢ及びＲＭＩオブジェクトに対するロードバランシングとフェイルオーバーは、クラスタを通してサービスのインスタンスを見つけることができるレプリカ認識スタブを使用して処理される。レプリカ認識スタブは、サービス編集処理の結果としてＥＪＢ及びＲＭＩオブジェクトに対して作られるものである。ＥＪＢ及びＲＭＩオブジェクトは、クラスタ内の全てのサーバインスタンスに均一に配置される。ＥＪＢ及びＲＭＩオブジェクトに対するフェイルオーバーは、サービスのレプリカ認識スタブを使用して達成される。クライアントが、レプリカ認識スタブを通じて機能しないサービスに対して呼び出しを行う時は、スタブは失敗を検出し、別のレプリカ上で呼び出しを再度試みる。
【００１２】
ＪＤＢＣ接続
「ＷｅｂＬｏｇｉｃサーバ」は、クラスタホストアプリケーションの利用可能性を改善するためにデータソース、接続プール、及びマルチプールを含むＪＤＢＣサービスのクラスタリングを可能にするものである。自分のクラスタに対して設定する各ＪＤＢＣサービスは、クラスタ内の各管理されたサーバ上に存在すべきである。
【００１３】
ＪＭＳ
「Ｗｅｂｌｏｇｉｃ  Ｊａｖａ（登録商標）  Ｍｅｓｓａｇｉｎｇ  Ｓｅｒｖｉｃｅ」（ＪＭＳ）アーキテクチャは、クラスタ内の任意の「ＷｅｂＬｏｇｉｃサーバ」サーバインスタンスから宛先までのクラスタ全体の透明なアクセスをサポートすることにより、複数のＪＭＳサーバのクラスタリングを実施する。「ＷｅｂＬｏｇｉｃサーバ」は、クラスタを通してＪＭＳ宛先と接続ファクトリーの分配をサポートするが、同じＪＭＳのトピック又はキューは、クラスタ内の各「ＷｅｂＬｏｇｉｃサーバ」インスタンスによって依然として別々に管理されている。
【００１４】
しかし、たとえアプリケーションサーバ環境でのクラスタリングの成功が成されても、今日のクラスタシステムの典型的な問題は、それらが、それらが処理する外部クライアント接続の数に適切に対処しないことである。方法の呼び出しは、一般的に、設定されたロードバランシングアルゴリズムにより、利用可能なサーバインスタンス間で負荷の均衡が取られる。その結果、外部クライアントとクラスタ内のサーバインスタンスとの間で多くのソケットが開かれて維持される必要がある。外部クライアント接続に対する従来のロードバランシングを無効にするが、依然としてより廉価なサーバ対サーバ接続に対してそれを可能にする新しい手法は、クラスタの安定性と拡張容易性を向上させる上で大きな有用性があると考えられる。
【００１５】
【特許文献１】米国特許仮出願第６０／４４９，７７５号
【発明の開示】
【００１６】
外部ｊａｖａ（登録商標）クライアントとクラスタ環境内のサーバインスタンスとの間に開かれたソケットの数を最小にするために、サーバアフィニティを使用することができる。本発明は、利用可能なサーバインスタンス間でロードバランシングを行う代わりに、サービスに対する方法呼び出しを既存の接続に「固着させる」ことによってこれを達成する。本発明の実施形態は、サーバアフィニティを提供するサービス及びＲＭＩオブジェクトに対する３つの新しいロードバランシングアルゴリズムを導入する。サーバアフィニティは、外部クライアント接続に対するロードバランシングをオフにし、その代わりに、クライアントは、その上でサービスにアクセスするためのサーバインスタンスを選択する時にサーバインスタンスへのその既存の接続を考慮する。サービスがサーバアフィニティに対して設定される場合、クライアント側のスタブは、それが既に接続されているサーバインスタンスを選択するように試み、方法呼び出しに対して同じサーバインスタンスの使用を継続する。そのクライアント上の全てのスタブは、そのサーバインスタンスの使用を試みることになる。そのサーバインスタンスが利用不能になった場合、スタブは、可能であればクライアントが既に接続しているサーバインスタンスにフェイルオーバーする。
【発明を実施するための最良の形態】
【００１７】
サーバアフィニティの目的は、外部クライアントとクラスタ内のサーバインスタンスとの間で開かれたソケットの数を最小にすることである。本発明の実施形態は、利用可能なサーバインスタンス間でロードバランシングを行う代わりに、サービス要求を既存の接続に「固着させる」ことによってこれを達成する。
【００１８】
ＥＪＢ及びＲＭＩオブジェクトに対するロードバランシング
本発明の実施形態は、サーバアフィニティを提供するサービス及びＲＭＩオブジェクトに対する３つの新しいロードバランシングアルゴリズムを導入する。サーバアフィニティは、外部クライアント接続に対するロードバランシングをオフにし、その代わりに、クライアントは、その上でサービスにアクセスするためのサーバインスタンスを選択する時にサーバインスタンスへのその既存の接続を考慮する。サービスがサーバアフィニティに対して設定される場合、クライアント側のスタブは、それが既に接続されているサーバインスタンスを選択するように試み、方法呼び出しに対して同じサーバインスタンスの使用を継続する。そのクライアント上の全てのスタブは、そのサーバインスタンスの使用を試みることになる。そのサーバインスタンスが利用不能になった場合、スタブは、可能であればクライアントが既に接続しているサーバインスタンスにフェイルオーバーする。
【００１９】
サーバアフィニティは、標準的ロードバランシング方法、すなわち、総当たり、重みベース、又はランダムの１つと組み合わせて使用され、ロードバランシングサービスのために全部で６つの代替方法を提供する。
総当たり：総当たりロードバランシングは、内部及び外部接続の両方に対して使用される。
重みベース：重みベースロードバランシングは、内部及び外部接続の両方に対して使用される。
ランダム：ランダムロードバランシングは、内部及び外部接続の両方に対して使用される。
総当たり−アフィニティ：サーバアフィニティは、外部Ｊａｖａ（登録商標）クライアントとサーバインスタンスの間の接続を支配する。
重みベース−アフィニティ：サーバアフィニティは、外部Ｊａｖａ（登録商標）クライアントとサーバインスタンスの間の接続を支配する。
ランダム−アフィニティ：サーバアフィニティは、外部Ｊａｖａ（登録商標）クライアントとサーバインスタンスの間の接続を支配する。
【００２０】
デフォルトにより、一実施形態では、「ＷｅｂＬｏｇｉｃサーバ」クラスタは、サービスに対して総当たりロードバランシング法を使用する。管理者は、望ましい方法に等しい「ｗｅｂｌｏｇｉｃ．ｃｌｕｓｔｅｒ．ｄｅｆａｕｌｔＬｏａｄＡｌｇｏｒｉｔｈｍ」変数を設定するための「管理コンソール」を使用することにより、全体的なクラスタに対して異なるデフォルトロードバランシング法を構成することができる。管理者はまた、ＲＭＩＣコンパイラ（ｒｍｉｃ）内の「−ｌｏａｄＡｌｇｏｒｉｔｈｍ」オプションを使用して、特定のＲＭＩオブジェクトに対するロードバランシングアルゴリズムを配置記述子内で指定することができる。ユーザがサービスに対して設定するロードバランシングアルゴリズムは、クラスタに対するデフォルトのロードバランシングアルゴリズムを無効にするものである。サービスに対するロードバランシングアルゴリズムは、クラスタサービスのために得られたレプリカ認識スタブに維持される。
【００２１】
サーバアフィニティ及び初期コンテキスト
クライアントは、クラスタ内の特定のサーバインスタンスから、又はＵＲＬ内のクラスタドレスを指定することによりクラスタから初期コンテキストを要求することができる。接続処理は、コンテキストの取得方法によって変動する。
初期コンテキストが特定の管理されたサーバから要求された場合、コンテキストは、指定されたサーバインスタンスに対する新しい接続を使用して得られる。
初期コンテキストがクラスタから要求された場合、デフォルトにより、コンテキスト要求には、一般的にクラスタサーバインスタンス間の総当たりベースでロードバランシングが行われる。
【００２２】
特定ＪＶＭとクラスタの間の既存の接続を再使用するために、コンテキストを取得する時に指定する「ｗｅｂｌｏｇｉｃ．ｊｎｄｉ．ＷＬＣｏｎｔｅｘｔ」特性のハッシュテーブル内で「ＥＮＡＢＬＥ＿ＳＥＲＶＥＲ＿ＡＦＦＩＮＩＴＹ」を真に設定する。（接続が利用不能の場合、新しい接続が作られる。）「ＥＮＡＢＬＥ＿ＳＥＲＶＥＲ＿ＡＦＦＩＮＩＴＹ」は、コンテキストがクラスタドレスから要求される時にのみサポートされる。
【００２３】
総当たりロードバランシング
本発明の実施形態（「ＷｅｂＬｏｇｉｃサーバ」において提供されるような）は、何のアルゴリズムも指定されない時には、クラスタサービススタブに対するデフォルトのロードバランシング手法として総当たりアルゴリズムを使用する。このアルゴリズムは、ＲＭＩオブジェクトとＥＪＢに対してサポートされるものである。それもまた、「ＷｅｂＬｏｇｉｃ」プロキシプラグインによって使用される方法である。総当たりアルゴリズムは、サーバインスタンスのリストを通して順番に循環する。クラスタサービスの場合、サーバリストは、クラスタサービスをホストするサーバインスタンスから成る。プロキシプラグインの場合、リストは、サーブレット又はＪＳＰをホストする全てのサーバインスタンスから成る。総当たりアルゴリズムの利点は、単純で廉価で非常に予測可能なことである。
【００２４】
重みベースロードバランシング
このアルゴリズムは、ＥＪＢ及びＲＭＩオブジェクトのクラスタリングだけに適用される。重みベースロードバランシングは、各サーバに対して予備割り当てされた重みを考慮することにより、総当たりアルゴリズムに対して改善されるものである。他のアプリケーションサーバ及び手段は、本明細書に説明したものとは別のタイプの重みベースアルゴリズムを使用することができるであろう。「クラスタ重み」フィールドにおいて、クラスタ内の各サーバに１と１００の間の数値的重みに割り当てるために「管理コンソール」内の「Ｓｅｒｖｅｒ−＞Ｃｏｎｆｉｇｕｒａｔｉｏｎ−＞Ｃｌｕｓｔｅｒ」タブを使用することができる。他のサーバに対してサーバが負荷のどの部分を担うかをこの値は判断する。全てのサーバの重みが同じである場合、それらサーバは、負荷の等しい部分を担うことになる。１つのサーバの重みが５０で他の全てのサーバの重みが１００の場合、重みが５０のサーバは、任意の他のサーバの半分だけを担うことになる。このアルゴリズムは、均一でないクラスタに総当たりアルゴリズムの利点を使用することを可能にする。重みベースアルゴリズムを使用する場合には、各サーバインスタンスに割り当てるために相対的な重みを慎重に判断すべきである。考慮すべき要素は、他のサーバとの関連でのサーバのハードウエアの処理容量（例えば、サーバに専用のＣＰＵの数と性能）、及び各サーバがホストする非クラスタ（ピン固定）サービスの数を含む。ユーザがサーバの指定された重みを変更してそれを再起動すると、新しい重み情報がクラスタ内に伝えられる。
【００２５】
ランダムロードバランシング
ロードバランシングのランダム法は、ＥＪＢ及びＲＭＩオブジェクトクラスタリングだけに適用される。ランダムロードバランシングでは、要求がサーバにランダムにルーティングされる。ランダムロードバランシングは、各サーバインスタンスが同様に設定されたマシン上で実行される均一なクラスタ配置だけに推奨される。要求のランダムな配置は、その上でサーバインスタンスが実行されるマシン間の処理容量の差を許容しない。クラスタ内のサーバをホストするマシンの処理容量がクラスタ内の他のマシンよりもかなり低い場合、ランダムロードバランシングは、それがより高い容量のマシンに与えるのと同じ程度に多くの要求をより容量の低いマシンに与えることになる。ランダムロードバランシングは、要求の累積数が徐々に増加するように、クラスタ内のサーバインスタンスに亘って要求を均一に分配する。小数の要求に亘っては、負荷は、厳密には均等に均衡化されない場合がある。
【００２６】
総当たりアフィニティ、重みベースアフィニティ、及びランダムアフィニティ
本発明は、サーバアフィニティを提供する３つの新しいロードバランシングアルゴリズム、すなわち、総当たりアフィニティ、重みベースアフィニティ、及びランダムアフィニティを導入する。サーバアフィニティは、ＪＭＳサービス、全てのＥＪＢホームインタフェース、及びステートレスＥＪＢリモートインタフェースを含めた全てのタイプのＲＭＩオブジェクトに対してサポートされる。サーバアフィニティアルゴリズムは、サーバインスタンス間のクライアント負荷の均衡化において、外部ｊａｖａ（登録商標）クライアントとサーバインスタンスの間の既存の接続を考慮する。サーバアフィニティは、それが事前の接続を使用してオーバーヘッドを低減するような方法で外部ｊａｖａ（登録商標）クライアントとサーバインスタンスの間でスマートロードバランシングを使用する。サーバアフィニティは、接続が必要なプロトコルとＱＯＳをサポートすると仮定して、外部ｊａｖａ（登録商標）クライアントからの方法呼び出しに対して、クライアントがオープン接続を有するサーバインスタンスに固着させる。失敗した場合は、サーバアフィニティは、接続が必要なプロトコルとＱＯＳをサポートすると仮定して、クライアントに対して、それがオープン接続を有するサーバインスタンスにフェイルオーバーさせる。サーバアフィニティは、サーバ対サーバ接続に対して実行されたロードバランシングには影響を及ぼさない。
【００２７】
サーバアフィニティの実施例
以下の実施例は、様々な状況下でのサーバアフィニティの影響を示すものである。各実施例において、配置されるサービスは、総当たりアフィニティに対して設定される。
【００２８】
図１は、クラスタからのコンテキストを示すものである。この実施例では、クライアントは、クラスタからコンテキストを取得する。コンテキスト上のルックアップとサービス呼び出しは、単一の接続に固着する。新しい初期コンテキストは、総当たりベースでロードバランシングが行われる。すなわち、
１．クライアントは、クラスタ（Ｐｒｏｖｉｄｅｒ＿ＵＲＬ＝ｃｌｕｓｔｅｒａｄｄｒｅｓｓ）から新しい初期コンテキストを要求し、ＭＳ１からコンテキストを取得する。
２．クライアントは、「サービスＡ」に対するコンテキスト上でルックアップを行う。ルックアップはＭＳ１に行く。
３．クライアントは、「サービスＡ」に対する呼び出しを出す。呼び出しは、クライアントが既に接続したＭＳ１に行く。「サービスＡ」に対する追加の方法呼び出しは、ＭＳ１に固着する。
４．異なる仮想マシンにある場合は、クライアントは、クラスタ（Ｐｒｏｖｉｄｅｒ＿ＵＲＬ＝ｃｌｕｓｔｅｒａｄｄｒｅｓｓ）から新しい初期コンテキストを要求し、ＭＳ２からコンテキストを取得する。
５．クライアントは、サービスＢに対するコンテキスト上でルックアップを行う。呼び出しは、クライアントが既に接続したＭＳ２に行く。サービスＢに対する追加の方法呼び出しは、ＭＳ２に固着する。
【００２９】
図２は、サーバアフィニティとフェイルオーバーを示すものである。この実施例は、サーバアフィニティがサービスフェイルオーバーに対して有する影響を示している。「管理されたサーバ」がダウンする時に、クライアントは、それが接続している別の「管理されたサーバ」にフェイルオーバーする。すなわち、
１．クライアントは、ＭＳ１から新しい初期コンテキストを要求する。
２．クライアントは、「サービスＡ」に対するコンテキスト上でルックアップを行う。ルックアップはＭＳ１に行く。
３．クライアントは、「サービスＡ」に対して呼び出しを行う。呼び出しは、クライアントが既に接続したＭＳ１に行く。「サービスＡ」に対する追加の方法呼び出しは、ＭＳ１に固着する。
４．クライアントは、ＭＳ３にピン固定されたサービスＣに対するスタブを取得する。クライアントは、ＭＳ３に対する接続を開く。
５．ＭＳ１が機能しなくなる。
６．クライアントは、「サービスＡ」に対して呼び出しを行う。クライアントは、ＭＳ１に対する接続をもはや有しない。クライアントがＭＳ３に接続されているので、それは、ＭＳ３上で「サービスＡ」のレプリカにフェイルオーバーする。
【００３０】
図３は、サーバアフィニティとサーバ対サーバ接続を示すものである。この実施例は、サーバアフィニティがサーバインスタンス間の接続に影響を与えないことを示している。すなわち、
１．ＭＳ４上のＪＳＰは、サービスＢに対するスタブを取得する。このインスタンスのＭＳ４は、ＭＳ１、ＭＳ２、及びＭＳ３に対するクライアントとして作用している。
２．ＪＳＰは、ＭＳ１上でレプリカを選択する。各方法呼び出しに対して、ＪＳＰは、その上でサービスＢが総当たりベースで利用可能な「管理されたサーバ」を通して循環する。ＭＳ１が機能しないか又は何らかの理由で使用できない場合を除いて、要求は必ずＭＳ１に行く。
【００３１】
クラスタサービスに対するパラメータベースのルーティング
パラメータベースのルーティングにより、ロードバランシングの挙動をより低レベルで制御することができる。任意のクラスタサービスに「ＣａｌｌＲｏｕｔｅｒ」を割り当てることができる。これは、呼び出しのパラメータを使用して各呼び出しの前に呼び出されるクラスである。「ＣａｌｌＲｏｕｔｅｒ」は、パラメータを自由に検査し、呼び出しがルーティングされるべきネームサーバを戻す。
【００３２】
連結サービスに対する最適化
「ＷｅｂＬｏｇｉｃサーバ」は、サービスの方法呼び出しを常にロードバランスするわけではない。殆どの場合、スタブ自体に連結されたレプリカを使用することは、リモートサーバ上に常駐するレプリカを使用するよりも効率的である。以下の図は、これを説明するものである。
【００３３】
図４は、連結最適化が方法呼び出しに対するロードバランシング論理を無効にする方法を示すものである。この実施例では、クライアントは、クラスタ内の第１の「ＷｅｂＬｏｇｉｃサーバ」インスタンスによってホストされたサーブレットに接続する。クライアントの活動に応答して、サーブレットは、「サービスＡ」に対するレプリカ認識スタブを取得する。「サービスＡ」のレプリカも同じサーバインスタンス上で利用可能なために、サービスは、クライアントのスタブに連結されると言われる。「ＷｅｂＬｏｇｉｃサーバ」は、クラスタ内の「サービスＡ」の他のレプリカにクライアントの呼び出しを分配する代わりに、「サービスＡ」のローカルな連結コピーを常に使用する。そのようにすることは、クラスタ内の他のサーバに対する対等接続を確立するネットワークオーバーヘッドを回避するので、ローカルコピーを使用することはより効率的である。ウェブアプリケーションが単一クラスタに配置される場合、連結最適化は、レプリカ認識スタブに固有のいかなるロードバランシング論理も無効にするものである。
【００３４】
トランザクション連結
基本的な連結手法に対する延長として、「ＷｅｂＬｏｇｉｃサーバ」は、同じトランザクションの一部として得られた連結クラスタリングサービスの使用を試みる。クライアントが「ユーザトランザクション」サービスを作成する時に、「ＷｅｂＬｏｇｉｃサーバ」は、トランザクションに連結されたサービスレプリカの使用を試みる。この最適化は図５に示されている。この実施例では、クライアントは、クラスタ内の第１の「ＷｅｂＬｏｇｉｃサーバ」インスタンスに接続し、「ユーザトランザクション」サービスを取得する。新しいトランザクションを開始した後に、クライアントは、トランザクションの作業をするために「サービスＡ及びＢ」を検索する。この状況では、「ＷｅｂＬｏｇｉｃサーバ」は、Ａ及びＢに対するスタブ内のロードバランシング手法には関係なく、「ユーザトランザクション」サービスと同じサーバ上に常駐するＡ及びＢのレプリカを常に使用しようと試みる。このトランザクション連結の手法は、基本的な最適化よりも一層重要である。仮にＡ及びＢのリモートレプリカが使用されるとすれば、Ａ及びＢに対する対等接続は、トランザクションがコミットされるまで固定されると考えられるので、トランザクションの継続に対して追加のネットワークオーバーヘッドがもたらされるであろう。更に、「ＷｅｂＬｏｇｉｃサーバ」は、トランザクションをコミットするために多層ＪＤＢＣ接続を使用することが必要になり、追加のネットワークオーバーヘッドをもたらすであろう。
【００３５】
トランザクション中のクラスーサービスの連結を使用して、「ＷｅｂＬｏｇｉｃサーバ」は、個々のサービスにアクセスするためのネットワークロードを低減する。サーバはまた、トランザクションの作業を行うために、多層接続ではなく単層ＪＤＢＣ接続を使用することができる。
【００３６】
ＪＭＳに対するロードバランシング
「ＷｅｂＬｏｇｉｃサーバ」ＪＭＳは、分配されたＪＭＳ宛先とクライアント接続とに対するサーバアフィニティをサポートする。デフォルトにより、「ＷｅｂＬｏｇｉｃサーバ」クラスタは、サービスをロードバランスするのに総当たり法を使用する。ＪＭＳサービスに対してサーバアフィニティを提供するロードバランシングアルゴリズムを使用するためには、望ましいアルゴリズムを設定する必要がある。ロードバランシングアルゴリズムは、「ｗｅｂｌｏｇｉｃ．ｃｌｕｓｔｅｒ．ｄｅｆａｕｌｔＬｏａｄＡｌｇｏｒｉｔｈｍ」を設定する「管理コンソール」を使用して設定することができる。
【００３７】
分配されたＪＭＳ宛先に対するサーバアフィニティ
サーバアフィニティは、分配された宛先の特徴を使用するＪＭＳアプリケーションに対してサポートされ、この特徴は、ピン固定された宛先に対してはサポートされない。ＪＭＳ接続ファクトリーに対してサーバアフィニティを設定する場合は、分配された宛先セット内の複数の物理的宛先に亘るロードバランシングコンシューマー又はプロデューサーであるサーバインスタンスは、同じサーバインスタンス上で実行されている全ての宛先に亘ってロードバランスすることを試みることになる。
【００３８】
クライアント接続に対する初期コンテキストアフィニティ及びサーバアフィニティ
システム管理者は、複数のＪＭＳサーバを設定して所定の「ＷｅｂＬｏｇｉｃサーバ」にそれらを割り当てるためのターゲットを使用することにより、クラスタ内の複数のサーバに亘るＪＭＳ宛先のロードバランシングを確立することができる。各ＪＭＳサーバは、正に１つの「ＷｅｂＬｏｇｉｃサーバ」上に配置され、宛先セットに対する要求を処理する。設定段階の間に、システム管理者は、ＪＭＳサーバに対するターゲットを指定することによってロードバランシングを可能にする。システム管理者は、複数の接続ファクトリーを設定してターゲットを使用して「ＷｅｂＬｏｇｉｃサーバ」にそれらを割り当てるためにことにより、クラスタ内の任意のサーバから宛先までのクラスタ全般に亘る透明なアクセスを確立することができる。各接続ファクトリーは、複数の「ＷｅｂＬｏｇｉｃサーバ」上に配置することができる。アプリケーションは、「Ｊａｖａ（登録商標）  Ｎａｍｉｎｇ  ａｎｄ  Ｄｉｒｅｃｔｏｒｙ  Ｉｎｔｅｒｆａｃｅ」（ＪＮＤＩ）を使用して接続ファクトリーを検索し、接続を作成してＪＭＳサーバとの通信を確立する。各ＪＭＳサーバは、宛先セットに対する要求を処理する。ＪＭＳサーバによって処理されない宛先に対する要求は、適切なサーバに転送される。「ＷｅｂＬｏｇｉｃサーバ」は、クライアント接続に対するサーバアフィニティを提供する。アプリケーションが所定のサーバインスタンスに対する接続を有する場合、ＪＭＳは、同じサーバインスタンスに対して新しいＪＭＳ接続を確立するように試みることになる。接続を作成する時に、ＪＭＳは、最初に初期コンテキストアフィニティを達成するように試みるであろう。それは、サーバインスタンスがその接続ファクトリーに対して設定されると仮定して、クライアントがその初期コンテキストに対して接続された１つ又は複数の同じサーバに接続しようと試みることになる。例えば、接続ファクトリーはサーバＡ及びＢに対して設定されているが、クライアントがサーバＣ上に「初期コンテキスト」を有する場合、接続ファクトリーは、Ａとの新しい接続を確立せず、サーバＢ及びＣ間を選択することになる。接続ファクトリーが初期コンテキストアフィニティを達成することができない場合、それは、クライアントが既に接続されているサーバに対するアフィニティの提供を試みるであろう。例えば、クライアントがサーバＡ上に「初期コンテキスト」を有し、サーバＢに対する何らかの他のタイプの接続を有すると仮定する。クライアントが次にサーバＢ及びＣに対して設定された接続ファクトリーを使用すると、それは、初期コンテキストアフィニティを達成しないことになる。接続ファクトリーは、その代わりに、サーバＣではなくそれが既に接続を有するサーバＢに対する接続を作り出そうと試みることにより、サーバアフィニティの達成を試みるであろう。接続ファクトリーが初期コンテキストアフィニティとサーバアフィニティのどちらも提供できない場合には、接続ファクトリーは、可能などこにでも自由に接続することができる。例えば、クライアントがサーバＡ上に初期コンテキストを有すると仮定すれば、サーバＢ及びＣに対して他の接続及び接続ファクトリーは何も設定されない。接続ファクトリーは、���かなるアフィニティも提供することができず、サーバＢ又はＣのいずれかに対して新しい接続を自由に試すことができる。
【００３９】
注：最後のケースでは、クライアントが同じ接続ファクトリーを使用して第２の接続を試みると、それは、それが第１の試みに対して行ったのと同じサーバに行くことになる。換言すれば、それが、第２の接続が行われた時に第１の接続に対してサーバＢを選択した場合、クライアントは、サーバＢに対する接続を有することになり、サーバアフィニティの規則が実施されることになる。
【００４０】
ＪＤＢＣ接続に対するロードバランシング
ＪＤＢＣ接続のロードバランシングは、ロードバランシングに対して設定されたマルチプールの使用を要求する。ロードバランシングサポートは、マルチプールを設定する時に選択することができるオプションである。ロードバランシングマルチプールは、高度に利用可能な挙動を提供し、更に、マルチプール内の接続プール間で負荷を均衡化する。マルチプールは、それが包含する接続プールの順序付けされたリストを有する。ロードバランシングに対してマルチプールを設定しない場合、それは、常にリスト中の第１の接続プールから接続を得ようと試みる。ロードバランシングマルチプールでは、それが包含する接続プールは、総当たり手法を使用してアクセスされる。マルチプール接続に対する各連続するクライアント要求において、リストは、接続した第１のプールがリストの周りを循環するように回転される。
【００４１】
本発明は、本開示の教示に従ってプログラムされた従来式汎用型か又は専用型のデジタルコンピュータ又はマイクロプロセッサを使用して好都合に実施することができる。ソフトウエア技術の当業者には明らかなように、本開示の教示に基づいて、熟練したプログラマーにより適切なソフトウエアコーディングを容易に準備することができる。
【００４２】
一部の実施形態では、本発明は、本発明の任意の処理を実行するコンピュータをプログラムするのに使用することができる命令をその上／その中に保存した記憶媒体（複数の媒体）であるコンピュータプログラム製品を含む。記憶媒体は、以下に限定されるものではないが、フロッピー（登録商標）ディスク、光ディスク、ＤＶＤ、ＣＤ−ＲＯＭ、マイクロドライブ、及び光磁気ディスクを含む任意の種類のディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、ＤＲＡＭ、ＶＲＡＭ、フラッシュメモリ装置、磁気又は光カード、ナノシステム（分子メモリＩＣを含む）、又は、命令及び／又はデータを保存するのに適する任意の種類の媒体又は装置を含むことができる。
【００４３】
本発明の以上の説明は、例証と説明の目的のために提供されたものである。それは、網羅的又は本発明を開示された正確な形態に限定することを意図していない。多くの変更又は変形が当業者には明らかであろう。特に、本明細書に説明した実施例は、本発明が「ＷｅｂＬｏｇｉｃ」環境で使用することができる方法を示すが、他のアプリケーションサーバ、サーバ、及びコンピュータ環境も本発明を使用して恩典を得ることができることは明白であろう。本発明が、例えばＥＪＢ及びＪＳＰのようなＪ２ＥＥコンポーネントを含む説明したもの以外のサービスと共に使用することができることも明白であろう。
【００４４】
実施形態は、本発明の原理とその実用的な応用を最も良く説明し、それによって他の当業者が想定される特定の利用に適する様々な変更と共に様々な実施形態に対して本発明を理解することができるように選択して説明したものである。本発明の範囲は、特許請求の範囲とその均等物よって規定されるものとする。
【図面の簡単な説明】
【００４５】
【図１】クライアントがクラスタからコンテキストを取得する場合の本発明の実施形態によるクラスタからのコンテキストを示す図である。
【図２】サーバアフィニティがサービスフェイルオーバーに対して有する影響を示す、本発明の実施形態によるサーバアフィニティとフェイルオーバーを示す図である。
【図３】本発明の実施形態によるサーバアフィニティとサーバ対サーバ接続とを示す図である。
【図４】リモートサーバ上に存在するレプリカを使用するのではなくスタブそれ自体と共に配置された本発明の実施形態によるレプリカを示す図である。
【図５】本発明の実施形態によりトランザクションと共に配置されたサービスレプリカを使用する試みを示す図である。
【符号の説明】
【００４６】
Ａ、Ｂ、Ｃ  サービス
【図１】
2006519441.tif 000003
【図２】
2006519441.tif 000004
【図３】
2006519441.tif 000005
【図４】
2006519441.tif 000006
【図５】
2006519441.tif 000007
【国際調査報告】
2006519441.tif 000008