JP2000315200A

JP2000315200A - 分散されたロード平衡インターネットサーバ

Info

Publication number: JP2000315200A
Application number: JP11309760A
Authority: JP
Inventors: B Logan David; ビーローガンディヴィッド; Satei Shirisshu; サテイシリッシュ
Original assignee: Alteon Websystems Inc
Current assignee: Nortel Altsystems Inc
Priority date: 1998-09-24
Filing date: 1999-09-24
Publication date: 2000-11-14
Also published as: IL132016A; IL132016A0

Abstract

(57)【要約】（修正有）【課題】分散されたロード平衡インターネットサーバ
を提供する。【解決手段】ピアハンドオフプロセスにおいて、スイ
ッチは特定のドメインネームのためのドメインネームサ
ーバルックアップリクエストを受け取る。スイッチはソ
ースIPアドレスを調べ、ユーザのIPアドレスを調べ、ユ
ーザに地図上で近いサーバサイトがないか調べる。スイ
ッチはドメインに対応する順序付けられたハンドオフテ
ーブルを調べる。スイッチは、（ａ）ドメインネームサ
ーバリクエストソースと対照的な遠隔サーバ位置、
（ｂ）遠隔サーバの負荷、及び（ｃ）前のハンドオフを
経験した遠隔サーバをベースとする次の遠隔サーバ（ま
たは独自の仮のインターネットプロトコルアドレス）を
選択する。スイッチは次いで、順序付けられたリストに
おけるIPアドレスとともにクライアントドメインネーム
にドメインネームサーバレスポンスを送り返す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は一般に、コンピュー
タデータネットワーク装置及び方法に関し、より詳細に
は、ドメインネームをドメインネームサーバ装置におけ
るIPアドレスに変換することを制御することによりロー
ディングを分配されたネットワークサーバに対して平均
化することに関する。

【０００２】

【従来の技術】ワールドワイドウェブ（WWW）、特にイ
ンターネットは急速に、ビジネスにおいて製品を売り、
顧客や供給者とコミュニケーションをとる本質的な方法
ととなっている。今、インターネットを「ミッション・
クリティカル(mission critical)ビジネスデリバリーイ
ンフラストラクチャー」と呼ぶ者もいる。結果として、
インターネットサーバ及びいわゆる「イントラネット」
サーバは以前にも増してすさまじく働いている。今支持
せねばならないクライアントサーバの数多くは劇的に増
加した。イントラネットサーバは、外部カウンターパー
トイントラネットサーバが何万もの同時クライアントコ
ネクションを支持可能である時、何百もの同時クライア
ントリクエストを提供しなければならない。

【０００３】クライアントは迅速な応答及び1週間に７
日、１日２４時間（「７×２４」）の稼働率を要求し、
かつ期待する。ミッション・クリティカルウェブ・コン
ピューティングインフラストラクチャーは力学的にサー
バ容量を基準化して、集合したクライアントデマンドに
合わせ、連続的なサービス可用性を更に保証するように
しなければならない。唯一の方法は、いくつかのサーバ
上で各アプリケーションを実行し、次いで連続的に種々
のサーバ、例えば「サーバロードバランシング」上でク
ライアントローディングを平均化することである。

【０００４】サーバロードバランサーは、アプリケーシ
ョン層セッションを識別し、管理するように層３及び層
４パケットヘッダーにおける情報を使用する。例えば、
TCP又はUDPポートナンバー、TCPアプリケーションセッ
ション及びIPソースの始まりと終わりを示すSYN/FINビ
ット、及びデスティネーションアドレスである。

【０００５】伝統的なサーバロードバランサーはリミテ
ッドパフォーマンス及び連結性を備えたPCベースのソフ
トウェア製品である。トラフィック容量及びサーバ母集
団における急速な成長により、性能、連結性、弾性、及
び節約における大規模な改良の命令を与えるスイッチ統
合サーバロードバランサーの新世代を引き起こす。

【０００６】スイッチベースのサーバロードバランサー
の新世代は、キャッシュに対するリダイレクション、複
数のファイアウォールに対するロードバランシングトラ
フィック、パケットフィルタリング、及び帯域幅管理の
ような複数のウェブインフラストラクチャー機能及び多
層スイッチングを備えたロードバランシングアプリケー
ションサーバを合同する。

【０００７】アルテオン（Alteon）ウェブシステムは
「サーバスイッチ」という用語を造りだして、サーバフ
ァームをフロントエンドする装置の新しい分類を表し、
全てのミッションクリティカルインターネット／イント
ラネットインフラストラクチャーにおけるサーバ関連ト
ラフィック管理を提供した。サーバスイッチは、グルー
プがネットワークに対する１つのサーバであるかのよう
にする一方で、通常のアプリケーション（あるいは１組
のアプリケーション）を実行するサーバのグループにわ
たってアプリケーションロードを力学的に分配する。同
じ内容にアクセスするウェブサーバの数多くは、通常の
アプリケーション又は１組のアプリケーションを支持す
るサーバのグループであるHTTPハントグループに必然的
に結合される。ハントグループはクライアントに対する
「仮の」HTTPサービスを提供する。クライアントは多く
の本物のサーバがこのサービスの提供に参加しているこ
とに気付いていない。クライアントは、本物のサーバを
フロントエンドするサーバスイッチに属する仮のサービ
スアドレスを使用するサービスにアクセスする。連結に
おいて仮のサービスのために到着することを要求する
時、サーバスイッチはこれらの要求をサーバの可用性、
ロードハンドリング能力、および現行のロードの知識に
よるハントグループにおける本物のサーバの１つに渡
す。

【０００８】このようにして、複数のサーバはシステム
の使用者によって要求されたアプリケーション処理容量
の総量を達成するのに使用される。各新サーバは容量を
アプリケーショに有用なたまった処理電力に加える。

【０００９】同様に重要であるが、サーバが故障又はメ
ンテナンスオペレーションのいずれかによりサービスが
止まった時、残った健全なサーバは使用者に近くされた
衝撃を多少あるいは全く与えずにロードをピックアップ
する。これを達成するためには、サーバスイッチはクラ
イアントロードを分配する全てのサーバ及び各アプリケ
ーションの健康状態を連続的に監視しなければならな
い。サーバスイッチはまた、完全なシステム余剰のため
のホットスタンバイ形態を支持しなければならない。

【００１０】サーバロードバランシングのキーの部分
は、セッション管理である。一旦セッションリクエスト
が本物のサーバに割り当てられると、サーバスイッチ
は、セッションと関連した、全ての継続的なパケットを
認識しなければならない。これらのパケットはクライア
ントが各セッションの存続期間、同一の物理的サーバと
関連して継続するのを確かめるように、適切に処理さ
れ、かつフォワードされる。

