(57)【要約】  クライアントと最も近いウェブサーバとの間の接続を指示するための技術について説明する。ネットワークの情報提供ＤＮＳリゾルバがネットワークの端部に配置される。エニーキャストを使用して、情報提供ＤＮＳリゾルバが、自身の宛先ネットブロックのルートをインターネットに通知する。クライアントからのネットワークに接続するための要求が、ＢＧＰテーブルに基づいて最も近い特定の情報提供ＤＮＳリゾルバへルーティングされる。要求が受信されると、応答が最も近いウェブサーバのＩＰアドレスと共にクライアントへ送信される。ネットワーク内の健康診断の測定結果を通じて最も近いウェブサーバが決定され、情報提供ＤＮＳリゾルバが自身に最も近いＩＰアドレスを動的に選択する。パケットを最も近い情報提供ＤＮＳリゾルバへ向けるルーティングプロトコルが、後続するトラフィックのネットワークへのルートも指示する。従って、情報提供ＤＮＳリゾルバにより選択された最も近いウェブサーバが、クライアントに最も近いウェブサーバとなる。【選択図】図３Ａ
2011509029.tif 000002
【特許請求の範囲】
【請求項１】
サーバに接続するための方法であって、
第２のネットワーク内の第１の複数のサーバから第１のネットワークに前記第２のネットワークへのルートを通知するステップと、
前記通知に少なくとも部分的に基づいて前記第１の複数のサーバのうちの第１の特定のサーバへルーティングされたクライアントからの要求を受信するステップと、
前記第１の特定のサーバにおける前記要求の受信時に、前記第２のネットワーク内の第２の複数のサーバのうちの第２の特定のサーバを少なくとも１つの基準に基づいて選択するステップと、
前記第２の特定のサーバを選択したことに応答して、前記クライアントが前記第２の特定のサーバに接続するための前記第２の特定のサーバのＩＰアドレスを前記クライアントに対して出力するステップと、
を含むことを特徴とする方法。
【請求項２】
前記第１の複数のサーバの各々が、前記第２のネットワークの端部に位置する、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記要求が、エニーキャストに基づいてルーティングされる、
ことを特徴とする請求項１に記載の方法。
【請求項４】
エニーキャストがボーダーゲートウェイプロトコルを使用して実施される、
ことを特徴とする請求項３に記載の方法。
【請求項５】
前記第１の複数のサーバが、前記第２のネットワークのドメインに関連するＤＮＳサーバを含む、
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記第１の複数のサーバがグローバルロードバランシングサーバをさらに含む、
ことを特徴とする請求項５に記載の方法。
【請求項７】
前記第２の特定のサーバを選択するステップが、前記第２の複数のサーバの中でいずれのサーバが前記第１の特定のサーバに最も近いかを判断するステップに基づく、
ことを特徴とする請求項１に記載の方法。
【請求項８】
前記第２の特定のサーバを選択するステップが、前記第１の複数のサーバの各々が前記第２の複数のサーバの利用可能性及び健康状態をモニタするステップをさらに含む、
ことを特徴とする請求項１に記載の方法。
【請求項９】
第２のネットワークの端部に位置し、該第２のネットワークへのルートを第１のネットワークに通知するように構成された第１の複数のサーバと、
前記第２のネットワーク内の第２の複数のサーバと、
を含むシステムであって、
前記第１の複数のサーバのうちの第１の特定のサーバがクライアントから要求を受信するように構成され、前記要求は、前記第１の複数のサーバからの通知に少なくとも部分的に基づいて前記第１の特定のサーバへルーティングされ、
前記第１の特定のサーバは、前記要求の受信時に、前記第２のネットワーク内の前記第２の複数の接続サーバのうちの第２の特定のサーバを少なくとも１つの基準に基づいて選択するように構成され、
前記第１の特定のサーバは、前記第２の特定のサーバの選択に応答して、前記第２の特定のサーバのＩＰアドレスを前記クライアントに対して出力するように構成された、
ことを特徴とするシステム。
【請求項１０】
前記要求がエニーキャストに基づいてルーティングされる、
ことを特徴とする請求項９に記載のシステム。
【請求項１１】
前記第１の複数のサーバが、前記第２のネットワークのドメインに関連するＤＮＳサーバを含む、
ことを特徴とする請求項９に記載のシステム。
【請求項１２】
前記第２の特定のサーバを選択するステップが、前記第２の複数のサーバの中でいずれのサーバが前記第１の特定のサーバに最も近いかを判断するステップに基づく、
ことを特徴とする請求項９に記載のシステム。
【請求項１３】
サーバに接続するための命令を記憶するコンピュータ可読記憶媒体であって、前記命令は、１又はそれ以上のプロセッサにより実行された場合、前記１又はそれ以上のプロセッサに、
第２のネットワーク内の第１の複数のサーバから第１のネットワークに前記第２のネットワークへのルートを通知するステップと、
前記通知に少なくとも部分的に基づいて前記第１の複数のサーバのうちの第１の特定のサーバへルーティングされたクライアントからの要求を受信するステップと、
前記第１の特定のサーバにおける前記要求の受信時に、前記第２のネットワーク内の第２の複数のサーバのうちの第２の特定のサーバを少なくとも１つの基準に基づいて選択するステップと、
前記第２の特定のサーバを選択したことに応答して、前記クライアントが前記第２の特定のサーバに接続するための前記第２の特定のサーバのＩＰアドレスを前記クライアントに対して出力するステップと、
を実行させる命令を含む、
ことを特徴とするコンピュータ可読記憶媒体。
【請求項１４】
前記複数のサーバの各々が前記第２のネットワークの端部に位置する、
ことを特徴とする請求項１３に記載のコンピュータ可読記憶媒体。
【請求項１５】
前記要求がエニーキャストに基づいてルーティングされる、
ことを特徴とする請求項１３に記載のコンピュータ可読記憶媒体。
【請求項１６】
エニーキャストがボーダーゲートウェイプロトコルを使用して実施される、
ことを特徴とする請求項１５に記載のコンピュータ可読記憶媒体。
【請求項１７】
前記複数のサーバが、前記第２のネットワークのドメインに関連するＤＮＳサーバを含む、
ことを特徴とする請求項１３に記載のコンピュータ可読記憶媒体。
【請求項１８】
前記複数のサーバがグローバルロードバランシングサーバをさらに含む、
ことを特徴とする請求項１７に記載のコンピュータ可読記憶媒体。
【請求項１９】
前記特定の接続サーバを選択するステップが、前記特定のサーバに最も近い前記接続サーバを決定するステップに基づく、
ことを特徴とする請求項１３に記載のコンピュータ可読記憶媒体。
【請求項２０】
前記特定の接続サーバを選択するステップが、前記複数のサーバの各々が前記複数の接続サーバの利用可能性及び健康状態をモニタするステップをさらに含む、
ことを特徴とする請求項１３に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上のグローバルトラフィック管理に関し、特に、ある基準に基づいてクライアントを特定のサーバへ向けることに関する。
【背景技術】
【０００２】
この項で説明するアプローチは追求できるアプローチではあるが、必ずしも以前から想到又は追求されていたアプローチではない。従って、他に指示がない限り、この項で説明するアプローチのいずれかを、単にこの項に含まれているという理由で従来技術として見なすべきではない。
【０００３】
グローバルロードバランシングすなわち「ＧＬＢ」は、サーバへのクライアントアクセスを分散したサーバの組全体に分散させる。クライアントアクセスが分散されるサーバの組は、例えばインターネットなどのワイドエリアネットワーク上のサーバであってもよい。説明する目的で、ＧＬＢを使用してインターネット上のサーバ全体にクライアントアクセスを分散させる例について考えてみる。クライアントアクセスのためのサーバの種類は様々であり、以下に限定されるわけではないが、ＨＴＴＰウェブサーバ、ＦＴＰサーバ、ＳＭＴＰ（メール）サーバ、その他の標準的なインターネットプロトコルサーバ、又は専用プロトコルを有するサーバが挙げられる。本明細書で使用する場合、「サーバ」という用語は上記のいずれかの種類のサーバを意味するものとする。
【０００４】
多くのＧＬＢは、様々な能動的及び受動的モニタリング技術を使用して複雑なインターネットのマップを生成する。このマップに基づき、ＧＬＢは、トラフィックルーティングを決定してクライアントを「最も近い」サーバに接続する。本明細書で使用する場合、「近い」とは、必ずしも決定の基礎を地理的な近さのみに置くことを意味するものではない。本明細書で使用する場合、「近い」サーバとは、クライアントへの接続が最も速いサーバのことである。従って、ネットワークの混雑により、クライアントが２００マイル離れたところにあるサーバに到達するよりも１００マイル離れたところにあるサーバに到達する方が遅い場合、ＧＬＢは、クライアントを２００マイル離れたサーバへルーティングする。
【０００５】
グローバルロードバランシングの最も一般的な形は、図１に示すドメインネームサービス（「ＤＮＳ」）に基づくものである。図１に示すシステムでは、地理的に異なるエリアに位置することができる２又はそれ以上のデータセンタが、ウェブアプリケーションをホストできる数多くのサーバを含む。クライアント１０５が、２つのデータセンタの各々によりホストされるウェブアプリケーションに接続したいと望む。例えば、ウェブアプリケーションをホストする一方のデータセンタがニューヨーク１０３に位置し、ウェブアプリケーションをホストする他方のデータセンタがサンフランシスコ１０１に位置することがある。
【０００６】
インターネットサービスプロバイダ（「ＩＳＰ」）は、ＩＳＰのネットワーク内に存在するとともにＩＳＰのユーザと通信してこれらのＤＮＳ要求を処理する、再帰的ＤＮＳリゾルバとも呼ばれる集中型ローカルネームリゾルバを使用することができる。クライアントがローカルネームリゾルバと通信し、ローカルネームリゾルバは、ユーザが要求する情報をどこで発見すべきかを判断する。ドメインの情報提供(authoritative)ＤＮＳリゾルバが、ローカルネームリゾルバから要求を受け取り、ドメインのＩＰアドレスをローカルネームリゾルバへ送信する。ドメインの情報提供ＤＮＳリゾルバとは、ドメインのネットワーク内に存在してこのネットワークのデータを保持するサーバのことである。ＧＬＢは、情報提供ＤＮＳリゾルバの一部であってもよく、或いは情報提供ＤＮＳリゾルバとは別個のものであってもよい。本明細書で使用する場合、「リゾルバ」という用語は情報提供ＤＮＳリゾルバのことを意味するものとするが、ＧＬＢがこの一部であってもなくてもよい。
【０００７】
例えば、図１では、クライアント１０５が、「ｗｗｗ．ｓａｍｐｌｅｄｏｍａｉｎ．ｃｏｍ．」などのドメイン名を含む要求１１１をローカルネームリゾルバ１０７へ送信する。ローカルネームリゾルバ１０７は、「ｗｗｗ．ｓａｍｐｌｅｄｏｍａｉｎ．ｃｏｍ．」の所有者である情報提供ＤＮＳリゾルバ１０９に「ｗｗｗ．ｓａｍｐｌｅｄｏｍａｉｎ．ｃｏｍ．」のＩＰアドレスを要求する（１１５）。「ｗｗｗ．ｓａｍｐｌｅｄｏｍａｉｎ．ｃｏｍ．」の情報提供ＤＮＳリゾルバ（及びＧＬＢ）１０９は、ＧＬＢにより生成されたマップ内の情報に基づくデータセンタのＩＰアドレスでローカルネームリゾルバ１０７に応答する。ＧＬＢが、サンフランシスコ１０１にあるデータセンタへの高トラフィックを検出した場合、ＧＬＢは、ニューヨークにあるデータセンタ１０３の方がクライアント１０５から地理的にかなり離れているとしても、ニューヨークにある「より近い」データセンタ１０３への接続を送信することができる。ローカルネームリゾルバ１０７は、ニューヨーク１０３にあるデータセンタのＩＰアドレスをクライアント１０５へ送信する。この時に初めて、クライアント１０５は、ニューヨーク１０３にあるデータセンタに接続（１１９）を行い、サンフランシスコ１０１にあるデータセンタには接続（１１７）しない。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ファイバの切断、装置の問題、容量の問題、ネットブロックの移動、又は人の介入などによりネットワークトポロジー又は接続性が変化した時に、多くの場合ゼロからインターネットマップを再構築する必要がある。マップの作成又は更新に使用するプロトコル及びアルゴリズムにもよるが、この処理はかなりの時間を必要とする場合がある。インターネットトポロジーの動的性質に起因して、ＧＬＢは、完全で正確なインターネットのモデルを保持することが困難となる場合がある。この結果生じるマップの不正確性が誤ったルーティング決定につながる可能性があり、これがクライアントにとって深刻な影響をサーバ性能に与える可能性がある。この結果、ＤＮＳベースのＧＬＢを使用してインターネットのマップを生成し保持することに基づかない「最も近い」接続をサーバに提供する技術の必要性が存在する。
【０００９】
本発明を、同じ参照数字が類似の要素を示す添付図面の図に限定としてではなく例示として示す。
【図面の簡単な説明】
【００１０】
【図１】ＤＮＳに基づくグローバルロードバランシングを示す図である。
【図２】本発明の実施形態による、最も近いＧＬＢ／情報提供ＤＮＳサーバにルーティングされるネーム解決要求ＩＰパケットを示す図である。
【図３Ａ】本発明の実施形態によるウェブサーバに接続するクライアントを示す図である。
【図３Ｂ】本発明の実施形態による、フェイルオーバーが発生したウェブサーバに接続するクライアントを示す図である。
【図４】本発明の実施形態を実施できるコンピュータシステムを示すブロック図である。
【発明を実施するための形態】
【００１１】
サーバが属する（インターネットなどの）ネットワークのマップを生成することに依拠しない技術を使用してクライアントをサーバに接続するための技術について説明する。以下の説明では、説明を目的として、本発明の完全な理解をもたらすために数多くの特定の詳細について記載する。しかしながら、本発明は、これらの特定の詳細を伴わずに実施できることが明らかであろう。その他の場合、本発明を不必要に曖昧にしないために、周知の構造及び装置についてはブロック図形式で示す。
【００１２】
概要
ある実施形態では、プロバイダのネットワークの端部の異なる場所に複数の情報提供ＤＮＳリゾルバが配置される。本明細書で使用する場合、ネットワークの「端部(edge)」とは、ネットワークの別のネットワークからの接続ポイント又はエントリポイントであるネットワークの部分のことである。他のネットワークとして、以下に限定されるわけではないが、別の私的ネットワーク又はインターネットを挙げることができる。プロバイダのネットワークはまた、クライアントをプロバイダのネットワークに接続できるサーバも含む。プロバイダのネットワーク内のサーバの種類は様々であってもよく、以下に限定されるわけではないが、ＨＴＴＰウェブサーバ、ＦＴＰサーバ、ＳＭＴＰ（メール）サーバ、その他の標準的なインターネットプロトコルサーバ、又は専用プロトコルを有するサーバを含む。複数の情報提供ＤＮＳリゾルバは、ＩＰパケットを「最も近い」情報提供ＤＮＳリゾルバへルーティングできるようにする宛先ＩＰアドレスを通知(announce)する。情報提供ＤＮＳリゾルバが、プロバイダのネットワークに接続するための要求をクライアントから受け取った場合、情報提供リゾルバは、クライアントが接続できるウェブサーバのＩＰアドレスで応答する。
【００１３】
ある実施形態では、グローバルロードバランシングが、情報提供ＤＮＳリゾルバとともに、応答中の情報提供ＤＮＳリゾルバまでのウェブサーバの「近さ」に基づいて、ウェブサーバへのＩＰアドレスを動的に選択する。パケットを特定の情報提供ＤＮＳリゾルバへ向けたルーティングプロトコルが、プロバイダのネットワークへの後続するトラフィックフローのルートも指図する。従って、情報提供ＤＮＳリゾルバにより選択される最も近いウェブサーバは、クライアントに最も近いウェブサーバでもある。その後、クライアントは、情報提供ＤＮＳリゾルバにより指定されたウェブサーバに直接接続する。
【００１４】
これらの方法は、インターネットのマップを構築又は保持する必要なく、クライアントを「最も近い」利用可能なサーバへ動的にリアルタイムで向ける機能を提供する。基本プロトコルが、障害又はトポロジーの変化に対して動的及び自己修正されるように設計されているので、マップの更新に数週間が必要であることとは対照的に、変化に対する秒単位の反応時間で正確なトラフィックルーティングの決定を行うことができる。インターネットのパケットフローを管理してグローバルロードバランシングを決定する同じ基本プロトコルを使用して、本技術は、より正確かつタイムリーなトラフィックルーティングを提供し、この結果向上したウェブサイト性能をもたらすことができる。
【００１５】
エニーキャスト
ある実施形態では、ネットワークの端部の異なる場所に配置された情報提供ＤＮＳリゾルバとともにエニーキャストを使用して、クライアントを「最も近い」情報提供ＤＮＳリゾルバにルーティングする。エニーキャストとは、各々が同じＩＰアドレスを有する複数の利用可能なサーバの場所の１つへインターネットトラフィックをルーティングする方法のことである。ある実施形態では、ネットワークの端部に配置された情報提供ＤＮＳリゾルバの２以上に同じＩＰアドレスが与えられることにより、クライアントＩＰパケットが最も近い情報提供ＤＮＳリゾルバにルーティングされるようになる。エニーキャストは、ユニキャスト及びマルチキャストという用語に似ている。ユニキャストでは、ソースネットワークアドレスと宛先ネットワークエンドポイントとの間に１対１の関係が存在する。マルチキャストでは、ソースネットワークアドレスと宛先ネットワークエンドポイントとの間に１対多の関係が存在する。個々の宛先アドレスが受信者エンドポイントの組を識別し、全ての情報が複製される。対照的に、エニーキャストは、ソースネットワークアドレスと潜在的宛先ネットワークエンドポイントとの間が１対任意の関係にある。個々の宛先アドレスは受信者エンドポイントの組を識別するが、任意の時点においてこれらのうちの１つのみが選択されて、任意の送信者からの情報を受信する。
【００１６】
エニーキャストは、これを全てのインターネットプロトコルに対しては使用できないという不都合を有する。例えば、エニーキャストは、ＴＣＰストリーム内の全てのパケットを同じ宛先に届ける必要がある場合、一貫したポイントツーポイント通信を保証することができず、またＴＣＰストリームに依拠するウェブトラフィックアプリケーションにエニーキャストを使用することはできない。エニーキャストはまた、接続の状態を維持することもできない。しかしながら、エニーキャストは、ＤＮＳネーム解決などの単一のパケット要求及び応答プロトコルを使用するアプリケーションには有用である。
【００１７】
エニーキャストは、ボーダーゲートウェイプロトコル（「ＢＧＰ」）を使用することにより実施することができる。ＢＧＰは、インターネットのコアルーティングプロトコルである。ＢＧＰは、ＩＰネットワークのルーティングテーブル、又はネットワークに到達する能力を指定する「プレフィックス」を保持することにより機能する。ルーティングテーブル内の情報として、以下に限定されるわけではないが、宛先ネットワークのＩＰアドレス、パケットを送信すべき経路のコスト、及び「ネクストホップ」とも呼ばれる、宛先への途中でパケットを送信すべき次のステーションのアドレスを挙げることができる。この結果、ＢＧＰは、利用可能な経路及びネットワークポリシーに基づいてルーティング決定を行う。例えば、同じ宛先への利用可能な２つの経路が存在し、第２の経路よりも第１の経路の方がコストが低い場合、コストが主な問題である場合には第１の経路ルーティングを選択することができる。別の例では、同じ宛先への利用可能な２つの経路が存在する場合、どちらの経路の方がパケットを宛先に速く届けることができるかによってルーティングを決定することができる。これにより「最も近い」ルートが戻される。経路を選択するための基準は実施構成ごとに異なってもよい。
【００１８】
エニーキャストはＤＮＳに関して広範に使用されてきた。例えば、ＤＮＳでは、クライアントが、ネーム解決に関する単一のパケット要求を、複数の情報提供ＤＮＳリゾルバのいずれか１つが応答する大規模ネットワークへ送信することができる。この要求を満たすために、接続又はＴＣＰストリームの状態は要求されないので、ＤＮＳはエニーキャストのための理想的なアプリケーションである。エニーキャストでは、同じプレフィックス、又は宛先ＩＰアドレスのブロックが、インターネット上の多くの異なる場所から同時に通知される。この結果、特定のプレフィックスにアドレス指定されたＩＰパケットを、所与のプレフィックスを通知したインターネット上の「最も近い」場所へルーティングすることができる。
【００１９】
ある実施形態では、ＤＮＳアドミニストレータが、ネットワークの端部にある単一のＩＰアドレスの背後にマスクされた複数の場所にわたって複数のサーバを配置する。ＢＧＰを使用して、情報提供ＤＮＳリゾルバ、又は情報提供サーバの前にあるルータが、ネットワークの端部からこれらの宛先ＩＰブロックへのルートをインターネット全体に通知する。本明細書では、情報提供ＤＮＳリゾルバのＩＰブロックへのルートを通知する場合、情報提供ＤＮＳリゾルバとは、情報提供ＤＮＳリゾルバ自体、情報提供ＤＮＳリゾルバの前にあるルータ、又は情報提供ＤＮＳリゾルバの一部であり得るＧＬＢサーバのことを意味することができる。
【００２０】
クライアントがネットワークに接続したいと望む場合、クライアントは、ネーム解決ＩＰパケットをネットワークへ送信する。着信ＩＰパケットは、ＢＧＰテーブルに基づいて、クライアントからプロバイダのネットワーク内の「最も近い」情報提供ＤＮＳリゾルバへの最短経路によりルーティングされる。
【００２１】
この技術の例を図２に示す。図２では、クライアント２０１がネットワーク２２１に接続したいと望む。ネットワークの例は、ドメイン「ｗｗｗ．ｓａｍｐｌｅｄｏｍａｉｎ．ｃｏｍ．」に関するネットワークであってもよい。ネットワーク２１９の端部の異なる場所又はエントリポイントに（グローバルロードバランシングを含む）情報提供ＤＮＳリゾルバが配置されている。エントリポイント２１５はＤＮＳリゾルバ２０３を含み、エントリポイント２１７はＤＮＳリゾルバ２０５を含み、エントリポイント２１９はＤＮＳリゾルバ２０７を含む。ネットワークはまた、クライアントに接続できるウェブサーバ２０９、２１１、及び２１３も含む。
【００２２】
エニーキャストを使用して、情報提供ＤＮＳリゾルバ、又は情報提供ＤＮＳリゾルバの前にあるルータの２以上が、「ｗｗｗ．ｓａｍｐｌｅｄｏｍａｉｎ．ｃｏｍ」ネットワークに関する同じＩＰ宛先アドレス又はプレフィックスを隣接するネットワークに通知し、これらの隣接するネットワークを介してインターネット全体に通知する。この通知に少なくとも部分的に基づいて、ＢＧＰが、ルータ２２３、２２５、２２７及び２２９に記憶されるルーティングテーブルを生成する。クライアント２０１が「ｗｗｗ．ｓａｍｐｌｅｄｏｍａｉｎ．ｃｏｍ」ネットワークに接続したいと望む場合、クライアント２０１はネーム解決ＩＰパケットを送信する。ＩＰパケットは、ネットワークへのあらゆる経路をたどることができる。ＩＰパケットが経路２５１をたどる場合、ＩＰパケットはルータ２２３に到達する。ルータ２２３は、経路２５３経由による情報提供ＤＮＳリゾルバ２０３への接続を示すルーティングテーブルを含む。ルータ２２３からの経路２５７はルータ２２５に接続する。ＩＰパケットが経路２５５をたどる場合、ＩＰパケットはルータ２２５に到着する。ルータ２２５において、経路２５９はルータ２２７に通じる。ルータ２２７からは、ネットワーク及びＤＮＳリゾルバ２０５への経路２６１を取ることができる。経路２６３はルータ２２９に通じる。ルータ２２９は、経路２６５を経由してＤＮＳリゾルバ２０７に接続することができる。このようにして、クライアント２０１は、１つのルータ（ルータ２２３）ホップを介してＤＮＳリゾルバ２０３に、２つのルータホップ（ルータ２２５、２２７）を介してＤＮＳリゾルバ２０５に、及び３つのルータホップ（ルータ２２５、２２７、２２９）を介してＤＮＳリゾルバ２０７に接続することができる。
【００２３】
ＢＧＰに基づき、ＩＰパケットは、最短経路を使用してネットワーク２２１へルーティングされる。いくつかの例では、情報提供ＤＮＳリゾルバ２０３への経路２５１及び経路２５３を取ることが地理的及び速度的に最も近いものとなり得る。その他の例では、経路２５５−２５９−２６１などの、より地理的に長い経路が速度的に「より近い」ものとなる場合があり、この経路上でＩＰパケットがルーティングされる。
【００２４】
最も近いウェブサーバの選択
ある実施形態では、グローバルロードバランシング（「ＧＬＢ」）により、情報提供ＤＮＳリゾルバが着信ネーム解決要求に動的応答を提供できるようになる。ネーム解決要求が、エニーキャストを使用する「最も近い」情報提供ＤＮＳリゾルバにより受信されると、この情報提供ＤＮＳリゾルバに対して「最も近い」利用可能なウェブサーバのＩＰアドレスを含む応答が行われる。本明細書で使用する場合、以下に限定されるわけではないが、地理的な近さ、トラフィックロード、操作性、及びウェブサーバの健康状態を含む多くの要素により、「近い」ウェブサーバを決定することができる。
【００２５】
ＩＰパケットをクライアントから特定の情報提供ＤＮＳリゾルバへ向けた基本ルーティングプロトコルは、後続する接続トラフィックのルートもプロバイダのネットワークへ向けるので、情報提供ＤＮＳリゾルバに「最も近い」ウェブサーバは、クライアントに「最も近い」ウェブサーバでもある。
【００２６】
ある実施形態では、定期的な健康診断中に、いずれのウェブサーバが情報提供ＤＮＳリゾルバに「最も近い」かが判断される。ウェブサーバの健康診断では、情報提供ＤＮＳリゾルバが、構成されるウェブサーバの全てにポーリングを行う。情報提供ＤＮＳリゾルバは、いずれのサーバが利用可能であるか、及びいずれのサーバが最も近いかに関する情報を収集する。ウェブサーバの健康状態を調べることにより利用可能性を判断することができ、ウェブサーバから情報提供ＤＮＳリゾルバへの応答の待ち時間により近さを判断することができる。この情報が収集され処理されると、情報提供ＤＮＳリゾルバは、最も近い利用可能なウェブサーバのＩＰアドレスでネーム解決要求に応答する。後続するＴＣＰトラフィックフローは、ネットワークの端部にある情報提供ＤＮＳリゾルバを通過してウェブサーバに到達するので、このウェブサーバが、クライアントに最も近い利用可能なウェブサーバにもなる。
【００２７】
本発明のある実施形態による、サーバに接続中のクライアントの例を図３Ａに示す。クライアント３１９がネットワーク３００に接続したいと望む。ネットワークの端部又はエントリポイントには、「１．１．１．１」の宛先ＩＰアドレスを通知する（情報提供ＤＮＳリゾルバを含む）ＧＬＢ３０１、３０３、及び３０５が位置する。エントリポイント３１３はＤＮＳリゾルバ３０１を含み、エントリポイント３１５はＤＮＳリゾルバ３０３を含み、エントリポイント３１７はＤＮＳリゾルバ３０５を含む。
【００２８】
ネットワークはまた、クライアントとＴＣＰ接続を行うことができるウェブサーバも含む。この例では、ウェブサーバ３０７が「２．２．２．２」のＩＰアドレスを有する。ウェブサーバ３０９は「３．３．３．３」のＩＰアドレスを有し、ウェブサーバ３１１は「４．４．４．４」のＩＰアドレスを有する。
【００２９】
クライアント３１９がネットワーク３００に接続したいと望む場合、クライアント３１９は、ネーム解決ＩＰパケットをネットワーク３００へ送信する。ＩＰパケットは、ＢＧＰを介して「最も近い」情報提供ＤＮＳリゾルバ３０１へルーティングされる。この特定の図には、エニーキャスト及びＢＧＰの処理は示していない。この例では、クライアント３１９がＩＰパケットを送信し、これが経路３２３を経由して「最も近い」情報提供ＤＮＳリゾルバへルーティングされるが、この場合の情報提供ＤＮＳリゾルバは情報提供ＤＮＳリゾルバ３０１である。情報提供ＤＮＳリゾルバ３０１は、利用可能なウェブサーバの各々の健康診断を既に行っている。情報提供ＤＮＳリゾルバ３０１は、経路３２９を介してウェブサーバ３０７に、経路３２７を介してウェブサーバ３０９に、経路３２５を介してウェブサーバ３１１にポーリングを行う。この例では、情報提供ＤＮＳリゾルバ３０１は、ウェブサーバ３０７が「最も近い」と判断する。この結果、情報提供ＤＮＳリゾルバ３０１は、ウェブサーバ３０７のＩＰアドレス（「２．２．２．２」）をクライアント３１９へ送信する。この結果、クライアントは、同じ基本プロトコルを使用して、情報提供ＤＮＳリゾルバ３０１が位置するネットワークの端部に接続を行ってウェブサーバ３０７に接続する。このようにして、クライアント３１９は、インターネットのマップを生成せずに最も近いウェブサーバ３０７に接続することができる。
【００３０】
サーバフェイルオーバー
ある実施形態では、選択された情報提供ＤＮＳサーバに近いウェブサーバが存在しなかったり、或いはウェブサーバに障害がある場合、クライアントからウェブサーバへの接続は依然として、選択された情報提供ＤＮＳリゾルバと同じネットワークエントリポイントを通過する。このことは、フェイルオーバー又はオーバーロードフィードバックにおいて発生する場合がある。本明細書で使用する場合、サーバのフェイルオーバーとは、以前アクティブであったサーバの障害又は異常終了時に冗長化サーバ又はスタンバイサーバに自動的に切り換わる機能のことを意味する。本明細書で使用する場合、オーバーロードフィードバックとは、ワーク又はネットワークトラフィックの量が、指定の閾値を超えていること、及び異なるサーバに対する接続要求を行うべきであることを示すサーバ又はネットワークからの情報のことを意味する。このことを図３Ｂに示す。
【００３１】
図３Ｂでは、ウェブサーバ３０７に障害がある。これは、動作障害又はトラフィックオーバーロードに起因し得る。障害は、情報提供ＤＮＳリゾルバ３０１により通常の健康診断下において検出される。クライアントは、図３Ａに示すものと同じ「近い」情報提供ＤＮＳリゾルバ３０１へルーティングされる。この状況下では、クライアントは、依然として同じネットワークエントリポイント３１３を通過する。情報提供ＤＮＳリゾルバ３０１は、「最も近い」ウェブサーバは機能していないウェブサーバ３０７ではなくウェブサーバ３０９であると判断する。情報提供ＤＮＳリゾルバ３０１は、ウェブサーバ３０９のＩＰアドレス（「３．３．３．３」）をクライアント３１９へ送信する。この結果、クライアント３１９は、エントリポイント３１３を介して接続を行い、経路３３１をとってウェブサーバ３０９に接続する。
【００３２】
ある実施形態では、クライアントがウェブサーバに接続されているときにウェブサーバに障害が起きた場合、クライアントは、ネーム解決ＩＰパケットをネットワークに再送信してネットワークに再接続する。初期接続が行われたときと同じ情報提供ＤＮＳリゾルバへＩＰパケットをルーティングすることができる。情報提供ＤＮＳリゾルバは、ポーリングによる利用可能性及び近接性に基づいてウェブサーバを選択する。障害のあるウェブサーバはこれ以上利用できない。新しく選択されたウェブサーバのＩＰアドレスがクライアントへ送信され、クライアントから新しく選択されたウェブサーバに接続が設定される。
【００３３】
ハードウェアの概要
図４は、本発明の実施形態を実施できるコンピュータシステム４００を示すブロック図である。コンピュータシステム４００は、情報を通信するためのバス４０２又はその他の通信機構、及び情報を処理するための、バス４０２に結合されたプロセッサ４０４を含む。コンピュータシステム４００はまた、プロセッサ４０４により実行される情報及び命令を記憶するための、バス４０２に結合されたランダムアクセスメモリ（ＲＡＭ）又はその他の動的記憶装置などのメインメモリ４０６も含む。メインメモリ４０６を使用して、プロセッサ４０４により実行される命令の実行中に一時的変数又はその他の中間情報を記憶することもできる。コンピュータシステム４００は、プロセッサ４０４のための静的情報及び命令を記憶するための、バス４０２に結合された読出し専用メモリ（ＲＯＭ）４０８又はその他の静的記憶装置をさらに含む。情報及び命令を記憶するための磁気ディスク又は光ディスクなどの記憶装置４１０が提供され、バス４０２に結合される。
【００３４】
コンピュータシステム４００を、バス４０２を介して、コンピュータユーザに情報を表示するためのブラウン管（ＣＲＴ）などのディスプレイ４１２に結合することができる。情報及びコマンド選択をプロセッサ４０４に通信するための英数字及びその他のキーを含む入力装置４１４がバス４０２に結合される。別の種類のユーザ入力装置には、方向情報及びコマンド選択をプロセッサ４０４に通信するとともにディスプレイ４１２上のカーソルの動きを制御するためのマウス、トラックボール、又はカーソル方向キーなどのカーソル制御４１６がある。通常、この入力装置は、装置が平面内で位置を特定できるようにする、（ｘなどの）第１軸及び（ｙなどの）第２軸の２つの軸の形の２つの自由度を有する。
【００３５】
本発明は、本明細書で説明する技術を実施するためのコンピュータシステム４００の使用に関する。本発明の１つの実施形態によれば、これらの技術は、メインメモリ４０６に含まれる１又はそれ以上の命令の１又はそれ以上の連続をプロセッサ４０４が実行することに応答してコンピュータシステム４００により実行される。このような命令を、記憶装置４１０などの別の機械可読媒体からメインメモリ４０６に読み込むことができる。メインメモリ４０６に含まれる一連の命令を実行することにより、本明細書で説明する処理ステップをプロセッサ４０４が実行するようになる。代替の実施形態では、ソフトウェア命令の代わりに、又はソフトウェア命令と組み合わせて配線回路を使用して本発明を実施することができる。従って、本発明の実施形態は、ハードウェア回路とソフトウェアとのいずれの特定の組み合わせにも限定されるものではない。
【００３６】
本明細書で使用する「機械可読媒体」という用語は、特定の様式で機械を動作させるデータを提供することに関与するあらゆる媒体のことを意味する。コンピュータシステム４００を使用して実施される実施形態では、例えば、実行用のプロセッサ４０４に命令を提供することに様々な機械可読媒体が関与する。このような媒体は、以下に限定されるわけではないが、記憶媒体及び送信媒体を含む多くの形を取ることができる。記憶媒体として、不揮発性媒体及び揮発性媒体の両方が挙げられる。不揮発性媒体としては、例えば記憶装置４１０などの光又は磁気ディスクが挙げられる。揮発性媒体としてはは、メインメモリ４０６などの動的メモリが挙げられる。送信媒体として、バス４０２を含むワイヤを含む、同軸ケーブル、銅線及び光ファイバが挙げられる。送信媒体はまた、電波及び赤外線データ通信中に生成されるような音波又は光波の形を取ることもできる。このような媒体は全て、媒体によって運ばれた命令を、機械に命令を読み込む物理機構により検出できるようにするために有形のものでなければならない。
【００３７】
機械可読媒体の共通形式として、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、又は他のあらゆる磁気媒体、ＣＤ−ＲＯＭ、他のあらゆる光媒体、パンチカード、紙テープ、穴のパターンを含む他のあらゆる物理媒体、ＲＡＭ、ＰＲＯＭ、及びＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、他のあらゆるメモリチップ又はカートリッジ、以下で説明するような搬送波、又はコンピュータが読み込むことのできる他のあらゆる媒体が挙げられる。
【００３８】
実行用のプロセッサ４０４に１又はそれ以上の命令の１又はそれ以上のシーケンスを搬送する際に、様々な形の機械可読媒体を関与させることができる。例えば、最初に命令を遠隔コンピュータの磁気ディスクに記憶して搬送することができる。遠隔コンピュータは、命令を自身の動的メモリにロードし、モデムを使用して電話回線を介して命令を送信することができる。コンピュータシステム４００に対してローカルなモデムが、データを電話回線上で受信し、赤外線送信器を使用してこのデータを赤外線信号に変換することができる。赤外線検出器が、赤外線信号の形で搬送されたデータを受信することができ、また適切な回路がこのデータをバス４０２上に配置することができる。バス４０２がデータをメインメモリ３０６に搬送し、ここからプロセッサ３０４が命令を取り出して実行する。プロセッサ４０４による実行の前又は後のいずれかに、メインメモリ４０６により受信された命令を任意に記憶装置４１０に記憶することができる。
【００３９】
コンピュータシステム４００は、バス４０２に結合された通信インターフェイス４１８を含む。通信インターフェイス４１８は、ローカルネットワーク４２２に接続されたネットワークリンク４２０に結合する双方向データ通信を提供する。例えば、通信インターフェイス４１８は、対応する種類の電話回線へのデータ通信接続を提供するための統合デジタル通信サービス網（ＩＳＤＮ）カード又はモデムであってもよい。別の例として、通信インターフェイス４１８は、互換性のあるＬＡＮにデータ通信接続を提供するためのローカルエリアネットワーク（ＬＡＮ）カードであってもよい。無線リンクを実現することもできる。あらゆるこのような実施構成において、通信インターフェイス４１８は、様々な種類の情報を表すデジタルデータストリームを搬送する電気、電磁又は光信号を送受信する。
【００４０】
通常、ネットワークリンク４２０は、１又はそれ以上のネットワークを介して他のデータ装置にデータ通信を提供する。例えば、ネットワークリンク４２０は、ローカルネットワーク４２２を介してホストコンピュータ４２４に又はインターネットサービスプロバイダ（ＩＳＰ）４２６により動作されるデータ装置に接続を提供することができる。さらにＩＳＰ４２６は、現在では一般に「インターネット」４２８と呼ばれるワールドワイドパケットデータ通信ネットワークを介してデータ通信サービスを提供する。ローカルネットワーク４２２及びインターネット４２８はともに、デジタルデータストリームを搬送する電気、電磁又は光信号を使用する。コンピュータシステム４００との間でデジタルデータを搬送する、様々なネットワークを介する信号、及び通信インターフェイス４１８を介するネットワークリンク４２０上の信号は、情報を伝送する搬送波の例示的な形である。
【００４１】
コンピュータシステム４００は、（単複の）ネットワーク、ネットワークリンク４２０及び通信インターフェイス４１８を介してメッセージを送信するとともに、プログラムコードを含むデータを受信することができる。インターネットの例では、サーバ４３０が、アプリケーションプログラムに求められるコードをインターネット４２８、ＩＳＰ４２６、ローカルネットワーク４２２及び通信インターフェイス４１８を介して送信することができる。
【００４２】
プロセッサ４０４は、受信したコードを受信時に実行することができ、及び／又は後で実行するために記憶装置４１０、又はその他の不揮発性記憶装置に記憶することができる。このようにして、コンピュータシステム４００は、搬送波の形のアプリケーションコードを取得することができる。
【００４３】
上述の明細書では、実施構成に応じて異なり得る数多くの特定の詳細を参照しながら本発明の実施形態について説明した。従って、本発明が何であるか、及び出願人が何を発明として意図しているかを示す唯一かつ排他的なものが、本出願に由来する特許請求の範囲の組であり、このような特許請求の範囲が発行される特定の形には今後のあらゆる補正が含まれる。本明細書に明確に示す、このような特許請求の範囲に含まれる用語のあらゆる定義が、特許請求の範囲で使用するこのような用語の意味を規定するものとする。従って、特許請求の範囲に明確に記載していない限定事項、要素、特性、特徴、利点又は属性により、決してこのような特許請求の範囲を限定すべきではない。従って、明細書及び図面については限定的な意味ではなく例示的な意味でとらえるべきである。
【符号の説明】
【００４４】
３００  ネットワーク
３０１  ＧＬＢ（グローバルロードバランシング）
３０３  ＧＬＢ（グローバルロードバランシング）
３０５  ＧＬＢ（グローバルロードバランシング）
３０７  サーバ
３０９  サーバ
３１１  サーバ
３１３  エントリポイント
３１５  エントリポイント
３１７  エントリポイント
３１９  クライアント
３２１  経路
３２３  経路
３２５  経路
３２７  経路
３２９  経路
【図１】
2011509029.tif 000003
【図２】
2011509029.tif 000004
【図３Ａ】
2011509029.tif 000005
【図３Ｂ】
2011509029.tif 000006
【図４】
2011509029.tif 000007
【手続補正書】
【提出日】平成22年9月27日(2010.9.27)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
クライアントからのドメイン名を解決するための要求をロードバランシングレゾルバにおいて受信し、ここで、前記ドメイン名にマッピングされたサーバのリストが前記ロードバランシングレゾルバに保持され、前記サーバのリスト内の各々のサーバは互いに異なるアドレスを有しているステップと、
前記ドメイン名にマッピングされた前記サーバのリスト内の特定のサーバを、特定のアドレスを有する前記特定のサーバの前記ロードバランシングレゾルバに対する近接性の尺度に少なくとも基づいて選択するステップと、
前記要求に応答して、前記ロードバランシングレゾルバが、前記選択ステップに基づいて前記特定のサーバの特定のアドレスを前記クライアントに提供するステップと、
を含むことを特徴とする方法。
【請求項２】
前記要求が、エニーキャストアドレスへ向けられるエニーキャストメッセージであり、前記ロードバランシングレゾルバが、前記エニーキャストアドレスを共有する複数のロードバランシングレゾルバの１つである、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記ロードバランシングレゾルバが、前記クライアントと前記特定のサーバとの間の近接性の尺度を示すマッピング情報を保持しない、
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記ロードバランシングレゾルバが、前記クライアントと前記ロードバランシングレゾルバとの間の近接性の尺度を示すマッピング情報を保持しない、
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記ロードバランシングレゾルバが情報提供ネームサーバである、
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記ロードバランシングレゾルバ及び前記サーバのリスト内の前記サーバの両方が第１の論理ネットワーク内に存在し、前記クライアントが第２の論理ネットワーク内に存在する、
ことを特徴とする請求項１に記載の方法。
【請求項７】
前記サーバのリスト内の前記サーバが第１の論理ネットワーク内に存在し、前記ロードバランシングレゾルバが前記第１の論理ネットワークの端部に存在し、前記クライアントが第２の論理ネットワーク内に存在する、
ことを特徴とする請求項１に記載の方法。
【請求項８】
前記近接性の尺度が、地理的な近接性の尺度、前記ロードバランシングレゾルバと前記特定のサーバとの間の接続速度の尺度、前記ロードバランシングレゾルバと前記特定のサーバとの間のトラフィックロードの尺度、及び前記ロードバランシングレゾルバと前記特定のサーバとの間の応答待ち時間の尺度のうちの１つである、
ことを特徴とする請求項１に記載の方法。
【請求項９】
前記特定のサーバが、前記サーバのリスト内の他のいずれのアクティブサーバよりも前記ロードバランシングレゾルバに近いという理由で選択される、
ことを特徴とする請求項１に記載の方法。
【請求項１０】
前記サーバのリスト内の個々のサーバへの接続をモニタする前記ロードバランシングレゾルバをさらに含み、前記選択ステップが前記モニタリング少なくとも基づく、
ことを特徴とする請求項１に記載の方法。
【請求項１１】
複数のコンピュータ装置により実装される複数のロードバランシングレゾルバを備えたシステムであって、
前記複数のロードバランシングレゾルバ内の個々のロードバランシングレゾルバが、同じエニーキャストアドレスで構成され、
前記複数のロードバランシングレゾルバ内の個々のロードバランシングレゾルバが、前記エニーキャストアドレスへ向けられたメッセージを受信するようにさらに構成され、
前記複数のロードバランシングレゾルバ内の個々のロードバランシングレゾルバが、クライアントからのドメイン名を解決するための要求に、
（ａ）前記ドメイン名に割り当てられたサーバのリスト内の特定のサーバを選択するステップ、
（ｂ）前記クライアントに前記特定のサーバのアドレスを提供するステップと、
によって応答するようにさらに構成され、
前記複数のロードバランシングレゾルバ内の個々のロードバランシングレゾルバが、前記サーバのリスト内の前記特定のサーバを、該特定のサーバの前記ロードバランシングレゾルバに対する近接性の尺度に少なくとも基づいて選択するようにさらに構成された、
ことを特徴とするシステム。
【請求項１２】
１又はそれ以上のプロセッサにより実行された場合、請求項１から請求項１０に記載の方法のいずれかを実行させる命令を記憶する１又はそれ以上のコンピュータ可読媒体。
【国際調査報告】
2011509029.tif 000008
2011509029.tif 000009