JP6030807B2 - 分散型ロードバランサでの接続公開 - Google Patents

Description

従来のロードバランサは、典型的には、複数のネットワークインターフェースコントローラ（ＮＩＣ）、例えば８個のＮＩＣを含む単一の専用ボックスであり、ＮＩＣの一部がクライアントからのインバウンドトラフィック／そこへのアウトバウンドトラフィックを取り扱い、他のＮＩＣがロードバランシングの対象となるホストデバイス（例えば、ウェブサーバのようなサーバ）からのアウトバウンドトラフィック／そこへのインバウンドトラフィックを取り扱う。これらの従来のロードバランサの帯域幅またはスループットは、典型的には、クライアント側で毎秒４０ギガビット（Ｇｂｐｓ）及びサーバ側で４０Ｇｂｐｓの範囲にある。ネットワークベースアプリケーション及びクラウドコンピューティングサービスのようなネットワークベースサービスの規模及び範囲が増大したので、データセンタは、ロードバランシングする必要がある数百またはさらに数千のホストデバイス（例えば、ウェブサーバ）を収容することもある。従来のロードバランサは、そのような環境では良好なスケーリングをすることができないことがある。

更に、従来のロードバランサは、典型的には、ホストデバイスから収集されたデータに適用される最大接続（または最大ｃｏｎｎｓ）、ラウンドロビン、及び／または最少接続（最少ｃｏｎｎｓ）のような技術を使用し、どのホストデバイスが接続を取り扱うかを選択する。更に、従来のロードバランサは、典型的には、ホストデバイスに対してプロキシとして機能し、それらは前部に配置されてクライアントからの接続（例えば、伝送制御プロトコル（ＴＣＰ）接続）を終了し、またクライアントトラフィックをホストデバイスとロードバランサとの間に確立されたＴＣＰ接続を介してホストデバイスに送る。したがって、ホストデバイス及びクライアントは、これらの従来のロードバランサを使用するとき、直接のＴＣＰ接続を介して通信しない。

少なくともいくつかの実施形態に従う、例となる分散型ロードバランシングシステムのブロック図である。 少なくともいくつかの実施形態に従う、図１の分散型ロードバランサシステムによって実装することができるロードバランシング方法の高レベルのフローチャートである。 少なくともいくつかの実施形態に従う、入口、出口、及びフロートラッカーの構成要素を含む例となるロードバランサノードを示す。 少なくともいくつかの実施形態に従う、分散型ロードバランサ内のルーティング及びパケットフローを例示する。 少なくともいくつかの実施形態に従って、入口ノードをエッジルータに広告することを例示する。 少なくともいくつかの実施形態に従う、マルチパスルーティング方法のフローチャートである。 少なくともいくつかの実施形態に従う、非対称のパケットフローをグラフィカルに例示する。 少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内のパケットフローを例示する。 少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内に接続を確立するときのパケットフローのフローチャートを提供する。 少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内に接続を確立するときのパケットフローのフローチャートを提供する。 少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内のパケットフローを例示する。 少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内のパケットフローを例示する。 少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内のパケットフローを例示する。 少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内のパケットフローを例示する。 少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内のパケットフローを例示する。 少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内のパケットフローを例示する。 少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内のパケットフローを例示する。 図１１Ａ〜１１Ｄは、少なくともいくつかの実施形態に従う、ロードバランサノードのコンシステントハッシュリング内のメンバーシップに影響を与えるイベントの取り扱いを例示する。 少なくともいくつかの実施形態に従う、ヘルスチェック間隔に従って各々のロードバランサノードによって行うことができるヘルスチェック方法の高レベルフローチャートである。 少なくともいくつかの実施形態に従う、別のロードバランサノードからロードバランサノードをヘルスチェックするための方法である。 少なくともいくつかの実施形態に従う、１つ以上の他のロードバランサノードをヘルスチェックするロードバランサノードをグラフィカルに例示する。 少なくともいくつかの実施形態に従う、サーバノードをヘルスチェックするロードバランサノードを示す。 少なくともいくつかの実施形態に従う、ロードバランサノード１１０によって維持することができる別のノードのヘルスの図をグラフィカルに例示する。 少なくともいくつかの実施形態に従う、各々のロードバランサノードによって維持することができるヘルス情報を例示する。 少なくともいくつかの実施形態に従って、ロードバランサノードの障害を取り扱うことを例示する。 少なくともいくつかの実施形態に従って、ロードバランサノードの障害を取り扱うことを例示する。 少なくともいくつかの実施形態に従って、接続公開技術をグラフィカルに例示する。 少なくともいくつかの実施形態に従って、接続公開技術をグラフィカルに例示する。 少なくともいくつかの実施形態に従う、各々のロードバランサモジュールによって行うことができる接続公開方法の高レベルのフローチャートである。 少なくともいくつかの実施形態に従う、接続公開パケットで受け取ったアクティブ接続情報を対象となるロードバランサノードに分散するための方法のフローチャートである。 少なくともいくつかの実施形態に従う、接続公開パケットで受け取ったアクティブな接続情報を対象となるロードバランサノードに分散するための代替の方法を例示する。 少なくともいくつかの実施形態に従う、ロードバランサノードの例となるソフトウェアスタックアーキテクチャを例示する。 実施形態で使用することができるコアパケット処理技術の態様を例示する。 少なくともいくつかの実施形態に従う、ロードバランサノードでデータフローを処理するための例となるマルチコアパケットプロセッサを例示する。 少なくともいくつかの実施形態に従う、ロードバランサノードでデータフローを処理するための別の例となるマルチコアパケットプロセッサを例示する。 少なくともいくつかの実施形態に従う、ロードバランサノードプロセスによる着信パケットの処理を例示する。 少なくともいくつかの実施形態に従う、ロードバランサノードプロセスによる発信パケットの処理を例示する。 少なくともいくつかの実施形態に従う、本番環境で分散型ロードバランサを含むロードバランシングシステムを例示する。 少なくともいくつかの実施形態に従う、多数の分散型ロードバランシングシステムの構成要素が、単一のプロセスでまたはそれとして、構成され、実行されることを可能にするメッセージバス機構を組み込む分散型ロードバランサテストシステムを例示する。 少なくともいくつかの実施形態に従う、メッセージバスパケットアダプタ及びパケットパイプラインを例示する。 少なくともいくつかの実施形態に従う、メッセージバスパケットアダプタ及びパケットパイプラインを例示する。 少なくともいくつかの実施形態に従う、例となるプロバイダネットワーク環境を例示する。 少なくともいくつかの実施形態に従う、図３３Ａに示されるような例となるプロバイダネットワーク環境の分散型ロードバランサの実現形態を例示する。 少なくともいくつかの実施形態に従う分散型ロードバランサ及びサーバノードの例となる物理的ラックの実現形態を例示する。 少なくともいくつかの実施形態に従う分散型ロードバランサ及びサーバノードの別の例となる物理的ラックの実現形態を例示する。 少なくともいくつかの実施形態に従う、１つ、２つ、またはそれ以上の分散型ロードバランサがネットワークに実装される例となるネットワーキング環境を例示する。 いくつかの実施形態で使用することができる例となるコンピュータシステムを例示するブロック図である。

実施形態は、本明細書では、いくつかの実施形態及び例示的な図面のための実施例として記載されているが、当業者であれば、実施形態は、記載された実施形態または図面に限定されるものではないことを認識するであろう。それらについての図面及び詳細な説明は、実施形態を開示された特定の形態に限定することを意図するものではなく、逆に、意図は、添付の特許請求の範囲によって定義される趣旨及び範囲内に入る全ての変更形態、等価物、及び代替物に及ぶことであると理解されよう。本明細書で使用される見出しは、構成上の目的のみのためであり、明細書または特許請求の範囲の範囲を限定するために使用されることを意味しない。本出願を通じて使用されているように、「することができる」の言葉は、必須の意味（すなわち、しなければならないを意味する）ではなく、許容の意味（すなわち、可能性を有することを意味する）で、使用される。同様に、「含む」、「含むこと」、及び「含んでいる」の言葉は、限定するものではないが、含むことを意味する。

ネットワーク環境内の分散型ロードバランシングのための方法及びシステムの様々な実施形態を説明する。様々なネットワーク環境内の分散型ロードバランサの実施形態に従って実装することができる分散型ロードバランシングの方法及びシステムの実施形態を説明する。例えば、分散型ロードバランサの実施形態は、パケットフロー、例えば伝送制御プロトコル（ＴＣＰ）技術パケットフローを、インターネットのような外部ネットワーク上のクライアントと図３３Ａ及び３３Ｂに例示されるプロバイダネットワーク１９００のようなローカルネットワーク上の送信先、典型的にはサーバ（例えば、ウェブサーバ、アプリケーションサーバ、データーサーバなど）との間に、促進し、維持するように使用することができる。実施形態は、主にＴＣＰパケットフローを処理することに関連して本明細書で説明されるが、実施形態は、ＴＣＰ以外の他のデータ通信プロトコルに、及びパケットフローを処理すること以外の他のアプリケーションに、適用できることに留意されたい。

分散型ロードバランサは、ＴＣＰパケットフローを、特定のクライアントと選択されたサーバ（例えば、ウェブサーバ）との間に、促進し、維持するように動作することができる。しかしながら、分散型ロードバランサは、従来のロードバランサで行われるように、クライアントからのＴＣＰフローを終了せず、かつサーバに対してプロキシとして動作しない。その代りに、分散型ロードバランサのロードバランサノードは、クライアントから受け取ったＴＣＰパケットを対象となるサーバにルーティングし、そのサーバは、それらのＴＣＰスタックを使用してクライアントへのＴＣＰ接続を管理する。言い換えれば、サーバは、クライアントからのＴＣＰパケットフローを終了する。

さらに、ロードバランサノード（複数可）が、従来のロードバランサ技術で行われるようにサーバから収集された情報に適用されるロードバランシング技術またはアルゴリズムに基づいて、どのサーバが接続要求にサービスするかについて決定する代わりに、ロードバランサノードは、新規の接続要求を受け取るサーバを無作為に選択することができ、サーバノードに存在する分散型ロードバランサの構成要素は、選択されたサーバが、それぞれのサーバの現在の状態の１つ以上のメトリックに基づいて、新規の接続要求を受け入れるかまたは拒否するかについて、ローカルで決定する。したがって、どのサーバが接続要求を受け入れるべきかについての決定は、ロードバランサノード（複数可）から接続を取り扱うサーバノードに移行される。言い換えれば、決定は、接続要求がサービスされる場所及び時間へより近接するように移行される。

クライアント及びサーバの間にパケットフローを促進し、維持するために、分散型ロードバランサの実施形態は、限定されるものではないが、マルチパスルーティング技術、コンシステントハッシング技術、分散型ハッシュテーブル（ＤＨＴ）技術、ボーダーゲートウェイプロトコル（ＢＧＰ）技術、メンバーシップ追跡、ヘルスチェック、接続公開、並びにパケットカプセル化及びデカプセル化を含む様々な技術または技術（複数）を用いることができる。分散型ロードバランシングシステムのこれらの、及び同様な他の態様は、図に関連して以下で説明される。

分散型ロードバランシングシステム
図１は、少なくともいくつかの実施形態に従う、例となる分散型ロードバランシングシステムのブロック図である。分散型ロードバランサの実施形態は、ネットワーク１００、例えば図３３Ａ及び３３Ｂに例示されるサービスプロバイダのプロバイダネットワーク１９００に、実装することができる。分散型ロードバランサシステムのクライアントパケットの取り扱いの高レベルの概要として、ネットワーク１００の１つ以上のクライアント１６０は、例えばインターネットのような外部ネットワーク１５０を介して、ネットワーク１００のボーダールータ１０２に接続することができる。ボーダールータ１０２は、分散型ロードバランサシステムのロードバランサノード層のロードバランサ（ＬＢ）ノード１１０に着信パケットをルーティングする分散型ロードバランサのエッジルータ１０４の構成要素へクライアント１６０から着信パケット（例えば、ＴＣＰパケット）をルーティングすることができる。少なくともいくつかの実施形態では、エッジルータ１０４は、フロー毎ハッシュ化マルチパスルーティング技術、例えば、等価コストマルチパス（ＥＣＭＰ）ハッシング技術に従って、ルーティング決定を行うことができる。ロードバランサノード１１０は、今度は、パケットをカプセル化し（例えば、ユーザーデータグラムプロトコル（ＵＤＰ）に従って）、カプセル化パケットを、ネットワーク１００のネットワークファブリック１２０（例えば、Ｌ３ネットワーク）を介して、サーバノード１３０のローカルのロードバランサモジュール１３２にルーティングする。ファブリック１２０は、限定するものではないが、スイッチ、ルータ、及びケーブルを含む１つ以上のネットワーキングデバイスまたは構成要素を含むことができる。サーバノード１３０では、ローカルのロードバランサモジュール１３２が、パケットをデカプセル化し、クライアントＴＣＰパケットをサーバ１３４のＴＣＰスタックに送る。サーバノード１３０のサーバ１３４は、次にそれらのＴＣＰスタックを使用し、クライアント１６０への接続を管理する。

図２は、少なくともいくつかの実施形態に従う、図１の分散型ロードバランサシステムによって実装することができるロードバランシング方法の高レベルのフローチャートである。分散型ロードバランサシステムの実施形態は、ロードを複数の送信先（例えば、ウェブサーバ）に割り当てる困難な問題を、従来のロードバランサで行われるように解決しないことが可能である。例えば、従来のロードバランサは、典型的には、最大接続、ラウンドロビン、及び／または最少接続技術のような技術またはアルゴリズムを使用し、どのサーバが接続を取り扱うべきかを選択する。しかしながら、これらの技術は、欠点を有し、具体的には、ロードバランシングの決定を行うために使用されるデータが多くの場合ほとんど直ぐに古くなっている分散型システムでは、首尾よく行うことが困難である。分散型ロードバランサシステムの少なくともいくつかの実施形態では、従来のロードバランサで行われるような１つ以上のロードバランシング技術を使用して接続要求を満たすようにサーバノード１３０を選択することを試みる代わりに、ロードバランサノード層のロードバランサノード１１０は、クライアント接続の要求を受け取るサーバノード１３０を無作為に決定することができる。そのサーバノード１３０がそれ自体をオーバーロード状態と見なす場合、サーバノード１３０は、接続要求をロードバランサノード１１０に送り返すことができ、したがって、サーバノード１３０が接続を現在取り扱うことができないことをロードバランサノード１１０に通知することができる。ロードバランサノード層は、次に、接続要求を受け取る別のサーバノード１３０を無作為に決定することができ、またはあるいは、エラーメッセージを要求元のクライアント１６０に返し、クライアント１６０に接続を現在確立できないことを通知することができる。

図２の１０で示されるように、分散型ロードバランサシステムのロードバランサノード層は、通信セッション（例えば、ＴＣＰ接続）の要求を送信元から受け取る。送信元は、例えば、分散型ロードバランサシステムを実装するネットワーク１００への外部ネットワーク１５０上のクライアント１６０であることができる。少なくともいくつかの実施形態では、要求は、ネットワーク１００のボーダールータ１０２でクライアント１６０から受け取られ、かつ着信パケットを例えばフロー毎等価コストマルチパス（ＥＣＭＰ）ハッシング技術を使用してロードバランサノード層のロードバランサ（ＬＢ）ノード１１０にルーティングするエッジルータ１０４にルーティングされ、クライアント１６０からの特定の接続要求がルーティングされるロードバランサノード１１０を疑似無作為に選択することができる。

２０に示されるように、ロードバランサノード層は、送信先ノードを無作為に選択し、接続要求を選択された送信先ノードに転送する。送信先ノードは、例えば、ロードバランサが前部に配置された複数のサーバノード１３０のうちの１つであることができる。少なくともいくつかの実施形態では、ロードバランサ層のロードバランサノード１１０は、接続要求を受け取るサーバノード１３０を全て既知のサーバノード１３０のうちから無作為に選択することができる。しかしながら、全て既知のサーバノード１３０のうちから純粋に無作為に選択する以外の他の方法は、いくつかの実施形態では、接続要求を受け取るサーバノード１３０を選択するために使用することができる。例えば、いくつかの実施形態では、サーバノード１３０に関する情報は、サーバノード１３０の無作為の選択を重み付けするために、ロードバランサノード１１０によって使用することができる。実施例として、異なるサーバノード１３０が、異なるタイプのデバイスであり、または異なるＣＰＵで構成されて異なる能力または容量を有している、ことをロードバランサノード１１０が知っている場合、情報は、無作為の選択をサーバノード１３０の特定のタイプ（複数可）または構成（複数可）に向かう方向に（または、そこから離れる方向に）バイアスするために使用することができる。

３０に示されるように、送信先ノードは、それが通信セッションを受け入れることができるかどうかを決定する。少なくともいくつかの実施形態では、サーバノード１３０のローカルのロードバランサ（ＬＢ）モジュール１３２は、サーバノード１３０のそれぞれのサーバ１３４が、それぞれのサーバ１３４の現在の状態の１つ以上のメトリックに基づいて、新規の接続を受け入れることができるかを決定する。

４０で、接続要求が受け入られると、次に５０に示されるように、送信先ノードは、送信先ノードが接続を取り扱うことができることをロードバランサノード層に通知する。６０に示されるように、通信セッションは、次に、ロードバランサノード層を介して送信元（例えば、クライアント１６０）と送信先ノード（例えば、サーバノード１３０のサーバ１３４）との間に確立される。少なくともいくつかの実施形態では、サーバノード１３０のサーバ１３４は、ＴＣＰスタックを使用し、クライアント１６０への接続を管理する。

４０で、接続要求が受け入られない場合、次に７０に示されるように、送信先ノードはロードバランサノード層に通知し、方法は要素２０に戻ることができる。ロードバランサノード層は、次に、２０で別の送信先ノードを無作為に選択することができ、またはあるいは、要求元のクライアント１６０に接続を現在確立できないことを通知することができる。クライアント１６０は、必ずしもではないが、接続要求を再提出し、要素１０で方法を再び開始することができることに留意されたい。

図１を再び参照すると、分散型ロードバランサシステムの少なくともいくつかの実施形態は、コモディティハードウェアを使用し、ネットワーク１００上のエッジルータ１０４で受け取ったクライアントトラフィックを、ネットワーク１００上のサーバノード１３０にルーティングすることができる。分散型ロードバランサの少なくともいくつかの実施形態は、複数のロードバランサノード１１０を含むロードバランサノード層を含むことができる。少なくともいくつかの実施形態では、各々のロードバランサノード１１０は、ロードバランサノード層の複数の役割のうちの１つ以上で機能することができる。ロードバランサノード１１０のこれらの役割は、入口ノード、及び出口ノード、及びフロートラッカーノード（所与のパケットフローのための１次フロートラッカーまたは２次フロートラッカーとして）の役割を含むことができる。少なくともいくつかの実施形態では、各々のロードバランサノード１１０は、コモディティラックマウント型コンピューティングデバイスのような別個のコンピューティングデバイスとしてまたはその上のロードバランサノード層に実装することができる。少なくともいくつかの実施形態では、各々のロードバランサノード１１０は、入口ノード、出口ノード、及びフロートラッカーノード（パケットフローのための１次または２次フロートラッカーとして）の３つの役割の各々で機能することができ、特定のパケットフローに対して、ロードバランサノード１１０は、概して、役割のうちの１つのみ（場合によっては２つまたは３つ）で機能することができる。しかしながら、少なくともいくつかの実施形態では、ロードバランサノード１１０は、特定のパケットフローに対して、１次フロートラッカー及び２次フロートラッカーの両方として機能することができない。あるいは、いくつかの実施形態では、各々のロードバランサノード１１０は、３つの役割のうちの１つのみで機能することができる。この実施形態では、コンピューティングデバイスの別個のセットは、具体的には入口ノード、出口ノード、及びフロートラッカーノードとしてロードバランサノード層に実装することができる。

少なくともいくつかの実施形態では、コンシステントハッシング及びコンシステントハッシュリング技術を適用し、パケットフローのための１次及び２次フロートラッカーを決定することができる。クライアントからの各々パケットフローは、例えば、クライアントＩＰアドレス、クライアントポート、サーバ（パブリック）ＩＰアドレス、及びサーバポートからなる４タプルによって一意的に識別することができる。この識別子は、クライアント及びパブリックエンドポイントのペアを示すＣＰまたはＣｃＰｐとして略記することある。任意の所与のＴＣＰフロー（またはＣＰペア）に関連付けられたパケットは、エッジルータ１０４からのハッシュ化マルチパス（例えば、ＥＣＭＰ）フロー分散により、入口サーバ１１２として動作する任意のロードバランサノード１１０上に現れることができる。コンシステントハッシングを使用することにより、パケットが入口ノードとして機能するロードバランサノード１１０に到着すると、入口ノードは、どのロードバランサノード１１０がパケットフローの状態を維持することを担当するかを決定することができる（すなわち、１次フロートラッカーノード）。ＣＰペアは、どのロードバランサノード１１０がパケットフローの状態情報を維持することを担当するかを決定するために、入口ノードによってコンシステントハッシュリングにハッシュ化することができる。コンシステントハッシュリング内のパケットフローのＣＰペアのコンシステントハッシュに従って決定されるノード１１０は、パケットフローのための１次フロートラッカーとして機能するノード１１０である。少なくともいくつかの実施形態では、コンシステントハッシュリング内の後継ノードは、パケットフローのための２次フロートラッカーとして機能する。

図３は、少なくともいくつかの実施形態に従って、全ての３つの役割（入口、出口、及びフロートラッカー）を実装する構成要素を含む例となるロードバランサ（ＬＢ）ノード１１０を示す。この実施例では、入口サーバ１１２の構成要素は、クライアント（複数可）からのインバウンドＴＣＰパケットを受け取ること、及びＴＣＰパケットをカプセル化パケットとしてサーバ（複数可）に送ることからなる入口役割を行う。出口サーバ１１４の構成要素は、サーバ（複数可）からアウトバウンドカプセル化パケットを受け取ること、及びデカプセル化ＴＣＰパケットをクライアント（複数可）に送ることとからなる出口役割を行う。フロートラッカー１１６の構成要素は、クライアント（複数可）１６０とサーバ（複数可）１３４との間に確立された１つ以上のパケットフローのための１次または２次フロートラッカーとして働く。入口サーバ１１２はまた、ロードバランサノード１１０のフロートラッカー１１６と、または別のロードバランサノード１１０のフロートラッカー１１６と、通信し、それぞれのクライアント１６０から受け取る接続要求に応じてクライアントとサーバ１３４のうちの１つとの間のＴＣＰ接続を開始し、またはパケットフローのマッピング情報を取得することができる。

ロードバランサノード
図１を再び参照すると、少なくともいくつかの実施形態では、ロードバランサノード層のロードバランサノード１１０は、クライアントトラフィック（パケット、例えば、ＴＣＰパケット）をネットワーク上の１つ以上のルータ１０４から受け取り、ファブリック１２０の分散型ロードバランサシステムによって使用されるプロトコル（例えば、ユーザーデータグラムプロトコル（ＵＤＰ））に従ってパケットをカプセル化する。ロードバランサノード層は、次にカプセル化パケットを、ファブリック１２０を介して送信先サーバノード１３０に転送する。各々のサーバノード１３０は、ロードバランサシステムの構成要素であるローカルのモジュール１３２を含む。モジュール１３２は、本明細書ではロードバランサモジュールまたは単にＬＢモジュールと呼ぶことができ、サーバノード１３０にソフトウェア、ハードウェア、またはそれらの組み合わせで実装することができる。各々のサーバノード１３０では、それぞれのロードバランサモジュール１３２は、パケットをデカプセル化し、ＴＣＰパケットを通常のＴＣＰ処理のためにローカルのＴＣＰスタックに送る。少なくともいくつかの実施形態では、ロードバランサノード層は、あらゆるクライアントサーバＴＣＰフローの状態情報を維持することができるが、ロードバランサノード層のロードバランサノード１１０は、ＴＣＰフローについて何も解釈しなくてもよい。各々のフローは、それぞれのサーバノード１３０のサーバ１３４とクライアント１６０との間で管理される。分散型ロードバランサシステムは、ＴＣＰパケットが正しい送信先サーバ１３４に到着することを保証する。各々のサーバノード１３０のロードバランサモジュール１３２は、それぞれのサーバ１３４がロードバランサノード１１０から受け取るクライアント接続要求に応じて、新規の接続を受け入れるかまたは拒否するかについて決定する。

少なくともいくつかの実施形態では、分散型ロードバランシングシステムは、コンシステントハッシング技術を使用し、例えば、どのサーバノード１３０が特定のＴＣＰパケットフローを担当しているかをどのロードバランサノード（複数可）１１０が覚えるべきかを決定することができる。コンシステントハッシング技術を使用し、ロードバランサノード層のロードバランサノード１１０は、コンシステントハッシュリングと見なすことができ、ロードバランサノード１１０は、リング内のメンバーシップを追跡し、コンシステントハッシング機能に従って特定のパケットフローを担当するリング内の特定のメンバーを決定することができる。少なくともいくつかの実施形態では、クライアント１６０とサーバ１３４との間の各々のパケットフローを追跡することを担当する２つのロードバランサノード１１０が存在し、これらのノード１１０は、１次フロートラッカー（ＰＦＴ）ノード及び２次フロートラッカー（ＳＦＴ）ノードと呼ぶことができる。少なくともいくつかの実施形態では、１次フロートラッカーは、フローのためのコンシステントハッシュリング上の第１のロードバランサノード１１０であり、２次フロートラッカーは、１次フロートラッカーノードとは異なるコンシステントハッシュリング上の次のまたは後続のロードバランサノード１１０である。この配設では、１次フロートラッカーノードに障害が発生する場合、次に２次フロートラッカーノードが新規の１次フロートラッカーになることができ、別のロードバランサノード１１０（例えば、コンシステントハッシュリング上の次のノード１１０）が２次フロートラッカーの役割を担うことができる。少なくともいくつかの実施形態では、ロードバランサノード１１０は、所与のパケットフローに対して１次フロートラッカー及び２次フロートラッカーの両方として機能することができないことに留意されたい。コンシステントハッシュリング内のこの及び他のメンバーシップの変更は、この明細書の後半で説明する。少なくともいくつかの実施形態では、ロードバランサ実現形態に関する構成情報（例えば、現在実現形態にあるロードバランサノード１１０及びサーバノード１３０の信頼できるリスト（複数可））は、分散型ロードバランシングシステムの構成サービス１２２の構成要素によって維持することができ、それは、例えばファブリック１２０を介してロードバランサノード１１０に結合された１つ以上のサーバデバイスに実装することができる。

少なくともいくつかの実施形態では、１次及び２次フロートラッカーノードとして機能することに加えて、ロードバランサノード１１０はまた、所与のフローに対して２つの他の役割、入口ノードの役割及び出口ノードの役割、のうちの１つで行うことができる。パケットフローのための入口ノードは、エッジルータ１０４からそれぞれのパケットフローを受け取り、パケットフローを（カプセル化パケットとして）ファブリック１２０を介してサーバノード１３０の選択されたサーバ１３４に転送するロードバランサノード１１０である。入口ノードは、実際のクライアントデータ（ＴＣＰデータパケット）をそれぞれの送信先サーバノード１３０に移動する唯一のロードバランサノード１１０である。入口ノードは、送信先サーバノード１３０のそれぞれのロードバランサモジュール１３２へのＴＣＰフローのマッピングを維持し、その結果、入口ノードは、どのロードバランサモジュール１３２にクライアントトラフィックを転送するかを認知する。出口ノードは、ファブリック１２０を介してサーバノード１３０から受け取ったパケットフローに対する応答トラフィックを、ボーダーネットワークを介してそれぞれのクライアント１６０に転送することを担当するロードバランサノード１１０である。ロードバランサモジュール１３２は、ロードバランサプロトコル（例えば、ＵＤＰ）に従ってサーバ１３４から取得した応答パケットをカプセル化し、カプセル化応答パケットを、ファブリック１２０を介してフローのためのそれぞれの出口ノードに送る。出口ノードは、ステートレスであり、単にパケットをデカプセル化し、応答パケット（例えば、ＴＣＰパケット）を、外部ネットワーク１５０を介してそれぞれのクライアント１６０に配信するためにボーダールータ１０２へのボーダーネットワークに送る。

前述のように、少なくともいくつかの実施形態では、各々ロードバランサノード１１０は、異なるパケットフローに対して、入口ノード、出口ノード、及び／またはフロートラッカーノード（１次または２次フロートラッカーのいずれかとして）の役割を行うことができる。ロードバランサノード層の単一のロードバランサノード１１０は、ノードがどんなパケットフローを処理しているかに依存して役割のいずれか１つで働くことができる。例えば、少なくともいくつかの実施形態では、ロードバランサノード１１０は、１つのパケットフローのための入口ノードとして、別のパケットフローのための１次または２次フロートラッカーとして、及び更に別のパケットフローのための出口ノードとして働くことができる。更に、少なくともいくつかの実施形態では、ロードバランサノード１１０は、同じパケットフローに対して複数の役割、例えば所与のパケットフローのための入口ノードとしてかつ１次（または２次）フロートラッカーノードとして、を行うことができる。しかしながら、少なくともいくつかの実施形態では、冗長性及びリカバリの目的のために、ロードバランサノード１１０は、同じパケットフローのための１次及び２次フロートラッカーノードの両方として機能することができない。

上記は、各々のロードバランサノード１１０が、入口サーバ、出口サーバ、及びフロートラッカーの３つの役割のいずれかで機能することができる実施形態を説明する。しかしながら、いくつかの実施形態では、コンピューティングデバイスの異なるグループは、ロードバランシングシステムの異なる役割に割り付けることができる。例えば、いくつかの実施形態では、別個のコンピューティングデバイスに各々が実装された入口ノード、出口ノード、及びフロートラッカーノードの異なるセットが存在してもよい。別の実施例として、いくつかの実施形態では、コンピューティングデバイスの１つのセットが入口ノード及びフロートラッカーノードの両方として機能することができ、一方コンピューティングデバイスの別のセットは出口ノードとしてのみ機能することができる。