【００１１】サーバスイッチはまた、物理的サーバへの
連結の結合が取り除かれる時のセッションの完了を監視
する。これは次回、最も有用なサーバに連結するのが好
ましいクライアントが連結し、各クライアントに最も可
能な限りのサービスを提供することを保証する。アプリ
ケーションによって継続的な連結がFTP制御及びデータ
連結、SSL（Secure Sockets Layer）、及びマルチペー
ジフォーム及びサーチエンジンに使用される持続的なHT
TPのような同一の物理的サーバにフォワードされること
を必要とするならば、特別なメカニズムがアドミニスト
レータにより呼び出される。

【００１２】サーバロードバランシングから利益を得る
環境はウェブホスティングサービス、オンラインサービ
スプロバイダー、及び高有用性要求物を備えたコーポレ
ートデータセンターを含む。理論上は、サーバロードバ
ランシングは通常の内容がサーバのグループにわたって
有用である、TCPベースの、又はUDPベースのアプリケー
ションを支持するように使用される。実際問題として、
ウェブサーバ、FTPサーバ、ドメインネームサーバサー
バ、及びRADIUSサーバのようなインターネット／イント
ラネットアプリケーションを支持するサーバは、好まし
くはサーバロードバランシングによって高成長及びウェ
ブ指向のトラフィックの予測できない容量を支持するこ
とを最初に利用する。

【００１３】ウェブページの大多数は読取専用情報を含
む。これはウェブホスティング環境がサーバロードバラ
ンシングにとって理想的であるようにする。ウェブホス
ト及びオンラインサービスプロバイダーは今日典型的に
複数のHTTP、FTP及び他のアプリケーションサーバを展
開し、ロードを静的に分配し、あるいはもっと一般的に
はラウンドロビンドメインネームサーバを経て分配す
る。両方の方法は、故障許容がなく、高度の管理を必要
とするため、望ましくない。サーバロードバランシング
はルトイン高有用性支持との複数のサーバの即応型使用
を可能にする。

【００１４】今日の多くのクラスタ化システムは超越し
たフェイルオーバー能力を提供するが、ロードバランシ
ング支持を提供しない。いくつかのシステムはまた、ク
ラスタに関係する数多くのサーバを制限する。これらの
制約はクラスタ化の解のスケーラビリティに衝撃を与え
る。サーバロードバランシングはロード共有ハントグル
ープにサーバを柔軟に結合することを可能にする。ま
た、冗長サーバがロードを共有するようにすることによ
ってサーバユーティライゼイション効率を改善する。

【００１５】たいてい、今日のサーバ環境はマルチベン
ダ及びマルチOSである。今日の一般的なクラスタ化の解
は単一のベンダからのサーバ又は単一のオペレーティン
グシステムを実行するサーバに限定される。サーバスイ
ッチ上のサーバロードバランシングはTCP及びUDPアプリ
ケーションを支持する異質のサーバがロード共有クラス
タにゆるく結合して、サーバインベストメントリターン
を最大化する事を可能にする。

【００１６】

【課題を解決するための手段】URLドメインネームに応
答してクライアントにウェブページを提供する実際のイ
ンターネットウェブサイトは、同一のデータ記憶装置を
夫々が有する、分配された多くのサイトのリストから自
動的にかつ即応して選択される。ピアハンドオフプロセ
スにおいて、スイッチは特定のドメインネームのための
ドメインネームサーバルックアップリクエストを受け取
る。スイッチはドメインネームサーバリクエストのため
のソースIPアドレスを調べ、ユーザのIPアドレスを調
べ、ユーザに地図上で近いサーバサイトがないか決定す
る。スイッチはドメインに対応する順序付けられたハン
ドオフテーブルを調べる。スイッチは、（ａ）ドメイン
ネームサーバリクエストソースと対照的な遠隔サーバ位
置、（ｂ）遠隔サーバの重量、及び（ｃ）前のハンドオ
フを経験した遠隔サーバをベースとする次の遠隔サーバ
（または独自の仮のインターネットプロトコルアドレ
ス）を選択する。スイッチは次いで、順序付けられたリ
ストにおけるIPアドレスとともにクライアントドメイン
ネームにドメインネームサーバレスポンスを送り返す。

【００１７】

【発明の実施の形態】図１は、本発明の分散サーバ負荷
均衡(distributed-server load-balancing)システムの
実施形態を表わし、ここに一般的な参照符号１００によ
り示される。分散サーバ負荷均衡システム１００によ
り、ウェブベースのコンテンツ及びサービスは、クライ
アント”Ｚ”１０２により表わされる多くのクライアン
トに、多くの独立したウェブ−サーバサイトからインタ
ーネット１０４を通して冗長に送られる。クライアント
１０２がウェブブラウザプログラムをロードしたとき、
例えばwww.alteon.com/products/index.htmlのようなユ
ニフォームリソースロケーション（ＵＲＬ）に入る。

【００１８】インターネット１０４上で使用されるＩＰ
アドレスは３２ビット長であるが、ほとんどのユーザ
は、彼らが加入するホストの数字のアドレスを覚えてい
ない。その代わりに人々は、ホストネームによる方がよ
り快適である。ほとんどのＩＰホストは、そのため、数
字のＩＰアドレス及びネームの両方を有している。これ
は人々にとっては便利である一方、ルーティングの目的
のためには、そのネームは数字のアドレスに逆に転換さ
れなくてはならない。インターネットホストは、トップ
レベルドメイン（top-level domain,ＴＬＤ）、ドメイ
ン及び（必要に応じ）サブドメイン、及びホストネーム
を含む、階層状ネーミング構造(hierarchical naming s
tructure)を使用している。ＩＰ−アドレス空間、及び
全てのＴＣＰ／ＩＰ関連の番号は、インターネットアサ
インドナンバーズオーソリティ（Internet Assigned Nu
mbers Authority,ＩＡＮＡ）により割り当てられ、維持
されている。ドメインネームは、ＴＬＤネーミングオー
ソリティにより割り当てられる；１９９８年４月まで、
インターネットネットワークインフォメーションセンタ
ー（Internet Network Information Center, Ｉｎｔｅ
ｒＮＩＣ）は、これらのネームの全般の機関であった
し、世界中のＮＩＣが米国以外のドメインを扱ってい
た。ＩｎｔｅｒＮＩＣは、インターネット上のホストネ
ームとＩＰ−アドレスとを両立させる分散データベース
である、ドメインネームシステム（ＤＮＳ）の全般の調
整及び管理にも責任があった。

