JP2012528551A

JP2012528551A - レイヤー２ドメインにわたる負荷分散

Info

Publication number: JP2012528551A
Application number: JP2012513343A
Authority: JP
Inventors: パテールパルビーン; モルツデイビッド; グリーンバーグアルバート; ユアンリーフア; カーンランディ
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2009-05-28
Filing date: 2010-05-28
Publication date: 2012-11-12
Anticipated expiration: 2030-05-28
Also published as: CA2759957C; KR101678711B1; US20100302940A1; EP2436157A4; CA2759957A1; CA2763032A1; WO2010138936A2; CN102449963A; EP2436156A4; EP2436157B1; CN102726021B; HK1175321A1; EP2436156B1; EP2436157A2; CN102449963B; WO2010138936A3; WO2010138937A3; CN102726021A; JP5960050B2; US8416692B2

Abstract

本出願は、ネットワーク構成に関し、具体的にはスケーラブル負荷分散ネットワーク構成に関する。一実施形態は、スケーラブル負荷分散システムに結合された外部クライアントを含む。スケーラブル負荷分散システムは、外部クライアントからのパケットフローの個々の着信パケットをカプセル化するように構成された負荷分散レイヤーを含む。負荷分散レイヤーを構成して、さらに、着信パケットをシステム上のターゲットデバイスへとルーティングする。ターゲットデバイスは、複数のＩＰサブネットにまたがることができる。着信パケットは、個々のターゲットデバイスに達するまでに、負荷分散レイヤーの１つ又は複数の負荷分散装置を通過することができる。個々のターゲットデバイスを構成して、１つ又は複数の負荷分散装置のいずれも通過することなく、パケットフローの少なくとも一部の発信パケットを外部クライアントへとルーティングすることができる。

Description

（背景技術）
負荷分散装置は、要求を処理することができる一連のサーバーにわたって一連の要求を
分配することができる、ネットワークインフラストラクチャの重要な一要素であり得る。従来の負荷分散装置は、それぞれが専門ハードウェアである一対のデバイスを含むことができる。この専門ハードウェアを使用しているため、従来の負荷分散装置は多大なコストがかかる傾向にある。別の欠点は、スケールアップ戦略を使用していることである。単一の対の負荷分散装置が同時に扱うことができる要求の数は、ハードウェアの容量によって制限される。より大きい容量のハードウェアを含むより高性能の負荷分散装置を取得して
、追加の要求を扱う。ＤＳＲ（Direct Server Return）の最適化は、ネットワーク中でのトラフィックのボトルネックを緩和するのに有用であり得る。しかし、従来の負荷分散装置の欠点は、この技術が一般的に、ネットワークの単一の仮想ＶＬＡＮ（Virtual Local Area Network）に限定されることである。

添付図面は、本出願において説明される概念の実施形態を示す。図示される実施形態の特徴は、以下の記載を添付図面と併せて参照することにより、より容易に理解することができる。複数の図面における類似の参照番号は、可能な限り、類似の要素を示すのに使用される。さらに、各参照番号の左端の数字は、その参照番号が最初に言及される図面及びそれに関連する考察を表す。

ある実施形態による本発明のある概念を採用することができるネットワーク環境を示す図である。他の実施形態による本発明のある概念を採用することができるネットワーク環境を示す図である。他の実施形態による本発明のある概念を採用することができるネットワーク環境を示す図である。他の実施形態による本発明のある概念を採用することができるネットワーク環境を示す図である。他の実施形態による本発明のある概念を採用することができるネットワーク環境を示す図である。他の実施形態による本発明のある概念を採用することができるスケーラブル負荷分散アーキテクチャを示す図である。本発明の概念のある実施形態による、図１〜６に示されるある構成要素を示す図である。本発明の概念の他の実施形態による、図１〜６に示されるある構成要素を示す図である。ある実施形態による本発明のある概念に適応したハッシュマッピング技術を示す図である。ある実施形態によるスケーラブル負荷分散概念のいくつかを実現することができるフローチャートである。他の実施形態によるスケーラブル負荷分散概念のいくつかを実現することができるフローチャートである。

（序論／概要）
ネットワーク負荷分散装置は、着信パケットをセッションごとに分類し、個々のセッションに関するパケットトラフィックを選択された資源（例えば、サーバー）に分配することによって、ネットワーク中の資源の利用の強化を支援することができる。負荷分散装置におけるパケットトラフィックのボトルネック化の緩和を支援するため、ＤＳＲ（Direct Server Return）などの最適化技術を利用することができる。ＤＳＲにより、ネットワークからの発信パケットトラフィックは、着信パケットトラフィックと同様に負荷分散装置を通過するのではなく、それを迂回することができる。しかし、この技術は、一般的に、ネットワークの単一の仮想ＶＬＡＮ（Virtual Local Area Network）に限定される。対照的に、図１は、本発明の概念のある高次図を示す。

（ネットワークの実施例）
図１は、外部クライアント１０２がインターネット１０６を介してスケーラブル負荷分散システム１０４と通信することができるネットワーク環境１００を示す。負荷分散又は拡散は、ネットワークデバイスが一連の有効な次ホップにわたってトラフィックを拡散することができる任意の適切な手段と見なすことができる。

スケーラブル負荷分散システム１０４は、１１０で示される本質的に無制限の数のターゲットデバイスを支援することができるという点でスケーラブルである、負荷分散機能レイヤー１０８を含むことができる。この場合、「本質的に無制限の」という用語は、概して、スケーラブル負荷分散システム１０４を制御する実体が望ましいと考える数のターゲットデバイスを意味することができる。例えば、ターゲットデバイスの数は、数十、数百、数千、又はそれ以上とすることができる。負荷分散機能レイヤー１０８を、外部クライアント１０２からの通信が通過し、矢印１１２によって示されるように、負荷分散機能によって個々のターゲットデバイスに分配することができるように構成する。しかし、矢印１１４によって表される戻り通信は、外部クライアント１０２へと戻る過程で負荷分散機能レイヤー１０８を通過する必要がない。

簡潔には、ある実施形態は、レイヤー２ドメイン間パケット配信技術を利用して、負荷分散機能１０８を達成することができる。場合によっては、これらのレイヤー２ドメイン間パケット配信技術により、ＤＳＲなどの負荷分散最適化技術を複数のＩＰサブネット間で使用し、それによって本質的に無制限のターゲットデバイス１１０を使用できるようにすることができる。スケーラビリティ及び他の理由から、インターネットプロトコルを使用するネットワークは、ＩＰアドレス中の共通のビットプレフィックスを共有するホストをＩＰサブネットへと分割することができる。一般的に、単一のサブネットの範囲は単一のＶＬＡＮの範囲に制限される。異なるサブネットからのＩＰ（Internet Protocol）アドレスを有するターゲットデバイス１１０を使用できるようにすることで、負荷分散装置の従来の設計における制限を大幅に排除することができる。個々のＩＰサブネットは、スケーラブル負荷分散システム１０４のいくつかのレイヤー２ドメインのうちの１つと関連付けることができる。１つ又は複数の実施形態では、パケットフローの個々の着信パケットは、例えばＩＰ−ｉｎ−ＩＰカプセル化を使用してカプセル化することができる。これは、例えば、負荷分散機能１０８のマルチプレクサ（ＭＵＸ又はＭｕｘ）によって得ることができる。

カプセル化された着信パケットは、個々のターゲットデバイスに達する前に負荷分散機能１０８を通過させることによって、スケーラブル負荷分散システム１０４上の資源又はターゲットデバイス１１０へとルーティングすることができる。少なくともある実施形態では、負荷分散機能は、ＤＳＲなどの最適化技術を使用して、負荷分散機能におけるパケットフローのトラフィックを低減／最小化することができる。ターゲットデバイス（例えば、サーバー）は、複数のＩＰサブネット又はＶＬＡＮと関連付けることができ、したがって、それらの間にまたがることができる。個々のターゲットデバイスと関連付けられた構成要素（例えば、ソフトウェア構成要素）は、受信した着信パケットのカプセル化を解除（ｄｅ−ｃａｐｓｕｌａｔｅ）してＩＰ情報を取得することができる。次に、その結果（発信パケット）を、負荷分散機能１０８を通過させる（すなわち、そこを通す）ことなく、スケーラブル負荷分散システム１０４から外部クライアント１０２（例えば、着信パケットの１つ又は複数を受信するクライアント）へとルーティングすることができる。簡潔には、スケーラブル負荷分散システム１０４は、負荷拡散及び余計なアドレス解決プロトコル（Ｇ−ＡＲＰ）と関連付けられた機能性を含む新たな機能性を可能にすることができる。これらの概念については以下でさらに展開する。

