(57)【特許請求の範囲】
【請求項１】
ＩＰマルチメディアサブシステム、ＩＭＳにおいて、ネットワークにおけるデータトラフィック負荷分散を決定するための方法であって、前記ネットワークが、クライアント送信元ノードと、少なくとも２つのサーバ宛先ノードとを含み、前記少なくとも２つのサーバ宛先ノードが、データ送信要求を処理するための異なるキャパシティを有し、前記方法が、
−  前記クライアント送信元ノードが、クライアント−サーバプロトコルに従って、前記ネットワークを介して前記少なくとも２つのサーバ宛先ノードにデータ送信の要求を送るステップと、
−  前記少なくとも２つのサーバ宛先ノードのそれぞれが、前記要求に応答して、その実際のキャパシティの状況に関する表示を送信するステップと、
−  前記クライアント送信元ノードが、前記サーバ宛先ノードにおける前記データトラフィックの負荷分散を決定するために前記状況表示を利用するステップと
を含み、
ネットワークを介して少なくとも２つのサーバ宛先ノードにデータ送信の要求を送るのにＤｉａｍｅｔｅｒまたはＲＡＤＩＵＳプロトコルが使用される、方法。
【請求項２】
実際のキャパシティの状況に関する前記表示が、使用されているキャパシティの量または空いているキャパシティの量を表す、請求項１に記載のトラフィック負荷分散を決定するための方法。
【請求項３】
実際のキャパシティの状況が、少なくともメモリおよび／または処理時間を考慮して決定される、請求項１または２に記載のトラフィック負荷分散を決定するための方法。
【請求項４】
前記ネットワークが、前記クライアント送信元ノードと前記サーバ宛先ノードとの間の接続を確立するためのプロキシノードをさらに含む、請求項１から３のいずれかに記載のトラフィック負荷分散を決定するための方法。
【請求項５】
ＩＰマルチメディアサブシステム、ＩＭＳにおいて、ネットワーク内で使用するためのインターフェースデバイスであって、前記ネットワークが、クライアント送信元ノードと、少なくとも２つのサーバ宛先ノードとを含み、前記少なくとも２つのサーバ宛先ノードが、クライアント送信元ノードからのデータ送信要求を処理するための異なるキャパシティを有し、前記インターフェースデバイスが、
−  前記少なくとも２つのサーバ宛先ノードからその実際のキャパシティの状況の表示を受信するための受信手段と、
−  受信された状況表示に基づいて、前記宛先ノードにおける負荷分散を決定するための処理手段と、
−  決定された負荷分散を前記クライアント送信元ノードに通信するための通信手段と
を含み、
インターフェースデバイスは、ＲＡＤＩＵＳまたはＤｉａｍｅｔｅｒプロトコルに従ってネットワークを介して少なくとも２つのサーバ宛先ノードにクライアント送信元ノードからのデータ送信要求を送るように構成される、インターフェースデバイス。
【請求項６】
前記処理手段が、ロードバランシングアルゴリズムを実行するように構成され、前記状況表示が、重み付け係数として使用される、請求項５に記載のインターフェースデバイス。
【請求項７】
前記受信された状況表示を記憶するための記憶手段をさらに含む、請求項５および６のいずれかに記載のインターフェースデバイス。
【請求項８】
ＩＰマルチメディアサブシステム、ＩＭＳにおいて、請求項５から７のいずれかに記載のインターフェースデバイスを含む、ネットワーク内で使用するためのクライアント送信元ノード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、分散ネットワークシステムにおけるデータトラフィックロードバランシングに関する。より詳細には、本発明は、そのようなロードバランシングを実行するための方法およびデバイスに関する。
【背景技術】
【０００２】
分散ネットワークシステムにおけるロードバランシング（ロードシェアリングとも呼ばれる）アルゴリズムの適用は、従来技術において一般に知られている。そのような分散ネットワークは、例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）がＩＰマルチメディアサービスを固定端末および／または移動端末に提供する通信ネットワークとすることができる。端末はＩＭＳに登録し、その後、その端末はマルチメディアサービスを要求することができる。マルチメディアサービスは、アプリケーションサーバによって提供される。ＩＭＳは端末をアプリケーションサーバに登録し、アプリケーションサーバは要求されたサービスをその端末に提供する。複数のアプリケーションサーバは、同じ端末に同時にサービスを提供することができる。
【０００３】
そのようなＩＭＳは典型的には、様々な機能を有するいくつかのノードを含む。ノードの第１の組は、ネットワークを介した通信のルーティングに関連する。そのようなノードの例は様々な呼セッション制御機能（ＣＳＣＦ）であり、呼セッション制御機能は、ネットワークに対してプロキシとして働き、認証チェックおよび認可チェックを実行し、特定のユーザのメッセージがネットワーク内の適切なノードに到着するまたはその逆も同様であることを保証することができる。第２のタイプのノードは既に述べたアプリケーションサーバ（ＡＳ）に関係し、アプリケーションサーバは特定のサービスをＩＭＳネットワークのユーザに提供する。そのようなサービスは、存在および位置サービスから、プッシュツートークオーバーセルラーネットワークサービスなどのより具体的なサービスまで多岐にわたることができる。第３のタイプのノードは、ユーザ管理と、アカウント情報、認可情報、特定のユーザが関連するサービス、特定のユーザに対して有効または無効にされたネットワークオプションなどのユーザ関連情報の記憶とに関連するノードである。第３のタイプのノードの典型的な例は、ＩＭＳネットワークにおけるユーザプロファイルおよび他のユーザ関連情報の大規模なデータベースとして働くホーム加入者サーバ（ＨＳＳ）である。ホーム加入者サーバ（ＨＳＳ）では、登録されている端末によって提供された識別情報が調べられる。ＨＳＳは端末識別情報の妥当性を確認する。
【０００４】
ＡＳまたはＣＳＣＦなどのＩＭＳネットワーク内のノードは、ＨＳＳと通信し、特定のユーザに関する情報をＨＳＳから取り出すことができる、またはＨＳＳに記憶されるか、その特定のユーザに関する記憶された情報を更新するために使用される情報をＨＳＳに供給することができる。ＨＳＳのＴＩＳＰＡＮ／３ＧＰＰ仕様は、認証、認可、請求などに使用されるユーザ関連情報に加えて、ユーザのためのアプリケーション特有の情報をＨＳＳに記憶する可能性を提供する。
【０００５】
ロードバランシングアルゴリズムは、クライアント送信元ノードからサーバ宛先ノードにデータを伝送するための複数の経路においてトラフィックを分散することによって、リソースの使用を最適化するために適用される。ロードバランシング決定は典型的には、クライアントまたはプロキシノードの送信側インターフェースで行われるので、ロードバランシングは送信側インターフェースで構成されなければならない。
【０００６】
古典的なロードシェアリングアルゴリズム（ラウンドロビン、順次、循環、ランダムなど）は、全てのレセプタが等しいキャパシティを有する構成において、すなわち、負荷がいくつかの宛先ノードにおいて均等に分散されなければならない場合に、うまく機能する。収集キャパシティ（すなわち、サーバキャパシティ）とは、クライアントノードから入ってくる新しい要求を受信し、処理するためにリソースが利用可能である度合いを指す。リソースは、計算能力、メモリサイズ、記憶装置などに対応する。
【０００７】
古典的なラウンドロビンは、図１に示されているように、クライアント−サーバ構成の異なるコレクタ（サーバ）において負荷を均等に分散する。古典的なラウンドロビンは、個々のサーバノードの収集キャパシティを考慮しない。図１に示されているように、これは、ノードが異なる収集キャパシティを有する場合に個々のノードレベルでの異なる負荷をもたらす。図上の線は、この構成における均等なロードシェアリングを表す。図１の例における４つのノードの様々な相対的な負荷割合が示されている。
【０００８】
しかし、構成が収集キャパシティが異なるサーバノードを含む、図２に示された状況では、古典的なラウンドロビン選択により、均等なロードシェアリングが一定のレベルを超えたときに、収集および処理キャパシティが少ないノードで一時的な過負荷状態が生じる。次いで、サーバは、応答を処理することができないことを示すブーリアン応答（例えば「空きなし」を意味する）を返す。次いで、送信側（クライアントノード）は、新しいコレクタ（すなわち、サーバノード）を選択し、要求を再送しなければならない。これがネットワークにおける全体的なトラフィックの増加をもたらし、したがって、リソースの非効率的な使用をもたらすことは明らかである。
【０００９】
したがって、既存のアルゴリズムは、特定の状況および環境において重大な制限を有する。
構成が拡大するとき、構成は理想的には、拡張時点での最良の費用／便益比を有するノードによって拡張される。多くの場合またはほとんどの場合でも、これは、改善された、より高性能な高キャパシティプラットフォームならびに／または異なる性能を有する異なるベンダの製品および異なるキャパシティ特性を有する製品と一致する。したがって、そのようなマルチノード構成は均一のままになっていない可能性がある。異種ノードを有するそのような拡張された構成は、上記に説明した従来技術の解決策では適切に処理することができない。
【００１０】
また、構成のいくつかのノードのキャパシティが異なる機能（またはアプリケーション）によって共有されるとき、性能低下が生じる場合がある。既存の選択アルゴリズムは、そのような一過性の状態を考慮しない。多くの場合、収集に利用可能な最小限のサーバキャパシティにとどまることを回避するために、バッチ処理は低トラフィック時間にスケジューリングされる。
【００１１】
サーバノードのキャパシティを考慮した、負荷が分散されなければならない混在した（すなわち、異なるキャパシティ）構成での古典的なロードシェアリングでは、全ての送信側は、選択規則（例えば、ロードシェアリング規則の集合）によって事前構成される必要がある。そのような集合は典型的には静的である。特定のノードがバッチジョブなどの他の処理による追加の負荷を体験すると、静的な負荷分散では解決することができない一過性の過負荷状態が生じる場合がある。
【００１２】
ほとんどのシステムは応答内の（ブーリアン）表示（「ｏｋ」または「ｎｏｔ  ｏｋ」を意味する）に依存して、次の選択を決定する。これらのバックオフ応答により、追加の負荷が生じることは明らかである。また、オーバーヘッドトラフィックは（より多くの否定応答があるので）負荷レベルとともに増加する。ブーリアンオン／オフ応答は変動性の挙動を生じさせ、場合によっては、グレースフルデグラデーション（ｇｒａｃｅｆｕｌ  ｄｅｇｒａｄａｔｉｏｎ）の代わりに不安定性および崩壊をもたらすことがある。さらに、低キャパシティサーバノードが比較的多くのトラフィックを受信するので、利用可能なキャパシティが非効率的に使用される。
【００１３】
静的な負荷分散規則の一例は、端末にアプリケーションサーバを登録するための解決策が提案されている欧州特許第２１３９１９５号に見出される。例えば、一群のサーバの間でロードバランシングを得るために使用することができる、静的な一連の定義済み規則が提供される。
【００１４】
上記で概略を述べた問題が生じ得る典型的な一例は、複数のデータジェネレータが記録を複数のデータコレクタに送信する３ＧＰＰ  Ｒｆインターフェースに関係する。別の例は、複数のＦＥＰ（フロントエンドプロセス）を使用して、ＨＳＳ（ホーム加入者サーバ）にアクセスするときの３ＧＰＰ  Ｃｘインターフェースである。当業者であれば理解するように、他のインターフェース、プロトコル、環境が可能であり得る。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】欧州特許第２１３９１９５号明細書
【非特許文献】
【００１６】
【非特許文献１】ＴＳ  ３２．２４０における３ＧＰＰ
【発明の概要】
【発明が解決しようとする課題】
【００１７】
本発明は、キャパシティが異なるノードを含む構成においてロードバランシングを使用するときに適用することができ、従来技術の解決策の制限が克服される方法およびデバイスを提供することを目的とする。
【課題を解決するための手段】
【００１８】
本発明は、ＩＰマルチメディアサブシステム（ＩＭＳ）において、ネットワークにおけるデータトラフィック負荷分散を決定するための適応方法に関する。ネットワークは、クライアント送信元ノードと、少なくとも２つのサーバ宛先ノードとを含み、少なくとも２つのサーバ宛先ノードは、データ送信要求を処理するための異なるキャパシティを有する。この方法は、
−  クライアント送信元ノードが、クライアント−サーバプロトコルに従って、ネットワークを介して少なくとも２つのサーバ宛先ノードにデータ送信の要求を送るステップと、
−  少なくとも２つのサーバ宛先ノードのそれぞれが、要求に応答して、その実際のキャパシティの状況に関する表示を送信するステップと、
−  クライアント送信元ノードが、サーバ宛先ノードにおけるデータトラフィックの負荷分散を決定するために前記状況表示を利用するステップと
を含む。
【００１９】
実際に、提案された解決策は本発明の目的を達成する。クライアントノードがデータトラフィックを送信するためのリソースを要求するたびに、サーバ宛先ノードはその実際の状況の表示、例えば、使用中である（または空いている）その利用可能な最大キャパシティの割合を提供する。次いで、サーバノードから来る情報から、リソースを要求したクライアントノードによって、次のデータトラフィック送信を考慮して、どのように負荷を平衡化させるかが決定され得る。この決定は、クライアントノードによって要求されたデータ送信にどのサーバノードを使用するかを示す。
【００２０】
好ましい実施形態では、実際のキャパシティの状況に関する表示は、使用されているキャパシティの量または空いているキャパシティの量を表す。
【００２１】
実際のキャパシティの状況は、有利には、少なくともメモリサイズ、ＣＰＵ処理時間またはこれらのパラメータの組合せを考慮して決定される。
【００２２】
別の実施形態では、ネットワークは、クライアント送信元ノードとサーバ宛先ノードとの間の接続を確立するためのプロキシノードをさらに含む。
【００２３】
第２の態様では、本発明は、ＩＰマルチメディアサブシステム（ＩＭＳ）において、ネットワーク内で使用するためのインターフェースデバイスに関し、ネットワークは、クライアント送信元ノードと、少なくとも２つのサーバ宛先ノードとを含み、少なくとも２つのサーバ宛先ノードは、データ送信要求を処理するための異なるキャパシティを有する。インターフェースデバイスは、
−  少なくとも２つのサーバ宛先ノードからその実際のキャパシティの状況の表示を受信するための受信手段と、
−  受信された状況表示に基づいて、宛先ノードにおける負荷分散を決定するための処理手段と、
−  決定された負荷分散をクライアント送信元ノードに通信するための通信手段と
を含む。
【００２４】
好ましくは、処理手段は、ロードバランシングアルゴリズムを実行するように構成され、状況表示は、重み付け係数として使用される。
【００２５】
別の実施形態では、インターフェースデバイスは、受信された状況表示を記憶するための記憶手段をさらに含む。
【００２６】
最も好ましい実施形態では、インターフェースデバイスは、ＲＡＤＩＵＳまたはＤｉａｍｅｔｅｒプロトコルに従って動作するように構成される。
【００２７】
また、本発明は、ＩＰマルチメディアサブシステム、ＩＭＳにおいて、先に説明したインターフェースデバイスを含む、ネットワーク内で使用するためのクライアント送信元ノードに関する。
【図面の簡単な説明】
【００２８】
【図１】従来技術で知られている古典的なラウンドロビンアルゴリズムを示す図である。
【図２】図１の従来技術の解決策の制限を示す図である。
【図３】Ｄｉａｍｅｔｅｒプロキシノードによるセットアップを示す図である。
【図４】本発明の例示的な適用例を示す図である。
【図５】Ｄｉａｍｅｔｅｒリダイレクト挙動を示す図である。
【図６】ラウンドロビンアルゴリズム（従来技術）の性能を示す図である。
【図７】本発明による解決策の性能を示す図である。
【発明を実施するための形態】
【００２９】
本発明では、クライアント−サーバ構成で、ネットワークにおいてマルチメディアサービスを提供するためのＩＰマルチメディアサブシステム（ＩＭＳ）が考慮される。サーバノードは全て、同じサーバキャパシティを有するわけではない。サーバキャパシティとは、ＣＰＵ時間、メモリサイズ、ＣＰＵとメモリサイズの組合せ、いくつかのシステム測定値の組合せなどに関するキャパシティを意味する。この文脈におけるキャパシティは、将来の（類似の）要求を扱う能力の表示を与えるものである。
【００３０】
最も好ましい実施形態では、クライアント−サーバ構成は、ＤｉａｍｅｔｅｒプロトコルまたはＤｉａｍｅｔｅｒの前身であるＲＡＤＩＵＳに従って動作するように構成される。
【００３１】
Ｒａｄｉｕｓ（Ｒｅｍｏｔｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｄｉａｌ  Ｉｎ  Ｕｓｅｒ  Ｓｅｒｖｉｃｅ）は、ネットワークサービスに接続し、ネットワークサービスを使用するために、集中型の認証、認可、課金（ＡＡＡ）管理をコンピュータに提供するネットワーキングプロトコルである。ＲＡＤＩＵＳプロトコルの広範なサポートおよびユビキタスな性質により、ＲＡＤＩＵＳプロトコルは、インターネットサービスプロバイダおよび企業によって、インターネットまたは内部ネットワーク、ワイヤレスネットワーク、および統合電子メールサービスへのアクセスを管理するために使用されることが多い。ＲＡＤＩＵＳは、ＵＤＰを伝送路として使用して、アプリケーションレイヤで動作するクライアント／サーバプロトコルである。ＲＡＤＩＵＳは、３つの機能、すなわち、ネットワークへのアクセスを許可する前にユーザまたはデバイスを認証すること、特定のネットワークサービスに対してこれらのユーザまたはデバイスを認可すること、およびこれらのサービスの使用に対して課金することを果たす。ＲＡＤＩＵＳは、リモートアクセス、ＩＰモビリティおよびポリシー制御に効率的にうまく対処することができない。
【００３２】
Ｄｉａｍｅｔｅｒプロトコルは、ＲＡＤＩＵＳのためのアップグレード経路を提供する。Ｄｉａｍｅｔｅｒは、認証者と認証を要求する任意のネットワークエンティティとの間の通信を制御する。Ｄｉａｍｅｔｅｒプロトコルは、ポリシー、ＡＡＡおよびリソース制御を実行するためにクライアントによって使用されるポリシープロトコルを定義する。これにより、単一のサーバは、多くのサービスのポリシーを処理することができる。ＲＡＤＩＵＳとの相違点の１つは、Ｄｉａｍｅｔｅｒプロトコルはより信頼性の高い伝送プロトコル（ＴＣＰまたはＳＣＴＰ）を使用するということである。Ｄｉａｍｅｔｅｒプロトコルは、やはり上記に説明した３ＧＰＰ  ＩＰマルチメディアサブシステム（ＩＭＳ）の発展によってさらに強化される。
【００３３】
Ｄｉａｍｅｔｅｒアプリケーションは、ソフトウェアアプリケーションではなく、Ｄｉａｍｅｔｅｒベースのプロトコルに基づくプロトコルである。それぞれのアプリケーションはアプリケーション識別子によって定義され、新しいコマンドコードおよび／または新しい必須の属性−値の組（Ａｔｔｒｉｂｕｔｅ−Ｖａｌｕｅ  Ｐａｉｒｓ）を追加することができる。新しい任意選択のＡＶＰを追加するのに、新しいアプリケーションは必要ない。
【００３４】
任意選択で、クライアント−サーバネットワークは、クライアントとサーバとの間に配置された１つまたは複数のプロキシノードをさらに含む。プロキシノードは典型的には、ルーティングタイプの機能および場合によってはバッファリングも実行するように構成される。Ｄｉａｍｅｔｅｒプロキシは、Ｄｉａｍｅｔｅｒベースのプロトコルｒｆｃ３５８８において定義される。プロキシノードを含むセットアップの例示は、図３に挙げられている。クライアントと「サーバ−ｘ」との間のリンクは、Ｄｉａｍｅｔｅｒプロキシノードを介して確立される。通信は示された順序で行われる、すなわち、クライアントがプロキシにコンタクトし、プロキシが当該のサーバと通信し、その後クライアントに戻る。
【００３５】
提案された解決策によれば、データ送信の要求がクライアントノードから受信されると、サーバノードは、例えば、最後のｘ秒間にわたる、その実際のキャパシティに関する表示を返す。この表示は、例えば、利用可能な最大キャパシティの割合、または逆に、既に使用中である割合を含むことができる。
【００３６】
ネットワークにおけるサーバノードの実際のキャパシティについての情報は、本発明によるインターフェースデバイスによって受信され、データトラフィックが送信されたときの宛先ノードにおける負荷分散を決定するために使用される。瞬間的に空いているキャパシティが大きいサーバが、より高い確率で、次のデータ送信に選択される。また、選択アルゴリズムは、より低い利用可能性表示を返したサーバノードについては、選択される確率がより低くなることを保証する。次いで、その結果として生じた実際の負荷分散に関する情報は、実際の送信が開始する前に、クライアント送信元ノードに提供される。
【００３７】
本発明によるインターフェースデバイスは、好ましくは、送信元クライアントノードに含まれる。あるいは、このインターフェースデバイスはスタンドアロンデバイスとすることができる。そうすると、そのようなスタンドアロンデバイスは典型的には、（プロトコルとしては）Ｄｉａｍｅｔｅｒプロキシノードとして挙動する。
【００３８】
提案された方法は、いくつかの利点を提供する。この方法により、レセプタ（すなわち、サーバ）の容量キャパシティに従った、複数の宛先ノードにおけるトラフィックの最適な異種分散が可能になる。したがって、通信の安定性および効率性が大幅に増大する。さらに、キャパシティおよび処理特性が異なる構成要素を使用して、データ収集キャパシティ構成を構築することができる。これにより、構成は、世代が異なるまたはベンダが異なる構成要素を用いて拡大することができる。反対に、従来技術の解決策では、収集キャパシティが追加されるたびに、既存の構成はアップグレードを必要とした。
【００３９】
本発明の重要な長所は、負荷分散が新しい状況に動的に適応するということである。例えば、バッチプロセスがサーバノードで動作しているために、そのノードの残りの収集キャパシティが一時的に低下すると、トラフィック分散は新しい最適条件を目指して動的に更新される。
【００４０】
次に、一例が提供される（図４参照）。やはり、異なるキャパシティを有する４つのサーバ宛先ノードが考慮される。それぞれのノードについて、使用されているキャパシティの部分が示されている。クライアント送信元ノードは、データトラフィックを宛先ノードに送信するための要求を送ってある。ステップ［１］は、前記要求に応答して、キャパシティに関するその実際の状況の表示を送るサーバノードを示す。この例では、サーバノードは、ＣＤＦ（ＴＳ  ３２．２４０における３ＧＰＰによって定義されたＩＭＳ機能である、課金データ機能）として示されている。サーバノードの応答メッセージは、２つの部分、すなわち、依然として利用可能である（ＣＰＵおよび／またはメモリサイズに関する）キャパシティの測定値の応答コード（要求が処理されたかどうかを示す）および追加の表示（場合によってはサブコードとして実装される）を含む。当業者であれば容易に理解するように、応答メッセージの他の構造も想到され得る。有利には、様々なノードの利用可能性に関する表示は、ＴＳ  ３２．２４０における３ＧＰＰによって定義されたＩＭＳ機能である、ＣＴＦ（課金トリガ機能）に記憶される。
ＣＴＦはＲｆ  Ｄｉａｍｅｔｅｒクライアントを実装することに留意されたい。この例では、受信された負荷表示の解釈は、実際にはＣＴＦの一部である。しかし、これはスタンドアロン機能またはＤｉａｍｅｔｅｒプロキシもしくはさらにはＤｉａｍｅｔｅｒリダイレクトに実装された機能とすることもできる。
【００４１】
実際に、Ｄｉａｍｅｔｅｒプロトコルは、Ｄｉａｍｅｔｅｒリダイレクトノードも定義する。このノードは、クライアントとサーバとの間の実際の通信の前に、ルーティング目的で参照される。シグナリング経路にリダイレクトノードがある場合、実際の負荷分散は依然としてクライアントによって実行される。この場合、ルーティングタスクはリダイレクトノードおよびクライアントノードにおいて共有される。
【００４２】
次のメッセージのためのサーバ宛先ノードを選択する場合、利用可能性情報が重み付けとしてロードバランシングアルゴリズムによって考慮され、サーバノードが選択される。起動時（または低トラフィック時）には、全てのサーバが高い利用可能性の数値（例えば、９５％）を返すので、ＣＴＦは全てのサーバにおいて負荷を均等に分散する。負荷が増加すると、より低いキャパシティを有するサーバによって返される利用可能性の数値は減少する。より多くの利用可能なキャパシティが残っている（および、したがって、より高い利用可能性の数値を返す）サーバノードは、空いているキャパシティがほとんどまたは全く残っていないサーバよりも、宛先として選択される確率が高い。比較的多くの数の要求がそのようなサーバのアドレスを有することになる。したがって、高負荷の宛先サーバが選択される頻度は低い。その結果として、少ない数の要求がそのような高負荷のサーバのアドレスを得る。このようにして、最適なロードシェアリングが達成される。サーバのうちの１つで収集状態が変化する（例えば、ＣＰＵを消費するバッチジョブが実行される）と、分散パターンは実際の状況に動的に適応される。
【００４３】
あらゆるロードバランシングアルゴリズムの目的は、サーバ毎の重み付け表示を動的に（リアルタイムで）生成し、これらの表示を使用して、（例えば、ＤＮＳで使用される）重み付けされたサーバ選択を適用することである。１つの考えられるアルゴリズムは、以下のように実装され得る。負荷分散機能は、
○  それぞれのサーバについて、負荷表示を受信し、記憶する
○  そのサーバの受信された値に一致する、サーバ毎のいくつかのエントリを有する動的なリストまたは配列を作成する。負荷インジケータが利用可能なリソースに対応するとき、そのままの値が使用され得る。負荷インジケータが使用されているリソースに対応するとき、（１００−使用されている負荷の％）情報が適用される。
【００４４】
○  配列の全ての要素において、対応するサーバのアドレス（またはそれに対するポインタ）が記憶される
送信されるべき全ての新しい要求に対して、送信側は、０から（負荷インジケータサーバ１＋負荷インジケータサーバ２など）の間のランダムな数を生成する。
ランダムな値は、動的な配列にアクセスするための指標として使用される。要求の宛先は、配列要素に記憶される。
サーバｘの受信された負荷表示が高いとき、比較的大きい数の配列エントリがサーバｘのアドレスを有することになる。サーバｙの受信された負荷表示が低いとき、その結果として、少ない数の配列エントリがそのサーバｙのアドレスを有することになる。ランダムな数がサーバｘを指す確率のほうが高い。
【００４５】
例示的なケースは、異なる収集キャパシティを有するノードのファームにおいて共有された３ＧＰＰ  Ｒｆトラフィック（Ｄｉａｍｅｔｅｒ）負荷に関する。利用可能なキャパシティのフィードバックは、最適なロードシェアリングを保証する。
【００４６】
本発明において提案された解決策によって達成される性能利得を示すために、従来技術におけるラウンドロビンアルゴリズムの性能との比較を以下に挙げる。
【００４７】
図６は、利用可能なサーバキャパシティのカットオフ閾値の８０％が使用されているときにラウンドロビン選択を適用することによって得られた性能曲線を示す。この閾値レベルに達した瞬間から「ｎｏｔ−ＯＫ」メッセージが送られる。レベルが６０％に低下すると、トラフィックが再開される。これらの値は典型的には、過負荷状態における安定性を「微調整」するために構成毎に設定される。これらの値は、サーバ状況がオン状態とオフ状態との間で変動している状況を回避するためにたどる一種のヒステリシス曲線を定義する。この図は、異なるキャパシティならびに累積スループットを有する４つのサーバを有する構成について、時間に応じた１秒毎の要求の数を示す。オーバーヘッドトラフィックが（特に、より低いキャパシティノードで）見られる。累積スループット（合計帯域幅）の大きな変動に注目されたい。最大レベル（この場合は、個々のサーバノードキャパシティの合計の８０％に等しい）に達することができない。
【００４８】
図７は、本発明によるキャパシティフィードバック解決策を使用したときに得られた性能を示す。やはり、図６の場合のサーバノードならびに最適な累積スループットの同じ構成について、時間に応じた１秒毎の要求の数が示されている。図６とは対照的に、オーバーヘッドトラフィックはもはや見られない。変動性の挙動はなくなっている。過渡期の後、累積キャパシティは最適レベルに対応する。
【００４９】
特定の実施形態を参照することによって本発明が示されてきたが、本発明が上記の例示的な実施形態の詳細に限定されないこと、また、本発明の範囲から逸脱することなく本発明が様々な変更および修正によって具体化され得ることは当業者には明らかであろう。したがって、本実施形態は、限定的なものではなく例示的なものとして、全ての点において考慮されるべきであり、本発明の範囲は、上記の説明によってではなく、添付の特許請求の範囲によって示され、したがって、特許請求の範囲と均等であるものの意味および範囲内に入る全ての変更は、特許請求の範囲に包含されるものとする。言い換えれば、根底にある基本的な原理の趣旨および範囲内にあり、その不可欠な属性がこの特許出願において特許請求される、任意のおよび全ての修正、変形または均等物を網羅することが企図される。さらに、「ｃｏｍｐｒｉｓｉｎｇ」または「ｃｏｍｐｒｉｓｅ」という語は他の要素またはステップを除外しないこと、「ａ」または「ａｎ」という語は複数を除外しないこと、また、コンピュータシステム、プロセッサまたは別の統合ユニットなどの単一の要素は特許請求の範囲に記載されたいくつかの手段の機能を実行し得ることが、この特許出願の読者によって理解されよう。特許請求の範囲におけるいかなる参照符号も、関係するそれぞれの請求項を限定するものとして解釈されるべきではない。「ｆｉｒｓｔ」、「ｓｅｃｏｎｄ」、「ｔｈｉｒｄ」、「ａ」、「ｂ」、「ｃ」などの用語は、本明細書においてまたは特許請求の範囲において使用されるとき、類似の要素またはステップを区別するために導入され、必ずしも連続した順番または時間的な順番を説明するものではない。同様に、「ｔｏｐ」、「ｂｏｔｔｏｍ」、「ｏｖｅｒ」、「ｕｎｄｅｒ」などの用語は、説明目的で導入され、必ずしも相対的な位置を示すものではない。そのように使用される用語は、適切な状況下で互いに交換可能であり、本発明の実施形態は、本発明に従って、上記に説明されたまたは示されたものとは異なる他の順序または向きで動作することができることを理解されたい。
【図１】
0005632074.tif 000002
【図２】
0005632074.tif 000003
【図３】
0005632074.tif 000004
【図４】
0005632074.tif 000005
【図５】
0005632074.tif 000006
【図６】
0005632074.tif 000007
【図７】
0005632074.tif 000008