ロードバランサモジュール
前述のように、各々のサーバノード１３０は、ロードバランサシステムの構成要素であるローカルのロードバランサモジュール１３２を含む。モジュール１３２は、サーバノード１３０に、ソフトウェア、ハードウェア、またはそれらの組み合わせで実装することができる。少なくともいくつかの実施形態では、サーバノード１３０のロードバランサモジュール１３２は、３つの主要な役割、発信パケットのカプセル化及び着信パケットのデカプセル化、ノード１３０のサーバ１３４についてのローカルのロードバランシングの決定、並びに接続公開、を行うことができる。これらの３つの役割は以下で簡単に説明し、この明細書の後半でより詳細に説明する。

分散型ロードバランシングシステムの少なくともいくつかの実施形態は、ＴＣＰ接続を終了することなく、またパケットをなりすますことなく、ロードバランサノード層を介して送られる全てのパケットの送信元及び送信先ＩＰアドレスは、パケットフロー内に含まれるエンドポイント（すなわち、クライアント１６０及びサーバ１３４）の実際のＩＰアドレスである。なりすましの代わりに、これらの実施形態は、ロードバランサノード１１０とファブリック１２０のサーバノード１３０との間に送られる全てのパケットを、例えばＵＤＰパケットとしてカプセル化する。フローのための入口ノードとして働くロードバランサノード１１０からサーバノード１３０に到着するパケットフロー内のインバウンドパケットは、ロードバランサノード１１０によってカプセル化されるので、パケットは、デカプセル化され、かつノード１３０のサーバ１３４のためのローカルホストＴＣＰフローにリダイレクトされる必要がある。ノード１３０のロードバランサモジュール１３２は、このデカプセル化を行う。同様に、サーバ１３４からのパケットフローのための発信パケットは、ロードバランサモジュール１３２によってカプセル化され、パケットフローのための出口ノードとして働くロードバランサノード１１０にファブリック１２０を介して送られる。

少なくともいくつかの実施形態では、サーバノード１３０のロードバランサモジュール１３２はまた、それぞれのサーバノード１３０のサーバ１３４に対するロードバランシングに関連するローカルの決定を行う。具体的には、ノード１３０のロードバランサモジュール１３２は、それぞれのサーバ１３４が、新規のＴＣＰ接続の要求の受け取りに応じて、別のＴＣＰフローを受け入れるかどうかを決定する。前述のように、ロードバランサノード１１０は、ロードバランサモジュール１３２に送られた全てのパケットをカプセル化し、その結果、ロードバランサモジュール１３２は、ＴＣＰ同期（ＳＹＮ）パケットをクライアント１６０から実際に受け取ることなく、その代わりに、ロードバランサモジュール１３２は、ロードバランサモジュール１３２が受け入れるか拒否することができるフロートラッカー１１６からのカプセル化プロトコル（例えば、ＵＤＰ）に従う接続要求メッセージを受け取る。ロードバランサモジュール１３２が接続要求メッセージを受け入れる場合、ロードバランサモジュール１３２は、ローカルホストに宛てられたＳＹＮパケットを作成する。ローカルホストが接続を受け入れると、これは、それぞれのクライアント接続を取り扱う実際のＴＣＰスタックになる。

少なくともいくつかの実施形態では、接続要求メッセージを受け入れるべきかどうかについての決定を行うために、ロードバランサモジュール１３２は、サーバノード１３０の現在のリソース消費量に関する１つ以上のメトリックを調べ、新規の接続を取り扱うために利用可能である十分なリソースがある場合、ロードバランサモジュール１３２は、接続を受け入れる。少なくともいくつかの実施形態では、ロードバランサモジュール１３２によって検討することができるリソースメトリックは、限定されるものではないが、ＣＰＵ使用率、最近の帯域幅使用量、及び確立された接続の数のうちの１つ以上を含むことができる。いくつかの実施形態では、それらのメトリックの代わりに、またはそれらに加えて、他のメトリックを検討することができる。例えば、いくつかの実施形態では、ロードバランサモジュールは、サーバのレイテンシ（すなわち、要求がサーバ接続バックログで費やされる時間量）をメトリックとして検討することができ、サーバのレイテンシが閾値を超える場合、接続要求を拒否することができる。これらの及び／または他のメトリックを使用し、ロードバランサモジュール１３２は、それぞれのサーバ１３４について、サーバ１３４が新規のパケットフローを受け入れるか拒否するかを決定することができる。少なくともいくつかの実施形態では、リソース利用率（例えば、Ｎパーセント利用）は、個別にまたは組み合わせてメトリック（複数可）から決定され、閾値（例えば、９０％利用）と比較することができる。決定されたリソース利用率が閾値以上である場合、または接続を追加することによってその率が閾値を超える場合は、接続要求を拒否することができる。

少なくともいくつかの実施形態では、ロードバランサモジュール１３２は、接続要求メッセージを拒否すべきかを決定するための確率的方法を実装することができる。上述のようにリソース利用率が閾値以上の場合に全ての接続要求を拒否する代わりに、この方法では、利用率の２つ以上の異なるレベルにおいて、異なる確率で、接続要求を拒否することができる。例えば、リソース利用率が８０％の場合、ロードバランサモジュール１３２は、２０％の確率で接続要求を拒否することができ、リソース利用率が９０％の場合、ロードバランサモジュール１３２は、２５％の確率で接続要求を拒否することができ、リソース利用率が９５％の場合、ロードバランサモジュール１３２は、５０％の確率で接続要求を拒否することができ、９８％以上では、ロードバランサモジュール１３２は、全ての接続要求を拒否することができる。

少なくともいくつかの実施形態では、各々の接続要求メッセージは、接続要求メッセージがロードバランサモジュール１３２によって何回拒否されたかの指示を含むことができる。ロードバランサモジュール１３０によって受け取られた接続要求メッセージが、それが閾値回数を超えて拒否されたことを示す場合、サーバノード１３０の性能メトリックが接続要求を拒否すべきであることを指示していても、ロードバランサモジュール１３０は、接続を受け入れることができる。

いくつかの場合では、接続要求メッセージが送られたロードバランサモジュール１３２の全てが接続要求を拒否することが可能である。少なくともいくつかの実施形態では、接続要求メッセージがロードバランサモジュール１３２からロードバランサモジュール１３２に無期限にわたって跳ね返されることを防ぐために、各々の接続要求メッセージには有効時間を与えることができる。この有効時間が過ぎると、フロートラッカーノードは、要求を終了し、要求を現在サービスできないことをそれぞれのクライアント１６０に通知することができる。

少なくともいくつかの実施形態では、サーバノード１３０のロードバランサモジュール１３２はまた、ロードバランサノード１１０への接続公開を行う。少なくともいくつかの実施形態では、接続公開を行うために、周期的にまたは非周期的に（例えば、１秒に１回）各々のロードバランサモジュール１３２は、サーバノード１３０のルーティングテーブル（例えば、ネットスタット（ｎｅｔｓｔａｔ）ルーティングテーブル）を調べ、アクティブな接続（ＴＣＰフロー）のリストを公開し、ロードバランサノード１１０に返す。所与のパケットフローの存在について通知される必要があるロードバランサノード１１０は、それぞれのパケットフローのための入口ノードとしてかつ１次及び２次フロートラッカーとして機能しているロードバランサノード１１０である。いくつかの実施形態では、ロードバランサモジュール１３２は、コンシステントハッシング技術を使用し、サーバノード１３０のアクティブなＴＣＰフローについて通知される必要があるロードバランサノード１１０のリストをフィルター処理することができる。例えば、ロードバランサモジュール１３２は、どのロードバランサノード１１０が、コンシステントハッシュリングに従って、所与のパケットフローのための１次及び２次フロートラッカーとして機能しているかを決定することができる。いくつかの実施形態では、ロードバランサモジュール１３２は、どのロードバランサノード１１０が最後に各々のパケットフローについてデータパケットをロードバランサモジュール１３２に送ったかを追跡し、この情報を使用し、入口ノードのみがクライアントデータをロードバランサモジュール１３２に転送するので、どのロードバランサノード１１０がパケットフローに対する入口ノードとして機能しているかを決定する。いくつかの実施形態では、ロードバランサモジュール１３２は、次に、ロードバランサノード１１０の各々のために、それがパケットフローについて通知される必要があると決定されたというメッセージを定式化し、メッセージをロードバランサノード１１０に送り、それぞれのサーバノード１３０が、クライアント（複数可）１６０への接続（複数可）をまだ維持していることをノード１１０に通知する。ロードバランサモジュール１３２によるロードバランサノード１１０へのこの接続公開は、ロードバランサノード１１０でリース期間を延長するものとして見なすことができる。ロードバランサノード１１０が特定のパケットフローを示す接続公開メッセージを期間（例えば、１０秒）内に受け取らなかった場合には、ロードバランサノード１１０は、それぞれのパケットフローを任意で忘れることができる。

ロードバランサノードへのマルチパスルーティング
図４は、少なくともいくつかの実施形態に従う、分散型ロードバランサ内のルーティング及びパケットフローの態様を例示する。少なくともいくつかの実施形態では、各々の入口ノード（入口ノードは、図４では入口サーバ１１２として示されている）は、例えばボーダーゲートウェイプロトコル（ＢＧＰ）を介して、１つ以上のパブリックエンドポイント（例えば、ＩＰアドレス及びポート）を分散型ロードバランサのためのエッジルータ１０４にルーティングするその能力を広告する。少なくともいくつかの実施形態では、各々入口ノードがＢＧＰセッションを介してそれ自体をエッジルータ１０４に広告するのではなく、図５に示されるように、１つ以上の他の入口ノード、例えば２つの近傍のノードが、ＢＧＰセッションをエッジルータ１０４と確立し、入口ノードを広告することができる。

従来のロードバランサは、典型的には、単一のパブリックエンドポイントを提供することができるだけである。対照的に、分散型ロードバランサの実施形態は、複数のロードバランサノード１１０が単一のパブリックエンドポイントをサービスすることを可能にする。ルータ能力に依存して、これは、全ての入口サーバ１１２にルーティングされる単一のパブリックＩＰアドレスがエッジルータ（複数可）１０４を介して帯域幅全体（例えば、１６０Ｇｂｐｓ）を取り扱うことができる構成を可能にする。少なくともいくつかの実施形態では、これを達成するために、エッジルータ（複数可）１０４は、層４のフロー毎ハッシュ化マルチパスルーティング技術、例えば等価コストマルチパス（ＥＣＭＰ）ルーティング技術を利用し、トラフィックを各々が同じパブリックＩＰアドレスを広告する複数の入口サーバ１１２にわたって分散することができる。層４のフローための送信元及び送信先ポートをエッジルータ（複数可）１０４のフローハッシュの一部として使用して着信パケットを入口サーバ１１２の全てに分散することは、概して、入口サーバ１１２として機能する同じロードバランサノード１１０にルーティングされる各々の接続のためのパケットを保持することができ、順番の乱れたパケットを回避することができる。しかしながら、エッジルータ（複数可）１０４は、いくつかの実施形態では、他の技術を使用してトラフィックを入口サーバ１１２にわたって分散することができることに留意されたい。

図４はまた、２つ以上の分散型ロードバランサがネットワーク１００に実装され得ることを示す。２つ以上の分散型ロードバランサは、複数のサーバ１３０を前部に備え、かつ各々が異なるパブリックＩＰアドレスを広告する独立したロードバランサとして各々が動作することができ、またはあるいは、図４に示されるように、２つ以上の分散型ロードバランサは、同じＩＰアドレスを各々が広告することができ、ハッシング技術（例えば、層４のフロー毎ハッシュ化マルチパスルーティング技術）をボーダールータ（複数可）１０２で使用してエッジルータ１０４に送り出されるパケットフローを分割することができ、それは、今度は、パケットフローをそれらのそれぞれの入口サーバ１１２に分散する。

図５は、少なくともいくつかの実施形態に従って、ボーダーゲートウェイプロトコル（ＢＧＰ）を使用して入口ノードをエッジルータに広告することを例示する。この実施例では、ロードバランサ実現形態で入口ノード１１０Ａ〜１１０Ｄとして機能する４つのロードバランサノードが存在する。エッジルータ１０４は、着信パケットをクライアント（図示せず）からロードバランサノード１１０にルーティングする。少なくともいくつかの実施形態では、エッジルータ１０４は、層４のフロー毎ハッシュ化マルチパスルーティング技術、例えば等価コストマルチパス（ＥＣＭＰ）ルーティング技術に従って、ルーティング決定を行うことができる。

少なくともいくつかの実施形態では、エッジルータ１０４は、ロードバランサ実現形態で現在利用可能である入口ノード１１０について学習し、ボーダーゲートウェイプロトコル（ＢＧＰ）技術を介して入口ノード１１０によって開始されるセッションを広告するクライアントトラフィックを受け取る。各々の入口ノード１１０は、ＢＧＰを使用し、それ自体をエッジルータ１０４に広告することができる。しかしながら、ＢＧＰは、典型的には、収束するために比較的長い時間を要する（３秒間以上）。各々の入口ノード１１０がＢＧＰを介してそれ自体を広告するこの技術を使用し、入口ノード１１０がダウンした場合、エッジルータ１０４でのＢＧＰセッションがタイムアウトするのに、したがってエッジルータ１０４が障害クローズダウンについて学習し、かつ現在のＴＣＰフローを入口ノード１１０に再ルーティングするのに、ネットワーキング期間中にかなりの時間（３秒間以上）を要する場合がある。

少なくともいくつかの実施形態では、ＢＧＰで収束問題を回避するために、かつノード１１０の障害の時により迅速にリカバリするために、入口ノード１１０がＢＧＰセッションを介してそれ自体をエッジルータ１０４に広告する代わりに、ロードバランサ実現形態の少なくとも１つの他の入口ノード１１０が、ＢＧＰを介して入口ノード１１０をエッジルータ１０４に広告することを担当する。例えば、図５に示されるようないくつかの実施形態では、所与の入口ノード１１０の左及び右の近傍の入口ノード１１０、例えば、ノード１１０の順序付けリスト、例えばノード１１０によって形成されるコンシステントハッシュリング内の左及び右の近傍のものは、所与の入口ノード１１０をエッジルータ１０４に広告することができる。例えば、図５では、入口ノード１１０Ａは、入口ノード１１０Ｂ及び１１０Ｄを広告し、入口ノード１１０Ｂは、入口ノード１１０Ａ及び１１０Ｃを広告し、入口ノード１１０Ｃは、入口ノード１１０Ｂ及び１１０Ｄを広告し、入口ノード１１０Ｄは、入口ノード１１０Ｃ及び１１０Ａを広告する。入口ノード１１０は、本明細書で後述されるように互いのヘルスをチェックし、広める。記載のヘルスチェック方法を使用し、不健全であるノードを検出することができ、情報は、１秒未満で、例えば１００ミリ秒（ｍｓ）で、ノード１１０にわたって伝搬することができる。入口ノード１１０が健全でないことが決定されると、不健全なノードを広告する入口ノード１１０は、不健全なノード１１０を広告することを即座に停止することができる。少なくともいくつかの実施形態では、入口ノード１１０は、ＴＣＰクローズまたはＢＧＰセッションについての同様のメッセージをエッジルータ１０４に送ることにより、エッジルータ１０４とのＢＧＰセッションを終了する。したがって、ノード１１０の障害を検出するために障害が発生したノード１１０によって確立されるＢＧＰセッションがタイムアウトするのを待機することではなく、ノード１１０が不健全であることが検出されると、障害が発生したノード１１０に代わって広告する他の入口ノード１１０が、ノード１１０を広告するエッジルータ１０４とのＢＧＰセッションを終了するときに、エッジルータ１０４は障害が発生したノード１１０を発見することができる。ロードバランサノードの障害の取り扱いは、本明細書の後半で図１８Ａ及び１８Ｂに関連して更に説明される。

図６は、分散型ロードバランシングシステムの少なくともいくつかの実施形態に従う、マルチパスルーティング方法のフローチャートである。９００に示されるように、ロードバランサ実現形態の入口ノード１１０は、それらの近傍のノード１１０をエッジルータ１０４に広告する。少なくともいくつかの実施形態では、入口ノード１１０は、コンシステントハッシュリングのようなノード１１０の順序付けリストに従って、それらの近傍のノード１１０を決定することができる。少なくともいくつかの実施形態では、入口ノード１１０は、各々の広告されるノード１１０について１つのＢＧＰセッションがエッジルータ１０４に確立されるＢＧＰセッションを使用し、それらの近傍のノード（複数可）１１０をエッジルータ１０４に広告する。

９０２で示されるように、エッジルータ１０４は、フロー毎ハッシュ化マルチパスルーティング技術、例えば等価コストマルチパス（ＥＣＭＰ）ルーティング技術に従って、クライアント１６０から受け取るトラフィックを、アクティブな（広告される）入口ノード１１０に分散する。少なくともいくつかの実施形態では、エッジルータ１０４は、パブリックＩＰアドレスをクライアント１６０に公開し、入口ノード１１０は全て、同じパブリックＩＰアドレスをエッジルータ１０４に広告する。エッジルータは、層４の送信元及び送信先ポートをエッジルータ１０４のフローハッシュの一部として使用し、着信パケットを入口ノード１１０にわたって分散する。これは、概して、同じ入口ノード１１０にルーティングされる各々接続のためのパケットを保持する。

９０２に示されるように、入口ノードは、データフローを対象となるサーバノード１３０に転送する。少なくともいくつかの実施形態では、入口ノード１１０は、データフローのための１次及び２次フロートラッカーノードと相互作用し、データフローを対象となるサーバノード１３０にマッピングする。各々入口ノード１１０は、受け取ったパケットを対象となるサーバノード１３０に適切に転送するために使用することができるノード１１０を介するアクティブなデータフローのマッピングを維持することができる。

要素９０６〜９１０は、入口ノード１１０の障害の検出及びそこからのリカバリに関する。９０６に示されるように、入口ノード１１０は、例えば本明細書に記載のヘルスチェック技術に従って、入口ノード１１０がダウンしていることを検出することができる。ノード１１０がダウンしていることが検出されると、その近傍のノード１１０は、ノード１１０をエッジルータ１０４に広告することを停止する。少なくともいくつかの実施形態では、これは、それぞれのＢＧＰセッションについてＴＣＰクローズをエッジルータ１０４に送ることを含む。

９０８で示されるように、エッジルータ１０４は、入口ノード１１０がダウンしていることがＢＧＰセッションのクローズを介して検出されると、フロー毎ハッシュ化マルチパスルーティング技術に従って、クライアント１６０からの着信トラフィックをその他の入口ノード１１０に再分配する。したがって、少なくともいくつかのデータフローは、異なる入口ノード１１０にルーティングすることができる。

９１０に示されるように、入口ノード１１０は、必要に応じてマッピングをリカバリし、データフローを適切な対象となるサーバノードに転送することができる。入口ノード１１０のノード１１０の障害からリカバリするための方法は、この明細書で別に説明される。一実施例では、入口ノード１１０は、現在のマッピングを有していないパケットを受け取ると、コンシステントハッシュ関数を使用し、コンシステントハッシュリングに従ってデータフローのためのフロートラッカーノードを決定し、フロートラッカーノードからマッピングをリカバリすることができる。

非対称のパケットフロー
少なくともいくつかの実施形態では、インバウンドデータに対するアウトバウンドトラフィックの比が１よりも大きいとき、入口ノードの帯域幅及びＣＰＵ使用率を効率的に利用するために、図７に示されるように分散型ロードバランシングシステムはサーバノード１３０からのアウトバウンドパケットを複数の出口ノードに転送する。少なくともいくつかの実施形態では、各々の接続について、それぞれのサーバノード１３０のロードバランサモジュール１３２は、クライアントエンドポイント／パブリックエンドポイントタプルをハッシュし、コンシステントハッシュアルゴリズムを使用し、それぞれのアウトバウンドパケットフローのための出口サーバ１１４として機能するロードバランサノード１１０を選択する。しかしながら、いくつかの実施形態では、他の方法及び／またはデータを使用して接続のための出口サーバ１１４を選択することができる。選択された出口サーバ１１４は、典型的には、必ずしもではないが、接続のための入口サーバ１１２として機能するロードバランサノード１１０とは異なるロードバランサノード１１０であってよい。少なくともいくつかの実施形態では、そのロードバランサノード１１０／出口サーバ１１４の障害が存在しない限り、特定の接続のためのアウトバウンドパケットの全ては、順番の乱れたパケットを回避するために同じ出口サーバ１１４に転送される。

少なくともいくつかの実施形態では、サーバノード１３０によって出口サーバ１１４を選択するために使用される方法及びデータは、エッジルータ（複数可）１０４によって行われる入口サーバ１１２を選択するために使用される方法及びデータとは異なってもよい。異なる方法及びデータを使用することは、概して、接続のための入口ノードとして選択されたロードバランサノード１１０とは異なるロードバランサノード１１０が所与の接続のための出口ノードとして選択されることをもたらすことができ、更に入口ノードとして機能する単一のロードバランサノード１１０を通過する接続のための発信トラフィックを取り扱うための出口ノードとして複数のロードバランサノード１１０が選択されることをもたらすことができる。

図７は、少なくともいくつかの実施形態に従って、非対称のパケットフローをグラフィカルに例示する。少なくとも１つの接続は、外部ネットワーク１５０上のクライアント１６０から入口サーバ１１２を介してサーバノード１３０Ａ、１３０Ｂ、１３０Ｃ、及び１３０Ｄの各々に確立されている。少なくともいくつかの実施形態では、各々の接続について、接続のための出口ノードを選択するために、それぞれのサーバノード１３０のロードバランサモジュール１３２は、クライアントエンドポイント／パブリックエンドポイントタプルをハッシュし、コンシステントハッシュアルゴリズムを使用し、それぞれのアウトバウンドパケットフローのための出口サーバ１１４として機能するロードバランサノード１１０を選択する。例えば、サーバノード１３０Ａは、接続のための出口サーバ１１４Ａを選択しており、サーバノード１３０Ｂは、１つの接続のための出口サーバ１１４Ａ及び別の接続のための出口サーバ１１４Ｂを選択している。しかしながら、いくつかの実施形態では、他の方法及び／またはデータを使用し、接続のための出口ノードを選択することができる。

クライアント接続をドロップすることがないロードバランサノードの障害からのリカバリ
ロードバランサノード１１０がコンシステントハッシングを使用してどのサーバノード１３０がクライアントトラフィックを受け取るべきかを決定することは可能であるが、いくつかの接続の長い存続期間が原因で、この手法は、新規のサーバノード１３０がコンシステントハッシュメンバーシップに加入し、かつその後の入口ロードバランサノード１１０の障害が存在する場合には、既存のフローを維持することができないことがある。このシナリオでは、障害が発生したノード１１０からフローを引き継ぐロードバランサノード１１０は、サーバ１３０のためのコンシステントハッシュリングが異なるメンバーシップを有しているので、選択されたオリジナルのマッピングを決定することができないことがある。したがって、少なくともいくつかの実施形態では、分散型ハッシュテーブル（ＤＨＴ）技術は、接続のためのサーバノード１３０を選択し、かつ選択されたサーバノード１３０にパケットをルーティングするために、ロードバランサノード１１０によって使用され得る。サーバノード１３０が特定の接続を受け取るためにＤＨＴに従って一旦選択され、かつサーバノード１３０が健全のままであること、及びサーバノード１３０のロードバランサモジュール１３２が、そのアクティブな接続の状態をＤＨＴに（例えば、接続公開を介して）周期的に送信することにより継続してリース期間を延長すること、を前提とすると、ＤＨＴは、接続が完了するまでマッピングを保持する。入口ノード１１０の障害は、エッジルータ１０４からその他のロードバランサノード１１０へのパケットの分散に影響を与え、ロードバランサノード１１０がクライアント接続の異なるセットからトラフィックを受け取ることをもたらす。しかしながら、ＤＨＴは全てのアクティブな接続を追跡するので、ロードバランサノード１１０は、ＤＨＴに照会して任意のアクティブなマッピングのためのリース期間を取得することができる。その結果、全てのロードバランサノード１１０は、トラフィックを正しいサーバノード１３０に渡し、それにより、入口ロードバランサノード１１０の障害が発生した場合でもアクティブなクライアント接続の障害を防ぐ。

分散型ロードバランシングシステムにおけるパケットフロー
図８は、少なくともいくつかの実施形態に従う、分散型ロードバランシングシステムにおけるパケットフローを例示する。図８の矢印付きの実線はＴＣＰパケットを表し、一方矢印付きの点線はＵＤＰパケットを表すことに留意されたい。図８では、入口サーバ１１２は、ＴＣＰパケットを１つ以上のクライアント１６０からエッジルータ１０４を介して受け取る。ＴＣＰパケットを受け取ると、入口サーバ１１２は、サーバノード１３０へのＴＣＰパケットフローのマッピングを有しているかを決定する。入口サーバ１１２がＴＣＰパケットフローのマッピングを有している場合は、サーバ１１２は、ＴＣＰパケットをカプセル化し（例えば、ＵＤＰに従って）、カプセル化パケットを対象となるサーバノード１３０に送る。入口サーバ１１２がＴＣＰパケットフローのマッピングを有していない場合は、入口サーバ１１２は、ＴＣＰパケットから抽出されたＴＣＰパケットフローに関する情報を含むＵＤＰメッセージを１次フロートラッカー１１６Ａに送って、サーバノード１３０への接続を確立し、かつ／またはＴＣＰパケットフローのマッピングを取得することができる。図９Ａ及び９Ｂ並びに図１０Ａ〜１０Ｇは、クライアント１６０とサーバノード１３０との間に接続を確立するための方法を例示する。サーバノード１３０のロードバランサモジュール１３２は、サーバノード１３０でＴＣＰ接続（複数可）のための出口サーバ（複数可）１１４として機能するロードバランサノード（複数可）１１０を無作為に選択し、ＵＤＰカプセル化ＴＣＰ応答パケットを、出口サーバ（複数可）１１４を介してクライアント（複数可）１６０に送る。

図９Ａ及び９Ｂは、少なくともいくつかの実施形態に従う、分散型ロードバランシングシステムで接続を確立するときのパケットフローのフローチャートを提供する。図９Ａの２００で示されるように、入口サーバ１１２は、ＴＣＰパケットをクライアント１６０からエッジルータ１０４を介して受け取る。２０２で、入口サーバ１１２がサーバノード１３０へのＴＣＰフローのマッピングを有している場合は、入口サーバ１１２は、２０４で示されるようにＴＣＰパケットをカプセル化してそれぞれのサーバノード１３０に送る。入口サーバ１１２は、１つ、２つ、またはそれ以上のクライアント１６０からの１つ、２つ、またはそれ以上のＴＣＰフローのためのパケットを連続して受け取り、かつ処理することができることに留意されたい。

２０２で、入口サーバ１１２がＴＣＰフローのマッピングを有していない場合、パケットは、クライアント１６０からのＴＣＰ同期（ＳＹＮ）パケットであってもよい。２０６で示されるように、ＳＹＮパケットを受け取ると、入口サーバ１１２は、ＳＹＮパケットからデータを抽出し、データを例えばＵＤＰメッセージで１次フロートラッカー１１６Ａに転送する。少なくともいくつかの実施形態では、入口サーバ１１２は、コンシステントハッシュ関数に従って、ＴＣＰフローのための１次フロートラッカー１１６Ａ及び／または２次フロートラッカー１１６Ｂを決定することができる。２０８で、１次フロートラッカー１１６Ａは、データを例えばハッシュテーブルに格納し、ＴＣＰ接続のサーバノード１３０の側のための初期ＴＣＰシーケンス番号を生成し、データ及びＴＣＰシーケンス番号を２次フロートラッカー１１６Ｂに転送する。２１０で、２次フロートラッカー１１６Ｂもまた、データを格納し、ＳＹＮ／ＡＣＫパケットを作成してクライアント１６０に送り、ＳＹＮ／ＡＣＫパケットは少なくともＴＣＰシーケンス番号を含む。

２１２で、入口サーバ１１２は、ＴＣＰ受信確認（ＡＣＫ）パケットをクライアント１６０からエッジルータ１０４から受け取る。入口サーバ１１２は、この時点で、サーバ１３０ノードへのＴＣＰフローのマッピングを有していないので、２１４で、入口サーバ１１２は、ＡＣＫパケットから抽出されたデータを含むメッセージを１次フロートラッカー１１６Ａに送る。２１６に示されるように、メッセージを受け取ると、１次フロートラッカー１１６Ａは、格納されたデータに従ってＴＣＰフローを確認し、ＡＣＫパケットからの確認応答されたシーケンス番号（＋１）がＳＹＮ／ＡＣＫで送られた値に一致することを確認する。１次フロートラッカー１１６Ａは、次に、ＴＣＰフローを受け取るサーバノード１３０を選択し、データ、ＴＣＰシーケンス番号、及び選択されたサーバノード１３０のローカルのロードバランサモジュール１３２のＩＰアドレスを含むメッセージを、２次フロートラッカー１１６Ｂに送る。２１８で示されるように、２次フロートラッカー１１６Ｂもまた、データ及びＴＣＰシーケンス番号を確認し、ＳＹＮメッセージを作成し、作成されたＳＹＮメッセージを選択されたサーバノード１３０のローカルのロードバランサモジュール１３２に送る。方法は、図９Ｂの要素２２０で継続する。

図９Ｂの２２０で示されるように、作成されたＳＹＮメッセージに応じて、ロードバランサモジュール１３２は、サーバノード１３０の１つ以上のメトリックを調べ、サーバノード１３０が接続を受け入れることができるかを決定することができる。２２２で、サーバノード１３０が接続を現在受け入れることができないことをロードバランサモジュール１３２が決定する場合は、２２４で、ロードバランサモジュール１３２は、２次フロートラッカー１１６Ｂに連絡する。２次フロートラッカー１１６Ｂは、それが以前に格納したフローに関する情報を削除することができる。２２６で、２次フロートラッカー１１６Ｂは、１次フロートラッカー１１６Ａに連絡する。１次フロートラッカー１１６Ａは、次に、図９Ａの２１６で示されるように、新規の対象となるサーバノード１３０を選択し、２次フロートラッカー１１６Ｂに連絡する。