図２は、１つ又は複数の実施形態による別の実施例のネットワーク環境２００を示す。ネットワーク環境２００は、図１に関連して上述した概念を達成することができる実施例の構造又は構成要素を提供する。ネットワーク環境２００は、インターネット１０６又は他のネットワークを介してスケーラブル負荷分散システム２０４と通信する外部クライアント２０２を含むことができる。スケーラブル負荷分散システム２０４は、一連のルーター２０６、一連の動的負荷分散装置（ＤＬＢ）２０８、及び一連のターゲットデバイス２１０を含むことができる。この実施例では、一連のルーター２０６はルーター２０６（１）及び２０６（ｎ）として明示する。一連のＤＬＢ２０８は、マルチプレクサ（つまり、ＭＵＸ）２１２（１）及び２１２（ｎ）をそれぞれ含むＤＬＢ２０８（１）及び２０８（ｎ）として明示する。一連のターゲットデバイス２１０は、アプリケーションサーバー２１４（１）及び２１４（ｎ）、ならびにローカル負荷分散装置２１６（１）及び２１６（ｎ）として明示する。

２１８で全体が示される点線の矢印は、スケーラブル負荷分散システム２０４の構成要素間の潜在的な通信パスを示す。太い実線の矢印２２０（１）及び２２０（２）は、ネットワーク環境２００を通って外部クライアント２０２からアプリケーションサーバー２１４（１）に至る２つの潜在的なパケットフロー経路を示す。太い実線の矢印２２２は、アプリケーションサーバー２１４（１）から外部クライアント２０２への戻りパケットフローパスを表す。例えば、太線の矢印２２０（１）及び２２０（２）は、アプリケーションサーバー２１４（１）によって扱われる外部クライアント２０２からの検索クエリを表すことができる。そのため、アプリケーションサーバー２１４（１）は「ターゲットデバイス」と呼ぶことができる。ここでは、ターゲットデバイスはアプリケーションレベルのアプリケーションサーバーであるが、サンプルのターゲットデバイスは、それに加えて又はその代わりに、例えばアプリケーションレベルの負荷分散装置であるローカル負荷分散装置など、別のタイプのターゲットデバイスであり得ることを認識し、理解されたい。注目すべきは、着信パケットフロー（すなわち、太線の矢印２２０（１）及び２２０（２））は一連のＤＬＢ２０８の１つを通過するが、発信される戻りパケットフロー（すなわち、太線の矢印２２２）は必ずしも負荷分散装置を通過せず、その代わりにＤＬＢを迂回するという点である。その結果、ＤＬＢにおけるパケットフロートラフィックのボトルネック化を低減又は最小化することができる。少なくともある実施形態では、これはＤＳＲ最適化技術を利用することによって得ることができる。実施例のＤＳＲ最適化技術については後述する。

少なくともある実施形態では、ＤＬＢ２０８（１）及び２０８（ｎ）の１つ又は複数に対するＭＵＸ２１２（１）及び／又は２１２（ｎ）は、ＩＰ−ｉｎ−ＩＰカプセル化を使用して、パケットフローをターゲットデバイス２１０に送ることができる。特定のカプセル化の実施例が提供されるが、カプセル化は、パス又はパスの一部に沿ってパケットの配信をアドレスする任意の手段であることができる。それに加えて、ターゲットデバイスに対するカプセル化解除構成要素２２２（１）〜２２２（ｎ）は、着信パケットフローの１つ又は複数のパケットのカプセル化を解除し、その結果（すなわち、発信パケットフロー）を外部クライアント２０２に返すことができる。一実施例では、カプセル化解除構成要素２２２（１）〜２２２（ｎ）は、ターゲットデバイス２１０上において、ターゲットデバイスのプロセッサによって実行可能なソフトウェア構成要素として明示することができる。

この実施形態では、ルーター２０６は、等コストマルチパス（ＥＣＭＰ）を使用して、ＤＬＢ２０８のＭＵＸ２１２（１）及び２１２（ｎ）にまたがってパケット負荷を拡散させることができる。さらに、ＭＵＸは、ターゲットデバイス２１０に送られるパケットに対してコンシステントハッシングを提供することができる。本発明の実施形態のいくつかでは、ＤＬＢ２０８及びターゲットデバイス２１０は、サーバー（１つ又は複数）などの単一のデバイス上に実装することができる。例えば、サーバーなどの単一の計算デバイスは、ＭＵＸ２１２（１）を備えたＤＬＢ２０８（１）及びアプリケーションサーバー２１４（１）を含むことができる。他の実施形態では、ＤＬＢはターゲットデバイスとは別個のデバイス上にあることができる。

動作の際、この実施例におけるＤＬＢ２０８はそれぞれ、ＡＰＩ（Application Program Interface）を提供して、ＶＩＰ（Virtual IP）をＶＩＰ−ＤＩＰマップのＤＩＰ（Direct IP）マッピング（例えば、ＶＩＰ→｛Ｓｌｏｔ₁，Ｓｌｏｔ₂，Ｓｌｏｔ₃，…，Ｓｌｏｔ_N｝）に統合するように構成することができる。個々のスロットはＤＩＰに割り当てられる。単一のＤＩＰがこのＶＩＰｔｏＤＩＰマップに複数回現れる場合がある。このＶＩＰｔｏＤＩＰマップはＶｉｐＭａｐと呼ぶことができる。

単一のＶＩＰアドレスとＤＩＰアドレスのリストとの間のマッピングとして上述してきたが、各アドレスはまた、ポート番号（例えば、ポート８０などのＴＣＰ（伝送制御プロトコル）ポート）と関連付けられてもよいことが理解されるべきである。この一般化では、ＶＩＰアドレス、又はＶＩＰアドレス及びポート番号を、ＤＩＰアドレス単独又はＤＩＰアドレスとポート番号のどちらかであるエントリからなるリストにマッピングすることができる。単一のＤＩＰアドレスが複数回、単独で、又は異なるポート番号とともに、若しくは同じポート番号とともに、任意の組み合わせで現れることがある。また、ＤＩＰ及びＤＩＰとポート番号の組み合わせの同一のリストをマッピングする、複数のＶＩＰ、又はＶＩＰとポート番号の組み合わせが存在することがある。ＤＬＢ２０８の個々のＭＵＸ２１２（１）〜２１２（ｎ）はそれぞれ、個々の受信パケットフローのパケットからのヘッダー部をハッシュし、その個々のパケットをターゲットデバイス２１０と関連付けられた適切なＩＰアドレスに送るように構成することができる。例えば、実施例の受信パケットについて考察する。ＤＬＢの一方又は両方は、実施例の受信パケットをハッシュし、計算によってスロット（例えば、｛Ｓｌｏｔ₁，Ｓｌｏｔ₂，Ｓｌｏｔ₃，…，Ｓｌｏｔ_N｝）を選択することができる。

Ｓｌｏｔ_i＝Ｎを法とするハッシュ（パケットヘッダフィールド）
ここで、ＮはＶＩＰ−ＤＩＰマップにおけるスロットの数である。次に、ＤＬＢ（１つ又は複数）のＭＵＸ（１つ又は複数）は、実施例の着信パケットをＳｌｏｔ１に示されるアドレスに送ることができる。この設計の潜在的な利点は、どのＤＬＢ２０８がパケットを処理するかに関わらず、同じフロー（例えば、すべてのパケットがＩＰソースアドレス、ＩＰ宛先アドレス、ＴＣＰソースポート、ＴＣＰ宛先ポート、及びＩＰプロトコル番号の同じ５タプルを共有するＴＣＰフロー）の一部であるパケットを同じターゲットデバイス２１０に転送できることである。

図３は、上述のネットワーク環境２００の代替の実施例を提供する別の実施例のネットワーク環境３００を示す。簡潔には、ネットワーク環境３００はネットワーク環境２００に類似している。しかし、ネットワーク環境３００では、ローカル負荷分散装置（ＬＬＢ）はＤＬＢとターゲットデバイスとの間の介在レイヤーと見なすことができる。具体的には、ネットワーク環境３００は、インターネット又は他のネットワーク３０６を介してスケーラブルネットワーク分散システム３０４と通信する外部クライアント３０２を含む。ネットワーク分散システム３０４は、ルーターレイヤー３０８、ＤＬＢレイヤー３１０、ＬＬＢレイヤー３１２、及びターゲットデバイスレイヤー３１４を含む。この場合、ターゲットデバイスレイヤー３１４はアプリケーションサーバー３１４（１）〜３１４（ｎ）を含む。ＬＬＢレイヤー３１２はＬＬＢ３１２（１）〜３１２（ｎ）を含む。

