従来のロード・バランサは複数のネットワーク・インターフェイス・コントローラ(NIC)(例えば8つのNIC)を含む単一の専用のボックスであり、これらNICのいくつかはクライアントからのインバウンド・トラフィック/クライアントへのアウトバウンド・トラフィックを扱い、その他のNICはホスト装置(例えば、ウェブ・サーバなどのサーバ)からのアウトバウンド・トラフィック/ホスト装置へのインバウンド・トラフィックを扱っており、それらはロード・バランシングされている。これら従来のロード・バランサの帯域幅または処理能力は、一般的に、クライアント側で40ギガビット毎秒(Gbps)、サーバ側で40Gbpsの範囲にある。ネットワーク・ベースのアプリケーションおよびクラウド・コンピューティング・サービスなどのネットワーク・ベースのサービスの規模と範囲が増大するにつれて、データ・センタはロード・バランシングを必要とする何百または何千ものホスト装置(例えば、ウェブ・サーバ)を収容する場合がある。従来のロード・バランサでは、かかる環境でうまくスケールアップできない。
さらに、従来のロード・バランサは、一般的に、ホスト装置から集められたデータに適用される最大接続、ラウンド・ロビン、及び/または、最小接続などの技法を用いてどのホスト装置が接続を扱うのかを選択する。加えて、従来のロード・バランサは、一般的に、それが面するホスト装置がプロキシの役割をし、したがって、クライアントからの接続(たとえば、通信制御プロトコル(TCP)接続)を終了させ、ホスト装置とロード・バランサとの間に確立されたTCP接続上でクライアント・トラフィックをホスト装置に送る。したがって、ホスト装置とクライアントは、これら従来のロード・バランサを使用するときには直接のTCP接続上で通信しない。
図1は、少なくともいくつかの実施形態による、分散型ロード・バランサ・システムの一例のブロック図である。
図2は、少なくともいくつかの実施形態による、図1の分散型ロード・バランサ・システムによって実装することができるロード・バランシング法の高レベルのフローチャートである。
図3は、少なくともいくつかの実施形態による、入口コンポーネント、出口コンポーネント、及びフロー・トラッカ・コンポーネントを含むロード・バランサ・ノードの一例を示す。
図4は、少なくともいくつかの実施形態による、分散型ロード・バランサの経路指定及びパケット・フローを示している。
図5は、少なくともいくつかの実施形態による、エッジ・ルータへの入口ノードの広告を示している。
図6は、少なくともいくつかの実施形態による、多重パス経路指定法のフローチャートである。
図7は、少なくともいくつかの実施形態による、非対称パケット・フローを図示している。
図8は、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示している。
図9Aは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムで接続を確立するときのパケット・フローのフローチャートを提供する。
図9Bは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムで接続を確立するときのパケット・フローのフローチャートを提供する。
図10Aは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。
図10Bは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。
図10Cは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。
図10Dは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。
図10Eは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。
図10Fは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。
図10Gは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。
図11Aは、少なくともいくつかの実施形態による、ロード・バランサ・ノード・コンシステント・ハッシュ・リングのメンバー数に影響を及ぼす事象の取り扱いを示す。
図11Bは、少なくともいくつかの実施形態による、ロード・バランサ・ノード・コンシステント・ハッシュ・リングのメンバー数に影響を及ぼす事象の取り扱いを示す。
図11Cは、少なくともいくつかの実施形態による、ロード・バランサ・ノード・コンシステント・ハッシュ・リングのメンバー数に影響を及ぼす事象の取り扱いを示す。
図11Dは、少なくともいくつかの実施形態による、ロード・バランサ・ノード・コンシステント・ハッシュ・リングのメンバー数に影響を及ぼす事象の取り扱いを示す。
図12は、少なくともいくつかの実施形態による、健全性チェック間隔にしたがって各ロード・バランサ・ノードが行うことができる健全性チェック法の高レベルなフローチャートである。
図13は、少なくともいくつかの実施形態による、別のロード・バランサ・ノードからあるロード・バランサ・ノードの健全性のチェックをする方法を示す。
図14は、少なくともいくつかの実施形態による、1つまたは複数の他のロード・バランサ・ノードの健全性をチェックする1つのロード・バランサ・ノードを図示する。
図15は、少なくともいくつかの実施形態による、サーバ・ノードの健全性をチェックするロード・バランサ・ノードを示す。
図16は、少なくともいくつかの実施形態による、ロード・バランサ・ノード110により維持することができる別のノードの健全性の図を図示する。
図17は、少なくともいくつかの実施形態による、各ロード・バランサ・ノードにより維持することができる健全性情報を示す。
図18Aは、少なくともいくつかの実施形態による、ロード・バランサ・ノードの故障の取り扱いを示す。
図18Bは、少なくともいくつかの実施形態による、ロード・バランサ・ノードの故障の取り扱いを示す。
図19A、図19Bは、少なくともいくつかの実施形態による、接続公表技法を図示する。
図20は、少なくともいくつかの実施形態による、各ロード・バランサ・モジュールにより実施することができる接続公表法の高レベルなフローチャートである。
図21は、少なくともいくつかの実施形態による、接続公表パケット内で受信されたアクティブな接続情報を標的ロード・バランサ・ノードに分散させる方法のフローチャートである。
図22は、少なくともいくつかの実施形態による、接続公表パケット内で受信されたアクティブな接続情報を標的ロード・バランサ・ノードに分散させる代替方法のフローチャートである。
図23は、少なくともいくつかの実施形態によるロード・バランサ・ノードのソフトウェア・スタック・アーキテクチャの例を示す。
図24は、実施形態に用いることができるコア・パケット処理技術の態様を示す。
図25は、少なくともいくつかの実施形態による、ロード・バランサ・ノード上のデータ・フローを処理する多重コア・パケット・プロセッサの例を示す。
図26は、少なくともいくつかの実施形態による、ロード・バランサ・ノード上のデータ・フローを処理する多重コア・パケット・プロセッサの別の例を示す。
図27は、少なくともいくつかの実施形態による、ロード・バランサ・ノード・プロセスによる着信パケットの処理を示す。
図28は、少なくともいくつかの実施形態による、ロード・バランサ・ノード・プロセスによる発信パケットの処理を示す。
図29は、少なくともいくつかの実施形態による、生産環境で分散型ロード・バランサを含むロード・バランシング・システムを示す。
図30は、少なくともいくつかの実施形態による、複数の分散型ロード・バランシング・システム・コンポーネントが単一のプロセスでまたは単一のプロセスとして構成され実行されることを可能にするメッセージ・バス・メカニズムを取り込んだ分散型ロード・バランサ・テスト・システムを示す。
図31は、少なくともいくつかの実施形態による、メッセージ・バス・パケット・アダプタ及びパケット・パイプラインを示す。
図32は、少なくともいくつかの実施形態による、メッセージ・バス・パケット・アダプタ及びパケット・パイプラインを示す。
図33Aは、少なくともいくつかの実施形態による、プロバイダ・ネットワーク環境の例を示す。
図33Bは、少なくともいくつかの実施形態による、図33Aに示すようなプロバイダ・ネットワーク環境の例における分散型ロード・バランサ実装を示す。
図34Aは、少なくともいくつかの実施形態による、分散型ロード・バランサ及びサーバ・ノードの物理的なラック実装の例を示す。
図34Bは、少なくともいくつかの実施形態による、分散型ロード・バランサ及びサーバ・ノードの物理的なラック実装の別の例を示す。
図35は、少なくともいくつかの実施形態による、1つ、2つまたはそれ以上の分散型ロード・バランサがネットワークに実装されたネットワーキング環境の例を示す。
図36は、いくつかの実施形態で用いることができるコンピュータ・システムの例を示すブロック・ダイアグラムである。
本明細書でいくつかの実施形態及び説明図面の例により実施形態を説明してきたが、当業者なら、実施形態が説明した実施形態または図面に限定されないことが分かるであろう。図面及びその詳細な説明は、実施形態を開示された特定の形態に限定することを意図せず、反対に、添付した請求項に規定された精神と範疇内に当てはまるすべての修正形態、等価形態、及び代替形態を網羅する意図であることを理解すべきである。本明細書に用いられた表題は構成上の目的のためだけに用いられたものであり、明細書または請求項の範囲を限定するために使用されたものではない。本出願全体にわたって使用されるとき、用語「may」は義務的な意味(すなわち、ねばならないの意味)ではなく許容的な意味(すなわち、〜する可能性を有する意味)で用いられる。同様に用語「include」、「including」、及び「includes」は、〜に限定はされないが含む、の意味である。
発明の詳細な説明
ネットワーク環境における分散化されたロード・バランシングの方法及びシステムの様々な実施形態が記載されている。様々なネットワーク環境における分散型ロード・バランサの実施形態により実施することができる分散化されたロード・バランシングの方法及びシステムの実施形態が記載される。分散型ロード・バランサの実施形態は、例えば、インターネット及び宛先などの外部ネットワーク、一般的には、図33A及び33Bに示されるプロバイダ・ネットワーク1900などのローカル・ネットワーク上のサーバ(例えば、ウェブ・サーバ、アプリケーション・サーバ、データ・サーバ等)上のクライアント間のパケット・フロー(例えば、TCP技術パケット・フロー)を促進および維持するために使用することができる。本明細書では、実施形態が、主としてTCPパケット・フローの処理に関連して記載されているが、実施形態はTCP以外の他のデータ通信プロトコル及びパケット・フローの処理以外の他のアプリケーションにも適用することができることに留意されたい。
分散型ロード・バランサは、特定のクライアントと選択されたサーバ(例えば、ウェブ・サーバ)との間のTCPパケット・フローを促進及び維持する作用をすることができる。しかし、分散型ロード・バランサは、クライアントからのTCPフローを終了させない、また、従来のロード・バランサにおいてなされるようにサーバに対するプロキシの働きをすることはない。その代わり、分散型ロード・バランサのロード・バランサ・ノードはクライアントから受け取ったTCPパケットを標的サーバに経路指定し、これらのサーバはそのTCPスタックを用いてクライアントへのTCP接続を管理する。言い換えれば、これらのサーバがクライアントからのTCPパケット・フローを終了させる。
加えて、従来のロード・バランサ技術でなされるようにサーバから集められた情報に適用されるロード・バランシング技法またはアルゴリズムに基づいてどのサーバが接続要請にサービスをするのかをロード・バランサ・ノードが決定する代わりに、ロード・バランサ・ノードは新たな接続要請を受けるサーバをランダムに選択することができ、サーバ・ノードに存在する分散型ロード・バランサのコンポーネントが、選択されたサーバが新たな接続要請を受けるか拒否するかにつきそれぞれのサーバの現状の1つまたは複数の指標に基づいて局所的に決定する。したがって、どのサーバが接続要請を受けるかについての決定は、ロード・バランサ・ノードから接続を扱うであろうサーバ・ノードに移行する。言い換えれば、この決定は、接続要請がサービスを受ける場所および時間のより近くに移行される。
クライアントとサーバとの間のパケット・フローを促進し維持するために、分散型ロード・バランサの実施形態は、限定はされないが、多重パス経路指定技術、コンシステント・ハッシング技術、分散化ハッシュ・テーブル(DHT)技術、境界ゲートウェイ・プロトコル(BGP)技術、メンバー数の追跡、健全性チェック、接続公表、並びに、パケットのカプセル化及びデカプセル化、を含む様々な技法または技術を採用することができる。分散型ロード・バランシング・システムのこれらの態様並びに他の態様を以下に図面を参照して説明する。
分散型ロード・バランシング・システム
図1は、少なくともいくつかの実施形態による分散型ロード・バランシング・システムの一例のブロック図である。分散型ロード・バランサの実施形態は、ネットワーク100、例えば図33A、33Bに示すサービス・プロバイダのプロバイダ・ネットワーク1900で実装することができる。分散型ロード・バランンサ・システムでのクライアント・パケットの取り扱いの高レベルな概要として、ネットワーク100の1つまたは複数のクライアント160は、例えばインターネットなどの外部ネットワーク150を介して、ネットワーク100の境界ルータ102に接続することができる。境界ルータ102はクライアント160からの着信パケット(例えば、TCPパケット)を、分散型ロード・バランサ・システムのロード・バランサ・ノード層内のロード・バランサ(LB)ノード110にこれらの着信パケットを経路指定する分散型ロード・バランサのエッジ・ルータ104のコンポーネントに経路指定することができる。少なくともいくつかの実施形態において、エッジ・ルータ104は、フロー単位ハッシュ化多重パス経路指定技術、例えば、等コスト多重パス(ECMP)ハッシュ技術によって経路指定の決定を行なうことができる。ロード・バランサ・ノード110はこれらのパケットを(例えば、ユーザー・データグラム・プロトコル(UDP)にしたがって)順次カプセル化しそれらのカプセル化パケットをネットワーク100のネットワーク・ファブリック120(例えば、L3ネットワーク)を介してサーバ・ノード130上のローカル・ロード・バランサ・モジュール132に経路指定する。ファブリック120は、限定はされないが、スイッチ、ルータ及びケーブルを含む1つまたは複数のネットワークキング装置またはコンポーネントを含むことができる。サーバ・ノード130では、ローカル・ロード・バランサ・モジュール132がこれらのパケットをデカプセル化しサーバ134のTCPスタックにこれらのクライアントTCPパケットを送信する。サーバ・ノード130のサーバ134は、その後、そのTCPスタックを用いてクライアント160への接続を管理する。
図2は、少なくともいくつかの実施形態による図1の分散型ロード・バランサ・システムによって実施することができるロード・バランシング法の高レベルのフローチャートである。分散型ロード・バランサ・システムの実施形態は、従来のロード・バランサで行われるように、多数の宛先(例えばウェブ・サーバ)の間に負荷を割り当てるという困難な問題を解決することができない。例えば、従来のロード・バランサは、一般的に、最大接続、ラウンド・ロビン及び/または最小接続の技法などの技法すなわちアルゴリズムを用いてどのサーバが接続を扱うかを選択する。しかし、これらの技法には欠点があり、特に、ロード・バランシングの決定に用いたデータがしばしばほとんどすぐに古くなる分散型システムにおいては成功裏に行なうのは困難である。分散型ロード・バランサ・システムの少なくともいくつかの実施形態では、従来のロード・バランサで行われるように1つまたは複数のロード・バランシング技術を使用することによってサーバ・ノード130を選択して接続要請を満たすように試みる代わりに、ロード・バランサ・ノード層のロード・バランサ・ノード110がランダムにサーバ・ノード130を決定してクライアントの接続要請を受けることができる。このサーバ・ノード130は、自身が過負荷であると考えたときは、ロード・バランサ・ノード110にこの接続要請を送り返すことができ、したがって、ロード・バランサ・ノード110にサーバ・ノード130が現在接続を扱えないことを知らせることができる。ロード・バランサ・ノード層は、その後、接続要請を受け取る別のサーバ・ノード130をランダムに決定することができ、あるいはその代わりに、要請中のクライアント160にエラー・メッセージを返して現在接続が設定できないことを知らせることもできる。
図2の10で示したように、分散型ロード・バランサ・システムのロード・バランサ・ノード層は、ソースから通信セッション(例えばTCP接続)の要請を受ける。このソースは、例えば、分散型ロード・バランサ・システムを実施するネットワーク100への外部ネットワーク150上のクライアント160でよい。少なくともいくつかの実施形態では、この要請をネットワーク100の境界ルータ102でクライアント160から受けることができ、また、例えば、フロー単位等コスト多重パス(ECMP)ハッシュ技術を用いてクライアント160からの特定の接続要請を経路指定するロード・バランサ(LB)ノード110を擬似ランダムに選択して、着信パケットをロード・バランサ・ノード層のロード・バランサ・ノード110に経路指定することができるエッジ・ルータ104に、経路指定することができる。
20で示したように、ロード・バランサ・ノード層は、宛先ノードをランダムに選択し、選択した宛先ノードに接続要請を送る。この宛先ノードは、例えば、ロード・バランサによって率いられた複数のサーバ・ノード130のうちの1つでよい。少なくともいくつかの実施形態では、ロード・バランサ層のロード・バランサ・ノード110は、すべての既知のサーバ・ノード130の中から接続要請を受けるサーバ・ノード130をランダムに選択することができる。しかし、いくつかの実施形態では、すべての既知のサーバ・ノード130の中からの純粋にランダムな選択以外の他の方法を用いて接続要請を受けることもできるサーバ・ノード130をランダムに選択することができる。例えば、いくつかの実施形態では、ロード・バランサ・ノード110がサーバ・ノード130に関する情報を用いてサーバ・ノード130のランダムな選択に重み付けすることができる。一例として、ロード・バランサ・ノード110が、異なるサーバ・ノード130が異なるタイプの装置であるか、または、異なるCPUで構成されており、したがって異なる能力またはキャパシティを持つことを知っている場合、その情報を用いてサーバ・ノード130の特定のタイプまたは構成の方に(または、避けて)ランダムな選択にバイアスをかけることができる。
30で示したように、宛先ノードは自身が通信セッションを受け入れることができるかどうかを判断する。少なくともいくつかの実施形態では、サーバ・ノード130上のローカル・ロード・バランサ(LB)モジュール132が、サーバ・ノード130上のそれぞれのサーバ134の1つまたは複数の指標に基づいてそれぞれのサーバ134が新たな接続を受け入れることができるかどうかを判断する。
40では、接続要請が受理された場合は、50で示されるようにその後、宛先ノードが自身が接続を扱うことができることをロード・バランサ・ノード層に知らせる。60で示されるように、その後、ロード・バランサ・ノード層を介してソース(例えば、クライアント160)と宛先ノード(例えば、サーバ・ノード130上のサーバ134)との間に通信セッションが設定される。少なくともいくつかの実施形態では、サーバ・ノード130上のサーバ134は、TCPスタックを使用してクライアント160への接続を管理する。
40では、接続要請が受理されなかった場合は、70で示されるように、その後、宛先ノードがロード・バランサ・ノード層に通知し、本方法はエレメント20に戻ることができる。ロード・バランサ・ノード層は、その後、20で別の宛先ノードをランダムに選択することができるか、またはその代わりに、要請中のクライアント160に接続が現在設定できないことを知らせることができる。クライアント160は、必ずしも必要ではないが、接続要請を再提出して本方法をエレメント10で再開することもできることに留意されたい。
再度、図1を参照すると、分散型ロード・バランサ・システムの少なくともいくつかの実施形態では、商品ハードウェアを使用してネットワーク100上のエッジ・ルータ104で受けたクライアント・トラフィックをネットワーク100上のサーバ・ノード130に経路指定することができる。分散型ロード・バランサの少なくともいくつかの実施形態では、複数のロード・バランサ・ノード110を含んだロード・バランサ・ノード層を含むことができる。少なくともいくつかの実施形態では、ロード・バランサ・ノード110はそれぞれ、ロード・バランサ・ノード層での複数の役割のうちの1つまたは複数の役割を果たすことができる。ロード・バランサ・ノード110のこれらの役割には、入口ノード、出口ノード、及び、フロー・トラッカ・ノード(所与のパケット・フローの一次フロー・トラッカまたは二次フロー・トラッカとしての)が含まれ得る。少なくともいくつかの実施形態では、各ロード・バランサ・ノード110は、商品のラックマウントのコンピューティング・デバイスなどの個別のコンピューティング・デバイスとしてまたはそのデバイス上で、ロード・バランサ・ノード層内に実装することができる。少なくともいくつかの実施形態では、各ロード・バランサ・ノード110は、入口ノード、出口ノード、及び、フロー・トラッカ・ノード(パケット・フローの一次フロー・トラッカまたは二次フロー・トラッカとしての)の3つの役割のそれぞれを果たすことができ、一般には、ロード・バランサ・ノード110は特定のパケット・フローに対する役割のうちのただ1つのみ(しかし、可能性としては2つまたは3つ)を果たしている。しかし、少なくともいくつかの実施形態では、ロード・バランサ・ノード110は、特定のパケット・フローに対する一次フロー・トラッカ及び二次フロー・トラッカの両方の役割は許容されないことに留意されたい。あるいは、いくつかの実施形態では、各ロード・バランサ・ノード110は、3つの役割のうちの1つのみを果たすことができる。この実施形態では、コンピューティング・デバイスの別個の組をロード・バランサ・ノード層に入口ノード、出口ノード及びフロー・トラッカ・ノードとして特異的に実装することができる。
少なくともいくつかの実施形態では、コンシステント・ハッシング技術とコンシステント・ハッシュ・リング技術を適用してパケット・フローに対する一次と二次のフロー・トラッカを決定することができる。クライアントからの各パケット・フローは、例えば、クライアントIPアドレス、クライアント・ポート、サーバ(パブリック)IPアドレス及びサーバ・ポートからなる4要素の組によって一意的に識別することができる。この識別子は、クライアント及びパブリックの終点対を示すCPまたはCcPpと短縮することができる。任意の与えられたTCPフロー(またはCP対)に関連したパケットは、エッジ・ルータ104からのハッシュ化多重パス(例えば、ECMP)フロー分布のせいで入口サーバ112として動作する任意のロード・バランサ・ノード110上に現れることができる。コンシステント・ハッシングを用いて、パケットが入口ノードとして働くロード・バランサ・ノード110に到達したときにこの入口ノードがパケット・フローの状態を維持する責任を負うロード・バランサ・ノード110(すなわち、一次フロー・トラッカ・ノード)を決定することができる。CP対が入口ノードによってコンシステント・ハッシュ・リングにハッシングされ、どのロード・バランサ・ノード110がパケット・フローの状態情報を維持する責任を負うのかを決定することができる。コンシステント・ハッシュ・リング内のパケット・フローのCP対のコンシステント・ハッシングにしたがって決定されるノード110は、パケット・フローに対する一次フロー・トラッカとして働くノード110である。少なくともいくつかの実施形態では、コンシステント・ハッシュ・リング内のサクセサ・ノードがパケット・フローに対する二次フロー・トラッカとして働く。
図3は、少なくともいくつかの実施形態により3つの役割(入口、出口及びフロー・トラッカ)を実装するコンポーネントを含むロード・バランサ(LB)ノード110の例を示す。この例では、入口サーバ112コンポーネントは、クライアントから入ってくるTCPパケットを受け取りこのTCPパケットをカプセル化パケットとしてサーバに送る、入口の役割を行う。出口サーバ114コンポーネントは、サーバから出て行くデカプセル化パケットを受け取りこのデカプセル化TCPパケットをクライアントに送る、出口の役割を行う。フロー・トラッカ116コンポーネントは、クライアント160とサーバ134の間で確立された1つまたは複数のパケット・フローに対する一次または二次フロー・トラッカとして働く。入口サーバ112もロード・バランサ・ノード110上のフロー・トラッカ116または別のロード・バランサ・ノード110上のフロー・トラッカ116と通信し、クライアントとサーバ134のうちの1つの間にそれぞれのクライアント160から受けた接続要請に応答してTCP接続を開始するか、またはパケット・フローのマッピング情報を得ることができる。もし出口サーバが、
ロード・バランサ・ノード
図1を再び参照すると、少なくともいくつかの実施形態では、ロード・バランサ・ノード層内のロード・バランサ・ノード110が、ネットワーク上の1つまたは複数のルータ104からのクライアント・トラフィック(パケット、例えば、TCPパケット)を受けファブリック120上の分散型ロード・バランサ・システムが用いるプロトコル(例えばユーザ・データグラム・プロトコル(UDP))にしたがってこのパケットをカプセル化する。ロード・バランサ・ノード層は、その後、このカプセル化パケットをファブリック120上で宛先サーバ・ノード130に転送する。各サーバ・ノード130は、ロード・バランサ・システムのコンポーネントであるローカル・モジュール132を含む。このモジュール132は、本明細書では、ロード・バランサ・モジュールまたは単にLBモジュールと呼び、サーバ・ノード130上のソフトウェア、ハードウェアまたはそれらの組合せで実装することができる。各サーバ・ノード130では、それぞれのロード・バランサ・モジュール132がパケットをデカプセル化しこのTCPパケットを通常のTCP処理のためにローカルTCPスタックに送る。少なくともいくつかの実施形態では、ロード・バランサ・ノード層はすべてのクライアント・サーバTCPフローの状態情報を維持することができるが、しかし、ロード・バランサ・ノード層内のロード・バランサ・ノード110はTCPフローに関して何も読み取ることができない。各フローは、それぞれのサーバ・ノード130上のサーバ134とクライアント160の間で管理される。分散型ロード・バランサ・システムは、TCPパケットが正しい宛先サーバ134に到着することを保証する。各サーバ・ノード130でのロード・バランサ・モジュール132は、ロード・バランサ・ノード110から受けたクライアント接続要請に応じてそれぞれのサーバ134が新しい接続を受けるか拒否するかについての決定を行なう。
少なくともいくつかの実施形態では、分散型ロード・バランシング・システムは、コンシステント・ハッシング技術を使用して、例えば、どのサーバ・ノード130が特定のTCPパケット・フローに責任を負うのかを記憶するロード・バランサ・ノード110を決定することができる。ロード・バランサ・ノード層内のロード・バランサ・ノード110は、コンシステント・ハッシング技術を用いてコンシステント・ハッシュ・リングとして見ることができる。また、ロード・バランサ・ノード110は、このリング内のメンバー数のトラックを保持し、コンシステント・ハッシング関数によって特定のパケット・フローに責任を負うリング内の特定のメンバー数を決定することができる。少なくともいくつかの実施形態では、クライアント160とサーバ134の間の各パケット・フローを追跡する責任を負う2つのロード・バランサ・ノード110があり、これらのノード110は一次フロー・トラッカ(PFT)ノードおよび二次フロー・トラッカ(SFT)ノードと呼ぶことができる。少なくともいくつかの実施形態では、一次フロー・トラッカは、フローに対するコンシステント・ハッシュ・リング上の第1ロード・バランサ・ノード110であり、二次フロー・トラッカは、一次フロー・トラッカ・ノードとは異なるコンシステント・ハッシュ・リング上の次のまたはその後のロード・バランサ・ノード110である。この配置で一次フロー・トラッカ・ノードが失敗した場合は、二次フロー・トラッカ・ノードが新たな一次フロー・トラッカになり、別のロード・バランサ・ノード110(例えば、コンシステント・ハッシュ・リング上の次のノード110)が二次フロー・トラッカの役割を引き継ぐことができる。少なくともいくつかの実施形態では、ロード・バランサ・ノード110が与えられたパケット・フローに対する一次フロー・トラッカと二次フロー・トラッカの両方の働きをすることは許容されないことに留意されたい。コンシステント・ハッシュ・リング内のこのメンバー数の変更及び他のメンバー数の変更については、後ほど本文書で論じる。少なくともいくつかの実施形態では、ロード・バランサ実装(例えば、現在実装されているロード・バランサ・ノード110及びサーバ・ノード130の正式なリスト)の構成情報は、例えば、ファブリック120を介してロード・バランサ・ノード110に結合している1つまたは複数のサーバ装置に実装することができる分散型ロード・バランシング・システムの構成サービス122コンポーネントにより維持することができる。
少なくともいくつかの実施形態では、ロード・バランサ・ノード110は、一次及び二次のフロー・トラッカ・ノードとして働くことに加えて、さらに、与えられたフローに対する他の2つの役割(入口ノードの役割と出口ノードの役割)のうちの1つを果たすこともできる。パケット・フローに対する入口ノードは、エッジ・ルータ104からそれぞれのパケット・フローを受け取り、ファブリック120を介してサーバ・ノード130上の選択されたサーバ134へパケット・フロー(カプセル化パケットとして)を転送するロード・バランサ・ノード110である。入口ノードは、実際のクライアント・データ(TCPデータ・パケット)をそれぞれの宛先サーバ・ノード130に移動させる唯一のロード・バランサ・ノード110である。入口ノードは、宛先サーバ・ノード130上のそれぞれのロード・バランサ・モジュール132へのTCPフローのマッピングを維持して、入口ノードがどのロード・バランサ・モジュール132がクライアント・トラフィックを転送するのかが分かるようにする。出口ノードは、ファブリック120を介してサーバ・ノード130から受け取ったパケット・フローの応答トラフィックを境界ネットワークを介してそれぞれのクライアント160に転送する責任を負ったロード・バランサ・ノード110である。ロード・バランサ・モジュール132は、ロード・バランサ・プロトコル(例えば、UDP)にしたがってサーバ134から得た応答パケットをカプセル化して、このカプセル化された応答パケットをファブリック120を介してそのフローのそれぞれの出口ノードに送る。出口ノードはステートレスであり、このパケットを単にデカプセル化し、外部ネットワーク150を介してそれぞれのクライアント160に送達するための境界ネットワーク上の境界ルータ102にこの応答パケット(例えば、TCPパケット)を送る。
先に述べたように、少なくともいくつかの実施形態では、各ロード・バランサ・ノード110は、異なるパケット・フローに対する入口ノード、出口ノード及び/またはフロー・トラッカ・ノード(一次または二次のフロー・トラッカのうちのいずれかとして)の役割を果たすことができる。ロード・バランサ・ノード層内の単一のロード・バランサ・ノード110は、このノードが処理しているパケット・フローに応じて、これら役割のうちの任意の1つを果たすことができる。例えば、少なくともいくつかの実施形態では、ロード・バランサ・ノード110は、1つのパケット・フローに対する入口ノード、別のパケット・フローに対する一次または二次のフロー・トラッカ、及び、さらに別のパケット・フローに対する出口ノードとしての役割を果たすことができる。加えて、少なくともいくつかの実施形態では、ロード・バランサ・ノード110が同一のパケット・フローに対して複数の役割(例えば、ある与えられたパケット・フローに対する入口ノード及び一次(または二次)フロー・トラッカ・ノードとしての役割)を果たすことができる。しかし、少なくともいくつかの実施形態では、冗長性と回復の目的のために、ロード・バランサ・ノード110が同一のパケット・フローに対して一次と二次のフロー・トラッカ・ノード両方の役割を果たすことは許容されない。
上記では、各ロード・バランサ・ノード110が、入口サーバ、出口サーバ及びフロー・トラッカの3つの役割のうちの任意の役割を果たすことができる実施形態を説明している。しかし、いくつかの実施形態では、異なるグループのコンピューティング装置はロード・バランシング・システムの異なる役割に割り当てることができる。例えば、いくつかの実施形態では、それぞれが別個のコンピューティング装置上に実装された入口ノード、出口ノード及びフロー・トラッカ・ノードの個別の組が存在できる。別の例として、いくつかの実施形態では、1組のコンピューティング装置が入口ノード及びフロー・トラッカ・ノードの両方の働きをすることができ、他方で、別の組のコンピューティング装置は出口ノードとしてのみ働くことができる。
ロード・バランサ・モジュール
前に述べたように、各サーバ・ノード130は、ロード・バランサ・システムのコンポーネントであるローカル・ロード・バランサ・モジュール132を含む。モジュール132は、サーバ・ノード130上のソフトウェア、ハードウェアまたはそれらの組合せにおいて実装することができる。少なくともいくつかの実施形態では、サーバ・ノード130上のロード・バランサ・モジュール132は3つの主な役割(外出パケットをカプセル化すること、着信パケットをデカプセル化すること及びノード130上のサーバ134に対するローカル・ロード・バランシングの決定を下し接続を公表すること)を果たすことができる。これらの3つの役割は、以下に簡潔に記述され、その後、本明細書により詳細に記述されている。
少なくとも分散型ロード・バランシング・システムのいくつかの実施形態では、TCP接続が終了されず、パケットのなりすましがなされない。すなわち、ロード・バランサ・ノード層によって送られたすべてのパケットのソースと宛先のIPアドレスは、パケット・フローに関与する終点(すなわち、クライアント160及びサーバ134)の実際のIPアドレスである。なりすましの代わりに、これらの実施形態では、ファブリック120上のロード・バランサ・ノード110とサーバ・ノード130との間に送られるすべてのパケットが、例えばUDPパケットとしてカプセル化される。パケット・フロー内の入口ノードとして働くロード・バランサ・ノード110からサーバ・ノード130に到着するパケット・フロー内のインバウンド・パケットはロード・バランサ・ノード110によってカプセル化されるので、これらのパケットをデカプセル化しノード130上のサーバ134のローカルホストTCPフローに向け直す必要がある。ノード130上のロード・バランサ・モジュール132がこのデカプセル化を行う。同様に、サーバ134からのパケット・フローの発信パケットはロード・バランサ・モジュール132によってカプセル化され、パケット・フローの出口ノードとして働くロード・バランサ・ノード110にファブリック120を介して送られる。
少なくともいくつかの実施形態では、サーバ・ノード130上のロード・バランサ・モジュール132も、それぞれのサーバ・ノード130上のサーバ134のロード・バランシングに関してローカルに決定を行う。具体的には、ノード130上のロード・バランサ・モジュール132は、新たなTCP接続要請を受けてそれぞれのサーバ134が別のTCPフローを受けるかどうかを決定する。先に述べたように、ロード・バランサ・ノード110がロード・バランサ・モジュール132に送られるすべてのパケットをカプセル化し、したがって、ロード・バランサ・モジュール132は実際にクライアント160からのTCP同期(SYN)パケットを受け取らず、その代わり、ロード・バランサ・モジュール132は、カプセル化プロトコル(例えば、UDP)にしたがって、ロード・バランサ・モジュール132が受理するかまたは拒否することができる接続要請メッセージをフロー・トラッカ116から受け取る。ロード・バランサ・モジュール132が接続要請メッセージを受理すると、ロード・バランサ・モジュール132はローカルホストに向かうSYNパケットを生成する。ローカルホストが接続を受理するときに、これはそれぞれのクライアント接続を扱う実際のTCPスタックになる。
少なくともいくつかの実施形態では、接続要請メッセージを受理すべきかどうかに関する決定をするために、ロード・バランサ・モジュール132は、サーバ・ノード130上の現在のリソース消費量に関する1つまたは複数の指標を見る。そして、新しい接続を取り扱うことができる十分なリソースがあるならば、ロード・バランサ・モジュール132は接続を受理する。少なくともいくつかの実施形態では、ロード・バランサ・モジュール132が考慮することができるリソース指標は、限定はされないが、CPU利用率、最近の帯域幅消費量及び確立した接続数のうちの1つまたは複数のものを含むことができる。いくつかの実施形態では、これらの指標の代わりに、またはそれらに加えて他の指標を考慮することができる。例えば、いくつかの実施形態では、ロード・バランサ・モジュールは、指標としてサーバ待ち時間(すなわち、要請時間はサーバの接続処理待ちで消費される)を考慮することができ、サーバ待ち時間が閾値を超えると接続要請を拒否することができる。これらの指標及び/または他の指標を用いて、ロード・バランサ・モジュール132は、それぞれのサーバ134につき新たなパケット・フローを受け入れるか拒否するかを決定することができる。少なくともいくつかの実施形態では、リソースの使用割合(例えば、使用率N%)を指標から個々にまたは閾値(例えば、90%)との組み合わせ及び比較で決定することができる。決定したリソース使用率が閾値となるかまたは閾値を超えるなら、あるいは、接続を追加すると使用率が閾値を超えるならば、接続要請を拒絶することができる。
少なくともいくつかの実施形態では、ロード・バランサ・モジュール132は、接続要請メッセージを拒絶すべきかどうかを決定する確立論的方法を実装することができる。リソース使用率が閾値であるか閾値を超えている場合、上記のようにすべての接続要請を拒絶する代わりに、この方法では、2つまたはそれを超える異なるレベルの使用率において異なる確率で接続要請を拒絶することができる。例えば、リソース使用率が80%ならば、ロード・バランサ・モジュール132は20%の確率で接続要請を拒絶することができ、リソース使用率が90%ならば、ロード・バランサ・モジュール132は25%の確率で接続要請を拒絶することができ、リソース使用率が95%ならば、ロード・バランサ・モジュール132は50%の確率で接続要請を拒絶することができ、リソース使用率が98%ならば、ロード・バランサ・モジュール132はすべての接続要請を拒絶することができる。
少なくともいくつかの実施形態では、各接続要請メッセージは、接続要請メッセージがロード・バランサ・モジュール132に何回拒絶されたかの表示を含むことができる。ロード・バランサ・モジュール130が受け取った接続要請メッセージが閾値の回数を超えて拒絶されたことを表示していれば、ロード・バランサ・モジュール130は、たとえサーバ・ノード130の性能指標が接続要請を拒絶すべきであると示していても接続を受理することができる。
いくつかの場合では、接続要請メッセージが送られるすべてのロード・バランサ・モジュール132が接続要請を拒絶することができる可能性がある。少なくともいくつかの実施形態では、接続要請メッセージが無期限にロード・バランサ・モジュール132からロード・バランサ・モジュール132に飛び込んでいくのを防ぐために、各接続要請メッセージに生存時間を与えることができる。生存時間が終わると、フロー・トラッカ・ノードは要請を終了し、それぞれのクライアント160に要請が現在なされ得ないことを知らせることができる。
少なくともいくつかの実施形態では、サーバ・ノード130上のロード・バランサ・モジュール132はまた、ロード・バランサ・ノード110に接続公表を行うこともできる。少なくともいくつかの実施形態では、定期的にまたは非定期に(例えば、1秒に一回)接続公表を行なうために、各ロード・バランサ・モジュール132はサーバ・ノード130をルーティング・テーブル(例えば、ネットスタット・ルーティング・テーブル)で見て、ロード・バランサ・ノード110にアクティブな接続(TCPフロー)のリストを公表する。ある所与のパケット・フローの存在につき通知する必要のあるロード・バランサ・ノード110は、それぞれのパケット・フローに対する入口ノード及び一次と二次のフロー・トラッカの働きをするロード・バランサ・ノード110である。いくつかの実施形態では、ロード・バランサ・モジュール132は、コンシステント・ハッシング技術を用いてサーバ・ノード130上のアクティブなTCPフローにつき通知する必要のあるロード・バランサ・ノード110のリストをフィルタリングすることができる。例えば、ロード・バランサ・モジュール132は、コンシステント・ハッシュ・リングによって、どのロード・バランサ・ノード110がそれぞれ与えられたパケット・フローに対する一次及び二次のフロー・トラッカとしての働きをしているのかを決定することができる。いくつかの実施形態では、ロード・バランサ・モジュール132は、どのバランサ・ノード110がロード・バランサ・モジュール132に各パケット・フローに対するデータ・パケットを最後に送ったのかを追跡し、この情報を用いてどのロード・バランサ・ノード110がパケット・フローの入口ノードとして働くかを決定する。なぜなら、入口ノードのみがクライアント・データをロード・バランサ・モジュール132に転送するからである。いくつかの実施形態では、その後、ロード・バランサ・モジュール132は、パケット・フローを通知する必要があると自身が決定した各ロード・バランサ・ノード110に対するメッセージを策定し、各ロード・バランサ・ノード110にメッセージを送信してそれぞれのサーバ・ノード130がクライアント160への接続を依然として維持していることを当該ノード110に知らせる。ロード・バランサ・モジュール132がロード・バランサ・ノード110に行なうこの接続公表は、ロード・バランサ・ノード110のリース期間の延長とみなすことができる。ロード・バランサ・ノード110がある時間(例えば、10秒)内に特別なパケット・フローを示す接続公表メッセージを受け取らないならば、その後、ロード・バランサ・ノード110はそれぞれのパケット・フローにつき自由に忘れることができる。
ロード・バランサ・ノードへの多重パス経路指定
図4は、少なくともいくつかの実施形態による、分散型ロード・バランサでの経路指定及びパケット・フローの態様を示す。少なくともいくつかの実施形態では、各入口ノード(入口ノードは入口サーバ112として図4に示されている)は、例えば、境界ゲートウェイ・プロトコル(BGP)を介して1つまたは複数のパブリック終点(例えば、IPアドレスとポート)を分散型ロード・バランサのエッジ・ルータ104に経路指定する自身の能力を広告する。少なくともいくつかの実施形態では、BGPセッションを介してエッジ・ルータ104に自身を広告する各入口ノードではなく、図5に示すように、1つまたは複数の他の入口ノード(例えば、2つの隣接ノード)がエッジ・ルータ104とBGPセッションを確立して当該入口ノードを広告することもできる。
従来のロード・バランサは、一般に、単一のパブリック終点のみの働きをすることができる。対照的に、分散型ロード・バランサの実施形態では、多数のロード・バランサ・ノード110が単一のパブリック終点を提供することができる。これによって、ルータの能力に依存して、すべての入口サーバ112に経路指定された単一のパブリックIPアドレスが、エッジ・ルータ104によって全帯域幅(例えば、160Gbps)を扱うことができる構成が可能になる。少なくともいくつかの実施形態では、この構成を達成するために、エッジ・ルータ104は4層フロー単位ハッシュ化多重パス経路指定技法(例えば、等コスト多重パス(ECMP)経路指定技法)を利用してそれぞれが同じパブリックIPアドレスを広告する複数の入口サーバ112全体にわたってトラフィックを分散させる。フローの4層ソース及び宛先ポートをエッジ・ルータ104の一部として用いて着信パケットをすべての入口サーバ112に分散させることで、フロー・ハッシュは、一般的に、乱れたパケットを回避するために入口サーバ112として働く同一のロード・バランサ・ノード110に経路指定された各接続に対するパケットを保持することができる。しかし、いくつかの実施形態では、エッジ・ルータ104は、他の技法を用いてトラフィックを入口サーバ112全体にわたって分散させることができることに留意されたい。
図4は、また、2つ以上の分散型ロード・バランサをネットワーク100上に実装することもできることも示している。これらの2つ以上の分散型ロード・バランサは、それぞれ、複数のサーバ130を率い、異なるパブリックIPアドレスを広告する独立したロード・バランサとして働くことができる。またはその代わりに、図4に示すように2つ以上の分散型ロード・バランサがそれぞれ同一のIPアドレスを広告することもできる。また、ハッシング技術(例えば、4層フロー単位ハッシュ化多重パス経路指定技法)を境界ルータ102で用いて、パケット・フローを次々にそれらの対応する入口サーバ112に分散させるエッジ・ルータ104にパケット・フローを分散させることができる。
図5は、少なくともいくつかの実施形態により、境界ゲートウェイ・プロトコル(BGP)を用いてエッジ・ルータに入口ノードを広告することを示す。この例において、ロード・バランサ実装で入口ノード110A〜110Dの働きをする4つのロード・バランサ・ノードが存在する。エッジ・ルータ104はクライアント(図示せず)からロード・バランサ・ノード110まで着信パケットを経路指定する。少なくともいくつかの実施形態では、エッジ・ルータ104が、4層フロー単位ハッシュ化多重パス経路指定技法(例えば、等コスト多重パス(ECMP)経路指定技法)によって経路指定の決定をすることができる。
少なくともいくつかの実施形態では、エッジ・ルータ104は、ロード・バランサ実装において、入口ノード110によって開始されたセッションを広告する境界ゲートウェイ・プロトコル(BGP)技術を介してクライアント・トラフィックを現在受け取ることができる入口ノード110を見つける。各入口ノード110はBGPを用いて自身をエッジ・ルータ104に広告することができるはずである。しかし、BGPは、一般的に、収束するのに比較的長い時間(3秒以上)を要する。各入口ノード110がBGPを介して自身を広告するこの技法を用いると、入口ノード110が故障した場合、エッジ・ルータ104上のBGPセッションが中断し、それによって、エッジ・ルータ104が故障中止を知り現在のTCPフローを入口ノード110に再度経路指定するのに、ネットワーク上の期間としてはかなりの時間(3秒以上)を要し得る。
BGPに関連する収束問題を回避しノード110の故障をより速く回復するために、少なくともいくつかの実施形態では、BGPセッションを介してエッジ・ルータ104に自身を広告する入口ノード110の代わりに、ロード・バランサ実装における少なくとも1つの他の入口ノード110がBGPセッションを介してエッジ・ルータ104に当該の入口ノード110を広告する責任を負う。例えば、図5に示すようないくつかの実施形態では、ある与えられた入口ノード110の左隣と右隣の入口ノード110、例えば、ノード110の整列されたリスト(例えば、ノード110によって形成されるコンシステント・ハッシュ・リング)での左隣と右隣が、この与えられた入口ノード110をエッジ・ルータ104に広告することができる。例えば、図5では、入口ノード110Aが入口ノード110B、110Dを広告し、入口ノード110Bが入口ノード110A、110Cを広告し、入口ノード110Cが入口ノード110B、110Dを広告し、そして、入口ノード110Dが入口ノード110C、110Aを広告する。入口ノード110は、後ほど本明細書で説明するように、互いの健全性をチェックしうわさとして広める。説明されるような健全性チェック法を用いると、不健全なノードを検出し、1秒未満、例えば100ミリ秒(ms)、でノード110の間にこの情報を広めることができる。ある入口ノード110が健全ではないと決定すると、不健全なノードを広告する入口ノード110はこの不健全なノード110を広告することを直ちに止めることができる。少なくともいくつかの実施形態では、入口ノード110は、BGPセッションに対するTCP閉鎖メッセージまたは類似のメッセージをエッジ・ルータ104に送ることにより、エッジ・ルータ104とのBGPセッションを終了する。したがって、あるノード110の故障を検出するためにこの故障ノード110が確立したBGPセッションの中断を待たなければならないのではなく、故障ノード110の代わりに広告し、ノード110が不健全であることを検出すると、このノード110を広告する他の入口ノードがエッジ・ルータ104とのBGPセッションを終了させるときにこの故障ノード110を発見することができる。ロード・バランサ・ノードの故障の取り扱いは、本明細書で図18A、18Bに関して後程論じる。
図6は、分散型ロード・バランシング・システムの少なくともいくつかの実施形態による、多重パス経路指定法のフローチャートである。900で示されたように、ロード・バランサ実装での入口ノード110は、それらの隣接ノード110をエッジ・ルータ104に広告する。少なくともいくつかの実施形態では、入口ノード110は、コンシステント・ハッシュ・リングなどのノード110の整列したリストに従ってそれらの隣接ノード110を決定することができる。少なくともいくつかの実施形態では、入口ノード110は、BGPセッションを用いてそれらの隣接ノード110をエッジ・ルータ104に広告し、これらのBGPセッションは広告された各ノード110に対して1つのBGPセッションがエッジ・ルータ104と確立される。
902で示されるように、エッジ・ルータ104は、フロー単位ハッシュ化多重パス経路指定技法(例えば、等コスト多重パス(ECMP)経路指定技術)にしたがって、クライアント160から受け取ったトラフィックをアクティブな(広告された)入口ノード110に分散させる。少なくともいくつかの実施形態では、エッジ・ルータ104はクライアント160にパブリックIPアドレスを公表し、すべての入口ノード110がエッジ・ルータ104に同じパブリックIPアドレスを広告する。エッジ・ルータは、4層ソース及び宛先ポートをエッジ・ルータ104のフロー・ハッシュの一部として使用して入口ノード110の間に着信パケットを分散させる。これによって、一般的に、同一の入口ノード110に経路指定された各接続に対するパケットが保持される。
904で示されるように、入口ノードはデータ・フローを標的サーバ・ノード130に転送する。少なくともいくつかの実施形態では、入口ノード110は、データ・フローに対する一次及び二次のフロー・トラッカ・ノードと相互に作用してデータ・フローを標的サーバ・ノード130にマッピングする。したがって、各入口ノード110は、標的サーバ・ノード130に受け取ったパケットを適切に転送するのに使用することができるノード110によってアクティブなデータ・フローのマッピングを維持することができる。
要素906〜910は、入口ノード110の故障を検知し故障から回復することに関する。906に示すように、入口ノード110は、ある入口ノード110が故障したことを、例えば、本明細書で記載したような健全性チェック技法によって、検出することができる。この入口ノード110が故障したことを検出すると、その隣接ノード110はエッジ・ルータ104へのこの入口ノード110の広告を停止する。少なくともいくつかの実施形態では、このことはそれぞれのBGPセッションのエッジ・ルータ104にTCP閉鎖メッセージを送ることを伴う。
908で示されるように、エッジ・ルータ104は、BGPセッションの閉鎖を介して入口ノード110が故障したことを検出すると、フロー単位ハッシュ化多重パス経路指定技法に従って、クライアント160からの着信トラフィックを残りの入口ノード110に再分散させる。したがって、少なくともいくつかのデータ・フローを異なる入口ノード110に経路指定することができる。
910で示されるように、入口ノード110は、必要に応じて、マッピングを回復し、データ・フローを適切な標的サーバ・ノードに転送することができる。入口ノード110のノード110故障から回復する方法は、本明細書の別の箇所で論じられる。一例として、ある入口ノード110は、現在のマッピングを持っていないパケットを受け取ると、コンシステント・ハッシュ関数を用いてコンシステント・ハッシュ・リングによるデータ・フローに対するフロー・トラッカ・ノードを決定し、このフロー・トラッカ・ノードからマッピングを回復することができる。
非対称なパケット・フロー
少なくともいくつかの実施形態では、入口ノード帯域幅及びCPU使用を効率的に利用するために、インバウンド・データに対するアウトバウンド・トラフィックの比率が1以上であるときに分散型ロード・バランシング・システムは、図7に示すようにサーバ・ノード130から多数の出口ノードへアウトバウンド・パケットを転送する。少なくともいくつかの実施形態では、各接続に対して、それぞれのサーバ・ノード130上のロード・バランサ・モジュール132は、クライアント終点/パブリック終点の組をハッシングし、コンシステント・ハッシュ・アルゴリズムを用いてそれぞれのアウトバウンド・パケット・フローの出口サーバ114の働きをするロード・バランサ・ノード110を選択する。しかし、いくつかの実施形態では、他の方法及び/またはデータを用いて接続の出口サーバ114を選択することもできる。選択された出口サーバ114は、必ずではないが一般的に、接続の入口サーバ112の働きをするロード・バランサ・ノード110とは異なるロード・バランサ・ノード110であり得る。少なくともいくつかの実施形態では、このロード・バランサ・ノード110/出口サーバ114の故障がなければ、この特別な接続のアウトバウンド・パケットは乱れたパケットを回避するためにすべて同じ出口サーバ114に転送されるであろう。
少なくともいくつかの実施形態では、サーバ・ノード130による出口サーバ114の選択に使用される方法およびデータは、エッジ・ルータ104によってなされる入口サーバ112の選択に使用される方法及びデータとは異なってよい。異なった方法及びデータを使用することで、一般に、ある与えられた接続の出口ノードとして選択されるロード・バランサ・ノード110は、この接続の入口ノードとして選択されたロード・バランサ・ノード110とは異なる結果となり得る。そして、多数のロード・バランサ・ノード110が選択されて、入口ノードとして働く単一のロード・バランサ・ノード110を通過する接続用の発信トラフィックを扱う結果となり得る。
図7は、少なくともいくつかの実施形態による、非対称のパケット・フローを図示している。少なくとも1つの接続が、外部ネットワーク150上のクライアント160から入口サーバ112を通ってサーバ・ノード130A、130B、130C、130Dのそれぞれとに確立される。少なくともいくつかの実施形態では、各接続に対して、接続用出口ノードを選ぶために、それぞれのサーバ・ノード130上のロード・バランサ・モジュール132は、クライアント終点/パブリック終点の組をハッシングし、コンシステント・ハッシュ・アルゴリズムを用いてそれぞれのアウトバウンド・パケット・フローの出口サーバ114として働くべきロード・バランサ・ノード110を選択する。例えば、サーバ・ノード130Aはある1つの接続の出口サーバ114Aを選択しており、サーバ・ノード130Bは1つの接続の出口サーバ114Aと別の接続の出口サーバ114Bを選択している。しかし、いくつかの実施形態では、他の方法及び/またはデータを用いて接続の出口ノードを選択することができる。
クライアント接続停止のないロード・バランサ・ノード故障からの回復
ロード・バランサ・ノード110は、コンシステント・ハッシングを用いてどのサーバ・ノード130がクライアント・トラフィックを受け取るべきかを決定することができる一方、いくつかの接続の長い寿命により、この手法は、新しいサーバ・ノード130がコンシステント・ハッシングのメンバーに加わり、後に入口ロード・バランサ・ノード110の故障が発生した場合、既存のフローを維持できない。この状況では、サーバ130のコンシステント・ハッシュ・リングが異なるメンバーを持つはずなので、故障ノード110からのフローを引き継ぐロード・バランサ・ノード110は、選択された元のマッピングを決定することができない。したがって、少なくともいくつかの実施形態では、ロード・バランサ・ノード110が、分散型ハッシュ・テーブル(DHT)技術を用いて接続のサーバ・ノード130を選び、パケットをこの選択されたサーバ・ノード130に経路指定することができる。一旦、サーバ・ノード130がDHTによって選択されて特別な接続を受けており、かつ、サーバ・ノード130が健全であり続け、サーバ・ノード130上のロード・バランサ・モジュール132がこのアクティブな接続の状況をDHTに定期的に送信すること(例えば、接続公表を介して)でリース期間を延長し続けたと仮定すると、DHTは接続が完了するまでマッピングを保持するであろう。入口ノード110の故障は、エッジ・ルータ104から残りのロード・バランサ・ノード110までのパケットの分布に影響を与え、その結果、ロード・バランサ・ノード110が異なる組のクライアント接続からのトラフィックを受け取る。しかし、DHTがアクティブな接続をすべて追跡するので、ロード・バランサ・ノード110は、DHTに尋ねて任意のアクティブなマッピングに対するリースを得ることができる。その結果、すべてのロード・バランサ・ノード110は、トラフィックを正しいサーバ・ノード130に渡し、これにより、入口ロード・バランサ・ノード110の故障の場合でさえアクティブなクライアント接続の失敗を防ぐであろう。
分散型ロード・バランシング・システムでのパケット・フロー
図8は、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。図8で、矢印つき実線はTCPパケットを表わしている一方、矢印つき点線はUDPパケットを表わしていることに留意されたい。図8では、入口サーバ112はエッジ・ルータ104を介して1つまたは複数のクライアント160からTCPパケットを受け取る。TCPパケットを受け取ると、入口サーバ112は、自身がこのTCPパケット・フローのサーバ・ノード130へのマッピングを有しているかどうかを判断する。入口サーバ112がTCPパケット・フローのマッピングを有しているならば、サーバ112は(例えば、UDPによって)TCPパケットをカプセル化し、このカプセル化パケットを標的サーバ・ノード130に送る。入口サーバ112がTCPパケット・フローのマッピングを有していないならば、入口サーバ112はTCPパケットから抽出されたTCPパケット・フローに関する情報を含んだUDPメッセージを一次フロー・トラッカ116Aに送りサーバ・ノード130への接続を確立することができ、かつ/または、TCPパケット・フローのマッピングを得ることができる。図9A、9B、及び図10A〜10Gは、クライアント160とサーバ・ノード130との間に接続を確立する方法を示す。サーバ・ノード130上のロード・バランサ・モジュール132は、サーバ・ノード130上のTCP接続の出口サーバ114として働くべきロード・バランサ・ノード110をランダムに選択し、出口サーバ114を介してUDPカプセル化TCP応答パケットをクライアント160に送る。
図9A、9Bは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システム内で接続を確立する場合のパケット・フローのフローチャートを提供する。図9Aの200に示すように、入口サーバ112は、エッジ・ルータ104を介してクライアント160からTCPパケットを受け取る。202では、入口サーバ112がサーバ・ノード130までのTCPフローのマッピングを有していれば、204で示すように、入口サーバ112はTCPパケットをカプセル化しそれぞれのサーバ・ノード130に送る。入口サーバ112は、1つ、2つ、またはそれを超えるクライアント160からの1つ、2つ、またはそれを超えるTCPフローのパケットを絶えず受け取ることができ、かつ処理することができていることに留意されたい。
202では、入口サーバ112がTCPフローのマッピングを有していないならば、このパケットはクライアント160からのTCP同期(SYN)パケットであり得る。206で示されるように、SYNパケットを受け取ると、入口サーバ112はこのSYNパケットからデータを抽出してこのデータを、例えば、UDPメッセージの形で、一次フロー・トラッカ116Aに転送する。少なくともいくつかの実施形態では、入口サーバ112は、コンシステント・ハッシュ関数によりTCPフローの一次フロー・トラッカ116A及び/または二次フロー・トラッカ116Bを決定することができる。208で、一次フロー・トラッカ116Aは、データを例えばハッシュ・テーブルに格納し、TCP接続のサーバ・ノード130側の最初のTCPシーケンス番号を生成し、二次フロー・トラッカ116Bにデータ及びTCPシーケンス番号を転送する。210では、二次フロー・トラッカ116Bも、データを格納し、少なくともTCPシーケンス番号を含むSYN/ACKパケットを作りクライアント160に送ることができる。
212で示されるように、入口サーバ112は、エッジ・ルータ104を介してクライアント160からTCP認識(ACK)パケットを受け取る。入口サーバ112はこの時点でサーバ・ノード130へのTCPフローのマッピングを有していない、それ故、214で、入口サーバ112は、ACKパケットから抽出されたデータを含むメッセージを一次フロー・トラッカ116Aへ送信する。216で示されるように、メッセージを受け取ると、一次フロー・トラッカ116Aは保存されたデータによってTCPフローを確認し、かつACKパケットからの認識されたシーケンス番号(+1)がSYN/ACKで送られた値と一致することを確認する。一次フロー・トラッカ116Aは、その後、サーバ・ノード130を選択してTCPフローを受け取り、データ、TCPシーケンス番号、及び選択されたサーバ・ノード130上のローカル・ロード・バランサ・モジュール132のIPアドレスを含むメッセージを二次フロー・トラッカ116Bに送る。218で示されるように、二次フロー・トラッカ116Bはまた、データ及びTCPシーケンス番号を確認し、SYNメッセージを作製し、この作製したSYNメッセージを選択されたサーバ・ノード130上のローカル・ロード・バランサ・モジュール132に送る。この手法は、図9Bの要素220で継続する。
図9Bの220で示されたように、ロード・バランサ・モジュール132は、作製されたSYNメッセージに応答して、サーバ・ノード130の1つまたは複数の指標を検査してサーバ・ノード130が接続を受理できるかを判断することができる。222では、ロード・バランサ・モジュール132がサーバ・ノード130が現在接続を受理できないと判断するならば、ロード・バランサ・モジュール132は224で二次フロー・トラッカ116Bにメッセージを送る。二次フロー・トラッカ116Bは、以前に格納していたフローの情報を削除することができる。226では、二次フロー・トラッカ116Bが一次フロー・トラッカ116Aにメッセージを送る。一次フロー・トラッカ116Aは、その後、新たな標的サーバ・ノード130を選択し、図9Aの216で示されるような二次フロー・トラッカ116Bにメッセージを送ることができる。
222で、ロード・バランサ・モジュール132が、サーバ・ノード130が接続を受理できると判断すると、図9Bの228に示されるように、ローカル・ロード・バランサ・モジュール132が作製されたSYNからTCP・SYNパケットを構築し、このTCP・SYNパケットをサーバ・ノード130上のサーバ134に送る。TCP・SYNパケットのソースIPアドレスは、サーバ134がクライアント160への直接のTCP接続を受け取ったと信じるようにクライアント160の実際のIPアドレスで占められている。ロード・バランサ・モジュール132は、TCPフローに関連する詳細を、例えば、ローカル・ハッシュ・テーブルに格納する。230で示されるように、サーバ134は、ロード・バランサ・モジュール132が傍受するSYN/ACKパケットに応答する。232に示されるように、ロード・バランサ・モジュール132は、その後、接続情報を含むメッセージを二次フロー・トラッカ116Bに送り接続が受理されたことを知らせる。このメッセージを受け取って、二次フロー・トラッカ116Bは、234で、サーバ134へのマッピングを記録し、やはりマッピング情報を記録する一次フロー・トラッカ116Aに同様なメッセージを送る。236で示されるように、一次フロー・トラッカ116Aは、その後、マッピング・メッセージを入口サーバ112へ転送する。入口サーバ112は、今や、クライアント160からサーバ130へのTCPフローのマッピングを有している。
238で、入口サーバ112は、データ・フローのいかなるバッファされたデータ・パケットもカプセル化し、サーバ・ノード130上のローカル・ロード・バランサ・モジュール132に転送する。入口サーバ112が受け取ったクライアント160からのデータ・フローの追加の着信パケットは、カプセル化され、ロード・バランサ・モジュール132に直接転送される。ロード・バランサ・モジュール132は、このパケットをデカプセル化しサーバ134に送る。
240では、ロード・バランサ・モジュール132が、データ・フローの出口サーバ114を任意に選択する。サーバ134からの後続のアウトバウンドTCPパケットは、ロード・バランサ・モジュール132によって傍受され、UDPによりカプセル化され、そして、任意に選択された出口サーバ114に転送される。出口サーバ114は発信パケットをデカプセル化し、TCPパケットをクライアント160に送る。
上で述べたように、202で、入口サーバ112が受信したパケットのTCPフローのマッピングを有していないならば、このパケットはクライアント160からのTCP同期(SYN)パケットであり得る。しかし、このパケットはTCP・SYNパケットとなることはできない。例えば、ロード・バランサ・ノード110のメンバー数が、ロード・バランサ・ノード110の追加または故障のせいで変化すると、エッジ・ルータ104は、1つまたは複数のTCPフローのパケットをこのパケットのマッピングを有していない入口サーバ112に経路指定することを開始することができる。少なくともいくつかの実施形態では、入口サーバ112は、入口サーバ112がマッピングを有していないパケットを受け取ると、コンシステント・ハッシュ関数を用いてTCPフローの一次フロー・トラッカ116A及び/または二次フロー・トラッカ116Bをコンシステント・ハッシュ・リングにより決定し、一次フロー・トラッカ116Aまたは二次フロー・トラッカ116Bのどちらかにメッセージを送りマッピングを要請することができる。フロー・トラッカ116からTCPフローのマッピングを受け取ると、入口サーバ112はこのマッピングを格納し、TCPフローのTCPパケットをカプセル化し正しい宛先サーバ・ノード130に転送することを開始することができる。
ロード・バランサ・ノードの詳細
少なくともいくつかの実施形態では、ロード・バランサ・ノード110には各々3つの役割がある:
・入口−クライアント接続でのクライアント160からの着信パケットをすべて受け取り、マッピングが知られているならパケットをサーバ・ノード130に経路指定し、マッピングが知られていないならフロー・トラッカにメッセージを送ること。入口ノードからの発信パケットは、この入口ノードによりカプセル化される(例えば、UDPにより)。
・フロー・トラッキング−接続状況の追跡(例えば、どのサーバ・ノード130/サーバ134が各クライアント接続にサービスを提供するように割り当てられてきたのかの)を保つこと。フロー・トラッカはまた、クライアント160とサーバ134の間の接続を確立することに参加もする。
・出口−サーバー134から受け取ったアウトバウンド・パケットをデカプセル化しクライアント160に転送すること。
少なくともいくつかの実施形態では、入口の役割で、ロード・バランサ・ノード110はクライアント->サーバのマッピングが知られているときにパケットをサーバ134に転送する責任を負い、またはマッピングが知られていないときに要請をフロー・トラッカに転送する責任を負う。少なくともいくつかの実施形態では、特別なクライアント接続/データ・フローの入口ノードとして働く、ロード・バランサ・ノード110はまた、クライアント接続の一次フロー・トラッカまたは二次フロー・トラッカのどちらかの働きをすることもできるが両方の働きはできない。
少なくともいくつかの実施形態では、フロー・トラッカの役割において、ロード・バランサ・ノード110は、依然確立されている接続の状態を維持する責任ならびに確立された接続のクライアント->サーバのマッピングを維持する責任を負う。2つのフロー・トラッカは個々のクライアント接続にかかわり、一次フロー・トラッカ及び二次フロー・トラッカと呼ばれる。少なくともいくつかの実施形態では、クライアント接続に関連したフロー・トラッカをコンシステント・ハッシュ・アルゴリズムを用いて決定することができる。フロー・トラッカはまた、限定はされないが、新たなクライアント接続それぞれのサーバ・ノード130を擬似ランダムに選択することを含むロード・バランシング機能も果たす。選択されたサーバ・ノード130上のローカル・ロード・バランサ・モジュール132がサーバ134は接続を扱うことができないと判断するならば、このローカル・ロード・バランサ・モジュール132は接続要請を拒絶することができることに留意されたい。このことが起きたならばフロー・トラッカは別のサーバ・ノード130を選択しこの別のサーバ・ノード130に接続要請を送ることができる。少なくともいくつかの実施形態では、与えられた接続の一次フロー・トラッカの役割及び二次フロー・トラッカの役割は、異なるロード・バランサ・ノード110によって果たされる。
少なくともいくつかの実施形態では、出口の役割において、ロード・バランサ・ノード110はステートレスであり、サーバ・ノード130から受け取った着信パケットをデカプセル化し、いくつかの検証を行い、そして、アウトバウンドTCPパケットをそれぞれのクライアント160に転送する。少なくともいくつかの実施形態では、サーバ・ノード130上のローカル・ロード・バランサ・モジュール132はある与えられた接続のロード・バランサ・ノード110を任意に選択することができる。
ロード・バランサ・ノード・コンシステント・ハッシュ・リングのトポロジ
少なくともいくつかの実施形態では、ロード・バランサ・ノード110は、入力キー空間(クライアント終点、パブリック終点)のコンシステント・ハッシングに基づいてリング・トポロジを形成する。入力キー空間は利用可能なフロー・トラッカ・ノードの間で分割することができる。そして、すべてのフロー・トラッカ・ノードはそのキー空間に対応する質問に答える責任を持つことができる。少なくともいくつかの実施形態では、コンシステント・ハッシュ・リング(例えば、二次のフロー・トラッカ・ノードがサクセサ・ノード、またはコンシステント・ハッシュ・リング内の一次フロー・トラッカ・ノードに対するネクスト・ノード)内のサクセサに基づいて、データを一次及び二次のフロー・トラッカ・ノードに複製することができる。あるフロー・トラッカ・ノードがなんらかの理由で故障したならば、コンシステント・ハッシュ・リング内のネクスト・ロード・バランサー・ノードが故障したノードのキー空間を獲得する。新たなフロー・トラッカ・ノードが加わるときに、このノードは、他のロード・バランサ・ノードがロード・バランサ実装内の構成変化、したがって、コンシステント・ハッシュ・リング内の構成変化につき学習することができるように、自身の終点を登録する(例えば、図1に示すような構成サービス122により)。コンシステント・ハッシュ・リング内でのフロー・トラッカの追加及び故障の取り扱いは図11A〜図11Dを参照してより詳細に論じる。
入口ノード<->フロー・トラッカ・ノードの通信
少なくともいくつかの実施形態では、入口ノードとして働くロード・バランサ・ノード110は、構成サービス122からのフロー・トラッカ・ノードとして働くロード・バランサ・ノード110につき学習することができる。入口ノードは、ロード・バランサ実装内の、したがってコンシステント・ハッシュ・リング内のメンバー数の変化につき構成サービス122をモニターすることができる。入口ノードがクライアント160からのパッケットを受け取りそのパケットに対するマッピングを有していないときに、この入口ノードはコンシステント・ハッシュ関数を用いてどのフロー・トラッカ・ノードがパケットにサービスすべきかを決定することができる。少なくともいくつかの実施形態では、ハッシュ関数への入力は、パケットからの(クライアント終点、パブリック終点の)ペアである。少なくともいくつかの実施形態では、入口ノードとフロー・トラッカ・ノードは、UDPメッセージを用いて通信する。
一次フロー・トラッカ・ノードが新たなパケット・フローの入口ノードからメッセージを受け取るとき、一次フロー・トラッカ・ノードはランダムにTCPシーケンス番号を決定し、二次フロー・トラッカ・ノードへ別のメッセージを転送する。二次フロー・トラッカ・ノードは、クライアントに対するTCP・SYN/ACKメッセージを生成する。両フロー・トラッカはクライアント接続終点ペアとTCPシーケンス番号を思い出し、メモリ圧力及び期限切れによって状態が除去されるまで、この情報を保持する。
一次フロー・トラッカ・ノードがTCP・ACKパケットを受信した入口ノードからメッセージを受け取るときに、一次フロー・トラッカ・ノードは認識されたTCPシーケンス番号がSYN/ACKパケット内に送られていた格納値と一致することを検証し、要請にサービスすべきサーバ・ノード130を選択し、そして、二次フロー・トラッカ・ノードへメッセージを転送する。二次フロー・トラッカ・ノードは、選択されたサーバ・ノード130上のロード・バランサ・モジュール132にメッセージを送って、サーバ・ノード130上のTCPスタックとの実際のTCP接続を開始し、その後、サーバ・ノード130からの認識応答を待つ。
二次フロー・トラッカ・ノードが、サーバ・ノード130上のロード・バランサ・モジュール132から接続認識を受け取るときに、両ノードのサーバ・ノード130に関連する情報を格納した、一次フロー・トラッカを通じた入口ノードへの逆向きのメッセージ・フローが起きる。これ以降、入口ノードに受信された追加のTCPパケットはサーバ・ノード130上のロード・バランサ・モジュール132に直接転送される。
ロード・バランサ・モジュール<->ロード・バランサ・ノードの通信
少なくともいくつかの実施形態では、すべてのロード・バランサ・モジュール132は、自身の終点を構成サービス122に登録し、ロード・バランサ・ノード層のメンバー数変化につき構成サービス122を絶えずモニターする。以下に、少なくともいくつかの実施形態によるロード・バランサ・モジュール132の機能につき説明する。
・接続公表:各サーバ・ノード130上のアクティブな接続(クライアント終点、パブリック終点)の組を、これらの接続に責任を負う一次及び二次の両フロー・トラッカ・ノード、ならびにこれらの接続に対するロード・バランサ・モジュール132のパケットを最後に送信した入口ノードに、定期的にまたは不定期に公表する。この接続公表機能は、責任のあるロード・バランサ・ノード110での接続状態のリースを更新する。
・ロード・バランサ層のメンバー数変化のモニター:メンバー数が変化したならば、ロード・バランサ・モジュール132は、この変化情報を用いて現在接続に責任を負っているロード・バランサ・ノードにアクティブな接続を直ちに送ることができる。
分散型ロード・バランシング・システム内のパケット・フロー:詳細
分散型ロード・バランシング・システムは多数のロード・バランサ・ノード110を含むことができる。少なくともいくつかの実施形態では、分散型ロード・バランシング・システム内の各ロード・バランサ・ノード110は、サーバ134へのクライアント160接続に対するフロー・トラッカ・ノード、出口ノード及び入口ノードの役割を果たすことができる。分散型ロード・バランシング・システムはまた、各サーバ・ノード130上にロード・バランサ・モジュール132を含むこともできる。
図10A〜10Gは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システム内のパケット・フローを示す。図10A〜10Gでは、ロード・バランサ・ノード110間で交換されたパケット及びロード・バランサ・ノード110とサーバ・ノード130との間で交換されたパケットは、UDPメッセージまたはUDPカプセル化クライアントTCPパケットのどちらかである。少なくともいくつかの実施形態では、クライアントTCPパケットは、境界ルータ102へのトランシット及び境界ルータ102からのトランシットにおいてロード・バランサ・ノード110の北側でネットワーク100上にデカプセル化された形でのみ存在できる(図1参照)。図10A〜10Gで実線矢印はTCPパケットを表す一方、点線矢印はUDPパケットを表すことに留意されたい。
少なくともいくつかの実施形態では、分散型ロード・バランシング・システムは、単一のロード・バランサ・ノード110が故障した際に、確立されている接続を保つように試みることができる。少なくともいくつかの実施形態では、一次フロー・トラッカ・ノードと二次フロー・トラッカ・ノードの接続詳細を複製して、これらのノードのどちらかが故障すれば、残りのフロー・トラッカ・ノードによって接続のクライアント->サーバのマッピングが回復できるようにすることで、これを実現することができる。少なくともいくつかの実施形態では、ノード故障の際にいくらかのパケット損失が生じ得るが、しかし、クライアント/サーバのTCPパケット再送信によって失われたパケットを回復することができる。
クライアントからのTCP接続はそれぞれTCPフローと呼ぶことができ、クライアントIPアドレス、クライアント・ポート、サーバ(パブリック)IPアドレス及びサーバ・ポートから成る4要素の組により一意的に識別される。この識別子は、クライアント終点とパブリック終点のペアを示すCPまたはCcPpと短縮することができる。任意の与えられたTCPフロー(またはCPペア)に関連するパケットは、上流のエッジ・ルータ104からのハッシュ化等コスト多重パス(ECMP)フロー分布のせいで、入口サーバ112として作動する任意のロード・バランサ・ノード110に現れることができる。しかし、TCPフローのパケットは一般的に、TCPフローの向きを変えるリンクまたはロード・バランサ・ノード110の故障がなければ、同じロード・バランサ・ノード110に到着し続けることができる。上流のルータ104からのTCPフローのパケットを受信するロード・バランサ・ノード110は、TCPフローの入口ノードと呼ばれる。
少なくともいくつかの実施形態では、コンシステント・ハッシングを用いて、パケットがTCPフローの入口ノードとして働くロード・バランサ・ノード110に到着するときにこの入口ノードがどのロード・バランサ・ノード110がTCPフローの状態を含む(すなわち、フロー・トラッカ・ノードである)のかを判断することができるようにする。CPペアを入口ノードによってコンシステント・ハッシュ・リング内にハッシングして、どのロード・バランサ・ノード110がTCPフローに関する状態を維持する責任があるのかを判断することができる。このノードはTCPフローの一次フロー・トラッカとして働く。コンシステント・ハッシュ・リング内のサクセサ・ノードはTCPフローの二次フロー・トラッカとして働く。
少なくともいくつかの実施形態では、すべてのロード・バランサ・ノード110が入口ノード、一次フロー・トラッカ・ノード及び二次フロー・トラッカ・ノードの働きをすることができる。TCPフローのコンシステント・ハッシングの結果に応じて、TCPフローの入口ノードとして働くロード・バランサ・ノード110がTCPフローの一次または二次のフロー・トラッカ・ノードとして働くこともできる。しかし、少なくともいくつかの実施形態では、異なる物理的なロード・バランサ・ノード110が、TCPフローの一次フロー・トラッカ及び二次フロー・トラッカの役割を果たす。
接続を確立させること
図10Aを参照すると、クライアント160からの新たな接続がクライアントTCP同期(SYN)パケットによって引き起こされ得る。ロード・バランサ・ノード110はSYNパケットを受信した際に、サーバ・ノード130との接続を実際に確立させない、また、これらは、サーバ・ノード130を直ちに選択して接続を受け取ることもしない。代わりに、ロード・バランサ・ノード110は、クライアントのSYNパケットから関連データを格納し、まだ選択されていないサーバ・ノード130の代わりにSYN/ACKパケットを生成する。図10Cを参照すると、一旦クライアント160がTCP3方向ハンドシェイク内の第一のACKパケットに応答すると、ロード・バランサ・ノード110はサーバ・ノード130を選択し、サーバ・ノード130の等価SYNパケットを生成し、サーバ・ノード130と実際のTCP接続を確立しようと試みる。
再度、図10Aを参照すると、TCPフローの入口サーバ112として働くロード・バランサ・ノード110でクライアントSYNパケットを受信した際に、入口サーバ112はSYNパケットからデータ・フィールドを抽出し、TCPフローの一次フロー・トラッカ116Aにデータを転送する。一次フロー・トラッカ116Aはデータを、例えば、ハッシュ・テーブルに格納し、最初のTCPシーケンス番号(TCP接続のサーバ側の)を生成し、同じデータを二次フロー・トラッカ116Bに転送する。二次フロー・トラッカ116Bは、クライアント160の、このサーバTCPシーケンス番号を含むSYN/ACKパケットを作製する。
図10Aで、入口サーバ112、一次フロー・トラッカ116A及び二次フロー・トラッカ116Bの役割がそれぞれ、異なるロード・バランサ・ノード110によって果たされる。しかし、いくつかの事例では、TCPフローの入口サーバ112として働くロード・バランサ・ノード110は、TCPフローの一次フロー・トラッカ116Aまたは二次フロー・トラッカ116Bとして働く(しかし、両方ではない)のと同じノード110となることができる。パケット・フローの入口サーバ112がこのフローのフロー・トラッカ116と同じノード110上にあることができるのは、エッジ・ルータ104がフロー単位ハッシュ化多重パス経路指定技法(例えば、ECMP経路指定技法)によって擬似ランダムに入口サーバ112を選択し、一方で、パケット・フローのフロー・トラッカ116はパケット・フローのアドレス情報に適用されたコンシステント・ハッシュ関数によりコンシステント・ハッシュ・リング上に決定されるという理由からである。パケット・フローの入口サーバ112がパケット・フローのフロー・トラッカ116と同じノード110上にあるならば、SYNパケットからのデータを、入口サーバ112を実装するノード110から他のフロー・トラッカ116ノード110に転送するだけでよい。例えば、図10Bでは、一次フロー・トラッカ116AがTCPフローの入口サーバ112と同じロード・バランサ・ノード110A上にある一方で、二次フロー・トラッカ116Bが異なるロード・バランサ・ノード110B上にあり、したがって、SYNパケットからのデータは、(フロー・トラッカ116Aによって)ノード110Aからロード・バランサ・ノード110B上の二次フロー・トラッカ116Bに転送される
図10Cを参照すると、この入口サーバ112は、非SYNパケットが入口サーバ112に到着するときに、どのサーバ・ノード130にパケットを転送するのかを知っているか知らないのかのどちらかである。TCPフローの入口サーバ112に到着すべき第一の非SYNパケットは、TCPの3方向ハンドシェイク内の第一TCP認識(ACK)パケット(できるだけ後続のデータ・パケット)であるべきであり、このTCP認識番号フィールドは図10AのSYN/ACKパケットに送られたサーバ・シーケンス番号(+1)と一致する。入口サーバ112がそのサーバ・マッピングを持っていない非SYNパケットを受信するとき、入口サーバ112は、シーケンス番号などのACKパケットからの情報を含むか、またはその代わりにACKパケット自体を含んだメッセージをTCPフローの一次フロー・トラッカ116Aに転送する。少なくともいくつかの事例では、一次フロー・トラッカ116AはTCPフローの保存されたデータを引き出し、認識されたシーケンス番号(+1)がSYN/ACKパケット内のクライアント160に送られていた値と一致することを確認する。一次フロー・トラッカは、その後、TCPフローのサーバ・ノード130を選択し、以前に格納したTCPフローのデータ、サーバ・シーケンス番号、及びその選択されたサーバ・ノード130上のロード・バランサ・モジュール132のIPアドレスを含む別のメッセージを二次フロー・トラッカ116Bに転送する。二次フロー・トラッカ116Bはサーバ・シーケンス番号を確認し、情報を記録し、作製されたSYNメッセージを選択されたサーバ・ノード130上のロード・バランサ・モジュール132に送る。今や、TCPフローのCP終点ペアが、ロード・バランサ・モジュール132/サーバ・ノード130にマッピングされる。サーバ・ノード130上のロード・バランサ・モジュール132は、作製されたSYNメッセージを二次フロー・トラッカ116Bから受信するとき、サーバ・ノード130上のサーバ134の正当なTCP・SYNパケットを作製する責任を負う。SYNパケットを作製する際に、ソースIPアドレスは、サーバ134がクライアント160から直接のTCP接続要請を受け取ったと信じるように、クライアント160の実際のIPアドレスで占められる。ロード・バランサ・モジュール132は、TCPフローに関連する詳細を、例えば、ローカル・ハッシュ・テーブルに格納し、TCP・SYNパケットをサーバ134に送信する(例えば、サーバ134のLinuxカーネルにSYNパケットを注入する)。
図10Cでは、入口サーバ112、一次フロー・トラッカ116A及び二次フロー・トラッカ116Bの役割はそれぞれ、相異なるロード・バランサ・ノード110によって果たされる。しかし、いくつかの事例では、TCPフローの入口サーバ112として働くロード・バランサ・ノード110は、TCPフローの一次フロー・トラッカ116Aまたは二次フロー・トラッカ116Bとして働く(しかし、両方ではない)同じノード110になるであろう。例えば、図10Dでは、二次フロー・トラッカ116Bが、TCPフローの入口サーバ112と同じロード・バランサ・ノード110A上にある一方で、一次フロー・トラッカ116Aは異なるロード・バランサ・ノード110B上にある。
図を10E参照すると、サーバ134(例えば、Linuxカーネル)は、ロード・バランサ・モジュール132にも傍受されるSYN/ACKパケットに応答する。このSYN/ACKパケットは、生成されたSYN/ACK内のクライアント160に二次フロー・トラッカ116Bからもともと配られたものとは異なるTCPシーケンス番号を含むことができる(図10A参照)。ロード・バランサ・モジュール132は、着信パケット及び発信パケットにシーケンス番号デルタを適用する責任を負う。サーバ134からのSYN/ACKパケットもまた、ロード・バランサ・モジュール132から二次フロー・トラッカ116Bに戻るメッセージ(例えば、UDPメッセージ)を発して選択されたサーバ・ノード130/ロード・バランサ・モジュール132/サーバ134への接続が成功したことを示す。このメッセージを受信した際に、二次フロー・トラッカ116Aは、委託されたように、クライアント160とサーバ134間のクライアント終点及びパブリック終点ペア(CP)のマッピングを記録することができ、同様なメッセージをやはりCPマッピングを記録する一次フロー・トラッカ116Aに送信する。一次フロー・トラッカ116Aは、その後、CPマッピング・メッセージを入口サーバ112に転送することができ、これは、入口サーバ112に、接続のいかなるバッファされたデータ・パケットもカプセル化データ・パケットとしてサーバ・ノード130上のローカル・ロード・バランサ・モジュール132へ転送させる。
図10Fを参照すると、接続のCPマッピングは入口サーバに知られており、接続用の入口サーバ112が受信した着信TCPパケットは、カプセル化でき(例えば、UDPにより)、カプセル化データ・パケットとしてサーバ・ノード130上のローカル・ロード・バランサ・モジュール132に直接転送され得る。ロード・バランサ・モジュール132はデータ・パケットをデカプセル化し、例えば、カーネルのTCPスタック上にTCPパケットを注入することによって、サーバ・ノード130上のサーバ134にTCPパケットを送信する。サーバ134からのアウトバウンド・パケットは、サーバ・ノード130上のロード・バランサ・モジュール132によって傍受され、カプセル化され(例えば、UDPにより)、そして、ロード・バランサ・モジュール132がこの接続の出口サーバ114としてランダムに選択した任意のロード・バランサ・ノード110に転送される。出口サーバ114はパケットをデカプセル化し、デカプセル化されたパケットをクライアント116に送信する。選択されたロード・バランサ・ノード110の出口機能はステートレスであり、それゆえ、出口サーバとして働くロード・バランサ・ノード110の故障の際に異なるロード・バランサ・ノード110を接続の出口サーバ114として選択することができる。しかし、一般的には、同じロード・バランサ・ノード110が接続の間の出口サーバ114として用いられて、アウトバウンド・パケットの再配列が縮小または除去される。
図10Gを参照すると、少なくともいくつかの実施形態では、一次フロー・トラッカ116Aによって選択されたサーバ・ノード130Aの上のロード・バランサ・モジュール132A(図10C参照)は、自身が過負荷であると判断したならば、二次フロー・トラッカ116B(図10C参照)から受け取った作製されたSYNメッセージを拒絶する選択肢を有している。少なくともいくつかの実施形態では、作製されたSYNメッセージは寿命(TTL)値すなわち拒絶の最大数を考慮したカウンタを含む。少なくともいくつかの実施形態では、このTTL値がゼロになるならば、ロード・バランサ・モジュール132Aは接続を受理するかまたは接続を止めて負荷を減らすかのどちらかを行うことができる。ロード・バランサ・モジュール132Aが接続を拒絶することを決定するならば、それはTTL値を減少させ、二次フロー・トラッカ116Bに拒絶メッセージを送る。二次フロー・トラッカ116BはCPマッピングをリセットし、同じことをするために一次フロー・トラッカ116Aに開放メッセージを送る。一次フロー・トラッカ116Aは、別のサーバ・ノード130B上の新たなロード・バランサ・モジュール132Bを選び、そして、新たな標的メッセージを、新たに作製したSYNメッセージを新たに選ばれたロード・バランサ・モジュール132Bに送る二次フロー・トラッカ116Bに送る。パケット停止の結果このシーケンス減衰が終了し得るが、しかし、クライアント160からの再送信によってロード・バランサ・モジュール選択プロセスを一次フロー・トラッカ116Aで再度開始させることができ、この一次フロー・トラッカ116Aは、必ずではないが、作製されたSYNパケットの以前の拒絶を学習していないならば、接続に同じロード・バランサ・モジュール132を選択することができることに留意されたい。
少なくともいくつかの実施形態では、TTLカウンタを用いてサーバ・ノード130に連続的に接続要請を送ること(これは、例えば、サーバ・ノード130がすべて使用中ならば起こり得る)を防ぐことができる。少なくともいくつかの実施形態では、ロード・バランサ・モジュール132がそれぞれのサーバ・ノード130の代わりに接続要請を拒絶する度に、ロード・バランサ・モジュール132はTTLカウンタを減少させる。フロー・トラッカ・ノード116は、TTLカウンタをモニターすることができ、また、TTLカウンタがゼロ(またはある指定された閾値を超える値)でない限り、別のサーバ・ノード130を選択して再度試みることができる。TTLカウンタがゼロ(または指定された閾値を超える値)になるならば、接続要請は停止され、フロー・トラッカ・ノード116はその接続のサーバ・ノード130のうちの選択された1つに更なる接続要請を試みない。少なくともいくつかの実施形態では、それぞれのクライアント160にエラー・メッセージを送ることができる。
少なくともいくつかの実施形態では、分散型ロード・バランサ・システムが多数のパブリックIPアドレスを支援する。これによって、クライアント160が同じクライアント・ポート番号から2つの異なるパブリックIPアドレスへの2つのTCP接続を開始することができる。これらのTCP接続は、クライアント160の視点とは異なるが、しかし、内部では、分散型ロード・バランサは、同じサーバ・ノード130への接続をマッピングする可能性があり、衝突に帰着するはずである。少なくともいくつかの実施形態では、ロード・バランサ・モジュール132は、図10C、10Dに示すように二次フロー・トラッカ116Bから作製されたSYNパケットを受け取る際に、可能性のある衝突を検出し対処するためにアドレス情報を自身のアクティブな接続と比較して、接続が衝突を起こすようであれば、図10Gに示すように接続要請を拒絶することができる。
ロード・バランサ・ノードの故障及び追加の取り扱い
多くの従来のロード・バランサでは、いくつかのまたはすべての既存の接続がロード・バランサの故障の際に失われる。少なくともいくつかの実施形態では、分散型ロード・バランシング・システムは、単一のロード・バランサ・ノード110の故障の際には、少なくとも確立している接続のうちのいくつかを維持して、接続を介して接続が正常に完了するまでクライアントとサーバがパケットを交換し続けることができるようにすることができる。加えて、この分散型ロード・バランシング・システムは、故障時に確立される過程にあった接続サービスを維持することができる。
分散型ロード・バランシング・システムの少なくともいくつかの実施形態では、単一のロード・バランサ・ノード110の故障の際に既存のクライアント接続を回復することができる故障回復プロトコルを実装することができる。しかし、多数のロード・バランサ・ノード110の故障はクライアント接続の喪失に帰着し得る。少なくともいくつかの実施形態では、クライアント160とサーバ134との間のTCP再送信をロード・バランサ・ノード110の故障に続く回復手段として使用することができる。
ロード・バランサ・ノード110の潜在的な故障に加えて、新たなロード・バランサ・ノード110が分散型ロード・バランサ・システムに加えられる場合がある。これらの新たなノード110は、ロード・バランサ層に、したがってコンシステント・ハッシュ・リングに加えられることができる。そして、既存のクライアント接続に関するロード・バランサ・ノード110の役割は、この変化により必要に応じて調整することができる。
少なくともいくつかの実施形態では、各接続が確立される(例えば、図10A〜10G参照)につれて、接続状態情報が、ハッシュ関数入力として例えば、(クライアントIP:ポート、パブリックIP:ポート)の組を用いるコンシステント・ハッシュ・アルゴリズムを用いて決定され得る一次及び二次フロー・トラッカと呼ばれる2つのロード・バランサ・ノード110に通される。単一のロード・バランサ・ノード110の故障の際には、少なくとも1つの残存するロード・バランサ・ノード110が、コンシステント・ハッシュ関数を介してマッピングされ続け、パケットを選択された接続用サーバ・ノード130に向けるのに必要な接続状態情報を含むことができる。加えて、ロード・バランサ・ノード110をコンシステント・ハッシュ・リングに追加する事例では、接続状態情報を適切なフロー・トラッカに対してリフレッシュすることができる。
図11A〜11Dは、少なくともいくつかの実施形態による、ロード・バランサ・ノードのコンシステント・ハッシュ・リング内のメンバー数に影響を及ぼす事象の取り扱いを示す。これらの事象には、限定はされないが、新たな一次フロー・トラッカ・ノードを追加すること、新たな二次フロー・トラッカ・ノードを追加すること、一次フロー・トラッカ・ノードの故障及び二次フロー・トラッカ・ノードの故障が含まれ得る。
図11Aは、コンシステント・ハッシュ・リングに新たな一次フロー・トラッカ・ノードを追加する取り扱いを示す。図11Aの上列は、1つまたは複数のクライアント接続の一次フロー・トラッカとしてのフロー・トラッカ116A及び同じ接続の二次フロー・トラッカとしてのフロー・トラッカ・ノード116Bを示す。図11Aの下列では、新たなフロー・トラッカ・ノード116Cが追加され、クライアント接続の一次フロー・トラッカとなる。フロー・トラッカ・ノード116A(以前は、一次フロー・トラッカ)が二次フロー・トラッカになる一方、フロー・トラッカ・ノード116B(以前は、二次フロー・トラッカ)がコンシステント・ハッシュ・リング内の次のフロー・トラッカになる。フロー・トラッカ116A及び116Bが維持したクライアント接続の状態情報を新たな一次フロー・トラッカ116Cに提供することができる。加えて、フロー・トラッカ116Bは、二次フロー・トラッカの役割で以前に追跡していた接続を「忘れる」ことができる。
図11Bは、コンシステント・ハッシュ・リングに新たな二次フロー・トラッカ・ノードを追加する取り扱いを示す。図11Bの上列は、1つまたは複数のクライアント接続の一次フロー・トラッカとしてのフロー・トラッカ116A及び同じ接続の二次フロー・トラッカとしてのフロー・トラッカ・ノード116Bを示す。図11Bの下列では、新たなフロー・トラッカ・ノード116Cが追加され、クライアント接続の二次フロー・トラッカとなる。フロー・トラッカ・ノード116Aは接続の一次フロー・トラッカとして残る一方、フロー・トラッカ・ノード116B(以前は、二次フロー・トラッカ)はコンシステント・ハッシュ・リング内の次のフロー・トラッカになる。フロー・トラッカ116A及び116Bが維持したクライアント接続の状態情報を新たな二次フロー・トラッカ116Cに提供することができる。加えて、フロー・トラッカ116Bは、二次フロー・トラッカの役割で以前に追跡していた接続を「忘れる」ことができる。
図11Cはコンシステント・ハッシュ・リング内の一次フロー・トラッカ・ノードの故障の取り扱いを示す。図11Cの上列は、1つまたは複数のクライアント接続の一次フロー・トラッカとしてのフロー・トラッカ116A、同じ接続の二次フロー・トラッカとしてのフロー・トラッカ・ノード116B及びコンシステント・ハッシュ・リング内の次のフロー・トラッカとしてのフロー・トラッカ・ノード116Cを示す。図11Cの下列では、一次フロー・トラッカ・ノード116Aが故障している。フロー・トラッカ・ノード116Bが接続の一次フロー・トラッカとなる一方、フロー・トラッカ・ノード116Cは接続の二次フロー・トラッカとなる。クライアント接続の状態情報はフロー・トラッカ116Bに維持され、新たな二次フロー・トラッカ116Cに提供され得る。
図11Dはコンシステント・ハッシュ・リング内の二次フロー・トラッカ・ノードの故障の取り扱いを示す。図11Dの上列は、1つまたは複数のクライアント接続の一次フロー・トラッカとしてのフロー・トラッカ116A、同じ接続の二次フロー・トラッカとしてのフロー・トラッカ・ノード116B及びコンシステント・ハッシュ・リング内の次のフロー・トラッカとしてのフロー・トラッカ・ノード116Cを示す。図11Dの下列では、二次フロー・トラッカ・ノード116Bが故障している。フロー・トラッカ・ノード116Aは接続の一次フロー・トラッカとして残る一方、フロー・トラッカ・ノード116Cは接続の二次フロー・トラッカとなる。クライアント接続の状態情報はフロー・トラッカ116Bに維持され、新たな二次フロー・トラッカ116Cに提供され得る。
少なくともいくつかの実施形態では、サーバ・ノード130上のロード・バランサ・モジュール132は、ロード・バランサ・ノード110に接続公表を行なう。少なくともいくつかの実施形態では、接続公表は、定期的に(例えば、1秒に一回)または非定期にサーバ・ノード130からの現在の接続状態情報をフロー・トラッカ・ノード及び入口ノードとして働くロード・バランサ・ノード110に公表する。このことは、接続の一次と二次の両フロー・トラッカ・ノードに対する接続マッピングをリフレッシュまたは回復させる働きをする。少なくともいくつかの実施形態では、例えば、図11A〜11Dに示すように、ロード・バランサ・モジュール132はフロー・トラッカのメンバー数変化を検出することができる。これを受けて、ロード・バランサ・モジュール132は、接続公表を行って一次及び二次のフロー・トラッカ・ノード内にメンバー数が変化したときに接続に対して変わったかもしれない接続状態情報を読み込むことができる。接続公表は、複数のロード・バランサ・ノードの故障の際に、少なくともいくつかの確立された接続を回復させることができることに留意されたい。
故障に関連したメッセージ・フロー
少なくともいくつかの実施形態では、一次及び二次のフロー・トラッカ・ノード間のプロトコルは、補正機能または同期機能を含むことができる。例えば、図11Aを参照すると、新たな一次フロー・トラッカ・ノード116Cがコンシステント・ハッシュ・リングに加わるときに、この新たなノード116Cはいくらかの数(約1/N)の接続のコンシステント・ハッシュのキー空間の権利を主張し、エッジ・ルータ104からこれらの接続に関するトラフィックの受け取りを開始することができる。しかし、新たな一次フロー・トラッカ・ノード116Cは、これらの接続に対して格納されたいかなる状態も有していないので、各パケット上でパケットがあたかもクライアント160から受け取られた最初のパケットであるかのように動作することができる。一次フロー・トラッカは、SYNパケット(例えば、図10A参照)に応じてサーバのTCPシーケンス番号を生成し、かつ、クライアント160からの最初のACKパケット(例えば、図1参照)に応答してサーバ・ノード130を選択する責任を負う。これらの生成された値は、以前の一次フロー・トラッカ(図11Aのフロー・トラッカ・ノード116A)によって選ばれた値と一致しない場合がある。しかし、少なくともいくつかの実施形態では、コンシステント・ハッシュ・アルゴリズムは前の一次フロー・トラッカ(図11Aのフロー・トラッカ・ノード116A)に二次フロー・トラッカの役割を割り当て、このフロー・トラッカは以前格納していた接続状態を依然として保持している。したがって、少なくともいくつかの実施形態では、二次フロー・トラッカ(図11Aのフロー・トラッカ・ノード116A)は、一次フロー・トラッカ116Cから受け取った情報に矛盾を検出したときに、一次フロー・トラッカ116Cに最新版メッセージを逆に送ってフロー・トラッカとして働く2つのロード・バランサ・ノード110を同期させることができる。コンシステント・ハッシュ・リングのメンバー数のその他の変化の後にも同様な方法を用いてフロー・トラッカを同期させることができる。
ロード・バランサ・モジュールの詳細
少なくともいくつかの実施形態では、ロード・バランサ・モジュール132は、サーバ・ノード130それぞれの上にある分散型ロード・バランサ・システムのコンポーネントである。ロード・バランサ・ノード132の役割には、限定はされないが、ロード・バランサ・ノード110から受信したパケットをデカプセル化し、デカプセル化されたパケットをサーバ・ノード130上のサーバ134に送ること、及び、サーバ134からの発信パケットをカプセル化し、カプセル化されたパケットをロード・バランサ・ノード110に送信することが含まれる。
少なくともいくつかの実施形態では、入口サーバ112として働くロード・バランサ・ノード110からサーバ・ノード130上のロード・バランサ・モジュール132への着信パケットは、実際のクライアント・データ・パケットをカプセル化するステートレス・プロトコル(例えば、UDP)パケットである。各カプセル化クライアント・データ・パケットは、ソース・アドレスとしてそれぞれのクライアント160の元のクライアントIPポート及び宛先アドレスとしてサーバ134のパブリックIPポートを有する。ロード・バランサ・モジュール132はクライアント・データ・パケットからカプセルを剥ぎ、例えば、このパケットをローカルホストのTCPフローに転送することによりサーバ・ノード130上のそれぞれのサーバ134にパケットを送信する。
少なくともいくつかの実施形態では、サーバ134から出口サーバ114として働くロード・バランサ・ノード110への発信パケットは、発信IPパケットをカプセル化するステートレス・プロトコル(例えば、UDP)パケットである。ロード・バランサ・モジュール132は発信IPパケットをカプセル化し、ファブリック120を介してこのカプセル化パケットを出口サーバ114に送信する。各カプセル化発信IPパケットは、ソース・アドレスとしてサーバ134のパブリックIP:ポート及び宛先アドレスとしてそれぞれのクライアント160のクライアントIP:ポートを有する。
ロード・バランサ・モジュールの機能
少なくともいくつかの実施形態では、サーバ・ノード130上のロード・バランサ・モジュール132の機能は、限定はされないが、以下のうちの1つまたは複数の機能を含むことができる。
・ロード・バランサ・ノード110からの、例えば、接続を扱う入口サーバ112からクライアント160までの、UDPトンネルを終了させること。これには、入口サーバ112から受信した着信クライアント・データ・パケットからUDPカプセル化を剥ぐことが含まれる。
・接続の発信トラフィックを受信する出口サーバ114を選択すること。
・それぞれのサーバ134への接続上の発信IPパケットを傍受し、接続の発信IPパケットをカプセル化し、出口サーバ114にカプセル化されたパケットを送信すること。
・着信パケット及び発信パケット内のシーケンス番号をマングリングして、フロー・トラッカ・ノード116がSYN/ACKをクライアント160に送信したときにこのシーケンス番号がフロー・トラッカ・ノード116によって生成されるシーケンス番号とつながるようにすること。
・それぞれのサーバ134の接続を受け入れるか、または拒絶するかの決定を、例えば、それぞれのサーバ134の現在の負荷を示す1つまたは複数の指標に基づいて、行うこと。
・クライアントIP:ポート・アドレスからそれぞれのサーバ134への接続を検出し、クライアントIP:ポート・アドレスに対するアクティブな接続が存在するならば、衝突を回避するために同じクライアントIP:ポート・アドレスからそれぞれのサーバ134への接続を拒絶すること。
・接続を追跡すること及び接続を公表すること。
ロード・バランサ・モジュール構成の情報
少なくともいくつかの実施形態では、各ロード・バランサ・モジュール132は、限定はされないが、その構造に対する以下の情報の組のうちの1つまたは複数の組を獲得し、ローカルに格納することができる。
一組のロード・バランサ・ノード110の終点
ロード・バランサ・モジュール132がサービスを提供する一組の有効なパブリックIPアドレス
それぞれのサーバ134が着信接続を受け入れるポート数
少なくともいくつかの実施形態では、この情報は、図1に示すような分散型ロード・バランサ・システムの構成サービス122コンポーネントにアクセスするか尋ねることにより、得られるか、更新することができる。いくつかの実施形態では、情報を得る他の方法を用いることもできる。
ロード・バランサ・モジュールのパケットの取り扱い
下記に、少なくともいくつかの実施形態による、インバウンド・トラフィック及びアウトバウンド・トラフィックに対するロード・バランサ・モジュール132の取り扱いにつき説明する。少なくともいくつかの実施形態では、インバウンド・データ・パケットがロード・バランサ・モジュール132によって受信されるとき、データ・パケットはUDPパケットからデカプセル化され、デカプセル化されたTCPパケット内の宛先アドレスが構成された1組の有効なパブリックIPアドレスにつき最初に確認される。一致しないならば、このパケットは除かれるかまたは無視される。少なくともいくつかの実施形態では、ロード・バランサ・モジュール132は、コンスタント・デルタによってTCPヘッダ内のシーケンス番号を調整してこのシーケンス番号がSYN/ACKパケットをクライアント160に送ったフロー・トラッカ・ノード116によって生成されランダムに選ばれたシーケンス番号と一致するようにすることができる。ロード・バランサ・モジュール132は、〔クライアント:パブリック〕終点から〔クライアント:サーバ〕終点までのマッピングを内部状態として記録する。
少なくともいくつかの実施形態では、サーバ134からのアウトバウンドTCPパケットに対して、ロード・バランサ・モジュール132は、先ず、その内部状態をチェックしてこのパケットがロード・バランサ・モジュールが管理しているアクティブな接続に対するものかどうかを判断する。もし、それがそうでなければ、ロード・バランサ・モジュール132はパケットを単に通過させる。もし、それがそうであるならば、ロード・バランサ・モジュール132は発信TCPパケットを例えばUDPによってカプセル化し、カプセル化されたパケットをこの接続の出口サーバ114として選ばれたロード・バランサ・ノード110に転送する。少なくともいくつかの実施形態では、ロード・バランサ・モジュール134は発信TCPパケット内のシーケンス番号をコンスタント・デルタによって調整してこのシーケンス番号がSYN/ACKパケットをクライアント160に送信したフロー・トラッカ・ノード116によって生成されたシーケンス番号とつながるようにすることができる。
接続の追跡
少なくともいくつかの実施形態では、各サーバ・ノード130上のロード・バランサ・モジュール132は、それぞれのサーバ134へのすべてのアクティブな接続の接続詳細を含むハッシュ・テーブルを管理する。少なくともいくつかの実施形態では、ハッシュ・テーブルのキーは(クライアントIP:ポート、パブリックIP:ポート)の組である。少なくともいくつかの実施形態では、各クライアント接続の接続状態は、限定はされないが、以下のうちの1つまたは複数のものを含むことができる。
・クライアントIP:ポート
・パブリックIP:ポート
・フロー・トラッカ・ノード116によって提供される最初のサーバTCPシーケンス番号
・サーバTCPシーケンス番号デルタ
・元の一次フロー・トラッカのIPアドレス
・元の二次フロー・トラッカのIPアドレス
・最後の検出された入口サーバ112のIPアドレス。
・このエントリーの認証有効時間
・最も長く使用されていない(LRU)/衝突インデックス
少なくともいくつかの実施形態では、各ロード・バランサ・モジュール132は、すべてのアクティブなクライアント接続の一次及び二次のフロー・トラッカ・ノードへの接続公表メッセージを生成する。少なくともいくつかの実施形態では、Linuxカーネルが接続の追跡を止めるまで/proc/net/tcpのコンテントがこれらの接続がフロー・トラッカ・ノードに公表され続けられるように、ロード・バランサ・モジュールのハッシュ・テーブルのアクティブな接続でスキャンされ傍受される。接続公表については、本明細書で後ほど詳細に論じる。
シーケンス番号のマングリング
以前に説明したように、少なくともいくつかの実施形態では、ロード・バランサ・ノード110はサーバ134の代わりにクライアント160のSYNパケットに応答してSYN/ACKパケットを生成する。クライアント160がACKパケット(TCP3方向ハンドシェイク)を送信した後にだけ、ロード・バランサ・モジュール110は、サーバ・ノード130上のロード・バランサ・モジュール132に任意のデータを送る。クライアント接続を確立するように最初に指示されたときに、ロード・バランサ・モジュール132はSYNパケットをローカルに作製してサーバ・ノード130上のサーバ134とTCP接続を開始し、サーバ134の対応するSYN/ACKパケットを傍受する。一般的に、サーバ134(例えば、サーバ・ノード130上のLinuxカーネル)は、クライアントがSYN/ACKパケット内でロード・バランサ・ノード110から受け取ったものとは完全に異なるTCPシーケンス番号を選択する。したがって、少なくともいくつかの実施形態では、ロード・バランサ・モジュール132は、クライアント160とサーバ134との間のTCP接続でのすべてのパケット内のシーケンス番号を訂正することができる。少なくともいくつかの実施形態では、ロード・バランサ・モジュール132は、ロード・バランサ・ノード110によって生成されたシーケンス番号と、サーバ134によって生成されたシーケンス番号間の差を計算し、この差をデルタ値としてTCP接続のハッシュ・テーブルのエントリに格納する。接続中のクライアント160から着信データ・パケットが到着するとき、TCPヘッダはサーバ134によって使用されるシーケンス番号とつながらない認識番号を含むであろう。したがって、ロード・バランサ・モジュール132はTCPヘッダ内のシーケンス番号値からデルタ値(例えば、2の補数を使用して)を差し引く。ロード・バランサ・モジュールは、また、接続中のサーバ134からクライアント130までのアウトバウンド・パケット内のシーケンス番号へのデルタ値の加算もおこなう。
分散型ロード・バランサ・システムにおける健全性のチェック
分散型ロード・バランサ・システムの少なくともいくつかの実施形態では、各ロード・バランサ・ノード110には、少なくとも以下の理由により、ロード・バランサ実装時に健全なメンバー(すなわち、健全なロード・バランサ・ノード110及びサーバ・ノード130)のコンシスタントな視野を必要とする。
・ロード・バランシング:ロード・バランサ・ノード110は、サーバ・ノード130の故障を検出し、クライアント・トラフィックを受信することができる健全なサーバ・ノード130の組に集まる必要がある。
・分散状態の管理:ロード・バランサは、複数のロード・バランサ・ノード110にわたって状態が共有/複製されている分散型システム(例えば、コンシステント・ハッシング・メカニズムによる)である。クライアント・トラフィックを適切に取り扱うために、各ロード・バランサ・ノード110は、ロード・バランサ実装時に健全なメンバー・ノード110の最終的にコンシスタントな視野を有する必要がある。
これを達成するために、分散ロード・バランサ・システムの少なくともいくつかの実施形態では、ロード・バランサ実装時のノードをモニターし、できるだけ早く健全でないノードを検出する健全性チェック・プロトコルの実施形態を実装することができる。健全性チェック・プロトコルは、ロード・バランサ実装時のノード間で健全性情報を伝達することができ、また、ノードが一組の健全なノードに集まることができるようにする方法を提供することができる。加えて、健全性チェック・プロトコルは、ロード・バランサ実装時の健全/非健全なノード及び状態変化を報告するメカニズムを提供することができる。
少なくともいくつかの実施形態では、健全性チェック・プロトコルは、次の仮定の1つ以上に基づくことができるが、これに限定されない。
・ロード・バランサ実装時のすべてのノードが知られている。(すなわち、健全性チェック・プロトコルは、発見をすることができない)
・すべてのノード故障は、フェイル・ストップである。
・ノード間のすべてのメッセージはステートレス・プロトコル(例えば、UDP)メッセージであり、メッセージは脱落、遅延、重複、または破損する場合がある。メッセージの送達が保証されない。
少なくともいくつかの実施形態では、ロード・バランサ実装時のノード(例えば、ロード・バランサ・ノード110またはサーバ・ノード130)を、次の条件に基づいて健全であるとみなすことができる。
・ノードの全ての内部コンポーネントが、レディ状態(クライアント・トラフィックを処理する準備ができている)である。
・ノードの着信/送信ネットワーク・リンクが健全である(少なくともクライアント・トラフィックが流れるネットワーク・インターフェイス・コントローラ(NIC)に対して)。
図12は、少なくともいくつかの実施形態による、各ロード・バランサ・ノードが健全性チェックのインターバルにより行うことができる健全性チェック法の高レベルのフローチャートである。1000に示すように、例えば100ミリ秒ごとの各ロード・バランサのインターバルにおいて、各ロード・バランサ(LB)ノード110は、少なくとも他の1つのLBノード110及び少なくとも1つのサーバ・ノード130の健全性をチェックすることができる。1002に示すように、ロード・バランサ・ノード110は、健全性チェックより、ローカルに格納された健全性情報を更新することができる。1004に示すように、ロード・バランサ・ノード110は、さらに、少なくとも他の1つのロード・バランサ・ノード110をランダムに選択することができ、その健全性情報を選択したロード・バランサ・ノード110に送信することができる。少なくともいくつかの実施形態では、ノード110は、健全なロード・バランサ・ノード110のリストを、1つまたは複数のサーバ・ノード130、例えば、ノード110が健全性をチェックした同一のサーバ・ノード130に送信することもできる。図12の各要素については、次の論議で更に詳細に説明する。
少なくともいくつかの健全性チェック・プロトコルの実施形態では、ロード・バランサ・ノード110は、それ自身の健全性を、他のロード・バランサ・ノード110に表明しない。代わりに、他の1つまたは複数のロード・バランサ・ノード110が、このノード110の健全性をチェックすることができる。例えば、少なくともいくつかの実施形態では、各ロード・バランサ・ノード110は、健全性チェックのために他の1つまたは複数のノード110を定期的にまたは非定期にランダムに選択することができる。別の例として、少なくともいくつかの実施形態では、他の1つまたは複数のロード・バランサ・ノード110、例えば、コンシステント・ハッシュ・リングなどの整列したノード110のリスト上にある所定のロード・バランサ・ノード110の最近接の2つのロード・バランサ・ノード110は、それぞれ、その所定のノード110の健全性を定期的にまたは非定期にチェックすることができる。少なくともいくつかの実施形態では、ノード110の健全性チェックは、図23に図示するノード110上のNIC1114に送信する健全性についてのピングを用いることを含むことができる。少なくともいくつかの実施形態において、第1のノード110は、健全性チェックによって第2のノード110を健全であると決定する場合、ロード・バランサ・ノード110のローカルな健全性情報の中に蓄積する第2のノード110の鼓動カウンタを更新する(例えば、増加させる)ことができる。第1のノード110は、自身のローカルな健全性情報を、ロード・バランサ実装中の他の1つ以上のロード・バランサ・ノード110に、定期的にまたは非定期に送信する。これらのロード・バランサ・ノード110は、その情報に応じて、自身のローカルな健全性情報を(例えば、第2のノードの鼓動カウンタを増加させることによって)更新することができる。また、その更新したローカルな健全性情報を他の1つまたは複数のノード110に送信することができる。第2のノード110の鼓動情報を、ロード・バランサ実装時の他のノード110にこのように伝達することができる。第2のノード110が健全な限り、第2のノード110から到達可能な他のすべてのノード110は、このように、例えば1秒につき1回または10秒ごとに1回の一貫した基調に基づいて増加される第2のノード110の鼓動カウンタを見るべきである。第2のノード110の健全性をチェックするノード110が、第2のノード110を非健全であると検出する場合、健全性をチェックするノード110は、第2のノード110の鼓動を送信しない。さらに、ある時間の限度を超えた後に、ロード・バランサ実装時の他のノード110は、問題のノード110を非健全、または故障しているとみなす。
少なくともいくつかの実施形態において、ロード・バランサ・ノード110は、自身の内部状態の1つまたは複数の側面をチェックすることができる。また、そのノード110が何らかの理由で非健全であることを、自身が検出する場合、そのノード110は、その健全性をチェックする他のノード110からの健全性についてのピングに応答することを止めることができる。したがって、非健全なノード110の健全性をチェックするノード110は、このノード110を非健全であるとみなすことができるので、このノード110の代わりに鼓動の増加を伝達することができない。
健全性チェック・プロトコルの詳細
少なくともいくつかの実施形態において、健全性チェック・プロトコルには、鼓動カウンタ技法及びゴシップ・プロトコル技術を活用することができる。この健全性チェック・プロトコルは、2つの主要部分:健全性のチェック、及びゴシップ/故障の検出、を有するとみなすことができる。
健全性のチェック:ロード・バランサ実装時のすべてのロード・バランサ・ノード110は、定期的にまたは非定期に、実装された他の1つまたは複数のノード110の健全性をチェックすることができる。他の1つ以上のノードを決定する方法は、後で述べる。健全性のチェックの中核となる考え方は、あるノード110が、別のノード110の健全性をチェックして、その別のノード110が健全であると判断するならば、チェックを行うノード110が、その別ノード110の鼓動カウンタを増加させ、伝達することによって、その別のノード110が健全であると、主張することである。換言すれば、このノード110は、他のノードに対して自身の健全性を主張しない。代わりに、他の1つまたは複数のノード110が、ロード・バランサ実装時の各ノード110の健全性をチェックし、主張する。
ゴシップ/故障検出:少なくともいくつかの実施形態では、健全性チェック・プロトコルには、ロード・バランサ実装時に、そのメンバーであるロード・バランサ・ノード110の間にロード・バランサ・ノード110の健全性情報を伝達するために、ゴシップ・プロトコルを活用することができる。このゴシップ・プロトコルは、急速に集まって、分散型ロード・バランシング・システムのために充分となる、最終的一貫性に対する保証を提供する。少なくともいくつかの実施形態では、各ロード・バランサ・ノード110は、ゴシップ・プロトコルを用いて、ロード・バランサ実装時の他の各ノード110の鼓動カウンタを、例えば、鼓動リスト内に保持する。各ロード・バランサ・ノード110は、上記の少なくとも他の1つのロード・バランサ・ノード110の健全性チェックを定期的にまたは非定期に行い、チェックされたノード110が健全であることを健全性チェックを経て決定すると直ちに、ノード110の鼓動カウンタを増加させる。少なくともいくつかの実施形態において、各ロード・バランサ・ノード110は、その時点の鼓動リストを送る、ロード・バランサ実装時の他の少なくとも1つのノード110を、定期的にまたは非定期にランダムに選択する。別のノード110からの鼓動リストを受信すると直ちに、ロード・バランサ・ノード110は、この2種類のリスト(受信したリスト及び自身のリスト)のノード110ごとに最大の鼓動カウンタを決定し、決定した最大の鼓動カウンタを自身の鼓動リストに用いることによって、受信したリストの鼓動情報を自身の鼓動リストと組み合わせる。今度は、この鼓動リストが別のランダムに選択されたノード110に送信され、それに応じて、そのノード110が自身の鼓動リストを更新する。以下同様に行われる。この技法を用いて、個々の健全なノード110の鼓動情報は、やがて(例えば、数秒で)、ロード・バランサ実装時の他の全てのロード・バランサ・ノード110に伝達される。所定のロード・バランサ・ノード110について、鼓動カウンタが増加し続ける限り、そのノード110は、他のノード110から健全であるとみなされる。ロード・バランサ・ノード110の鼓動カウンタが、指定された時間、健全性チェック及びゴシップの方法で増加しないならば、他のロード・バランサ・ノード110は、非健全であるとみなされたロード・バランサ・ノード110に集中することができる。
ロード・バランサ・ノードの健全性チェック
以下は、少なくともいくつかの実施形態による、ロード・バランサ・ノード110が実施することのできる、別のロード・バランサ・ノード110の健全性をチェックする方法を述べている。図23を参照すると、少なくともいくつかの実施形態では、以下の条件のうち一つまたは複数のものがロード・バランサ・ノード110で確認されるならば、そのノード110を健全であるとみなすことができる。
・ノード110のプロセッサ・スレッド(例えば、コア・パケット処理コード1108のスレッド)がレディ状態(内部)である。
・ノード110が、エッジ・ルータ104のIPアドレス及び/またはMACアドレス(内部)を認知している。
・ノード110の全てのスレッド及び/またはプロトコル・ハンドラがレディ状態(内部)である。
・北側(エッジルータ104/境界ネットワーク)及び南側(サーバ130/生産ネットワーク)からの着信リンク及び発信リンクがアクティブ(外部)である。
・ノード110は、ロード・バランサ実装時に用いられるネットワーク・インターフェイス・コントローラ(NIC)を介して、パケットを受信し、発信することができる。例えば、図23に示すロード・バランサ・ノード110の実施形態の例において、このノード110は、北向きのNIC1114A及び南向きのNIC1114Bを介してパケットを受信すること及び発信することに成功するはずである。
これらの健全性の条件のうち1つまたは複数のものが所定のノード110にあてはまらないならば、そのノード110は健全でないとみなすことができる。なお、いくつかの実施形態では、上記の条件の全てがノード110にあてはまるならば、ノード110は必ず健全であるとみなされることに留意されたい。
少なくともいくつかの実施形態では、上記の健全性についての条件に加えて、例えばコントロール・プレーンの通信のために用いることができる、NIC1114Cとして図23に示す、各ロード・バランサ・ノード110上の第3のNICも、このNICに対してパケットを送信し、そこからパケットを受信することによって、健全性をチェックするノード110でチェックすることもできる。この第3のNICのチェックが失敗するならば、チェックを受けているノード110は健全ではないとみなすことができる。
図13は、少なくともいくつかの実施形態による、ロード・バランサ・ノードの健全性を、別のロード・バランサ・ノードからチェックする方法の例を示している。この例では、ロード・バランサ・ノード110Aが、ロード・バランサ・ノード110Bの健全性をチェックしている。各ノード110A及び110Bは、北向きのNIC(図23のNIC1114A)、及び南向きのNIC(図23のNIC1114B)を有する。1で、ノード110Aがエッジ・ルータ104を介して北向きのNICからノード110Bの北向きのNICまでパケット(例えば、ピングパケット)を送信する。ノード110Bが、その北向きのNICにパケットを受信し、上記リストに示した条件が満たされるとすると、2で、ファブリック120を介してその北向きのNICからノード110Aの北向きのNICに応答を送信する。ノード110Aが、その北向きのNICでこの応答を受信した後に、3で、ファブリック120を介してその南向きのNICからノード110Bの南向きのNICまでパケット(例えば、ピングパケット)を送信する。ノード110Bが、その南向きのNICでパケットを受信し、上記リストに示した条件が満たされるなら、4で、エッジ・ルータ104を介してその南向きのNICからノード110Aの南向きのNICに応答を送信する。ノード110Aは、その南向きのNICでこの応答を受信すると直ちに、ノード110Bが健全であるとみなし、ノード110Bのローカルな鼓動カウンタを増加させる。その後、このことを、以前に説明したようなゴシップ・プロトコルにより他のノード110にさらに伝達することができる。
上記に代わるものとして、いくつかの実施形態では、ロード・バランサ・ノード110Bは、その北向きのNICで受信した最初のピング・メッセージに対して、その南向きのNICを介してノード110Aの南向きのNICへと応答することができ、その南向きのNICで受信した2つ目のピング・メッセージに対して、その北向きのNICを介してノード110Aの北向きのNICへと応答することができる。
加えて、いくつかの実施形態では、ノード110Aは、自身の第3のNICからノード110Bの第3のNICのネットワーク接続を確認すること、及び、ノード110Bが健全であるならば、ノード110Bの第3のNICから自身の第3のNICにピング・メッセージへの応答を受信することによって、コントロール・プレーンの通信に用いるノード110Bの第3のNIC(図23にNIC1114Cとして示す)の健全性をチェックすることもできる。ピング・メッセージ及びその応答は、1つまたは複数のコントロール・プレーン・デバイス170、例えば、ネットワークスイッチを通過することができる。
上記の健全性チェック・メカニズムは、全方向(北、南、及びコントロール・プレーン通過)へのノード110Bの全ての着信リンクと発信リンク及びデータ経路、並びにノード110Bの全てのNICを動作させる。また、同メカニズムは、ピング・パケットが、クライアント・パケットと同様にノード110Bの内部キュー及びディスパッチングを通り抜けるとき、ノード110Bの内部の健全性を確かめる。
ロード・バランサ・ノードへの健全性チェックの責任の割り当て
少なくともいくつかの実施形態では、ロード・バランサ実装時の各ロード・バランサ・ノード110は、ロード・バランサ実装時に他の全てのロード・バランサ・ノード110のリスト(例えば、整列リスト)に、例えばコンフィギュレーション機能によって、及び/または、図1に示すコンフィギュレーション・サービス122のコンポーネントによってアクセスする。少なくともいくつかの実施形態では、各ロード・バランサ・ノード110は、このリスト上の他の1つまたは複数のノード110をランダムに選択し、健全性チェック・インターバルごとに健全性をチェックし、健全である判断した場合、その鼓動カウンタを増加させることができる。なお、このリストは、その時点で健全性チェック機構が健全、または非健全のいずれとみなすかにかかわらず、ロード・バランサ実装時のすべてのロード・バランサ・ノード110を含む。そして、その時点で非健全なノード110をこのリストからランダムに選択し、健全なノード110と同様に健全性をチェックすることができる。したがって、ノード110の健全性をチェックする1つまたは複数のノード110は、その時点で非健全なノード110を健全であると判断することができ、その鼓動カウンタを増加させ、他のノード110に伝達することができ、したがって、非健全なノード110を、健全なステータスに戻すことができる。
あるいはこの代わりに、いくつかの実施形態では、各ロード・バランサ・ノード110は、このリスト中の他の1つまたは複数のノード110の健全性をチェックし、健全であると判断した場合、その鼓動カウンタを増加させることに対して責任を負うことができる。例えば、いくつかの実施形態では、各ノード110は、他の2つのノード、例えば、このリスト中にある「左」(または、前)及び「右」(または、次)の最近接のノード110に対して責任を負うことができる。なお、このリストは円形であるとみなすことができ、このリストの「最後」のノード110はこのリストの「最初」のノード110の健全性のチェックに責任を負うことができる。逆もまた同じ。いくつかの実施形態では、他の2つのノード110を、例えばこのリスト上の次にある最近接の2つとして、別途選択することができる。いくつかの実施形態では、各ノード110は、このリスト上の他の2つ以上のノード110、例えば、他の3つまたは4つのノード110の健全性チェックについての責任を負うことができる。少なくともいくつかの実施形態では、ノード110がチェックする隣接のノード110を非健全であると判断するならば、このノード110は、この非健全な隣接ノード110がチェックする義務を負っていたリスト上の少なくとも1つのノードの健全性をチェックする責任を負うことができる。少なくともいくつかの実施形態では、その隣接ノード110(例えば、「左」及び「右」の近傍ノード)の健全性をチェックすることに加えて、各ロード・バランサ・ノード110は、また、定期的にまたは非定期にリングの中のノード110をランダムに選択することができ、そのランダムに選択したノード110の健全性をチェックすることができ、健全であれば、このランダムなノード110の鼓動を増加させ、伝達することができる。少なくともいくつかの実施形態では、この順序リストの他の全てのノード110を、それが以前健全であるとみなされたかどうかに関わらず、ランダム抽出及び健全性チェックの対象として考慮する。
少なくともいくつかの実施形態では、各ノード110は、ランダムに選択した1つまたは複数のノード110、または、代替的に、隣接ノード110及びランダムに選択したノードの健全性チェックを、健全性チェック・インターバルと呼ぶことができる通常の間隔で行う。例えば、いくつかの実施形態では、鼓動インターバルは100ミリ秒であってもよいが、より短いか、またはより長いインターバルを用いることもできる。加えて、少なくともいくつかの実施形態では、各ノード110は、その時点の鼓動リストを少なくとも1つのランダムに選択した他のノード110に、ゴシップ・インターバルと呼ぶことができる通常のインターバルで送信、または「うわさを広める」。いくつかの実施形態では、健全性チェック・インターバル及びゴシップ・インターバルは同じであってもよいが、必ずしも同じではない。
図14は、少なくともいくつかの実施形態による、他の1つまたは複数のロード・バランサ・ノードの健全性をチェックするロード・バランサ・ノードを視覚的に示している。この例では、ロード・バランサ実装時に8つのロード・バランサ・ノード110A〜110Hがある。ドットの円は、実装されたすべてのノード110の順序リストを表現している。いくつかの実施形態では、各ノード110は、各インターバルで健全性をチェックするために、リスト上の1つまたは複数の他のノード110をランダムに選択することができる。選択肢の1つとして、いくつかの実施形態では、各ロード・バランサ・ノード110は、順序リスト上の1つまたは複数の特定のノード110をチェックする責任を負うことができる。例えば、ノード110Aは、図14に示す、順序リストに従った、ノード110Aの最隣接の2つのノード110B及び110Hの健全性をチェックする責任を負うことができる。加えて、ロード・バランサ・ノードは、個々の健全性チェック・インターバルで順序リストから別のノード110をランダムに選択することもできる。この例に示すように、ノード110Aは、健全性をチェックするノード110Fもランダムに選択している。ゴシップ・インターバルで、ノード110Aは、ある他の健全なノード110、例えばノード110Dをランダムに選択して、その時点の鼓動リストを選択した他のノード110に、例えば、UDPメッセージで送信する。ノード110は、別のノード110から鼓動リストを受信すると直ちに、それに応じて自身の鼓動リストを更新し、この鼓動リストを、ランダムに選択した1つまたは複数のノード110に、次のゴシップ・インターバルで伝達することができる。
サーバ・ノードの健全性のチェック
ロード・バランサ・ノード110の健全性を、上述したようにチェックすることに加えて、この健全性チェック・プロトコルの実施形態は、サーバ・ノード130上のロード・バランサ・モジュール132及びサーバ134を含むサーバ・ノード130の健全性をチェックすることができる。少なくともいくつかの実施形態では、以下の条件の一方または両方がサーバ・ノード130に確認される場合、サーバ・ノード130を健全であるとみなすことができる:
・ロード・バランサ・モジュール132が健全である。
・サーバ・ノード130が健全性ピング(例えば、L7健全性ピング)への応答に成功する。
図15は、少なくともいくつかの実施形態による、サーバ・ノードの健全性をチェックするロード・バランサ・ノードを示している。少なくともいくつかの実施形態では、ロード・バランサ実装時の各ロード・バランサ・ノード110は、ロード・バランサ実装時の他の全てのロード・バランサ・ノード110のリスト、及び、ロード・バランサ実装時の全てのサーバ・ノード130のリストにアクセスする。リストは、例えば、コンフィギュレーション機能によって、及び/または、図1に示すコンフィギュレーション・サービス122のコンポーネントによって取得及び更新することができる。少なくともいくつかの実施形態では、サーバ・ノード130を、図15に示したコンシステント・ハッシュ・リングを形成する健全なロード・バランサ・ノード110に対してコンシステント・ハッシュすることができる。少なくともいくつかの実施形態では、このリングの中の各サーバ・ノード130の健全性を、このリングの中の2つの健全なロード・バランサ・ノード110でチェックする。例えば、図15において、サーバ・ノード130Aの健全性を、ロード・バランサ・ノード110A及び110Cによってチェックする。この2つのノード110を、コンシステント・ハッシュ・リングの中のサーバ・ノード130に対する第1(ノード110A)及び第2(ノード110B)の健全性チェック・ノード110と呼ぶことができる。なお、所定の健全なロード・バランサ・ノード110は、1つまたは複数のサーバ・ノード130の健全性をチェックすることができる。例えば、図15において、ロード・バランサ・ノード110Aは、サーバ・ノード130B及び130Cの健全性もチェックする。加えて、所定のロード・バランサ・ノード110は、1つまたは複数のサーバ・ノード130の第1の健全性チェック・ノード、及び1つまたは複数の他のサーバ・ノード130の第2の健全性チェック・ノードとなることができる。例えば、図15において、ロード・バランサ・ノード110Aは、サーバ・ノード130A及び130Bの第1の健全性チェッカ・ノードであり、サーバ・ノード130C及び130Dの第2の健全性チェッカ・ノードである。
少なくともいくつかの実施形態では、ロード・バランサ・ノード110が故障している場合、コンシステント・ハッシュ・リングの帰属関係が変化し、なお健全で、したがって、なおコンシステント・ハッシュ・リングに留まる、他の1つまたは複数のロード・バランサ・ノード110が、故障しているノード110が以前健全性をチェックしていたサーバ・ノード130の健全性チェックに対する責任を負うことができる。
少なくともいくつかの実施形態では、各健全なノード110は、割り当てられたサーバ・ノード130の健全性チェックを、通常のインターバルで行う。このインターバルを、サーバ・チェック・インターバルと呼ぶことができる。少なくともいくつかの実施形態では、サーバ・チェック・インターバルは、前述したゴシップ・インターバルより長いかまたは同じでよい。
少なくともいくつかの実施形態では、サーバ・ノード130の健全性チェックを行うために、健全なロード・バランサ・ノード110(例えば、図15のノード110A)は、サーバ・ノード130(例えば、図15のサーバ・ノード130A)に、健全性ピング・メッセージ(例えば、L7 HTTP健全性ピング・メッセージ)送信を開始する。健全であれば、サーバ・ノード130は、ピング応答をロード・バランサ・ノード110に送り返す。少なくともいくつかの実施形態では、サーバ・ノード130上のロード・バランサ・モジュール132がピング・メッセージを受信し、処理するので、成功すれば、サーバ・ノード130上のモジュール132が健全であることが、健全性チェック・ピングによって証明される。このピングに対する応答を受信すると直ちに、ロード・バランサ・ノード110はサーバ・ノード130が健全であるとみなし、サーバ・ノード130の鼓動カウンタを増加させる。
少なくともいくつかの実施形態では、所定の健全なロード・バランサ・ノード110によって健全性をチェックした全てのサーバ・ノード130の鼓動カウンタを、他のロード・バランサ・ノード110に伝達することができる。この伝達は、例えば、ロード・バランサ・ノード110の鼓動カウンタに関して前述したゴシップ技法に従う。このゴシップ技法では、各ノード110が、その鼓動リストを、通常のインターバル(ゴシップ・インターバル)でランダムに選択した少なくとも他の1つのノード110に送信し、受信ノード110が、2種類のリスト中の最大値によって自身の鼓動リストを更新する。
故障検出及びゴシップ
少なくともいくつかの実施形態では、ロード・バランサ実装時の全てのロード・バランサ・ノードがコンシステントな視野を保持できるように、上述したロード・バランサ・ノード110及びサーバ・ノード130の健全性チェックによって得た情報を、ロード・バランサ実装時のすべてのノード110に伝達することが必要である場合がある。上述したように、少なくともいくつかの実施形態では、ロード・バランサ・ノード110は、ゴシップ・プロトコルによって互いに通信し、この健全性情報を交換し、伝達し、ロード・バランサ・ノード110及びサーバ・ノード130の故障を検出することができる。
少なくともいくつかの実施形態では、通常のインターバル(ゴシップ・インターバルと呼ぶことができる)で、各ロード・バランサ・ノード110は、別のロード・バランサ・ノード110をランダムに選択し、その別のノード110に、ロード・バランサ・ノード110及びサーバ・ノード130の鼓動カウンタとともに健全なロード・バランサ・ノード110及びサーバ・ノード130についての自身の見解を送信する。ロード・バランサ・ノードまたはサーバ・ノード130が健全な限り、当該のノードは健全性チェックを合格し、その鼓動カウンタは増加し続ける。あるノードの鼓動カウンタが指定されたインターバル(これは、故障のタイム・インターバルと呼ぶことができる)の間変化しないならば、ロード・バランサ・ノード110は、そのノードが故障していると疑う。いったんノードが故障していると疑うと、ロード・バランサ・ノード110は、このノードを非健全であると判断する前に、指定されたインターバル(これを、非健全なタイム・インターバルと呼ぶことができる)を待つことができる。この非健全なタイム・インターバルによって、ロード・バランサ・ノード110は、このノードが故障していることをすべてのロード・バランサ・ノード110が知るまで待つことができる。
図16は、少なくともいくつかの実施形態による、ロード・バランサ・ノード110が保持することのできる、別のノード(ロード・バランサ・ノード110またはサーバ・ノード130)の健全性の状態、または健全性についての見解を視覚的に示している。300で示すように、ロード・バランサ・ノード110が、問題とするノードが健全であるとの見解からスタートすることを仮定されたい。これは、このノードの鼓動カウンタがそれまで増加していたことを示唆する。しかし、ノードの鼓動カウンタが302に示すように指定されたインターバル(故障タイム・インターバル)の間増加しないならば、ロード・バランサ・ノード110は、304に示すように、このノードが故障していると疑う。ノードの鼓動カウンタが306に示すように指定されたインターバル(非健全なタイム・インターバル)の間増加しないならば、ロード・バランサ・ノード110は、308に示すように、このノードを非健全であるとみなす。しかし、非健全なタイム・インターバルが終了する前に、310に示すようにノードの鼓動カウンタが増加するならば、ロード・バランサ・ノード110は、このノードを健全である300と再びみなす。同様に、312に示すように、非健全なノードに対する鼓動の増加を受信すれば、このノードを健全である300とみなすことができる。
ノードが非健全であると判断すると、非健全なノードがロード・バランサ・ノード110であるかサーバ・ノード130であるかによって、また、ロード・バランサ・ノード110の非健全なノードとの関係によって、本明細書の他の箇所でも述べているように、ロード・バランサ・ノード110を様々に動作させることができる。
ロード・バランサ・ノードのデータ
少なくともいくつかの実施形態では、各ロード・バランサ・ノード110は、ロード・バランサ実装時の状態についてのデータを保持することができる。少なくともいくつかの実施形態では、このデータを、1つまたは複数のデータ構造で、各ロード・バランサ・ノード110上に保持することができる。このデータ構造は、限定はされないが、健全なロード・バランサ・ノード・リスト、疑惑のロード・バランサ・ノード・リスト及び鼓動リストを含む。図17は、健全なロード・バランサ・ノード・リスト320、疑惑のロード・バランサ・ノード・リスト322、非健全なロード・バランサ・ノード・リスト324及びロード・バランサ・ノード鼓動リスト326を保持するロード・バランサ・ノード110の例を示す。
少なくともいくつかの実施形態では、各ロード・バランサ・ノード110は、健全なロード・バランサ・ノード・リスト320を保持することができる。このリストは、例えば、どのノード110が健全であり、したがってゴシップ・プロトコルに関与しているかを決定するために用いることができる健全なロード・バランサ・ノード110のリストである。リスト320上のノード110のみが、ゴシップ・プロトコルによるロード・バランサ情報の伝達に関与し、リスト320上のノード110のみが、コンシステント・ハッシュ・リングに存在するとみなされ、また、このリストのノード110のみが、サーバ・ノード130の健全性をチェックする。ノード110は、このリスト320から、鼓動情報を送信する先とする別のノード110をランダムに選択することができる。加えて、鼓動カウンタを、健全なロード・バランサ・ノード・リスト320にその時あるノード110とのみ交換する。少なくともいくつかの実施形態では、ロード・バランサ・ノードNがロード・バランサ・ノード110による健全性チェックに合格する場合、または、ロード・バランサ・ノード110が、ある他のリスト320上のロード・バランサ・ノードからノードNについてのゴシップ・メッセージを受信するならば、ノードNを、別のロード・バランサ・ノード110の健全なロード・バランサ・ノード・リスト320に追加することができる。
少なくともいくつかの実施形態では、各ロード・バランサ・ノード110は、疑惑のロード・バランサ・ノード・リスト322を保持することができる。これは、指定されたインターバル(故障タイム・インターバルと呼ばれる)の間、その鼓動カウンタ(鼓動リスト326を参照)が増加しなかったロード・バランサ・ノードのリストである。ロード・バランサ・ノードEがロード・バランサ・ノード110の疑惑のロード・バランサ・ノード・リスト322の中にあるならば、ロード・バランサ・ノード110は、ノードEについてゴシップしない。健全なリスト320上の、ある他のロード・バランサ・ノード110が、ノード110の鼓動リスト326のノードEのカウンタより高い鼓動カウンタでノードEについてロード・バランサ・ノード110にうわさを広めるならば、ノードEは、疑惑のリスト322から健全なリスト320に移動される。ノードEがロード・バランサ・ノード110の疑惑のリスト322に指定されたインターバル(非健全なタイム・インターバルと呼ばれる)の間留まる場合、ノードEは、ロード・バランサ・ノード110によって非健全であるとみなされ、非健全なノード・リスト324上に移動される。ノードGがノード110による健全性チェックに合格すると直ちに、または、別のノード110からのノードGの鼓動カウンタの更新を受信すると直ちに、非健全なノード・リスト324上のノード110(この例では、ノードG)を、ロード・バランサ・ノード110の健全なノード・リスト320に移動させることができる。
少なくともいくつかの実施形態では、各ロード・バランサ・ノード110は、すべての既知のロード・バランサ・ノード110の鼓動リスト326を保持することができる。各ノード110に対して、このリスト326は、鼓動カウンタがいつ最後に変化したかを示す鼓動カウンタ及びタイムスタンプを含むことができる。
少なくともいくつかの実施形態では、各ロード・バランサ・ノード110は、すべての既知のサーバ・ノードの鼓動リストを保持することもできる。これは、図17には示していない。このリストは、ロード・バランサ・ノード鼓動リスト326に類似していてもよい。いくつかの実施形態では、2種類のリストを併合することができる。少なくともいくつかの実施形態では、サーバ・ノード130についての鼓動情報を、例えばゴシップ・プロトコルにより、ロード・バランサ・ノード110についての鼓動情報とともに、または、それに加えてロード・バランサ・ノード110の間に伝達することができる。
図17は4つの分離したリストを示すが、2個以上のリストを単一のリストに結合することができる点に注意するべきである。例えば、いくつかの実施形態では、すべてのノード110についての単一のリストを、各ロード・バランサ・ノード110上に保持することができ、各ノードがその時点で健全であるか、疑わしいか、または非健全であるかどうかを示すために、ビット・フラグまたは他のデータ構造を用いることができる。
サーバ・ノードのデータ
少なくともいくつかの実施形態では、サーバ・ノード130、及びノード130上のローカル・ロード・バランサ・モジュール132は、ロード・バランサ・ノード110を用いたゴシップ・プロトコルに関与しない。ロード・バランサ・ノード110は、それら自身の間でのみ、ロード・バランサ・ノードに対する健全性チェックの方法によって得られる、他のロード・バランサ・ノード110についての鼓動情報、及び、サーバ・ノードに対する健全性チェックの方法によって得られる、サーバ・ノード130についての鼓動情報を広める(具体的には、各ロード・バランサ・ノード110は、その時点で、健全なロード・バランサ・ノード・リスト320上にあるノードのみに情報を伝える)。
しかし、サーバ・ノード130が出力クライアント・トラフィックを転送することのできる先であるロード・バランサ・ノード110(とりわけ、出口ノード)を、サーバ・ノード130が決定できるように、また、どのロード・バランサ・ノードに接続公表情報を送信するべきであるかをサーバ・ノード130が判断できるように、各サーバ・ノード130/ロード・バランサ・モジュール132は、ロード・バランサ実装時の健全なロード・バランサ・ノード110についての情報を必要とする場合がある。少なくともいくつかの実施形態では、この情報をサーバ・ノード130に提供するために、ロード・バランサ・ノード110は、その時点での健全なロード・バランサ・ノード110を識別する情報(例えば、図17の健全なロード・バランサ・ノード・リスト320)で、サーバ・ノード130を定期的にまたは非定期に更新することができる。少なくともいくつかの実施形態では、所定のサーバ・ノード130(図15を参照)の健全性をチェックする責任を負うロード・バランサ・ノード110は、その時点の健全なロード・バランサ・ノードを識別する情報をサーバ130に提供する責任を負う。例えば、図15では、ロード・バランサ・ノード110Aは、その健全なロード・バランサ・ノードリスト320を、サーバ・ノード130A、130B、130C及び130Dに送信することができる。また、ロード・バランサ・ノード110Bは、その健全なロード・バランサ・ノードリスト320を、サーバ・ノード130C、130D及び130Eに送ることができる。以下同様である。
ロード・バランサ・ノード故障の取り扱い
図18A,18Bは、少なくともいくつかの実施形態による、ロード・バランサ・ノード故障への対処を示している。図18Aは、ロード・バランサ実装の例を示す。ここではロード・バランサ実装中の4つのロード・バランサ・ノード110A〜110Dがある。エッジ・ルータ104は、着信パケットをクライアント(図示せず)からロード・バランサ・ノード110まで経路指定する。少なくともいくつかの実施形態では、エッジ・ルータ104は、4層フロー単位ハッシュ化多重パス経路指定技法、例えば等コスト・多重パス(ECMP)経路指定技法により経路指定を行うことができる。少なくともいくつかの実施形態では、エッジ・ルータ104は、ロード・バランサ・ノード110の広告、例えば、このロード・バランサ・ノード110で開始される境界ゲートウェイ・プロトコル(BGP)技術セッションを介した広告によって、クライアント・トラフィックを受信するためにロード・バランサ実装時に利用できるロード・バランサ・ノード110についての情報を得る。しかし、少なくともいくつかの実施形態では、BGPセッションによって自身をエッジ・ルータ104に広告するロード・バランサ・ノード110の代わりに、ロード・バランサ実装時の他の少なくとも1つのノード110が、BGPによってそのノード110をエッジ・ルータ104に広告する責任を負う。例えば、図18Aに示すいくつかの実施形態では、所定のノード110の左右に隣接するノード110が、その所定のノード110をエッジ・ルータ104に広告する。例えば、ロード・バランサ・ノード110Aはノード110B及び110Dを広告し、ロード・バランサ・ノード110Bはノード110A及び110Cを広告し、また、ロード・バランサ・ノード110Cはノード110B及び110Dを広告する。
また、図18Aの例に示すように、各ロード・バランサ・ノード110は、他の1つまたは複数のロード・バランサ・ノード110の健全性を定期的にチェックする。例えば、1つまたは複数のランダムに選択されたノード110、ロード・バランサ・ノードの順序リストによって決定された1つまたは複数の隣接するノード110、または、1つまたは複数の隣接するノード110及び1つまたは複数のランダムに選択されたノードである。加えて、各ロード・バランサ・ノード110は、少なくとも1つのサーバ・ノード130の健全性を定期的にチェックすることができるし、健全なロード・バランサ・ノード110についてのリストを、健全性チェックを行うサーバ・ノードに送信することもできる。ロード・バランサ・ノード110及びサーバ・ノード130の健全性情報をノード110の間で伝達することができるが、これを、例えばゴシップ・プロトコルによって行うことができる。
図18Bは、図18Aのロード・バランサ実装時の例において、1つのロード・バランサ・ノード110の故障の取り扱いを示している。この例では、ロード・バランサ・ノード110Bが、何かの理由で故障している。例えば、ノード110A及び110Cはノード110Bの健全性をチェックすることができ、両方とも、ノード110Bがその健全性チェックに不合格であることを検出することができる。例えば、ノード110A及び110Cは、ノード110Bの鼓動カウンタを増加させない。ノード110A及び110Bの双方からの鼓動情報を、他の健全なロード・バランサ・ノード110(この例では、唯一の他のロード・バランサ・ノードはノード110Dである)に、ゴシップ・プロトコルによって伝達する。全ての健全なロード・バランサ・ノード110(この例では、ノード110A、110C及び110D)がノード110Bの故障に集中するとすぐに、限定はされないが、1つまたは複数の次の事象が生じる可能性がある。なお、これらの事象は必ずしもこの順序で起こるわけではない。
・ノード110A及び110Cは、ノード110Bをエッジ・ルータ104に広告するのを止める。これは、少なくともいくつかの実施形態では、ノード110がノード110Bを広告するためにエッジ・ルータ104と確立したBGPセッションを終わらせることを含む。なお、各ノード110は、エッジ・ルータ104と、広告する他のノードごとに、別々のBGPセッションを確立するので、ノード110Bに対するBGPセッションを終わらせても、他の広告されているノード110に影響を及ぼさない。少なくともいくつかの実施形態では、ノード110は、BGPセッションに対するエッジ・ルータ104へのTCP終了または類似のメッセージを送信することによって、エッジ・ルータ104とのBGPセッションを終了させる。
・エッジ・ルータ104は、ノード110Bが、もはやいずれのノードからも広告されていないことが検出されたことに応答して、ノード110Bに対するクライアント・データ・パケットの経路指定を停止する。また、エッジ・ルータ104は、クライアントからのパケット・フローを、残っている健全なロード・バランサ・ノード110、特に、ノード110上の入口サーバ112に再分散させるために、多重パス(例えば、ECMP)ハッシングを調整する。入口サーバ112に経路指定されたパケット・フローであって、それに対して入口サーバ112がクライアント->サーバ・マッピングを有していない、いかなるパケット・フローについても、そのマッピングを、このクライアント->サーバ接続のフロー・トラッカ・ノード(flow tracker node)から得ることができる。または、代わりに、図10A〜10Gに図示する技法に従って、新しいクライアント->サーバ接続を確立することができる。
・ノード110A及び110Cは、相互に広告するために、それぞれ、エッジ・ルータ104にBGPセッションを開設することができる。なお、ノード110A及び110Cはともに、ロード・バランサ・ノード110B同様、ノード110Dによってもエッジ・ルータ104に広告されるので、ノード110Bが故障しているときノード110A及び110Bの広告を停止することができるという事実によって、エッジ・ルータ104が、これら2つのノード110へのパケットの経路指定を停止するということにはならない。
・少なくともいくつかの実施形態では、ノード110A及び110Cは、今や隣接するノード110であるので、相互に健全性をチェックする責任を負うことができる。なお、ノード110Bを非健全であるとみなしているにもかかわらず、他の1つまたは複数のノード110は、それでもランダムに健全性をチェックすることができる。
・残っている1つまたは複数の健全なロード・バランサ・ノード110は、以前にノード110Bによってフローをトラッキングしたフロー・トラッキング接続の責任を負うことができる。例えば、ノード110C及び/またはノード110Dは、ノード110Bがその一次またはニ次のフロー・トラッカであった1つまたは複数の接続を、図11Cおよび11Dに示す一次またはニ次のフロー・トラッカとして引き継ぐことができる。
・残っている1つまたは複数の健全なロード・バランサ・ノード110は、以前ノード110Bが健全性をチェックしたサーバ・ノード130の健全性をチェックする責任を負うことができる。サーバ・ノード130を、残っているロード・バランサ・ノード110による健全なロード・バランサ・ノード・リスト(今やノード110Bを含んでいない)で更新する。例えば、図18Bにおいて、ロード・バランサ・ノード110Aはサーバ・ノード130Cの健全性チェック及び更新を開始し、ロード・バランサ・ノード110Cは、サーバ・ノード130Bの健全性チェック及び更新を開始する。
・エッジ・ルータ104上では、故障しているノード110BからのBGPセッションが、やがてタイムアウトになる。あるいは、エッジ・ルータ104が、ノード110Bの故障を認識して、BGPセッションを終了することができる。
2つのロード・バランサ・ノード110が、同時に、または、ほとんど同時に故障する場合がありうる。2つの故障したロード・バランサ・ノードが互いに隣接していない場合、故障は独立しており、別々の単独のノード110故障として図18Bに示す方法によって取り扱うことができる。しかし、2つの故障したノードが互いに隣接している場合(例えば、図18Aのノード110B及び110C)、全ての健全なロード・バランサ・ノード110(この例では、ノード110A及び110D)が故障を検出し、故障に集中すると直ちに、限定はされないが、1つまたは複数の、次の事象が生じる場合がある。なお、これらの事象は必ずしもこの順序で生じるわけではないことに留意されたい。
・ノード110Aが、ノード110Bの代わりにエッジ・ルータ104に対するBGPセッションを終了させる。
・ノード110Dが、ノード110Cの代わりにエッジ・ルータ104に対するBGPセッションを終了させる。
・ノード110A及び110Dが、互いを広告するエッジ・ルータ104とのBGPセッションを開始する。
・ノード110A及び110Dは、互いの健全性チェックを開始することができる。なお、ノード110A及び110Dは、故障しているノード110の健全性チェックを継続することもできる。
・残っている健全なノード110が、健全なロード・バランサ・ノード・リストでサーバ・ノード130を更新する。
・ノード110B及びノード110Cが互いをエッジ・ルータ104に広告し続けることができるので、トラフィックがエッジ・ルータ104からノード110B及び/またはノード110Cに流れ続けることができる。しかし、これらのBGPセッションはやがてタイムアウトになり、それに応じてエッジ・ルータ104が残っている広告されたノード110にこのフローを再分散させる。
・ノード110B及び110Cがノード110A及び110Dをなお健全であると考えているならば、ノード110B及び110Cは、それぞれがノード110A及び110Dを広告する先であるエッジ・ルータ104とのBGPセッションを閉じることができる。
接続公表
再び図1を参照すると、少なくともいくつかの実施形態では、ロード・バランサ実装時のロード・バランサ・ノード110は、サーバ130に対するクライアントのTCP接続の状態情報を保持している。この状態情報は、ロード・バランサ・ノード110が、エッジ・ルータ104からTCP接続に対して責任を負うサーバ・ノード130まで着信クライアント・トラフィックを経路指定できるようにする。サーバ・ノード130上のロード・バランサ・モジュール132は、それぞれのサーバ134に対するアクティブなTCP接続のリストを保持している。接続公表は、サーバ・ノード130上のロード・バランサ・モジュール132がロード・バランサ・ノード110に対するアクティブなクライアントTCP接続のリストを公表することができるメカニズムであり、このメカニズムによってそれを公表する。少なくともいくつかの実施形態では、接続公表パケットを、通常のインターバルでロード・モジュール132によってロード・バランサ・ノード110に対して形成し、公表する。この通常のインターバルを接続公表インターバルと呼ぶことができる。
少なくともいくつかの実施形態では、ロード・バランサ・ノード110が保持する接続状態情報を、キャッシュの形態で見ることができる。また、特定の接続についての状態情報を保持することは、その接続についてロード・バランサ・ノード110に対するリースを継続することとみることができる。キャッシュエントリが更新されない限り、ロード・バランサ・ノード110はデータ・フローを取り扱うサーバ・ノード130にクライアント・データ・フローを経路指定することができてはいけない。接続公表メカニズムは定期的に、サーバ・ノード130からのその時点の接続状態を有する、ロード・バランサ・ノード110上のキャッシュを、したがってリースを更新し、こうして、クライアント160から適切なサーバ・ノード130へのTCPパケットの流れを保持する。クライアント160がサーバ134へのTCP接続を終了するとき、この接続と関連するサーバ・ノード130上のロード・バランサ・モジュール132は、そのアクティブな接続のリストからこの接続を削除し、したがって、このTCP接続を、もはや接続公表メカニズムを通じて公表しない。したがって、この接続(とりわけ、この接続のための入口サーバ112並びに一次及び二次のフロー・トラッカ116)と関連するロード・バランサ・ノード110上のこの接続の接続状態情報(キャッシュ・エントリ)はもはや更新されず、この接続は、ロード・バランサ・ノード110から外される。少なくともいくつかの実施形態では、この接続の1つまたは複数のキャッシュ・エントリは、他のなんらかのアクティブな接続のためにメモリが求められるまで、ロード・バランサ・ノード110上のキャッシュに残ることができる。
こうして、接続公表メカニズムは、入口サーバ112並びに一次及び二次のフロー・トラッカ116に関する接続リースを定期的または非定期に延長し、クライアント・トラフィックの流れを保持する。加えて、接続公表メカニズムは、少なくともいくつかのロード・バランサ・ノード110の故障からの回復を支援することができる。クライアント接続の状態情報を保持する1つまたは複数のロード・バランサ・ノード110が故障しているときに、いくつかの事例で、残っているロード・バランサ・ノード110に接続公表によって提供されるアクティブな接続情報を用いて接続を回復することができる。
接続公表メカニズムを用いることで、サーバ・ノード130は、サーバ134とクライアント160の間の接続状態に関する信頼すべき情報源となる。加えて、サーバ134への接続の終了は、サーバ・ノード130上のロード・バランサ・モジュール132とロード・バランサ・ノード110により受動的に取り扱われる。ハンドシェイキングは、サーバ・ノード130とロード・バランサ・ノード110の間では求められない。換言すれば、ロード・バランサ・モジュール132は、特定の接続が終了したことをロード・バランサ・ノード110に積極的に通知するために、このノードにメッセージを送信する必要はない。サーバ134が接続を終了するときに、サーバ134は接続に関する内部状態を消去する。ロード・バランサ・モジュール132は、サーバ134の内部状態を用いて接続公表パケットにデータを追加する。この接続はもはやサーバ134の内部状態にないので、接続は、ロード・バランサ・ノード110に公表されない。ロード・バランサ・ノード110上での接続のリースはこのように終了し、ロード・バランサ・ノード110はこの接続に関して受動的に忘れる。この接続に用いられたロード・バランサ・ノード110のキャッシュ内のメモリは、その後、必要に応じて、他の接続に用いることができる。
いくつかの実施形態では、ロード・バランサ・ノード110によって維持される接続のリースには、キャッシュ内の、接続に関するタイムスタンピング・エントリを含めることができる。接続についてのリースを接続公表パケットによって更新するときには、タイムスタンプを更新することができる。接続が、サーバ・ノード130上のロード・バランサ・モジュール132によりもはや公表されていないという理由で、接続についてのリースが更新されないならば、タイムスタンプはもはや更新されない。少なくともいくつかの実施形態では、接続についてのエントリをメモリが必要となるまでキャッシュ内に残すことのできるレイジィー・ガーベジ・コレクション法を用いることができる。例えば、少なくともいくつかの実施形態では、キャッシュ・エントリに対するタイムスタンプは、リース更新時の閾値と比較することができ、キャッシュ・エントリに対するタイムスタンプがこの閾値よりも古いならば、このエントリは古いままであり再利用することができる。しかし、いくつかの実施形態では、古いままであるエントリを、積極的にガーベジ・コレクションすることができる。
受け側の接続公表
少なくともいくつかの実施形態では、クライアントTCP接続ごとに、接続状態を維持する3つのロード・バランサ・ノード110:入口サーバ112として働くノード110、一次フロー・トラッカ116として働くノード110、及び二次フロー・トラッカ116として働くノード、がある。所定のTCPフローに対して、例えばロード・バランサ・ノード110によって、コンシステント・ハッシュ関数をTCPフローに適用して、一次フロー・トラッカ116ノード及び、それを継承するコンシステント・ハッシュ・リング内のノードを見つけることによって、一次及び二次のフロー・トラッカ116を決定することができる。TCPフローに対して入口サーバ112として働くロード・バランサ・ノード110は、エッジ・ルータ104の内部多重パス(例えば、ECMP)ハッシュ関数に基づいてエッジ・ルータ104からのTCPフローのトラフィックを受信するノード110である。ノード110の故障または追加があるならば、入口サーバ112として働くロード・バランサ・ノード110は、多くのアクティブなTCPフローに対して変わることができる。そして、少なくともいくつかのアクティブなTCPフローのフロー・トラッカとして働くロード・バランサ・ノード110は、変わることができる(図11A〜11D参照)。サーバ・ノード130上のサーバ132に対するTCPフローごとに、どのロード・バランサ・ノード110がそのTCPフローの入口サーバ112であるかを示す状態情報を、サーバ・ノード130上のロード・バランサ・モジュール132が維持している。それは、そのロード・バランサ・モジュール132がそのロード・バランサ・ノード110からトラフィックを受信するからである。しかし、少なくともいくつかの実施形態では、ロード・バランサ・モジュール132は、TCPフローに対して、どのロード・バランサ・ノード110が一次及び二次のフロー・トラッカとして働くのかを知ることはできないし、決定する能力を有することはできない。なぜなら、ロード・バランサ・モジュール132は、用いられるコンシステント・ハッシュ関数を知ることができないからである。換言すれば、少なくともいくつかの実施形態では、ロード・バランサ・モジュール132は、コンシステント・ハッシングを行わない。
アクティブな接続情報の公表
図19A、19Bは、少なくともいくつかの実施形態による、接続公表技法を視覚的に示している。図19Aは、ロード・バランサ・ノードに対してアクティブな接続の情報を公表するロード・バランサ(LB)モジュールを示す。少なくともいくつかの実施形態では、各ロード・バランサ・モジュール132は、サーバ・ノード130上でアクティブなTCPフローごとに情報を収集して、接続公表パケットを形成する。所定のTCPフローの情報は、フローに対する入口サーバ112として働くロード・バランサ・ノード110を識別する情報を含む。接続公表パケットの準備ができている(例えば、接続公表インターバルに達しているとき)とき、ロード・バランサ・モジュール132は、ロード・バランサ・ノード110をランダムに選択するが、その選択は、例えば、健全なロード・バランサ・ノード110のリストからであり、そのリストはロード・バランサ・ノード110からサーバ・ノード130に定期的に送信され、そのロード・バランサ・ノード110は、前述のとおりサーバ・ノード130の健全性をチェックする。その後、ロード・バランサ・モジュール132は、選択したノード110に接続公表パケットを送信する。例えば、図19Aにおいて、ロード・バランサ・モジュール132Aは、ロード・バランサ・ノード110Aに1つの接続公表パケットを既に送信しているが、その後、ロード・バランサ・ノード110Bに、別の接続公表パケットを送る。
図20は、少なくともいくつかの実施形態による、各ロード・バランサ・モジュール132が行うことのできる接続公表方法についてのハイレベルのフローチャートである。500に示すように、ロード・バランサ(LB)モジュール132は、それぞれのサーバ・ノード130上のアクティブな各TCPフローに対して接続公表エントリを作成する。少なくともいくつかの実施形態では、ロード・バランサ・モジュール132が、サーバ・ノード130上のサーバ134が対処するアクティブなTCP接続の一式を、例えばサーバ・ノード130上の/proc/net/tcpから読み出す。アクティブな各TCP接続に対して、ロード・バランサ・モジュール132は、(例えば、ローカルに保持されているアクティブな接続の表の中で)そのTCPフローに対して入口サーバ112の役割を果たすロード・バランサ・ノード110を探し、この接続に対するTCPタプルを示す接続公表エントリ(例えば、以下からなる4−タプル:クライアントIPアドレス、クライアント・ポート、サーバの(公開)IPアドレス、及びサーバ・ポート)並びにこの接続のための入口サーバ112を作成する。なお、各ロード・バランサ・モジュール132は、アクティブなTCP接続ごとの情報を保持し、その情報は、その接続が受け取ったパケットの出所である最後のロード・バランサ・ノード110を示すことに留意されたい。また、ロード・バランサ・モジュール132は、この情報を、個々のアクティブな接続に対する入口ノード110を識別するために用いることができる。
502に示すように、ロード・バランサ・モジュール132は、(1つまたは複数の接続公表エントリを含み、アクティブなTCP接続ごとに1つのエントリを有する)接続公表パケットが送信されることになっているロード・バランサ・ノード110をランダムに選択する。少なくともいくつかの実施形態では、接続公表パケットを送信する準備ができているとロード・バランサ・モジュール132が判断したとき、ロード・バランサ・モジュール110を、ランダムに選択することができる。少なくともいくつかの実施形態では、この判断を、接続公表インターバルに従って行う。非限定的な例として、この接続公表インターバルを、100ミリ秒(ms)または1秒とすることができる。少なくともいくつかの実施形態では、ロード・バランサ・モジュール110を、ロード・バランサ・ノード110のうちの1つから以前に受信した健全なロード・バランサ・ノード110のリストから選択する。504で示すように、ロード・バランサ・モジュールは、この後、接続公表パケットを、選択したロード・バランサ・ノード110に公表する。少なくともいくつかの実施形態では、接続公表パケットはステートレス・パケット、例えばUDPパケットである。いくつかの実施形態では、この接続公表パケットを、標的のロード・バランサ・ノード110に送信する前に圧縮することができる。少なくともいくつかの実施形態では、接続公表情報を、2つ以上のパケットで標的のロード・バランサ・ノード110に送信することができる。
要素504から要素500に返っている矢で示すように、ロード・バランサ・モジュール132は、連続的に、接続公表パケットを構築し、ランダムなノード110を選択し、また、選択したノードにパケットを送信することができる。上記したように、これを、接続公表インターバルに従って行うことができるので、ロード・バランサ・ノード110を、その時点のアクティブな接続の情報で比較的定期的にリフレッシュすることができ、ロード・バランサ・ノード110上の接続リースを継続することができる。
少なくともいくつかの実施形態では、接続公表パケットは、ロード・バランサ・モジュールによってロード・バランサ・ノード110にランダムに分散されるので、接続公表パケットを受信するロード・バランサ・ノード110は、接続公表パケット内のアクティブな接続情報を、接続の正しい入口/一次/二次の各ノード110に分散させる義務を負う。図19B及び図21、22は、少なくともいくつかの実施形態で用いることができるアクティブな接続情報を分散させる方法を示す。
図19Bは、少なくともいくつかの実施形態による、ロード・バランサ・ノード110の間へのアクティブな接続情報の分散化を示している。ロード・バランサ・ノード110がロード・バランサ・モジュール132から接続公表パケットを受信するとき、ロード・バランサ・ノード110は、そのときに示されるTCPフローごとの情報を分析して、そのフローの入口ノード並びに一次及びニ次のフロー・トラッカ・ノードを決定することができる。ロード・バランサ・ノード110がフローに対してそれらの役割の1つの働きをしているならば、ロード・バランサ・ノード110は、(例えば、状態情報についてそのキャッシュを更新することによって)フローの情報を消費する。少なくともいくつかの実施形態では、ロード・バランサ・ノード110はまた、パケットにフローの情報を入れて、フローに対する他の役割を担う1つまたは複数の他のノード110に送信することもできる。接続公表パケットが示す残りのフローに対しては、ロード・バランサ・ノード110は、アクティブな接続情報を2つ以上のより小さなパケットに分割して、それぞれのパケットを1つまたは複数の他のロード・バランサ・ノード110に送信する。例えば、少なくともいくつかの実施形態では、1つまたは複数のフローのアクティブな接続情報を含むパケットを、フローの入口サーバ112、一次フロー・トラッカ116A及び二次フロー・トラッカ116Bとして働くロード・バランサ・ノード110に送信することができる。
図21は、少なくともいくつかの実施形態による、接続公表パケット内に受信されたアクティブな接続情報を、標的ロード・バランサ・ノード110に分散させる方法のフローチャートである。520に示すように、ロード・バランサ・ノード110はロード・バランサ・モジュール132から接続公表パケットを受信する。このロード・バランサ・モジュール132は、例えば、図19A、20を参照して上記で説明したように、パケットを生成して、このパケットを受信するロード・バランサ・ノード110を選択した。接続公表パケットは、パケットを受信するサーバ・ノード130を識別する情報(例えば、サーバ・ノード130上のロード・バランサ・モジュール132のIPアドレス)、及びアクティブなTCP接続を識別するエントリのリスト(例えば、各接続に対するクライアントIPアドレス、クライアント・ポート、サーバの(パブリック)IPアドレス、及びサーバ・ポートの4要素からなる組)を含むことができる。
図21の要素522〜530において、ロード・バランサ・モジュール110は、受信した接続公表パケットに示されるアクティブなTCP接続情報を繰り返し処理する。522に示すように、ロード・バランサ・ノード110は、パケット内の次のTCPフローのエントリを分析して、それぞれのTCPフローの入口ノード110並びに一次及び二次のフロー・トラッカ・ノード110を決定する。少なくともいくつかの実施形態では、ロード・バランサ・ノード110は、この接続公表エントリから入口ノード110の識別情報を得る。少なくともいくつかの実施形態では、TCPフローの一次及び二次のフロー・トラッカ・ノード110を、コンシステント・ハッシュ関数により決定することができる。524では、ロード・バランサ・ノード110が、調査中のTCPフローに対して1つの役割を担うならば、その後、526で、ロード・バランサ・ノード110は、例えば、そのキャッシュを状態情報に対して更新することによって、このフローの情報を消費する。528で示されるように、ロード・バランサ・ノード110は、TCPフローの接続公表エントリを、別のロード・バランサ・ノード110に送信されるべき構築中のパケットに追加することができる。530では、接続公表パケット内に、フローの接続公表エントリがもっとあるならば、この方法は、522に戻って次のエントリを処理する。そうでないならば、ロード・バランサ・ノードは、それぞれが、元の接続公表パケットからの接続公表エントリのサブセットを含む新らたに構築されたパケットを、532で示すように、パケットの標的ロード・バランサ・ノード110に送信する。少なくともいくつかの実施形態では、標的ロード・バランサ・ノード110に送信されたパケットは、ステートレス・パケット、例えば、UDPパケットである。いくつかの実施形態では、このパケットを、標的のロード・バランサ・ノード110に送信する前に圧縮することができる。
このように、少なくともいくつかの実施形態では、図21の要素522〜528において、フロー・トラッカ・ノード110は、受信した接続公表パケット内の接続公表エントリから、522で決定された情報によりそれぞれ他のノード110のうちの特定の1つに送信される1つまたは複数のパケット(例えば、UDPパケット)を構築する。少なくともいくつかの実施形態では、別のノード110に送信されたパケットは、TCPフローのエントリを含み、この標的ノード110はTCPフローの入口ノード110、一次フロー・トラッカ・ノード110または二次フロー・トラッカ・ノード110として働く。なお、いくつかの実施形態では、所定のロード・バランサ・ノード110は、TCPフローの入口ノード及び一次フロー・トラッカ・ノードの両方、または、TCPフローの入口ノード及びニ次フロー・トラッカ・ノードの両方の働きをすることができることに留意されたい。
図22は、少なくともいくつかの実施形態による、接続公表パケット内に受信されたアクティブな接続情報を、標的ロード・バランサ・ノード110に分散させる代替の方法を示している。550に示すように、ロード・バランサ・ノード110は、ロード・バランサ・モジュール132から、接続公表パケットを受信する。この方法では、552で示すように、ロード・バランサ・モジュール110上のプロセスが、このパケット内の接続公表エントリを分析し、それに応じて、この受信したパケットを1つまたは複数のより小さなパケットに分割する。ロード・バランサ・モジュール110は、このプロセスの間、フロー情報をローカルに消費しない。一旦、接続公表パケットが1つまたは複数のパケットに分割されると、これらのパケットは、その後、554〜560に示すように処理される。554では、パケットの標的ノード110がこのロード・バランサ・ノード110であれば、このロード・バランサ・ノード110は、556で示すようにパケットをローカルに消費する。そうでないなら、このパケットは、標的ロード・バランサ・ノード110に送信される。560で、処理するべきパケットがもっとあれば、この方法は、次に554に戻る。そうでないなら、この方法は終了される。
このように、ロード・バランサ・モジュール132から接続公表パケットを受信するロード・バランサ・ノード110は、接続公表パケットを他のロード・バランサ・ノード110のうちの特定のものに特異的な2つ以上のより小さなパケットに分割し、それに応じてパケットを分散させることができ、一方、ロード・バランサ・ノード110がその時点で取り扱ういかなるTCPフローについても、そのフロー情報が内部的に消費される。その間に、他のロード・バランサ・ノード110は、ロード・バランサ・モジュール132から接続公表パケットを受信し、接続公表エントリを複数のより小さなパケットに分割し、さらに、これらのより小さなパケットを標的ノード110に送信し、それによって、アクティブな接続情報をノード110間に分散させることもできる。
接続公表のトリガ
少なくともいくつかの実施形態では、接続公表は、1つまたは複数の異なる事象によって、ロード・バランサ・モジュール132上で始動され得る。既に述べたように、いくつかの実施形態では、接続公表パケットが生成され、接続公表インターバル、例えば100ミリ秒または1秒のインターバルにより、ランダムに選択されたロード・バランサ・ノード110に送信されて、このロード・バランサ・ノード110上のTCP接続のリースが更新され得る。いくつかの実施形態では、ロード・バランサ・ノード110のメンバー数の変化は、接続公表の事象を直ちに始動させることができる。少なくともいくつかの実施形態では、ロード・バランサ・モジュール132は、それぞれのサーバ・ノード130の健全性をチェックするロード・バランサ・ノード110のうちの1つが送る健全なロード・バランサ・ノード110のリストから、変化について知ることができる。ロード・バランサ・モジュール132は、このリストによる変化(削除または追加)を検出すると直ちに、接続公表パケットを生成し、ロード・バランサ・ノード110に送信することができるので、この変化に影響を受けたTCP接続を、ロード・バランサ・ノード110によって、より速く回復させることができる。
パケット・ループの防止
接続公表パケットを処理している間にロード・バランサ層のメンバー数が変化するならば、接続公表パケット・ループが生じる可能性がある。第1のノード110は、ロード・バランサ・モジュール132から接続公表パケットを受信し、より小さなパケットを第2のノード110に送信することができる。しかし、メンバー数が変化したならば、第2のノードは、パケットが第1のノード110に行くこと決定することができ、このため、パケットを第1のノード110に転送することができる。少なくともいくつかの実施形態では、このループの発生を防止するために、さまざまなポート番号を、ロード・バランサ・モジュール132及びロード・バランサ・ノード110から受信する接続公表パケットに用いることができる。また、ロード・バランサ・ノード110は、別のロード・バランサ・ノード110から受信した接続公表パケットを再分散させない。
接続公表パケット分散の代替案
上記の接続公表の方法において、ロード・バランサ・モジュール132は、接続公表パケットを送信する相手であるロード・バランサ・ノード110をランダムに選択する。しかし、いくつかの実施形態では、他の方法を用いてロード・バランサ・ノード110を選択することができる。例えば、いくつかの実施形態では、ロード・バランサ・ノード132は、1つまたは複数のアクティブなTCPフローを取り扱う特定の入口ノード110にそれぞれ向けられた1つまたは複数の接続公表パケットを構築することができ、パケットを標的入口ノード110に送信した。この入口ノード110は、アクティブな接続情報を、その接続の一次及び二次のフロー・トラッカに、さらに再分散させた。他の例として、いくつかの実施形態では、接続公表パケットを、ランダムに選択した単一のノード110に送信する代わりに、各接続公表パケットを、ロード・バランサ・モジュール132によって、2つ以上の健全なノード110、または、全ての健全なノード110に送信することができる。
ロード・バランサ・ノードのアーキテクチャ
図23は、少なくともいくつかの実施形態によるロード・バランサ・ノード110のソフトウェア・スタックのアーキテクチャの例を示したものであり、これに限定する意図はない。このソフトウェア・スタック・アーキテクチャの例では、ロード・バランサ・ノード110は、ジャバ・ネイティブ・インターフェイス(JNITM)1104を用いて、ロード・バランサ・サーバのネイティブ・コード1106及び、例えば、インテルTM・データプレーン開発キット(DPDK)技術コードのコア・パケット処理コード1108を含むことができるネイティブ・コードの層を管理する単一のジャバTM技術プロセス1102内で動作する。このネイティブ・コードは2つのネットワーク・インターフェイス・コントローラ(NIC1114A及び1114B)をインターフェイス接続することができる。第一のNIC(NIC1114A)は「北」、すなわち、エッジ・ルータ104の方に面することができる。第二のNIC(NIC1114B)は「南」、すなわち、サーバ・ノード130の方に面することができる。少なくともいくつかの実施形態では、NIC1114A及び1114BはTCPスタックを維持することができない。したがって、少なくともいくつかの実施形態では、ロード・バランサ・ノード110が制御プレーンを介してプロセスと通信することができるように、TCP接続をサポートする第三のNIC1114Cを含むことができるし、逆もまた同様である。あるいは、いくつかの実施形態では、ロード・バランサ・ノード110は北に面する第一のNIC1114Aと南に面する第二のNIC1114Bのみを実装することができて、南に面するNIC1114BがTCPスタックを実装することができ、それを介してロード・バランサ・ノード110がプロセスとのコントロール・プレーンを介した通信をすることができる。ロード・バランサ・ノード110はまた、オペレーティング・システム(OS)技術ソフトウェア1112(例えば、リナックスTMカーネル)並びに、OS技術ソフトウェア1112及びJNI1104技術の上にあるジャバ・バーチャル・マシーン(JVMTM)技術ソフトウェア1110レイヤー、も含む。
少なくともいくつかの実施形態では、分散型ロード・バランシング・システム内の各ロード・バランサ・ノード110は、高いパケット・レートで多くのデータ・フローを同時に処理しなければならない場合がある。少なくともいくつかの実施形態では、処理能力の必要なレベルを達成するために、ロード・バランサ・ノード110は高性能パケット処理用のインテルTM・データプレーン開発キット(DPDK)技術を利用することができる。DPDK技術は、ユーザ空間プログラムがパケットを直接ネットワーク・インターフェイス・コントローラ(NIC)から読み取り/ネットワーク・インターフェイス・コントローラ(NIC)に書き込むことを可能にし、リナックス・カーネル・ネットワーキング・スタック(リナックスixgbeベースNICドライバを除く)の多くの層を迂回する。パケット処理へのDPDKアプローチは、ビジー・ループにNICハードウェアを直接投入する専用のCPUコアを選択して割り込みハンドラーベースの入力を拒絶する。このアプローチは、ビジー・ループ内に専用のCPUコアを連続的に走らせることによる熱出力の増加を犠牲にして、はるかに高いパケット・レートを可能にすることができる。DPDK技術はまた、CPUコア・マネジメント、ロックフリー・キュー、メモリ・プール及び同期プリミティブを含むパケット処理ツールを提供することができる。図24に示すように、DPDK技術では、専用のCPUコア600を個々の特別なタスクに使用することができる。そして、作業は非停止キュー602を用いてあるCPUコア600Aから別のCPUコア600Bに渡される。
DPDKキュー602は高速の2の累乗リング・バッファを用いて実装され、単一及び多数の生産者/消費者のバリアントを支援することができる。この多数の生産者/消費者のバリアントは比較交換(CAS)ループを含んでアクセスを同期させるので、真にロック・フリーではない。パケット・バッファ・メモリはすべて、バッファへのポインタだけがキュー602に読み書きされるようにメモリ・プール内にあらかじめ割り当てることができる。メモリ・プールは、キューとして実装することができ、最適化してメモリ・チャンネルとランク全体にわたって分散させることができ、不均等メモリ・アクセス(NUMA)で最適化された割り当てをサポートすることができる。少なくともいくつかの実施形態では、パケット・バッファは、各パケット・バッファ内に十分なヘッドルーム及びテイルルームを過剰に割り当てて、バッファのコピーを必要とせずに外部ネットワーク層のヘッダを追加/削除することができるカプセル化/デカプセル化の操作をサポートするエムバフ(Mbuf)パラダイムなどの方法を用いることができる。
ロード・バランサ・ノード110の少なくともいくつかの実施形態では、DPDK技術を活用するコア・パケット処理アーキテクチャを実装することができる。各ロード・バランサ・ノード110は、コア・パケット処理アーキテクチャにより実装された少なくとも1つの多重コア・パケット・プロセッサを含むことができる。コア・パケット処理アーキテクチャは、多重コア・パケット・プロセッサのキュー及びコアによって単一生産者/単一消費者のパラダイムをパケット・フローに用いることができる。このパラダイムでは、各キューは、それがパケットを供給するコアを唯一のコアに入力し、各コアはそれがパケットを供給するコアを唯一のコアに互いに出力する。加えて、多重コア・パケット・プロセッサ内のコアが使用するメモリは共有されない。すなわち、各コアは固有の分離したメモリ領域を有している。したがって、コア間でのメモリまたはキューの共有はなく、メモリまたはキューのコンテンションはなく、かつ、所有権の要求(RFO)または比較交換(CAS)などのメモリまたはキューを共有するメカニズムの必要性はない。図25、26は、コア・パケット処理アーキテクチャにより実装された多重コア・パケット・プロセッサの例を示す。
図25は、少なくともいくつかの実施形態による、データ・フロー処理にDPDK技術を活用するコア・パケット処理アーキテクチャにより実装された多重コア・パケット・プロセッサの例を示す。コア・パケット処理アーキテクチャは、単一生産者/単一消費者のパラダイムによる多重コア・パケット・プロセッサとして実装することができる。少なくともいくつかの実施形態では、図23に示すように、ロード・バランサ・ノード110は各々2つのネットワーク・インターフェイス・コントローラ(NIC)、すなわち、境界ネットワーク/エッジ・ルータ104に面する北向きNIC1114Aと生産ネットワーク/サーバ・ノード130に面する南向きNIC1114B、を有する。少なくともいくつかの実施形態では、NIC1114は10GpbsNICであってよい。ロード・バランサ・ノード110を通って流れる大多数のパケットは、これらの2つのNICのうちの1つ(NIC1114AまたはNIC1114Bのいずれか)で受け取られ、処理され(例えば、カプセル化されるか、またはデカプセル化される)、そして、他のNIC(NIC1114BまたはNIC1114Aのいずれか)に送信される。
図25を参照すると、少なくともいくつかの実施形態では、ロード・バランサ・ノード110は、各NIC1114に対して、2つのCPUコア、受信(RX)コア610および送信(TX)コア630に回転をつける。ロード・バランサ・ノード110はまた、両方向の両NIC1114のパケットを処理するいくつかのワーカ・コア620にも回転をつけ、この例では、ワーカ・コア620A〜620Dが使用されている。受信コア610はそれらの入力キューからの着信パケット群がNIC1114に到達したときこれらを読み、各パケットに対する作業のほとんどを行うワーカ・コア620にこれらのパケットを分散させるが、その際、各受信コア610は各ワーカ・コア620のそれぞれのワーカ入力キュー612にパケットを供給する。少なくともいくつかの実施形態では、受信コア610は、いかなる特別なクライアント接続(そのIPアドレスとポートによって区別される)も同じワーカ・コア620で処理されることを保障しつつ各着信パケットに4層「フロー・ハッシュ」技法(以前に説明したような、エッジ・ルータ104が用いることができるフロー単位ハッシュ化多重パス経路指定技法に類似)を実施してワーカ・コア620にパケットを分散させることができる。これは、各ワーカ・コア620がパケットの同じサブセットを常に見ることができ、ロックを必要としないように、ワーカ・コア620によって管理されたステート・データ上のコンテンションを除去することを意味する。受信パケットへのポインタは、ワーカ・コア620が絶えず新しい入力をモニターするワーカ・キュー622全体にわたって分散させることができる。ワーカ・コア620は、各接続の状態(例えば、指定されたサーバ・ノード130)を管理する責任を負い、パケットを自身のアウトバウンド・キュー632の1つに転送する前にパケットのUDPカプセル化またはデカプセル化を行うことができる。送信コア630は、ワーカ・コア620のアウトバウンド・キュー632を巡回して出力パケットがキュー632上に現れるときにこの出力パケットを自身の対応するNIC1114に記入する。
図26は、少なくともいくつかの実施形態による、データ・フロー処理のDPDK技術を活用するコア・パケット処理アーキテクチャによって実装された別の多重コア・パケット・プロセッサの例を示す。コア・パケット処理アーキテクチャは、単一生産者/単一消費者のパラダイムによる多重コア・パケット・プロセッサとして実装することができる。少なくともいくつかの実施形態では、高スループット・クライアントTCPフローの処理に加えて、ロード・バランサ・ノード110に関するDPDKコア・アーキテクチャはまた、ARP、DHCP及びBGPなどの他のプロトコルの場合に北及び南に面するNIC1114上でパケットを送受信するために使用することもできる。図26に示される実施形態では、ワーカ・コア620Aはこれら他のプロトコルの場合のパケットの取り扱いに専念する。これらのパケットの処理が一般にクライアントTCPフローの処理よりゆっくりと起こるので、このワーカ・コア620Aを「遅い」ワーカ・コアと呼ぶ場合があり、一方、クライアントTCPフローのみを処理する他のワーカ・コア620B−620Dを速いワーカ・コアと呼ぶ場合がある。北に面するNIC1114及び南に面するNIC1114上の着信パケットを取り扱う受信コア610A及び受信コア610Bは、それぞれ、遅いワーカ・コア620Aで取り扱われるべきパケットを識別し、これらのパケットを遅いワーカ・コア620Aの入力キュー622に向けることができる。遅いワーカ・コア620Aはまた、Java/JNIによって生成されたパケットの入力キュー622及びJava/JNIへの出力パケットの出力キュー634をモニターすることもできる。遅いワーカ・コア620Aはまた、遅いワーカ・コア620Aが、速いワーカ・コア620B〜620Dのそれぞれにパケット(例えば、接続公表パケット)を送ることができるように、速いワーカ・コア620B〜620Dのそれぞれの入力キュー622に出力もする。遅いワーカ・コア620Aはまた、送信コア630A及び630Bのそれぞれに配給されるアウトバウンド・キュー632も有している。
少なくともいくつかの実施形態では、速いワーカ・コア620B〜620Dそれぞれの第三の入力キュー622は、遅いワーカ・コア620Aからの出力キューである。少なくともいくつかの実施形態では、この第三の入力キュー622は、例えば、それぞれが接続状態情報を含む接続公表パケットを速いワーカ・キュー620B〜620Dが受信し処理するのに用いることができる。これらの接続公表パケットの少なくともいくつかに関しては、送信コア630への出力が存在しない場合がある。その代わり、パケット内の接続状態情報は、速いワーカ・コア620により、例えば、それぞれの速いワーカ・コア620が維持する格納された1つまたは複数のパケット・フローの状態を更新するのに消費される場合がある。したがって、速いワーカ・コア620B〜620Dに入力する、遅いワーカ・コア620Aからの出力キューは、入力キュー622以外の、速いワーカ・コアに格納された状態を更新する受信コア610からの直接的な経路を提供することができる。
少なくともいくつかの実施形態では、図25、26の多重コア・パケット・プロセッサは、着信パケットにフィルターをかけ、有効なパケットだけを処理し出力することができる。例えば、少なくともいくつかの実施形態では、受理コア610は、パケットにフィルターをかけてワーカ・コア620のどれにも支援されないプロトコルのパケットを取り除き、これらのパケットがワーカ・コア620に送られないようにすることができる。少なくともいくつかの実施形態では、ワーカ・コア620はそれぞれ、パケットを処理する際に、それぞれのワーカ入力キュー622から読んだパケットを先ず分析してこれらのパケットを更に処理して送信コア630に出力することが受理されるかどうかを判断し、受理されたパケットの処理及び送信コア630への出力のみを終了し、受理されないパケットを廃棄することができる。例えば、ワーカ・コア620は各パケットのアドレス情報を見て、負荷分散された有効なアドレスで標的とされたパケットのみを受理し、他のいかなるパケットも廃棄することができる。
境界ゲートウェイ・プロトコル(BGP)データの取り扱い
少なくともいくつかの実施形態では、コア・アーキテクチャの中外でBGPクライアントに関連したパケット・フローは、以下のように扱うことができる。NIC1114A及び1114Bは、リナックス・カーネルに結合していないので、エッジ・ルータ104へのTCP接続は、図26に示すようなコア・アーキテクチャによって傍受され、出力キュー634経由でBGPパケットをジャバ空間に伝える遅いワーカ・コア622Aによって処理される。これらのTCPパケットは、TCP接続を管理しパケットを効果的にTCPストリーム内に移動させるためのリナックス・カーネルによる処理を含んで、BGPクライアントに送達される前にロード・バランサ・ノード110上の1つまたは複数のモジュールによってさらに処理される。このデザインにより、標準的なジャバTCPソケット・ライブラリを用いてBGPクライアントを書くことが可能になる。
図27は、少なくともいくつかの実施形態にしたがう、ロード・バランサ(LB)ノード・プロセス650による着信BGP TCPパケットの処理を示す。エッジ・ルータ104からのパケットは北に面するNIC640に到着し、受信コア652の入力キュー640に入る。受信コア652は、キュー640からのパケットを読み、このパケットをBGPパケットとして識別し、遅いワーカ・コア656の入力キュー654にパケットを載置する。遅いワーカ・コア656はパケットを認証し、JNI出力キュー658にそれを載置する。JNIパケットのレシーバ660はJNIを介してキュー658からのパケットを読み、ソース/宛先アドレスをマングリングし、パケットをロウ(raw)ソケット644に書きこむ。リナックス・カーネル646は、ロウ(raw)パケットを受信し、それをTCPプロトコルにより取り扱い、ペイロード・データをTCPソケットの入力ストリームに追加する。パケットからのデータは、その後、BGPクライアント662内のジャバTCPソケットに送達される。
図28は、少なくともいくつかの実施形態による、ロード・バランサ(LB)ノード・プロセス650による発信BGP・TCPパケットの処理を示す。BGPクライアント662はリナックス・カーネル646のジャバTCPソケットにデータを書きこむ。リナックス・カーネル646はTCPプロトコルによってデータを取り扱い、データをTCPパケットに変換する。少なくともいくつかの実施形態では、TCPパケットは127.x.x.x iptables規則と一致する。TCPパケットは出力キュー648、例えば、Netfilter LOCAL_OUTキューに載置される。JNIを介してキュー648をモニターするJNIパケット・レシーバ670のジャバ・スレッドは、TCPパケットを受信し、各NF_STOLENをマークしてカーネル646にそれらを忘れさせる。ジャバ・スレッドは、ソース/宛先アドレスをマングリングし、JNIを介して遅いワーカ・コア656のJNI入力キュー672にパケットを加える。遅いワーカ・コア656はそのJNI入力キュー672からTCPパケットを受信し、このパケットを北に面するNIC640の送信コア666のアウトバウンド・キュー664に載置する。送信コア666はその入力キュー664からTCPパケットを読み取り、それらを北に面するNIC640に書き込む。TCPパケットはNIC640によりエッジ・ルータ104に送られる。
分散型ロード・バランサのシミュレーション及びテスト
本明細書に記述されたロード・バランサは、多くの独立したコンポーネント(例えば、ルータ、ロード・バランサ・ノード、ロード・バランサ・モジュールなど)の相互作用を必要とする分散型システムである。分散されたコンポーネント、ロジック、プロトコルのテストを行ない、かつ、ノード故障、メッセージ欠落、遅延などのシナリオをシュミュレートするために、複雑なネットワーク技術(例えば、生産ネットワーク)における多数のホストに設置すべきコードを必要とせずに相互作用をテストできる単一のプロセスで分散型ロード・バランサを動作させることができるテスト・システムの実施形態が記述される。これを達成するために、ロード・バランサの多数のコンポーネントが構成され、単一のプロセスでまたは単一のプロセスとして実行されることが可能となるメッセージ・バスと呼ばれるソフトウェア・メカニズムが記述される。この単一のプロセスは単一のホスト・システム上で実行することができる。メッセージ・バスのメカニズムは、分散型ロード・バランサ・システムを、例えば、単一のホスト・システム上で、単一のシステムとしてテストできるようにする。一方、ロード・バランサのコンポーネント(例えば、ロード・バランサ・ノード及びロード・バランサ・モジュール)に対しては、これらのコンポーネントは実際の生産ネットワーク上で動作するように見える。
メッセージ・バスは、分散型ロード・バランサが単一のプロセスとして動作できるようにする枠組みを提供する。このプロセスでの1つまたは複数のメッセージ・バス層のそれぞれは、分散型ロード・バランサのコンポーネント間のネットワーク(例えば、イーサネット)セグメントをシミュレートする。分散型ロード・バランサ・システムのソフトウェア・コンポーネントは、コンポーネントがメッセージ・バス環境で動作できるようにするために特別な様式で書かれる必要はない。代わりに、メッセージ・バスの枠組みでは、分散型ロード・バランサ・システムのコンポーネントが生成するパケットを傍受し、実際の物理的なネットワークではなくメッセージ・バス層によって提供されるシミュレートされたネットワークにパケットを向け、標的のコンポーネント<メッセージ・バスNICまたはパケット・アダプタと処され得る)にパケットを送達する。メッセージ・バス層は、コンポーネント間の通信用のTCP/IPスタックを実装しない。代わりに、メッセージ・バス層は、ホスト・システムのオペレーティングシステム(OS)とインターフェイス接続し、ホスト・システムのTCP/IPスタックを使用する。メッセージ・バス層は、OSによって提供されるTCP/IPスタックを利用して、クライアントとサーバが予測するTCPストリームをメッセージ・バスが傍受して送達する個々のパケットに変換し、かつそれらのパケットから変換する。
少なくともいくつかの実施形態では、メッセージ・バスとインターフェイス接続するために、ロード・バランサのコンポーネントが、それぞれが有効なメディア・アクセス・コントロール(MAC)アドレスを有しており、物理的なネットワークではなくメッセージ・バス擬似ネットワーク環境にパケットを送信し、そこからパケットを受信する少なくとも1つのメッセージ・バス・ネットワーク・インターフェイス・コントローラ(NIC)を備えることができる。メッセージ・バスNICは、物理的なネットワークにではなくメッセージ・バスに取り付けられた仮想のネットワーク・インターフェイス・コントローラである。メッセージ・バスによって通信する必要のあるロード・バランサのコンポーネントは、それぞれ、少なくとも1つのメッセージ・バスNICを必要とする。メッセージ・バスNICは、メッセージ・バスへのパイプライン出口及びコンポーネントへのパイプライン入口の働きをする。コンポーネントは、各メッセージ・バスNICに対する多数のメッセージ・バス・ネットワーク・インターフェイスを実証することができる。
メッセージ・バス・ネットワーク・インターフェイスは、コンポーネントがメッセージ・バスNICを介してメッセージ・バスに結合するメカニズムである。メッセージ・バス・ネットワーク・インターフェイスは、メッセージ・バス・ネットワーク・インターフェイスが物理的なネットワークにではなくメッセージ・バスに結合するという違いはあるが、リナックス技術でのインターフェイス構成(ifconfig)インターフェイスと同意語であり得る。メッセージ・バス・ネットワーク・インターフェイスは、IPアドレスを有しており、メッセージ・バスNICの上に位置する。メッセージ・バス・ネットワーク・インターフェイスは、コンポーネントがメッセージ・バスからパケットを受け取るために使用することができるパケット・ソース・インターフェイスと、コンポーネントがメッセージ・バスにパケットを送るために使用することができるパケット・シンク・インターフェイスとを露出させる。
各ロード・バランサ・ノードは、パケット・ソース・インターフェイスとパケット・シンク・インターフェイスの実装によって送達され送られた個々のネットワーク・パケットを処理する。メッセージ・バス環境内で動作するときは、これらのインターフェイスは、2層イーサネット・ヘッダ(これがカーネル・ネットワーク・スタックによって行なわれることを予測するロード・バランサ・ノードの)を追加または除去するメッセージ・バス・ネットワーク・インターフェイスによって実装される。図29に示すような生産環境では、パケット・ソース・インターフェイスとパケット・シンク・インターフェイスの実装で、実際のネットワーク・インターフェイス上でパケットを送受信する。図30に示すようなメッセージ・バス環境では、パケット・ソース・インターフェイスとパケット・シンク・インターフェイスの実装で、メッセージ・バス層からパケットを受信し、メッセージ・バス層にパケットを送信する。
単純化のために、メッセージ・バスNIC及びメッセージ・バス・インターフェイスをメッセージ・バス・パケット・アダプタ、または単にパケット・アダプタと総称することができる。例えば、図31、32を参照されたい。
図29は、少なくともいくつかの実施形態による、生産環境での分散型ロード・バランサ700を含むロード・バランシング・システムを示す。ロード・バランサ700はこの説明では単純化されている。ロード・バランサ700は、ロード・バランサ700を実装するデータ・センタなどのネットワーク設備の境界ルータ702を介して外部ネットワーク740上のクライアント742と接続することができる。ロード・バランサ700は、数種類のコンポーネント、すなわち、それぞれ分離したサーバ・ノード(図示せず)上に実装された、少なくとも1つのエッジ・ルータ704、2つまたはそれ以上のロード・バランサ(LB)ノード710、2つまたはそれ以上のロード・バランサ(LB)モジュール732、ルータまたはスイッチなどのファブリック720を形成する2つまたはそれ以上のネットワーク・コンポーネント、及び、少なくともいくつかの実施形態では、構成サービス722を、含む。少なくともいくつかの実施形態では、ロード・バランサ700の各コンポーネントは、市販のラックマウント方式のコンピューティング・デバイスなどの個別のコンピュータとして実装することができ、または個別のコンピューティング・デバイス上に実装することができる。
図30は、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムの多数のコンポーネントが構成され単一のプロセスでまたは単一のプロセスとして実施できるようにするメッセージ・バス・メカニズムを組込んだ分散型ロード・バランサ評価システム800を示す。図29に示すロード・バランサ700には、各ロード・バランサ・ソフトウェア・コンポーネントが別個のコンピューティング・デバイス(例えば、ロード・バランサ・ノード710上のロード・バランサ・ソフトウェア、及びサーバ・ノード上のロード・バランサ・モジュール732)にインストールされ実行される。これらのロード・バランサ・ソフトウェア・コンポーネントが単一のプロセスで実行できるようにするために、各ロード・バランサ・ソフトウェア・コンポーネント(図30にロード・バランサ(LB)ノード810及びロード・バランサ(LB)モジュール832として示す)は、ロード・バランサ・ソフトウェアの内外のパケットも、物理的なネットワーク上に送受信されるのではなくメッセージ・バス・メカニズムによって傍受され経路指定され得るようにコンポーネントのネットワーク接続性を抽象化するコードを含むことができる。
少なくともいくつかの実施形態では、分散型ロード・バランサ・テスト・システム800では、メッセージ・バス・メカニズムは、コンポーネント間の通信用のTCPスタックを実装していない。代わりに、メッセージ・バス・メカニズムは、ホスト・システムのオペレーティング・システム(OS)とインターフェイス接続し、ホスト・システムのTCPスタックを使用する。少なくともいくつかの実施形態では、メッセージ・バスの機能性は、IPテーブルを介して、ユーザ層の下のホスト・システムのOSのカーネル(例えば、リナックス・カーネル)に、すなわち、カーネルの機能性に結合する。メッセージ・バスの機能性は、カーネルのレベルでIPテーブルに接続し、パケットを傍受し、経路指定用のメッセージ・バス・プロセスにこれらのパケットを送る。
図30の擬似のエッジ・ルータ862及び擬似のファブリック864により示されるように、物理的なネットワーク・コンポーネント(例えば、図29のエッジ・ルータ704及びファブリック720)の機能は、クライアント860、サーバ834及び構成サービス866ができるように、ソフトウェアの中でシミュレーションすることができる。しかし、少なくともいくつかの実施形態では、擬似ではない実際のサーバ834を、分散型ロード・バランサ・テスト・システム800で使用することができることに留意されたい。図30のメッセージ・バス層850は物理的なネットワーク・インフラに置き換わる。したがって、ロード・バランサ・ソフトウェア・コンポーネント(ロード・バランサ・ノード810及びロード・バランサ・モジュール832)は、図29に示すような生産ネットワーク環境で実行していないことに気付かずにロード・バランサ・テスト・システム800内で動作することができる。
いくつかのコンポーネント(例えば、擬似のルータ)は、ネットワーク・セグメントをシミュレーションする相異なるメッセージ・バス層850にパケットを渡しかつそれらのメッセージ・バス層850からパケットを受け取るために、2つ以上のメッセージ・バス層850に接続することができる。
分散型ロード・バランス・テスト・システム800のメッセージ・バス層850に実装されたメッセージ・バス・メカニズムは、ネットワーク・セグメントの「ワイヤ」をシミュレーションする。少なくともいくつかの実施形態では、メッセージ・バス・メカニズムは、コンポーネントのMACアドレスに基づいて分散型ロード・バランス・テスト・システム800の宛先コンポーネントにパケットを送達する。したがって、各ロード・バランサ・ソフトウェア・コンポーネント(ロード・バランサ・ノード810およびロード・バランサ・モジュール832)は、ロード・バランサ・ソフトウェア・コンポーネントが分散型ロード・バランス・テスト・システム800の他のコンポーネントから送られたパケットを受信できるように接続されているメッセージ・バス層850にMACアドレスを提供する。
メッセージ・バス・パケット・アダプタ
図31、32は、少なくともいくつかの実施形態による、メッセージ・バス・パケット・アダプタを示す。少なくともいくつかの実施形態では、ロード・バランサ(LB)ソフトウェアの各コンポーネントは、パケット・ソース・インターフェイス及びパケット・シンク・インターフェイスの実装を通して送達され送られる個々のネットワーク・パケットを有している。図31を参照すると、分散型ロード・バランス・テスト・システム800で動作するとき、これらのインターフェイス(パケット・ソース・インターフェイス862及びパケット・シンク・インターフェイス864として示されている)は、メッセージ・バス層850とロード・バランサ・ソフトウェア・コンポーネント870の間のパケット・アダプタ860によって実装されることができる。このパケット・アダプタ860は、これがカーネル・ネットワーク・スタックによって行われると予測するロード・バランサ・ソフトウェア・コンポーネント870に対する2層イーサネット・ヘッダを加えるかまたは削除する。図29に示すような生産環境では、ロード・バランサ・ソフトウェア・コンポーネントに対してパケット・ソース及びパケット・シンクを実装することにより、これらのコンポーネントが実装されている物理的なデバイスの実際のネットワーク・インターフェイス上のパケットが送受信される。
図31を参照すると、少なくともいくつかの実施形態では、ロード・バランサ・ソフトウェア・コンポーネント870がパケットを送信するときに、パケット・シンク・インターフェイス864の送信パケット法を呼び出す実行スレッドは、パケット・アダプタ860内及びメッセージ・バス層850内の一連の機能を横切っていき宛先コンポーネントの入力キューにパケットを加えることにより最終的に宛先コンポーネントのパケットを送達する。少なくともいくつかの実施形態では、ロード・バランサ・ソフトウェア・コンポーネント870がパケットを受信するときに、ロード・バランサ・ソフトウェア・コンポーネント870はパケット・ソース・インターフェイス862の受信パケット法を呼び出し、その入力キューからパケットを読む。少なくともいくつかの実施形態では、メッセージ・バス・メカニズムは、パケットを送達するのに自身のどんな追加のスレッドも必要としない。
メッセージ・バス・パケット・パイプライン
図32を参照すると、少なくともいくつかの実施形態では、パケット・ソース・インターフェイス862及びパケット・シンク・インターフェイス864のメッセージ・バス850側に、パケット・パイプラインのフィーチャーが提供される。ロード・バランサ・ソフトウェア・コンポーネント870がパケット・シンク・インターフェイス864を介してパケットを送信するとき、パケット・データはメッセージ・バス層850に到達する前に一連の段階(パケット・パイプライン880)を横切っていくことができる。これらの段階では、パケットを修正し、パケットを落とし、パケットを複製し、パケットを遅らせる等のことができる。一旦、パケットがパケット・パイプライン880を横切っていき、メッセージ・バス層850が宛先コンポーネント870を選択すると、パケットはまた、宛先コンポーネント870の入力キューに加えられる前に宛先コンポーネント870に関連した2番目の一連のパイプライン段階(パケット・パイプライン882)を横切っていくこともできる。
プロバイダ・ネットワーク環境の例
このセクションでは、分散型ロード・バランシングの方法及び装置の実施形態を実装することができるプロバイダ・ネットワーク環境について説明する。しかし、これらのプロバイダ・ネットワーク環境の例は、それらに限定することは意図されていない。
図33Aは、少なくともいくつかの実施形態による、プロバイダ・ネットワーク環境の例を示す。プロバイダ・ネットワーク1900は、クライアントが、限定するものではないが、プロバイダ・ネットワーク内あるいは1つまたは複数のデータ・センタ内のデバイスに実装された計算リソース及びストレージ・リソースを含む仮想化されたリソースの実例1912にアクセスし、それを購入し、それを借り、または別の方法でそれを取得することができるようにする1つまたは複数の仮想化サービス1910を介して、クライアントにリソース仮想化を提供することができる。プライベートIPアドレス1916は、リソースの実例1912と関連付けることができ、プライベートIPアドレスは、プロバイダ・ネットワーク1900上のリソース実例1912の内部ネットワーク・アドレスである。いくつかの実施形態では、プロバイダ1900はまた、クライアントがプロバイダ1900から得ることができるパブリックIPアドレス1914及び/またはパブリックIPアドレス領域(例えばインターネット・プロトコル・バージョン4(IPv4)またはインターネット・プロトコル・バージョン6(IPv6)のアドレス)も提供することができる。
従来は、プロバイダ・ネットワーク1900は、仮想化サービス1910を介して、サービス・プロバイダのクライアント(例えばクライアント・ネットワーク1950Aを運営するクライアント)がクライアントに割り当てられた少なくともいくつかのパブリックIPアドレス1914をクライアントに割り当てられた特別なリソース実例1912を結びつけることができるようにする。プロバイダ・ネットワーク1900はまた、クライアントが、クライアントに割り当てられた1つの仮想化計算リソース実例1912に以前にマッピングされたパブリックIPアドレス1914を、クライアントに割り当てられた別の仮想化計算リソース実例1912に再マッピングすることができるようにする。サービス・プロバイダに提供された仮想化計算リソース実例1912とパブリックIPアドレス1914を用いて、クライアント・ネットワーク1950Aのオペレータなどのサービス・プロバイダのクライアントは、例えば、クライアントに特有なアップリケーションを実装し、インターネットなどの中間ネットワーク1940上にクライアントのアプリケーションを提示することができる。中間のネットワーク1940上の他のネットワーク実体1920は、その後、クライアント・ネットワーク1950Aによって公表された、宛先パブリックIPアドレス1914へのトラフィックを生成することができる。このトラフィックは、サービス・プロバイダ・データ・センタに経路指定され、このデータ・センタでネットワーク基板を介して宛先パブリックIPアドレス1914に現在マッピングされている仮想化計算リソース実例1912のプライベートIPアドレス1916に経路指定される。同様に、仮想化計算リソース実例1912からの応答トラフィックはネットワーク基板を介して中間ネットワーク1940に戻ってソース実体1920まで経路指定され得る。
本明細書で使用されるようなプライベートIPアドレスは、プロバイダ・ネットワークでのリソース・インスタンスの内部ネットワーク・アドレスを参照する。プライベートIPアドレスは、プロバイダ・ネットワーク内でのみ経路指定することができる。プロバイダ・ネットワークの外部に起因するネットワーク・トラフィックはプライベートIPアドレスに直接経路指定されず、代わりに、このトラフィックはリソース・インスタンスにマッピングされたパブリックIPアドレスを用いる。プロバイダ・ネットワークは、ネットワーク・アドレス変換(NAT)または類似の機能を提供してパブリックIPアドレスからプライベートIPアドレスへのマッピング及びその逆も行うネットワーク・デバイスまたはアプライアンスを含むことができる。
本明細書で使用されるようなパブリックIPアドレスは、サービス・プロバイダまたはクライアントのどちらかによってリソース・インスタンスに割り当てられる、インターネット経路指定可能なネットワーク・アドレスである。パブリックIPアドレスに経路指定されたトラフィックは、例えば、1:1ネットワーク・アドレス変換(NAT)を介して変換され、リソース・インスタンスのそれぞれのプライベートIPアドレスに転送される。
いくつかのパブリックIPアドレスを、プロバイダ・ネットワーク・インフラによって特別のリソース・インスタンスに割り当てることができ、これらのパブリックIPアドレスは、標準パブリックIPアドレスまたは単に標準IPアドレスと呼ぶことができる。少なくともいくつかの実施形態では、標準IPアドレスのリソース・インスタンスのプライベートIPアドレスへのマッピングは、リソース・インスタンス・タイプすべての初期立上げ構成である。
少なくともいくつかのパブリックIPアドレスはプロバイダ・ネットワーク1900のクライアントに割り当てられるか、またはこのクライアントが獲得することができる。その後、クライアントはこれらの割り当てられたパブリックIPアドレスをクライアントに割り当てられた特別なリソース・インスタンスにあてがうことができる。これらのパブリックIPアドレスをクライアント・パブリックIPアドレス、または単にクライアントIPアドレスと呼ぶことができる。クライアントIPアドレスは、標準IPアドレスの場合のようにプロバイダ・ネットワーク1900によりリソース・インスタンスにあてがわれる代わりに、クライアントにより、例えば、サービス・プロバイダにより提供されたAPIを介してあてがわれることができる。標準IPアドレスとは異なり、クライアントIPアドレスは、それぞれのクライアントによりクライアント・アカウントに割り当てられ、必要に応じて、または望むなら、他のリソース・インスタンスに再マッピングされることができる。クライアントIPアドレスは特別のリソース・インスタンスにではなくクライアントのアカウントに関連付けられている。そして、クライアントがこのIPアドレスを手放すことを選択するまで、クライアントはこのIPアドレスをコントロールする。従来の静的なIPアドレスと異なり、クライアントIPアドレスは、クライアントがクライアントのアカウントに関連付けられた任意のリソース・インスタンスにクライアントのパブリックIPアドレスを再マッピングすることにより、リソース・インスタンスまたは利用可能ゾーンの故障を覆うことができるようにする。クライアントIPアドレスは、例えば、クライアントが、代替リソース・インスタンスにクライアントIPアドレスを再マッピングすることでクライアントのリソース・インスタンスまたはソフトウェアの問題を、巧みに処理できるようにする。
図33Bは、少なくともいくつかの実施形態による、図33Aで示したプロバイダ・ネットワーク環境の例における分散型ロード・バランサの実装を示す。プロバイダ・ネットワーク1900は、クライアント1960に、サービス1910、例えば、仮想化ストレージ・サービスを提供することができる。クライアント1960は、例えば、サービス1910への1つまたは複数のAPIを介して、サービス1910にアクセスしてプロバイダ・ネットワーク1900の生産ネットワーク部の複数のサーバ・ノード1990上に実装されたリソース(例えば、ストレージ・リソースまたは計算リソース)の利用を得ることができる。サーバ・ノード1990はそれぞれ、サーバ(図示せず)(例えば、ウェブ・サーバまたはアプリケーション・サーバ)、並びに、ローカル・ロード・バランサ(LB)モジュール1992を実装することができる。1つまたは複数の分散型ロード・バランサ1980は、境界ネットワークと生産ネットワークの間のロード・バランサ層に実装することができる。境界ルータ1970は、インターネットなどの中間ネットワーク1940を介して、クライアント1960からのパケット・フローのパケット(例えば、TCPパケット)を受信し、境界ネットワークを介して分散型ロード・バランサ1980のエッジ・ルータにこれらのパケットを転送することができる。パケットは、分散型ロード・バランサ1980のエッジ・ルータによって公表されたパブリックIPアドレスを標的にすることができる。各分散型ロード・バランサ1980のエッジ・ルータは、分散型ロード・バランサ1980それぞれのロード・バランサ・ノード間にパケット・フローを分散させることができる。少なくともいくつかの実施形態では、入口ノードとして働くロード・バランサ・ノードはそれぞれ、同じパブリックIPアドレスをエッジ・ルータに広告し、エッジ・ルータは、クライアント1960からのパケット・フローを、フロー単位ハッシュ化多重パス経路指定技法(例えば、等コスト多重パス(ECMP)ハッシング技法)により、入口サーバ間に分散させる。ロード・バランサ・ノードは、本明細書で説明した接続プロトコルを用いてパケット・フローの標的サーバ・ノード1990を決定し、サーバとクライアント1960の間の接続を促すことができる。一旦接続が確立されれば、入口ノードは、フロー・トラッカ・ノードが接続の状態を維持する間に、生産ネットワーク上の標的サーバ・ノード1990へのフロー用に受信したパケットをカプセル化し送信する。サーバ・ノード1990上のロード・バランサ・モジュール1992は、サーバ・ノード1960上のそれぞれのサーバが接続を受理するかどうかについての決定を行うことができる。ロード・バランサ・モジュールは入口ノードからパケットを受信してデカプセル化し、サーバ・ノード1990上のそれぞれのサーバにデカプセル化したパケット(例えば、TCPパケット)を送信する。ロード・バランサ・モジュール1992はまた、パケット・フローの出口ノードとしてロード・バランサ・ノードを選択し、生産ネットワークを介して、選択した出口ノードにフローの発信パケットを送信することもできる。出口ノードは、次に、パケットをデカプセル化し、それぞれのクライアント1960に送達するためにデカプセル化パケットを境界ネットワークに送信する。
図34Aは、少なくともいくつかの実施形態による分散型ロード・バランサ及びサーバ・ノードの物理的なラック実装の例を示すが、これに限定する意図はない。少なくともいくつかの実施形態では、分散型ロード・バランサの様々なコンポーネントを市販のラック・マウント方式のコンピューティング・デバイス上にまたはかかるコンピューティング・デバイスとして実装することができる。ラック190は、それぞれロード・バランサ・ノード(LBノード110A〜110F)として働く複数のコンピューティング・デバイス及びそれぞれサーバ・ノード(サーバ・ノード130A〜130L)として働く複数のコンピューティング・デバイスを含むことができる。ラック190はまた、少なくとも1つのエッジ・ルータ104、ファブリック120を形成する1つまたは複数のラックマウント方式のネットワーキング・デバイス(ルータ、スイッチなど)、及び1つまたは複数の他のコンポーネント180(他のネットワーキング・デバイス、パッチパネル、電源、冷却システム、バスなど)も含むことができる。図33A、33Bのプロバイダ・ネットワーク1900を実装する1つまたは複数のデータ・センタなどのネットワーク100の設備は1つまたは複数のラック190を含むことができる。
図34Bは、少なくともいくつかの実施形態による分散型ロード・バランサ及びサーバ・ノードの物理的なラック実装の別の例を示すが、これに限定する意図はない。図34Bは、スロット・マウント方式のコンピューティング・デバイス、例えば、ラック190内のブレード・サーバとして実装されたLBノード110及びサーバ・ノード130を示す。
図35は、少なくともいくつかの実施形態による、サーバ・ノードが別個に実装されて1つ、2つまたはそれ以上の分散型ロード・バランサがネットワークに実装できるネットワーキング環境の例を示す。この例では、2つの分散型ロード・バランサ1980A、1980Bが示されている。分散型ロード・バランサ1980はそれぞれ、境界ネットワークを介してクライアント1960からパケット・フローを受信し、本明細書で説明したロード・バランシング法を行って複数のサーバ・ノード1990全体にわたってパケット・フローを分散させることができる。いくつかの実装形態では、各分散型ロード・バランサ1980は図34A、34Bに示したラック190に類似しているが、ロード・バランサ・ラックに取り付けられたサーバ・ノードがないラック実装形態であり得る。サーバ・ノード1990は、データ・センタ内の1つまたは複数の別個のラックに取り付けられたブレード・サーバなどのラックマウント方式のコンピューティング・デバイスでよい。いくつかの実装形態では、サーバ・ノード1990は、プロバイダ・ネットワークによって提供される2つ以上の異なるサービスを実装することができ、各サービスは異なる1つまたは複数のロード・バランサ1980よって率いられる。
例示的システム
少なくともいくつかの実施形態では、本明細書で説明したような分散型ロード・バランシングの方法及び装置の一部またはすべてを実装するサーバは、図36に示したようなコンピュータ・システム2000などの1つまたは複数のコンピュータ・アクセス可能なメディアを含むか、または、かかるメディアにアクセスするように構成された汎用コンピュータ・システムを含むことができる。例示した実施形態では、コンピュータ・システム2000は、入出力(I/O)インターフェイス2030を介してシステム・メモリ2020に結合した1つまたは複数のプロセッサ2010を含む。コンピュータ・システム2000は、I/Oインターフェイス2030に結合したネットワーク・インターフェイス2040をさらに含む。
様々な実施形態では、コンピュータ・システム2000は、1つのプロセッサ2010を含むユニプロセッサ・システム、または数個(例えば2、4、8個またはその他の適切な個数)のプロセッサ2010を含む多重プロセッサ・システムであってよい。プロセッサ2010は命令を実行することができる任意の適切なプロセッサであってよい。例えば、様々な実施形態では、プロセッサ2010は、x86、パワーPC、SPARC、またはMIPS・ISAなどの様々な任意の命令セット・アーキテクチャ(ISA)、あるいは他の任意の適切なISAを実装している汎用プロセッサまたは埋め込みプロセッサであってよい。重プロセッサ・システムでは、各プロセッサ2010は、必ずではないが、通常、同じISAを実装することができる。
システム・メモリ2020は、プロセッサ2010によりアクセス可能な命令及びデータを格納するように構成することができる。様々な実施形態では、システム・メモリ2020は、スタティック・ランダム・アクセス・メモリ(SRAM)、シンクロナス・ダイナミックRAM(SDRAM)、不揮発性/フラッシュ型メモリ、または、他の任意のタイプのメモリなどの任意の適切なメモリ技術を用いて実装され得る。例示した実施形態では、分散型ロード・バランシングの方法と装置につき上記で説明した方法、技術、及びデータの機能などの1つまたは複数の所望の機能を実装するプログラム命令及びデータが、システム・メモリ2020内にコード2024及びデータ2026として格納されて示されている。
1つの実施形態では、I/Oインターフェイス2030は、プロセッサ2010、システム・メモリ2020、及び、ネットワーク・インターフェイス2040または他の周辺インターフェイスを含むデバイス内の任意の周辺デバイスの間のI/Oトラフィックを調整するように構成することができる。いくつかの実施形態では、I/Oインターフェイス2030は、いかなる必要なプロトコル、タイミングまたは他のデータの変換も実行して、1つのコンポーネント(例えば、システム・メモリ2020)からのデータ信号を別のコンポーネント(例えば、プロセッサ2010)が用いるのに適したフォーマットに変換することができる。いくつかの実施形態では、例えば、I/Oインターフェイス2030は、例えば、周辺装置相互接続(PCI)バス標準または汎用シリアル・バス(USB)標準の変形などの様々なタイプの周辺バスを通して取り付けられたデバイス用のサポートを含むことができる。いくつかの実施形態では、I/Oインターフェイス2030の機能を、例えば、北ブリッジ及び南ブリッジなどの1つまたは複数の別個のコンポーネントに分割することができる。また、いくつかの実施形態では、システム・メモリ2020に対するインターフェイスなどのI/Oインターフェイス2030の機能のいくつかまたはすべてを直接プロセッサ2010に組み込むこともできる。
ネットワーク・インターフェイス2040は、例えば、図1〜35で説明したような他のコンピュータシステムまたはデバイスのような、ネットワーク2050に取り付けられたコンピュータ・システム2000及び他のデバイス2060の間でデータが交換されることを可能とするよう構成されてよい。様々な実施形態において、ネットワーク・インターフェイス2040は、例えば、イーサネット・ネットワークのタイプのような、任意の適切な有線若しくは無線の一般データ・ネットワークを介した通信をサポートすることができる。加えて、ネットワーク・インターフェイス2040は、アナログ・ボイス・ネットワーク若しくはディジタル・ファイバー・コミュニケーション・ネットワークのようなテレコミュニケーション/テレフォニー・ネットワーク、ファイバー・チャンネル・SANのようなストレージ・エリア・ネットワーク、または、任意の他の適切なタイプのネットワーク及び/またはプロトコル、を介した通信をサポートすることができる。
いくつかの実施形態では、システム・メモリ2020は、分散型ロード・バランシング・システムの実施形態の実装に対して上記で図1〜35につき説明したようなプログラム命令及びデータを格納するように構成されたコンピュータ・アクセス可能な媒体の一実施形態でよい。しかし、他の実施形態では、プログラム命令及び/またはデータを、異なるタイプのコンピュータ・アクセス可能な媒体で受信し、かかる媒体に送信し、またはかかる媒体に格納することができる。一般的にいえば、コンピュータ・アクセス可能な媒体は、磁気媒体または光学媒体(例えば、I/Oインターフェイス2030を介してコンピュータ・システム2000に結合したディスク、またはDVD/CD)などの非一時的なストレージ媒体またはメモリ媒体を含むことができる。非一時的なコンピュータ・アクセス可能なストレージ媒体はまた、コンピュータ・システム2000のいくつかの実施形態でシステム・メモリ2020または別のタイプのメモリとして含むことができるRAM(例えば、SDRAM、DDR SDRAM、RDRAM、SRAM等)、ROMなどの任意の揮発性または不揮発性の媒体を含むこともできる。さらに、コンピュータ・アクセス可能な媒体は、伝送媒体または、ネットワーク・インターフェイス2040を介して実装できるようなネットワーク及び/または無線リンクなどの通信媒体を介して伝えられる電気信号、電磁気信号またはディジタル信号などの伝送信号を含むことができる。
本開示の実施形態は、以下の条項を考慮して説明することができる:
[項1]
1つまたは複数のクライアントからのパケット・フロー内のパケットを自身の単一のパブリックIPアドレスにより受信するように構成されたルータと、
複数のサーバ・ノードと、
前記分散型ロード・バランサ・システムの入口サーバとしてそれぞれ構成された複数のロード・バランサ・ノードと、
を含み、
前記入口サーバはすべて前記同じ単一のパブリックIPアドレスを前記ルータに広告し、
前記ルータは、さらに、前記パケット・フロー内の前記パケットのソース及び宛先アドレス情報に適用されたハッシュ化多重パス経路指定技法により前記複数の入口サーバ間に前記パケット・フローを分散させるように構成され、
各入口サーバは、さらに、前記ルータからの1つまたは複数のパケット・フロー内のパケットを受信し、前記パケット・フローのそれぞれにマッピングされた1つまたは複数の前記サーバ・ノードに前記パケットを分散させる、分散型ロード・バランサ・システム。
[項2]
前記ハッシュ化多重パス経路指定技法が、等コスト多重パス(ECMP)経路指定技法である、項1に記載された分散型ロード・バランサ・システム。
[項3]
各ロード・バランサ・ノードが1つまたは複数の他のロード・バランサ・ノードにより前記ルータに広告される、項1に記載された分散型ロード・バランサ・システム。
[項4]
前記1つまたは複数の他のロード・バランサ・ノードのそれぞれが前記ルータと境界ゲートウェイ・プロトコル(BGP)セッションを確立して前記ロード・バランサ・ノードを前記ルータに広告する、項3に記載された分散型ロード・バランサ・システム。
[項5]
前記ロード・バランサ・ノードを前記ルータに広告する前記1つまたは複数の他のロード・バランサ・ノードのそれぞれがさらに、
前記ルータに広告されている前記ロード・バランサ・ノードが故障したことを検出し、
前記検出に応答して、前記ロード・バランサ・ノードを前記ルータに広告するBGPセッションを終了する、
ように構成されている、項4に記載された分散型ロード・バランサ・システム。
[項6]
前記ルータが、さらに、前記1つまたは複数の他のロード・バランサ・ノードがBGPセッションを終了するのに応答して、前記ハッシュ化多重パス経路指定技法により前記複数の入口サーバの間に前記パケット・フローを再分散させるように構成された、項5に記載された分散型ロード・バランサ・システム。
[項7]
パケットの前記ソース及び宛先アドレス情報が、クライアントIPアドレス、クライアント・ポート、サーバ・パブリックIPアドレス、及びサーバ・ポートを含む、項1に記載された分散型ロード・バランサ・システム。
[項8]
ルータで、パブリックIPアドレスにより1つまたは複数のクライアントからのパケット・フロー内のパケットを受信することと、
前記ルータで、前記パケット・フロー内の前記パケットのソース及び宛先アドレス情報に適用されたハッシュ化多重パス経路指定技法により複数のロード・バランサ・ノード間に前記パケット・フローを分散させ、ここで、複数のロード・バランサ・ノードが1つまたは複数のIPアドレスを共有し、することと、
前記1つまたは複数のロード・バランサ・ノードのそれぞれで、前記ルータから受信した1つまたは複数のパケット・フロー内の前記パケットを、前記それぞれのパケット・フローにマッピングされた複数のサーバ・ノードのうちの複数のサーバ・ノードのうちの1つまたは複数のサーバ・ノードに分散させることと、
を含む、
方法。
[項9]
前記ハッシュ化多重パス経路指定技法が、等コスト多重パス(ECMP)経路指定技法である、項8に記載された方法。
[項10]
各ロード・バランサが他の少なくとも1つのロード・バランサ・ノードを前記ルータに広告することをさらに含み、各ロード・バランサ・ノードは、1つまたは複数の前記他のロード・バランサ・ノードによって前記ルータに広告される、項8に記載された方法。
[項11]
ロード・バランサ・ノードを広告する前記1つまたは複数の他のロード・バランサ・ノードが、前記ロード・バランサ・ノードの特定の順序付けに従う前記ロード・バランサ・ノードの左右の隣接ロード・バランサ・ノードを含む、項10に記載された方法。
[項12]
前記広告が、前記ロード・バランサ・ノードが広告する他のそれぞれのロード・バランサ・ノードの前記ルータと境界ゲートウェイ・プロトコル(BGP)セッションを確立する各ロード・バランサ・ノードから成る、請求項10に記載された方法。
[項13]
ロード・バランサ・ノードによって前記ルータに広告されている別のロード・バランサ・ノードが故障したことを前記ロード・バランサ・ノードで検出することと、
前記検出することに応答して、前記他のロード・バランサ・ノードを広告する前記ルータとの前記BGPセッションを終了することと、
をさらに含む、項12に記載された方法。
[項14]
前記ルータで、ロード・バランサ・ノードを広告する1つまたは複数のBGPセッションが終了したと判断することに応答して、前記ハッシュ化多重パス経路指定技法により前記パケット・フローを前記複数のロード・バランサ・ノードの間に再分散させること、をさらに含む、項13に記載された方法。
[項15]
パケットの前記ソース及び宛先アドレス情報が、クライアントIPアドレス、クライアント・ポート、サーバIPアドレス、及びサーバ・ポートを含む、項8に記載された方法。
[項16]
複数のロード・バランサ・ノードで、前記ロード・バランサ・ノードに共有されている1つまたは複数のパブリックIPアドレスをルータに広告することと、
前記ルータで、単一のパブリックIPアドレスにより1つまたは複数のクライアントからのパケット・フロー内のパケットを受信することと、
前記ルータで、前記パケット・フロー内の前記パケットのソース及び宛先アドレス情報に適用されたハッシュ化多重パス経路指定技法により複数のロード・バランサ・ノード間に前記パケット・フローを分散させることと、
1つまたは複数のロード・バランサ・ノードのそれぞれで、前記ルータから受信した1つまたは複数のパケット・フロー内の前記パケットを、複数のサーバ・ノードのうちの1つまたは複数のサーバ・ノードに分散させることと、
を実装するためのコンピュータ実行可能なプログラム命令を格納する、非一時的コンピュータ・アクセス可能なストレージ媒体。
[項17]
前記広告において、各ロード・バランサー・ノードが、他のロード・バランサー・ノードの1つまたは複数により前記ルータに広告される、項16に記載された非一時的コンピュータ・アクセス可能なストレージ媒体。
[項18]
他のロード・バランサー・ノードの1つまたは複数のそれぞれが、前記ルータと境界ゲートウェイ・プロトコル(BGP)セッションを確立して、前記ロード・バランサ・ノードを前記ルータに広告する、請求項17に記載された非一時的コンピュータ・アクセス可能なストレージ媒体。
[項19]
前記プログラム命令が、
ロード・バランサ・ノードによって前記ルータに広告されている別のロード・バランサ・ノードが故障したことを前記ロード・バランサ・ノードで検出することと、
前記検出することに応答して、前記他のロード・バランサ・ノードを広告する前記ルータとの前記BGPセッションを終了することと、
をさらに実装するためのコンピュータ実行可能なものである、項17に記載された非一時的コンピュータ・アクセス可能なストレージ媒体。
[項20]
前記プログラム命令が、前記ルータで、前記複数のロード・バランサ・ノードのうちの1つが前記他のロード・バランサ・ノードによって広告されていないと判断することに応答して、前記ハッシュ化多重パス経路指定技法により、前記パケット・フローを前記複数のロード・バランサ・ノードの間に再分散させることをさらに実装するためのコンピュータ実行可能なものである、項17に記載された非一時的コンピュータ・アクセス可能なストレージ媒体。
結論
様々な実施形態は、先の説明に従って実装された命令及び/またはデータを、コンピュータ・アクセス可能な媒体上で、受信し、送信し、格納することをさらに含むことができる。一般的に言って、コンピュータ・アクセス可能な媒体は、例えば、ディスクまたはDVD/CD−ROM、RAM(例えば、SDRAM、DDR、RDRAM、SRAM等)などの揮発性または非揮発性媒体、ROM等、並びに、ネットワーク及び/または無線リンクなどの通信媒体を介して伝えられる電気信号、電磁気信号またはディジタル信号などの伝送媒体または信号を含むことができる。
図で示され、本明細書で説明されたような様々な方法は、方法の例示的な実施形態を表わしている。これらの方法は、ソフトウェア、ハードウェアまたそれらの組合せで実装することができる。方法の順序は変えることができ、様々な要素を追加し、記録し、組み合わせ、省略し、修正する等のことが可能である。
本開示の利益を有する当業者なら明白であるはずであるが、本開示の様々な修正および変更を加えることができる。かかる修正及び変更のすべてが包含されることが意図されており、したがって、上記の説明は限定する意味ではなく例示的なものであるとみなすべきである。