２２２で、サーバノード１３０が接続を受け入れることができることをロードバランサモジュール１３２が決定する場合は、図９Ｂの２２８で示されるように、ローカルのロードバランサモジュール１３２は、作成されたＳＹＮからＴＣＰ ＳＹＮパケットを構築し、ＴＣＰ ＳＹＮパケットをサーバノード１３０のサーバ１３４に送る。ＴＣＰ ＳＹＮパケットの送信元ＩＰアドレスは、クライアント１６０の実際のＩＰアドレスが取り込まれているので、サーバ１３４は、クライアント１６０への直接のＴＣＰ接続を受け取ったことを確信する。ロードバランサモジュール１３２は、ＴＣＰフローについての関連する詳細を、例えばローカルのハッシュテーブルに格納する。２３０で示されるように、サーバ１３４は、ロードバランサモジュール１３２が傍受するＳＹＮ／ＡＣＫパケットで応答する。２３２で示されるように、ロードバランサモジュール１３２は、次に、接続情報を含むメッセージを２次フロートラッカー１１６Ｂに送り、接続が受け入れられたことを示す。このメッセージを受け取ると、２３４で、２次フロートラッカー１１６Ｂは、サーバ１３４へのマッピングを記録し、同様のメッセージを１次フロートラッカー１１６Ａに送り、それもまたマッピング情報を記録する。２３６に示されるように、１次フロートラッカー１１６Ａは、次に、マッピングメッセージを入口サーバ１１２に転送する。入口サーバ１１２は、これで、クライアント１６０からサーバ１３０へのＴＣＰフローのマッピングを有する。

２３８で、入口サーバ１１２は、データフローのための任意のバッファされたデータパケットをカプセル化し、サーバノード１３０のローカルのロードバランサモジュール１３２に転送する。入口サーバ１１２によって受け取られるクライアント１６０からのデータフローのための追加の着信パケットは、カプセル化されてロードバランサモジュール１３２に直接に転送され、それはパケットをデカプセル化し、データパケットをサーバ１３４に送る。

２４０で、ロードバランサモジュール１３２は、データフローのための出口サーバ１１４を無作為に選択する。サーバ１３４からの後続のアウトバウンドＴＣＰパケットは、ロードバランサモジュール１３２によって傍受され、ＵＤＰに従ってカプセル化され、任意に選択された出口サーバ１１４に転送される。出口サーバ１１４は、発信パケットをデカプセル化し、ＴＣＰパケットをクライアント１６０に送る。

上述のように、２０２で、入口サーバ１１２が受け取ったパケットのＴＣＰフローのマッピングを有していない場合、パケットはクライアント１６０からのＴＣＰ同期（ＳＹＮ）パケットであってよい。しかしながら、パケットはＴＣＰ ＳＹＮパケットでなくてもよい。例えば、ロードバランサノード１１０のメンバーシップがロードバランサノード１１０の追加または障害によって変わる場合、エッジルータ１０４は、入口サーバ１１２がマッピングを有していない１つ以上のＴＣＰフローのためのパケットを、入口サーバ１１２にルーティングすることを開始することができる。少なくともいくつかの実施形態では、入口サーバ１１２がマッピングを有していないそのようなパケットを受け取ると、入口サーバ１１２は、コンシステントハッシュ関数を使用し、コンシステントハッシュリングに従ってＴＣＰフローのための１次フロートラッカー１１６Ａ及び／または２次フロートラッカー１１６Ｂを決定し、１次フロートラッカー１１６Ａまたは２次フロートラッカー１１６Ｂのいずれかに連絡してマッピングを要求することができる。ＴＣＰフローのマッピングをフロートラッカー１１６から受け取ると、入口サーバ１１２は、マッピングを格納し、かつＴＣＰフローのためのＴＣＰパケット（複数可）をカプセル化して正しい送信先サーバノード１３０に転送することを開始することができる。

ロードバランサノードの詳細
少なくともいくつかの実施形態では、ロードバランサノード１１０は、各々３つの役割を有し、
・入口−クライアント接続で全ての着信パケットをクライアント１６０から受け取り、マッピングが既知の場合、パケットをサーバノード１３０にルーティングし、マッピングが既知でない場合、フロートラッカーに連絡する。入口ノードからの発信パケットは、入口ノードによってカプセル化される（例えば、ＵＤＰに従って）。
・フロー追跡−接続状態の追跡を維持する（例えば、各々のクライアント接続をサービスするために、どのサーバノード１３０／サーバ１３４が割り付けられたか）。フロートラッカーもまた、クライアント１６０及びサーバ１３４との間に接続を確立することに参加する。
・出口−サーバ１３４から受け取ったアウトバウンドパケットをデカプセル化し、クライアント１６０に転送する。

少なくともいくつかの実施形態では、入口の役割において、ロードバランサノード１１０は、クライアント−＞サーバのマッピングが既知のとき、パケットをサーバ１３４に転送し、またはマッピングが既知でないとき、要求をフロートラッカーに転送することを担当する。少なくともいくつかの実施形態では、特定のクライアント接続／データフローのための入口ノードとして機能するロードバランサノード１１０はまた、そのクライアント接続のための１次フロートラッカーまたは２次フロートラッカーのいずれかとして、しかし両方ではなく、機能することができる。

少なくともいくつかの実施形態では、フロートラッカーの役割において、ロードバランサノード１１０は、まだ確立されている接続の状態を維持すること、並びに確立された接続のためのクライアント−＞サーバのマッピングを維持することを担当する。２つのフロートラッカーは、各々の個別のクライアント接続に関与し、１次フロートラッカー及び２次フロートラッカーと呼ばれる。少なくともいくつかの実施形態では、クライアント接続に関連するフロートラッカーは、コンシステントハッシュアルゴリズムを使用して決定することができる。フロートラッカーはまた、限定するものではないが、各々の新規のクライアント接続のためのサーバノード１３０を擬似無作為的に選択することを含むロードバランシング機能を行う。選択されたサーバノード１３０のローカルのロードバランサモジュール１３２は、サーバ１３４が接続を取り扱うことができないことを決定する場合、接続要求を拒否することができることに留意されたい。このことが起こると、次にフロートラッカーは、別のサーバノード１３０を選択し、接続要求を他のサーバノード１３０に送ることができる。少なくともいくつかの実施形態では、所定の接続のための１次フロートラッカーの役割及び２次フロートラッカーの役割は、異なるロードバランサノード１１０によって行われる。

少なくともいくつかの実施形態では、出口の役割において、ロードバランサノード１１０は、ステートレスであり、サーバノード１３０から受け取った着信パケットをデカプセル化し、いくつかの検証を行い、アウトバウンドＴＣＰパケットをそれぞれのクライアント１６０に転送する。少なくともいくつかの実施形態では、サーバノード１３０のローカルのロードバランサモジュール１３２は、所与の接続のためのロードバランサノード１１０を任意で選択することができる。

ロードバランサノードのコンシステントハッシュリングトポロジ
少なくともいくつかの実施形態では、ロードバランサノード１１０は、入力鍵空間（クライアントエンドポイント、パブリックエンドポイント）のコンシステントハッシングに基づいて、リングトポロジを形成する。入力鍵空間は、利用可能なフロートラッカーノード間で分割することができ、全てのフロートラッカーノードは、その鍵空間に対応するクエリに答えることを担当することができる。少なくともいくつかの実施形態では、データは、コンシステントハッシュリングの後継に基づいて１次及び２次フロートラッカーノードに複製することができる（例えば、２次フロートラッカーノードは、１次フロートラッカーノードに対して、後継ノード、すなわちコンシステントハッシュリングの次のノードである）。フロートラッカーノードが何らかの理由でダウンした場合、コンシステントハッシュリングの次のロードバランサノードは、障害が発生したノードの鍵空間を取得する。新規のフロートラッカーノードが加わると、ノードはそのエンドポイントを記録し（例えば、図１に示されるような構成サービス１２２で）、その結果、他のロードバランサノードは、ロードバランサ実現形態、したがってコンシステントハッシュリングの構成の変更に関して学習することができる。コンシステントハッシュリングのフロートラッカーの追加及び障害の取り扱いは、図１１Ａ〜１１Ｄを参照してより詳細に説明する。
入口ノード＜−＞フロートラッカーノードの通信

少なくともいくつかの実施形態では、入口ノードとして機能するロードバランサノード１１０は、構成サービス１２２からフロートラッカーノードとして機能するロードバランサノード１１０に関して学習することができる。入口ノードは、ロードバランサ実現形態、したがってコンシステントハッシュリングのメンバーシップの変更に関して構成サービス１２２を監視することができる。入口ノードがマッピングを有していないパケットを入口ノードがクライアント１６０から受け取ると、入口ノードは、コンシステントハッシュ関数を使用し、どのフロートラッカーノードがパケットをサービスすべきかを決定することができる。少なくともいくつかの実施形態では、ハッシュ関数への入力は、パケットからの（クライアントエンドポイント、パブリックエンドポイント）ペアである。少なくともいくつかの実施形態では、入口ノード及びフロートラッカーノードは、ＵＤＰメッセージを使用して通信する。

１次フロートラッカーノードが、新規のパケットフローのための入口ノードからメッセージを受け取ると、１次フロートラッカーノードは、ＴＣＰシーケンス番号を無作為に決定し、別のメッセージを２次フロートラッカーノードに転送する。２次フロートラッカーノードは、クライアントのためのＴＣＰ ＳＹＮ／ＡＣＫメッセージを生成する。両方のフロートラッカーは、クライアント接続エンドポイントペア及びＴＣＰシーケンス番号を記憶しており、メモリプレッシャーまたは有効期限によって状態が一掃されるまで、この情報を保持する。

１次フロートラッカーノードが、ＴＣＰ ＡＣＫパケットを受け取ったというメッセージを入口ノードから受け取ると、１次フロートラッカーノードは、確認応答されたＴＣＰシーケンス番号がＳＹＮ／ＡＣＫパケットで送られた格納された値に一致することを検証し、要求をサービスするサーバノード１３０を選択し、メッセージを２次フロートラッカーノードに転送する。２次フロートラッカーノードは、メッセージを選択されたサーバノード１３０のロードバランサモジュール１３２に送って、サーバノード１３０のＴＣＰスタックとの実際のＴＣＰ接続を開始し、その後、サーバノード１３０からの受信確認応答を待機する。

２次フロートラッカーノードがサーバノード１３０のロードバランサモジュール１３２からの接続受信確認を受け取ると、両方のノードにおいて関連するサーバノード１３０に関する情報を格納する１次フロートラッカーを介する入口ノードへの逆メッセージフローが始動される。この時点から、入口ノードで受け取られる追加のＴＣＰパケットは、サーバノード１３０のロードバランサモジュール１３２に直接に転送される。

ロードバランサモジュール＜−＞ロードバランサノードの通信
少なくともいくつかの実施形態では、全てのロードバランサモジュール１３２は、構成サービス１２２でそのエンドポイントを記録し、ロードバランサノード層のメンバーシップの変更に関して構成サービス１２２を継続的に監視する。以下では、少なくともいくつかの実施形態に従う、ロードバランサモジュール１３２の機能を説明する、
・接続公開−接続を担当する１次及び２次フロートラッカーノードの両方への、並びにパケットを接続のためのロードバランサモジュール１３２に最後に送った入口ノードへの、それぞれのサーバノード１３０上のアクティブな接続のセット（クライアントエンドポイント、パブリックエンドポイント）を、周期的（例えば、１秒に１回）または非周期的に公開する。接続公開機能は、担当しているロードバランサノード１１０での接続状態のリース期間を更新する。
・ロードバランサ層のメンバーシップの変更を監視する。メンバーシップが変更されると、ロードバランサモジュール１３２は、この変更情報を使用して、即座に現在接続を担当しているロードバランサノードへアクティブな接続を送ることが出来る。

分散型ロードバランシングシステム内のパケットフロー−詳細
分散型ロードバランシングシステムは、複数のロードバランサノード１１０を含むことができる。少なくともいくつかの実施形態では、分散型ロードバランシングシステムの各々のロードバランサノード１１０は、サーバ１３４へのクライアント１６０の接続のためのフロートラッカーノード、出口ノード、及び入口ノードの役割で機能することができる。分散型ロードバランシングシステムはまた、各々のサーバノード１３０にロードバランサモジュール１３２を含むことができる。

図１０Ａ〜１０Ｇは、少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内のパケットフローを例示する。図１０Ａ〜１０Ｇでは、ロードバランサノード１１０間で交換されるパケット及びロードバランサノード１１０とサーバノード１３０との間で交換されるパケットは、ＵＤＰメッセージまたはＵＤＰカプセル化クライアントＴＣＰパケットのいずれかである。少なくともいくつかの実施形態では、クライアントＴＣＰパケットは、ボーダールータ１０２（図１を参照）への及びそこからの転送中に、ロードバランサノード１１０のノース側にデカプセル化形態でネットワーク１００に存在するだけである。図１０Ａ〜１０Ｇの矢印付きの実線はＴＣＰパケットを表し、一方矢印付きの点線はＵＤＰパケットを表すことに留意されたい。

少なくともいくつかの実施形態では、分散型ロードバランシングシステムは、確立された接続を単一のロードバランサノード１１０の障害発生時に維持するように試みることができる。少なくともいくつかの実施形態では、これは、１次フロートラッカーノード及び２次フロートラッカーノードの接続の詳細を複製し、その結果、これらのノードのいずれかに障害が発生した場合、接続のクライアント−＞サーバのマッピングが残りのフロートラッカーノードによって復元することができることによって、達成することができる。少なくともいくつかの実施形態では、ノードの障害が発生すると一部のパケットの損失が発生することがあるが、クライアント／サーバＴＣＰパケット再送信は、失われたパケットをリカバリすることができる。

クライアントからの各々のＴＣＰ接続は、ＴＣＰフローと呼ぶことができ、クライアントＩＰアドレス、クライアントポート、サーバ（パブリック）ＩＰアドレス、及びサーバポートからなる４タプルによって一意的に識別される。この識別子は、クライアント及びパブリックエンドポイントのペアを示すＣＰまたはＣｃＰｐと略記することができる。任意の所与のＴＣＰフロー（またはＣＰペア）に関連付けられたパケットは、上流側のエッジルータ１０４からのハッシュ化等価コストマルチパス（ＥＣＭＰ）フロー分散によって、入口サーバ１１２として動作する任意のロードバランサノード１１０に現れることができる。しかしながら、ＴＣＰフローのためのパケットは、概して、ＴＣＰフローをリダイレクトする原因となるリンクまたはロードバランサノード１１０の障害が存在しない限り、同じロードバランサノード１１０に継続して到着することができる。上流側のルータ１０４からＴＣＰフローのためのパケットを受け取るロードバランサノード１１０は、ＴＣＰフローのための入口ノードと呼ばれる。

少なくともいくつかの実施形態では、コンシステントハッシングを使用し、それにより、パケットがＴＣＰフローのための入口ノードとして機能するロードバランサノード１１０に到着すると、入口ノードは、どのロードバランサノード１１０がＴＣＰフローについての状態を含んでいるか（すなわち、フロートラッカーノード）を決定することができる。ＣＰペアは、どのロードバランサノード１１０がＴＣＰフローに関連する状態を維持することを担当しているか決定するために、入口ノードによってコンシステントハッシュリングにハッシュ化することができる。このノードは、ＴＣＰフローのための１次フロートラッカーとして機能する。コンシステントハッシュリングの後継ノードは、ＴＣＰフローのための２次フロートラッカーとして機能する。

少なくともいくつかの実施形態では、全てのロードバランサノード１１０は、入口ノード、１次フロートラッカーノード、及び２次フロートラッカーノードとして機能することができる。ＴＣＰフローのコンシステントハッシュの結果に依存して、ＴＣＰフローのための入口ノードとして機能するロードバランサノード１１０はまた、ＴＣＰフローのための１次または２次フロートラッカーノードとして機能することができる。しかしながら、少なくともいくつかの実施形態では、異なる物理的ロードバランサノード１１０がＴＣＰフローのための１次及び２次フロートラッカーの役割を行う。

接続の確立
図１０Ａを参照すると、クライアント１６０からの新規の接続は、クライアントＴＣＰ同期（ＳＹＮ）パケットによって始動することができる。ロードバランサノード１１０は、ＳＹＮパケットを受け取ると、サーバノード１３０との接続を実際に確立せず、また接続を受け取るためのサーバノード１３０を即座に選択もしない。その代りに、ロードバランサノード１１０は、クライアントのＳＹＮパケットから関連のデータを格納し、選択されることになるサーバノード１３０に代わって、ＳＹＮ／ＡＣＫパケットを生成する。図１０Ｃを参照すると、クライアント１６０がＴＣＰスリーウェイハンドシェイクにおいて第１のＡＣＫパケットで一旦応答すると、ロードバランサノード１１０は、サーバノード１３０を選択し、そのサーバノード１３０のための等価ＳＹＮパケットを生成し、サーバノード１３０との実際のＴＣＰ接続を確立することを試みる。

図１０Ａを再び参照すると、ＴＣＰフローのための入口サーバ１１２として機能するロードバランサノード１１０でクライアントＳＹＮパケットを受け取ると、入口サーバ１１２は、ＳＹＮパケットからデータフィールドを抽出し、データをＴＣＰフローのための１次フロートラッカー１１６Ａに転送する。１次フロートラッカー１１６Ａは、データを、例えばハッシュテーブルに格納し、初期ＴＣＰシーケンス番号（ＴＣＰ接続のサーバ側のための）を生成し、同じデータを２次フロートラッカー１１６Ｂに転送する。２次フロートラッカー１１６Ｂは、サーバＴＣＰシーケンス番号を含むクライアント１６０のためのＳＹＮ／ＡＣＫパケットを作成する。

図１０Ａでは、入口サーバ１１２、１次フロートラッカー１１６Ａ、及び２次フロートラッカー１１６Ｂの役割は、各々異なるロードバランサノード１１０によって行われる。しかしながら、いくつかの場合では、ＴＣＰフローのための入口サーバ１１２として機能するロードバランサノード１１０は、ＴＣＰフローのための１次フロートラッカー１１６Ａまたは２次フロートラッカー１１６Ｂとして機能する同じノード１１０であってもよい（しかし、両方ではない）。パケットフローのための入口サーバ１１２がそのフローのためのフロートラッカー１１６と同じノード１１０にあってもよいことの理由は、エッジルータ１０４は、フロー毎ハッシュ化マルチパスルーティング技術（例えば、ＥＣＭＰルーティング技術）に従って、そのフローのための入口サーバ１１２を擬似無作為的に選択し、一方そのパケットフローのためのフロートラッカー１１６は、パケットフローのアドレス情報に適用されるコンシステントハッシュ関数に従って、コンシステントハッシュリング上で決定されるということである。パケットフローのための入口サーバ１１２が、そのパケットフローのためのフロートラッカー１１６と同じノード１１０にある場合、ＳＹＮパケットからのデータは、入口サーバ１１２を実装するノード１１０から他のフロートラッカー１１６ノード１１０に転送されるだけでよい。例えば、図１０Ｂでは、１次フロートラッカー１１６Ａは、ＴＣＰフローのための入口サーバ１１２と同じロードバランサノード１１０Ａにあり、一方２次フロートラッカー１１６Ｂは、異なるロードバランサノード１１０Ｂにあり、したがってＳＹＮパケットからのデータは、ノード１１０Ａから（フロートラッカー１１６Ａによって）ロードバランサノード１１０Ｂの２次フロートラッカー１１６Ｂに転送される。

図１０Ｃを参照すると、非ＳＹＮパケットが入口サーバ１１２に到着すると、入口サーバ１１２は、パケットをどのサーバノード１３０に転送すべきかを既知であるか、または既知でないかのいずれかである。ＴＣＰフローのための入口サーバ１１２に到着する第１の非ＳＹＮパケットは、ＴＣＰスリーウェイハンドシェイクにおける第１のＴＣＰ受信確認（ＡＣＫ）パケット（または、おそらく後続のデータパケット）であるべきであり、ＴＣＰ受信確認番号フィールドは、図１０ＡのＳＹＮ／ＡＣＫパケットで送られたサーバシーケンス番号（＋１）に一致する。入口サーバ１１２が、サーバマッピングを有していない非ＳＹＮパケットを受け取ると、それは、ＴＣＰフローのための１次フロートラッカー１１６Ａにメッセージを転送し、メッセージは、シーケンス番号のようなＡＣＫパケットからの情報を含み、またはあるいは、ＡＣＫパケット自体を含む。少なくともいくつかの場合では、１次フロートラッカー１１６Ａは、ＴＣＰフローのための格納されたデータを記憶し、受信確認されたシーケンス番号（＋１）がＳＹＮ／ＡＣＫパケットでクライアント１６０に送られた値に一致することを確認する。１次フロートラッカーは、次に、ＴＣＰフローのためのサーバノード１３０を選択し、ＴＣＰフローのための以前に格納されたデータ、サーバのシーケンス番号、及び選択されたサーバノード１３０のロードバランサモジュール１３２のＩＰアドレスを含む別のメッセージを、２次フロートラッカー１１６Ｂに転送する。２次フロートラッカー１１６Ｂは、サーバのシーケンス番号を確認し、情報を記録し、作成されたＳＹＮメッセージを選択されたサーバノード１３０のロードバランサモジュール１３２に送る。ＴＣＰフローのＣＰエンドポイントのペアは、この時点で、ロードバランサモジュール１３２／サーバノード１３０にマッピングされる。サーバノード１３０のロードバランサモジュール１３２は、作成されたＳＹＮメッセージを２次フロートラッカー１１６Ｂから受け取ると、サーバノード１３０のサーバ１３４のための正規のＴＣＰ ＳＹＮパケットを作成することを担当する。ＳＹＮパケットを作成する際に、送信元ＩＰアドレスにクライアント１６０の実際のＩＰアドレスが取り込まれ、その結果、サーバ１３４は、クライアント１６０から直接のＴＣＰ接続要求を受け取ったと確信する。ロードバランサモジュール１３２は、ＴＣＰフローに関する関連の詳細を、例えばローカルのハッシュテーブルに格納し、ＴＣＰ ＳＹＮパケットをサーバ１３４に送る（例えば、ＳＹＮパケットをサーバ１３４のＬｉｎｕｘカーネルに注入する）。

図１０Ｃでは、入口サーバ１１２、１次フロートラッカー１１６Ａ、及び２次フロートラッカー１１６Ｂの役割は、各々異なるロードバランサノード１１０によって行われる。しかしながら、いくつかの場合では、ＴＣＰフローのための入口サーバ１１２として機能するロードバランサノード１１０は、ＴＣＰフローのための１次フロートラッカー１１６Ａまたは２次フロートラッカー１１６Ｂとして機能する同じノード１１０であってもよい（しかし、両方ではない）。例えば、図１０Ｄでは、２次フロートラッカー１１６Ｂは、ＴＣＰフローのための入口サーバ１１２と同じロードバランサノード１１０Ａにあり、一方１次フロートラッカー１１６Ａは、異なるロードバランサノード１１０Ｂにある。

図１０Ｅを参照すると、サーバ１３４（例えば、Ｌｉｎｕｘカーネル）は、ロードバランサモジュール１３２もまた傍受するＳＹＮ／ＡＣＫパケットで応答する。ＳＹＮ／ＡＣＫパケットは、２次フロートラッカー１１６Ｂから生成されたＳＹＮ／ＡＣＫでクライアント１６０に元々配信された（図１０Ａを参照）ものとは異なるＴＣＰシーケンス番号を含むことができる。ロードバランサモジュール１３２は、シーケンス番号デルタを着信及び発信パケットに適用することを担当する。サーバ１３４からのＳＹＮ／ＡＣＫパケットはまた、ロードバランサモジュール１３２から２次フロートラッカー１１６Ｂに戻されるメッセージ（例えば、ＵＤＰメッセージ）を始動し、選択されたサーバノード１３０／ロードバランサモジュール１３２／サーバ１３４への接続が成功したことを示す。このメッセージを受け取ると、２次フロートラッカー１１６Ａは、クライアント１６０とサーバ１３４との間のクライアント及びパブリックエンドポイント（ＣＰ）マッピングをコミットされたものとして記録し、同様のメッセージを、ＣＰマッピングを同様に記録する１次フロートラッカー１１６Ａに送ることができる。１次フロートラッカー１１６Ａは、次に、ＣＰマッピングメッセージを入口サーバ１１２に転送することができ、それは入口サーバ１１２に、サーバノード１３０のローカルのロードバランサモジュール１３２への接続のための全てのバッファされたデータパケットをカプセル化データパケットとして、転送させる。

図１０Ｆを参照すると、接続のためのＣＰマッピングは、入口サーバに既知であり、その結果、接続のために入口サーバ１１２によって受け取られる着信ＴＣＰパケットは、カプセル化され（例えば、ＵＤＰに従って）、サーバノード１３０のローカルのロードバランサモジュール１３２にカプセル化データパケットとして直接に転送することができる。ロードバランサモジュール１３２は、データパケットをデカプセル化し、ＴＣＰパケットを、例えばＴＣＰパケットをカーネルのＴＣＰスタックに注入することにより、サーバノード１３０のサーバ１３４に送る。サーバ１３４からのアウトバウンドパケットは、サーバノード１３０のロードバランサモジュール１３２によって傍受され、カプセル化され（例えば、ＵＤＰに従って）、ロードバランサモジュール１３２がこの接続のために出口サーバ１１４として無作為に選択する任意のロードバランサノード１１０に転送される。出口サーバ１１４は、パケットをデカプセル化し、デカプセル化パケットをクライアント１１６に送る。選択されたロードバランサノード１１０の出口機能は、ステートレスであり、その結果、異なるロードバランサノード１１０は、出口サーバとして機能するロードバランサノード１１０の障害が発生すると、接続のための出口サーバ１１４として選択することができる。しかしながら、概して同じロードバランサノード１１０は、アウトバウンドパケットの再配列を減少させる、または除去するために、接続の期間にわたって出口サーバ１１４として使用される。

図１０Ｇを参照すると、少なくともいくつかの実施形態では、１次フロートラッカー１１６Ａによって選択されたサーバノード１３０Ａのロードバランサモジュール１３２Ａ（図１０Ｃを参照）が、それがオーバーロード状態であることを決定する場合、それは、２次フロートラッカー１１６Ｂから受け取る作成されたＳＹＮメッセージを拒否する選択肢を有する（図１０Ｃを参照）。少なくともいくつかの実施形態では、作成されたＳＹＮメッセージは、存続可能時間（ＴＴＬ）値または拒否の最大数を許容するカウンタを含む。少なくともいくつかの実施形態では、このＴＴＬ値がゼロに達すると、ロードバランサモジュール１３２Ａは、接続を受け入れるか、または接続をドロップしてロードを捨てるか、のいずれかを行うことができる。ロードバランサモジュール１３２Ａが、接続を拒否することを決定する場合、それは、ＴＴＬ値をデクリメントし、拒否メッセージを２次フロートラッカー１１６Ｂに送る。２次フロートラッカー１１６Ｂは、ＣＰマッピングをリセットし、同じことを行うように解放メッセージを１次フロートラッカー１１６Ａに送る。１次フロートラッカー１１６Ａは、別のサーバノード１３０Ｂの新規のロードバランサモジュール１３２Ｂを選び、新規の対象となるメッセージを２次フロートラッカー１１６Ｂに送り返し、それは、新規の作成されたＳＹＮメッセージを新規に選ばれたロードバランサモジュール１３２Ｂに送る。パケットのドロップは、このシーケンスが完了することに失敗する結果になる場合もあるが、クライアント１６０からの再送信は、ロードバランサモジュール選択プロセスを１次フロートラッカー１１６Ａで再び始動させることができ、それは、必ずではないが、作成されたＳＹＮパケットの以前の拒否について学習していなかった場合、接続のために同じロードバランサモジュール１３２を選ぶことに留意されたい。

少なくともいくつかの実施形態では、ＴＴＬカウンタは、サーバノード１３０に接続要求を連続して送ることを防ぐために使用することができ、それは、例えば、全てのサーバノード１３０が使用中になっている場合に、起こることがある。少なくともいくつかの実施形態では、ロードバランサモジュール１３２がそれぞれのサーバノード１３０に代わって接続要求を拒否する度に、ロードバランサモジュール１３２は、ＴＴＬカウンタをデクリメントする。フロートラッカーノード１１６は、ＴＴＬカウンタを監視することができ、ＴＴＬカウンタがゼロでない（または、ある指定された閾値より上である）限り、別のサーバノード１３０を選択し、再び試行することができる。ＴＴＬカウンタがゼロに達する（または、指定された閾値に達する）場合、接続要求はドロップされ、その接続のためにサーバノード１３０のうちの選択された１つに接続要求を送る更なる試みは、フロートラッカーノード１１６によって行われない。少なくともいくつかの実施形態では、エラーメッセージをそれぞれのクライアント１６０に送ることができる。

少なくともいくつかの実施形態では、分散型ロードバランサシステムは、複数のパブリックＩＰアドレスをサポートする。このように、クライアント１６０は、同じクライアントポート番号から２つの異なるパブリックＩＰアドレスへの２つのＴＣＰ接続を開始することができる。これらのＴＣＰ接続は、クライアント１６０の観点からすると異なっているが、内部では分散型ロードバランサは、その接続を同じサーバノード１３０にマッピングすることがあり、衝突をもたらすことがある。少なくともいくつかの実施形態では、潜在的な衝突を検出して取り扱うために、ロードバランサモジュール１３２は、図１０Ｃ及び１０Ｄで示されるように作成されたＳＹＮパケットを２次フロートラッカー１１６Ｂから受け取ると、アドレス情報をそのアクティブな接続と比較し、この接続が衝突の原因となっている場合、図１０Ｇで示されるように接続要求を拒否することができる。