カプセル化解除構成要素３１６（１）〜３１６（ｎ）はそれぞれ、ＬＬＢ３１２（１）〜３１２（ｎ）上に駐在する。この構成では、外部クライアントの通信はＤＬＢレイヤー３１０でカプセル化し、ＬＬＢレイヤー３１２で受信されるとカプセル化を解除することができる。次に、通信を適切なアプリケーションサーバー３１４（１）〜３１４（ｎ）に転送することができる。外部クライアント３０２へのあらゆる戻り通信は、ＤＬＢレイヤー３１０及びＬＬＢレイヤー３１２を迂回させることができる。ＤＬＢレイヤー及びＬＬＢレイヤーを迂回させることで、潜在的なボトルネックを回避し、かつ／又は着信する通信のためにシステム資源を保存することができる。

図４は、スケーラブル負荷分散システムのネットワーク環境４００における構成要素の別の高次の実施例を示す。この実施例では、これらの構成要素は、クエリジェネレーター４０２（１）〜４０２（ｎ）、アクセスルーター（ＡＲ）４０４（１）〜４０４（ｎ）、レイヤー２集合スイッチ４０６（１）〜４０６（ｎ）、及びＴｏＲ（Top of Rack）スイッチ４０８（１）〜４０８（ｎ）を含む。ＴｏＲは、ＭＵＸ（Ｍ）、ヘルスモニタ（Ｈ）、サーバー（Ｓ）、負荷分散装置（Ｂ）などの様々なサーバーラック構成要素と通信することができる。

特定のサービスに役立つＶＩＰ１に対しては、ＡＲ４０４（１）〜４０４（ｎ）を、同じコストを有するＩＩＰ（Intermediate IP）アドレス（ＩＩＰ１〜ＩＩＰＮ）への次ホップをそれぞれ指すＮ個のルートで構成することができる。ＡＲでは、ルートはすべてＶＩＰに対する次ホップであってもよい。したがって、ＡＲはＮ個のＩＩＰアドレス内でトラフィックを均等に分配してもよい。これらのルートは、等しい距離空間を有するＡＲ上の静的ルート（すなわち、等コスト静的ルート（図５に関連して後述する））として構成することができる。あるいは、これらのルートは、ＡＲと適切なセッションをもつルーティングプロトコル（例えば、ＢＧＰ (Border Gateway Protocol) 又はＯＳＰＦ (Open Shortest Path First)スピーカーによって動的に確立することができる。それに加えて、ＡＲはＶＩＰをアナウンスするように構成することができる。ＩＩＰはＭＵＸ（Ｍ）をまたいで分割されてもよい。ＭＵＸは、構成されたＩＩＰに対するＡＲＰリクエストに応答できるように、それ自体のＩＰアドレス（ＭＩＰ）に加えて、１つ又は複数のＩＩＰアドレスも有して構成されてもよい。したがって、個々のＭＵＸは転送されたトラフィックの一部分を受信してもよい。パケットを受信する際、個々のＭＵＸは、１つの活動中のＤＬＢを選択してトラフィックを転送する、コンシステントハッシングアルゴリズムを実行することができる。

ＭＵＸは、同じ一連の活動中のＤＬＢに基づいて同じコンシステントハッシングアルゴリズムを使用してもよい。したがって、どのＭＵＸがＡＲ４０４（１）〜４０４（ｎ）からパケットを受信しても、それを同じＤＬＢに転送することができる。新しいＤＬＢが追加されるか、又はプールから除去されると、それによって一部の局所的構成が変化する場合があるが、既存の接続は保存できることに留意されたい。

図５は、Ｎ個の等コスト静的ルートを構成するためのネットワーク環境５００及びそれに関連する技術を示す。この例では、ネットワーク環境５００は、アクセスルーター４０４（１）（図４にて言及）、ＩＩＰ（１）〜ＩＩＰ（ｎ）、ＭＵＸ２１２（１）〜２１２（ｎ）、及びＤＬＢ２０８（１）〜２０８（ｎ）（図２にて言及）を含む。ネットワーク環境５００は、各ＶＩＰに対してＮ個の等コスト静的ルートを構成することができる。これらの等コスト静的ルートの次ホップは中間ＩＰ（ＩＩＰ）アドレスＩＩＰ（１）〜ＩＩＰ（ｎ）を指す。これらのＩＩＰアドレスは、ＶＩＰ及びＤＩＰプールとは無関係に別個のアドレスプールから取り出されてもよい。この実施形態はまた、トラフィックがＮ個のＩＩＰアドレスに等しく分配されるように、負荷拡散を始めることができる。

別の実施形態では、ルーターに対するＢＧＰ接続などのルーティングプロトコルを使用して、起動していて各ＶＩＰに対するパケットを受け取っているＭＵＸの情報をルーターに与えることができる。

様々な実施形態は、ＭＵＸモジュールが移り変わる間、長期にわたる接続をどのように保存するかという課題に対処することができる。ある実施形態で利用される方策は、各ＭＵＸで扱われる個々のフローの状態を保持し、この状態のコピーを、個々のＭＵＸがスケーラブル負荷分散システムに追加されたときにそのＭＵＸに与えるというものであり得る。既存の接続を壊さずにＭＵＸの追加又は削除を扱うため、１つの代替の実施例は、新しい接続が任意のＭＵＸによって最初に扱われるたびに状態情報を作成するというものである。この状態は、ピアツーピア機構によって直接、あるいは、接続のためにパケットを扱う必要がある任意のＭＵＸが、他のＭＵＸがその接続のパケットを送ったＤＩＰを決定することができる、論理的に集約されたストアに状態を送ることによって間接的に、ＭＵＸの間で共有することができる。

状態の共有の必要性がはるかに少なく、したがってより一層スケーラブルであり得る代替の実施形態は、ＭＵＸがＶＩＰとＤＩＰの間の現在のマッピング（すなわち、ＶｉｐＭａｐ）を使用して、あるいは、１つのＶｉｐＭａｐ（Ｖ）を使用するパケット転送から別のＶｉｐＭａｐ（Ｖ’）を使用するパケット転送へと変化する遷移期間に、パケットを転送するというものである。この実施形態では、ＭＵＸを、Ｖ、Ｖ’、及びそれらの現在の遷移状態（すなわち、ＶとＶ’との間で遷移する状態にあるか、又はそれらすべてが全パケットに対してＶ’のみを使用して転送を始めているか）に同意するようにすることができる。遷移中でない場合、すべてのＭＵＸは現在のＶｉｐＭａｐを使用してすべてのパケットを転送する。遷移中である場合、ＭＵＸは、新しい接続のパケット（例えば、ＴＣＰＳＹＮパケット）を発見するたびにローカル状態を作成する。新しい接続以外のものを示すパケットを転送するときは、ＭＵＸは、その接続に対する状態を有しているかを確かめる。状態を有している場合、ＭＵＸは新しいＶｉｐＭａｐＶ’を使用してパケットを転送し、そうでなければ、古いＶｉｐＭａｐＶを使用してパケットを転送する。

簡潔には、少なくともある構成では、ＭＵＸ２１２（１）〜２１２（ｎ）は次の主要構成要素を有してもよい。（１）ＩＩＰの所有権をルーターに対して主張し、そのＩＩＰに対するトラフィックを受信するＩＩＰモジュール、（２）どのＤＬＢ２０８（１）〜２０８（ｎ）がトラフィックを転送するかを決定するコンシステントハッシングモジュール、（３）パケットを修正するパケットリライター、（４）ローカルＤＬＢモニタ。これらの構成要素のいずれか又はすべてを、簡単に入手できる（すなわち、商品の）サーバーに、及び／又は様々なシステム設計のルーターに実装することができる。ＭＵＸ構成要素については、図６〜８に関連してより詳細に後述する。

ＩＩＰモジュール（ＩＩＰ（１）〜ＩＩＰ（ｎ））は、ＡＲＰプロトコルによってＭＵＸ２１２（１）〜２１２（ｎ）をルーターに登録する役割を担ってもよい。基本的に、ＩＩＰモジュールは、ルーター上で、ＩＩＰアドレス及びＭＵＸＭＡＣアドレスのＩＰ−ＭＡＣマッピングを確立してもよい。

実施例の機能（function）「ｂｏｏｌＡｄｄＩＰ（ＩＰＡｄｄｒｅｓｓｉｉｐ）」について考察する。この実施例の機能では、ＩＩＰアドレスは、ＭＵＸインターフェース上の二次的なＩＰアドレスと考えることができる。ＭＵＸが複数の二次的なＩＰアドレスを有することが可能であることに留意されたい。「ＡｄｄＩＰ（）」によって、ＭＵＸネットワークスタックが３つの余計なＡＲＰ（Ｇ−ＡＲＰ）リクエストを送ってもよく、それによってルーターのＡＲＰテーブルを更新する（又はＩＰアドレス自体に対する競合検出を開始する）ことができる。