【００１９】クライアント−Ｚ１０２では、ドメイン
ネームサーバの”getByHostname”照会が、ローカルド
メインネームサーバに実際に発行され、www.alteon.com
で使用するために登録された数字のインターネットプロ
トコルアドレス（ＩＰ−アドレス）を要求する。それぞ
れのローカルドメインネームサーバは、特定のドメイン
ネーム及びホストにサービスを提供するホストのための
ＩＰ−アドレスを、それが既に知っているかどうかを確
認する。それは、この情報を先立って必要とすること及
びローカルプライベートキャッシュメモリ中にそれが発
見した答を記憶させることにより、このことを知ること
ができよう。もしローカルドメインネームサーバが、要
求されたＵＲＬドメインネームに対するホストネームＩ
Ｐ−アドレスを知らないなら、それは、ＤＮＳ階層中で
より高位のドメインネームサーバへ反復する照会を実行
するであろう。そのようなドメインネームサーバの照会
は、より高いレベルのドメインネームサーバによって答
えられるか、あるいはその要求は、分散サーバネットワ
ークスイッチサイト１０６、１０８、又は１１０の内の
１つに、最後には表面に浮かんでくるかのどちらかであ
ろう。

【００２０】ＩＰ−アドレスは、ルーティングの目的の
ために階層状であり、さらに２つのサブフィールドに分
けられている。ネットワーク識別子(Network Identifie
r,ＮＥＴ＿ＩＤ)サブフィールドは、インターネットに
接続されたＴＣＰ／ＩＰサブネットワークを識別する。
ＮＥＴ＿ＩＤは、ネットワーク間の高レベルのルーティ
ングのために使用され、カントリーコード、シティコー
ド又はエリアコードとほぼ同じ方法が電話ネットワーク
中で使用される。ホスト識別子（ＨＯＳＴ＿ＩＤ）サブ
フィールドは、サブネットワーク内の特定のホストを指
示する。

【００２１】ほとんどのＩＰホストは、数字のＩＰ−ア
ドレス及びネームを通常有する。ネームは、人々のため
の便宜として提供されるが、そのようなネームは、ルー
ティングの目的のためには数字のアドレスに逆に転換さ
れなくてはならない。インターネットホストは、トップ
レベルドメイン（top-level domain,ＴＬＤ）、ドメイ
ン及び（必要に応じ）サブドメイン、及びホストネーム
を含む、階層状ネーミング構造(hierarchical naming s
tructure)を使用している。分散サーバネットワークス
イッチ１０６、１０８及び１１０は、分散サイトとして
編成され、ここでそれぞれは、例えばwww.alteon.comの
ようなサブドメインに対する正当ネームサーバ(Authori
tative Name Server)として働く。それぞれのそのよう
な分散サイトは、www.alteon.comに対応するＩＰ−アド
レス識別を有するドメインネームサーバの照会に応答す
ることができる。

【００２２】ＴＣＰ／ＩＰプロトコルの一続きは、ＯＳ
Ｉトランスポート(OSI Transport)及びセッションレイ
ヤ(Session Layer)におおよそ対応する２つのプロトコ
ルを含む。これらのプロトコルは、トランスミッション
コントロールプロトコル(Transmission Control Protoc
ol)及びユーザデータグラムプロトコル(User Datagram
Protocol,ＵＤＰ)と呼ばれる。個々のアプリケーション
は、ＴＣＰ／ＵＤＰメッセージ中のポート識別子により
表わされる。ポート識別子及びＩＰ−接続は、一緒にソ
ケットを形成する。接続のサーバ側上の周知のポート番
号は、ポート−２０（ＦＴＰデータ転送）、ポート−２
１（ＦＴＰコントロール）、ポート−２３（Telnet,電
話ネットワーク）、ポート−２５（ＳＭＴＰ）、ポート
−４３（whois,誰か）、ポート−７０（Gopher,ゴーフ
ァー）、ポート−７９（finger,指）、及びポート−８
０（ＨＴＴＰ）を含む。

【００２３】図解の目的のため、分散サーバスイッチ１
０８は、クライアント１０２により発せられたドメイン
ネームサーバ照会を受け取ると仮定する。本発明の実施
形態では、分散サーバスイッチ１０８は、仮想−ＩＰ
（ＶＩＰ）を表わすＩＰ−アドレスの一組を返すであろ
う。例えば、分散サーバスイッチ１０８は、ＵＲＬ照会
に、どれもが単一のＵＲＬに関連するウェブベースのコ
ンテンツ及びサービスの要求を満足する”192.168.13.2
0”、”162.113.25.28”及び”172.176.110.10”を含む
ＩＰ−アドレスの一組でもって応答することができよ
う。これらの数個のＩＰ−アドレスのそれぞれは、例え
ば、分散サーバスイッチ１０６及び１１０によって表わ
されるような、地理的に異なったサーバに存在する。ク
ライアント１０２は、そのような応答を、それのローカ
ルドメインネームサーバ経由で受け取るであろう。そし
てクライアント１０２は、これらのＩＰ−アドレスを使
用し、例えば分散サーバスイッチ１０６で実際に働いて
いるＶＩＰ−アドレスである”192.168.13.20”へのＴ
ＣＰポート８０接続を開くことができる。クライアント
１０２は、これが単なるＶＩＰであることを知らず、ま
たスイッチ１０６に存在する”192.168.13.10”の実際
のＩＰアドレスを無視することができる。その後、www.
alteon.comウェブサイトを有するクライアント１０２に
より発せられたトラフィックは、分散サーバスイッチ１
０６により扱われ、他の可能性のあるスイッチ１０８及
び１１０からオフロード(off-load)される。

【００２４】それぞれのスイッチ１０６、１０８及び１
１０のためのＶＩＰの設定(set up)は、任意の１つへの
要求(request)がクライアント１０２に与えられている
同じデータに帰するように、それぞれ同じコンテンツ及
びアプリケーションへのクライアントのアクセスを可能
にしなければならない。そのため、利用可能なリソース
をユーザが必要とするサービスに分配する、ある手段を
確立する必要がある。そのような手段において考慮すべ
き要因は、関連する個々の分散サーバのＶＩＰの健全
性、基本的なインターネットアサインドナンバーオーソ
リティ（ＩＡＮＡ）が登録したクライアント及びサーバ
の位置、及び現時に測定された応答時間及びスループッ
トに従って利用可能なサーバのリストを含む。最も健全
で、より近くに位置し、良好な応答時間及びスループッ
トを示すようなサーバは、それらにより多くのトラフィ
ックが向けられるべきである。それらの対応するＶＩＰ
に応答することにより、非常にしばしば、このことは実
行される。

【００２５】ＤＮＳは、インターネット上の各ドメイン
に対するホストネーム及びＩＰ−アドレス情報の普通の
分散データベースである。各ドメインに対し、単一の正
当ネームサーバ(authoritative name server)がある。
やく１２個のルートサーバ(root server)が、こららの
正当ネームサーバのすべてのリストを有する。ホストに
よりＤＮＳに要求(request)がなされたとき、その要求
はローカルネームサーバに行く。もし、ローカルネーム
サーバのところでの情報が不十分あれば、正当ネームサ
ーバを見つけるための要求がルートへなされ、また情報
の要求(information request)は、そのネームサーバへ
送られる。ネームサーバは、以下のタイプの情報を含
む。