ロードバランサノードの障害及び追加の取り扱い
多くの従来のロードバランサでは、ロードバランサの障害が発生すると一部または全部の既存の接続が失われる。少なくともいくつかの実施形態では、単一のロードバランサノード１１０の障害が発生すると、分散型ロードバランシングシステムは、確立された接続の少なくともいくつかを維持することができ、その結果、クライアント及びサーバは、接続が正常に完了するまで、接続を介してパケットの交換を継続することができる。さらに、分散型ロードバランシングシステムは、障害発生の時点で確立される過程にあったサービス接続を継続することができる。

分散型ロードバランシングシステムの少なくともいくつかの実施形態では、単一のロードバランサノード１１０の障害が発生すると既存のクライアント接続をリカバリすることができる障害リカバリプロトコルを実装することができる。しかしながら、複数のロードバランサノード１１０の障害は、クライアント接続が失われる結果となることがある。少なくともいくつかの実施形態では、クライアント１６０とサーバ１３４との間のＴＣＰ再送信は、ロードバランサノード１１０の障害に続くリカバリの手段として使用することができる。

潜在的なロードバランサノード１１０の障害に加えて、新規のロードバランサノード１１０を分散型ロードバランサシステムに追加することができる。これらの新規のノード１１０は、ロードバランサ層に、したがってコンシステントハッシュリングに追加することができ、既存のクライアント接続に関するロードバランサノード１１０の役割は、必要に応じて、変更に従って調整することができる。

フロートラッカーノードの障害及び追加の取り扱い
少なくともいくつかの実施形態では、各々の接続が確立されると（例えば、図１０Ａ〜１０Ｇを参照）、接続状態情報は、１次及び２次フロートラッカーと呼ばれる２つのロードバランサノード１１０を通過し、それらは、例えば、（クライアントＩＰ：ポート、パブリックＩＰ：ポート）タプルをハッシュ関数入力として使用するコンシステントハッシュアルゴリズムを使用して決定することができる。単一のロードバランサノード１１０の障害が発生すると、生き残っているロードバランサノード１１０の内の少なくとも１つは、コンシステントハッシュ関数を介して継続してマッピングすることができ、パケットを接続のための選択されたサーバノード１３０に向ける接続に必要な状態情報を含むことができる。さらに、ロードバランサノード１１０をコンシステントハッシュリングに追加する場合では、接続のための状態情報は、適切なフロートラッカーに更新することができる。

図１１Ａ〜１１Ｄは、少なくともいくつかの実施形態に従う、ロードバランサノードのコンシステントハッシュリングのメンバーシップに影響を与えるイベントの取り扱いを例示する。これらのイベントは、限定されるものではないが、新規の１次フロートラッカーノードを追加すること、新規の２次フロートラッカーノードを追加すること、１次フロートラッカーノードの障害、及び２次フロートラッカーノードの障害を含むことができる。

図１１Ａは、コンシステントハッシュリングへの新規の１次フロートラッカーノードの追加の取り扱いを例示する。図１１Ａの上部行は、フロートラッカー１１６Ａを１つ以上のクライアント接続のための１次フロートラッカーとして、及びフロートラッカーノード１１６Ｂを同じ接続（複数可）のための２次フロートラッカーとして、示す。図１１Ａの底部行では、新規のフロートラッカーノード１１６Ｃが追加され、クライアント接続（複数可）のための１次フロートラッカーになっている。フロートラッカーノード１１６Ａは、以前は１次フロートラッカーであったが、２次フロートラッカーになり、一方フロートラッカーノード１１６Ｂは、以前は２次フロートラッカーであったが、コンシステントハッシュリング内の次のフロートラッカーになっている。フロートラッカー１１６Ａ及び１１６Ｂによって維持されていたクライアント接続（複数可）のための状態情報は、新規の１次フロートラッカー１１６Ｃに提供することができる。さらに、フロートラッカー１１６Ｂは、２次フロートラッカーの役割でそれの以前に追跡された接続を「忘れる」ことができる。

図１１Ｂは、コンシステントハッシュリングへの新規の２次フロートラッカーノードの追加の取り扱いを例示する。図１１Ｂの上部行は、フロートラッカー１１６Ａを１つ以上のクライアント接続のための１次フロートラッカーとして、及びフロートラッカーノード１１６Ｂを同じ接続（複数可）のための２次フロートラッカーとして示す。図１１Ｂの底部行では、新規のフロートラッカーノード１１６Ｃが追加され、クライアント接続（複数可）のための２次フロートラッカーになっている。フロートラッカーノード１１６Ａは、接続（複数可）のための１次フロートラッカーとして残り、一方フロートラッカーノード１１６Ｂは、以前は２次フロートラッカーであったが、コンシステントハッシュリング内の次のフロートラッカーになっている。フロートラッカー１１６Ａ及び１１６Ｂによって維持されていたクライアント接続（複数可）のための状態情報は、新規の２次フロートラッカー１１６Ｃに提供することができる。さらに、フロートラッカー１１６Ｂは、２次フロートラッカーの役割でそれの以前に追跡された接続を「忘れる」ことができる。

図１１Ｃは、コンシステントハッシュリング内の１次フロートラッカーノードの障害の取り扱いを例示する。図１１Ｃの上部行は、フロートラッカー１１６Ａを１つ以上のクライアント接続のための１次フロートラッカーとして、フロートラッカーノード１１６Ｂを同じ接続（複数可）のための２次フロートラッカーとして、及びフロートラッカーノード１１６Ｃをコンシステントハッシュリング内の次のフロートラッカーとして示す。図１１Ｃの底部行では、１次フロートラッカーノード１１６Ａに障害が発生している。フロートラッカーノード１１６Ｂは、接続（複数可）のための１次フロートラッカーになり、一方フロートラッカーノード１１６Ｃは、接続（複数可）のための２次フロートラッカーになっている。クライアント接続（複数可）のための状態情報は、フロートラッカー１１６Ｂによって維持され、新規の２次フロートラッカー１１６Ｃに提供することができる。

図１１Ｄは、コンシステントハッシュリング内の２次フロートラッカーノードの障害の取り扱いを例示する。図１１Ｄの上部行は、フロートラッカー１１６Ａを１つ以上のクライアント接続のための１次フロートラッカーとして、フロートラッカーノード１１６Ｂを同じ接続（複数可）のための２次フロートラッカーとして、及びフロートラッカーノード１１６Ｃをコンシステントハッシュリング内の次のフロートラッカーとして示す。図１１Ｄの底部行では、２次フロートラッカーノード１１６Ｂに障害が発生している。フロートラッカーノード１１６Ａは、接続（複数可）のための１次フロートラッカーとして残り、一方フロートラッカーノード１１６Ｃは、接続（複数可）のための２次フロートラッカーになっている。クライアント接続（複数可）のための状態情報は、フロートラッカー１１６Ｂによって維持され、新規の２次フロートラッカー１１６Ｃに提供することができる。

少なくともいくつかの実施形態では、サーバノード１３０のロードバランサモジュール１３２は、ロードバランサノード１１０への接続公開を行う。少なくともいくつかの実施形態では、接続公開は、現在の接続状態情報を、サーバノード１３０からフロートラッカーノード及び入口ノードとして機能するロードバランサノード１１０に、周期的（例えば、１秒に１回）または非周期的にプッシュし、それは、接続のための１次及び２次フロートラッカーノードの両方への接続マッピングを更新する、または復元するように動作する。少なくともいくつかの実施形態では、ロードバランサモジュール１３２は、フロートラッカーのメンバーシップの変更、例えば図１１Ａ〜１１Ｄに例示されたようなもの、を検出することができる。それに応じて、ロードバランサモジュール１３２は、接続公開を行い、メンバーシップが変更したときに接続に関して変更した可能性がある１次及び２次フロートラッカーノードに接続に関する状態情報を取り込むことができる。接続公開は、複数のロードバランサノードの障害が発生したときに、少なくとも一部の確立された接続をリカバリすることが可能であることに留意されたい。

障害関連メッセージフロー
少なくともいくつかの実施形態では、１次と２次フロートラッカーノードとの間のプロトコルは、補正または同期機能を含むことができる。例えば、図１１Ａを参照すると、新規の１次フロートラッカーノード１１６Ｃがコンシステントハッシュリングに加わると、新規のノード１１６Ｃは、いくつかの数の接続（約１／Ｎ）をコンシステントハッシュ鍵空間に主張し、これらの接続に関連するトラフィックをエッジルータ１０４から受け取ることを開始することができる。しかしながら、新規の１次フロートラッカーノード１１６Ｃは、接続に関して格納された一切の状態を有していないので、それは、クライアント１６０から受け取った第１のパケットであるかのように各々のパケットに対して動作することができる。１次フロートラッカーは、ＳＹＮパケットに応じてサーバＴＣＰシーケンス番号を生成すること（例えば、図１０Ａを参照）、及びクライアント１６０からの第１のＡＣＫパケットに応じてサーバノード１３０を選択すること（例えば、図１を参照）を担当し、それらの生成された値は、以前の１次フロートラッカー（図１１Ａのフロートラッカーノード１１６Ａ）によって選ばれた値に一致しないことがある。しかしながら、少なくともいくつかの実施形態では、コンシステントハッシュアルゴリズムは、以前の１次フロートラッカー（図１１Ａのフロートラッカーノード１１６Ａ）を２次フロートラッカーの役割に割り当て、このフロートラッカーは、接続に関して以前に格納された状態を依然として保持する。したがって、少なくともいくつかの実施形態では、２次フロートラッカー（図１１Ａのフロートラッカーノード１１６Ａ）が１次フロートラッカー１１６Ｃから受け取った情報の中に不一致を検出すると、それは、更新メッセージを１次フロートラッカー１１６Ｃに送り返し、接続のためのフロートラッカーとして機能する２つのロードバランサノード１１０を同期させることができる。同様な方法を使用し、コンシステントハッシュリングのメンバーシップ内の他の変更の後で、フロートラッカーを同期させることができる。

ロードバランサモジュールの詳細
少なくともいくつかの実施形態では、ロードバランサモジュール１３２は、サーバノード１３０の各々に存在する分散型ロードバランサシステムの構成要素である。ロードバランサノード１３２の役割は、限定されるものではないが、ロードバランサノード１１０から受け取ったパケットをデカプセル化すること及びデカプセル化パケットをサーバノード１３０のサーバ１３４に送ること、並びにサーバ１３４からの発信パケットをカプセル化すること及びカプセル化パケットをロードバランサノード１１０に送ること、を含む。

少なくともいくつかの実施形態では、入口サーバ１１２として機能するロードバランサノード１１０からサーバノード１３０のロードバランサモジュール１３２への着信パケットは、実際のクライアントデータパケットをカプセル化するステートレスのプロトコル（例えば、ＵＤＰ）パケットである。各々のカプセル化クライアントデータパケットは、それぞれのクライアント１６０のオリジナルのクライアントＩＰ：ポートを送信元アドレスとして、及びサーバ１３４のパブリックＩＰ：ポートを送信先アドレスとして、有する。ロードバランサモジュール１３２は、クライアントデータパケットからカプセル化を取り除き、例えばパケットをローカルホストＴＣＰフローにリダイレクトすることにより、パケットをサーバノード１３０のそれぞれのサーバ１３４に送る。

少なくともいくつかの実施形態では、サーバ１３４から出口サーバ１１４として機能するロードバランサノード１１０への発信パケットは、発信ＩＰパケットをカプセル化するステートレスのプロトコル（例えば、ＵＤＰ）パケットである。ロードバランサモジュール１３２は、発信ＩＰパケットをカプセル化し、カプセル化パケットを、ファブリック１２０を介して出口サーバ１１４に送る。各々のカプセル化発信ＩＰパケットは、サーバ１３４のパブリックＩＰ：ポートを送信元アドレスとして、及びそれぞれのクライアント１６０のクライアントＩＰ：ポートを送信先アドレスとして、有する。

ロードバランサモジュールの機能
少なくともいくつかの実施形態では、サーバノード１３０のロードバランサモジュール１３２の機能は、限定されるものではないが、以下のうちの１つ以上を含むことができる、
・ロードバランサノード（複数可）１１０からの、例えばクライアント１６０への接続を取り扱う入口サーバ１１２からのＵＤＰトンネルを終端すること。これは、入口サーバ１１２から受け取った着信クライアントデータパケットからＵＤＰカプセル化を取り除くことを含む。
・接続のための発信トラフィックを受け取る出口サーバ１１４を選択すること。
・それぞれのサーバ１３４への接続で発信ＩＰパケットを傍受すること、接続のための発信ＩＰパケットをカプセル化すること、及びカプセル化パケットを出口サーバ１１４に送ること。
・着信及び発信パケット内のシーケンス番号をマングリングし、その結果、フロートラッカーノード１１６がＳＹＮ／ＡＣＫをクライアント１６０に送ったとき、シーケンス番号が、フロートラッカーノード１１６によって生成されたシーケンス番号に整合する。
・それぞれのサーバ１３４のための接続を受け入れるか、拒否するかを、例えばそれぞれのサーバ１３４の現在のロードを示す１つ以上のメトリックに基づいて、決定を行うこと。
・クライアントＩＰ：ポートアドレスのためのアクティブな接続が存在する場合、同じクライアントＩＰ：ポートアドレスからそれぞれのサーバ１３４への接続を検出し、拒否して、衝突を回避すること。
・接続の追跡及び接続の公開。

ロードバランサモジュール構成情報
少なくともいくつかの実施形態では、各々のロードバランサモジュール１３２は、限定されるものではないが、その構成に関する情報の以下のセット、ロードバランサノード１１０のエンドポイントのセット、それが提供すべき有効なパブリックＩＰアドレスのセット、及びそれぞれのサーバ１３４が着信接続を受け入れるポート番号（複数可）、のうちの１つ以上を取得し、ローカルで格納することができる。少なくともいくつかの実施形態では、この情報は、図１に例示されるように、分散型ロードバランサシステムの構成サービス１２２の構成要素から取得することができる、またはそれにアクセスまたは照会することによって更新することができる。いくつかの実施形態では、情報を取得する他の方法を使用することができる。

ロードバランサモジュールのパケット取り扱い
以下では、少なくともいくつかの実施形態に従うインバウンドトラフィック及びアウトバウンドトラフィックに対するロードバランサモジュール１３２の動作を説明する。少なくともいくつかの実施形態では、インバウンドデータパケットがロードバランサモジュール１３２によって受け取られるとき、データパケットは、ＵＤＰパケットからデカプセル化され、デカプセル化ＴＣＰパケット内の送信先アドレスは、最初に、構成された有効パブリックＩＰアドレスのセットに対して検証される。一致しない場合、パケットはドロップされるまたは無視される。少なくともいくつかの実施形態では、ロードバランサモジュール１３２は、一定のデルタによってＴＣＰヘッダ内のシーケンス番号を調整することができ、その結果、シーケンス番号は、ＳＹＮ／ＡＣＫパケットをクライアント１６０に送ったフロートラッカーノード１１６によって生成される無作為に選ばれたシーケンス番号に一致する。ロードバランサモジュール１３２は、［クライアント：パブリック］エンドポイントから［クライアント：サーバ］エンドポイントへのマッピングを内部状態として記録する。

少なくともいくつかの実施形態では、サーバ１３４からのアウトバウンドＴＣＰパケットの場合、ロードバランサモジュール１３２は、その内部状態を最初にチェックし、パケットはロードバランサモジュールが管理しているアクティブな接続のためのものであるかを決定する。そうではない場合、ロードバランサモジュール１３２は、パケットを通過させるだけである。そうである場合、ロードバランサモジュール１３２は、発信ＴＣＰパケットを例えばＵＤＰに従ってカプセル化し、カプセル化パケットをこの接続のための出口サーバ１１４として選択されたロードバランサノード１１０に転送する。少なくともいくつかの実施形態では、ロードバランサモジュール１３４は、一定のデルタによって発信ＴＣＰパケット内のＴＣＰシーケンス番号を調整することができ、その結果、それは、ＳＹＮ／ＡＣＫパケットをクライアント１６０に送ったフロートラッカーノード１１６によって生成されたシーケンス番号に整合する。

接続の追跡
少なくともいくつかの実施形態では、各々のサーバノード１３０のロードバランサモジュール１３２は、それぞれのサーバ１３４の全てのアクティブなクライアント接続に関する接続の詳細を含むハッシュテーブルを管理する。少なくともいくつかの実施形態では、ハッシュテーブルのための鍵は、（クライアントＩＰ：ポート、パブリックＩＰ：ポート）タプルである。少なくともいくつかの実施形態では、各々のクライアント接続に関する接続状態は、限定されるものではないが、以下のうちの１つ以上を含む、
・クライアントＩＰ：ポート。
・パブリックＩＰ：ポート。
・フロートラッカー１１６ノードによって提供される初期サーバＴＣＰシーケンス番号。
・サーバＴＣＰシーケンス番号デルタ。
・オリジナルの１次フロートラッカーＩＰアドレス
・オリジナルの２次フロートラッカーＩＰアドレス。
・最後に検出された入口サーバ１１２のＩＰアドレス。
・このエントリに関する有効期間。
・最小使用頻度（ＬＲＵ）／衝突指標。

少なくともいくつかの実施形態では、各々のロードバランサモジュール１３２は、接続公開メッセージを全てのアクティブなクライアント接続のための１次及び２次フロートラッカーノードに周期的に生成する。少なくともいくつかの実施形態では、／ｐｒｏｃ／ｎｅｔ／ｔｃｐのコンテンツは、ロードバランサモジュールのハッシュテーブル内のアクティブな接続でスキャンされ、また交差し、その結果それらは、Ｌｉｎｕｘカーネルが接続の追跡を停止するまで、フロートラッカーノードに継続して公開される。接続公開は、本明細書の後半でより詳細に説明される。

シーケンス番号マングリング
前述のように、少なくともいくつかの実施形態では、ロードバランサノード１１０は、サーバ１３４に代わってクライアント１６０のＳＹＮパケットに応じてＳＹＮ／ＡＣＫパケットを生成する。クライアント１６０がＡＣＫパケット（ＴＣＰスリーウェイハンドシェイク）を送った後にのみ、ロードバランサモジュール１１０は、任意のデータをサーバノード１３０のロードバランサモジュール１３２に送る。ロードバランサモジュール１３２が最初にクライアント接続を確立するように命令されると、ロードバランサモジュール１３２は、ＳＹＮパケットをローカルで作成してサーバノード１３０のサーバ１３４とのＴＣＰ接続を開始し、サーバ１３４の対応するＳＹＮ／ＡＣＫパケットを傍受する。典型的には、サーバ１３４（例えば、サーバノード１３０のＬｉｎｕｘカーネル）は、クライアントがロードバランサノード１１０からＳＹＮ／ＡＣＫパケット内で受け取ったものとは全く異なるＴＣＰシーケンス番号を選択する。したがって、少なくともいくつかの実施形態では、ロードバランサモジュール１３２は、クライアント１６０とサーバ１３４との間のＴＣＰ接続における全てのパケット内のシーケンス番号を補正することができる。少なくともいくつかの実施形態では、ロードバランサモジュール１３２は、ロードバランサノード１１０によって生成されたシーケンス番号とサーバ１３４によって生成されたシーケンス番号との間の差を計算し、その差をデルタ値としてＴＣＰ接続のためのハッシュテーブルエントリ内に格納する。着信データパケットが接続上のクライアント１６０から到着すると、ＴＣＰヘッダは、サーバ１３４によって使用されるシーケンス番号に整合しない受信確認番号を含み、ロードバランサモジュール１３２は、デルタ値をＴＣＰヘッダ内のシーケンス番号値から減算する（例えば、２つの補数を使用して）。ロードバランサモジュールはまた、デルタ値をサーバ１３４から接続上のクライアント１３０へのアウトバウンドパケット内のシーケンス番号に加算する。

分散型ロードバランサシステムのヘルスチェック
分散型ロードバランサシステムの少なくともいくつかの実施形態では、各々のロードバランサノード１１０は、少なくとも以下の理由から、ロードバランサ実現形態の健全なメンバーの（すなわち、健全なロードバランサノード１１０及びサーバノード１３０の）コンシステントビューを要求する、
・ロードバランシング−ロードバランサノード１１０は、サーバノード１３０の障害を検出し、クライアントトラフィックを受け入れることができる健全なサーバノード１３０のセットを収束する必要がある。
・分散状態管理−ロードバランサは、複数のロードバランサノード１１０にわたり（例えば、コンシステントハッシング機構に従って）共有された／複製された状態を備える分散型システムである。クライアントトラフィックを適正に取り扱うために、各々のロードバランサノード１１０は、ロードバランサ実現形態の健全なメンバーノード１１０の最終的なコンシステントビューを有する必要がある。

これを実現するために、分散型ロードバランサシステムの少なくともいくつかの実施形態は、ロードバランサ実現形態のノードを監視し、可能な限り迅速に不健全なノードを検出するヘルスチェックプロトコルの実施形態を実装する。ヘルスチェックプロトコルは、ヘルス情報をロードバランサ実現形態のノード間に伝搬させることができ、ノードが健全ノードのセットに収束することを可能にする方法を提供することができる。さらに、ヘルスチェックプロトコルは、ロードバランサ実現形態の健全／不健全ノード及び状態変化を報告するための機構を提供することができる。

少なくともいくつかの実施形態では、ヘルスチェックプロトコルは、限定されるものではないが、以下の前提条件のうちの１つ以上に基づくことができる、
・ロードバランサ実現形態の全てのノードが既知である。（すなわち、ヘルスチェックプロトコルは探索を行わなくてもよい）。
・全てのノード障害は、フェイルストップである。
・ノード間の全てのメッセージはステートレスプロトコル（例えば、ＵＤＰ）メッセージであり、メッセージは、ドロップ、遅延、重複、または破損している可能性がある。メッセージ配信は保証されていない。

少なくともいくつかの実施形態では、ロードバランサ実現形態のノード（例えば、ロードバランサノード１１０またはサーバノード１３０）は、以下の条件下で健全とみなすことができる、
・ノードの内部の構成要素の全てが準備完了状態にある（クライアントトラフィックを取り扱う準備が完了している）。
・ノードの着信／発信ネットワークリンクが健全である（少なくともクライアントトラフィックがフローするネットワークインターフェースコントローラ（ＮＩＣ）に関して）。

図１２は、少なくともいくつかの実施形態に従う、ヘルスチェック間隔に従って各々のロードバランサノードによって行うことができるヘルスチェック方法の高レベルのフローチャートである。１０００に示されるように、各々のロードバランサ間隔で、例えば１００ミリ秒毎で、各々ロードバランサ（ＬＢ）ノード１１０は、少なくとも１つの他のＬＢノード１１０及び少なくとも１つのサーバノード１３０をヘルスチェックすることができる。１００２に示されるように、ロードバランサノード１１０は、そのローカルに格納されたヘルス情報をヘルスチェックに従って更新することができる。１００４に示されるように、ロードバランサノード１１０は、次に、少なくとも１つの他のロードバランサノード１１０を無作為に選択し、そのヘルス情報を選択されたロードバランサノード（複数可）１１０に送ることができる。少なくともいくつかの実施形態では、ノード１１０はまた、健全なロードバランサノード１１０のリストを１つ以上のサーバノード１３０、例えばノード１１０によってヘルスチェックされる同じサーバノード（複数可）１３０に送ることができる。図１２の要素は、以下の考察でより詳細に説明される。

ヘルスチェックプロトコルの少なくともいくつかの実施形態では、ロードバランサノード１１０は、それ自身のヘルスを他のロードバランサノード１１０にアサートしない。その代りに、１つ以上の他のロードバランサノード１１０は、そのノード１１０をヘルスチェックすることができる。例えば、少なくともいくつかの実施形態では、各々のロードバランサノード１１０は、ヘルスチェックするための１つ以上の他のノード１１０を周期的または非周期的に無作為に選択することができる。別の実施例として、少なくともいくつかの実施形態では、１つ以上の他のロードバランサノード１１０、例えばコンシステントハッシュリングのようなノード１１０の順序付けリストにある所与のロードバランサノード１１０の２つの最近傍のものは、各々所与のノード１１０のヘルスを周期的または非周期的にチェックすることができる。少なくともいくつかの実施形態では、ノード１１０をヘルスチェックすることは、図２３に例示されるように、ノード１１０のＮＩＣ１１１４に送られたヘルスピンを使用することを含むことができる。少なくともいくつかの実施形態では、第１のノード１１０がヘルスチェックを介して第２のノード１１０が健全であることを決定する場合、第１のノード１１０は、ロードバランサノード１１０に関するローカルのヘルス情報に格納された第２のノード１１０のためのハートビートカウンタを更新する（例えば、インクリメントする）ことができる。第１のノード１１０は、そのローカルのヘルス情報をロードバランサ実現形態の１つ以上の他のロードバランサノード１１０に周期的または非周期的に送り、それらは、それら自身のヘルス情報をそれに応じて更新し（例えば、第２のノードのためのハートビートカウンタをインクリメントすることにより）、それらの更新されたローカルのヘルス情報を１つ以上の他のノード１１０に送ることができる。第２のノード１１０に関するハートビート情報は、そのようにロードバランサ実現形態の他のノード１１０に伝搬することができる。第２のノード１１０が健全である限り、第２のノード１１０から到達可能である他のノード１１０の全ては、第２のノード１１０のハートビートカウンタが、このように一貫した基準で例えば１秒に１回または１０秒毎に一回インクリメントされていることを確認する必要がある。第２のノード１１０が、そのヘルスをチェックするノード（複数可）１１０によって、不健全であることが検出される場合、ノード１１０のハートビートは、ヘルスチェックするノード１１０によって送られることがなく、ある時間閾値の後に、ロードバランサ実現形態１１０の他のノード１１０は、そのノード１１０が不健全であるまたはダウンしているとみなす。

少なくともいくつかの実施形態では、ロードバランサノード１１０は、それ自身の内部状態の１つ以上の態様をチェックすることができ、ノード１１０が、それがある理由で不健全であることを検出する場合、ノード１１０は、そのヘルスをチェックする他のノード１１０からのヘルスピンに応答することを停止することができる。したがって、不健全なノード１１０のヘルスをチェックするノード１１０は、ノード１１０を不健全なものとしてみなすことができ、ノード１１０に代わってハートビートのインクリメントを伝搬しなくてもよい。

ヘルスチェックプロトコルの詳細
少なくともいくつかの実施形態では、ヘルスチェックプロトコルは、ハートビートカウンタ技術及びゴシッププロトコル技術を活用することができる。ヘルスチェックプロトコルは、２つの主要部分、ヘルスチェック及びゴシップ／障害検出を有するとみなすことができる。

ヘルスチェック−ロードバランサ実現形態の全てのロードバランサノード１１０は、実現形態の１つ以上の他のノード１１０を周期的または非周期的にヘルスチェックすることができる。１つ以上の他のノードが決定される方法は後半で説明される。ヘルスチェックのコアとなるアイデアは、ノード１１０が別のノード１１０をヘルスチェックし、他のノード１１０が健全であることを決定する場合、チェックしたノード１１０は、他のノード１１０のハートビートカウンタをインクリメントし、伝搬することによって、他のノード１１０が健全であることアサートする。言い換えれば、ノード１１０は、それ自身のヘルスを他のノードにアサートせず、その代りに、１つ以上の他のノード１１０がロードバランサ実現形態の各々のノード１１０のヘルスをチェックし、アサートする。

ゴシップ／障害検出−少なくともいくつかの実施形態では、ヘルスチェックプロトコルは、ゴシッププロトコルを活用し、ロードバランサノード１１０のヘルス情報をロードバランサ実現形態のメンバーのロードバランサノード１１０間に伝搬することができる。ゴシッププロトコルは、急速に収束し、分散型ロードバランシングシステムの目的のために十分である最終的な一貫性の保証を提供する。少なくともいくつかの実施形態では、ゴシッププロトコルを使用し、各々のロードバランサノード１１０は、ロードバランサ実現形態の各々の他のノード１１０のためのハートビートカウンタを、例えばハートビートリストに維持する。各々のロードバランサノード１１０は、上述のように、少なくとも１つの他のロードバランサノード１１０のヘルスチェックを周期的または非周期的に行い、チェックされたノード１１０が健全であることを、ヘルスチェックを介して決定すると、ノード１１０のためのハートビートカウンタをインクリメントする。少なくともいくつかの実施形態では、各々のロードバランサノード１１０は、それがその現在のハートビートリストを送るロードバランサ実現形態の少なくとも１つの他のノード１１０を周期的または非周期的に無作為に選択する。ハートビートリストを別のノード１１０から受け取ると、ロードバランサノード１１０は、２つのリスト（受け取ったリスト及びそれ自身のリスト）内の各々ノード１１０のための最大ハートビートカウンタを決定し、それ自身のハートビートリスト内の決定された最大ハートビートカウンタを使用することにより、受け取ったリスト内のハートビート情報をそれ自身のハートビートリストと併合する。今度は、このハートビートリストは別の無作為に選択されたノード１１０に送られ、それは、それに応じてそれ自身のハートビートリストを更新し、以降も同様である。この技術を使用すると、各々の健全なノード１１０に関するハートビート情報は、最終的に（例えば、数秒以内に）ロードバランサ実現形態の他のロードバランサノード１１０の全てに伝搬される。ハートビートカウンタが所与のロードバランサノード１１０について増え続ける限り、それは、他のノード１１０によって、健全であるとみなされる。ロードバランサノード１１０のハートビートカウンタが、ヘルスチェック及びゴシップ方法によって指定された期間にわたってインクリメントされない場合に、他のロードバランサノード１１０は、不健全であるとみなされているロードバランサノード１１０に収束することができる。