説明のため、実施例の機能「ＲｅｍｏｖｅＩＰ（ＩＰＡｄｄｒｅｓｓｉｐｐ）」について考察する。この実施例の機能は、ＭＵＸインターフェースからＩＩＰアドレスを除去してもよい。実施例の機能「ＳｅｎｄＡＲＰ（）」についても考察する。この実施例の機能はＧ−ＡＲＰリクエストの送信を強制してもよい。このＧ−ＡＲＰリクエストは、ＩＩＰ−ＭＡＣマッピングの正確性に対する予備的基準として送られてもよい。

（Ｇ−ＡＲＰ及びアドレス競合検出）
ＩＰアドレスをインターフェースに追加する際、オペレーティングシステム（ＯＳ）はＧ−ＡＲＰを（同じＬ２ドメイン内で）ブロードキャストすることができる。このＧ−ＡＲＰリクエストは、それが要求するＩＰアドレスを求めてもよい。他のマシンがこのＩＰアドレスに返答しない場合、ＩＰアドレスは成功裏に追加されてもよい。そうでなければ、ＩＰアドレスの競合を検出することができ、ＭＵＸスタックが、マシンがこのＩＰアドレスを要求するのを防いでもよい。これは、別のＭＵＸがＩＩＰを要求していて（例えば、フェイルオーバー）、それを除去できなかった場合に起こり得る。このシナリオは、外部基準によって（例えば、防御するマシンの切換えによって）扱うことができる。

新しいＭＵＸ、例えばＭＵＸ「Ｂ」が、ＭＵＸ「Ａ」との置換えを必要とする際（例えば、ＭＵＸＡの計画ダウンタイム及び／又はＭＵＸＡのシステム障害によって）、新しいＭＵＸＢはＭＵＸＡのＩＩＰを自身のインターフェースに追加してもよい。

少なくとも１つの実施形態では、上述したようなモジュールは、パケットフローをサーバーのプール内の１つ又は複数のステートフルモジュールに導いてもよく、ステートフルモジュールはフロー状態ごとにそれを保持してもよい。この場合、受信パケットは、ルートをクライアントからモジュールへ、ステートフルモジュールへ、さらに関連したリクエストを扱うターゲットサーバーへと進めてもよい。送信フローは、ターゲットサーバーからステートフルモジュールへ、さらにクライアントへとルーティングしてもよい。ステートフルモジュールでのフロー状態ごとに、個々のステートフルモジュールがフローレベルでポリシーを適用して、追加の負荷分散機能を支援してもよい。特に、ステートフルモジュールは、例えば、クッキー若しくはＵＲＬを検査して、ターゲットサーバーに対する負荷分散が、アプリケーション、クライアントリクエスト、及び／又はサーバーとネットワーク要素に対する役割及び／又は負荷及び／又は条件に依存するようにカスタマイズすることができる。この実施形態は、ＣＰＵ及び状態集約的ワークロードを必要なだけの数のサーバーに展開させることができるので、有利であり得る。

少なくとも１つの実施形態では、モジュールは、ステートフルモジュールへのルーティングを、ＴＣＰ／ＩＰ及びアプリケーションヘッダーが所持するヘッダー情報よりも深い情報に依存させるように適合することができる。特に、Ｗｉｎｄｏｗｓ７（登録商標）などにおける直接アクセス機能を支援するため、モジュールは、パケットの一部の解読を可能にする暗号プロトコルを学習するか、又はそれに参加することができる。その結果、ステートフルモジュールによるターゲットサーバーの選択は、解読された部分に依存することができる。ターゲットサーバーが、送信フローを扱うことができる（かつ潜在的に最も適切な）ステートフルモジュールにそれを戻すように、メカニズムを構築することができる。これは、プログラマブルＣＰＵを使用してモジュールを実現することによって利益を得てもよい。

少なくとも１つの実施形態では、モジュールは、ＩＰ（Internet Protocol）オプションなどのパケットヘッダーのどこかの部分に元の宛先アドレスを含め、パケットをターゲットデバイスに送ってもよい。パケットの一部がモジュールを通過しない場合、ターゲットデバイスは、この情報をパケットヘッダーから抽出し、それを使用してソース（例えば、外部クライアント）に直接発信パケットを送ることができる。

図６は、上述した概念及び後述する概念を達成することができる実施例のスケーラブル負荷分散システムアーキテクチャ６００を示す。この実施例では、スケーラブル負荷分散システムアーキテクチャ６００は、スケーラブル負荷分散マネージャ６０２を含むことができ、ＭＵＸロールは６０４で表され、ＤＩＰロールは６０６で表される。負荷分散システムアーキテクチャ６００はさらに、ヘルスモニタ６０８、ヘルスプローブ６１０、及びルートマネージャ６１２を含むことができる。ＭＵＸロール６０４は、ユーザーモード６１６で動作するＭＵＸコントローラ６１４と、カーネルモード６２０で動作するＭＵＸドライバ６１８とを伴うことができる。ＤＩＰロール６０６は、ユーザーモード６２４で動作するＤＩＰコントローラ６２２と、カーネルモード６２８で動作するカプセル化解除ドライバ６２６とを伴うことができる。

スケーラブル負荷分散マネージャ６０２は、スケーラブル負荷分散システムアーキテクチャ６００との相互作用のためのエントリポイントと見なすことができる。スケーラブル負荷分散マネージャ６０２は、スケーラブル負荷分散概念の一実施例を管理するのに使用することができるＡＰＩを提供することができる。スケーラブル負荷分散の実施例は、ＸＭＬ構成又はＡＰＩを使用して指定することができる。

スケーラブル負荷分散マネージャ６０２は、ＭＵＸマシンに対するＶＩＰ：ＤＩＰマッピングを構成し、ＭＵＸマシンが同期し続けることを確保する役割を担うことができる。さらに、スケーラブル負荷分散マネージャ６０２は、ＤＩＰが追加されるか、又はプールから適切に除去されたとき、長期にわたる接続の保存を促進することもできる。この機能については、図９に関連してより詳細に後述する。

利用可能性を向上するため、スケーラブル負荷分散マネージャ６０２を複写することができ、マスター選択アルゴリズムを使用して状態の一貫性を確保することができる。

ＭＵＸロール６０４は、１つ又は複数のＩＩＰ（Intermediate IP）アドレスで構成されてもよい。図４に関連して上述したように、ルーター４０４（１）などのルーターは、ＶＩＰに宛てられたパケットを一連のＩＩＰに向けて転送するように構成されてもよい。所与のＩＩＰを有して構成されたＭＵＸは、そのＩＩＰに向けて転送されたパケットに対するＭＵＸ処理を行う。

ＭＵＸコントローラ６１４はＭＵＸドライバ６１８を制御することができる。ＭＵＸコントローラは、スケーラブル負荷分散マネージャ６０２によって使用されるウェブサービスＡＰＩをエクスポートして、ＭＵＸを制御することができる。ある実施形態では、ＭＵＸコントローラは次の機能を行うことができる。

１．ＶＩＰ：ＤＩＰマップをドライバにダウンロードする。
２．長期にわたる接続をドライバに通知する。
３．ドライバから統計を収集する。
４．ネットワークインターフェース上でＩＩＰを構成する。
５．指定されたＩＩＰに対してネットワーク上でＧ−ＡＲＰパケットを送出して、ネットワーク上のルーター又は他のホストによってＩＩＰに向けて転送されたあらゆるパケットをＭＵＸに集める。

ＭＵＸドライバ６１８は、基本のパケット修正機能を実装することができる。ＭＵＸドライバは、着信パケットのヘッダー部をハッシュし、それに対してハッシュ値及び現在のＶＩＰマップに基づいてＤＩＰを選び、配信のためにパケットをカプセル化することができる。マップに加えて、ＭＵＸドライバ６１８は、すべてのＶＩＰに対してすべての長期にわたる接続のハッシュ：ＤＩＰマッピングのキャッシュを維持することもできる。

ＤＩＰコントローラ６２２は、ＤＩＰマシン上のカプセル化解除ドライバ６２６を制御することができる。ＭＵＸコントローラ６１４と同様に、ＤＩＰコントローラ６２２は、スケーラブル負荷分散マネージャ６０２によって使用されるウェブサービスＡＰＩをエクスポートして、ＤＩＰマシンを制御し問い合わせることができる。ある実施形態では、ＤＩＰコントローラ６２２は次の機能を行うことができる。

