(57)【要約】  【課題】  キャッシュ・サーバ・バランシング方法及びシステムを提供すること。  【解決手段】  プロキシ・キャッシュ・システムのような連係キャッシュ・サーバの集合体を含むシステムにおいて、リクエストされたオブジェクトがローカル的に見つからない場合、連係キャッシュ・サーバにリクエストが転送される。例えば、或るオブジェクトがリファレンス・スキューのためにすべてのクライアントによる高い要求状態にあるかどうか、及びホット・オブジェクトを含むキャッシュ・サーバが転送リクエストのためにオーバロードになったかどうかをオーバロード状態が決定する。それの応答して、オーバロードのキャッシュ・サーバから少ないロードのキャッシュ・サーバに或る又はすべての転送リクエストをシフトすることによって、ロードがバランスを取られる。集中型及び分散型のロード・バランシングが開示される。【選択図】  図１
2007220140.tif 000002
【特許請求の範囲】
【請求項１】
各々にブラウザが接続された、複数の連携キャッシュ・サーバに接続されたロード・モニタを有する、ロード・バランシングのためのキャッシュ・サーバ・システムにおいて、ロード・バランシングを行う方法であって、 
前記連携キャッシュ・サーバのうちの第１の連携キャッシュ・サーバが、前記ブラウザから、オブジェクトにアクセスするリクエストを受け取るステップと、 
前記ブラウザから前記連携キャッシュ・サーバにリクエストされた前記オブジェクト毎に、該オブジェクトにアクセスするリクエストが、他の連携キャッシュ・サーバに転送された転送頻度を記録するステップと、 
前記複数の連携キャッシュ・サーバの、個々の連携キャッシュ・サーバのロード状態を記録するステップと、 
前記ブラウザから、アクセスするリクエストを受けた前記オブジェクトが前記第１の連携キャッシュ・サーバ中に見つからないというキャッシュ・ミスに応答して、前記ロード・モニタが、前記連携キャッシュ・サーバから、前記ブラウザから受け取ったリクエストの転送を依頼する転送リクエストを受け取るステップと、 
前記ロード・モニタが、 前記転送リクエストに応答して、 前記キャッシュ・ミスを生じた連携キャッシュ・サーバ以外の、前記オブジェクトを所有する第１の連携キャッシュ・サーバにおけるロード状態及び前記オブジェクトに対する転送頻度に基づいて、前記第１の連携キャッシュ・サーバよりも負荷の少ない第２の連携キャッシュ・サーバに、前記オブジェクトに対する前記転送リクエストの送信先をシフトするステップと、
を含むキャッシュ・サーバ・ロード・バランシング方法。
【請求項２】
前記シフトするステップは、更に、前記ロード・モニタが、前記転送リクエストに応答して前記ロード状態及び転送頻度をチェックするステップを有する、請求項１に記載の方法。
【請求項３】
更に、前記ロード・モニタが分散型ロード・モニタであり、前記分散型ロード・モニタがローカル・ロード状態、前記各連携キャッシュ・サーバにおけるキャッシュされたオブジェクトに対する転送頻度及び所有情報をモニタ及び維持するステップを含む、請求項２に記載の方法。
【請求項４】
更に、前記各連携キャッシュ・サーバが前記ローカル・ロード状態の情報、転送頻度、及び所有情報のうちの１つ又は複数を定期的に交換及び維持するステップを含む、請求項３に記載の方法。
【請求項５】
更に、前記各連携キャッシュ・サーバが前記ローカル・ロード状態の情報、転送頻度、及び所有情報のうちの１つ又は複数個を、前記転送リクエスト及び応答のうちの１つ又は複数個と共に結合処理することによって交換するステップを含む、請求項３に記載の方法。
【請求項６】
更に、前記ロード・モニタが、前記オブジェクトに対する転送リクエストを受け取り、前記オブジェクトに対する転送頻度を更新するステップを含む、請求項１乃至請求項５のうちのいずれかに記載の方法。
【請求項７】
前記少ないロードの連携キャッシュ・サーバが前記シフト・リクエストを受け取るステップと、
前記少ないロードの連携キャッシュ・サーバが前記シフト・リクエストに応答して起点のオブジェクト・サーバからの前記オブジェクトのコピーをリクエストするステップと、を更に含む、請求項６に記載の方法。
【請求項８】
前記ロード・モニタが過去のインターバルにおける各キャッシュ・サーバのロード状態を計算するステップと、
前記ロード・モニタが過去のインターバルにおけるすべてのキャッシュ・サーバの平均的なロードを計算するステップと、
前記ロード・モニタが前記平均的なロードより上の閾値を超えるロード状態を有するキャッシュ・サーバを検出するステップと、
を更に含む、請求項１乃至請求項７のうちのいずれかに記載の方法。
【請求項９】
前記連携キャッシュ・サーバのロード状態は前記転送リクエストの数及び前記連携キャッシュ・サーバへの直接リクエストの数のウェート付けされた和である、請求項１乃至請求項８のうちのいずれかに記載の方法。
【請求項１０】
前記ロード・モニタが、前記オブジェクトまたは前記オブジェクトを含むパーティションに関するキャッシュ情報を維持するステップを更に含む、請求項１乃至請求項９のうちのいずれかに記載の方法。
【請求項１１】
前記オブジェクト又は前記パーティションのキャッシュ情報は前記オブジェクトに関連した転送頻度を含む、請求項１０に記載の方法。
【請求項１２】
前記ロード・モニタが分散型ロード・モニタであり、前記分散型ロード・モニタがロード状態、転送頻度、及び各連携キャッシュ・サーバにおけるキャッシュされたオブジェクトに対する所有情報をモニタし、ローカル的に維持するステップを更に含む、請求項１１に記載の方法。
【請求項１３】
前記各連携キャッシュ・サーバが前記ロード状態、転送頻度、及び所有情報のうちの１つ又は複数個を定期的に交換するステップを更に含む、請求項１２に記載の方法。
【請求項１４】
前記各連携キャッシュ・サーバが、前記ロード状態、転送頻度、及び所有情報のうちの１つ又は複数個を前記転送リクエスト及び応答のうちの１つ又は複数個と共に結合処理することによって交換するステップを更に含む、請求項１１、請求項１２，又は請求項１３に記載の方法。
【請求項１５】
各々にブラウザが接続された、複数の連携キャッシュ・サーバに接続されたロード・モニタを有する、ロード・バランシングのためのキャッシュ・サーバ・システムであって、 
前記ブラウザから前記連携キャッシュ・サーバにリクエストされた前記オブジェクト毎に、該オブジェクトにアクセスするリクエストが、他の連携キャッシュ・サーバに転送された転送頻度を記録する手段と、 
前記複数の連携キャッシュ・サーバの、個々の連携キャッシュ・サーバのロード状態を記録する手段と、 
前記ブラウザのアクセスによる、 前記複数の連携キャッシュ・サーバの１つにおけるオブジェクトに関するキャッシュ・ミスに応答して前記キャッシュ・ミスを生じた連携キャッシュ・サーバから転送リクエストを受け取る手段と、
前記キャッシュ・ミスを生じた連携キャッシュ・サーバ以外の、前記オブジェクトを所有する第１の連携キャッシュ・サーバにおけるロード状態及び前記オブジェクトに対する転送頻度に基づいて、前記第１の連携キャッシュ・サーバよりも負荷の少ない第２連携キャッシュ・サーバに、前記オブジェクトに対する前記転送リクエストの送信先をシフトする手段と、
を含むキャッシュ・サーバ・ロード・バランシング・システム。
【請求項１６】
前記シフトする手段は、更に、前記転送リクエストに応答して前記ロード状態及び転送頻度をチェックする手段を有する、請求項１５に記載のシステム。
【請求項１７】
更に、前記オブジェクトに対する転送リクエストを受け取り、前記オブジェクトに対する転送頻度を更新する手段を含む、請求項１５乃至請求項１６のいずれかに記載のシステム。
【請求項１８】
前記オブジェクトまたは前記オブジェクトを含むパーティションに関するキャッシュ情報を維持する手段を更に含み、前記キャッシュ情報が前記オブジェクトに関連した転送頻度を含む、請求項１５乃至請求項１７のいずれかに記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、連携キャッシュ・サーバ相互間のロード・バランシングに関し、詳しくは、ロード状態及び連携キャッシュ・サーバからリクエストが転送される頻度に基づいたロード・バランシングに関するものである。
【背景技術】
【０００２】
ワールド・ワイド・ウェブの使用法における成長は急激に増大してきた。その結果、ウェブ・オブジェクトのアクセスに対する応答時間は満足し得ないほど遅いものとなることがある。ウェブ・アクセス・タイムを改良するための１つの方法は、ブラウザと起点ウェブ・サーバとの間で１つ又は複数のプロキシ・キャッシュ・サーバを使用することである。プロキシ・キャッシュ・サーバの例は、ＩＢＭ社から出ているＮＥＴＦＩＮＩＴＹ（商標）サーバのようなマイクロソフト社のＷｉｎｄｏｗｓ  ＮＴ（商標）を走らせるＰＣサーバのクラスタ、及びＩＢＭ  ＲＳ／６０００（商標）又はＳＰ／２（商標）のようなＩＢＭ社のＡＩＸ（商標）オペレーティング・システムを走らせるワークステーション・サーバを含む。実際に、インターネット・サービス・プロバイダ（ＩＳＰ）社のような益々多くの組織が、応答時間の改良及びインターネットに対するトラフィックの減少を助けるために連携プロキシ・キャッシュ・サーバの集合体を使用しようとしている。連携キャッシュ・サーバの集合体は、信頼性及び性能に関して単一のキャッシュ・サーバを越える卓越した利点を有する。１つのキャッシュ・サーバが故障した場合でも、リクエストは他の連携キャッシュ・サーバによってサービスされることが可能である。リクエストはサーバ相互間で分散され、従って、スケーラビリティを高めることができる。結局、リクエストされたオブジェクトがそれらのキャッシュ・サーバの１つにおいて見つかる確立が高くなるように、総合キャッシュ・サイズは非常に大きいものである。
【０００３】
連係キャッシュ・サーバの場合、キャッシュ・ミスによりローカル的にサービスされ得ないリクエストは、そのリクエストされたオブジェクトを記憶する他のキャッシュ・サーバに転送されることがある。その結果、キャッシュ・サーバに到来し得るリクエストには２つの種類、即ち、直接リクエスト及び転送リクエストが存在する。直接リクエストは、クライアントから直接に受け取られるリクエストである。転送リクエストは、他のキャッシュ・サーバにおけるキャッシュ・ミスのためにそれらのクライアントに代わりに他のキャッシュ・サーバから到来するリクエストである。リクエストがキャッシュ・サーバ相互間で転送されることによって、その時点ではほとんどのクライアントが関連するイン・デマンド（又は、"ホット"）オブジェクトを１つのキャッシュ・サーバが含むということが生じる場合、そのキャッシュ・サーバは容易にオーバロードになってキャッシュ・サーバ相互間で不平等なワークロードを生じさせることになる。同じオーバロードのキャッシュ・サーバがそれに転送されたリクエストに応答することを大多数のキャッシュ・サーバは期待するので、不平等なワークロードはパフォーマンス障害を生じさせることがある。従って、プロキシ・キャッシュ・サーバの集合体の間で動的なロード・バランシングを行うための方法に対する要求が存在する。本発明はそのような要求に対処するものである。
【０００４】
ロード・バランシングは、伝統的には、到来する直接リクエストをキャッシュ・サーバ相互間で「公平に分散させる」フロント・エンド・スケジューラによって行われる。例えば、ロード・バランシングは、サン・マイクロシステムズ社によるＮＥＴＲＡ（商標）プロキシ・キャッシュによって行われるように、マッピング・テーブルを操作することによってＤＮＳレベルで行われ得るものである（サン・マイクロシステムズ社の「プロキシ・キャッシュ・サーバ  製品概要（Proxy Cache Server, Product Overview）白書 http://www.sun.com/ 参照）。サーバのクラスタ相互間のロード・バランシングは、ＩＢＭ社によって提案されたＮＥＴＤＩＳＰＡＴＣＨＥＲ（商標）のようなフロント・エンド・ルータによっても行われ得るものである（例えば、IBM Research Report, RC 20853, May 1997 における G. Goldman 及び G. Hunt 氏による "NetDispatcher: A TCP Connection Router"と題した論文参照）。ここでは、到来するリクエストはＮＥＴＤＩＳＰＡＴＣＨＥＲ（商標）によってそのクラスタにおける最もロードの少ないサーバに分配される。しかし、これらの伝統的な方法は「直接リクエスト」だけを分配し、同じプロキシ・サーバへ同時に転送されるホット・オブジェクトに対する過剰のリクエストに起因したロード・インバランス問題を処理するものではない。本発明はそのような要求に対処する。
【０００５】
連係キャッシング又はリモート・キャッシングは、システム・パフォーマンスを改善するために分散型ファイル・システムにおいて使用されている（例えば、１９９４年の Pro. of 1st Symp. on Operating Systems Design and Implementation誌の pp.1-14 における M. D. Dahlin 氏他による「連係キャッシング：ファイル・システム・パフォーマンスを改善するためにリモート・クライアント・メモリを使用する（Cooperative caching : Using Remote Client Memory to Improve File System Performance）」と題した論文参照）。ここでは、ＬＡＮ上に分散したワークステーションの集合体のファイル・キャッシュが更に効果的な総合ファイル・キャッシュを形成するように調整される。各ワークステーションは、ローカル・リクエストによって参照されたオブジェクトのみならず、リモート・ワークステーションからのリクエストによって参照され得るオブジェクトもキャッシュする。ローカル・キャッシュ・ミスの時、ローカル・リクエストは、コピーが見つかる場合、そのコピーを得ることができる他のクライアント・ワークステーションに送られることも可能である。別の方法では、オブジェクトはオブジェクト・サーバから得られる。ここで重要なことは、主として、更新の際にキャッシュ・コヒーレンシを維持する方法及びローカル的に置換されたオブジェクトを他のワークステーションのキャッシュ・メモリに移動することによってキャッシュ・ヒット率を維持する方法である。動的なロード・バランシングは存在しない。
【０００６】
連係キャッシングは、アクセス・タイムを減少させるために集合プロキシ・キャッシュ・サーバにおいても使用される。キャッシュ・ミスの時、場合によってはＷＡＮを通して起点のウェブ・サーバへ直接に指向する代わりに、キャッシュ・サーバは、ＬＡＮ又は地域的なエリア・ネットワークにおける連係キャッシュ・サーバからオブジェクトを得るようにリクエストを転送してもよい。例えば、ＳＱＵＩＤシステムにおけるローカル・キャッシュ・ミスの時、キャッシュ・サーバは（インターネット・キャッシュ・プロトコル（ＩＣＰ）を使用して）他のキャッシュ・サーバのセットにリクエストをマルチキャストする（D. Wessels氏他による「Ｓｑｕｉｄインターネット・オブジェクト・キャッシュ（Squid Internet Object Cache）」と題した論文参照  http://squid.nlanr.net/）。それらのキャッシュがリクエストされたオブジェクトを含む場合、これらの連係キャッシュ・サーバは、それを表すメッセージでもって応答する。そこで、そのリクエストされたオブジェクトは、インターネット上のオリジナル・ウェブ・サーバの代わりに、そのリクエストに最初に応答した連係キャッシュ・サーバから得られる。しかし、タイム・アウト期間を過ぎてもどれも応答しない場合、そのリクエストされたオブジェクトは起点のウェブ・サーバからフェッチされるであろう。転送リクエストのために、キャッシュ・サーバにおいてロード・インバランスが生じることがある。
【０００７】
マルチキャスティングの代わりに、ＣＲＩＳＰシステムは、他のプロキシ・サーバにおいてキャッシュされたオブジェクトを見つけるためにロジカル・セントラル・ディレクトリを使用する（１９９７年  Duke University 発行の Technical Report CS-1997-18, Dept. of Computer Science 誌における S. Gadda 氏他による「スケーラブル・インターネット・キャッシュのためのディレクトリ構造（Directory Structure for Scaleable Internet Caches）」と題した論文参照）。ここでは、キャッシュ・ミスの際、キャッシュ・サーバはディレクトリ・サーバにそのオブジェクトに関して尋ねる。キャッシュ・オブジェクト記憶装置が表す主要な意味に従って、ディレクトリ・サーバは、そのオブジェクトを含んだキャッシュを有するサーバにそのようなリクエストを送る。それが見つかった場合、そのオブジェクトはリクエスティング・サーバに送られ、一方、オリジナル・サーバはそのオブジェクトをキャッシュし続ける。リクエストされたオブジェクトのコピーを有するキャッシュがない場合、リクエスティング・サーバは起点のウェブ・サーバからインターネットを介して（場合によってはＷＡＮを介して）そのオブジェクトを得る。再び、これは、このキャッシュ・サーバに転送されたその後のリクエストによって、そのキャッシュ・サーバにおいてロード・インバランスを生じさせることがある。
【０００８】
連係キャッシュ・サーバにおいてオブジェクトを見つけるための更にもう１つの方法はハッシュ関数によるものである。その一例がキャッシュ・アレイ・ルーティング・プロトコル（ＣＡＲＰ）である（V. Valloppillil 及び K. W. Ross 氏による「キャッシュ・アレイ・ルーティング・プロトコル v1.0（Cache Array Routing Protocol v1.0」と題した論文参照  http://ircache.nlanr.net/Cache/ICP/draft-vinod-carp-v1-03.txt, Feb. 1998）。ＣＡＲＰでは、オブジェクト・スペース全体が連係キャッシュ・サーバ相互間で、各キャッシュ・サーバに対して１つのパーティションでもって区画化される。構成されたクライアント・ブラウザからのリクエストがキャッシュ・サーバによって受け取られる時、そのパーティションを識別するためにＵＲＬ又は宛先ＩＰアドレスのようなそのリクエストからのキーにハッシュ関数が適用される。リクエスティング・キャッシュ・サーバにハッシュ・パーティションが割り当てられる場合、そのリクエストはローカル的にサービスされる。そうでない場合、それは、識別されたパーティションにおける適切なキャッシュ・サーバに転送される。
【０００９】
ＳＱＵＩＤ、ＣＲＩＳＰ、及びＣＡＲＰは、ミスしたオブジェクトのためにＷＡＮを通さなければならない可能性を減ずるために他のプロキシ・サーバのキャッシュを使用する。それらは、リクエストされたオブジェクトのコピーを含み得るキャッシュを持った連係キャッシュ・サーバを見つけるための機構が異なっている。各キャッシュ・サーバは２種類のリクエスト、即ち、直接リクエスト及び転送リクエストをサービスする。直接リクエストは、プロキシ・サーバに接続されたブラウザから直接に行われるリクエストである。転送リクエストは、リクエストされたオブジェクトを持たないキャッシュを有する連係キャッシュ・サーバによって行われるリクエストである。いずれの場合も、プロキシ・サーバが所与の瞬間にキャッシュするオブジェクトのタイプに従って、それのＣＰＵは、それが直接リクエスト及び転送リクエストの両方をサービスするのに忙しいので、オーバロードなることがある。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
前述の要求に従って、本発明の１つの局面はキャッシュ・サーバ・バランシング方法を提供する。その方法は、連係キャッシュ・サーバにおける１つのオブジェクトに関するキャッシュ・ミスに応答してその連係キャッシュ・サーバから転送リクエストを受け取るステップと、ロード状態及びそのオブジェクトに対する転送頻度に基づいて連係キャッシュ・サーバ相互間で前記転送リクエストのうちのそのオブジェクトに対する１つ又は複数個の転送リクエストをシフトするステップを含む。
【００１１】
本発明のもう１つの局面は、各キャッシュ・サーバが直接リクエスト及び転送リクエストを受け取ることができ、しかも、キャッシュ・ミスが生じた場合、そのオブジェクトをキャッシュする所有キャッシュ・サーバにリクエストが転送されることがある連携キャッシュ・サーバの集合体においてロード・バランスする方法を提供する。この方法は、前記連携キャッシュ・サーバに対するロード状態及び転送頻度をモニタするステップと、そのロード状態及び転送頻度の変化に基づいて１つの連携キャッシュ・サーバから第２の連携キャッシュ・サーバに１つ又は複数個の転送リクエストをシフトするステップとを含む。
【００１２】
例えば、連携プロキシ・キャッシュ・サーバの集合体を含むシステムでは、リクエストされたオブジェクトがローカル的に見つからない場合、リクエストは他の連携キャッシュ・サーバに転送可能である。そのオブジェクトを起点ウェブ・サーバからインターネットを介してフェッチする代わりに、キャッシュ・サーバはローカル・エリア・ネットワーク又はイントラネットにおける連携キャッシュ・サーバからコピーを得ることができる。１つのオブジェクトへのアクセスのための平均的な応答時間を連携キャッシュ・サーバによってかなり改善することが可能である。しかし、リファレンス・スキューのために、或るオブジェクトはすべてのクライアントによる高い需要があることがある。その結果、それらのホット・オブジェクトを含むプロキシ・キャッシュ・サーバは、他のキャッシュ・プロキシ・キャッシュ・サーバから到来する転送リクエストによってオーバロードになり、パフォーマンス障害を生じることがある。本発明によれば、出願人は、オーバロードのキャッシュ・サーバから少ないロードのキャッシュ・サーバに幾つかの又はすべての転送リクエストをシフトすることによる、連携プロキシ・キャッシュ・サーバの集合体のロード・バランシング方法を提案する。
【課題を解決するための手段】
【００１３】
本発明によるキャッシュ・サーバ・ロード・バランシング方法の一例は、連携キャッシュ・サーバにおけるオブジェクトに関するるキャッシュ・ミスに応答して連携キャッシュ・サーバから転送リクエストを受け取るステップと、ロード状態及びそのオブジェクトに対する転送頻度に基づいて連携キャッシュ・サーバ相互間でそのその転送リクエストのうちのそのオブジェクトに対する１つ又は複数個の転送リクエストをシフトするステップとを含む。
【００１４】
本発明は、所有キャッシュ・サーバにおけるロード状態及びそれに対する転送頻度を周期的にモニタするフィーチャ、及び、そのモニタリングに応答して、キャッシュされたオブジェクトに関する１つ又は複数のその後の転送リクエストを、その所有キャッシュ・サーバから１つ又は複数の連携キャッシュ・サーバに先見的にシフトするためのフィーチャも含む。別の方法として、そのシフトするステップは、更に、転送リクエストの受け取りに応答してロード状態及び転送頻度をチェックするステップを含む。１つの例では、連携キャッシュ・サーバのロード状態は、前記連携キャッシュ・サーバへの前記転送リクエストの数及び直接リクエストの数のウェート付けされた和である。別の例では、キャッシュ情報が各オブジェクト・レベル又はオブジェクト・レベルのパーティションにおいて維持される。
【００１５】
本実施例は、集中型環境及び分散型環境の両方及びそれらの種々のハイブリッドを含んだ、ロード・バランシングを遂行するための種々のインプリメンテーションを含む。例えば、分散型ロード・モニタは、各連携キャッシュ・サーバにおけるキャッシュされたオブジェクトに対するローカル・ロード状態、転送頻度、及び所有の情報をモニタし及び維持するために使用可能である。連携キャッシュ・サーバは、ロード状態情報、転送頻度、及び所有の情報のうちの１つ又は複数個を定期的に交換及び維持することができる。例えば、連携キャッシュ・サーバは、ロード状態情報、転送頻度、及び所有の情報の１つ又は複数個を、１つ又、複数の転送リクエスト及び応答と結合することによって情報を交換することができる。
【００１６】
もう１つの例では、オーバロードの連携キャッシュ・サーバが少ないロードの連携キャッシュ・サーバを識別することができ、シフト・リクエスト及びキャッシュされたオブジェクトのコピーを（その後そのオブジェクトをキャッシュする）少ないロードの連携キャッシュ・サーバにコミュニケートすることができるので、そのオブジェクトに対するその後のリクエストは転送されないであろう。別の代替え方法として、オーバロードの連携キャッシュ・サーバは、少ないロードの連携キャッシュ・サーバにシフト・リクエストコミュニケートすることができる。その後、その少ないロードの連携キャッシュ・サーバは、シフト・リクエストに応答して起点オブジェクト・サーバからオブジェクトのコピーを得る。更にもう１つの代替え方法では、所有キャッシュ・サーバは、その後の転送リクエストがシフトされるように、１つ又は複数の他の連携キャッシュ・サーバにシフト・リクエスト・メッセージをマルチキャストすることができる。
【００１７】
本発明の完全分散型のインプリメンテーションでは、連携キャッシュ・サーバは、それぞれ、ロード状態をモニタし且つローカル的に維持するための分散型ロード・モニタを含むことができ、キャッシング・テーブルのローカル・コピーにおいて又はハッシュ関数によって転送頻度及び所有情報を維持することもできる。連携キャッシュ・サーバは、キャッシング・テーブルのローカル・コピー又はハッシュ関数によって所有情報を修正することができる。
【００１８】
本実施例は、オブジェクトに関する所有を少なくとも２つの連携キャッシュ・サーバ相互間で共同所有に修正するためのフィーチャ及びその後のオブジェクト・リクエストをそのオブジェクトの１つ又は複数の少ないロードの共同所有者に転送するための更に別のフィーチャを含む。共有オブジェクトに対するロード状態の減少が検出される場合、そのロード状態の減少に応答して、共同所有は一体化されることが可能である。
【００１９】
更にもう１つの例では、ロード状態及び転送頻度に基づいて１つ又は複数の転送リクエストをシフトすることは、オブジェクトのコピーを所有キャッシュ・サーバから１つ又は複数の連携キャッシュ・サーバにコミュニケートすることによって達成され得るし、従って、（そのオブジェクトが受領側のキャッシュに残っている限り）その後のリクエストは転送されないであろう。
【００２０】
本実施例による集中型環境の一例は、連携キャッシュ・サーバに対する転送頻度及びロード状態を維持するための集中型論理的ロード・モニタを含む。そのロード・モニタは、それらのキャッシュ・サーバにおけるロードをモニタするためのロード・テーブル、並びに転送頻度をモニタし且つオブジェクトを見つけるためのキャッシング・テーブル（又は、ハッシュ関数）を維持するための論理的ディレクトリ・サーバを含むことがある。そのディレクトリ・サーバは、ローカル的にミスしたオブジェクトに対する他のキャッシュ・サーバにおけるオブジェクト・ロケーションに関するリクエストを受け取り、ローカル的にミスしたオブジェクトに対するリクエストを転送する。そのディレクトリ・サーバは、オブジェクト・ロケーションに対するリクエストに応答して、ロード及び所与のオブジェクトに対する転送頻度に基づいてキャッシング・テーブルを操作することによって連携キャッシュ・サーバの間でリクエストのロード・バランスをとる。
【発明を実施するための最良の形態】
【００２１】
集中型アーキテクチャ及び分散型アーキテクチャの両方に対する本実施例のロード・バランシング・ロジックの例を説明することにする。図１は、本発明において提案された集中型ロード・バランシング・ロジックを適用し得る、プロキシ・キャッシュ・サーバの集合体を使用したシステムのブロック図の一例を示す。図示のように、このシステムはプロキシ・キャッシュ・サーバ１５０の集合体を含む。単一レベルのキャッシュ・サーバしか示されてないけれども、キャッシュ・サーバ１５０のハイアラーキがあってもよい。通常のように、これらのプロキシ・キャッシュ・サーバは、ローカル・エリア・ネットワーク（ＬＡＮ）又はリージョナル・エリア・ネットワーク、或いはイントラネット１４０を介して相互に接続される。各キャッシュ・サーバ１５０は広域ネットワーク（ＷＡＮ）又はインターネット１１０にも接続される。そのＷＡＮ及び１１５を介して、これらのプロキシ・キャッシュ・サーバは、それら自身のキャッシュにおいてローカル的に見つけることができないオブジェクトに対する起点ウェブ・サーバにも届き得るものである。
【００２２】
本実施例によれば、論理的ロード・モニタ１２０は、連携キャッシュ・サーバ１５０のロード状態及び転送頻度（図３）をモニタするためのロード・バランシング・ロジック１３０を含み、それらに対してロード・バランシングを施す。後述するように、ロード・モニタ１２０の種々のフィーチャは、１つ又は複数のキャッシュ・サーバに常駐することができ、キャッシュ・サーバの間で重複及び分散されることが可能であり、又はパーソナル・コンピュータ（ＰＣ）サーバ又はワークステーションのような他の専用システムに常駐することができる。集中型のシステム構成では、ロード・モニタ１２０は、転送リクエスト１２５をキャッシュ・サーバに指向させる場合に中央ディレクトリ機能を遂行することができる。１つ又は複数のブラウザ１６０が各キャッシュ・サーバ１５０に接続するように構成可能である。直接リクエスト１５５は、通常のブラウザ１６０を走らせるコンピュータのようなクライアントからその構成されたキャッシュ・サーバ１５０に送られる。リクエストされたオブジェクトがローカル的に見つかる場合、それはブラウザに戻される。そうでない場合、キャッシュ・サーバ１５０はロード・モニタ１２０にメッセージをコミュニケートする。ロード・モニタ１２０に関する種々の例示インプリメンテーションを以下で更に詳細に説明することにする。ロード・インバランス状態又は傾向が終わらない場合、ロード・モニタ１２０は、そのリクエストされたオブジェクトを所有キャッシュ・サーバ１５０にリクエスト１２５を転送する。そこで、その所有キャッシュ・サーバは、例えば、ＬＡＮ１４０を介してリクエスティング・キャッシュ・サーバにそのリクエストされたオブジェクトを送る。
【００２３】
実際のロード・インバランスが識別されるか又はロードの傾向に基づいて予測される場合、ロード・モニタ１２０は、オーバロードのキャッシュ・サーバから１つ又は複数のアンダーロードの（少ないロードの）キャッシュ・サーバへの転送リクエストのシフトを開始させる。更に詳細に後述するように、所有のシフトは、サーバ１５０のロード状態及び転送頻度、並びに他の要素に基づき得るものである。
【００２４】
図３及び図４は、ロードモニタによって維持された２つのテーブルのデータ・フォーマットの例を示す。図示のように、それらのテーブルはロード・テーブル１０２及びキャッシング・テーブル１０１を含む。単一のテーブル又は種々の他のデータ構造が代替的に又は等価的に使用可能であることは当業者には明らかであろう。ロード・テーブル１０２は、オーバロード及びアンダローダのサーバが識別されるように、各キャッシュ・サーバ１５０（Ａ、Ｂ、Ｃ・・・"１０２２"）のロード状態１０２１を含む。通常のように、ロード状態１０２１は各キャッシュ・サーバをプローブすることによって定期的に更新可能である。キャッシュ・サーバのロードは、転送リクエストの数及び直接リクエストの数のウェート付けされた和であってもよい。オーバロードのキャッシュ・サーバ１５０は任意の一般的な技法によって識別可能である。例えば、ロード・モニタは過去のインターバルにおけるすべてのプロキシ・キャッシュ・サーバの平均的ロードを計算することができる。オーバロードのキャッシュ・サーバは、その平均的なロードより上の閾値を越えたロードを有するサーバとなり得る。
【００２５】
本実施例によれば、ロード・バランシングは、オーバロードの量及びキャッシュされたオブジェクトの転送頻度１０１１によるロードを考慮している。このように、ロード・モニタは、オーバロードのキャッシュ・サーバＣ"１０２１３"からアンダロードのキャッシュ・サーバＡ"１０２１１"にいくつかの又はすべての転送リクエストをシフトし続けるべきかどうかを決定することができる。キャッシング・テーブル１０１は、１つのオブジェクト又はオブジェクトのパーティションに関する転送頻度１０１１及び所有１０１２の情報を含んでいる。後述するように、所有は、Ａ"１０１２２"におけるような単独であってもよく、或いは２つ又はそれ以上の連携キャッシュ・サーバの間の共有Ｂ、Ｃ"１０１２１"及びＣ，Ａ"１０１２３"であってもよい。転送頻度１０１１は、オブジェクトに対するリクエストがロード・モニタを通して転送された回数を表す。転送頻度１０１１に加えて、キャッシング・テーブル１０１は、オブジェクトに対するリクエストが転送された最新の時間を表すタイムスタンプ１０１３を維持することもできる。更に、オブジェクト又はパーティションに対するキャッシング情報は、ロード・モニタ１２０によってオブジェクトｉｄ又はパーティションｉｄ１０１０に対する所与の時間的期間における転送頻度（カウント／時間）を含むことが可能である。代替え方法として、オブジェクトｉｄ／パーティションｉｄ１０１０はオブジェクト識別子に関するハッシュ関数に基づくものであってもよく、或いは、ウェブ・サーバにおいてオブジェクトが編成されるというディレクトリ構造に基づくものであってもよい。パーティションの場合、１つのパーティションに属する如何なるオブジェクトもロード・モニタによって転送されるであろう。所有のシフトは、サーバのロード状態、転送頻度１０１１、及びタイム・スタンプ情報のような他の情報に基づくことも可能である。
【００２６】
図５は、キャッシュ・ミスのために、キャッシュ・サーバ１５０からのリクエスト１２５に応答してロード・モニタ１２０によって取られるステップに対するロジック・フローの一例を示す。図示のように、ステップ２０１において、リクエストされたオブジェクト／パーティションがキャッシング・テーブルにおいて見つかるかどうか知るためのチェックが行われる。それが見つからない場合、ステップ２０２において、そのオブジェクト／パーティションのための新しいエントリが作成され、１つのキャッシュ・サーバがそれの所有者として割り当てられる。キャッシング・テーブルにおいてエントリが見つかる場合、ステップ２０３において、転送頻度１０１１が更新される、例えば、１だけインクレメントされる。そこで、ロード・モニタは、ステップ２０４において、その所有者がその時オーバロードであるかどうか（及び、転送頻度１０１１がそれに対する重要な貢献者であること）を知るためにロード・テーブル１０２を調べる。それが肯定される場合、ステップ２０５において、ロード・モニタはアンダロード（又は少ないロードの）キャッシュ・サーバを見つけ、それをそのリクエストされたオブジェクトの新しい（又は、共同の）所有者"１０１２２"として割り当てる。従って、キャッシング・テーブル１０１におけるオブジェクトに対する所有情報１０１２が更新される。そのロジック・フローがキャッシング・テーブル１０１又は使用される他のデータ構造における共同所有"１０１２３"又は階層的所有１０１２より成り得ることは当業者には明らかであろう。そこで、リクエスト（おそらく、そのリクエストされたオブジェクトのコピーを有するリクエスト）が、ステップ２０６において、新しい単独の所有者"１０１２２"（又は、共同所有者 "１０１２３"）に転送される。
【００２７】
別の方法として、新しい所有者は、起点オブジェクト・サーバから、例えば、インターネット１１０を介してオブジェクト・コピーを得るようにリクエストすることが可能である。所与のオブジェクトｉｄ／パーティションｉｄ１０１０及びキャッシュ・サーバ（所有１０１２）に対して、少なくとも部分的には高い転送頻度１０１１のために、ロード・チェック・ステップ２０４が先見的に、即ち、定期的に、或いは、識別されたオーバロード又はオーバロード傾向のロード状態１０２１に応答して遂行され得ることは当業者には明らかであろう。それが肯定される場合、ステップ２０５において、ロード・モニタはアンダロードの（少ないロードの）キャッシュ・サーバを見つけ、それをそのリクエストされたオブジェクトの新しい（又は、共同の）所有者として割り当て、おそらく、上記のように新しい（共同の）所有者にそのオブジェクトのコピーを送る。逆に、ステップ２０８において共同所有モデルが使用される場合、共同所有オブジェクト（ｐ  "１０１０１"）に対するロード状態１０２１１及び転送頻度１０１１１が所定の閾値以下に降下する時、ステップ２０９において、共同所有（Ｂ，Ａ  "１０
１２１"）は、例えば、他のホット・オブジェクトのための空間を作るために、
単独の所有及びキャッシュ・サーバＢ，Ａ  "１０１２１"の１つからそれらの追放されたコピーの１つにマージされることもあり得る。
【００２８】
図６は、１つのオブジェクトに対するリクエストがブラウザ１６０から直接に受け取られる（１５５）又はロード・モニタ１２０から転送される（１２５）時のキャッシュ・サーバに対するロジック・フローの一例を示す。図示のように、ステップ３０１において、それは、先ず、リクエストされたオブジェクトがそれにキャッシュにおいてローカル的に見つかるかどうかを知るためのチェックを行う。それが肯定される場合、ステップ３０２において、それはオブジェクトを戻し、ステップ３０６において、プロセスは終了する。そうでない場合、ステップ３０３において、リクエストが直接リクエストであるか又は転送リクエストであるかを知るためのチェックが行われる。それが直接リクエストである場合、ステップ３０４においてそのリクエストはロード・モニタに送られ、ステップ３０６においてプロセスは終了する。一方、そのリクエストが転送リクエストである場合、ステップ３０５においてキャッシュ・サーバは起点のウェブ・サーバからオブジェクトをフェッチし、そのオブジェクトを戻すであろう。そこで、ステップ３０６においてプロセスは終了である。
【００２９】
次に、図１及び図２に戻ると、例えば、キャッシュ・サーバＣ  "１０２２３"に接続しているブラウザ１６０がオブジェクトｐ  "１０１０１"を接続するものと仮定する。キャッシング・テーブル１０１から、オブジェクトｐ  "１０１０１"がサーバＣにおいてキャッシュされず、（Ｂ，Ａ  "１０１２１"が、最初は、Ｂによって単独で指定されるだけであると仮定すると）キャッシュ・サーバＢにおいてキャッシュされる（キャッシュ・サーバＢによって「所有される」）ことがわかる。オブジェクトｐにおけるキャッシュ・ミスに応答して、サーバＣ  "１０２２３"はオブジェクトｐに対するリクエストをロード・モニタ１２０に送る。サーバＢにおけるロード状態"１０２１２"及びｐ  "１０１０１"に対するリクエストの転送頻度１０１１に従って、ロード・モニタは、オブジェクトｐのコピーをサーバＣに送ることを要請するリクエストをサーバＢに転送することが可能である。或いは、サーバＢがその時オーバロードである場合又はそのような傾向にある場合、ロード・モニタは、オブジェクトｐの新しい（又は、Ｂ，Ａ  "１０１２１"におけるように共同の）所有者として働くようにアンダロードの（又は、少ないロードの）サーバを見つけることによってその転送リクエストをシフトしてもよい。そこで、リクエストはそのオブジェクトに対する新しい（又は、共同の、例えば、Ａの）所有サーバに転送される。所有の移動の後でも、オブジェクトｐのコピーは依然としてサーバＢのキャッシュにあり、依然として、サーバＢに到来する直接リクエストをサービスすることができる。しかし、この例では、オブジェクトｐに対するすべての（又は、共同所有の場合にはいくつかの）その後の転送リクエストはサーバＡにシフトされるであろう。別の方法として、共同所有Ｂ，Ａ  "１０１２１"の場合、オブジェクトｐ  "１０１０１"に対するその後の転送リクエストが少ないロードのサーバに送られることも可能である。
【００３０】
今や、オブジェクト見つけるために論理的に中心のディレクトリが使用されるプロキシ・キャッシュ・サーバの集合体に関して本実施例によるロード・バランシング方法を説明したが、種々の代替え方法が考えられるであろう。本発明は、更に、これらのシステムに対するロード・バランシングを得るためにも適用可能である。
【００３１】
例えば、本発明は、ローカル的にミスしたオブジェクトのコピーを見つけるために各キャッシュ・サーバ１５０が連携キャッシュ・サーバのリストをマルチキャストする連携プロキシ・キャッシュ・サーバの集合体に対してロード・バランシングを行うように構成可能である。この場合、特定の所有情報がそのシステム内のどこかに維持される必要はない。しかし、それらの連携キャッシュ・サーバからオブジェクトが見つかるという保証もない。すべてのプロキシ・キャッシュ・サーバのロード状態１０２１を維持するために及びこの情報を各キャッシュ・サーバ１５０と共有するために論理的ロード・モニタ１２０が使用されるものと仮定する。ロード・バランシングは、キャッシュ・サーバがそれのリクエスト（シフト・リクエストとも呼ばれる）をマルチキャストする宛先の連携サーバのリストからオーバロードのサーバを排除することによって達成され得る。その結果、少ないロードのキャッシュ・サーバだけが転送リクエスト１２５を受け取るであろう。
【００３２】
もう１つの代替え方法は、ローカル的にミスしたオブジェクトのコピーを見つけるためにハッシュ関数が使用されるという連携プロキシ・キャッシュ・サーバの集合体のためのロード・バランシング方法である。この場合、連携プロキシ・キャッシュ・サーバ１５０の間で、各キャッシュ・サーバに対して１つのパーティションとして、オブジェクト空間を区画化することが可能である。転送リクエストをシフトすることによってロード・バランシングを達成するためには、転送リクエストがオーバロードのサーバに指向しないようにハッシュ関数を変更することが可能である。１つの望ましい方法は、プロキシ・キャッシュ・サーバの合計数よりもずっと大きい多数のバケットにオブジェクト空間をハッシュすることである。その場合、これらのハッシュ・バケットは、キャッシュ・サーバの間でロードをバランスさせるという最終目的を持ってそれらのキャッシュ・サーバに割り当てられる。ハッシュ関数を効果的に変更して、１つのオーバロードのサーバからアンダロードのサーバに１つ又は複数のハッシュ・バケットを定期的に移動させることが可能である。
【００３３】
いずれの場合も、連携キャッシュ・サーバのロード状態は、計算されたロード状態に直接に転送頻度で解することができる。例えば、ロード状態は、前記転送リクエストの数及び前記連携キャッシュ・サーバへの直接リクエストの数のウェート付けされた和であってもよい。別の方法として、ロード・モニタは、各連携キャッシュ・サーバに対する転送頻度全体を別々に維持することもできる。
【００３４】
図２、図３及び図４を参照すると、更に別の代替え方法は、分散しているロード・モニタ１２０である。即ち、キャッシュ・サーバ１５０にまたがっていくつかの又はすべてのロード・モニタが複製される。１つの例では、分散ロード・モニタは、連携キャッシュ・サーバのローカルのロード状態情報１０２１（及び、後述するように、おそらく、Ａ、Ｂ、Ｃ、．．．"１０２２"すべてのロード状態）を含む。分散ロード・モニタ１２０' は、各オブジェクトｉｄ／パーティションｉｄ  １０１０に対する転送頻度１０１１及び所有１０１２の情報を持ったキャッシング・テーブル１０１も含むことが望ましい。別の方法として、例えば上記のようなハッシュ関数は分散され、キャッシュ・サーバに記憶されてもよい。ロード状態情報１０２１及び／又はキャッシング・テーブル１０１は、状態の変化（所有、又はロード状態の重大な変化）がある時、又はキャッシュ転送リクエスト及び応答と共に結合処理される時、定期的に交換可能である。ロード状態情報１０２１は、トラッキングのために又は他の目的でそれと関連づけられたタイム・スタンプ（図示されてない）を持つこともできる。
【００３５】
ここで、キャッシュ・サーバ１５０がキャッシュ・ミスを有する場合、ローカルのロード・モニタ１２０' は、それのローカル・キャッシング・テーブル１０１においてそのリクエストされたオブジェクトの所有者をルップアップし、そのリクエストを所有キャッシュ・サーバに転送する。別の方法として、ハッシュ関数が、パーティションを識別するためにＵＲＬ又は宛先ＩＰアドレスのようなリクエストからのキーに適用され、しかる後そのリクエストが正しいキャッシュ・サーバに転送されてもよい。転送リクエスト（即ち、キャッシュ・ミスを持ったキャッシュ・サーバからのリクエスト）が受け取られる時、所有キャッシュ・サーバは、それを転送リクエストとして（例えば、クライアントと対立する他のキャッシュ・サーバからのリクエストとしてそれを識別することによって）識別し、それの転送頻度情報１０１１を適用可能なものとして更新する（図５のステップ２０３）。オーバロードの傾向又は状態が現れる場合（ステップ２０４）、所有キャッシュ・サーバは、シフト・リクエスト及びキャッシュされたオブジェクトのコピーでもってリクエスティング・キャッシュ・サーバに応答することができる。
【００３６】
別の方法として、リクエスティング・キャッシュ・サーバは、起点オブジェクト・サーバからイントラネット、ＷＡＮ、又はインターネットを介してコピーを得ることができる。いずれの場合も、転送サーバがそのオブジェクトのコピーをキャッシュする時、このサーバは、それがキャッシュに残っている限り、転送リクエストを最早発生しないであろうし（ステップ３０１，３０２）、従って、所有キャッシュ・サーバにおけるロードを比例的に減少させるであろう。更に、所有キャッシュ・サーバは、シフト・リクエスト・メッセージを１つ又は複数の他の連携キャッシュ・サーバ１５０にマルチキャストすることができ、従って、その後の転送リクエストは、例えば、キャッシュ・テーブルのそれらのローカル・コピーを更新することによって又はハッシュ関数を修正することによってシフトされるであろう（ステップ２０５）。この時点で、他のキャッシュ・サーバは、キャッシング・テーブル１０１のそれらのローカル・コピーに表されるように、新しい所有者に（又は、所有を分け合う場合には２つ又はそれ以上のキャッシュ・サーバ１５０の最も少ないロードの所有者に）それらのリクエストを転送することができる。オリジナル・キャッシュ所有者のロードが受容可能なレベル、例えば、閾値によって表されるレベルまで減少した時（ステップ２０４）、共同所有者の情報はそれのオリジナル状態にマージされ得る（例えば、Ｂ，Ａ  "１０
１２１"-->Ｂ）。
【００３７】
すべてのキャッシュ・サーバ（Ａ，Ｂ，Ｃ、．．．"１０２２"）に対するロード状態情報１０２１が十分に分散している場合、リクエスティング・キャッシュ・サーバは所有サーバのロード状態（及び関連するタイム・スタンプ）を先見的に、即ち、そのリクエストを転送する前にチェックすることができるであろう。それがオーバロードである場合、リクエスティング・キャッシュ・サーバは所有キャッシュ・サーバから（又は、起点キャッシュ・サーバからイントラネット又はインターネット１１０を介して）オブジェクトのコピーを、及び、恐らく、ロード状態情報をリクエストすることができるであろう。所有キャッシュ・サーバはそれのキャッシング・テーブルを更新すること又は新しい共同所有を表すようにハッシュ関数を修正することができるであろう。そこで、リクエスティング・サーバ（又は、所有サーバ）は、そのオブジェクトの新しい共同所有を表すメッセージを他のすべてのキャッシュ・サーバ１５０にマルチキャストすることができ、恐らく、更新されたロード状態を含むことができるであろう。この時点で、他のキャッシュ・サーバはそれらのキャッシング・テーブルを更新するか又は新しい共同所有を表すようにハッシュ関数を修正するであろうし、キャッシング・テーブル１０１のローカル・コピーにおいて表された所有を分け合う２つ又はそれ以上のキャッシュ・サーバ１５０の最も少ないロードの所有者にそれらのリクエストを転送することができる（ステップ２０６）。共有キャッシュ所有者のロードが、例えば、閾値によって表されるような受容可能なレベルまで減少した時（ステップ２０４及び２０８）、ステップ２０９において、所有情報はそれのオリジナル状態にマージされることが可能である。
【００３８】
本発明の望ましい実施例は、キャッシュ・サーバ１５０を具備したプロセッサ（図示されてない）上で又は前述の集中型モデルのようなロード・モニタ１２０を具体化した他のコンピュータ上で実行するためのコンピュータ・プログラム製品又はプログラム記憶装置において有形的に具体化されたソフトウエアとしてインプリメントされ得るフィーチャを含んでいる。例えば、ＪＡＶＡ(R)のような一般的なオブジェクト指向コンピュータの実行可能なコードでインプリメントされたソフトウエアは種々なプラットフォームに跨る移植性を与える。ＲＥＸＸ、Ｃ、Ｃ++、及びＳｍａｌｌｔａｌｋを含むがそれらに限定されない他の多くのコンパイルされた又はインタープリットされたプロシージャ指向及び／又はオブジェクト指向（ＯＯ）プログラミング環境が使用されてもよいことは当業者には明らかであろう。
【００３９】
本実施例の方法が、磁気的、電気的、光学的、又は他の永続的なプログラム又はデータ記憶装置において具体化され得ることも当業者には明らかであろう。なお、上記の記憶装置は、磁気ディスク、ダイレクト・アクセス記憶装置（ＤＡＳＤ）、バブル・メモリ、テープ、ＣＤ−ＲＯＭ及びＤＶＤのような光ディスク・フォーマット、及び、コア、ＲＯＭ、ＰＲＯＭ、フラッシュ・メモリ又はバッテリ・バックアップＲＡＭのような他の永続的（不揮発性とも呼ばれる）記憶装置を含むが、それらに限定されない。本発明の精神及び技術範囲では、サーバ１２０' のメモリにおいて実証された１つ又は複数のコンポーネントがディスク（図示されてない）、ネットワーク、他のサーバを介して直接にアクセス及び維持され得ることは当業者には明らかであろう。
【００４０】
要約すると、プロキシ・キャッシュ・サーバのような連携キャッシュ・サーバの集合体を含むシステムにおいて、リクエストされたオブジェクトをローカル的に見つけることができなかった場合、１つの連携キャッシュ・サーバにリクエストが転送されることが可能である。例えば、リファレンス・スキューのために、或るオブジェクトがすべてのクライアントによって高い要求状態にある場合、及びそれらのホット・オブジェクトを含むキャッシュ・サーバが転送リクエストのためにオーバロードになっている場合、オーバロード状態が検出される。それに応答して、オーバロードのキャッシュ・サーバから少ないロードのキャッシュ・サーバにいくつかの又はすべての転送リクエストをシフトすることによってロードはバランスをとられる。集中型ロード・バランシング環境及び分散型ロード・バランシング環境の両方が説明されている。
【００４１】
本発明の望ましい実施例を代替え方法と共に説明したけれども、現在及び将来とも、当業者が本願の特許請求の範囲に記載された技術的範囲内で種々の改良及び拡張を行い得ることは明らかであろう。これらの特許請求の範囲は、上述の本発明に対する適正な保護を維持するためのものと解されるべきである。
【図面の簡単な説明】
【００４２】
【図１】本発明による集中型ロード・バランシング・ロジックを適用し得る、プロキシ・キャッシュ・サーバの集合体を使用するシステムの例をブロック図形式で示す。
【図２】本発明による分散型ロード・バランシング・ロジックを適用し得る、プロキシ・キャッシュ・サーバの集合体を使用するシステムのもう１つの例をブロック図形式で示す。
【図３】図１に示されたロード・モニタが維持し得るテーブルに対するデータ・フォーマットの例を示す。
【図４】図２に示されたロード・モニタが維持し得るテーブルに対するデータ・フォーマットの例を示す。
【図５】キャッシュ・ミスのために、キャッシュ・サーバからのリクエストに応答してロード・モニタに対するロジック・フローの例を示す。
【図６】オブジェクトに対するリクエストに応答してキャッシュ・サーバに対するロジック・フローの例を示す。
【図１】
2007220140.tif 000003
【図２】
2007220140.tif 000004
【図３】
2007220140.tif 000005
【図４】
2007220140.tif 000006
【図５】
2007220140.tif 000007
【図６】
2007220140.tif 000008