ロードバランサノードのヘルスチェック
以下で、少なくともいくつかの実施形態に従って、別のロードバランサノード１１０によって行うことができるロードバランサノード１１０をヘルスチェックするための方法を説明する。図２３を参照すると、少なくともいくつかの実施形態では、ロードバランサノード１１０は、以下の条件のうちの１つ以上がノード１１０について決定される場合、健全であるとみなすことができる、
・ノード１１０のプロセッサスレッド（例えば、コアパケット処理コード１１０８のスレッド）は、準備完了状態（内部）にある。
・ノード１１０は、エッジルータ１０４のＩＰアドレス及び／またはＭＡＣアドレスを既知である（内部）。
・ノード１１０のスレッド及び／またはプロトコルハンドラの全ては、準備完了状態にある（内部）。
・ノース側（エッジルータ１０４／ボーダーネットワーク）からの、及びサウス側（サーバ１３０／実稼働ネットワーク）からの着信及び発信リンクは、アクティブである（外部）。
・ノード１１０は、ロードバランサ実現形態で使用されるネットワークインターフェース制御装置（ＮＩＣ）を介してパケットを受け取り、急送することができる。例えば、図２３に示されるような例となるロードバランサノード１１０実施形態では、ノード１１０は、パケットをノース側ＮＩＣ１１１４Ａ及びサウス側ＮＩＣ１１１４Ｂを介して首尾よく受け取り、急送する必要がある。

これらのヘルス条件のうちの１つ以上が所与のノード１１０について保持されない場合、ノード１１０は、健全でないとみなすことができる。いくつかの実施形態では、ノード１１０は、上記の条件の全てがノード１１０について保持される場合にのみ、健全であるとみなされることに留意されたい。

少なくともいくつかの実施形態では、上記のヘルス条件に加えて、例えば制御プレーン通信のために使用することができる各々のロードバランサノード１１０の図２３でＮＩＣ１１１４Ｃとして示される第３のＮＩＣもまた、パケットをＮＩＣへ送ること及びパケットをそこから受け取ることによって、ヘルスチェックするノード１１０によってチェックすることができ、第３のＮＩＣのチェックが不合格になる場合、チェックされているノード１１０は不健全であるとみなすことができる。

図１３は、少なくともいくつかの実施形態に従って、ロードバランサノードを別のロードバランサノードからヘルスチェックするための例となる方法を例示する。この実施例では、ロードバランサノード１１０Ａは、ロードバランサノード１１０Ｂをヘルスチェックする。各々のノード１１０Ａ及び１１０Ｂは、ノース側ＮＩＣ（図２３のＮＩＣ１１１４Ａ）及びサウス側ＮＩＣ（図２３のＮＩＣ１１１４Ｂ）を有する。１では、ノード１１０Ａは、パケット（例えば、ピンパケット）をそのノース側ＮＩＣからノード１１０Ｂのノース側ＮＩＣにエッジルータ１０４を介して送る。ノード１１０Ｂは、パケットをそのノース側ＮＩＣで受け取り、上記のリストに示された条件が満たされれば、２で、応答をそのノース側ＮＩＣからノード１１０Ａのノース側ＮＩＣにファブリック１２０を介して送る。そのノース側ＮＩＣで応答を受け取り後、３で、ノード１１０Ａは、パケット（例えば、ピンパケット）をそのサウス側ＮＩＣからノード１１０Ｂのサウス側ＮＩＣにファブリック１２０を介して送る。ノード１１０Ｂは、パケットをそのサウス側ＮＩＣで受け取り、上記のリストに示された条件が満たされれば、４で、応答をそのサウス側ＮＩＣからノード１１０Ａのサウス側ＮＩＣにエッジルータ１０４を介して送る。応答をそのサウス側ＮＩＣで受け取ると、ノード１１０Ａは、ノード１１０Ｂを健全であるとみなし、ノード１１０Ｂのローカルのハートビートカウンタをインクリメントし、それは、次に、前述のようにゴシッププロトコルに従って、他のノード１１０に伝搬することができる。

上記の代替として、いくつかの実施形態では、ロードバランサノード１１０Ｂは、そのサウス側ＮＩＣを介して、そのノース側ＮＩＣで受け取った第１のピンメッセージに対して、ノード１１０Ａのサウス側ＮＩＣに応答し、そのノース側ＮＩＣを介してそのサウス側ＮＩＣで受け取った第２のピンメッセージに対して、ノード１１０Ａのノース側ＮＩＣに応答することができる。

さらに、いくつかの実施形態では、ノード１１０Ａはまた、ピンをそれ自身の第３のＮＩＣからノード１１０Ｂの第３のＮＩＣに送り、ノード１１０Ｂが健全である場合に、ピンメッセージに対する応答をその第３のＮＩＣでノード１１０Ｂの第３のＮＩＣから受け取ることにより、制御プレーン通信のために使用されているノード１１０Ｂの第３のＮＩＣ（図２３でＮＩＣ１１１４Ｃとして示される）をヘルスチェックすることができる。ピンメッセージ及び応答は、１つ以上の制御プレーンデバイス（複数可）１７０、例えばネットワークスイッチを通過することができる。

上述のヘルスチェック機構は、全ての方向（ノース、サウス、及び制御プレーンを介する）のノード１１０Ｂの着信及び発信リンク並びにデータパスの全て、並びにノード１１０ＢのＮＩＣの全てを用い、更にクライアントパケットと同じように、ピンパケットが内部のキューを通過するときにノード１１０Ｂの内部のヘルス及びノード１１０Ｂの急送を検証する。

ロードバランサノードへのヘルスチェック担当の割り当て
少なくともいくつかの実施形態では、ロードバランサ実現形態の全てのロードバランサノード１１０は、例えば図１に示されるような構成機能を介して及び／または構成サービス１２２の構成要素を介して、ロードバランサ実現形態の他のロードバランサノード１１０の全てのリスト（例えば、ソート済みリスト）へのアクセスを有する。少なくともいくつかの実施形態では、各々のロードバランサノード１１０は、各々のヘルスチェック間隔でヘルスチェックし、健全であると決定されるとハートビートカウンタをインクリメントするリスト上の１つ以上の他のノード１１０を無作為に選択することができる。リストは、ヘルスチェック機構を介して現在健全または不健全とみなされていてもロードバランサ実現形態の全てのロードバランサノード１１０を含み、現在不健全であるノード１１０は、健全であるノード１１０と同様に、リストから無作為に選択され、ヘルスチェックされることに留意されたい。したがって、現在不健全であるノード１１０は、ノード１１０をヘルスチェックする１つ以上のノード１１０によって健全であると決定されることがあり、そのハートビートカウンタは、インクリメントされ、他のノード１１０に伝搬することができ、不健全であるノード１１０は、したがって、健全な状態に戻ることができる。

あるいは、いくつかの実施形態では、各々のロードバランサノード１１０は、リスト内の１つ以上の他のノード１１０をヘルスチェックし、健全であることが決定される場合、それらのハートビートカウンタをインクリメントすることを担当することができる。例えば、いくつかの実施形態では、各々のノード１１０は、２つの他のノード、例えばリスト内のその「左の」（または前の）及び「右の」（または次の）最近傍のノード１１０を担当することができる。リストは、円とみなすことができ、リストの「終わり」にあるノード１１０は、リストの「始め」にあるノード１１０をヘルスチェックすることを担当することができ、またその逆も同様である。いくつかの実施形態では、２つの他のノード１１０は、それ以外の方法では、例えばリスト上で２つの次に最近傍のものとして選択することができる。いくつかの実施形態では、各々のノード１１０は、リスト上の２つ以上の他のノード１１０、例えば３つまたは４つの他のノード１１０をヘルスチェックすることを担当することができる。少なくともいくつかの実施形態では、ノード１１０によってチェックされている近傍のノード１１０が不健全であると決定される場合に、ノード１１０は、不健全である近傍のノード１１０がチェックを担当していたリスト上の少なくとも１つのノードをヘルスチェックすることを担当することができる。少なくともいくつかの実施形態では、その近傍のノード１１０（例えば、「左」及び「右」の近傍のノード）をヘルスチェックすることに加えて、各々のロードバランサノード１１０はまた、リング内のノード１１０を周期的または非周期的に無作為に選択し、無作為に選択したノード１１０のヘルスチェックを行い、健全である場合、無作為のノード１１０のハートビートをインクリメントし、かつ伝搬させることができる。少なくともいくつかの実施形態では、順序付けリスト内の全ての他のノード１１０は、他のノード１１０が以前に健全であるとみなされたか否かに関わらずに、無作為の選択及びヘルスチェックの対象とみなされる。

少なくともいくつかの実施形態では、各々のノード１１０は、１つ以上の無作為に選択されたノード１１０の、またはあるいは、その近傍のノード１１０及び無作為に選択されたノードのヘルスチェックを、ヘルスチェック間隔と呼ぶことができる一定の間隔で、行う。例えば、いくつかの実施形態では、ハートビート間隔は１００ミリ秒であってもよいが、より短いまたはより長い間隔を使用することもできる。さらに、少なくともいくつかの実施形態では、各々のノード１１０は、その現在のハートビートリストを少なくとも１つの無作為に選択されたノード１１０に、ゴシップ間隔と呼ぶことができる一定の間隔で、送るまたは「ゴシップ」する。いくつかの実施形態では、ヘルスチェック間隔及びゴシップ間隔は同じであってもよいが、必ずしも同じではない。

図１４は、少なくともいくつかの実施形態に従って、１つ以上の他のロードバランサノードをヘルスチェックするロードバランサノードをグラフィカルに例示する。この実施例では、ロードバランサ実現形態に８つのロードバランサノード１１０Ａ〜１１０Ｈが存在する。点線の円は、実現形態の全てのノード１１０の順序付けリストを表す。いくつかの実施形態では、各々のノード１１０は、各々の間隔でヘルスチェックするためにリスト上の１つ以上の他のノード１１０を無作為に選択することができる。代替として、いくつかの実施形態では、各々のロードバランサノード１１０は、順序付けリスト上の１つ以上の特定のノード１１０をチェックすることを担当することができ、例えば、ノード１１０Ａは、図１４に示されるように、順序付けリストに従って、その２つの最近傍のノード１１０Ｂ及び１１０Ｈをヘルスチェックすることを担当することができる。更に、ロードバランサノードはまた、別のノード１１０を各々のヘルスチェック間隔で順序付けリストから無作為に選択することができる。この実施例で示されるように、ノード１１０Ａはまた、ヘルスチェックするためにノード１１０Ｆを無作為に選択した。ゴシップ間隔で、ノード１１０Ａは、ある他の健全であるノード１１０、例えばノード１１０Ｄを無作為に選択し、その現在のハートビートリストを選択された他のノード１１０に、例えばＵＤＰメッセージで送る。ノード１１０は、ハートビートリストを別のノード１１０から受け取ると、それに応じてそれ自身のハートビートリストを更新し、ハートビートリストを１つ以上の無作為に選択されたノード１１０に、次のゴシップ間隔で伝搬することができる。

サーバノードのヘルスチェック
上述のようにロードバランサノード１１０をヘルスチェックすることに加えて、ヘルスチェックプロトコルの実施形態は、ノード１３０のロードバランサモジュール１３２及びサーバ１３４を含むサーバノード１３０のヘルスチェックを行うことができる。少なくともいくつかの実施形態では、サーバノード１３０は、以下の条件の１つまたは両方がノード１３０について決定される場合、健全であるとみなすことができる、
・ロードバランサモジュール１３２は健全である。
・サーバノード１３０は、ヘルスピン（例えば、Ｌ７ヘルスピン）に首尾よく応答する。

図１５は、少なくともいくつかの実施形態に従って、サーバノードをヘルスチェックするロードバランサノードを例示する。少なくともいくつかの実施形態では、ロードバランサ実現形態の全てのロードバランサノード１１０は、ロードバランサ実現形態の他のロードバランサノード１１０の全てのリスト、並びにロードバランサ実現形態の全てのサーバノード１３０のリストにアクセスすることができる。リスト（複数可）は、例えば図１に示されるように構成機能を介して及び／または構成サービス１２２構成要素を介して、取得し、更新することができる。少なくともいくつかの実施形態では、サーバノード１３０は、健全なロードバランサノード１１０に対してコンシステントハッシュ化され、図１５に示されるようにコンシステントハッシュリングを形成することができる。少なくともいくつかの実施形態では、リング内の各々のサーバノード１３０は、リング内の２つの健全なロードバランサノード１１０によってヘルスチェックされる。例えば、図１５では、サーバノード１３０Ａは、ロードバランサノード１１０Ａ及び１１０Ｃによってヘルスチェックされる。これらの２つのノード１１０は、コンシステントハッシュリング内のサーバノード１３０のための第１（ノード１１０Ａ）及び第２（ノード１１０Ｂ）ヘルスチェックノード１１０と呼ぶことができる。所与の健全なロードバランサノード１１０は、１つよりも多くのサーバノード１３０をヘルスチェックすることができることに留意されたい。例えば、図１５では、ロードバランサノード１１０Ａはまた、サーバノード１３０Ｂ及び１３０Ｃをヘルスチェックする。更に、所与のノードバランサノード１１０は、１つ以上のサーバノード１３０のための第１のヘルスチェックノード１１０であり、かつ１つ以上の他のサーバノード１３０のための第２のヘルスチェックノード１１０であることができる。例えば、図１５では、ロードバランサノード１１０Ａは、サーバノード１３０Ａ及び１３０Ｂのための第１のヘルスチェッカーノードであり、かつサーバノード１３０Ｃ及び１３０Ｄのための第２のヘルスチェッカーノードである。

少なくともいくつかの実施形態では、ロードバランサノード１１０に障害が発生すると、コンシステントハッシュリングのメンバーシップが変更されて、まだ健全でありしたがってコンシステントハッシュリングにまだ存在するロードバランサノード１１０の１つ以上の他のものが、障害が発生したノード１１０によって以前にヘルスチェックされたサーバノード１３０をヘルスチェックすることを担当することができる。

少なくともいくつかの実施形態では、各々の健全なノード１１０は、サーバチェック間隔と呼ぶことができる一定の間隔で、その割り付けられたサーバノード１３０のヘルスチェックを行う。少なくともいくつかの実施形態では、サーバチェック間隔は、前述のゴシップ間隔よりも大きいまたは等しくてよい。

少なくともいくつかの実施形態では、サーバノード１３０のヘルスチェックを行うために、健全なロードバランサノード１１０（例えば、図１５のノード１１０Ａ）は、サーバノード１３０（例えば、図１５のサーバノード１３０Ａ）へのヘルスピンメッセージ（例えば、Ｌ７ ＨＴＴＰヘルスピンメッセージ）を開始する。健全である場合、サーバノード１３０は、ピン応答をロードバランサノード１１０に送り返す。少なくともいくつかの実施形態では、ピンメッセージは、サーバノード１３０のロードバランサモジュール１３２によって受け取られ、処理され、その結果成功すると、ヘルスチェックピンは、サーバノード１３０のモジュール１３２が健全であることを確立する。ピンに対する応答を受け取ると、ロードバランサノード１１０は、サーバノード１３０を健全であるとみなし、サーバノード１３０のためのハートビートカウンタをインクリメントする。

少なくともいくつかの実施形態では、所与に健全なロードバランサノード１１０によってヘルスチェックされた全てのサーバノード１３０のためのハートビートカウンタは、例えば各々のノード１１０がそのハートビートリストを少なくとも１つの他の無作為に選択されたノード１１０に一定の間隔（ゴシップ間隔）で送るロードバランサノード１１０のハートビートカウンタについて前述されたゴシップ技術に従って、他のロードバランサノード１１０に伝搬させることができ、受け取るノード１１０は、２つのリスト内の最大値に従ってそれ自身のハートビートリストを更新する。

障害検出及びゴシップ
少なくともいくつかの実施形態では、上述のロードバランサノード１１０のヘルスチェック及びサーバノード１３０のヘルスチェックを介して取得された情報は、ロードバランサ実現形態の全てのノード１１０に伝搬されることが必要となることがあり、その結果全てのロードバランサノード１１０は、ロードバランサ実現形態のコンシステントビューを維持することができる。上述のように、少なくともいくつかの実施形態では、ロードバランサノード１１０は、ゴシッププロトコルに従って互いに通信し、ヘルス情報を交換し、かつ伝搬し、またロードバランサノード１１０及びサーバノード１３０の障害を検出することができる。

少なくともいくつかの実施形態では、一定の間隔（ゴシップ間隔と呼ぶ）で、各々ロードバランサノード１１０は、別のロードバランサノード１１０を無作為に選択し、健全なロードバランサノード１１０及びサーバノード１３０のそのビューを、ロードバランサノード１１０及びサーバノード１３０のためのハートビートカウンタと共に、他のノード１１０に送る。ロードバランサノードまたはサーバノード１３０が健全である限り、ノードは、そのヘルスチェックを渡し、そのハートビートカウンタは増加し続ける。ノードのためのハートビートカウンタが指定された間隔（失敗時間間隔と呼ぶことができる）にわたって変わらない場合は、ノードは、ロードバランサノード１１０によって障害が発生したと疑われる。障害が発生しているとノードが一旦疑われると、ロードバランサノード１１０は、ノードが不健全であると決定する前に、指定された間隔（不健全時間間隔と呼ぶことができる）にわたって待機することができる。この不健全時間間隔は、全てのロードバランサノード１１０がノードに障害が発生したことを学習するまで、ロードバランサノード１１０が待機することを可能にする。

図１６は、少なくともいくつかの実施形態に従って、ロードバランサノード１１０によって維持することができる別のノード（ロードバランサノード１１０またはサーバノード１３０のいずれか）のヘルスの状態、またはビューをグラフィカルに例示する。３００に示されるように、対象となるノードが健全であるというビューでロードバランサノード１１０が始まることを想定する。これは、ノードのためのハートビートカウンタがインクリメントしていたことを示す。しかしながら、３０２に示されるように、ノードのハートビートカウンタが指定された間隔（失敗時間間隔）にわたって増加しない場合は、３０４に示されるように、ロードバランサノード１１０は、ノードに障害が発生したことを疑う。３０６に示されるように、ノードのハートビートカウンタが指定された間隔（不健全時間間隔）にわたって増加しない場合は、ロードバランサノード１１０は、３０８に示されるように、ノードを不健全であるとみなす。しかしながら、３１０に示されるように、ノードのためのハートビートカウンタが、不健全時間間隔が満了となる前に、インクリメントする場合、ロードバランサノード１１０は、３００で、再びノードを健全であるとみなす。同様に、３１２に示されるように、不健全なノードのためのハートビートのインクリメントを受け取ると、３００で、そのノードを健全であるとみなすことができる。

ノードが不健全であること決定することは、本明細書の他の箇所で説明されるが、不健全なノードがロードバランサノード１１０か、またはサーバノード１３０かに依存して、更に不健全なノードとのロードバランサノード１１０の関係に依存して、ロードバランサノード（複数可）１１０による異なる動作を含むことができる。

ロードバランサノードのデータ
少なくともいくつかの実施形態では、各々のロードバランサノード１１０は、ロードバランサ実現形態の状態に関するデータを維持することができる。少なくともいくつかの実施形態では、このデータは、限定されるものではないが、健全なロードバランサノードのリスト、疑わしいロードバランサノードのリスト、及びハートビートのリストを含み、各々ロードバランサノード１１０の１つ以上のデータ構造に維持することができる。図１７は、健全なロードバランサノードのリスト３２０、疑わしいロードバランサノードのリスト３２２、不健全なロードバランサノードのリスト３２４、及びロードバランサノードハートビートのリスト３２６を維持する例となるロードバランサノード１１０を例示する。

少なくともいくつかの実施形態では、各々のロードバランサノード１１０は、健全なロードバランサノードのリスト３２０を維持することができ、それは、例えばどのノード１１０が健全であるか、したがってゴシッププロトコルに参加しているかを決定するために使用することができる健全なロードバランサノード１１０のリストである。リスト３２０にあるノード１１０のみが、ゴシッププロトコルを介するロードバランサ情報の伝搬に関与し、リスト３２０にあるノード１１０のみが、コンシステントハッシュリングに存在するとみなされ、このリストにあるノード１１０のみが、サーバノード１３０をヘルスチェックする。ノード１１０は、そのハートビート情報が送られる別のノード１１０をこのリスト３２０から無作為に選択することができる。更に、ハートビートカウンタは、健全なロードバランサノードのリスト３２０に現在あるノード１１０のためにのみ、交換される。少なくともいくつかの実施形態では、ロードバランサノードＮは、ノードＮがロードバランサノード１１０によるヘルスチェックに合格する場合、またはロードバランサノード１１０がノードＮに関するゴシップメッセージをリスト３２０にある他のロードバランサノード１１０から受け取る場合、別のロードバランサノード１１０の健全なロードバランサノードのリスト３２０に追加することができる。

少なくともいくつかの実施形態では、各々のロードバランサノード１１０は、疑わしいロードバランサノードのリスト３２２を維持することができ、それは、ハートビートカウンタ（ハートビートリスト３２６を参照）が指定された間隔（失敗時間間隔と呼ばれる）にわたって増加しなかったロードバランサノードのリストである。ロードバランサノードＥがロードバランサノード１１０の疑わしいロードバランサノードのリスト３２２にある場合は、ロードバランサノード１１０は、ノードＥについてゴシップしない。健全なもののリスト３２０にある他のロードバランサノード１１０が、ノード１１０のハートビートリスト３２６にあるノードＥのためのカウンタより高いハートビートカウンタで、ノードＥについてロードバランサノード１１０にゴシップする場合は、ノードＥは、疑わしいもののリスト３２２から健全なもののリスト３２０に移される。ノードＥが、ロードバランサノード１１０の疑わしいもののリスト３２２に指定された間隔（不健全時間間隔と呼ばれる）にわたって留まる場合、ノードＥは、ロードバランサノード１１０によって不健全であるとみなされ、不健全なノードのリスト３２４に移される。不健全なノードのリスト３２４にあるノード１１０（この実施例では、ノードＧ）は、ノードＧがノード１１０によるヘルスチェックに合格すると、またはノードＧのための更新されたハートビートカウンタを別のノード１１０から受け取ると、ロードバランサノード１１０の健全なノードのリスト３２０に移すことができる。

少なくともいくつかの実施形態では、各々のロードバランサノード１１０は、全ての既知のロードバランサノード１１０のためのハートビートリスト３２６を維持することができる。各々のノード、１１０について、このリスト３２６は、ハートビートカウンタ及びハートビートカウンタが最後に変更された時を示すタイムスタンプを含むことができる。

少なくともいくつかの実施形態では、各々のロードバランサノード１１０はまた、図１７に示されないが、全ての既知のサーバノードのためのハートビートリストを維持することができる。このリストは、ロードバランサノードのハートビートリスト３２６と同様であってもよい。いくつかの実施形態では、二つのリストは組み合わせることができる。少なくともいくつかの実施形態では、サーバノード１３０についてのハートビート情報は、例えばゴシッププロトコルに従って、ロードバランサノード１１０についてのハートビート情報と共に、またはそれに加えて、ロードバランサノード１１０間に伝搬することができる。

図１７は４つの分離したリストを示しているが、リストの２つ以上は、単一のリストに組み合わせることができることに留意されたい。例えば、いくつかの実施形態では、全てのノード１１０の単一のリストは、各々のロードバランサノード１１０に維持することができ、ビットフラグまたは他のデータ構造を使用し、各々のノードが現在健全であるか、疑わしいか、または不健全であるかどうかを示すことができる。

サーバノードのデータ
少なくともいくつかの実施形態では、サーバノード１３０及びノード１３０のローカルのロードバランサモジュール１３２は、ロードバランサノード１１０とのゴシッププロトコルに参加しない。ロードバランサノード１１０は、ロードバランサノードのヘルスチェック方法によって取得された他のロードバランサノード１１０に関するハートビート情報、及びサーバノードのヘルスチェック方法によって取得されたサーバノード１３０に関するハートビート情報を、それら自身の間のみにゴシップする（具体的には、各々のロードバランサノード１１０は、その健全なロードバランサノードのリスト３２０に現在あるノードのみにゴシップする）。

しかしながら、各々のサーバノード１３０／ロードバランサモジュール１３２は、ロードバランサ実現形態の健全なロードバランサノード１１０に関する情報を必要とすることができ、その結果サーバノード１３０は、サーバノード１３０が発信クライアントトラフィックを転送することができるロードバランサノード１１０（具体的には、出口ノード）を決定し、かつどのロードバランサノードに接続公開情報を送るべきかを決定することができる。少なくともいくつかの実施形態では、この情報をサーバノード１３０に提供するために、ロードバランサノード１１０は、現在健全であるロードバランサノード１１０（例えば、図１７の健全なロードバランサノードのリスト３２０）を識別する情報でサーバノード１３０を周期的または非周期的に更新することができる。少なくともいくつかの実施形態では、所与のサーバノード１３０（図１５を参照）ヘルスチェックすることを担当するロードバランサノード１１０は、現在健全であるロードバランサノードを識別する情報をサーバ１３０に提供することを担当する。例えば、図１５を参照すると、ロードバランサノード１１０Ａは、その健全なロードバランサノードのリスト３２０をサーバノード１３０Ａ、１３０Ｂ、１３０Ｃ、及び１３０Ｄに送ることができ、ロードバランサノード１１０Ｂは、その健全なロードバランサノードのリスト３２０をサーバノード１３０Ｃ、１３０Ｄ、及び１３０Ｅに送ることができ、以降も同様である。

ロードバランサノードの障害の取り扱い
図１８Ａ及び１８Ｂは、少なくともいくつかの実施形態に従って、ロードバランサノードの障害の取り扱いを例示する。図１８Ａは、例となるロードバランサ実現形態を示す。ロードバランサ実現形態には、現在４つのロードバランサノード１１０Ａ〜１１０Ｄが存在する。エッジルータ１０４は、クライアント（図示せず）からの着信パケットをロードバランサノード１１０にルーティングする。少なくともいくつかの実施形態では、エッジルータ１０４は、層４のフロー毎ハッシュ化マルチパスルーティング技術、例えば等価コストマルチパス（ＥＣＭＰ）ルーティング技術に従って、ルーティング決定を行うことができる。少なくともいくつかの実施形態では、エッジルータ１０４は、ロードバランサノード１１０のアドバタイズメント、例えばロードバランサノード１１０によって開始されたボーダーゲートウェイプロトコル（ＢＧＰ）技術セッションを介するアドバタイズメント、を介してクライアントトラフィックを受け取るためにロードバランサ実現形態で現在利用可能であるロードバランサノード１１０に関して学習する。しかしながら、少なくともいくつかの実施形態では、ロードバランサノード１１０がそれ自身をエッジルータ１０４にＢＧＰセッションを介して広告する代わりに、ロードバランサ実現形態の少なくとも１つの他のノード１１０が、ノード１１０をエッジルータ１０４にＢＧＰを介して広告することを担当する。例えば、図１８Ａに示されるようないくつかの実施形態では、所与のノード１１０の左及び右の近傍のノード１１０が所与のノード１１０をエッジルータ１０４に広告する。例えば、ロードバランサノード１１０Ａは、ノード１１０Ｂ及び１１０Ｄを広告し、ロードバランサノード１１０Ｂは、ノード１１０Ａ及び１１０Ｃを広告し、ロードバランサノード１１０Ｃは、ノード１１０Ｂ及び１１０Ｄを広告する。

図１８Ａの実施例に示されるように、各々のロードバランサノード１１０はまた、１つ以上の他のロードバランサノード１１０、例えば１つ以上の無作為に選択されたノード１１０、ロードバランサノードの順序付けリストによって決定されるような１つ以上の近傍のノード１１０、または１つ以上の近傍のノード及び１つ以上の無作為に選択されたノード、を周期的にヘルスチェックする。更に、各々のロードバランサノード１１０は、少なくとも１つのサーバノード１３０を周期的にヘルスチェックすることができ、更に健全なロードバランサノード１１０のそのリストを、それがヘルスチェックするサーバノード（複数可）に送ることができる。ロードバランサノード１１０及びサーバノード１３０に関するヘルス情報は、例えばゴシッププロトコルに従ってノード１１０間に伝搬することができる。