１．ループバックインターフェース上でＶＩＰを構成する。
２．指定されたＶＩＰに対してカプセル化解除を構成する。
３．現在活動中の接続についてＤＩＰマシンに問い合わせる。
４．ＤＩＰマシンの健全性を問い合わせる（これは、ヘルスモニタの実装に応じて任意である）。

カプセル化解除ドライバ６２６は、指定されたＶＩＰに宛てられたＩＰ−ｉｎ−ＩＰパケットのカプセル化を解除することができる。この特徴は、特定のアプリケーションとの間で進行中の通信の切断を回避する助けとなる。例えば、生のソケットを使用してＩＰ−ｉｎ−ＩＰを送っているアプリケーションがある場合（例えば、仮想プライベートネットワークＶＰＮアプリケーション）、カプセル化解除ドライバ６２６はそれらのカプセル化を解除しない。

ルートマネージャ６１２は、ＭＵＸマシンが追加されるか、又はプールから除去されるとき、ルーターを構成する役割を担うことができる。ルートマネージャは、ＯＳＰＦ若しくはＢＧＰなどのルーティングプロトコル、又はインターフェースを使用して、ルーター上に静的ルートを構成することができる。

ヘルスモニタ６０８は、ＭＵＸマシン及びＤＩＰマシン、ならびに場合によってはリクエスト処理に関与するルートの健全状態を維持する役割を担うことができる。この目的のため、ヘルスモニタは、ネットワーク及び／又はネットワーク構成要素の健全性を判断するのに有用であり得る、１つ又は複数のネットワークパラメーターを監視することができる。スケーラブル負荷分散マネージャ６０２は、ＭＵＸ及びＤＩＰに関する健全性情報の信頼できるソースとしてヘルスモニタ６０８を使用することができる。ヘルスモニタ６０８が、健全性が変化したイベントをスケーラブル負荷分散マネージャ６０２に通知した場合、スケーラブル負荷分散マネージャは、対応するプールにノードを追加したり、又はそこからノードを除去したりする適切な処置を講ずることができる。

１つの観点から見ると、ヘルスモニタ６０８は、ＭＵＸ、ＤＬＢ、及び／又はそれらのマシンへのルートの健全性を監視するのに用いられてもよい。

少なくともある実施形態では、ヘルスモニタ６０８は、ＶＰＮダイヤラー、ＭＵＸモニタ、及びＤＬＢモニタという３つのモジュールから成ることができる。ＤＬＢはＨＴＴＰインターフェースを提供してもよい。ヘルスモニタ６０８は、ターゲット構成要素の健全性を確立するため、様々な種類のヘルスプローブ６１０を用いてもよい。例えば、ヘルスモニタは、「ｈｔｔｐｇｅｔ」を送って、ＤＬＢから小さいテキスト／ｘｍｌファイルを取り出してもよい。ファイルが「マジックワード」を含んでいて、ヘルスモニタ及びＤＬＢがそれに同意した場合、ヘルスモニタは、ＤＬＢが立ち上がって稼働していると見なし、ＤＬＢ又はＭＵＸが予想どおりに稼働しているかを判断してもよい。さらに、少なくともある実施形態では、ヘルスモニタ構成要素はＭＵＸデバイス以外の別個のデバイス上にあってもよい。

ヘルスプローブ６１０はヘルスモニタ６０８によって使用することができる。例えば、ヘルスモニタは、そのジョブを達成するのに様々なヘルスプローブを使用することができる。ヘルスプローブ６１０は、ターゲットマシンの健全性の面を能動的に監視することができ、例えば、ピングプローブはマシンの接続性及び活動性を監視する。他のヘルスプローブは、単にマシン／ロールにその健全性を問い合わせてもよく、マシン／ロールが自身の健全性の記録を維持する役割を担って、プローブは単にそれを周期的に問い合わせることができる。

ＨＴＴＰプローブが成功している場合、これはすべてが立ち上がって稼働していることを示し得る。しかし、これはＴＣＰを通じて稼働するので、ＤＬＢがソケット又は他の資源を一時的に使い果たしている可能性がある。また、サービスの妨害（ＤｏＳ）攻撃中、ＤＬＢが長期間の間、資源（例えば、ソケット）を使い果たしている可能性がある。これに対する１つの解決策は、継続的なＨＴＴＰ接続を維持することであり得る。しかし、ほとんどのサーバー／ブラウザの実施形態では継続的なＴＣＰ接続が時間切れになってしまう。例えば、一部のブラウザでは６０秒後に継続的な接続が時間切れになることがある。したがって、ヘルスモニタは、継続的な接続が切れた場合にそれを再開するように整備され、継続的な接続の切断がＤＩＰ障害を示すものとして必ずしも見なさないようにすべきである。

障害を起こしたＭＵＸに別のＭＵＸが取って代わることができる場合、すべてのＭＵＸは同じコンシステントハッシング機能を作動させているので、パケットが同じＤＬＢに転送される。したがって、フロー（例えば、ＴＣＰ接続）は妨害されないはずである。

ＭＵＸの個別のプールは、アクティブなＭＵＸのホットスタンバイとして利用可能にされてもよい。ヘルスモニタ６０８は、ＭＵＸの障害を検出すると、１つ又は複数のＭＵＸを始動させて、障害を起こしたＭＵＸのＩＩＰを引き継いでもよい。同時に、ヘルスモニタは障害を起こしたＭＵＸのスイッチを切ってもよい。ＭＵＸの計画ダウンタイムに対処するため、ホットスタンバイに使用されるのと同様の技術を使用することができる。ＭＵＸはステートレスモードで動作するので、ある実施形態は、すべてのパケットが送り出された後で安全にＭＵＸのスイッチを切ることができる。

少なくとも１つの実施形態では、ＤＬＢの計画ダウンタイムは、ステートフルＭＵＸマップ遷移によって対処することができる。

１．ＭＵＸは、ＤＬＢ（Ｄ）を使用するＶｉｐＭａｐ（Ｖ）を使用している。
２．ＭＵＸは、ＤＬＢ（Ｄ）がＴ時間に停止するという通知を受ける。
３．ＭＵＸは、ＤＬＢ（Ｄ）を使用しない新しいＶｉｐＭａｐ（Ｖ’）を計算する。
４．ＭＵＸは、ドライバを設置する（Ｖ→Ｖ’遷移モード）。
５．遷移中、状態テーブルが維持され、すべてのＴＣＰＳＹＮがテーブルに新しいエントリをもたらす。
ａ．パケットが状態テーブルのエントリと一致する場合、それは新しいフローであり、したがってＶ’を使用する。
ｂ．それ以外の場合、古いＶが使用される。
注：この遷移期間中、すべての新しいフローは新しいＶｉｐＭａｐ（Ｖ’）に切り替わり、ＤＬＢ（Ｄ）が回避される。
６．ＤＬＢ（Ｄ）は、アクティブなＴＣＰ接続（ＶＩＰに対する）の数を数え続ける。カウンターがゼロに達すると、遷移が完了したことをＭＵＸに通知する。
７．あるいは、ＭＵＸは、状態テーブルのいずれのエントリにも一致しない接続として、長期にわたる接続を識別することができる。
８．時間Ｔに達すると、遷移Ｖ→Ｖ’が強制される。ＭＵＸはＶ’に基づいてすべてのトラフィックを転送する。

一実施形態では、ＭＵＸの計画ダウンタイムには次のステップによって対処する。
１．ＶｉｐＭａｐを新しいＭＵＸ（Ｍ’）に設定する。
２．古いＭＵＸ（Ｍ）がすべてのＶＩＰトラフィックをＭ’に転送するように設定し、Ｍ’は通常通りトラフィックをＤＬＢに転送する。
３．ＩＩＰを古いＭＵＸ（Ｍ）から除去する。
４．ＩＩＰに新しいＭＵＸ（Ｍ’）を追加する。次いで、
５．ルーターが新しいＭＵＸへの転送を始める。

少なくとも１つの実施形態では、ヘルスモニタ６０８は、不測の障害を監視するため、周期的なプローブをＭＵＸ及びＤＬＢに送ることができる。ＤＬＢ障害が観察されると、ヘルスモニタはＭＵＸに対して、そのＶｉｐＭａｐを更新して障害を起こしたＤＬＢの使用を回避するように指示することができる。ＭＵＸ障害が観察されると、ヘルスモニタは、同じＶＬＡＮ内の別のＭＵＸに対して、ＩＩＰをインストールする（かつＧ−ＡＲＰを使用してルーターに知らせる）ように指示することができる。少なくとも１つの実施形態では、ヘルスモニタは２秒ごとにＫｅｅｐＡｌｉｖｅプローブを送り、障害が３回連続した後にＭＵＸ／ＤＬＢの停止を知らせることができる。