【００２６】Ａ−レコード：アドレスレコードは、ホス
トネームをＩＰ−アドレスにマッピングする。

【００２７】ＰＴＲ−レコード：ポインタレコードは、
ＩＰ−アドレスをホストネームにマッピングする。

【００２８】ＮＳ−レコード：ネームサーバレコード
は、所定のドメインに対する正当ネームサーバを一覧に
して示す。

【００２９】ＭＸ−レコード：メール交換レコードは、
所定のドメインに対するメールサーバを一覧にして示
す。

【００３０】クライアント１０２が失敗を突然経験する
ように指摘されたか、又はオーバーロードであるサーバ
スイッチが１０６，１０８又は１１０ならば、それ
は「"HTTP redirect"」を発行する。従って、クライア
ント１０２は、異なるサーバスイッチ１０６、１０８又
は１１０に向かうように命令される。「HTTP Request」
が、最大通信（"MaxConns"）又はもはやいなかるヘルス
リアルサーバもないＶＩＰで到着するとき、「"HTTP re
direct"」は発行される。

【００３１】図１の分散サーバロード平衡システム１０
０は、ＶＩＰサイトに関するＤＮＳ要求に応答するよう
にドメインネームサーバを使用する。"www.alteon.com"
の例は、Alteonウェブ分散サーバに関する同じコンテン
ツに対するアクセスを備える米国を介して散乱した種々
のＶＩＰを示す。スイッチが、ＶＩＰと関係して"www.a
lteon.com"を解決するためにドメインネームサーバName
Requestを受信するとき、次のコンテンツ要求に応答す
るために「ベストサイト」を適合する適当なドメインネ
ームサーバレスポンスで応答する。例えば、かかるベス
トサイトは、ユーザの最大の数で、最小の遅延を負荷す
るものを表す。最小のコストであるものとして応答する
ベストサイトを構成するような、他の標準も可能であ
る。

【００３２】サイトの稼働状態及びスループットの測定
は、全ての他のピアリモートサイト１０６、１０８、及
び１１０で「Ｌ４ヘルス−チェッキング」（オプション
として内容確認で）の間に得られる。このようなもの
は、アプリケーションの使用可能性の状態を決定し、ま
た、各サイトのスループット性能を決定するのに使用さ
れる。

【００３３】稼働状態、負荷、スループット情報を、サ
イト間で、周期的にもしくは所定の事象によって引き起
こされる時に交換することができる分散ＳＬＢ状態プロ
トコルが、使用される。インターネットトポロジーアウ
ェアネスが本発明の実施例に含まれるのが好ましい。

【００３４】インターネットトポロジーアウェアネスに
関し、ＤＮＳ／ＨＴＴＰハンド−オフのために使用され
る特定のスイッチが、要求のソース＿ＩＰを調べ、世界
中のＩＰ−アドレス空間を割り当てられたＩＡＮＡに基
づいて「最良の」サーバーで応答する。外部の「加入者
データ−ベース」に、登録されたユーザーネットワーク
がどこに位置するかを記述する必要な両の細目を提供す
るように要求しても良い。この情報を、インターネット
割り当て番号局（Internet Assigned NumbersAuthorit
y）及びＷＨＯＩＳデーターベースで見つけることがで
きる。

【００３５】図２を、環境２００を監視する分散された
サイトを図示するのを助けるのに使用する。典型的なメ
インコンテンツサーバサイト２０２は、例えば、定義さ
れたリモートサーバ２０４，２０６，２０８，２１０及
び２１２のような、分配されたサイトスイッチで稼働す
るＶＩＰの稼働に対応する定義されたREAL SERVERのセ
ットにアクセスする。各メインサイト２０２は、周期的
なヘルスと、各定義されたリモートサーバのスループッ
トチェックである。そして、各スイッチは、分配された
サイトスイッチにおけるＶＩＰの稼働に対応する各々の
その定義されたリモートREAL SERVERをテストする。各
リモートサーバ２０４，２０６，２０８，２１０及び２
１２に対する構成可能な反復ヘルスチェックを実行する
ことによって、メインサイト２０２は、平均応答時間
と、ハンド・オフに関する準備におけるコンテンツの可
用性とを学習することができる。

【００３６】これらのコンテンツヘルスチェックは、ヘ
ルスチェックの全ての反復に関して、開始時間から終了
時間まで、測定されるのが好ましい。サイト及びスイッ
チは、相互変換可能に使用されうる。サイトあたりのあ
るスイッチは、この例において仮定される。

【００３７】図２において、分配されたサーバスイッチ
２０２は、その好ましいハンド・オフサイトが、優先順
に、定義されたリモートサーバ２１０，２０４，２０
６，２０８であるように決定されうる。定義されたリモ
ートサーバ２１０の９００ｍｓｅｃ応答は、他のより遅
い応答よりもより魅力的である。各リモートサーバ２１
０，２０４，２０６，２０８の応答時間は、時間重み平
均としてメインサイト２０２で記録される。この情報は
また、分配されたサイトステータスプロトコルを使用し
て他の全てのスイッチに各スイッチによって連絡され
る。互いのスイッチは、その定義されたリモートリアル
サーバの各々に関して応答時間とスループットテストを
行い、テストの開始からテストの終了までの合計のレス
ポンスインターバルを計算する。

【００３８】例えば、ＨＴＴＰ，ＦＴＰ，ＮＮＴＰ，Ｄ
ＮＳ，ＳＭＴＰ及びＰＯＰ３のようなコンテンツヘルス
チェックサポートを有するプロトコル及びアプリケーシ
ョンに関して、コンテンツは、Adminによって定義され
た、例えばＵＲＬ，ファイルネーム等のようなコンテン
ツコンフィギュレーションに基づいて反復的にアクセス
されうる。コンテンツヘルスチェックでサポートされて
いないプロトコル及びアプリケーションに関して、又
は、コンテンツコンフィギュレーションがまだ定義され
ていない場合において、TCO OPEN/CLOSE接続プロセス
は、サーバロード平衡に関するほとんど同じ情報を作り
出すように実行されうる。

【００３９】図２では、分配されたサーバスイッチ１０
６に対する４つの分配されたサイトのセットがある。ヘ
ルス／スループットチェックは、分配されたサイトＶＩ
Ｐに応答して各々定義されたリモートサーバに関して行
われる。各サイトで対応するリモートリアルサーバを有
する分配サーバスイッチ１０６で定義された５つのＶＩ
Ｐがあるならば、分配されたサーバスイッチ１０６でス
イッチは、（おのおの５つのリモートＶＩＰを備える、
４つの分配されたサイト）ヘルスチェックインターバル
にわたって２０のヘルス／スループットチェックをする
必要がある。