図１８Ｂは、図１８Ａの例となるロードバランサ実現形態の単一のロードバランサノード１１０の障害の取り扱いを例示する。この例では、ロードバランサノード１１０Ｂが、ある理由で障害を発生している。例えば、ノード１１０Ａ及び１１０Ｃは、ノード１１０Ｂをヘルスチェックし、その両方が、ノード１１０Ｂがそのヘルスチェックに不合格であることを検出することができる。したがって、ノード１１０Ａ及び１１０Ｃは、ノード１１０Ｂのためのハートビートカウンタをインクリメントしない。ノード１１０Ａ及び１１０Ｂの両方からのハートビート情報は、ゴシッププロトコルに従って、他の健全なロードバランサノード１１０（この実施例では、唯一の他のロードバランサノードはノード１１０Ｄである）に伝搬される。健全なロードバランサノード１１０（この実施例では、ノード１１０Ａ、１１０Ｃ、及び１１０Ｄ）の全てがノード１１０Ｂの障害に収束するとすぐに、限定されるものではないが、以下のイベントのうちの１つ以上が起こることがある。これらのイベントは、この順序で必ずしも起こらないことに留意されたい。
・ノード１１０Ａ及び１１０Ｃは、ノード１１０Ｂをエッジルータ１０４に広告することを停止する。少なくともいくつかの実施形態では、これは、ノード１１０がノード１１０Ｂを広告するためにエッジルータ１０４と確立したＢＧＰセッションを終了させることを含む。各々のノード１１０は、それが広告する各々の他のノード１１０ための別々のＢＧＰセッションをエッジルータ１０４と確立しているので、ノード１１０ＢのためのＢＧＰセッションを終了させることは、広告される他のノード１１０に影響しないことに留意されたい。少なくともいくつかの実施形態では、ノード１１０は、ＢＧＰセッションのためのＴＣＰクローズまたは同様のメッセージをエッジルータ１０４に送ることにより、エッジルータ１０４とのＢＧＰセッションを終了する。
・ノード１１０Ｂが、もはやノードのいずれによっても広告されていないことの検出に応じて、エッジルータ１０４は、クライアントデータパケットをノード１１０Ｂにルーティングすることを停止する。エッジルータ１０４はまた、マルチパス（例えば、ＥＣＭＰ）ハッシングを調整し、クライアントからのパケットフローを残りの健全なロードバランサノード１１０へ、具体的にはノード１１０の入口サーバ１１２に再分配する。入口サーバ１１２がクライアント−＞サーバのマッピングを有していない入口サーバ１１２にルーティングされる任意のパケットフローの場合、マッピングは、クライアント−＞サーバの接続のためのフロートラッカーノードから取得することができ、またはあるいは、新規のクライアント−＞サーバの接続が、図１０Ａ〜１０Ｇに例示されたような技術に従って確立することができる。
・ノード１１０Ａ及び１１０Ｃは、それぞれエッジルータ１０４へのＢＧＰセッションを開き、互いに広告することができる。ノード１１０Ａ及び１１０Ｃの両方が、ロードバランサノード１１０Ｄ並びにノード１１０Ｂによって、エッジルータ１０４に広告されるので、ノード１１０Ｂは、それに障害が発生したときに、ノード１１０Ａ及び１１０Ｂをエッジルータ１０４に広告することを停止することがあるという事実によって、エッジルータ１０４がパケットをそれらの２つのノード１１０にルーティングすることを停止しないことに留意されたい。
・少なくともいくつかの実施形態では、ノード１１０Ａ及び１１０Ｃは、それらが現時点で近傍のノード１１０になるので、互いをヘルスチェックすることを担当することができる。ノード１１０Ｂは、たとえ不健全であるとみなされても、他のノード１１０のうちの１つ以上によって依然として無作為にヘルスチェックすることができることに留意されたい。
・残りの健全なロードバランサノード１１０のうちの１つ以上は、以前にノード１１０Ｂによってフロー追跡された接続をフロー追跡することを担当することができる。例えば、ノード１１０Ｃ及び／またはノード１１０Ｄは、図１１Ｃ及び１１Ｄに示されるように、ノード１１０Ｂが１次または２次フロートラッカーであった１つ以上の接続のための１次または２次フロートラッカーを引き継ぐことができる。
・残りの健全なロードバランサノード１１０のうちの１つ以上は、以前にノード１１０Ｂによってヘルスチェックされたサーバノード１３０をヘルスチェックすることを担当することができる。サーバノード１３０は、残りのロードバランサノード１１０によって、健全なロードバランサノードのリスト（現時点で、ノード１１０Ｂを含まない）で更新される。例えば、図１８Ｂでは、ロードバランサノード１１０Ａは、サーバノード１３０Ｃのヘルスチェック及び更新を開始し、ロードバランサノード１１０Ｃは、サーバノード１３０Ｂのヘルスチェック及び更新を開始する。
・エッジルータ１０４では、障害が発生したノード１１０ＢからのＢＧＰセッションが最終的にタイムアウトする。あるいは、エッジルータ１０４は、ノード１１０Ｂに障害が発生したことを認識すると、ＢＧＰセッションを終了することができる。

２つのロードバランサノード１１０に同時にまたはほぼ同時に障害が発生する場合があることも可能である。２つの障害が発生したロードバランサノードが互いに隣接していない場合は、障害は独立しており、図１８Ｂに例示される方法に従って、別々の単一のノード１１０の障害として取り扱うことができる。しかしながら、２つの障害が発生したノードが互いに隣接する場合に（例えば、図１８Ａでは、ノード１１０Ｂ及び１１０Ｃ、すべての健全ロードバランサノード１１０（この実施例では、ノード１１０Ａ及び１１０Ｄ）が障害を検出してそれに収束するとすぐに、限定されるものではないが、以下のイベントのうちの１つ以上が起こることができる。これらのイベントは、必ずしもこの順序で起こらないことに留意されたい。
・ノード１１０Ａは、ノード１１０Ｂのためのエッジルータ１０４へのＢＧＰセッションを終了する。
・ノード１１０Ｄは、ノード１１０Ｃのためのエッジルータ１０４へのＢＧＰセッションを終了する。
・ノード１１０Ａ及び１１０Ｄは、エッジルータ１０４とのＢＧＰセッションを開始し、互いを広告する。
・ノード１１０Ａ及び１１０Ｄは、互いをヘルスチェックすることを始める。ノード１１０Ａ及び１１０Ｄはまた、障害が発生したノード１１０を継続してヘルスチェックすることに留意されたい。
・残りの健全なノード１１０は、健全なロードバランサノードのリストでサーバノード１３０を更新する。
・トラフィックは、エッジルータ１０４からノード１１０Ｂ及び／またはノード１１０Ｃに、これらの２つのノード１１０が継続して互いをエッジルータ１０４に広告することができるので、継続してフローすることができる。しかしながら、これらのＢＧＰセッションは最終的にタイムアウトし、エッジルータ１０４は、相応にフローを残りの広告されたノード１１０に再分配する。
・ノード１１０Ｂ及び１１０Ｃは、それらがノード１１０Ａ及び１１０Ｄを広告するエッジルータ１０４とのそれらのＢＧＰセッションを、ノード１１０Ｂ及び１１０Ｃがそれらはまだ健全であると思う場合、閉じることができる。

接続公開
図１を再び参照すると、少なくともいくつかの実施形態では、ロードバランサ実現形態のロードバランサノード１１０は、サーバ１３０へのクライアントＴＣＰ接続のための状態情報を維持する。この状態情報は、ロードバランサノード１１０がエッジルータ１０４からの着信クライアントトラフィックを、ＴＣＰ接続を担当するサーバノード１３０にルーティングすることを可能にする。サーバノード１３０のロードバランサモジュール１３２は、それらのそれぞれのサーバ１３４へのアクティブなＴＣＰ接続のリストを維持する。接続公開は、サーバノード１３０のロードバランサモジュール１３２がロードバランサノード１１０へのアクティブなクライアントＴＣＰ接続のそれらのリストを公開することができる機構である。少なくともいくつかの実施形態では、接続公開パケットは、接続公開間隔と呼ぶことができる一定の間隔でロードモジュール１３２によって、形成され、ロードバランサノード１１０に公開される。

少なくともいくつかの実施形態では、ロードバランサノード１１０によって維持される接続状態情報は、キャッシュの形態としてみることができ、特定の接続についての状態情報を維持することは、その接続ためのロードバランサノード１１０でリース期間を維持することとしてみることができる。キャッシュエントリが更新されない限り、ロードバランサノード１１０は、データフローを取り扱っているサーバノード１３０にクライアントデータフローをルーティングすることができないことがある。接続公開の機構は、ロードバランサノード１１０のキャッシュ、したがってリース期間を、サーバノード１３０からの現在の接続状態情報で周期的に更新し、それによってクライアント１６０から適切なサーバノード１３０へフローするＴＣＰパケットを維持する。クライアント１６０がサーバ１３４へのＴＣＰ接続を終了すると、その接続に関連するサーバノード１３０のロードバランサモジュール１３２は、アクティブな接続のそのリストから接続をドロップし、したがってもはや接続公開機構を介してＴＣＰ接続を公開しない。したがって、その接続に関連するロードバランサノード１１０（具体的に、接続のための入口サーバ１１２並びに１次及び２次フロートラッカー１１６）のその接続に関する接続状態情報（１つまたは複数のキャッシュエントリ）は、もはや更新されることがなく、接続はロードバランサノード１１０によってドロップされる。少なくともいくつかの実施形態では、接続のためのキャッシュエントリまたはエントリ（複数）は、メモリが他のあるアクティブな接続に必要とされるまで、ロードバランサノード１１０のキャッシュに留まることができる。

したがって、接続公開の機構は、入口サーバ１１２並びに１次及び２次フロートラッカー１１６の接続リース期間を周期的または非周期的に延長し、クライアントトラフィックフローを維持する。更に、接続公開の機構は、少なくともいくつかのロードバランサノード１１０の障害からのリカバリに役立つことができる。クライアント接続に関する状態情報を保持する１つ以上のロードバランサノード１１０に障害が発生するとき、接続公開によって残りのロードバランサノード１１０に提供されるアクティブな接続情報は、いくつの場合では、接続をリカバリするために使用することができる。

接続公開の機構を使用すると、サーバノード１３０は、サーバ１３４とクライアント１６０との間の接続の状態のための信頼できるソースとなる。更に、サーバ１３４への接続を閉じることは、サーバノード１３０のロードバランサモジュール１３２及びロードバランサノード１１０によって受動的に取り扱われる。ハンドシェイクは、サーバノード１３０とロードバランサノード１１０との間に必要とされない。言い換えれば、ロードバランサモジュール１３２は、特定の接続が閉じられたことをノードに能動的に通知するために、メッセージをロードバランサノード１１０に送る必要がない。サーバ１３４が接続を閉じるとき、サーバ１３４は、接続に関するその内部状態をクリアする。ロードバランサモジュール１３２は、サーバ１３４の内部状態を使用し、接続公開パケットを取り込む。接続は、もはやサーバ１３４の内部状態に存在しないので、接続はロードバランサノード１１０に公開されない。したがって、ロードバランサノード１１０の接続のためのリース期間が満了し、ロードバランサノード１１０は、接続を受動的に忘れる。接続のために使用されたロードバランサノード１１０のキャッシュ内のメモリは、その後必要に応じて他の接続のために使用することができる。

いくつかの実施形態では、ロードバランサノード１１０によって維持される接続のためのリース期間は、キャッシュ内に接続のためのタイムスタンプのエントリを含むことができる。接続のリース期間が、接続公開パケットによって更新されると、タイムスタンプを更新することができる。接続がもはやサーバノード１３０のロードバランサモジュール１３２によって公開されていない理由により接続のリース期間が更新されない場合は、タイムスタンプはもはや更新されない。少なくともいくつかの実施形態では、接続のためのエントリが、メモリが必要となるまでキャッシュ内に留まることができるレイジーガベージコレクション方法を使用することができる。例えば、少なくともいくつかの実施形態では、キャッシュエントリのタイムスタンプは、リース期間更新時間閾値と比較することができ、キャッシュエントリのタイムスタンプが閾値よりも古い場合は、エントリは古くなっており、再利用することができる。しかしながら、いくつかの実施形態では、古くなっているエントリは、能動的にガベージコレクションすることができる。

接続公開受信者
少なくともいくつかの実施形態では、各々のクライアントＴＣＰ接続について、接続状態を維持する３つのロードバランサノード１１０、入口サーバ１１２として機能するノード１１０、１次フロートラッカー１１６として機能するノード１１０、及び２次フロートラッカー１１６として機能するノードが存在する。所与のＴＣＰフローのために、１次及び２次フロートラッカー１１６は、例えばロードバランサノード１１０によって、コンシステントハッシュ関数をＴＣＰフローに適用して１次フロートラッカー１１６ノード及びコンシステントハッシュリングのその後継ノードを見つけることにより、決定することができる。ＴＣＰフローのための入口サーバ１１２として機能するロードバランサノード１１０は、エッジルータ１０４の内部マルチパス（例えば、ＥＣＭＰ）ハッシュ関数に基づいてエッジルータ１０４からのそのフローのためのトラフィックを受け取るノード１１０である。ノード１１０の障害または追加が存在する場合、入口サーバ１１２として機能するロードバランサノード１１０は、アクティブなＴＣＰフローの多くに対して変更されることがあり、少なくともいくつかのアクティブなＴＣＰフローのためのフロートラッカーとして機能するロードバランサノード１１０は、変更されることがある（例えば、図１１Ａ〜１１Ｄを参照）。サーバノード１３０のサーバ１３２への全てのＴＣＰフローについて、そのサーバノード１３０のロードバランサモジュール１３２は、それがロードバランサノード１１０からトラフィックを受け取るので、ロードバランサノード１１０のうちのどれが、そのＴＣＰフローのための入口サーバ１１２であるかを示す状態情報を維持する。しかしながら、少なくともいくつかの実施形態では、ロードバランサモジュール１３２は、使用されているコンシステントハッシュ関数を知らないことがあるので、ロードバランサモジュール１３２は、どのロードバランサノード１１０がＴＣＰフローのための１次及び２次フロートラッカーとして機能しているかを知らないことがあり、決定できないことがある。言い換えれば、少なくともいくつかの実施形態では、ロードバランサモジュール１３２は、コンシステントハッシングを行わない。

アクティブな接続情報の公開
図１９Ａ及び１９Ｂは、少なくともいくつかの実施形態に従って、接続公開技術をグラフィカルに例示する。図１９Ａは、アクティブな接続情報をロードバランサノードの公開するロードバランサ（ＬＢ）モジュールを例示する。少なくともいくつかの実施形態では、各々のロードバランサモジュール１３２は、サーバノード１３０上の各々のアクティブなＴＣＰフローに関する情報を収集し、接続公開パケットを形成する。所与のＴＣＰフローに関する情報は、フローのための入口サーバ１１２として機能するロードバランサノード１１０を識別する情報を含む。接続公開パケットの準備が完了すると（例えば、接続公開間隔に達すると）、ロードバランサモジュール１３２は、ロードバランサノード１１０を、例えば前述のようにサーバノード１３０をヘルスチェックするロードバランサノード１１０からサーバノード１３０に周期的に送られる健全なロードバランサノード１１０のリストから無作為に選択する。ロードバランサモジュール１３２は、次に、接続公開パケットを選択されたノード１１０に送る。例えば、図１９Ａでは、ロードバランサモジュール１３２Ａは、１つの接続公開パケットをロードバランサノード１１０Ａに送り、後に別の接続公開パケットをロードバランサノード１１０Ｂに送る。

図２０は、少なくともいくつかの実施形態に従って、各々ロードバランサモジュール１３２によって行うことができる接続公開方法の高レベルのフローチャートである。５００に示されるように、ロードバランサ（ＬＢ）モジュール１３２は、それぞれのサーバノード１３０上の全てのアクティブなＴＣＰフローのための接続公開エントリを作成する。少なくともいくつかの実施形態では、ロードバランサモジュール１３２は、サーバノード１３０のサーバ１３４が取り扱うアクティブなＴＣＰ接続のセットを、例えばサーバノード１３０の／ｐｒｏｃ／ｎｅｔ／ｔｃｐから取り出す。全てのアクティブなＴＣＰ接続について、ロードバランサモジュール１３２は、ＴＣＰフローのための入口サーバ１１２として機能するロードバランサノード１１０を検索し（例えば、アクティブな接続のローカルで維持されたテーブル内で）、接続のためのＴＣＰタプル（例えば、クライアントＩＰアドレス、クライアントポート、サーバ（パブリック）ＩＰアドレス、及びサーバポートからなる４タプル）及び接続のための入口サーバ１１２を示す接続公開エントリを作成する。各々のロードバランサモジュール１３２は、接続のためにパケットを受け取った最後のロードバランサノード１１０を示す各々のアクティブなＴＣＰ接続に関する情報を維持し、この情報は、ロードバランサモジュール１３２によって使用され、各々のアクティブな接続のための入口ノード１１０を識別することができることに留意されたい。

５０２に示されるように、ロードバランサモジュール１３２は、接続公開パケット（各々のアクティブなＴＣＰ接続のための１つのエントリとともに、１つ以上の接続公開エントリを含む）が送られるロードバランサノード１１０を無作為に選択する。少なくともいくつかの実施形態では、ロードバランサモジュール１１０は、ロードバランサモジュール１３２が、接続公開パケットが送られる準備が完了していることを決定すると、無作為に選択することができる。少なくともいくつかの実施形態では、この決定は、接続公開間隔に従って行われる。非限定的な実施例として、接続公開間隔は、１００ミリ秒（ｍｓ）、または１秒であってもよい。少なくともいくつかの実施形態では、ロードバランサモジュール１１０は、以前にロードバランサノード１１０のうちの１つから受け取った健全なロードバランサノード１１０のリストから選択される。５０４では、ロードバランサモジュールは、次に、接続公開パケットを選択されたロードバランサノード１１０に公開する。少なくともいくつかの実施形態では、接続公開パケットは、ステートレスパケット、例えばＵＤＰパケットである。いくつかの実施形態では、接続公開パケットは、パケットを対象となるロードバランサノード１１０に送る前に圧縮することができる。少なくともいくつかの実施形態では、接続公開情報は、２つ以上のパケットで、対象となるロードバランサノード１１０に送ることができる。

要素５０４から要素５００に戻る矢印で示されるように、ロードバランサモジュール１３２は、連続して接続公開パケットを構築し、無作為のノード１１０を選択し、及びパケットを選択されたノードを送ることができる。上述のように、これは、接続公開間隔に従って行うことができ、その結果、ロードバランサノード１１０は、現在のアクティブな接続情報で比較的定期的に更新され、ロードバランサノード１１０上に接続リース期間を維持する。

少なくともいくつかの実施形態では、接続公開パケットは、ロードバランサモジュールによって、ロードバランサノード１１０に無作為に分配されるので、接続公開パケットを受け取るロードバランサノード１１０は、接続公開パケット内のアクティブな接続情報を接続のための正しい入口／１次／２次ノード１１０に分配することを担当する。図１９Ｂ並びに図２１及び２２は、少なくともいくつかの実施形態で使用することができるアクティブな接続情報を分配するための方法を例示する。

図１９Ｂは、少なくともいくつかの実施形態に従って、アクティブな接続情報をロードバランサノード１１０間に分配すること例示する。ロードバランサノード１１０が接続公開パケットをロードバランサモジュール１３２から受け取ると、ロードバランサノード１１０は、その中に示される各々のＴＣＰフローのための情報を分析し、そのフローのための入口ノード並びに１次及び２次フロートラッカーノードを決定することができる。ロードバランサノード１１０は、フローのためのそれらの役割のうちの１つで機能し、ロードバランサノード１１０は、フローのための情報を消費する（例えば、状態情報のそのキャッシュを更新することにより）。少なくともいくつかの実施形態では、ロードバランサノード１１０はまた、フローのための情報をパケット（複数可）にいれて、フローのための他の役割で機能している１つ以上の他のノード１１０に送ることができる。接続公開パケットによって示される残りのフローについて、ロードバランサノード１１０は、アクティブな接続情報を２つ以上のより小さいパケットに分割し、各々のパケットを１つ以上の他のロードバランサノード１１０に送る。例えば、少なくともいくつかの実施形態では、１つ以上のフローのためのアクティブな接続情報を含むパケットは、フロー（複数可）のための入口サーバ１１２、１次フロートラッカー１１６Ａ、及び２次フロートラッカー１１６Ｂとして機能しているロードバランサノード１１０に送ることができる。

図２１は、少なくともいくつかの実施形態に従って、接続公開パケットで受け取ったアクティブな接続情報を対象となるロードバランサノード１１０に分配するための方法のフローチャートである。５２０に示されるように、ロードバランサノード１１０は、接続公開パケットをロードバランサモジュール１３２から受け取る。ロードバランサモジュール１３２は、例えば図１９Ａ及び２０を参照して前述したように、パケットを生成し、パケットを受け取るロードバランサノード１１０を選択した。接続公開パケットは、パケットを受け取ったサーバノード１３０を識別する情報（例えば、サーバノード１３０のロードバランサモジュール１３２のＩＰアドレス）、及びアクティブなＴＣＰ接続を識別するエントリのリスト（例えば、各々の接続のためのクライアントＩＰアドレス、クライアントポート、サーバ（パブリック）ＩＰアドレス、及びサーバポートからなる４タプル）を含み得る。

図２１の要素５２２〜５３０では、ロードバランサモジュール１１０は、受け取った接続公開パケット内に示されるアクティブなＴＣＰ接続情報を反復して処理する。５２２に示されるように、ロードバランサノード１１０は、パケット内の次のＴＣＰフローのためのエントリを分析し、それぞれのＴＣＰフローのための入口ノード１１０並びに１次及び２次フロートラッカーノード１１０を決定する。少なくともいくつかの実施形態では、ロードバランサノード１１０は、接続公開エントリから入口ノード１１０の識別子を取得する。少なくともいくつかの実施形態では、ＴＣＰフローのための１次及び２次フロートラッカーノード１１０は、コンシステントハッシュ関数に従って決定することができる。５２４で、ロードバランサノード１１０が検査されるＴＣＰフローのための役割のうちの１つで機能している場合、次に５２６で、ロードバランサノード１１０は、例えば状態情報のそのキャッシュを更新することにより、フローに関する情報を消費する。５２８に示されるように、ロードバランサノード１１０は、ＴＣＰフローのための接続公開エントリを、別のロードバランサノード１１０に送られる構築されるパケットに追加することができる。５３０で、接続公開パケットにフローのための更なる接続公開エントリが存在する場合は、方法は５２２に戻り、次のエントリを処理する。それ以外の場合、５３２に示されるように、ロードバランサノードは、オリジナルの接続公開パケットから接続公開エントリのサブセットをそれぞれが含む新規に構築されたパケット（複数可）を、パケットのための対象となるロードバランサノード１１０に送る。少なくともいくつかの実施形態では、対象となるロードバランサノード１１０に送られるパケットは、ステートレスパケット、例えばＵＤＰパケットである。いくつかの実施形態では、パケットは、パケットを対象となるロードバランサノード１１０に送る前に圧縮することができる。

したがって、少なくともいくつかの実施形態では、図２１の要素５２２〜５２８において、フロートラッカーノード１１０は、受け取った接続公開パケット内の接続公開エントリから５２２で決定された情報に従って、他のノード１１０のうちの特定の１つにそれぞれが送られる１つ以上のパケット（例えば、ＵＤＰパケット）を構築する。少なくともいくつかの実施形態では、別のノード１１０に送られるパケットは、対象となるノード１１０が入口ノード１１０、１次フロートラッカーノード１１０、または２次フロートラッカーノード１１０として機能するＴＣＰフローのためのエントリを含む。いくつかの実施形態では、所与のロードバランサノード１１０は、ＴＣＰフローのための入口及び１次フロートラッカーノードの両方として、またはＴＣＰフローのための入口及び２次フロートラッカーノードの両方として、機能することができることに留意されたい。

図２２は、少なくともいくつかの実施形態に従って、接続公開パケットで受け取ったアクティブな接続情報を、対象となるロードバランサノード１１０に分配するための代替の方法を例示する。５５０に示されるように、ロードバランサノード１１０は、接続公開パケットをロードバランサモジュール１３２から受け取る。この方法では、５５２に示されるように、ロードバランサモジュール１１０でのプロセスは、パケット内の接続公開エントリを分析し、受け取ったパケットを１つ以上のより小さいパケットに相応に分割する。ロードバランサモジュール１１０は、このプロセスの間、フロー情報をローカルで消費しない。接続公開パケットが１つ以上のパケットに一旦分割されると、パケットは、次に、５５４〜５６０に示されるように処理される。５５４で、パケットのための対象となるノード１１０がこのロードバランサノード１１０である場合は、５５６で示されるように、ロードバランサノード１１０は、パケットをローカルで消費する。それ以外の場合、パケットは、対象となるロードバランサノード１１０に送られる。５６０で、処理すべき更なるパケットが存在する場合は、方法は５５４に戻る。それ以外の場合は、方法を終了する。

したがって、接続公開パケットをロードバランサモジュール１３２から受け取るロードバランサノード１１０は、接続公開パケットを、他のロードバランサノード１１０の内の特定のものに特有である２つ以上の小さいパケットに、分割し、パケットを相応に分配することができ、一方ロードバランサノード１１０によって現在取り扱われている任意のＴＣＰフローに関するフロー情報を内部で消費する。その間、他のロードバランサノード１１０もまた、ロードバランサモジュール１３２から接続公開パケットを受け取り、接続公開エントリを複数のより小さいパケットに分割し、より小さいパケットを対象となるノード１１０に送り、アクティブな接続情報をノード１１０間に分配する。

接続公開始動
少なくともいくつかの実施形態では、接続公開は、１つ以上の異なるイベントによって、ロードバランサモジュール１３２で始動することができる。前述のように、いくつかの実施形態では、接続公開パケットは、接続公開間隔、例えば１００ｍｓまたは１秒の間隔に従って、生成され、無作為に選択されたロードバランサノード１１０に送信され、ロードバランサノード１１０上のＴＣＰ接続のためのリース期間を更新することができる。いくつかの実施形態では、ロードバランサノード１１０のメンバーシップの変更は、即座の接続公開イベントを始動することができる。少なくともいくつかの実施形態では、ロードバランサモジュール１３２は、それぞれのサーバノード１３０をヘルスチェックするロードバランサノード１１０のうちの１つから送られた健全なロードバランサノード１１０のリストから変更について学習することができる。リストに従って変更（削除または追加のいずれか）を検出すると、ロードバランサモジュール１３２は、接続公開パケットを生成してロードバランサノード１１０に送ることができ、その結果、変更に影響されたＴＣＰ接続は、ロードバランサノード１１０によって、より迅速にリカバリすることができる。

パケットループの防止
接続公開パケットを処理している間に、ロードバランサ層のメンバーシップが変更される場合、接続公開パケットのループが起こることがある。第１のノード１１０は、ロードバランサモジュール１３２から接続公開パケットを受け取り、より小さいパケットを第２のノード１１０に送ることができる。しかしながら、メンバーシップが変更された場合、第２のノード１１０は、パケットは第１のノード１１０に行くべきであることを決定することができ、したがってパケットを第１のノード１１０に転送することができる。少なくともいくつかの実施形態では、このループが起こることを防止するために、ロードバランサモジュール１３２から受け取った接続公開パケット及びロードバランサノード１１０から受け取ったものに異なるポート番号を使用することができ、ロードバランサノード１１０は、他のロードバランサノード１１０から受け取った接続公開パケットを再分配しない。

接続公開パケット分配代替案
上述の接続公開方法では、ロードバランサモジュール１３２は、接続公開パケットが送られるロードバランサノード１１０を無作為に選択する。しかしながら、いくつかの実施形態では、他の方法を使用して、ロードバランサノード１１０を選択することができる。例えば、いくつかの実施形態では、ロードバランサノード１３２は、アクティブなＴＣＰフローの１つ以上を取り扱う特定の入口ノード１１０をそれぞれが対象とする１つ以上の接続公開パケットを構築し、パケット（複数可）を対象となる入口ノード（複数可）１１０に送ることができる。入口ノード（複数可）１１０は、次に、アクティブな接続情報を接続のための１次及び２次フロートラッカーに再分配することができる。別の実施例として、いくつかの実施形態では、接続公開パケットを単一の無作為に選択されたノード１１０に送る代わりに、各々の接続公開パケットは、ロードバランサモジュール１３２によって、健全なノード１１０のうちの２つ以上に、または健全なノード１１０の全てに、送ることができる。

ロードバランサノードアーキテクチャ
図２３は、少なくともいくつかの実施形態に従うロードバランサノード１１０のための例となるソフトウェアスタックアーキテクチャを例示し、限定することを意図しない。この例となるソフトウェアスタックアーキテクチャでは、ロードバランサノード１１０は、ロードバランササーバネイティブコード１１０６及びコアパケット処理コード１１０８、例えばＩｎｔｅｌ（商標）Ｄａｔａｐｌａｎｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ（ＤＰＤＫ）テクノロジーコード、を含むことができるネイティブコードの層を管理するために、Ｊａｖａ Ｎａｔｉｖｅ Ｉｎｔｅｒｆａｃｅ（ＪＮＩ（商標））１１０４テクノロジーを使用する単一のＪａｖａ（商標）テクノロジープロセス１１０２で実行される。ネイティブコードは、２つのネットワークインターフェースコントローラ（ＮＩＣ１１１４Ａ及び１１１４Ｂ）にインターフェースすることができる。第１のＮＩＣ（ＮＩＣ１１１４Ａ）は、「ノース」、すなわちエッジルータ１０４の方向に面することができる。第２のＮＩＣ（ＮＩＣ１１１４Ｂ）は、「サウス」、すなわちサーバノード１３０の方向に面することができる。少なくともいくつかの実施形態では、ＮＩＣ１１１４Ａ及び１１１４Ｂは、ＴＣＰスタックを維持しなくてもよい。したがって、少なくともいくつかの実施形態は、ＴＣＰ接続をサポートする第３のＮＩＣ１１１４Ｃを含むことができ、その結果、ロードバランサノード１１０は、制御プレーンを介してプロセスと通信することができ、その逆も同様である。あるいは、いくつかの実施形態では、第１のノース側ＮＩＣ１１１４Ａ及び第２のサウス側ＮＩＣ１１１Ｂのみが、ロードバランサノード１１０に実装することができ、第２のサウス側ＮＩＣ１１１４Ｂは、ロードバランサノード１１０が制御プレーンを介してプロセスと通信することができるＴＣＰスタックを実装することができる。ロードバランサノード１１０はまた、オペレーティングシステム（ＯＳ）テクノロジーソフトウェア１１１２、例えばＬｉｎｕｘ（商標）カーネル、ＯＳテクノロジーソフトウェア１１１２の上部のＪａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ（ＪＶＭ（商標））テクノロジーソフトウェア１１１０層、及びＪＮＩ１１０４テクノロジー０を含む。

少なくともいくつかの実施形態では、分散型ロードバランシングシステムのロードバランサノード１１０は、それぞれ高いパケットレートの多くのデータフローを同時に処理することが必要となることがある。少なくともいくつかの実施形態では、スループットの必要なレベルを達成するために、ロードバランサノード１１０は、高性能のパケット処理のために、Ｉｎｔｅｌ（商標）Ｄａｔａｐｌａｎｅ Ｄｅｖｅｌｏｐｍｅｎｔ Ｋｉｔ（ＤＰＤＫ）テクノロジーを活用することができる。ＤＰＤＫテクノロジーは、ユーザー空間プログラムがパケットをネットワークインターフェースコントローラ（ＮＩＣ）に及びそこから直接に読取／書込みすることを可能にし、またＬｉｎｕｘカーネルネットワーキングスタックの多くの層をバイパスする（Ｌｉｎｕｓ ｉｘｇｂｅベースＮＩＣドライバを除く）。パケット処理へのＤＰＤＫアプローチは、ＮＩＣハードウェアをビジーループに直接にポーリングする専用ＣＰＵコアに有利なように割込みハンドラベース入力を拒否する。このアプローチは、専用ＣＰＵコアをビジーループで連続的に実行することによって熱出力を増加させることを犠牲にして、かなり高いパケットレートを可能にすることができる。ＤＰＤＫテクノロジーはまた、ＣＰＵコア管理、ロックフリーキュー、メモリプール、及び同期基本命令を含むパケット処理のためのツールを提供する。図２４に示されるように、ＤＰＤＫテクノロジーでは、専用ＣＰＵコア６００は、各々の特定のタスクのために使用することができ、ワークは、非ブロッキングキュー６０２を使用して、１つのＣＰＵコア６００Ａから別のＣＰＵコア６００Ｂへ送られる。