ミッションクリティカルなＶＩＰに対する高速のＭＵＸフェイルオーバー（＜＜１秒）を達成するため、各ＩＩＰに対して仮想のＭＵＸ群を利用してもよい。この高速フェイルオーバーのコストは、通常動作中のネットワーク使用を上回ることがある。以下のステップを使用して、ＶＩＰに対するＭＵＸ及びＩＩＰを管理することができる。

Ａ．各ＩＩＰはマルチキャストアドレスであることができる。各ＶＩＰには一群のＭＵＸが割り当てられる。
Ｂ．その群のマスターＭＵＸが実際にＩＩＰを保持する。
Ｃ．マスターＭＵＸは、このＶＩＰに対するアクティブなＭＵＸであることをその群の全てのメンバーに同報する。このアナウンスは高速（＜＜１秒）で送られる。このアナウンスはまた、他のＭＵＸが新しいマスター選択プロセスを開始するのを防ぐ。
Ｄ．ＩＩＰはマルチキャストアドレスであり得るので、上流のルーターは受信したすべてのパケットをＶＩＰ群のＭＵＸメンバー（マスター及びすべてのバックアップ）に複写する。
Ｅ．指定されたバックアップＭＵＸは、指定された時間Ｔの間パケットを格納する。
Ｆ．マスターＭＵＸは、パケットに対して負荷分散機能を行い、それらをＤＬＢに転送する。
Ｇ．所与の時間Ｔの間にマスターＭＵＸが生きているというアナウンスが受信されなかった場合。指定されたバックアップＭＵＸが負荷分散を開始し、そのバッファ内のすべてのパケットを転送する。
Ｈ．この群の中のバックアップが新しいマスター選択プロセスを開始する。ある構成では、指定されたバックアップＭＵＸが新しいマスターになることができる。
Ｉ．ステップＧにより、ＤＬＢがいくつかのパケットを二度受信することがあるが、ＴＣＰは複写されたパケット及び一時的なパケット損失を十分に許容する。上流のルーターが生きていて、良好に動作している限り、パケット損失は起こらないことがあることに留意されたい。

図７は、１つ又は複数の実施形態によるＭＵＸ２１２（１）（図２にて言及）の一実施例の構成を示す。集合的にみると、図７及び８は、パスに沿ってパケットをどのようにカプセル化し、カプセル化を解除できるかを示す。

図７は、ユーザーモード７０２及びカーネルモード７０４を含むが、カーネルモードにおけるＭＵＸのＭＵＸドライバ６１８によって提供される機能に焦点を当てている。この場合、ＭＵＸドライバは、ネットワークスタックのＩＰレイヤーの拡張として実現される。

この実施例では、パケット７０６は、アプリケーションサーバーなどから、ＭＵＸドライバ６１８によって受信される。パケットは、７０８にあるソースクライアントアドレスと、７１０にある宛先ＶＩＰアドレスとを含む。パケットは、物理的なＮＩＣ（Network Interface Card）レイヤー７１２及びＮＤＩＳ（Network Driver Interface Specification）レイヤー７１４を通って移動する。パケットは、ＩＰレイヤー７１８にあるＭＵＸドライバのフォワーダー７１６によって扱われる。フォワーダーは、パケット７０６をカプセル化してパケット７２０を生成する。このパケットは、ソースＭＵＸアドレス７２２及び宛先ＤＩＰアドレス７２４によってカプセル化された、７０８にあるソースクライアントアドレスと７１０にある宛先ＶＩＰアドレスとを含む。したがって、元のパケット７０６は、クライアント７０８からではなくＭＵＸ２１２（１）から来たような印象を与える形で、パケット７２０にカプセル化される。

ＭＵＸ２１２（１）は、ＶＩＰ：ＤＩＰマッピングとして知られるレイヤー４負荷分散を実現することができる。クライアントからのトラフィックは、層１によってＭＵＸノードの１つに送ることができる（一般的に、ＥＣＭＰ（Equal Cost Multi Path）ルーティングによる）。ＭＵＸ２１２（１）がパケット７０６を受信すると、パケットヘッダー部（どのヘッダー部がハッシュされるかに関して柔軟性がある）をハッシュすることができ、このハッシュに基づいてＤＩＰを選択することができる（このプロセスの一実施例は図９に関連して後述される）。次に、ＭＵＸは、元のパケット７０６を、選ばれたＤＩＰを宛先（すなわち、宛先ＤＩＰアドレス７２４）として、またＭＵＸをソースＩＰアドレスとして示す、新しいＩＰヘッダーにカプセル化することができる（あるいは、ＭＵＸは元の送信者をソースＩＰとして使用することができる）。

負荷分散クラスター中のＭＵＸノードは同じハッシュ関数を使用することができる。さらに、ＭＵＸノードはＤＩＰの追加及び適切な削除の間、状態を維持することができる。これにより、どのＭＵＸがパケットを受信するかに関わらず、所与のフローにおけるパケットを次の層の同じサーバーに転送することが可能になる。

図８は、図６に関連して上述したＤＩＰロール６０６の一実施例を示す。簡潔には、この場合、ＤＩＰカプセル化解除ドライバ６２６は、図７で言及したカプセル化されたパケット７２０に対してカプセル化解除を行うことができる。この構成では、ＤＩＰカプセル化解除ドライバは、ネットワーキングスタックのＩＰレイヤーの拡張として実現される。上述したように、図７は、配信パスのフロントエンドにおいてカプセル化を達成するための一実施例を提供し、図８は、バックエンドにおいて、上述した元のパケット７０６のカプセル化を解除する一実施例を提供する。

この実施例では、カプセル化解除ドライバ６２６はカプセル化されたパケット７２０を受信することができる。カプセル化解除ドライバは、カプセル化（すなわち、ソースＭＵＸアドレス７２２及び宛先ＤＩＰアドレス７２４）を除去することができ、カプセル化されたパケットがパスを移動するとパケット７０６が生成され、宛先ＶＩＰアドレス７１０へ配信できるようになる。

上述のＭＵＸ２１２（１）及びＤＩＰロール６０６は、本発明の概念を用いて、ロケーションアドレス（すなわち、宛先ＤＩＰ７２４）を有するアプリケーションアドレス（すなわち、宛先ＶＩＰアドレス７１０）と関連付けられたパケット７０６など、パケットのカプセル化を容易にすることができるので、パケット７０６をレイヤー３インフラストラクチャにわたって搬送し、最終的にレイヤー２宛先ＶＩＰアドレス７１０に配信することができる。さらに、カプセル化されたパケットは、カプセル化によって定義された、選択されたパスを移動することができ、選択されたパスは、混雑を回避するために後続のパケットに対して簡単に再選択することができる。

さらに、この構成は、ネットワークノードプール（すなわち、スケーラブル負荷分散システム１０４、２０４、及び／又は３０４の構成要素）の中断がない（又は中断が低減された）増加及び縮小を容易にすることができる。簡潔には、スケーラブル負荷分散システム状態は静的ではない傾向がある。例えば、より多くのアプリケーションサーバーがオンラインになることができたり、かつ／又はアプリケーションサーバーがオフラインになることができたり、スイッチをオンオフすることができたり、通信が開始及び終了されたりなどである。本発明の概念により、既存のスケーラブル負荷分散システムマッピングから新しいスケーラブル負荷分散システムマッピングへの適切な遷移を可能にすることができる。例えば、本発明の概念は、既存のマッピングの既存の又は進行中の通信を追跡することができる。ある実施形態は、既存のマッピングを利用するような進行中の通信の連続性を維持しながら、新しい通信のためにスケーラブル負荷分散システムの変化を反映する新しいマッピングを利用しようとすることができる。その結果、これらの実施形態は、比較的シームレスな形で古いマッピングから新しいマッピングへと「適切に」遷移することができる。

図９は、ハッシュ空間をＤＩＰプールにマッピングする実施例の方法９００を示す。例えば、マッピングにより、影響を受けるＤＩＰに進まないトラフィックに対する中断なしに、ＤＩＰをＶＩＰプールから除去できるようになる。例えば、ハッシュ空間（すなわち、潜在的なハッシュ値）と利用可能なＤＩＰのプールとの間の第１のマッピングが９０２で示される。ハッシュ空間と利用可能なＤＩＰの別のプールとの間の第２のマッピングが９０４で示される。この場合、第２のマッピング９０４は、９０６で示されるように、ＤＩＰ１が終わる（すなわち、利用不能になる）結果として生じる。まず第１のマッピング９０２を見ると、ハッシュ値が、９０８（１）、９０８（２）、及び９０８（３）ではＤＩＰ１に、９１０（１）、９１０（２）、及び９１０（３）ではＤＩＰ２に、９１２（１）、９１２（２）、及び９１２（３）ではＤＩＰ３に、また９１４（１）、９１４（２）、及び９１４（３）ではＤＩＰ４にマッピングされる。したがって、ハッシュ値はボトルネックを低減又は回避することができる形で、利用可能なＤＩＰ間で分配される。