【００４０】リアルサーバヘルスは、リアルサーバに構
成されたサービスに対する一連のＴＣＰ−ＳＹＮ要求を
介してテスト装置において監視される。これらの要求
は、デフォルトによって数秒ごとに行われる。どんな反
応の遅いサーバでも、サーバが「ダウン」を宣言する
か、応答可能になるまで、反復的に要求を受信する。

【００４１】別の考えは、ヘルスチェック中に個々のス
イッチがリモートサーバに届かないならば、個々のスイ
ッチがすべきであるということである。この状況が生じ
たとき、他のスイッチにもはや接続することができない
スイッチは、(a)接続ハンド・オフに関してサーバスイ
ッチがもはやふさわしくないと判断されるべきであり、
ドメインネームサーバ応答又は「ＨＴＴＰ転送」に関す
る目標としてリモートサーバのＶＩＰを使用して停止す
べきであり、(b)サーバスイッチが応答可能でない他の
全ての分配されたサイトに知らせるために、分配された
サイトステートプロトコル（ＤＳＳＰ）トリガー更新を
送信すべきである。他の全てのサイトは、次いで、サー
バスイッチが応答可能か、それに応じて作動するかどう
か判断する。

【００４２】分配された分配サーバステートプロトコル
（ＤＳＳＰ）は、あるサイトから他の分配された分配サ
ーバごとにステータス及びヘルス情報を連絡するのに使
用される。プロトコルは、(a)これが通常及び周期的な
ＵＰＤＡＴＥか、又は、これがＥＶＥＮＴ通知であるか
？、(b)ＶＩＰハンド・オフオーダされたリスト及び重
み付けされた平均応答時間、(c)ＶＩＰあたりの利用可
能な接続のような分配されたサーバ容量を残し、スイッ
チにおけるメモリリソース可用性を残すことを判断する
能力である。

【００４３】通常の周期的なリアルサーバヘルスチェッ
クプロトコルが、サイトが応答可能であるか否かを判断
するので、「keep-alive」又は「hello-are-you-there
?」プロトコルとしてＤＳＳＰを使用する必要がない。

【００４４】表１は、図２と同様な、サイトあたり単一
のＶＩＰを備えるサイトＡ−Ｆを備える仮定のネットワ
ークにおけるシミュレーションされた応答時間を示す。
時間は、各々のサイトの点から見たものである。本発明
の実施形態では、表１によって表されたものと同様の情
報の表は、ＤＳＳＰを使用するサイトの間で通信され
る。各受信サイトは、後で使用するためにＶＩＰハンド
・オフオーダーされたリストを生成するためにスループ
ット数の比較を行う。各サイトＡ−Ｆでの各スイッチ
は、テストされる分配されたサーバがどんなヘルスチェ
ックにも応答しないならば、テストサイトの透視から
「ダウン」していると判断できる状況を除いて、同じハ
ンド・オフテーブルを計算する。

【００４５】表１ ---------------------テストをするサイト-----------
------- （ミリ秒における平均遅延時間）これらの測定によりサイトＡでは、サイトＤが高いスル
ープットであるように見える。サイトＢは、高いスルー
プットを有するようにサイトＣが見え、サイトＣ及びサ
イトＥはサイトＦが高いスループットを有するように判
断する。

【００４６】表２は、表１で測定された、各サイトのオ
ーダされたハンド・オフ・プリファレンスの結果であ
る。この情報が、サイトの間で交換されるとき、各サイ
トは、各サイトが最初のプリファレンス、第２のプリフ
ァレンスなどとなるのにどれだけの時間がかかるか計算
する。

【００４７】表２ ------------------サイトプリファレンス選択--------
---------

【００４８】表２において、サイトＡはある例では第１
のプリファレンスである。サイトＢは、ある例では第１
のプリファレンスである。サイトＣはある例では第１の
プリファレンスである。サイトＤはある例では第１のプ
リファレンスである。サイトＥはある例では第１のプリ
ファレンスである。サイトＥは決して現れない。そし
て、サイトＦはある例では第１のプリファレンスであ
る。第２行では、Ａ＝１，Ｂ＝０，Ｃ＝１，Ｄ＝０，Ｅ
＝２，Ｆ＝２を生成する。

【００４９】表３：静的重みテーブルＤＮＳ／ＨＴＴＰ転送ハンド・オフ重み（Traff Dist
付）

【００５０】表３の所定の重みの列を参照すると、各最
初の位置の外観は、第３の位置の外観の重みの４倍受信
するのが好ましい。各第２の位置の外観は、第３の位置
の外観の重みの２倍受信する。第４から第６の位置の外
観は、重みなく受信する。従って、本発明のアルゴリズ
ムの実施形態は、表４に示したように構成されうる。

【００５１】表４

【００５２】かかる方法を使用する際に種々の利点があ
る。最も良いサイトは一般的に、他のサイトよりもより
多く通信を受信するが、より多くの通信は受信しない。
発生するいかなるハンド・オフもトップ２乃至３のサイ
トにわたる平均であるのが好ましく、静的ハンド・オフ
重みを調整することによって調整可能である。全ての他
のサイトによって不十分に実行されるようなサイトは、
少ししか受信せず、又は全くハンド・オフしない。ＷＡ
Ｎリンク、サーバなどを含む全てのサイトが上手く実行
するならば、各サイトが時間にわたって等しいトラフィ
ックの分配を受信しているようなものである。

【００５３】テーブルIIIのような計算されたハンドオ
フテーブルは、もっぱら、ＤＮＳ応答の順序付けや「Ｈ
ＴＴＰリダイレクト（転送）」プリファレンス（優先）
に使用される。「ＨＴＴＰリダイレクト」が呼び出され
ないときにＴＣＰ接続リクエストがＶＩＰへ送られてき
た場合、それは使用されない。

【００５４】モニタリング・ハンドオフ交換プロセスに
３つのサイト若しくはそれより少ないサイトしか含まれ
ていないときは、ハンドオフの決定におけるグラニュラ
リティの貧弱さが問題になることがある。このような場
合、最も極端な場合を除けば、「最良」対「最悪」サイ
トを正確に決定するに十分なスループットデータサンプ
ルは存在しない。このような状況におけるこの問題を緩
和するため、スイッチ内の制御や同調可能パラメータが
含まれていなければならない。多くの接続を受け入れる
ことができるサイトは、多くの接続を受け取るために、
あるテンデンシー（性癖）を有する。