ＤＰＤＫキュー６０２は、高速の２のべき乗リングバッファを使用して実装することができ、単一及び複数のプロデューサ／コンシューマバリアントをサポートすることができる。複数のプロデューサ／コンシューマバリアントは、それらはアクセスを同期するためのコンペアアンドスワップ（ＣＡＳ）ループを含むので、真にロックフリーではない。全てのパケットバッファメモリは事前にメモリプールに割り当てることができ、その結果バッファへのポインタのみがキュー６０２に対して読取及び書込みが行われる。メモリプールは、キューとして実装することができ、メモリをメモリチャネル及びランクにわたって分配するように最適化することができ、非均一メモリアクセス（ＮＵＭＡ）最適化割り当てをサポートすることができる。少なくともいくつかの実施形態では、パケットバッファは、各々パケットバッファに十分なヘッドルーム及びテールルームを過剰割当して、バッファコピーを必要とせずに外側ネットワーク層ヘッダを追加／除去することができるカプセル化／デカプセル化操作をサポートするＭｂｕｆパラダイムのような方法を使用することができる。

ロードバランサノード１１０の少なくともいくつかの実施形態では、ＤＰＤＫテクノロジーを活用するコアパケット処理アーキテクチャを実装することができる。各々のロードバランサノード１１０は、コアパケット処理アーキテクチャに従って実装された少なくとも１つのマルチコアパケットプロセッサを含むことができる。コアパケット処理アーキテクチャは、マルチコアパケットプロセッサのキュー及びコアを通るパケットフローのための単一のプロデューサ／単一のコンシューマパラダイムを使用することができる。このパラダイムでは、各々のキューは唯一のコアに入力し、各々のコアはそれがパケットを供給する互いのコアで唯一のコアに出力する。更に、マルチコアパケットプロセッサのコアによって使用されるメモリは共有されず、各々のコアはそれ自身の別々のメモリ領域を有する。したがって、コア間で共有するメモリまたはキューが存在せず、メモリまたはキューの競合が存在せず、所有権の要求（ＲＦＯ）またはコンペアアンドスワップ（ＣＡＳ）のようなメモリまたはキュー共有機構を必要としない。図２５及び２６は、コアパケット処理アーキテクチャに従って実装された例となるマルチコアパケットプロセッサを例示する。

図２５は、少なくともいくつかの実施形態に従い、データフローを処理するためにＤＰＤＫテクノロジーを活用するコアパケット処理アーキテクチャに従って実装された例となるマルチコアパケットプロセッサを例示する。コアパケット処理アーキテクチャは、単一のプロデューサ／単一のコンシューマパラダイムに従って、マルチコアパケットプロセッサとして実装することができる。少なくともいくつかの実施形態では、図２３に例示されるように、ロードバランサノード１１０は、各々２つのネットワークインターフェースコントローラ（ＮＩＣ）、ボーダーネットワーク／エッジルータ１０４に面するノース側ＮＩＣ１１１４Ａ及び実稼働ネットワーク／サーバノード１３０に面するサウス側ＮＩＣ１１１４Ｂを有する。少なくともいくつかの実施形態では、ＮＩＣ１１１４は、１０Ｇｐｂｓ ＮＩＣであってよい。ロードバランサノード１１０を介してフローするパケットの大部分は、これらの２つのＮＩＣのうちの１つ（ＮＩＣ１１４Ａまたは１１１４Ｂのいずれか）で受け取られ、処理され（例えば、カプセル化またはデカプセル化）、及び他のＮＩＣ（ＮＩＣ１１１４Ｂまたは１１１４Ａのいずれか）に送信される。

図２５を参照すると、少なくともいくつかの実施形態では、ロードバランサノード１１０は、各々ＮＩＣ１１１４の２つのＣＰＵコア、受信（ＲＸ）コア６１０、及び送信（ＴＸ）コア６３０をスピンアップする。ロードバランサノード１１０はまた、４つのワーカーコア６２０Ａ〜６２０Ｄが使用されるこの実施例において、両方のＮＩＣ１１１４のためのパケットを処理する複数のワーカーコア６２０を両方向にスピンアップする。受信コア６１０は、着信パケットのバッチを、それらがＮＩＣ１１１４に到着するときにそれらの入力キューから読み取り、パケットを各々のパケットのためのワークのバルクを行うワーカーコア６２０に分配し、同時に各々の受信コア６１０はパケットを各々のワーカーコア６２０のためのそれぞれのワーカー入力キュー６１２に供給する。少なくともいくつかの実施形態では、受信コア６１０は、各々の着信パケットに層４「フローハッシュ」技術（前述のエッジルータ１０４によって使用することができるフロー毎ハッシュ化マルチパスルーティング技術と同様である）を行い、パケットをワーカーコア６２０に分配することができ、同時に任意の特定のクライアント接続（そのＩＰアドレス及びポートで区別される）は同じワーカーコア６２０によって処理されることを保証する。これは、各々のワーカーコア６２０は、パケットの同じサブセットを常に見て、ワーカーコア６２０によって管理される状態データに関する競合を除去することができ、その結果ロックを必要としない。受け取ったパケットへのポインタは、ワーカーコア６２０が新規の入力について連続して監視するワーカーキュー６２２にわたって分配することができる。ワーカーコア６２０は、各々の接続に関する状態（例えば、割り付けられたサーバノード１３０）を管理することを担当し、パケットをそれらのアウトバウンドキュー６３２に転送する前に、パケットにＵＤＰカプセル化またはデカプセル化を行うことができる。送信コア６３０は、ワーカーコア６２０を通してアウトバウンドキュー６３２をサイクルし、それらがキュー６３２に現れるときに出力パケットをそれらの対応するＮＩＣ１１１４に書き込む。

図２６は、少なくともいくつかの実施形態に従って、データフローを処理するためにＤＰＤＫテクノロジーを活用するコアパケット処理アーキテクチャに従って実装された別の例となるマルチコアパケットプロセッサを例示する。コアパケット処理アーキテクチャは、単一のプロデューサ／単一のコンシューマパラダイムに従って、マルチコアパケットプロセッサとして実装することができる。少なくともいくつかの実施形態では、高スループットのクライアントＴＣＰフローを処理することに加えて、ロードバランサノード１１０のＤＰＤＫコアアーキテクチャはまた、ＡＲＰ、ＤＨＣＰ、及びＢＧＰのような他のプロトコルのためのノース及びサウス側ＮＩＣ１１１４でパケットを送り、受け取るために使用することができる。図２６に示される実施形態では、ワーカーコア６２０Ａは、それらの他のプロトコルのためのパケットを取り扱うことに専用される。このワーカーコア６２０Ａは、これらのパケットの処理が概してクライアントＴＣＰフローより遅いレートで起こるので、「低速」ワーカーコアと呼ぶことができ、一方クライアントＴＣＰフローのみを処理する他のワーカーコア６２０Ｂ〜６２０Ｄは、高速ワーカーコアと呼ぶことができる。ノース側及びサウス側ＮＩＣ１１１４でそれぞれ着信パケットを取り扱う受信コア６１０Ａ及び６１０Ｂは、低速ワーカーコア６２０Ａによって取り扱われるパケットを識別し、パケットを低速ワーカーコア６２０Ａのための入力キュー６２２に向けることができる。低速ワーカーコア６２０Ａはまた、Ｊａｖａ／ＪＮＩによって生成されたパケットのための入力キュー６２２、及びＪａｖａ／ＪＮＩへの出力パケットのための出力キュー６３４を監視することができる。低速ワーカーコア６２０Ａはまた、高速ワーカーコア６２０Ｂ〜６２０Ｄの各々のための入力キュー６２２へ出力し、その結果低速ワーカーコア６２０Ａは、パケット、例えば接続公開パケットを、高速ワーカーコア６２０Ｂ〜６２０Ｄの各々に送ることができる。低速ワーカーコア６２０Ａはまた、送信コア６３０Ａ及び６３０Ｂの各々に供給されるアウトバウンドキュー６３２を有する。

少なくともいくつかの実施形態では、各々の高速ワーカーコア６２０Ｂ〜６２０Ｄの第３の入力キュー６２２は、低速ワーカーコア６２０Ａからの出力キューである。少なくともいくつかの実施形態では、第３の入力キュー６２２は、例えば、接続状態情報を各々含む接続公開パケットを、高速ワーカーキュー６２０Ｂ〜６２０Ｄによって、受け取り、処理するために使用することができる。これらの接続公開パケットの少なくともいくつかについて、送信コア６３０への出力が存在しなくてもよい。その代りに、パケット内の接続状態情報は、高速ワーカーコア６２０によって、例えばそれぞれの高速ワーカーコア６２０が維持する１つ以上のパケットフローに関する格納された状態を更新することによって、消費することができる。したがって、高速ワーカーコア６２０Ｂ〜６２０Ｄに入力される低速ワーカーコア６２０Ａからの出力キューは、高速ワーカーコアの格納された状態を更新するために受信コア６１０から直接の入力キュー６２２以外のパスを提供することができる。

少なくともいくつかの実施形態では、図２５及び２６のマルチコアパケットプロセッサは、着信パケットをフィルター処理し、有効であるパケットのみを処理し、出力することができる。例えば、少なくともいくつかの実施形態では、受信コア６１０は、ワーカーコア６２０の何れによってもサポートされていないプロトコルであるパケットを除外し、したがってパケットをワーカーコア６２０に送らなくてよい。少なくともいくつかの実施形態では、ワーカーコア６２０は、パケットを処理するとき、各々最初に、それらのそれぞれのワーカー入力キュー６２２から読み取られたパケットを分析し、パケットを更なる処理のために受け入れて送信コア６３０に出力すべきかを決定することができ、受け入れられたパケットのみの処理及び送信コア６３０への出力を完了することができ、受け入れられなかったパケットは廃棄することができる。例えば、ワーカーコア６２０は、各々のパケットに関するアドレス情報を見て、ロードバランス化される有効なアドレスに向けられたパケットのみを受け入れることができ、一切の他のパケットを廃棄する。

ボーダーゲートウェイプロトコル（ＢＧＰ）データの取り扱い
少なくともいくつかの実施形態では、コアアーキテクチャに出入するＢＧＰクライアントに関連するパケットフローは、以下のように取り扱うことができる。ＮＩＣ１１１４Ａ及び１１１４Ｂは、Ｌｉｎｕｘカーネルに向けられていないので、エッジルータ１０４へのＴＣＰ接続は、図２６で例示されるようにコアアーキテクチャによって傍受され、低速ワーカーコア６２２Ａによって処理され、それはＢＧＰパケットを、出力キュー６３４を介してＪａｖａ空間内に送り込む。これらのＴＣＰパケットは、ＢＧＰクライアントに配信される前に、ＴＣＰ接続を管理し、パケットをＴＣＰストリームに効果的に変換するためにＬｉｎｕｘカーネルによる処理を含めて、ロードバランサノード１１０の１つ以上のモジュールによって更に処理される。この設計は、ＢＧＰクライアントが標準のＪａｖａ ＴＣＰソケットライブラリを使用して書き込まれるのを可能にする。

図２７は、少なくともいくつかの実施形態に従って、ロードバランサ（ＬＢ）ノードプロセス６５０による着信ＢＧＰ ＴＣＰパケットの処理を例示する。エッジルータ１０４からのパケットは、ノース側ＮＩＣ６４０に到着し、受信コア６５２のための入力キュー６４０に入る。受信コア６５２は、キュー６４０からパケットを読み取り、パケットをＢＧＰパケットとして識別すると、パケットを低速ワーカーコア６５６のための入力キュー６５４に置く。低速ワーカーコア６５６は、パケットを検証し、それをＪＮＩ出力キュー６５８に置く。ＪＮＩパケットレシーバ６６０は、ＪＮＩを介してキュー６５８からパケットを読み取り、送信元／送信先アドレスをマングリングし、パケットを生のソケット６４４に書き込む。Ｌｉｎｕｘカーネル６４６は、生のパケットを受け取り、それをＴＣＰプロトコルに従って取り扱い、ペイロードデータをＴＣＰソケットＩｎｐｕｔＳｔｒｅａｍに追加する。パケットからのデータは、次に、ＢＧＰクライアント６６２のＪａｖａ ＴＣＰソケットに配信される。

図２８は、少なくともいくつかの実施形態に従って、ロードバランサ（ＬＢ）ノードプロセス６５０による発信ＢＧＰ ＴＣＰパケットの処理を例示する。ＢＧＰクライアント６６２は、データをＬｉｎｕｘカーネル６４６のＪａｖａ ＴＣＰソケットに書き込む。Ｌｉｎｕｘカーネル６４６は、データをＴＣＰプロトコルに従って取り扱い、データをＴＣＰパケット（複数可）に変換する。少なくともいくつかの実施形態では、ＴＣＰパケット（複数可）は、１２７．ｘ．ｘ．ｘ ｉｐｔａｐｌｅｓ規則に適合する。ＴＣＰパケット（複数可）は、出力キュー６４８、例えばＮｅｔｆｉｌｔｅｒ ＬＯＣＡＬ＿ＯＵＴキューに置かれる。ＪＮＩを介してキュー６４８を監視するＪＮＩパケットレシーバ６７０のＪａｖａスレッドは、ＴＣＰパケット（複数可）を受け取り、各々のＮＦ＿ＳＴＯＬＥＮにマークしてカーネル６４６にそれらのことを忘れさせる。Ｊａｖａスレッドは、送信元／送信先アドレスをマングリングし、パケット（複数可）を、ＪＮＩを介して低速ワーカーコア６５６のためのＪＮＩ入力キュー６７２に追加する。低速ワーカーコア６５６は、ＴＣＰパケット（複数可）をそのＪＮＩ入力キュー６７２から受け取り、パケットをノース側ＮＩＣ６４０送信コア６６６のためのアウトバウンドキュー６６４に置く。送信コア６６６は、ＴＣＰパケット（複数可）をその入力キュー６６４から読み取り、それらをノース側ＮＩＣ６４０に書き込む。ＴＣＰパケットは、ＮＩＣ６４０によってエッジルータに送られる。

分散型ロードバランサのシミュレーション及びテスト
本明細書の記載のロードバランサは、多くの独立した構成要素（例えば、ルータ、ロードバランサノード、ロードバランサモジュールなど）の相互作用を必要とする分散型システムである。分散型構成要素、論理、及びプロトコルのテストを行うために、並びにノード障害、メッセージドロップ、及び遅延のようなシナリオをシミュレートするために、複雑なネットワークトポロジ（例えば、実稼働ネットワーク）の複数のホストにコードを展開することを必要とせずに、相互作用をテストすることができる単一のプロセスで分散型ロードバランサを実行させることを可能にするテストシステムの実施形態を説明する。これを達成するために、複数のロードバランサの構成要素が単一のプロセスでまたはそれとして構成され、実行されることを可能にするメッセージバスと呼ばれるソフトウェア機構を説明し、単一のプロセスは単一のホストシステムで実行することができる。メッセージバス機構は、分散型ロードバランサシステムが単一のプロセスとして、例えば単一のホストシステムでテストされることを可能にし、一方ロードバランサの構成要素（ロードバランサノード及びロードバランサモジュール）に対して、それらは実際の実稼働ネットワークで実行されているように見える。

メッセージバスは、分散型ロードバランサが単一のプロセスとして実行されることを可能にするフレームワークを提供する。プロセス内の１つ以上のメッセージバス層の各々は、分散型ロードバランサの構成要素間でネットワーク（例えば、イーサネット（登録商標））セグメントをシミュレートする。分散型ロードバランサシステムのソフトウェア構成要素は、特別の様式で書き込む必要がなく、構成要素がメッセージバス環境内で動作することを可能にする。その代りに、メッセージバスフレームワークは、分散型ロードバランサシステムの構成要素が生成するパケットを傍受し、パケットを、実際の物理的ネットワークの代わりに、メッセージバス層によって提供されるシミュレートされたネットワークに向け、パケットを対象となる構成要素に配信する構成要素（メッセージバスＮＩＣまたはパケットアダプタと呼ぶことができる）を提供する。メッセージバス層は、構成要素間の通信のためのＴＣＰ／ＩＰスタック（複数可）を実装しない。その代りに、メッセージバス層は、ホストシステムのオペレーティングシステム（ＯＳ）とインターフェースし、ホストシステムのＴＣＰ／ＩＰスタックを使用する。メッセージバス層は、ＯＳによって提供されるＴＣＰ／ＩＰスタックを活用し、クライアント及びサーバが、メッセージバスが傍受し、配信する個別のパケットに対して及びそこから期待するようにＴＣＰストリームを変換する。

少なくともいくつかの実施形態では、メッセージバスとインターフェースするために、ロードバランサの構成要素は、有効なメディアアクセス制御（ＭＡＣ）アドレスを各々が有する少なくとも１つのメッセージバスネットワークインターフェースコントローラ（ＮＩＣ）を備え、それは、物理的ネットワークとの送受の代わりにメッセージバスシミュレートされたネットワーク環境へパケットを送り、そこからパケットを受け取る。メッセージバスＮＩＣは、物理的ネットワークの代わりにメッセージバスに取り付けられる仮想ネットワークインターフェースコントローラである。メッセージバスを介して通信する必要がある各々のロードバランサの構成要素は、少なくとも１つのメッセージバスＮＩＣを必要とする。メッセージバスＮＩＣは、メッセージバスへの出パイプライン出口として、及び構成要素へのパイプライン入口として機能する。構成要素は、各々のメッセージバスＮＩＣへの複数のメッセージバスネットワークインターフェースをインスタンス化することができる。

メッセージバスネットワークインターフェースは、構成要素を、メッセージバスＮＩＣを介してメッセージバスに取り付けるための機構である。メッセージバスネットワークインターフェースは、Ｌｉｎｕｘテクノロジーのインターフェース構成（ｉｆｃｏｎｆｉｇ）インターフェースと同義であることができるが、メッセージバスネットワークインターフェースは、物理的ネットワークの代わりにメッセージバスに取り付けられるという違いがある。メッセージバスネットワークインターフェースは、ＩＰアドレスを有し、メッセージバスＮＩＣの上部に位置する。メッセージバスネットワークインターフェースは、メッセージバスからパケット受け取るために構成要素が使用することができるパケットソースインターフェースと、メッセージバスにパケットを送るために構成要素が使用することができるパケットシンクインターフェースと、を公開する。

各々のロードバランサノードは、パケットソース及びパケットシンクインターフェースの実現形態を介して配信され、送られる個別のネットワークパケットを処理する。メッセージバス環境で実行されると、これらのインターフェースは、層２イーサネットヘッダーを追加または除去するメッセージバスネットワークインターフェースによって実装される（これがカーネルネットワークスタックによって行われることを期待するロードバランサノードのために）。図２９に示されるような実稼働環境では、パケットソース及びパケットシンクインターフェースの実現形態は、実際のネットワークインターフェース上のパケットを受信し、送信する。図３０に示されるようなメッセージバス環境では、パケットソース及びパケットシンクインターフェースの実現形態は、メッセージバス層または層（複数）からパケットを受信し、そこへパケットを送信する。

簡略化のために、メッセージバスＮＩＣ及びメッセージバスインターフェースは、集合的にメッセージバスパケットアダプタ、または単にパケットアダプタと呼ぶことができる。例えば、図３１及び３２を参照。

図２９は、少なくともいくつかの実施形態に従って、実稼働環境に分散型ロードバランサ７００を含むロードバランシングシステムを例示する。ロードバランサ７００は、この説明のための単純化された。ロードバランサ７００は、ロードバランサ７００を実装するデータセンタのようなネットワーク設備のボーダールータ７０２を介して外部ネットワーク７４０上のクライアント７４２に接続することができる。ロードバランサ７００は、複数のタイプの構成要素、少なくとも１つのエッジルータ７０４、２つ以上のロードバランサ（ＬＢ）ノード７１０、各々が別々のサーバノード（図示なし）に実装された２つ以上のロードバランサ（ＬＢ）モジュール７３２、ルータまたはスイッチのようなファブリック７２０を形成する１つ以上のネットワーキング構成要素、及び少なくともいくつかの実施形態では、構成サービス７２２を含む。少なくともいくつかの実施形態では、ロードバランサ７００の各々の構成要素は、汎用ラックマウント型コンピューティングデバイスのような分離したコンピューティングデバイスとして、またはその上に実装することができる。

図３０は、少なくともいくつかの実施形態に従って、複数の分散型ロードバランシングシステムの構成要素が、単一のプロセスで、またはそれとして構成され、実行されることを可能にするメッセージバス機構を組み込む分散型ロードバランサテストシステム８００を例示する。図２９に示されるロードバランサ７００では、各々のロードバランサソフトウェア構成要素は、別々のコンピューティングデバイスに組み込まれ、実行される（例えば、ロードバランサノード７１０上のロードバランサソフトウェア及びサーバノード上のロードバランサモジュール７３２）。これらのロードバランサソフトウェア構成要素が単一のプロセスで実行されることを可能にするために、各々のロードバランサソフトウェア構成要素（図３０にロードバランサ「ＬＢ」ノード８１０及びロードバランサ（ＬＢ）モジュール８３２として示される）は、構成要素のネットワーク接続を抽象化するコードを含むことができ、その結果ロードバランサソフトウェア構成要素に出入するパケットはまた、物理的ネットワーク上で送受される代わりに、メッセージバス機構を介して傍受され、ルーティングすることができる。

少なくともいくつかの実施形態では、分散型ロードバランサテストシステム８００において、メッセージバス機構は、構成要素間の通信のためのＴＣＰスタック（複数可）を実装しない。その代りに、メッセージバス機構は、ホストシステムのオペレーティングシステム（ＯＳ）とインターフェースし、ホストシステムのＴＣＰスタックを使用する。少なくともいくつかの実施形態では、メッセージバス機能は、ＩＰテーブル、カーネルの機能を介して、ユーザー層の下のホストシステムのＯＳのカーネル（例えば、Ｌｉｎｕｘカーネル）に結合される。メッセージバス機能は、カーネルレベルでＩＰテーブルに接続し、パケットを傍受し、パケットをルーティングのためにメッセージバスプロセスに送り込む。

図３０のシミュレートされたエッジルータ８６２及びシミュレートされたファブリック８６４によって示されるように、物理的ネットワーク構成要素（例えば、図２９のエッジルータ７０４及びファブリック７２０）の機能は、ソフトウェアでシミュレートすることができ、クライアント８６０、サーバ８３４、及び構成サービス８６６も同様に可能である。しかしながら、少なくともいくつかの実施形態では、シミュレートされたものではない実際のサーバ８３４を分散型ロードバランサテストシステム８００で使用することもできることに留意されたい。図３０のメッセージバス層８５０は、物理的ネットワークインフラストラクチャと交換する。したがって、ロードバランサソフトウェア構成要素（ロードバランサノード８１０及びロードバランサモジュール８３２）は、図２９に示されるような実稼働ネットワーク環境でそれらが実行されていないことを意識しないまま、ロードバランサテストシステム８００で実行することができる。

いくつかの構成要素（例えば、シミュレートされたルータ）は、ネットワークセグメントをシミュレートする異なるメッセージバス層８５０へパケットを送り、そこからパケットを受け取るために、１つよりも多くのメッセージバス層８５０に接続することができる。

分散型ロードバランシングテストシステム８００のメッセージバス層８５０に実装されたメッセージバス機構は、ネットワークセグメントの「ワイヤー」をシミュレートする。少なくともいくつかの実施形態では、メッセージバス機構は、構成要素のＭＡＣアドレスに基づいて、分散型ロードバランシングテストシステム８００の送信先構成要素へパケットを配信する。したがって、各々ロードバランサソフトウェア構成要素（ロードバランサノード８１０及びロードバランサモジュール８３２）は、ＭＡＣアドレスをそれが接続されたメッセージバス層（複数可）８５０に提供し、その結果ロードバランサソフトウェア構成要素は、分散型ロードバランシングテストシステム８００の他の構成要素からそれに送られたパケットを受け取ることができる。

メッセージバスパケットアダプタ
図３１及び３２は、少なくともいくつかの実施形態に従って、メッセージバスパケットアダプタを例示する。少なくともいくつかの実施形態では、各々のロードバランサ（ＬＢ）ソフトウェア構成要素は、パケットソース及びパケットシンクインターフェースの実現形態を介して配信され、送られた個別のネットワークパケットを処理する。図３１を参照すると、分散型ロードバランシングテストシステム８００で実行されると、それらのインターフェース（パケットソースインターフェース８６２及びパケットシンクインターフェース８６４として示される）は、メッセージバス層８５０とロードバランサソフトウェア構成要素８６０との間にあって、これがカーネルネットワークスタックによって行われることを期待するロードバランサソフトウェア構成要素８７０のための層２イーサネットヘッダーを追加または除去するパケットアダプタ８７０によって実装することができる。図２９に例示されるような実稼働環境では、ロードバランサソフトウェア構成要素のためのパケットソース及びパケットシンクの実現形態は、構成要素が実装される物理的デバイスの実際のネットワークインターフェース上でパケットを受け取り、送信する。

図３１を参照すると、少なくともいくつかの実施形態では、ロードバランサソフトウェア構成要素８７０がパケットを送信すると、パケットシンクインターフェース８６４の送信パケット方法をコールする実行のスレッドは、パケットアダプタ８６０内及び更にメッセージバス層８５０内の機能のチェーンを横切り、パケットをその構成要素の入力キューに追加することにより、パケットを最終的に送信先構成要素に配信する。少なくともいくつかの実施形態では、ロードバランサソフトウェア構成要素８７０がパケットを受け取ると、ロードバランサソフトウェア構成要素８７０は、パケットソースインターフェース８６２の受信パケット方法をコールし、その入力キューからパケットを読み取る。少なくともいくつかの実施形態では、メッセージバス機構は、パケットを配信するためにそれ自身の一切の追加のスレッドを必要としない。

メッセージパケットパイプライン
図３２を参照すると、少なくともいくつかの実施形態では、パケットソースインターフェース８６２及びパケットシンクインターフェース８６４のメッセージバス８５０側は、パケットパイプライン機能を提供する。ロードバランサソフトウェア構成要素８７０が、パケットシンクインターフェース８６４を介してパケットを送ると、パケットデータは、メッセージバス層８５０に達する前に、一連のステージ（パケットパイプライン８８０）を横切ることができる。これらのステージは、パケットを変調し、パケットをドロップし、パケットを複製し、パケットを遅延することなどができる。一旦パケットがパケットパイプライン８８０を横切ると、メッセージバス層８５０は送信先構成要素８７０を選択し、送信先構成要素８７０に関連付けられた第２の一連のパイプラインステージ（パケットパイプライン８８２）はまた、パケットが送信先構成要素８７０の入力キューに追加される前に、横切られることができる。

例となるプロバイダネットワーク環境
このセクションは、分散型ロードバランシング方法及び装置の実施形態を実装することができる例となるプロバイダネットワーク環境を説明する。しかしながら、これらの例となるプロバイダネットワーク環境は限定することを意図しない。

図３３Ａは、少なくともいくつかの実施形態に従って、例となるプロバイダネットワーク環境を例示する。プロバイダネットワーク１９００は、限定するものではないが、１つ以上のデータセンタのプロバイダネットワークまたはネットワーク（複数）内のデバイス上に実装される計算及びストレージリソースを含めて、クライアントが仮想化リソースのインスタンス１９１２にアクセス、購入、賃貸、またはそうでなければ取得することを可能にする１つ以上の仮想化サービス１９１０を介してクライアントにリソース仮想化を提供することができる。プライベートＩＰアドレス１９１６は、リソースインスタンス１９１２に関連付けることができ、プライベートＩＰアドレスは、プロバイダネットワーク１９００上のリソースインスタンス１９１２の内部ネットワークアドレスである。いくつかの実施形態では、プロバイダネットワーク１９００はまた、クライアントがプロバイダ１９００から取得することができるパブリックＩＰアドレス１９１４及び／またはパブリックＩＰアドレス範囲（例えば、インターネットプロトコルバージョン４（ＩＰｖ４）またはインターネットプロトコルバージョン６（ＩＰｖ６）アドレス）を提供することができる。

従来、プロバイダネットワーク１９００は、仮想化サービス１９１０を介して、サービスプロバイダのクライアント（例えば、クライアントネットワーク１９５０Ａを操作するクライアント）がクライアントに割り付けられたまたは割り当てられた少なくともいくつかのパブリックＩＰアドレス１９１４をクライアントに割り付けられた特定のリソースインスタンス１９１２に動的に関連付けることを可能にすることができる。プロバイダネットワーク１９００はまた、クライアントが以前にクライアントに割り当てられた１つの仮想化コンピューティングリソースインスタンス１９１２にマッピングされたパブリックＩＰアドレス１９１４を、クライアントに別に割り当てられた別の仮想化コンピューティングリソースインスタンス１９１２に再マッピングすることを可能にする。サービスプロバイダによって提供された仮想化コンピューティングリソースインスタンス１９１２及びパブリックＩＰアドレス１９１４を使用し、クライアントネットワーク１９５０Ａのようなサービスプロバイダのクライアントは、例えば、クライアント固有アプリケーションを実装し、クライアントアプリケーションをインターネットのような中間ネットワーク１９４０に提示することができる。中間ネットワーク１９４０上の他のネットワークエンティティ１９２０は、次に、クライアントネットワーク１９５０Ａによって発行された送信先パブリックＩＰアドレス１９１４へのトラフィックを生成することができ、トラフィックは、サービスプロバイダデータセンタにルーティングされ、データセンタでは、ネットワーク基板を介して、送信先パブリックＩＰアドレス１９１４に現在マッピングされた仮想化コンピューティングリソースインスタンス１９１２のプライベートＩＰアドレス１９１６に、ルーティングされる。同様に、仮想化コンピューティングリソースインスタンス１９１２からの応答トラフィックは、ネットワーク基板を介して中間ネットワーク１９４０へ返されて送信元エンティティ１９２０にルーティングすることができる。