９０６でＤＩＰ１が失われると、この実施形態は、すべての個々の利用可能なＤＩＰに対する突然の過負荷を回避するような形で、残りの利用可能なＤＩＰの間でＤＩＰ１の負荷を再分配する。例えば、第２のマッピング９０４では、第１のマッピング９０２では９０８（１）でＤＩＰ１にマッピングされていたハッシュの第１の部分は、９１６で示されるＤＩＰ２に再割り当てされる。ＤＩＰ１の第２の部分９０８（２）は９１８で示されるＤＩＰ３に再割り当てされる。ＤＩＰ１の第３の部分９０８（３）は９２０で示されるＤＩＰ４に再割り当てされる。したがって、この実施形態は、残りのＤＩＰのいずれに対する過負荷も回避することができ、それによって過負荷を受けたＤＩＰと関連付けられるボトルネックが潜在的に作られるのを回避するような公正な形で、第１のマッピング９０２に見られるような四方向の分配から、第２のマッピング９０４に見られるような三方向の分配へとパケットフローをシームレスに再分配する。

より詳細な説明のため、１つ又は複数のアプリケーションサーバー（ＤＬＢ）に対するＶＩＰのマッピングを決定する、ＶＩＰ−ＤＩＰマップＭを有するＭＵＸ（ＭＵＸ２１２（１）など）について考察する。ＭがＭ’に変更されるシナリオについて考察する。上述の技術を利用して、Ｍを適切にＭ’に変更することができる。長期の接続が存在することがあるので、任意に、期限Ｔを定義することができる。その結果、Ｔに達するとＭＵＸがＭをＭ’に変更することができ、又は適切な変更が完了する。

以下に記載するのは、ＭをＭ’に適切に変更する手法の単なる一実施例である。

パケットＰに対して、ＭＵＸは、マップＭを使用して計算することができるＨ（Ｐ）と、マップＭ’を使用して計算することができるＨ’（Ｐ）の両方を計算することができる。
Ｈ（Ｐ）＝Ｈ’（Ｐ）の場合、Ｈ（Ｐ）に転送されるものはＨ’（Ｐ）に転送されるものに等しい。

Ｈ（Ｐ）！＝Ｈ’（Ｐ）であり、ＰがＳＹＮ（ＴＣＰ接続を開始してもよいＴＣＰＳＹＮパケット）である場合、Ｐを使用して、Ｈ’（Ｐ）に進むべき新しい接続を設定することができ、又はハッシュ（Ｐ）→Ｈ’（Ｐ）を状態テーブルＳに挿入して、このフローがＭ’へと移動したものとして認識できるようにすることができる。

Ｈ（Ｐ）！＝Ｈ’（Ｐ）であり、ＰがＳＹＮではなく、ハッシュ（Ｐ）がＳにない場合、これはＨ（Ｐ）への進行中の接続の一部であり得るので、Ｈ（Ｐ）に進む。

Ｈ（Ｐ）！＝Ｈ’（Ｐ）であり、ＰがＳＹＮではなく、ハッシュ（Ｐ）がＳにある場合、これは既にＭ’へと移動した進行中の接続の一部であり得るので、Ｈ’（Ｐ）に進む。

Ｔに達するか、又は遷移が終わったとすべてのＤＬＢが通知すると、マッピングをＭからＭ’に変更することができ、状態テーブルＳをフラッシュすることができる。

これに付随して、ＤＬＢには同じＭ→Ｍ’の遷移を通知することができ、この遷移によってそれ（すなわち、ＤＬＢ）が影響を受けたかを計算することができる。

ＤＬＢが遷移していると判断すると、有している接続を適切に終わらせることができる。

継続的なＨＴＴＰ接続の場合、ＤＬＢＨＴＴＰサーバーは「ＨＴＴＰＫｅｅｐａｌｉｖｅ」を不能にすることができる。そのため、ＤＬＢＨＴＴＰサーバーは、ＦＩＮとの基本的なＴＣＰ接続（ＴＣＰ接続を完成させるＴＣＰＦＩＮパケット）を終了することができる。ＦＩＮは、このパケットの送信者が接続を終了しようとしていることを示すＴＣＰヘッダー中のフラグと見なすことができる。外部クライアントは接続を再開してもよい。しかし、これは新しいハンドシェイクを開始する傾向があるので、ＭＵＸは新しいＤＬＢに対する新しいＴＣＰ接続をルーティングすることができる。

あるいは、継続的なＨＴＴＰ接続は、後述するような確立しているＴＣＰ接続と同じように扱うことができる。

確立しているＴＣＰ接続は、遷移期間の間、不活発又は使用中であることがあり、ＨＴＴＰがそれを切断することが予期されることがある。ある潜在的な動作は次のとおりである。
１．クライアント側でＴＣＰ接続をタイムアウトさせる。基本的に、この技術はこれらのＴＣＰ接続を単に無視する。
２．時間Ｔに達するとクライアントが通知を受けるように、ＴＣＰＲＳＴをクライアントに強制的に送る。ＲＳＴの送信は正しいシーケンス番号を有することを必要としない。そのため、この技術は、「確立している」接続を単に列挙し、確立している接続をすべて打ち切ることができる。
３．ＭＵＸは、遷移の影響を受けた接続が終了したとＤＬＢが判断するまで、継続的な接続の状態を維持することができる。

オープンＴＣＰソケットの数が０のとき、ＭＵＸは、ノードをプールから安全に除去できるという通知を受けることができる。

要約すると、本発明の実施形態は、ＩＰ−ｉｎ−ＩＰカプセル化を使用することができるので、サブネットだけではなく潜在的なすべてのターゲットデバイスにわたってＤＳＲを使用することができる。さらに、負荷分散装置を所望に応じてスケーラブル論理層として実現することができる。これらの概念はまた、システム遷移の間、接続を保存することができる。例えば、ＤＩＰを追加又は除去することができ、負荷を再分散することができ、かつ／又は適切に接続を遷移させながらシステム容量を調整することができる。ＭＵＸレイヤーにおいてコンシステントハッシングを達成して、スケーラビリティを可能にするとともに、状態を保つことなく障害を起こしたＤＩＰを除去するのを可能にすることができる。さらに、システムのモニタリング、制御、及び／又は管理機能を、負荷分散機能とともに配置することができる。これにより、他の潜在的利点の中でも特に、マスターがＭＵＸ間のアドレスの連続性を確保できるようになる。

（第１の方法の実施例）
図１０は、１つ又は複数の実施形態による、ＶＩＰに対するＤＩＰプールの拡張に関して長期の接続を保存することと関連付けられた、一実施例のステップ又は動作について説明する方法１０００のフローチャートを示す。

方法は、任意の適切なハードウェア、ソフトウェア（例えば、ファームウェアを含む）、又はそれらの任意の組み合わせと関連して実現することができる。場合によっては、方法は、方法を行うプロセッサ又は計算装置によって実行することができるコンピューター可読記憶媒体に格納することができる。さらに、方法のステップの１つ又は複数は、任意の回数繰り返すことができる。それに加えて又はその代わりに、少なくともある実施形態ではステップの１つ又は複数が省略されてもよい。

ステップ１００２で、ネットワーク又はスケーラブル負荷分散システムに対して新しい接続が識別される。少なくともある実施形態では、これはＴＣＰＳＹＮを探すことによって遂行することができる。

ステップ１００４で、新しい接続に対する状態を保つ。

ステップ１００６で、既存の又は古い接続に対して既存の又は古いハッシュを使用し、新しい接続に対しては新しいハッシュを使用することができる。

ステップ１００８で、ＤＩＰを問い合わせる。少なくともある実施形態では、これは、保存すべき長期にわたる接続に対するＤＩＰを問い合わせることを含むことができる。あるいは、負荷分散システムは、パケットヘッダーを解釈することによってアクティブな接続を判断することができる。

ステップ１０１０で、新しい接続に対する状態を終了する。

ステップ１０１２で、保存されていた接続に対する状態を終了する。少なくともある実施形態では、これは、保存されていた接続がＤＩＰで終了するとそれらの状態を無効にすることを含むことができる。