【００５５】ＤＳＳＰトリガ型更新は、通常の更新が有
する全ての情報を含んでいるのが好ましいが、これらの
トリガ型更新は、あるスイッチが遠隔サーバともはや通
信をすることができないときに、或いは、全てのサーバ
がそれらの各ＭａｘＣｏｎｎｓに存在し、リアルサーバ
をＶＩＰのために利用することができない等のように、
あるスイッチがローカルリソースコンストレイント（局
部資源制約）を被ったときに、そのスイッチから他の全
てのスイッチへ直ちに送信される。

【００５６】ＤＳＳＰ更新の例を示すため、サイトＡは
５つのピア（同一層内の）サイトＢ〜Ｆを有する。各サ
イトＡ〜Ｆは２つのＶＩＰを実行し、また、各サイトと
互いにピアされている（同一の層内とされている）。セ
ッションハンドオフ分散型サーバの決定のため、各サイ
トのスイッチは、各遠隔ＶＩＰ／局部ＶＩＰ結合につい
ての各マッチング（整合）ドメインネームのために、順
序付けされたハンドオフテーブルを計算する。各スイッ
チは、“www．Alteon．com”を表示するＶＩＰを伝達
し、エントリが、各ＶＩＰの試験応答性に基づいて「計
算されたハンドオフテーブル」に現れる。“www．Alteo
n．com”のような所定のドメインネームのため、順序付
けされたハンドオフテーブルが各スイッチによって構築
されるのが好ましい。ハンドオフテーブルはその後、テ
ーブルを構築するためのドメインネームに関するドメイ
ンネームサーバリクエストがスイッチによって受け取ら
れたときに、調査される。各スイッチは、本明細書のテ
ーブルに示されているように、計算された重み値に基づ
いて遠隔リアルサーバの重みを動的に更新する。“ww
w．Alteon．com”についてのドメインネームサーバリク
エストをいずれかのスイッチが受け取ったとき、そのス
イッチは、現在の重みに基づいて「次に好適の」遠隔サ
ーバに対応するＩＰアドレスを用いて応答する。分散型
サーバＦに対応するＶＩＰは、大体、リクエストの２５
％を受け取る。換言すれば、いずれかのサーバが受け取
っている時間の２５％はドメインネームサーバリクエス
トである、ということであり、そのスイッチは分散型サ
ーバのＶＩＰアドレスを用いて応答する。テーブルＶ：順序付けされたハンドオフ重みテーブルＤＮＳ／ＨＴＴＰリダイレクトハンドオフ重み（トラフ
ィック識別を有する）

【００５７】順序付けされたハンドオフテーブル、即
ち、テーブルＶでは、サイトＣは０の重みを有する。こ
のＶＩＰは、このＶＩＰに送信されるいずれのハンドオ
フリクエストをも有してはならない。この例では、サイ
トＡ、ＢおよびＥがハンドオフの大部分を受け取る。

【００５８】セションハンドオフ実行のため、スイッチ
は、自身がホストになっている（hosting）ドメインネ
ームについてのドメインネームサーバリクエストを受け
取ったときに、ハンドオフ重みやアベイラビリティ（可
用性）等に基づいて、それらのドメインをロードバラン
ス（負荷平衡化）しているスイッチの適当なＩＰアドレ
スを用いて応答する。一般に、近くのサーバがダウンし
ているかまたはオーバーロードしていない場合には、あ
る領域内のユーザがその領域内の若しくはその領域付近
のサーバと関連付けられているときに最良であることが
好ましい。例えば、“www．Alteon．com”に関するホス
トコンテント（内容）がインストールされた５つのサイ
トが全世界、即ち、サンジョーズ（西アメリカ）、アト
ランタ（東アメリカ）、エクアドル（南アメリカ）、パ
リ（フランス）、東京（日本）に存在しているものとす
る。ヨーロッパのユーザは、パリのサイトによってサー
ビスを受けるのが好ましく、チリのユーザは、エクアド
ルのサイトによってサービスを受けるのが好ましい等で
ある。日本のユーザがコンテントのためにはるばるアト
ランタのサイトへやって来たと仮定すると、多くの他の
ユーザがそこから利益を受けることができるような帯域
幅を浪費させ、また、このようなサービスは、直接的に
は、日本のユーザにも不必要な応答遅延を生じさせるも
のとなる。

【００５９】それゆえ、どんなセッションハンド・オフ
を実行する前にもユーザ要求の地理的ソースを最終的に
決定するために重み付けをすることがスイッチに関して
重要である。スイッチが、構成されたドメインに関する
ドメインネームサーバ要求を受信するとき、要求、及び
ＩＡＮＡから種々の地域の登記に発行されたＩＰアドレ
スブロックを備えるそれに全体的に関するソースＩＰア
ドレスを調査すべきである。表４は、種々の地域の登記
に関するアドレスブロック割り当てのいくつかを示し、
それらはそれぞれ地理的なドメインである。表VI

【００６０】表VIのエクステンションは、本発明の各ス
イッチの実施例がアクセスできるデーターベース形式で
提供されるのが好ましい。ソースネットワークは、１２
４−ビットＩＰサブネット深度に変換されるのが好まし
い。使用されるデーターベースは、ＩＡＮＡ「ＷＨＯＩ
Ｓ」データベースから得られるのが好ましい。スイッチ
においてこのような表の情報を使用することによって、
ドメインネームサーバーが、ドメインネームサーバーレ
スポンダーは、要求に関して大よその地理的な決定をす
ることが可能となる。もし、ドメインネームサーバー要
求が211.123.11.20であるならば、要求しているホスト
は環太平洋地域ののいずれかに位置し、203、204、21
1、212のいずれかで始まるサイトに向けられるべきであ
る。もし、分散サイトＶＩＰのいずれかが地理的に異な
ったネットワークにあるならば、スイッチは、全ドメイ
ンネームサーバーが応答する間、この表の情報を使用す
るのが好ましい。

【００６１】ピアハンド−オフプロセスでは、スイッチ
は、特定のＶＩＰドメインネームのドメインネームサー
バールックアップ要求を受信する。スイッチは、ドメイ
ンネームサーバー要求のソースＩＰアドレスを調べ、ユ
ーザーのＩＰアドレスを調べ、そのユーザーに地理的に
近いサーバーサイトがあるかどうかを決定する。スイッ
チは、ドメインに対応する順序づけられたハンド−オフ
表を調べる。スイッチは、（ａ）ドメインネームサーバ
ー要求ソースと比較されたリモートサーバー位置、
（ｂ）リモートサーバー重み、（ｃ）先のハンド−オフ
を体験したリモートサーバーに基づいて、好ましく、次
のリモートサーバー（もしくはそれ自体のＶＩＰ）を選
ぶ。そして、スイッチは、ドメインネームサーバー応答
を順序付けられたリストのＩＰアドレスと共にクライア
ントドメインネームサーバーに返す。