プライベートＩＰアドレスは、本明細書で使用される場合、プロバイダネットワークのリソースインスタンスの内部ネットワークアドレスを指す。プライベートＩＰアドレスは、プロバイダネットワーク内のみでルーティング可能である。プロバイダネットワークの外部から発信されるネットワークトラフィックは、プライベートＩＰアドレスに直接にルーティングされず、その代りに、トラフィックは、リソースインスタンスにマッピングされたパブリックＩＰアドレスを使用する。プロバイダネットワークは、パブリックＩＰアドレスからプライベートＩＰアドレスに、及びその逆にマッピングを行うために、ネットワークアドレストランスレーション（ＮＡＴ）または同様の機能を提供するネットワークデバイスまたは装置を含むことができる。

パブリックＩＰアドレスは、本明細書で使用される場合、サービスプロバイダによってか、またはクライアントによってかのいずれかで、リソースインスタンスに割り付けられたインターネットルーティング可能であるネットワークアドレスである。パブリックＩＰアドレスにルーティングされるトラフィックは、例えば１：１ネットワークアドレストランスレーション（ＮＡＴ）を介して変換され、リソースインスタンスのそれぞれのプライベートＩＰアドレスに転送される。

いくつかのパブリックＩＰアドレスは、プロバイダネットワークインフラストラクチャによって、特定のリソースインスタンスに割り付けることができ、それらのパブリックＩＰアドレスは、標準パブリックＩＰアドレス、または単に標準ＩＰアドレスと呼ぶことができる。少なくともいくつかの実施形態では、リソースインスタンスのプライベートＩＰアドレスへの標準のＩＰアドレスのマッピングは、全てのリソースインスタンスタイプに対してデフォルト起動構成である。

少なくともいくつかのパブリックＩＰアドレスは、プロバイダネットワーク１９００のクライアントに割り当てられる、またはそれによって取得することができ、クライアントは、次に、それらの割り当てられたパブリックＩＰアドレスをクライアントに割り当てられた特定のリソースインスタンスに割り付けることができる。これらのパブリックＩＰアドレスは、クライアントパブリックＩＰアドレス、または単にクライアントＩＰアドレスと呼ぶことができる。標準ＩＰアドレスの場合のようにプロバイダネットワーク１９００によってリソースインスタンスに割り付ける代わりに、クライアントＩＰアドレスは、リソースインスタンスに、クライアントによって、例えばサービスプロバイダによって提供されるＡＰＩを介して割り付けることができる。標準ＩＰアドレスとは異なり、クライアントＩＰアドレスは、必要または所望に応じて、それぞれのクライアントによって、クライアントアカウントに割り当てられ、また他のリソースインスタンスに再マッピングすることができる。クライアントＩＰアドレスは、特定のリソースインスタンスではなく、クライアントのアカウントに関連付けられ、クライアントは、クライアントがそれを解放することを選ぶまで、そのＩＰアドレスを制御する。従来の静的ＩＰアドレスとは異なり、クライアントＩＰアドレスは、クライアントのパブリックＩＰアドレスをクライアントのアカウントに関連付けられた全てのリソースインスタンスに再マッピングすることにより、クライアントがリソースインスタンスまたは利用可能ゾーン障害をマスクすることを可能にする。クライアントＩＰアドレスは、例えば、クライアントＩＰアドレスを交換用リソースインスタンスに再マッピングすることにより、クライアントがクライアントのリソースインスタンスまたはソフトウェアに伴う問題をエンジニアリングすることを可能にする。

図３３Ｂは、少なくともいくつかの実施形態に従って、図３３Ａに示されるような例となるプロバイダネットワーク環境における分散型ロードバランサの実現形態を例示する。プロバイダネットワーク１９００は、サービス１９１０、例えば仮想化ストレージサービスを、クライアント１９６０に提供することができる。クライアント１９６０は、サービス１９１０に、例えば１つ以上のＡＰＩを介してサービス１９１０にアクセスし、プロバイダネットワーク１９００の実稼働ネットワーク部分の複数のサーバノード１９９０に実装されたリソース（例えば、ストレージリソースまたは計算リソース）の使用を取得することができる。サーバノード１９９０は、それぞれサーバ（図示せず）、例えばウェブサーバまたはアプリケーションサーバ、並びにローカルのロードバランサ（ＬＢ）モジュール１９９２を実装することができる。１つ以上の分散型ロードバランサ１９８０は、ボーダーネットワークと実稼働ネットワークとの間のロードバランサ層に実装することができる。ボーダールータ（複数可）１９７０は、インターネットのような中間ネットワーク１９４０を介してクライアント１９６０からのパケットフロー内のパケット（例えば、ＴＣＰパケット）を受け取り、パケットを、ボーダーネットワークを介して分散型ロードバランサ（複数可）１９８０のエッジルータ（複数可）に転送することができる。パケットは、分散型ロードバランサ（複数可）１９８０のエッジルータ（複数可）によって発行されたパブリックＩＰアドレス（複数可）に向けられる。各々の分散型ロードバランサ１９８０のエッジルータは、パケットフローをそれぞれの分散型ロードバランサ１９８０のロードバランサノード間に分配することができる。少なくともいくつかの実施形態では、入口ノードとして機能する各々のロードバランサノードは、同じパブリックＩＰアドレスをエッジルータに広告し、エッジルータは、フロー毎ハッシュ化マルチパスルーティング技術、例えば等価コストマルチパス（ＥＣＭＰ）ハッシング技術に従って、クライアント１９６０からのパケットフローを入口サーバ間に分配する。ロードバランサノードは、本明細書に記載の接続プロトコルを使用して、パケットフローのための対象となるサーバノード１９９０を決定し、サーバとクライアント１９６０との間の接続を促進することができる。接続が一旦確立されると、入口ノードは、フローのために受け取ったパケットをカプセル化して対象となる実稼働ネットワーク上のサーバノード１９９０へ送り、その間フロートラッカーノードは、接続のための状態を維持する。サーバノード１９９０のロードバランサモジュール１９９２は、サーバノード１９６０のそれぞれのサーバが接続を受け入れたかどうかについて決定を行うことができる。ロードバランサモジュールは、入口ノードからのパケットを受け取ってデカプセル化し、デカプセル化パケット（例えば、ＴＣＰパケット）をサーバノード１９９０のそれぞれのサーバに送る。ロードバランサモジュール１９９２はまた、パケットフローのための出口ノードとしてのロードバランサノードを選択し、フローのための発信パケットをカプセル化し、実稼働ネットワークを介して選択された出口ノードに送る。出口ノードは、今度はパケットをデカプセル化し、デカプセル化パケットをそれぞれのクライアント１９６０への配信のためのボーダーネットワークに送る。

図３４Ａは、少なくともいくつかの実施形態に従って、分散型ロードバランサ及びサーバノードの例となる物理的ラック実現形態を例示するが、限定することを意図しない。少なくともいくつかの実施形態では、分散型ロードバランサの様々な構成要素は、汎用ラックマウント型コンピューティングデバイス上にまたはそれとして実装することができる。ラック１９０は、各々がロードバランサノード（ＬＢノード１１０Ａ〜１１０Ｆ）として機能する複数のコンピューティングデバイス、及び各々がサーバノード（サーバノード１３０Ａ〜１３０Ｌ）として機能する複数のコンピューティングデバイスを含むことができる。ラック１９０はまた、少なくとも１つのエッジルータ１０４、ファブリック１２０を形成する１つ以上のラックマウント型ネットワーキングデバイス（ルータ、スイッチなど）、及び１つ以上の他の構成要素１８０（他のネットワーキングデバイス、パッチパネル、電源、冷却システム、バスなど）を含むことができる。データセンタまたは図３３Ａ及び３３Ｂのプロバイダネットワーク１９００を実装するセンタのようなネットワーク１００設備は、１つ以上のラック１９０を含むことができる。

図３４Ｂは、少なくともいくつかの実施形態に従って、分散型ロードバランサ及びサーバノードの別の例となる物理的ラック実現形態を例示するが、限定することを意図しない。図３４Ｂは、ラック１９０内にスロットマウント型コンピューティングデバイス、例えばブレードサーバとして実装されたＬＢノード１１０及びサーバノード１３０を示す。

図３５は、少なくともいくつかの実施形態に従って、１つ、２つ以上の分散型ロードバランサが、分離して実装されたサーバノードと共に、ネットワークに実装することができる例となるネットワーキング環境を例示する。この実施例では、２つの分散型ロードバランサ１９８０Ａ及び１９８０Ｂが示される。分散型ロードバランサ１９８０は、各々クライアント１９６０からのパケットフローを、ボーダーネットワークを介して受け取り、本明細書に記載のロードバランシング方法を行い、パケットフローを複数のサーバノード１９９０に分配することができる。いくつかの実現形態では、各々の分散型ロードバランサ１９８０は、図３４Ａ及び３４Ｂに示されるラック１９０と同様なラック型実現形態であることができるが、ロードバランサラックに組み込まれたサーバノードを備えない。サーバノード１９９０は、データセンタ内の１つ以上の別々のラックに組み込まれたブレードサーバのようなラックマウント型コンピューティングデバイスであってもよい。いくつかの実現形態では、サーバノード１９９０は、プロバイダネットワークによって提供される２つ以上の様々なサービスを実装することができ、各々のサービスは異なる１つ以上のロードバランサ１９８０を前段に備える。

例示のシステム
少なくともいくつかの実施形態では、本明細書に記載の分散型ロードバランシング方法及び装置の一部または全部を実装するサーバは、図３６に例示されるコンピュータシステム２０００のような１つ以上のコンピュータアクセス可能媒体を含む、またはそれにアクセスするように構成される汎用コンピュータシステムを含むことができる。例示の実施形態では、コンピュータシステム２０００は、入力／出力（Ｉ／Ｏ）インターフェース２０３０を介してシステムメモリ２０２０の結合された１つ以上のプロセッサ２０１０を含む。コンピュータシステム２０００は、Ｉ／Ｏインターフェース２０３０に結合されたネットワークインターフェース２０４０を更に含む。

様々な実施形態では、コンピュータシステム２０００は、１つのプロセッサ２０１０を含むユニプロセッサシステム、またはいくつかのプロセッサ２０１０（例えば、２つ、４つ、８つ、または別の適切な数）を含むマルチプロセッサシステムであることができる。プロセッサ２０１０は、命令を実行できる任意の適切なプロセッサであることができる。例えば、様々な実施形態では、プロセッサ２０１０は、ｘ８６、ＰｏｗｒｅＰＣ、ＳＰＡＲＣ、またはＭＩＰＳ ＩＳＡ若しくは任意の他の適切なＩＳＡのような様々な命令セットアーキテクチャ（ＩＳＡ）のいずれかを実装する汎用または埋め込み型プロセッサであることができる。マルチプロセッサシステムでは、プロセッサ２０１０の各々は、一般的に、必ずしもではないが、同じＩＳＡを実装することができる。

システムメモリ２０２０は、プロセッサ（複数可）２０１０によってアクセス可能な命令及びデータを格納するように構成することができる。様々な実施形態では、システムメモリ２０２０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、同期ダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュ型メモリ、または任意の他のタイプのメモリのような任意の適切なメモリ技術を使用して実装することができる。例示された実施形態では、分散型ロードバランシング方法及び装置について上述したそれらの方法、技術、及びデータのような１つ以上の所望の機能を実装するプログラム命令及びデータは、システムメモリ２０２０内にコード２０２４及びデータ２０２６として格納されて示される。

一実施形態では、Ｉ／Ｏインターフェース２０３０は、プロセッサ２０１０、システムメモリ２０２０、及びネットワークインターフェース２０４０または他の周辺インターフェースを含むデバイス内の任意の周辺デバイス間でＩ／Ｏトラフィックを調整するように構成することができる。いくつかの実施形態では、Ｉ／Ｏインターフェース２０３０は、任意の必要なプロトコル、タイミング、または他のデータ変換を行い、１つの構成要素（例えば、システムメモリ２０２０）からのデータ信号を別の構成要素（例えば、プロセッサ２０１０）による使用に適するフォーマットに変換することができる。いくつかの実施形態では、Ｉ／Ｏインターフェース２０３０は、例えば周辺構成要素相互接続（ＰＣＩ）バス規格、またはユニバーサルシリアルバス「ＵＳＢ」規格の変種のような様々なタイプの周辺バスを介して取り付けられたデバイスのためのサポートを含むことができる。いくつかの実施形態では、Ｉ／Ｏインターフェース２０３０の機能は、例えばノースブリッジ及びサウスブリッジのような２つ以上の別々の構成要素に分割することができる。更に、いくつかの実施形態では、システムメモリ２０２０へのインターフェースのようなＩ／Ｏインターフェース２０３０の機能は、プロセッサ２０１０に直接に組み込むことができる。

ネットワークインターフェース２０４０は、コンピュータシステム２０００と例えば、図１〜３５に例示されたような他のコンピュータシステムまたはデバイスのようなネットワークまたはネットワーク（複数）２０５０に取り付けられた他のデバイス２０６０との間で、データの交換を可能にするように構成することができる。様々な実施形態では、ネットワークインターフェース２０４０は、例えばイーサネットネットワークのタイプのような任意の適切な有線または無線汎用データネットワークを介する通信をサポートすることができる。更に、ネットワークインターフェース２０４０は、アナログ音声ネットワークまたはデジタルファイバ通信ネットワークのような通信／電話ネットワークを介する、ファイバチャネルＳＡＮのようなストレージエリアネットワークを介する、または任意の他の適切なタイプのネットワーク及び／若しくはプロトコルを介する、通信をサポートすることができる。

いくつかの実施形態では、システムメモリ２０２０は、分散型ロードバランシングシステムの実施形態を実装するために図１〜３５について上述したプログラム命令及びデータを格納するように構成されたコンピュータアクセス可能媒体の一実施形態であることができる。しかしながら、他の実施形態では、プログラム命令及び／またはデータは、受け取られ、送信され、または異なるタイプのコンピュータアクセス可能媒体に格納することができる。一般的に、コンピュータアクセス可能媒体は、磁気または光学的媒体のような非一時的ストレージ媒体またはメモリ媒体、例えば、Ｉ／Ｏインターフェース２０３０を介してコンピュータシステム２０００に結合されたディスクまたはＤＶＤ／ＣＤを含むことができる。非一時的コンピュータアクセス可能ストレージ媒体はまた、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどのような任意の揮発性または不揮発性媒体を含むことができ、それらは、システムメモリ２０２０または別のタイプのメモリとしてコンピュータシステム２０００のいくつかの実施形態に含めることができる。更に、コンピュータアクセス可能媒体は、ネットワークインターフェース２０４０を介して実装することができるようなネットワーク及び／または無線リンクのような通信媒体を介して搬送される電気的、電磁気的、またはデジタル信号のような伝送媒体または信号を含むことができる。

開示の実施形態は以下の付記の観点で説明することができる。
１．複数のロードバランサノードと、
各々がロードバランサモジュール及びサーバを実装する複数のサーバノードと、
１つ以上のクライアントからのパケットフローを複数のロードバランサノードに分散するように動作可能なルータと、を備え、
ロードバランサノードが、パケットフローを複数のロードバランサモジュールのうちの選択されたものに分散するように動作可能であり、
各々のロードバランサモジュールが、
１つ以上のパケットフロー内のロードバランサノードから受け取ったパケットを、それぞれのサーバノードのサーバに送ることであって、１つ以上のパケットフローの各々が、パケットフローのためにサーバと送信元クライアントとの間に確立された１つ以上の接続のうちの１つに対応する、送ることと、
１つ以上のアクティブな接続の各々に関する状態情報を、サーバから収集することと、
１つ以上のアクティブな接続に関する収集された状態情報を、接続公開パケットとして、複数のロードバランサノードのうちの少なくとも１つに公開することと、を行うように動作可能である、分散型ロードバランサシステム。
２．収集及び公開が、指定された間隔で行われる、付記１に記載の分散型ロードバランサシステム。
３．各々のロードバランサノードが、
接続公開パケットをロードバランサモジュールから受け取り、
接続公開パケット内の状態情報を有する各々の接続について、
接続に関する状態情報を分析し、状態情報に対応する１つ以上の対象となるロードバランサノードを決定し、かつ
接続に関する状態情報を決定された１つ以上の対象となるロードバランサノードに転送するように、更に動作可能である、付記１に記載の分散型ロードバランサシステム。
４．各々のロードバランサノードが、
少なくとも１つの接続に関する状態情報をキャッシュし、かつ
ロードバランサモジュールによって公開された接続公開パケット内の状態情報に従って、キャッシュされた状態情報を更新する、ように更に動作可能であり、ロードバランサノードの所与の接続に関するキャッシュされた状態情報の更新が、ロードバランサノードの接続のリース期間を更新する、付記１に記載の分散型ロードバランサシステム。
５．各々のロードバランサノードが、接続に関するキャッシュされた状態情報が少なくとも指定された期間にわたって更新されていないことを決定することにより、接続のリース期間の有効期限が切れていることを決定するように更に動作可能である、付記４に記載の分散型ロードバランサシステム。
６．１つ以上のアクティブな接続に関する収集された状態情報を接続公開パケットとして複数のロードバランサノードのうちの少なくとも１つに公開するために、各々ロードバランサモジュールが、少なくとも１つのロードバランサノードを、複数のロードバランサノードのうちから無作為に選択するように動作可能である、付記１に記載の分散型ロードバランサシステム。
７．各々が複数のサーバノードのうちの別個の１つに実装された複数のロードバランサモジュールの各々によって、
それぞれのサーバノードのサーバと複数のクライアントのうちの１つとの間の１つ以上のアクティブな接続の各々に関する状態情報を収集すること、及び
１つ以上のアクティブな接続に関する収集された状態情報を、接続公開パケットとして、複数のロードバランサノードのうちの少なくとも１つに公開すること、を行うことと、
接続公開パケット内の収集された状態情報に従って、複数のロードバランサノードの各々の接続に関するキャッシュされた状態情報を更新することと、を含む、方法。
８．収集及び公開が、指定された間隔で行われる、付記７に記載の方法。
９．複数のロードバランサノードによって、パケットフローをクライアントから複数のロードバランサモジュールのうちの選択されたものに分散することを更に含み、パケットフローの各々が、接続のうちの１つに対応する、付記７に記載の方法。
１０．１つ以上のロードバランサモジュールの各々によって、１つ以上のパケットフロー内のロードバランサノードから受け取ったパケットを、それぞれのサーバノードのサーバに送ることを更に含み、１つ以上のパケットフローの各々が、サーバとパケットフローの送信元クライアントとの間に確立された１つ以上の接続のうちの１つに対応する、付記９に記載の方法。
１１．接続公開パケット内の収集された状態情報に従う、複数のロードバランサノードの各々の接続に関するキャッシュされた状態情報の前記更新が、
ロードバランサノードによって、接続公開パケットをロードバランサモジュールから受け取ることと、
接続公開パケット内の状態情報に対応する対象となるロードバランサノードを決定することと、
接続公開パケット内の収集された状態情報を、状態情報に対応する決定された対象となるロードバランサノードに従って、２つ以上のパケットに分割することと
２つ以上のパケットを対象となるロードバランサノードに転送することと、を含む、付記７に記載の方法。
１２．所与の接続の対象となるロードバランサノードが、それぞれのパケットフローのための入口サーバとして機能するロードバランサノード及びそれぞれのパケットフローのためのフロートラッカーとして機能する少なくとも１つのロードバランサノードを含み、入口サーバが、パケットフロー内のパケットをルータから受け取り、パケットをパケットフローにマッピングされたサーバノードに転送し、かつパケットフローのためのフロートラッカーが、パケットフローに関する状態情報を維持するロードバランサノードである、付記１１に記載の方法。
１３．ロードバランサノードの所与の接続に関するキャッシュされた状態情報の更新が、ロードバランサノードの接続のリース期間を更新する、付記７に記載の方法。
１４．接続に関連するキャッシュされた状態情報が少なくとも指定された期間にわたって更新されていないことを決定することにより、ロードバランサノードが、ロードバランサノードの接続に関するリース期間の有効期限が切れていることを決定することを更に含む、付記７に記載の方法。
１５．各々のロードバランシングモジュールが、接続公開パケットを公開すべきである少なくとも１つのロードバランサノードを無作為に決定する、付記７に記載の方法。
１６．複数のサーバノードの各々のロードバランサモジュールを実装するようにコンピュータ実行可能なプログラム命令を格納し、サーバノードのロードバランサモジュールが、
それぞれのサーバノードのサーバと複数のクライアントのうちの１つとの間の１つ以上のアクティブな接続の各々に関する状態情報を収集し、かつ
１つ以上のアクティブな接続に関する収集された状態情報を、接続公開パケットとして複数のロードバランサノードのうちの少なくとも１つに公開するように動作可能であり、
公開された状態情報が、複数のロードバランサノードの接続に関するキャッシュされた状態情報を更新し、ロードバランサノード上で所与の接続に関するキャッシュされた状態情報を更新することが、ロードバランサノードの接続のリース期間を更新する、非一時的コンピュータアクセス可能ストレージ媒体。
１７．収集及び公開が、指定された間隔で各々のロードバランサモジュールによって行われる、付記１６に記載の非一時的コンピュータアクセス可能ストレージ媒体。
１８．サーバノードのロードバランサモジュールが、１つ以上のパケットフロー内のロードバランサノードから受け取ったパケットを、それぞれのサーバノードのサーバに送るように更に動作可能であり、１つ以上のパケットフローの各々が、サーバとパケットフローのための送信元クライアントとの間に確立された１つ以上の接続のうちの１つに対応する、付記１６に記載の非一時的コンピュータアクセス可能ストレージ媒体。
１９．プログラム命令が、複数のロードバランサノードの各々で、
接続公開パケットをロードバランサモジュールから受け取ることと、
接続公開パケット内の状態情報に対応する対象となるロードバランサノードを決定することと、
接続公開パケット内の収集された状態情報を、状態情報に対応する決定された対象となるロードバランサノードに従って、２つ以上のパケットに分割することと、
２つ以上のパケットを対象となるロードバランサノードに転送することと、を実装するように更にコンピュータ実行可能である、付記１６に記載の非一時的コンピュータアクセス可能ストレージ媒体。
２０．各々のロードバランシングモジュールが、接続公開パケットを公開する少なくとも１つのロードバランサノードを無作為に決定する、付記１６に記載の非一時的コンピュータアクセス可能ストレージ媒体。

結論
様々な実施形態は、コンピュータアクセス可能媒体上の前述の記載に従って実装される命令及び／またはデータを、受け取ること、送ること、または格納することを更に含むことができる。一般的に言えば、コンピュータアクセス可能媒体は、磁気若しくは光媒体、例えばディスク若しくはＤＶＤ／ＣＤ−ＲＯＭ、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどのような揮発性若しくは不揮発性媒体のようなストレージ媒体またはメモリ媒体、並びに伝送媒体、または、ネットワーク及び／若しくは無線リンクのような通信媒体を介して搬送される電気的、電磁気的、またはデジタル信号などの信号、を含むことができる。

図に例示された及び本明細書に記載された様々な方法は、方法の例示の実施形態を表す。方法は、ソフトウェア、ハードウェア、またはそれらの組み合わせで実装することができる。方法の順序は、変更することができ、様々な要素は、追加、並べ替え、組み合わせ、省略、変更などが可能である。

様々な変更及び改変は、本開示に利益を有する当業者には明らかであるように、行うことが可能である。全てのそのような変更及び改変を包含することを意図し、したがって、上記の説明は、限定的ではなく例示的であるとみなされるべきである。

Claims (15)

1. 複数のロードバランサノードと、
   各々がロードバランサモジュール及びサーバを実装する複数のサーバノードと、
   １つ以上のクライアントからのパケットフローを前記複数のロードバランサノードに分散するように動作可能なルータと、を備え、
   前記ロードバランサノードが、前記パケットフローを前記複数のロードバランサモジュールのうちの選択されたものに分散するように動作可能であり、
   各々のロードバランサモジュールが、
   １つ以上のパケットフロー内の前記ロードバランサノードから受け取ったパケットを、前記それぞれのサーバノードの前記サーバに送ることであって、前記１つ以上のパケットフローの各々が、パケットフローのために前記サーバと送信元クライアントとの間に確立された１つ以上の接続のうちの１つに対応する、送ることと、
   １つ以上のアクティブな接続の各々に関する状態情報を、前記サーバから収集することと、
   前記１つ以上のアクティブな接続に関する前記収集された状態情報を、接続公開パケットとして、前記複数のロードバランサノードのうちの少なくとも１つに公開することと、を行うように動作可能である、分散型ロードバランサシステム。
2. 前記収集及び前記公開が、指定された間隔で行われる、請求項１に記載の前記分散型ロードバランサシステム。
3. 各々のロードバランサノードが、
   接続公開パケットをロードバランサモジュールから受け取り、
   前記接続公開パケット内の状態情報を有する各々の接続について、
   前記接続に関する前記状態情報を分析し、前記状態情報に対応する１つ以上の対象となるロードバランサノードを決定し、かつ
   前記接続に関する状態情報を前記決定された１つ以上の対象となるロードバランサノードに転送するように、更に動作可能である、請求項１に記載の前記分散型ロードバランサシステム。
4. 各々のロードバランサノードが、
   少なくとも１つの接続に関する状態情報をキャッシュし、かつ
   前記ロードバランサモジュールによって公開された前記接続公開パケット内の前記状態情報に従って、前記キャッシュされた状態情報を更新する、ように更に動作可能であり、前記ロードバランサノードの所与の接続に関する前記キャッシュされた状態情報の更新が、前記ロードバランサノードの前記接続のリース期間を更新する、請求項１に記載の前記分散型ロードバランサシステム。
5. 各々のロードバランサノードが、前記接続に関する前記キャッシュされた状態情報が少なくとも指定された期間にわたって更新されていないことを決定することにより、接続の前記リース期間の有効期限が切れていることを決定するように更に動作可能である、請求項４に記載の前記分散型ロードバランサシステム。
6. 前記１つ以上のアクティブな接続に関する前記収集された状態情報を接続公開パケットとして前記複数のロードバランサノードのうちの少なくとも１つに公開するために、各々のロードバランサモジュールが、前記少なくとも１つのロードバランサノードを、前記複数のロードバランサノードのうちから無作為に選択するように動作可能である、請求項１に記載の前記分散型ロードバランサシステム。
7. 各々が複数のサーバノードのうちの別個の１つに実装された複数のロードバランサモジュールの各々によって、
   前記それぞれのサーバノードのサーバと複数のクライアントのうちの１つとの間の１つ以上のアクティブな接続の各々に関する状態情報を収集すること、及び
   前記１つ以上のアクティブな接続に関する前記収集された状態情報を、接続公開パケットとして、複数のロードバランサノードのうちの少なくとも１つに公開すること、を行うことと、
   前記接続公開パケット内の前記収集された状態情報に従って、前記複数のロードバランサノードの各々の前記接続に関するキャッシュされた状態情報を更新することと、を含む、方法。
8. 前記収集及び前記公開が、指定された間隔で行われる、請求項７に記載の前記方法。
9. 前記複数のロードバランサノードによって、パケットフローを前記クライアントから前記複数のロードバランサモジュールのうちの選択されたものに分散することを更に含み、前記パケットフローの各々が、前記接続のうちの１つに対応する、請求項７に記載の前記方法。
10. 前記１つ以上のロードバランサモジュールの各々によって、１つ以上のパケットフロー内の前記ロードバランサノードから受け取ったパケットを、前記それぞれのサーバノードの前記サーバに送ることを更に含み、前記１つ以上のパケットフローの各々が、前記サーバと前記パケットフローの送信元クライアントとの間に確立された１つ以上の接続のうちの１つに対応する、請求項９に記載の前記方法。
11. 前記接続公開パケット内の前記収集された状態情報に従う、前記複数のロードバランサノードの各々の前記接続に関するキャッシュされた状態情報の前記更新が、
    ロードバランサノードによって、接続公開パケットをロードバランサモジュールから受け取ることと、
    前記接続公開パケット内の前記状態情報に対応する対象となるロードバランサノードを決定することと、
    前記接続公開パケット内の前記収集された状態情報を、前記状態情報に対応する前記決定された対象となるロードバランサノードに従って、２つ以上のパケットに分割することと、
    前記２つ以上のパケットを前記対象となるロードバランサノードに転送することと、を含む、請求項７に記載の前記方法。
12. 所与の接続の前記対象となるロードバランサノードが、前記それぞれのパケットフローのための入口サーバとして機能するロードバランサノード、及び前記それぞれのパケットフローのためのフロートラッカーとして機能する少なくとも１つのロードバランサノードを含み、入口サーバが、前記パケットフロー内のパケットをルータから受け取り、前記パケットを前記パケットフローにマッピングされたサーバノードに転送し、パケットフローのためのフロートラッカーが、前記パケットフローに関する状態情報を維持するロードバランサノードである、請求項１１に記載の前記方法。
13. ロードバランサノードの所与の接続に関する前記キャッシュされた状態情報の更新が、前記ロードバランサノードの前記接続のリース期間を更新する、請求項７に記載の前記方法。
14. 前記接続に関するキャッシュされた状態情報が少なくとも指定された期間にわたって更新されていないことを決定することにより、ロードバランサノードが、前記ロードバランサノードの接続に関するリース期間の有効期限が切れていることを決定することを更に含む、請求項７に記載の前記方法。
15. 各々のロードバランシングモジュールが、前記接続公開パケットを公開すべきである前記少なくとも１つのロードバランサノードを無作為に決定する、請求項７に記載の前記方法。

Images