方法１０００は説明のために提供されるものであり、限定的な意味で解釈すべきでない。例えば、遷移中に用いることができる代替の方法は、次のアルゴリズムを利用することができる。
１．パケットヘッダーを解釈することによって、新しい接続の開始パケットを識別する（例えば、ＴＣＰＳＹＮを探す）。
２．新しい接続の開始パケットである場合、それを新しいマップのみにしたがって送る。
３．他の場合は、古いマップ及び新しいマップの両方にしたがってパケットを送る。
４．ＤＩＰを要求するか、又は特定の期間にわたって負荷分散装置における状態を追跡することによって、古い接続を識別する。
５．古いマップにしたがって古い接続を送り、新しいマップにしたがって新しい接続を送る。
６．タイムアウト後、又はＤＩＰで終了すると、古い接続に関する状態を無効にする。

（第２の方法の実施例）
図１１は、一実施例の方法１１００のステップ又は動作について説明するフローチャートを示す。方法は、任意の適切なハードウェア、ソフトウェア（例えば、ファームウェアを含む）、又はそれらの任意の組み合わせと関連して実現することができる。場合によっては、方法は、方法を行うプロセッサ又は計算装置によって実行することができるコンピューター可読記憶媒体に格納することができる。さらに、方法のステップの１つ又は複数は、任意の回数繰り返すことができる。それに加えて又はその代わりに、少なくともある実施形態ではステップの１つ又は複数が省略されてもよい。

ステップ１１０２で、ネットワークパケットを一連のモジュール間で拡散させることができる。少なくとも１つの実施形態では、モジュールは、サーバー上及び／又はルーター内で実装されるように構成されたＭＵＸモジュールである。拡散は、パケットの個々の特性に対して無意識的であり得るが、宛先へのパケットが、その宛先向けのパケットを扱うのに必要な状態を含むＭＵＸモジュールに配信されてもよい。少なくともある実施形態では、個々のネットワークパケットはＥＣＭＰルーターを使用してモジュール間で拡散される。

ステップ１１０４で、ネットワークパケットを個々のモジュールにおいてカプセル化することができる。少なくともある実施形態では、パケットのカプセル化は、ＩＰ−ｉｎ−ＩＰカプセル化を含み、かつ／又はパケットが送られた１つ若しくは複数のＶＩＰアドレスを保存する。この点に関して、本明細書に記載される技術の潜在的に重要な特徴は、パケットの特性（例えば、５タプル、ＩＰソースアドレス、ＩＰ宛先アドレス、ＩＰプロトコル番号、ＴＣＰソースポート、及び／又はＴＣＰ宛先ポート）に基づくネットワークパケットのカプセル化と関連付けられるので、同じリクエストの一部であるパケットは、ある実施形態では、どのＭＵＸモジュールがパケットをカプセル化するかに関わらず、同じターゲットデバイスによってすべて扱われ得ることに留意されたい。

ステップ１１０６で、モジュール間で共有される状態を使用して、ネットワークパケットをカプセル化するターゲットデバイスを選択することができる。少なくともある実施形態では、モジュール間で共有される状態はコンシステントハッシュ関数のキー空間である。それに加えて又はその代わりに、少なくともある実施形態では、モジュール間で共有される状態は、ターゲットデバイスの障害に応答して変更することができる。

ステップ１１０８で、ネットワークパケットをモジュールから転送することができる。

ステップ１１１０で、ターゲットデバイス、ＭＵＸモジュール、ルーター、及び様々な構成要素間のルートの健全性を監視することができる。

（結論）
負荷分散シナリオに関係する技術、方法、デバイス、システムなどを、構造的特徴及び／又は方法論的作用に特有の用語を用いて記載しているが、添付の特許請求の範囲にて定義される主題は記載した特定の特徴又は動作に必ずしも限定されないことを理解されたい。むしろ、特定の特徴及び動作は、特許請求の範囲の方法、デバイス、システムなどを実現する例示的な形態として開示される。

Claims

処理デバイスによって実行されると動作を行う命令が格納されたコンピューター可読記憶媒体であって、前記動作が、
一連のモジュール間でネットワークパケットを拡散するステップ（１１０２）と、
個々のモジュールにおいて前記ネットワークパケットをカプセル化するステップ（１１０４）と、
前記一連のモジュール間で共有される状態を使用して、前記ネットワークパケットをカプセル化するターゲットデバイスを選択するステップ（１１０６）と、
前記ネットワークパケットを前記一連のモジュールから転送するステップ（１１０８）とを含むことを特徴とするコンピューター可読記憶媒体。
前記一連のモジュール間で共有される前記状態は、コンシステントハッシュ関数のキー空間であることを特徴とする請求項１に記載のコンピューター可読記憶媒体。
個々のネットワークパケットを、等しいコストマルチパスルーティングを使用して、前記一連のモジュール間で拡散することを特徴とする請求項１に記載のコンピューター可読記憶媒体。
前記ターゲットデバイスの健全性を監視するステップをさらに含むことを特徴とする請求項１に記載のコンピューター可読記憶媒体。
前記一連のモジュール間で共有される前記状態を、前記ターゲットデバイスの障害に応答して変更することを特徴とする請求項１に記載のコンピューター可読記憶媒体。
前記一連のモジュールの数を、負荷パラメーターの１つ若しくは複数又は他のパラメーターの１つ若しくは複数に基づいて、提供されるサービスのダウンタイムを引き起こすことなく、動的に変更できることを特徴とする請求項１に記載のコンピューター可読記憶媒体。
前記ターゲットデバイスはターゲットデバイスの一連のメンバーであり、前記一連のうちの１つ若しくは複数の既存のターゲットデバイスが利用不能になるという通知、又は１つ若しくは複数の新しいターゲットデバイスが利用可能であるという通知を受信する場合、新しい一連のターゲットデバイスに対する今後の通信と関連付けられたネットワークパケットを拡散する構成に遷移すると同時に、前記一連のターゲットデバイスに対する進行中の通信と関連付けられたネットワークパケットを送り続けることを特徴とする請求項１に記載のコンピューター可読記憶媒体。
前記パケットのカプセル化は、ＩＰ（Internet Protocol）−ｉｎ−ＩＰカプセル化を含むことを特徴とする請求項１に記載のコンピューター可読記憶媒体。
前記パケットのカプセル化は、前記パケットが送られる１つ又は複数の仮想ＩＰアドレスを保存することを特徴とする請求項６に記載のコンピューター可読記憶媒体。
外部クライアントデバイス（１０２）からのパケットフローの個々の着信パケットをカプセル化するように構成された負荷分散レイヤー（１０８）と、個々のターゲットデバイス（２１０）とを備えるシステム（１０４）であって、
前記負荷分散レイヤー（１０８）は、前記着信パケットを前記システム（１０４）のターゲットデバイス（１１０）にルーティングするようにさらに構成され、前記ターゲットデバイス（１１０）は、１つ又は複数のＩＰ（Internet Protocol）サブネットにまたがり、前記着信パケットは、前記個々のターゲットデバイス（２１０）に達する前に前記負荷分散レイヤー（１０８）の１つ又は複数の負荷分散装置（２０８）を通過し、
前記個々のターゲットデバイス（２１０）は、前記１つ又は複数の負荷分散装置（２０８）のいずれも通過することなく、前記パケットフローの少なくともいくつかの発信パケットを前記外部クライアントデバイス（１０２）にルーティング（２２２）するように構成されたことを特徴とするシステム。
前記負荷分散レイヤーを、ＩＰ（Internet Protocol）−ｉｎ−ＩＰカプセル化又はパケット修正及びＩＰオプションの一方又は両方を利用して、前記個々の着信パケットをカプセル化するように構成することを特徴とする請求項１０に記載のシステム。
前記負荷分散レイヤーは、少なくとも１つの動的負荷分散装置及び少なくとも１つのマルチプレクサを備え、前記少なくとも１つのマルチプレクサを、前記個々の着信パケットをカプセル化するように構成することを特徴とする請求項１０に記載のシステム。
前記負荷分散レイヤーは、少なくとも１つのマルチプレクサを備え、前記少なくとも１つのマルチプレクサを、ＩＰ−ｉｎ−ＩＰカプセル化を利用して前記個々の着信パケットをカプセル化するように構成することを特徴とする請求項１０に記載のシステム。
前記個々のターゲットデバイスは、前記負荷分散レイヤーからのパケットのカプセル化を解除するように構成されたカプセル化解除構成要素を含み、個々のターゲットデバイスは複数の仮想ローカルエリアネットワークにまたがることを特徴とする請求項１０に記載のシステム。
前記１つ又は複数の負荷分散装置は、ＶＩＰ（Virtual IP）を前記負荷分散レイヤーのＤＩＰ（Direct IP）マッピングに統合する、アプリケーションプログラムインターフェースを提供するように構成された動的負荷分散装置を備えることを特徴とする請求項１０に記載のシステム。