【００６２】スイッチが、スイッチＶＩＰへの「ＴＣＰ
ＳＹＮ」を受信する時、それは、パケットを受け取る
か、もしくは、もし、ローカルＶＩＰが過負荷ならば、
パケットを拒絶する。もし、拒絶ならば、スイッチは、
このドメインの順序付けられたハンド−オフ表を調べ、
（ａ）ドメインネームサーバー要求ソースと比較された
リモートサーバー位置、（ｂ）各リモートサーバーの重
み、（ｃ）先のハンド−オフで識別されたリモートサー
バーに基づいて、好ましく、次のリモートサーバーもし
くはそれ自体のＶＩＰを選ぶ。スイッチは、負荷及び他
のサイトの使用可能性に応じて、「ＨＴＴＰリダイレク
ト」をクライアントに返すか、要求を捨てる。

【００６３】スイッチが、ドメインネームサーバー応答
を出す時、それは、設定可能なドメインネームサーバー
ＴＴＬ値でそのようにし、ダウンストリームドメインネ
ームサーバーが、長時間、サーバースイッチのＩＰアド
レスをキャッシュしないことを確実にする。

【００６４】分散負荷バランシングパラメーターに関
し、各スイッチはスイッチ−ワイド分散ＳＬＢ−パラメ
ータで構成されて、その分散サイトを識別するのが好ま
しい。例えば、全ての他のスイッチの管理ＩＰ−アドレ
スのリストによって構成される。

【００６５】様々な調整可能なパラメータが、本発明の
実施例に含まれるのが好ましい。スイッチあたり８つの
設定可能な分散サイトを有する分散サイトが、リモート
スイッチのＩＰ−アドレスで構成される。これらのサイ
トの各々は、リモートリアルサーバー（ＶＩＰの）が存
在する潜在的なハンド−オフサイトとしてスイッチによ
って認識され得る。分散−サーバー状態プロトコルイン
ターバルは、スイッチが、どのくらい頻繁に定期的なＤ
ＳＳＰアップデートを通知するかを表す。１分のデフォ
ルトで１−１２０分の範囲が選ばれ、個々のサイト毎に
変えられる。ドメインネームサーバーＴＴＬは、ドメイ
ンネームサーバー要求に応答する時に使用されるべきＴ
ＴＬ−値を表す。１分のデフォルトで０−２２５分の範
囲が選ばれる。分散ＳＬＢオン／オフ制御に関し、「Ｈ
ＴＴＰリダイレクト」オプションを使用でき、デフォル
トを「オン」として「オン／オフ」にセットできる。ま
た、「ＵｓｅＤＮＳＲｅｓｐｏｎｄ」オプションを使用
でき、デフォルトを「オン」として「オン／オフ」にセ
ットできる。順序づけられたハンド−オフ重み（１−１
６にインデックス付けされた）は１−６４の値を有する
ことができ、順序づけられたハンド−オフリストを計算
する間考慮される。

【００６６】各ハンド−オフ重みインデックス（１、
２、３、・・・１６）は、最良のパフォーミングサイト
対最悪のパフォーミングサイトに相当する。各インデッ
クスは、順序付けられたハンド−オフリストにおけるサ
ーバースイッチの相対位置によって乗算されるのが好ま
しい統計的に設計された重みを有することができる。も
し、順序付けられたハンド−オフ重み（ＯＨＷ）インデ
ックス−１が４にセットされるならば、最良のパフォー
ミングサイトは、１の重みを有するサイトの４倍の接続
を受信する。代表的な構成を、ＯＨＷ−１を「６」に、
ＯＨＷ−２を「４」に、ＯＨＷ−３を「２」に、そして
他の全てを「１」にといったようにセットしても良い。
これは、第１、第２、第３の最良のパフォーミングサイ
トを、サーバースイッチの残りのものと比較して６倍、
４倍、２倍の多くのハンド−オフを受信するように導
く。

【００６７】図３は、本発明の分散サーバーウェッブバ
ランス方法の実施例のフローチャートを表し、ここで
は、共通参照番号３００で参照される。この方法３００
はステップ３０２で始まり、そのステップでは、ＤＮＳ
−ルックアップのユーザー要求が受信される。このよう
な要求は、特定のウェッブ−ベースの内容及びサービス
で応答するＩＰ−アドレス番号を要求する。ステップ３
０４は、ＤＮＳ−ルックアップ問合せに含まれるユーザ
ーＩＰ−アドレスを調べることによって、ユーザーの地
理的なドメインが何であるかを決定する。ステップ３０
６は、ユーザーの地理的なエリア中もしくはユーザーの
地理的なエリア近くの使用可能なネットワークサイト及
びスイッチを調べる。ステップ３０８は、以降、ユーザ
ーと対応するジョブを与えられるべき「最良の」仮想Ｉ
Ｐ−サーバー（ＶＩＰ）を計算する。何が「最良」を生
ぜしめるかは、何の目標が検討されるかによって変わ
る。「最良」は、ユーザー、ウェッブサイト、バックボ
ーンオペレータ、インターネットサービスプロバイダー
（ＩＳＰ）、コスト等々の観点からの最良のシステム全
体の性能であり得る。バックグランドプロセス３１０
は、全てのＶＩＰの稼働状態及び性能を継続的に監視す
る。ステップ３１２は、ユーザーのＤＮＳ−ルックアッ
プ要求に、ユーザーにサービスするための「最良の」Ｖ
ＩＰのＩＰ−アドレスで応答する。

【００６８】本発明を好ましい実施例を参照してここに
説明したけれども、本発明の精神及び範囲から逸脱する
ことなく、他の応用をここに説明したものの代わりにし
ても良いことは当業者は容易に理解されよう。従って、
本発明は、以下に含まれる請求の範囲によってのみ限定
されるべきである。

【図面の簡単な説明】

【図１】図１は、本発明の分配されたサーバのロードバ
ランシングシステム実施形態のブロックダイアグラムで
ある。

【図２】図２は、サイトAがウェブページのアクセスの
ためにクライアントリクエストを冗長して支持できる他
のいくつかのサイトについて得られる情報を示すダイア
グラムである。

【図３】図３は、本発明の分配されたサーバのロードバ
ランシング方法実施形態のフローチャートである。

【符号の説明】

１０２クライアント１０４インターネット２０２サイト

フロントページの続き (72)発明者シリッシュサテイアメリカ合衆国カリフォルニア州 95118 サンホセボールデラドライヴ 1533

Claims

【特許請求の範囲】

【請求項１】ドメインホストネームに関する特定のユニ
フォームリソースロケータ（ＵＲＬ）の変換に関してネ
ットワークユーザから、数値のインターネットプロトコ
ル（ＩＰ）アドレスに対するＤＮＳルックアップ要求を
受信するドメインネームシステム（ＤＮＳ）サーバを有
し、前記ネットワークユーザは、ユーザＩＰアドレスか
ら識別されうる特定の地理的な領域に存在し、地理的に様々であり、前記ネットワークユーザにアクセ
ス可能である複数のウェブサーバサイトを有し、各々
が、前記特定のＵＲＬに関するそのウェブベースのコン
テンツ及びサービスを別に複製し、複数のウェブサーバサイトの各々のヘルス及び応答パフ
ォーマンスを監視し、個々のアクセス可能性及び地理的
ロケーションに関する複数のウェブサーバサイトのうち
のリストを保守するポリシーマネージャと、前記ネットワークユーザからの前記ＤＮＳルックアップ
要求を受信するために接続され、かかるＤＮＳルックア
ップ要求に応答するように複数のウェブサーバサイトの
うちの好ましい１つに関するポリシーマネージャを調べ
るために接続され、更に、複数のウェブサーバサイトの
うちの前記好ましい１つのＩＰアドレスを備える前記ネ
ットワークユーザを提供するために接続されるＩＰアド
レスコンバータに対するＤＮＳクエリーと、を有する、多くのクライアントに冗長に配送されるウェブベースの
コンテンツ及びサービスを提供する、分散されたロード
平衡インターネットサーバシステム。
【請求項２】複数のウェブサーバサイトの各々が仮想Ｉ
Ｐアドレス（ＶＩＰ）に対応し、世界中の異なる場所で
物理的に位置決めされる、請求項１に記載のシステム。
【請求項３】複数のウェブサーバサイトの各々が、その
他のものをオフ・ロードすることができ、異なった地理
的ロケーションを有する多くの同時のネットワークユー
ザの要求を満たすように並列に作動することができる、
請求項１に記載のシステム。
【請求項４】ＤＮＳクエリー−ＩＰアドレスコンバータ
は、システム・ワイド・ロードが複数のウェブサーバサ
イトの各々の間で平衡がとられるように作動する、請求
項１に記載のシステム。
【請求項５】ポリシーマネージャが、応答時間マトリッ
クスと、前記リストを保守するハンドオフ・テーブルと
を更に含む、請求項１に記載のシステム。
【請求項６】ポリシーマネージャが、最悪のパフォーマ
ンスのウェブサーバサイトに対する最高のパフォーマン
スに対応するハンド・オフ重みインデックスと、サーバ
スイッチのオーダされたハンド・オフ・リストにおける
相対的な位置によって増やされた静的に構成された重み
とを有する、請求項５に記載のシステム。
【請求項７】ポリシーマネージャが更に、インターネッ
トトポロジーアウェアネスと、ヘルス、ロード、周期的
又は所定のイベントによってトリガーがかけられたとき
のいずれかにおけるウェブサーバサイトの間のスループ
ット情報とを交換することができる分散されたＳＬＢス
テートプロトコルと、を有する、請求項５に記載のシス
テム。
【請求項８】複数のウェブサーバサイトが、互いのウェ
ブサーバサイトによる複製に関する全てのウェブコンテ
ンツ及びサービスを提供するメインコンテンツサイトを
含む、請求項１に記載のシステム。
【請求項９】ドメインホストネームに関する特定のユニ
フォームリソースロケータ（ＵＲＬ）の変換に関してネ
ットワークユーザから、数値のインターネットプロトコ
ル（ＩＰ）アドレスに対するＤＮＳルックアップ要求を
ドメインネームシステム（ＤＮＳ）サーバで受信し、前
記ネットワークユーザは、ユーザＩＰアドレスから識別
されうる特定の地理的な領域に存在し、前記ネットワークユーザにアクセス可能である地理的に
様々なロケーションで、複数のウェブサーバサイトを配
置し、各ウェブサーバサイトが、前記特定のＵＲＬに関
するそのウェブベースのコンテンツ及びサービスを別に
複製し、複数のウェブサーバサイトの各々のヘルス及び応答パフ
ォーマンスをポリシーマネージャで監視し、個々のアク
セス可能性及び地理的ロケーションに関する複数のウェ
ブサーバサイトのうちのリストを保守し、前記ネットワークユーザからの前記ＤＮＳルックアップ
要求の受信に応答してＤＮＳクエリーをＩＰアドレスに
変換し、かかるＤＮＳルックアップ要求に応答するよう
に複数のウェブサーバサイトのうちの好ましい１つに関
する前記ポリシーマネージャを調べるために接続し、更
に、複数のウェブサーバサイトのうちの前記好ましい１
つのＩＰアドレスを備える前記ネットワークユーザを提
供するために接続する、ステップを有する、単一のＤＮＳルックアップ要求に応答してロード平衡冗
長サイトから多くのクライアントにウェブベースのコン
テンツ及びサービスを提供する方法。
【請求項１０】複数のウェブサーバサイトの各々が仮想
ＩＰアドレス（ＶＩＰ）に対応し、世界中の異なる場所
で物理的に位置決めされるように、複数のウェブサーバ
サイトを位置決めする、請求項９に記載の方法。
【請求項１１】複数のウェブサーバサイトの各々が、そ
の他のものをオフ・ロードすることができ、異なった地
理的ロケーションを有する多くの同時のネットワークユ
ーザの要求を満たすように並列に作動することができる
ように、複数のウェブサーバサイトを配置する、請求項
９に記載の方法。
【請求項１２】システム・ワイド・ロードが複数のウェ
ブサーバサイトの各々の間で平衡がとられるようにＤＮ
Ｓクエリー−ＩＰアドレスコンバータが作動するよう
に、変換する請求項９に記載の方法。
【請求項１３】ポリシーマネージャが、応答時間マトリ
ックスと、前記リストを保守するハンドオフ・テーブル
とを更に含むように監視する、請求項９に記載の方法。
【請求項１４】前記ポリシーマネージャが、最悪のパフ
ォーマンスのウェブサーバサイトに対する最高のパフォ
ーマンスに対応するハンド・オフ重みインデックスと、
サーバスイッチのオーダされたハンド・オフ・リストに
おける相対的な位置によって増やされた静的に構成され
た重みとを更に有するように監視する、請求項１３に記
載の方法。
【請求項１５】前記ポリシーマネージャが更に、インタ
ーネットトポロジーアウェアネスと、ヘルス、ロード、
周期的又は所定のイベントによってトリガーがかけられ
たときのいずれかにおけるウェブサーバサイトの間のス
ループット情報とを交換することができる分散されたＳ
ＬＢステートプロトコルと、を有するように監視する、
請求項１３に記載の方法。
【請求項１６】前記複数のウェブサーバサイトが、互い
のウェブサーバサイトによる複製に関する全てのウェブ
コンテンツ及びサービスを提供するメインコンテンツサ
イトを含むように配置する、請求項９に記載の方法。