特許 6194100 分散型ロードバランサ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6194100

(24)【登録日】2017年8月18日

(45)【発行日】2017年9月6日

(54)【発明の名称】分散型ロードバランサ

(51)【国際特許分類】

   H04L 12/803 20130101AFI20170828BHJP

   G06F 13/00 20060101ALI20170828BHJP

【ＦＩ】

   H04L12/803

   G06F13/00 357Z

【請求項の数】14

【全頁数】78

(21)【出願番号】特願2016-509084(P2016-509084)

(86)(22)【出願日】2014年4月16日

(65)【公表番号】特表2016-518081(P2016-518081A)

(43)【公表日】2016年6月20日

(86)【国際出願番号】US2014034428

(87)【国際公開番号】WO2014172500

(87)【国際公開日】20141023

【審査請求日】2015年12月8日

(31)【優先権主張番号】13/864,167

(32)【優先日】2013年4月16日

(33)【優先権主張国】US

【前置審査】

(73)【特許権者】

【識別番号】507303550

【氏名又は名称】アマゾン・テクノロジーズ・インコーポレーテッド

(74)【代理人】

【識別番号】100098394

【弁理士】

【氏名又は名称】山川 茂樹

(72)【発明者】

【氏名】ソレンソン，ザ サード，ジェームズ・クリストファー

(72)【発明者】

【氏名】ローレンス，ダグラス・スチュワート

(72)【発明者】

【氏名】スリニヴァサン，ヴェンカトラガヴァン

(72)【発明者】

【氏名】ヴァイジャ，アクシャイ・スハス

(72)【発明者】

【氏名】チャン，ファン

【審査官】 速水 雄太

(56)【参考文献】

【文献】 特開２０１２−０４４６２３（ＪＰ，Ａ）

【文献】 特開２００３−１３１９６１（ＪＰ，Ａ）

【文献】 国際公開第２００４／０８８９４０（ＷＯ，Ａ１）

【文献】 特開２００３−１５２７２９（ＪＰ，Ａ）

【文献】 特開２０１１−１８２０７０（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００５／０２８１２０５（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１１／０１６１９８０（ＵＳ，Ａ１）

【文献】 特開２００６−１９５９０４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／８０３

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

分散型ロードバランサシステムであって、
複数のロードバランサノード、及び
各々がサーバ及びロードバランサモジュールを有する複数のサーバノードを備え、その中で、
前記複数のロードバランサノードは、１以上のクライアントからのデータ通信プロトコルのパケットフローを前記複数のサーバノードの中に分散し、且つ、前記パケットフローを前記複数のサーバノードの中に分散するために、
前記複数のロードバランサノードは、前記クライアントからの前記パケットフローに対する接続要求を受信するために前記複数のサーバノードの中からサーバノードをランダムに選択し、前記選択されたサーバノードに対して前記接続要求を送信する、
ように構成され、
各サーバノード上の前記ロードバランサモジュールは、前記複数のロードバランサノードの１つからのパケットフローに対する接続要求を受信し、且つ、前記サーバノード上の前記サーバによって各前記パケットフローに対するデータ通信プロトコル接続が受諾されるかどうかを判定し、前記サーバが前記データ通信プロトコル接続を受諾できない場合には、前記接続要求を拒絶し、前記サーバが前記データ通信プロトコル接続を受諾することができる場合には、前記複数のロードバランサノードと協働して前記それぞれのクライアントと前記それぞれのサーバとの間で前記データ通信プロトコル接続を確立するように構成され、
各サーバノード上の前記ロードバランサモジュールはさらに、
前記それぞれのクライアントと前記それぞれのサーバとの間の前記パケットフローのためのデータ通信プロトコル接続を確立した後、
前記データ通信プロトコル接続のための出口サーバとして動作するための前記複数のロードバランサノードのうちの１つを選択し、
前記ロードバランサノードのうちの１つからの、前記データ通信プロトコル接続のための着信データ通信プロトコルパケットを受信し、前記着信データ通信プロトコルパケットを前記サーバノード上の前記サーバに送信し、
前記データ通信プロトコル接続のための発信データ通信プロトコルパケットを中断し、前記発信データ通信プロトコルパケットを前記選択された出口サーバに、前記それぞれのクライアントへ配送するために送信するように構成されている、
前記分散型ロードバランサシステム。

【請求項2】

さらに、ハッシュ化マルチパス・ルーティング技法に従って、前記１以上のクライアントからの前記パケットフローを前記複数のロードバランサノードの中に分散するように構成されたルータをさらに備える、
請求項１に記載の分散型ロードバランサシステム。

【請求項3】

前記サーバノード上の前記サーバによって各前記パケットフローに対するデータ通信プロトコル接続が受諾されるかどうかを判定するために、前記ロードバランサモジュールが、前記サーバノード上の前記サーバの１以上の現在の資源使用量のメトリクスを分析して、前記接続を前記サーバが受諾できるかどうかを判定するように構成され、前記１以上の現在の資源の使用量のメトリクスが、ＣＰＵの使用、帯域幅の使用量、サーバ待ち時間、及び確立された接続数のうちの１以上を含む、
請求項１に記載の分散型ロードバランサシステム。

【請求項4】

前記複数のロードバランサノードが、さらに、拒絶された接続要求を受信するために前記複数のサーバノードの中から、他のサーバノードをランダムに選択し、前記接続要求を前記他のサーバノードに対して送信するように構成されている、
請求項１に記載の分散型ロードバランサシステム。

【請求項5】

クライアントとサーバとの間で確立された各データ通信プロトコル接続が、前記クライアントに始まり、前記複数のロードバランサノードの１以上の中を通って、前記サーバによって終端される、
請求項１に記載の分散型ロードバランサシステム。

【請求項6】

クライアントに対するパケットフローにおけるデータ通信プロトコルのパケットを受信することと、
前記パケットフローについての接続要求を複数のサーバノードの中からランダムに選択されたサーバノードに対して送信することとを、
複数のロードバランサノードの１以上によって実行することと、
前記サーバノード上のサーバが各前記パケットフローに対するデータ通信プロトコル接続を受諾できるかまたはできないかどうかを判定することと、
前記サーバが前記データ通信プロトコル接続を受諾できないと判定したときは前記接続要求を拒絶することと、
前記サーバが前記データ通信プロトコル接続を受諾できると判定したときは前記接続要求を受諾することとを、
前記選択されたサーバノードによって実行することと、を含み、
前記接続要求を受諾することは、
前記パケットフローについての前記それぞれのクライアントと前記それぞれのサーバとの間で前記データ通信プロトコル接続を確立するために、前記１以上のロードバランサノードが協働することと、
前記それぞれのクライアントと前記それぞれのサーバとの間の前記パケットフローのための前記データ通信プロトコル接続を確立した後、前記データ通信プロトコル接続のための出口サーバとして動作するための前記複数のロードバランサノードのうちの１つを選択し、前記データ通信プロトコル接続における発信データ通信プロトコルパケットは前記選択された出口サーバを介して前記それぞれのクライアントへ配送されることと、を含む方法。

【請求項7】

前記確立された接続がクライアントに始まり、前記複数のロードバランサノードの１つの中を通って、前記サーバによって終端される、請求項６に記載の方法。

【請求項8】

１以上のクライアントからのパケットフローをハッシュ化マルチパス・ルーティング技法に従って前記複数のロードバランサノードの中に分散するルータから前記パケットが受信される、請求項６に記載の方法。

【請求項9】

前記サーバノード上のサーバがデータ通信プロトコル接続を受諾できるかまたはできないかどうかを前記判定することが、前記サーバの１以上の現在の資源使用量のメトリクスを分析して前記接続を受諾できるかどうかを判定することを含む、請求項６に記載の方法。

【請求項10】

前記選択されたサーバノードが前記接続要求を拒絶した場合に、前記１以上のロードバランサノードが、前記複数のサーバノードの中からランダムに選択された他のサーバノードに対して前記接続要求を送信することをさらに含む、請求項６に記載の方法。

【請求項11】

ロードバランサシステムであって、
複数のサーバノードの各々がサーバ及びロードバランサモジュールを備え、前記ロードバランサモジュールが、
クライアントからのパケットフローについての接続要求を複数のロードバランサノードの１つから受信し、前記ロードバランサモジュールを含む前記サーバノードは前記ロードバランサノードによって前記接続要求を受信するためにランダムに選択され、
前記サーバノード上の前記サーバが各前記パケットフローに対するデータ通信プロトコル接続を受諾できるかまたはできないかどうかを判定し、
前記サーバが前記データ通信プロトコル接続を受諾できないと判定したときは前記接続要求を拒絶し、及び
前記サーバが前記データ通信プロトコル接続を受諾できると判定したときは前記ロードバランサノードと前記サーバとが通信して、前記クライアントと前記サーバとの間に前記データ通信プロトコル接続を確立する、
ように構成され、
各サーバノード上の前記ロードバランサモジュールはさらに、
前記クライアントと前記サーバとの間の前記パケットフローのためのデータ通信プロトコル接続を確立した後、
前記データ通信プロトコル接続のための出口サーバとして動作するための前記複数のロードバランサノードのうちの１つを選択し、
前記ロードバランサノードのうちの１つからの、前記データ通信プロトコル接続のための着信データ通信プロトコルパケットを受信し、前記着信データ通信プロトコルパケットを前記サーバノード上の前記サーバに送信し、
前記データ通信プロトコル接続のための発信データ通信プロトコルパケットを中断し、前記発信データ通信プロトコルパケットを前記選択された出口サーバに、前記クライアントへ配送するために送信するように構成されている、
前記ロードバランサシステム。

【請求項12】

前記サーバノード上のサーバがデータ通信プロトコル接続を受諾できるかまたはできないかどうかを判定するために、前記ロードバランサモジュールが、前記サーバの１以上の現在の資源使用量のメトリクスを分析して、前記サーバが前記接続を受諾できるかどうかを決定することを実行できる、請求項１１に記載のロードバランサシステム。

【請求項13】

前記１以上の現在の資源使用量のメトリクスが、１以上のＣＰＵの使用、帯域幅の使用量、サーバ待ち時間、及び確立された接続数を含む、請求項１２に記載のロードバランサシステム。

【請求項14】

前記接続要求を拒絶するために、前記接続要求の中の生存時間（ＴＴＬ）カウンタを減じて、前記接続要求を前記ロードバランサノードに対して返送するように前記ロードバランサモジュールが動作でき、前記プログラム命令は、さらに、前記ロードバランサノードが、
前記返送された接続要求の中の前記ＴＴＬカウンタを検査し、
前記ＴＴＬカウンタが閾値を超えている場合には、前記接続要求を受信するために前記複数のサーバノードの中から他のサーバノードをランダムに選択し、及び
前記ＴＴＬカウンタが前記閾値以下である場合には、前記接続要求を廃棄することを実現するようにコンピュータを実行可能にする、請求項１１に記載のロードバランサ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、分散型ロードバランサに関する。

【背景技術】

【0002】

従来のロードバランサは、通常、単一且つ専用のボックスで、多数のネットワーク・インターフェイス制御部（ＮＩＣ）、例えば８個のＮＩＣを有し、いくつかのＮＩＣはクライアントとの間でインバウンドトラフィックやアウトバウンドトラフィックを取り扱い、他のＮＩＣは負荷分散されているホスト装置（例えば、ウェブサーバなどのサーバ）との間でアウトバウンドトラフィックやインバウンドトラフィックを取り扱う。これら従来のロードバランサにおける帯域幅またはスループットは、通常、クライアント側においても４０ギガビット／秒（Ｇｂｐｓ）及びサーバ側においても４０Ｇｂｐｓの範囲内である。クラウド・コンピュータ・サービスなどのネットワークベースのアプリケーション及びネットワークベースのサービスの規模や範囲は増加してきているので、データセンターは、負荷分散をするためのホスト装置（例えば、ウェブサーバ）を数百ないし数千に達するまで収容するようになっていく。従来のロードバランサはこのような環境にうまくスケールを変更することができない。

【0003】

さらに、従来のロードバランサは、ホスト装置から収集したデータに対して、通常、最大接続（またはｍａｘ ｃｏｎｎｓ）、ラウンド・ロビン、及び／または最小の接続（ｌｅａｓｔ ｃｏｎｎｓ）などの技法を使用して、接続を取り扱ういずれかのホスト装置を選択する。また、従来のロードバランサは、クライアントからの接続（例えば、伝送制御プロトコル（ＴＣＰ）接続）を受けて、それゆえ終了させるホスト装置に対して、通常、プロキシとしての機能を果たし、ホスト装置とロードバランサとの間で確立されたＴＣＰ接続上でクライアントトラフィックをホスト装置に送信する。したがって、これら従来のロードバランサを使用した場合に、ホスト装置とクライアントとは直接のＴＣＰ接続によっては通信しない。

【図面の簡単な説明】

【0004】

【図1】少なくともいくつかの実施形態において、分散型ロードバランシングシステムの実施例のブロック図である。

【図2】少なくともいくつかの実施形態において、図１の分散型ロードバランサシステムによって実施されるロードバランシング方法の上位のフローチャートである。

【図3】少なくともいくつかの実施形態において、入口、出口及びフロー追跡部の構成要素を有するロードバランサノードの実施例を示す。

【図4】少なくともいくつかの実施形態において、分散型ロードバランサ内のルーティング及びパケットフローを示す。

【図5】少なくともいくつかの実施形態において、エッジルータに対して広告している入口ノードを示す。

【図6】少なくともいくつかの実施形態において、マルチパス・ルーティング方法のフローチャートである。

【図7】少なくともいくつかの実施形態において、非対称のパケットフローをグラフィカルに示す。

【図8】少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。

【図9A】少なくともいくつかの実施形態において、分散型ロードバランシングシステム内で接続を確立した場合のパケットフローのフローチャートを提供する。

【図9B】少なくともいくつかの実施形態において、分散型ロードバランシングシステム内で接続を確立した場合のパケットフローのフローチャートを提供する。

【図10A】少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。

【図10B】少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。

【図10C】少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。

【図10D】少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。

【図10E】少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。

【図10F】少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。

【図10G】少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。

【図11A】少なくともいくつかの実施形態において、ロードバランサノードのコンシステントハッシュリングにおけるメンバーシップに影響を与えるイベントの取り扱いを示す。

【図11B】少なくともいくつかの実施形態において、ロードバランサノードのコンシステントハッシュリングにおけるメンバーシップに影響を与えるイベントの取り扱いを示す。

【図11C】少なくともいくつかの実施形態において、ロードバランサノードのコンシステントハッシュリングにおけるメンバーシップに影響を与えるイベントの取り扱いを示す。

【図11D】少なくともいくつかの実施形態において、ロードバランサノードのコンシステントハッシュリングにおけるメンバーシップに影響を与えるイベントの取り扱いを示す。

【図12】少なくともいくつかの実施形態において、ヘルスチェック間隔に従って各ロードバランサノードによって実行されるヘルスチェック方法の上位のフローチャートである。

【図13】少なくともいくつかの実施形態において、他のロードバランサノードからロードバランサノードをヘルスチェックする方法を示す。

【図14】少なくともいくつかの実施形態において、１以上の他のロードバランサノードをヘルスチェックするロードバランサをグラフィカルに示す。

【図15】少なくともいくつかの実施形態において、サーバノードをヘルスチェックするロードバランサを示す。

【図16】少なくともいくつかの実施形態において、ロードバランサノード１１０によって維持される他のノードのヘルスの表示をグラフィカルに示す。

【図17】少なくともいくつかの実施形態において、各ロードバランサノードによって維持される健康情報を示す。

【図18A】少なくともいくつかの実施形態において、ロードバランサノードの障害の取り扱いを示す。

【図18B】少なくともいくつかの実施形態において、ロードバランサノードの障害の取り扱いを示す。

【図19A】少なくともいくつかの実施形態において、接続公開技法をグラフィカルに示す。

【図19B】少なくともいくつかの実施形態において、接続公開技法をグラフィカルに示す。

【図20】少なくともいくつかの実施形態において、各ロードバランサモジュールによって実行される接続公開方法の上位のフローチャートである。

【図21】少なくともいくつかの実施形態において、接続公開パケット内で受信されたアクティブな接続情報を目標のロードバランサノードに対して分散する方法のフローチャートである。

【図22】少なくともいくつかの実施形態において、接続公開パケット内で受信されたアクティブな接続情報を目標のロードバランサノードに対して分散する代替方法を示す。

【図23】少なくともいくつかの実施形態において、ロードバランサノードに対する例示的なソフトウェア・スタック・アーキテクチャを示す。

【図24】実施形態において使用されるコアパケット処理技術の態様を示す。

【図25】少なくともいくつかの実施形態において、ロードバランサノード上でデータフローを処理する例示的なマルチコア・パケット・プロセッサを示す。

【図26】少なくともいくつかの実施形態において、ロードバランサノード上でデータフローを処理する他の例示的なマルチコア・パケット・プロセッサを示す。

【図27】少なくともいくつかの実施形態において、ロードバランサノードのプロセスによる着信パケットの処理を示す。

【図28】少なくともいくつかの実施形態において、ロードバランサノードのプロセスによる発信パケットの処理を示す。

【図29】少なくともいくつかの実施形態において、生産環境の中で分散型ロードバランサを含むロードバランシングシステムを示す。

【図30】少なくともいくつかの実施形態において、単一のプロセスの中でまたは単一のプロセスとして多数の分散型ロードバランシングシステムの構成要素が構成され且つ実行されることを可能にするメッセージバスのメカニズムを組み込む分散型ロードバランサ試験システムを示す。

【図31】少なくともいくつかの実施形態において、メッセージバスのパケットアダプタ及びパケットパイプラインを示す。

【図32】少なくともいくつかの実施形態において、メッセージバスのパケットアダプタ及びパケットパイプラインを示す。

【図33A】少なくともいくつかの実施形態において、例示的なプロバイダ・ネットワーク環境を示す。

【図33B】少なくともいくつかの実施形態において、分散型ロードバランサの実装を図３３Ａにみられうようなプロバイダ・ネットワーク環境の例で示す。

【図34A】少なくともいくつかの実施形態において、分散型ロードバランサ及びサーバノードの例示的な物理的なラック実装を示す。

【図34B】少なくともいくつかの実施形態において、分散型ロードバランサ及びサーバノードの他の例示的な物理的なラック実装を示す。

【図35】少なくともいくつかの実施形態において、ネットワーク内に１つ、２つまたはそれより大きい分散型ロードバランサが実装された例示的なネットワーク環境を示す。

【図36】いくつかの実施形態において使用される例示的なコンピュータシステムを示すブロック図である。

【0005】

いくつかの実施形態及び説明図についての実施例として実施形態が本明細書に記載されるが、当業者であれば、記載された当該実施形態及び図面には実施形態が限定されないということを認識するであろう。図面及びそれについての詳細な記述は、開示された特定の形態に実施形態を限定する意図はなく、その反対に、添付された特許請求の範囲によって画定される趣旨及び範囲に包含される、すべての変形、等価物、及び代替に及ぶという意図であることを理解する必要がある。ここで使用された見出しは、構成上の目的のためのみであり、本明細書の範囲または特許請求の範囲を限定するために使用されるものではない。この出願を通して使用されるように、「ｍａｙ（〜する）」の用語は、強制的な意味（すなわち、しなければならない（ｍｕｓｔ）の意味）ではなく、許容的な意味（すなわち、可能性を持つの意味）に使用されている。同様に、「ｉｎｌｃｕｄｅ」、「ｉｎｃｌｕｄｉｎｇ」、「ｉｎｃｕｌｕｄｅｓ」の用語は含んでいることを意味し、制限する意味ではない。

【発明を実施するための形態】

【0006】

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

【0007】

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

【0008】

さらに、従来のロードバランサ技術において行われているように、サーバから収集された情報に適用されるロードバランシング技法またはアルゴリズムに基づいて、どのサーバが接続要求に対応するかに関してロードバランサノードが決定を下す代わりに、ロードバランサノードは、新たな接続要求を受信するサーバをランダムに選択して、当該サーバノード上に属する分散型ロードバランサの構成要素が、それぞれのサーバの現在の状態の１以上のメトリクスに基づいて、選択されたサーバが新たな接続要求を受理するかまたは拒絶するかどうかに関してローカルに決定を下す。したがって、どのサーバが接続要求を受理すべきかに関する決定は、ロードバランサノードから接続を取り扱うサーバノードに移管される。言い換えれば、決定は、接続要求が対応されるより近い場所及び時間に移管される。

【0009】

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

【0010】

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

【0011】

図２は、少なくともいくつかの実施形態において、図１の分散型ロードバランサシステムによって実行されるロードバランシング方法の上位のフローチャートである。分散型ロードバランサシステムの実施形態は、従来のロードバランサにおいて行われているような、多数の宛先（例えば、ウェブサーバ）の中に負荷を対応付けている困難な問題を解決することができない。例えば、従来のロードバランサは、一般的に、最大接続、ラウンド・ロビン、及び／または、最小接続の技法などの技法またはアルゴリズムを使用して、接続を取り扱うべきいずれかのサーバを選択する。しかしながら、これらの技法は欠点があり、特に、ロードバランシングの決定をするために使用されるデータがほとんど急速に古くなるようなことが多い場所での分散型システムにおいては特に成功裏に実行することが困難である。分散型ロードバランサシステムの少なくともいくつかの実施形態において、従来のロードバランサにおいて行われているような、１以上のロードバランシング技法を使用して、接続要求を満たすサーバノード１３０を選択する試みに代えて、ロードバランサノードレイヤにおけるロードバランサノード１１０が、クライアント接続のための要求を受信するサーバノード１３０をランダムに決定してもよい。サーバノード１３０が自身を過負荷であると判断した場合には、当該サーバノード１３０は接続要求をロードバランサノード１１０に送信して戻すので、当該サーバノード１３０が現在は接続を取り扱うことができないことをロードバランサノード１１０に通知する。ロードバランサノードレイヤは、次に、接続要求を受信すべき他のサーバノード１３０をランダムに決定するか、あるいは、要求しているクライアント１６０に対してエラーメッセージを返送して、接続が現在は確立できないことをクライアント１６０に通知する。

【0012】

図２の１０に示されるように、分散型ロードバランサシステムのロードバランサノードレイヤは、通信セッション（例えば、ＴＣＰ接続）についての要求を送信元から受信する。送信元は、例えば、分散型平衡器システムを実装するネットワーク１００に対する外部ネットワーク１５０上のクライアント１６０であってよい。少なくともいくつかの実施形態において、要求はネットワーク１００の境界ルータ１０２においてクライアント１６０から受信され、例えば、クライアント１６０からの特定の接続要求がルーティングされるロードバランサノード１１０を擬似ランダムに選択するためのフロー単位の等価マルチパス（ＥＣＭＰ）ハッシュ処理の技法を用いて、ロードバランサノードレイヤにおけるロードバランサ（ＬＢ）ノード１１０に対して着信パケットをルーティングするエッジルータ１０４に対してルーティングされる。

【0013】

２０に示されるように、ロードバランサノードレイヤは、宛先ノードをランダムに選択して、その選択された宛先ノードに接続要求を転送する。宛先ノードは、例えば、ロードバランサによって対応させられた複数のサーバノード１３０の１つであってよい。少なくともいくつかの実施形態において、ロードバランサレイヤにおけるロードバランサノード１１０は、すべての既知のサーバノード１３０の中から接続要求を受信すべきサーバノード１３０をランダムに選択してよい。しかしながら、すべての既知のサーバノード１３０の中からの単なるランダムな選択ではなく、いくつかの実施形態においては、接続要求を受信すべきサーバノード１３０を選択するために、他の方法が使用されてもよい。例えば、いくつかの実施形態において、サーバノード１３０に関する情報が、サーバノード１３０のランダムな選択の重みづけをするロードバランサノード１１０によって使用される。実施例のように、ロードバランサノード１１０が、異なるサーバノード１３０が異なるタイプの装置であるか、または、異なるＣＰＵで構成されており、そのため異なる能力または容量を持っていることを認識している場合には、サーバノード１３０の特定のタイプまたは構成に向かう（または、離れる）ようにランダムな選択に偏りを持たせるためにその情報が使用されてもよい。

【0014】

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

【0015】

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

【0016】

４０において、接続要求が受理されない場合には、７０に示されるように、宛先ノードはロードバランサノードレイヤに通知し、方法は要素２０に戻る。その後、ロードバランサノードレイヤは、２０において他の宛先ノードをランダムに選択するか、または、要求しているクライアント１６０に対して、現在は接続を確立することができない旨を通知することができる。クライアント１６０は、必ずしも接続要求を再実行する必要はなく、要素１０において再び方法を開始することに留意されたい。

【0017】

再び図１を参照すると、分散型ロードバランサシステムの少なくともいくつかの実施形態分散型は、汎用のハードウェアを使用して、ネットワーク１００上のエッジルータ１０４において受信されたクライアントトラフィックをネットワーク１００上のサーバノード１３０にルーティングする。分散型ロードバランサの少なくともいくつかの実施形態は、多数のロードバランサノード１１０を含むロードバランサノードレイヤを含んでもよい。少なくともいくつかの実施形態において、各ロードバランサノード１１０は、ロードバランサノードレイヤにおいて１以上の多数の役割を果たす。ロードバランサノード１１０のこれらの役割は、入口ノード、及び出口ノード、及びフロー追跡部ノード（所定のパケットフローに対する一次フロー追跡部または二次フロー追跡部として）を含む。少なくともいくつかの実施形態において、各ロードバランサノード１１０は、汎用のラック収容型演算装置などの独立した演算装置としてまたはその上で、ロードバランサノードレイヤの中に実装されてもよい。少なくともいくつかの実施形態において、各ロードバランサノード１１０は、入口ノード、出口ノード、及びフロー追跡部ノード（パケットフローに対する一次または二次フロー追跡部として）の３つの役割の各々を果たすが、通常は、ロードバランサノード１１０は、特定のパケットフローに対する複数の役割の中の１つの役割だけに従事する（ただし、２つまたは３つの役割に従事することも可能）。しかしながら、少なくともいくつかの実施形態において、ロードバランサノード１１０は、特定のパケットフローに対する一次フロー追跡部及び二次フロー追跡部の両方としての役割を果たすことは許されないことに留意されたい。あるいは、いくつかの実施形態において、各ロードバランサノード１１０は、３つの役割の中の１つの役割のみを果たす。この実施形態においては、演算装置の独立した組み合わせは、特に、入口ノード、出口ノード、及びフロー追跡部ノードとして、ロードバランサノードレイヤの中に実装されてもよい。

【0018】

少なくともいくつかの実施形態において、コンシステントハッシュ法及びコンシステントハッシュリング技術は、パケットフローに対する一次及び二次フロー追跡部を決定するために適用されてもよい。クライアントからの各パケットフローは、例えば、クライアントＩＰアドレス、クライアントポート、サーバ（パブリック）ＩＰアドレス、及びサーバポートから構成される４つのタプルによって一意に認証される。この識別子は、クライアント及び公開エンドポイント対を示すＣＰまたはＣｃＰｐとして略すことができる。任意の所定のＴＣＰフロー（またはＣＰ対）に関連するパケットは、エッジルータ１０４からのハッシュ化マルチパス（例えば、ＥＣＭＰ）フロー分散のせいで、入口サーバ１１２として動作する任意のロードバランサノード１１０上に出現し得る。入口ノードとして機能しているロードバランサノード１１０にパケットが到達した場合には、入口ノードは、パケットフロー（すなわち、一次フロー追跡部ノード）に対応する状態を維持することを担うのにどのロードバランサノード１１０にするかを決定することができるように、コンシステントハッシュ法が使用される。ＣＰ対は、入口ノードによってハッシュ化されてコンシステントハッシュリングに入り、パケットフローに関する状態情報を維持することを担うのにどのロードバランサノード１１０にするかを決定する。コンシステントハッシュリングにおいてパケットフローに対応するＣＰ対のコンシステントハッシュに従って決定されたノード１１０は、パケットフローに対して一次フロー追跡部としての機能を果たすノード１１０である。少なくともいくつかの実施形態において、コンシステントハッシュリングの中で後に続くノードは、パケットフローに対して二次フロー追跡部としての機能を果たす。

【0019】

図３は、少なくともいくつかの実施形態において、すべての３つの役割（入口、出口、及びフロー追跡部）を実施する構成要素を含む例示的なロードバランサ（ＬＢ）ノード１１０を示す。この実施例において、入口サーバ１１２の構成要素は、クライアントからのインバウンドのＴＣＰパケットを受信して、そのＴＣＰパケットをカプセル化されたパケットとしてサーバに送信する入口の役割を実行する。出口サーバ１１４の構成要素は、サーバからのアウトバウンドのカプセル化されたパケットを受信して、デカプセル化されたＴＣＰパケットをクライアントに対して送信する出口の役割を実行する。フロー追跡部１１６の構成要素は、クライアント１６０とサーバ１３４との間に確立された１または２以上のパケットフローに対応する一次または二次フロー追跡部として実行する。入口サーバ１１２はまた、ロードバランサノード１１０上のフロー追跡部１１６または他のロードバランサノード１１０上のフロー追跡部１１６と通信し、それぞれのクライアント１６０から受信した接続要求に応答して、クライアントとサーバ１３４の１つとの間のＴＣＰ接続を開始し、または、パケットフローに対するマッピング情報を取得する。
＜ロードバランサノード＞

【0020】

再び図１を参照すると、少なくともいくつかの実施形態において、ロードバランサノードレイヤにおけるロードバランサノード１１０は、ネットワーク上の１以上のルータ１０４からのクライアントトラフィック（パケット、例えば、ＴＣＰパケット）を受信して、ファブリック１２０上の分散型ロードバランサシステムによって使用されるプロトコル（例えば、ユーザ・データグラム・プロトコル（ＵＤＰ））に従って、そのパケットをカプセル化する。次に、ロードバランサノードレイヤは、そのカプセル化されたパケットを宛先サーバノード１３０に対してファブリック１２０を介して転送する。各サーバノード１３０は、ロードバランサシステムの構成要素であるローカルモジュール１３２を含む。モジュール１３２は、ここにおいてはロードバランサモジュールまたは単にＬＢモジュールと称され、サーバノード１３０上のソフトウェア、ハードウェア、またはこれらの複合内に実装されてもよい。各サーバノード１３０において、それぞれのロードバランサモジュール１３２は、パケットをデカプセル化して、正常なＴＣＰ処理のためにローカルＴＣＰスタックに対してＴＣＰパケットを送信する。少なくともいくつかの実施形態において、ロードバランサノードレイヤは、すべてのクライアント−サーバＴＣＰフローにおける状態情報を維持するが、しかし、ロードバランサノードレイヤにおけるロードバランサノード１１０は、ＴＣＰフローに関するいかなるものも解釈することはない。各フローは、それぞれのサーバノード１３０上のサーバ１３４とクライアント１６０との間で管理される。分散型ロードバランサシステムは、ＴＣＰパケットが正しい宛先サーバ１３４に到達することを保証する。各サーバノード１３０におけるロードバランサモジュール１３２は、それぞれのサーバ１３４がロードバランサノード１１０から受信したクライアント接続要求に応答する新たな接続を受諾するかまたは拒絶するかどうかについて決定を下す。

【0021】

少なくともいくつかの実施形態において、分散型ロードバランシングシステムは、コンシステントハッシュ法の技術を使用して、例えば、どのサーバノード１３０が特定のＴＣＰパケットフローに対して責任を負うかについて、どのロードバランサノード１１０が記憶すべきかを決定する。コンシステントハッシュ法の技術を使用することにより、ロードバランサノードレイヤにおけるロードバランサノード１１０は、コンシステントハッシュリングとして見られ、ロードバランサノード１１０はそのリング内のメンバーシップを追跡し、コンシステントハッシュ法の機能に従って、特定のパケットフローに対して責任を負うそのリング内の特定のメンバーを決定する。少なくともいくつかの実施形態において、クライアント１６０とサーバ１３４との間における各パケットフローの追跡に対して責任を負う２つのロードバランサノード１１０が存在するが、これらのノード１１０は一次フロー追跡部（ＰＦＴ）ノード及び二次フロー追跡部（ＳＦＴ）ノードと称される。少なくともいくつかの実施形態において、一次フロー追跡部は、フローについてのコンシステントハッシュリング上の第１のロードバランサノード１１０であり、二次フロー追跡部は、一次フロー追跡部ノードとは異なる、コンシステントハッシュリング上の次のまたはそれに続くロードバランサノード１１０である。この配列において、一次フロー追跡部ノードに障害が生じた場合には、二次フロー追跡部ノードが新たな一次フロー追跡部になり、他のロードバランサノード１１０（例えば、コンシステントハッシュリング上の次のノード１１０）が二次フロー追跡部の役割を負う。少なくともいくつかの実施形態において、ロードバランサノード１１０は、所定のパケットフローに対する一次フロー追跡部及び二次フロー追跡部の両方としての機能を果たすことは許されないことに留意されたい。コンシステントハッシュリングにおけるこのメンバーシップの変更及び他のメンバーシップの変更については、本明細書において後述する。少なくともいくつかの実施形態において、ロードバランサの実装についての構成情報（例えば、現在実装されているロードバランサノード１１０及びサーバノード１３０の信頼できるリスト）は、分散型ロードバランシングシステムの構成サービス１２２の構成要素によって維持され、例えば、ファブリック１２０を介してロードバランサノード１１０に結合された１以上のサーバ装置上に実装されてもよい。

【0022】

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

【0023】

上記したように、少なくともいくつかの実施形態において、各ロードバランサノード１１０は、異なるパケットフローに対して入口ノード、出口ノード、及び／またはフロー追跡部ノード（一次または二次フロー追跡部のいずれかとして）の役割を実行する。ロードバランサノードレイヤにおける単一のロードバランサノード１１０は、ノードが処理しているパケットフローが何であるかに依存して、役割のいずれか１つを実行する。例えば、少なくともいくつかの実施形態において、ロードバランサノード１１０は、１つのパケットフローに対しては入口ノードとして、他のパケットフローに対しては一次もしくは二次フロー追跡部として、さらに他のパケットフローに対しては出口ノードとして実行してもよい。さらに、少なくともいくつかの実施形態において、ロードバランサノード１１０は、同一のパケットフローに対して例えば、所定のパケットフローに対して入口ノードとして且つ一次（または二次）フロー追跡部ノードとして多重の役割を実行する。しかしながら、少なくともいくつかの実施形態において、冗長性及び回復の目的のために、ロードバランサノード１１０は、同一のパケットフローに対して一次及び二次フロー追跡部ノードの両方としての役割を果たすことは許されない。

【0024】

各ロードバランサノード１１０が入口サーバ、出口サーバ、及びフロー追跡部の３つの役割のいずれかを果たす実施形態について、上記説明した。しかしながら、いくつかの実施形態においては、演算装置の異なるグループは、ロードバランシングシステムにおいて異なる役割を割り当てられてもよい。例えば、いくつかの実施形態においては、入口ノード、出口ノード、及びフロー追跡部ノードの各々が独立した演算装置に実装された異なる組み合わせが存在してもよい。いくつかの実施形態における他の実施例として、演算装置の１つの組み合わせは入口ノード及びフロー追跡部ノードの両方としての役割を果たし、その一方、演算装置の他の組み合わせは出口ノードのみとしての役割を果たす。
ロードバランサモジュール

【0025】

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

【0026】

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

【0027】

少なくともいくつかの実施形態において、サーバノード１３０上のロードバランサモジュール１３２もまた、それぞれのサーバノード１３０上のサーバ１３４に対するロードバランシングに関連するローカルな決定を下す。特に、ノード１３０上のロードバランサモジュール１３２は、新たなＴＣＰ接続のための要求の受信に応答して他のＴＣＰフローをそれぞれのサーバ１３４が受諾するかどうかを決定する。上記したように、ロードバランサノード１１０はロードバランサモジュール１３２に送信されるすべてのパケットをカプセル化するので、ロードバランサモジュール１３２は実際にはクライアント１６０からのＴＣＰ同期（ＳＹＮ）パケットを受信しない。その代わりに、ロードバランサモジュール１３２は、ロードバランサモジュール１３２が受諾または拒絶のいずれかが可能なフロー追跡部１１６からのカプセル化プロトコル（例えば、ＵＤＰ）に従って、接続要求メッセージを受信する。ロードバランサモジュール１３２が接続要求メッセージを受諾した場合には、ロードバランサモジュール１３２はローカルホスト宛てのＳＹＮパケットを生成する。ローカルホストが接続を受諾した場合には、これはそれぞれのクライアント接続を取り扱う実際のＴＣＰスタックになる。

【0028】

少なくともいくつかの実施形態において、接続要求メッセージを受諾すべきかどうかについて決定を下すために、ロードバランサモジュール１３２は、サーバノード１３０上の現在の資源使用量に関する１以上のメトリクスを観察し、新たな接続を取り扱うのに使用できる十分な資源が存在する場合には、ロードバランサモジュール１３２はその接続を受諾する。少なくともいくつかの実施形態において、ロードバランサモジュール１３２によって判断された資源のメトリクスは、１以上のＣＰＵの使用、直前の帯域幅の使用量、及び確立された接続数を含んでもよいが、これらには限定されない。いくつかの実施形態においては、これらのメトリクスの代わりにまたはこれらのメトリクスに加えて、他のメトリクスが検討できる。例えば、いくつかの実施形態において、ロードバランサモジュールは、サーバの待ち時間（すなわち、サーバ接続の未処理分の中で使われている時間要求の量）をメトリックとして判断し、サーバの待ち時間が閾値を超えている場合には、接続要求を拒絶する。これらのメトリクス及びまたは他のメトリクスを使用することで、ロードバランサモジュール１３２は、それぞれのサーバ１３４に対して、そのサーバ１３４が新たなパケットフローを受諾すべきかまたは拒絶すべきかどうか決定できる。少なくともいくつかの実施形態において、資源の利用率（例えば、Ｎ％の利用率）は、単独にまたは組み合わせて、且つ、閾値（例えば、９０％の利用率）と比較されたメトリクスから決定されてもよい。決定された資源の利用率が、閾値以上である場合、あるいは、これから追加される接続が閾値を超える利用率に移行するおそれがある場合には、接続要求は拒絶される。

【0029】

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

【0030】

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

【0031】

場合によっては、接続要求メッセージを送信されたロードバランサモジュール１３２のすべてが接続要求を拒絶する可能性もある。少なくともいくつかの実施形態において、接続要求メッセージが無期限にロードバランサモジュール１３２からロードバランサモジュール１３２に戻されることを回避するために、各接続要求メッセージに生存時間が与えられてもよい。この生存時間が切れたときは、フロー追跡部ノードは、要求を終結し、現在は要求に対応できないことをそれぞれのクライアント１６０に通知することができる。

【0032】

少なくともいくつかの実施形態において、サーバノード１３０上のロードバランサモジュール１３２もまた、ロードバランサノード１１０に対して接続公開を実行する。少なくともいくつかの実施形態において、接続公開を実行するために、定期的（例えば、１秒に１回）または不定期に、各ロードバランサモジュール１３２は、サーバノード１３０上のルーティングテーブル（例えば、ｎｅｔｓｔａｔルーティングテーブル）を観察し、アクティブな接続（ＴＣＰフロー）のリストを公開してロードバランサノード１１０に戻す。所定のパケットフローの存在について情報を必要とするロードバランサノード１１０は、それぞれのパケットフローに対して入口ノードとして且つ一次及び二次フロー追跡部としての役割を果たすロードバランサノード１１０である。いくつかの実施形態においては、ロードバランサモジュール１３２は、コンシステントハッシュ法の技法を用いて、サーバノード１３０上のアクティブなＴＣＰフローについて情報を必要とするロードバランサノード１１０のリストをフィルタリングする。例えば、ロードバランサモジュール１３２は、コンシステントハッシュリングに従って所定のパケットフローに対して一次及び二次フロー追跡部としての役割を果たすのがどのロードバランサノード１１０であるかを判定することができる。いくつかの実施形態において、ロードバランサモジュール１３２は、各パケットフローについてロードバランサモジュール１３２にデータパケットを最後に送信したのがどのロードバランサノード１１０であるかを追跡し、この情報を用いてパケットフローに対して入口ノードとして対応しているのがどのロードバランサノード１１０であるかを追跡するが、それは入口ノードのみがクライアントデータをロードバランサモジュール１３２に転送するからである。いくつかの実施形態において、ロードバランサモジュール１３２は、次に、パケットフローについて情報を必要とすることを決定したロードバランサノード１１０の各々に関するメッセージを公式化し、そのメッセージをロードバランサノード１１０に送信し、それぞれのサーバノード１３０がクライアント１６０に対する接続をまだ維持していることをノード１１０に通知する。ロードバランサモジュール１３２によるロードバランサノード１１０へのこの接続公開は、ロードバランサノード１１０におけるリースの延長と見なされてもよい。ロードバランサノード１１０が、一定の期間（例えば、１０秒）内の特定のパケットフローを示す接続公開メッセージを受信しなかった場合には、ロードバランサノード１１０は、解放されてそれぞれのパケットフローのことを忘れる。
ロードバランサノードに対するマルチパス・ルーティング

【0033】

図４は、少なくともいくつかの実施形態において、分散型ロードバランサにおけるルーティング及びパケットフローの態様を示す。少なくともいくつかの実施形態において、各入口ノード（入口ノードは、図４においては入口サーバ１１２として示さる）は、１以上の公開エンドポイント（例えば、ＩＰアドレス及びポート）にルーティングできる自分の能力を、例えば、境界ゲートウェイ・プロトコル（ＢＧＰ）を経由して、分散型ロードバランサに関するエッジルータ１０４に広告する。少なくともいくつかの実施形態においては、各入口ノードがＢＧＰセッション経由でエッジルータ１０４に自身を広告するというよりむしろ、図５に示されるように、１以上の他の入口ノード、例えば、２つの隣接するノードが、エッジルータ１０４とＢＧＰセッションを確立して当該入口ノードを広告する。

【0034】

従来のロードバランサは、通常、単一の公開エンドポイントの役割を果たすことのみができる。反対に、分散型ロードバランサの実施形態によって、多数のロードバランサノード１１０が単一の公開エンドポイントの役割を果たすことを可能にする。ルータの能力に依存するならば、このことにより、すべての入口サーバ１１２に対してルーティングされた単一のパブリックＩＰアドレスが、エッジルータ１０４を介して全体の帯域幅（例えば、１６０Ｇｂｐｓ）を取り扱うことができる構成を可能にする。少なくともいくつかの実施形態において、このことを遂行するために、エッジルータ１０４は、レイヤ４のフロー単位ハッシュ化マルチパス・ルーティング技法、例えば、等価マルチパス（ＥＣＭＰ）ルーティング技法を利用して、各々が同一のパブリックＩＰアドレスを広告する多数の入口サーバ１１２の全体に亘ってトラフィックを分散する。エッジルータ１０４のフローハッシュの部分として、フローに対するレイヤ４の送信元ポート及び宛先ポートを使用して、入口サーバ１１２のすべてに対して着信パケットを分散することにより、一般的には、入口サーバ１１２として機能している同一のロードバランサノード１１０にルーティングされた各接続のためにパケットを保持して、パケットが順序から外れるのを回避する。しかしながら、いくつかの実施形態においては、エッジルータ１０４は、他の技法を使用して入口サーバ１１２の全体に亘ってトラフィックを分散することに留意されたい。

【0035】

図４もまた、ネットワーク１００上に実装される２以上の分散型ロードバランサを示す。２以上の分散型ロードバランサは、各々が複数のサーバ１３０に対応するとともに、各々が異なるパブリックＩＰアドレスを広告する独立したロードバランサとして各々が行動し、あるいは、図４に示されるように、２以上の分散型ロードバランサが、各々同一のＩＰアドレスを広告し、ハッシュ法の技法（例えば、レイヤ４のフロー単位ハッシュ化マルチパス・ルーティング技法）が境界ルータ１０２において使用されて、パケットフローをエッジルータ１０４に区分し、そして今度は、エッジルータ１０４がパケットフローを対応するそれぞれの入口サーバ１１２に分散する。

【0036】

図５は、少なくともいくつかの実施形態において、入口ノードをエッジルータに広告するために境界ゲートウェイ・プロトコル（ＢＧＰ）を使用することを示す。この実施例において、ロードバランサ実装の中に、入口ノード１１０Ａないし１１０Ｄとしての役割を果たす４つのロードバランサノードがある。エッジルータ１０４は、クライアント（図示せず）からの着信パケットをロードバランサノード１１０にルーティングする。少なくともいくつかの実施形態において、エッジルータ１０４は、レイヤ４のフロー単位ハッシュ化マルチパス・ルーティング技法、例えば、等価マルチパス（ＥＣＭＰ）ルーティング技法に従って、ルーティングの決定を下す。

【0037】

少なくともいくつかの実施形態において、エッジルータ１０４は、入口ノード１１０によって開始されたセッションを広告する境界ゲートウェイ・プロトコル（ＢＧＰ）技術を介して、ロードバランサ実装の中でクライアントトラフィックを受信するために現在使用できる入口ノード１１０について学習する。各入口ノード１１０は、エッジルータ１０４に対して自身を広告するためにＢＧＰを使用することができる。しかしながら、ＢＧＰは、一般に、収束するのに比較的長い時間（３秒以上）がかかる。各入口ノード１１０がＢＧＰを介して自身を広告する際にこの技法を使用すると、入口ノード１１０がダウンに至る場合には、エッジルータ１０４上でのＢＧＰセッションがネットワーキングの期間の中では相当な時間（３秒以上）を要して時間切れになるので、エッジルータ１０４は障害閉鎖について学習する結果になり、現在のＴＣＰフローを入口ノード１１０に再びルーティングすることになる。

【0038】

ＢＧＰに伴う収束の問題を回避するため、且つ、ノード１１０を障害からより迅速に回復させるために、少なくともいくつかの実施形態においては、入口ノード１１０がＢＧＰセッションを介してエッジルータ１０４に自身を広告する代わりに、ロードバランサ実装の中で少なくとも１つの他の入口ノード１１０が、ＢＧＰを介してエッジルータ１０４に対して入口ノード１１０を広告するための責任を負う。例えば、図５に示すようないくつかの実施形態において、所定の入口ノード１１０の左右の隣接する入口ノード１１０、例えば、ノード１１０の順序リストの左右の隣接物、例えば、ノード１１０によって形成されたコンシステントハッシュリングが、当該所定の入口ノード１１０をエッジルータ１０４に対して広告してもよい。例えば、図５において、入口ノード１１０Ａは入口ノード１１０Ｂ及び１１０Ｄを広告し、入口ノード１１０Ｂは入口ノード１１０Ａ及び１１０Ｃを広告し、入口ノード１１０Ｃは入口ノード１１０Ｂ及び１１０Ｄを広告し、そして入口ノード１１０Ｄは入口ノード１１０Ｃ及び１１０Ａを広告する。入口ノード１１０は、本明細書において後述するように、お互いの健康をチェックし且つ喧伝する。上記したようにヘルスチェック方法を使用すれば、不健康なノードを検出することができ、且つ、その情報を１秒未満、例えば、１００ミリ秒（ｍｓ）でノード１１０の間に伝達することができる。ある入口ノード１１０が健康でないと決定されると、その不健康な入口ノードを広告する入口ノード１１０は、直ちにその不健康なノード１１０の広告を停止する。少なくともいくつかの実施形態において、入口ノード１１０は、ＢＧＰセッションについてのＴＣＰ Ｃｌｏｓｅメッセージまたは同様のメッセージをエッジルータ１０４に送信することによって、エッジルータ１０４との間のＢＧＰセッションを終了する。このように、ノード１１０の障害を検出するために、障害のある入口ノード１１０によって確立されたＢＧＰセッションが時間切れになるのを待つのではなく、障害のある入口ノード１１０の代理として広告する他の入口ノード１１０が、当該ノード１１０が不健康であることを検出したことで、エッジルータ１０４との間で当該入口ノード１１０を広告するＢＧＰセッションを終了するときに、エッジルータ１０４は障害のあるノード１１０を発見する。ロードバランサノードの障害を取り扱うことについては、図１８Ａ及び１８Ｂに関連して、本明細書においてさらに説明する。

【0039】

図６は、分散型ロードバランシングシステムの少なくともいくつかの実施形態において、マルチパス・ルーティング方法のフローチャートである。９００に示されるように、ロードバランサ実装の中の入口ノード１１０は、それらに隣接するノード１１０をエッジルータ１０４に広告する。少なくともいくつかの実施形態において、入口ノード１１０は、コンシステントハッシュリングなどのノード１１０の順序リストに従って、それらに隣接するノード１１０を決定する。少なくともいくつかの実施形態において、入口ノード１１０は、各々の広告されたノード１１０に対応してエッジルータ１０４に対して確立された１つのＢＧＰセッションと共に、ＢＧＰセッションを使用して、それらに隣接するノード１１０をエッジルータ１０４に対して広告する。

【0040】

９０２に示されるように、エッジルータ１０４は、フロー単位ハッシュ化マルチパス・ルーティング技法、例えば、等価マルチパス（ＥＣＭＰ）ルーティング技法に従って、クライアント１６０から受信されたトラフィックをアクティブな（広告された）入口ノード１１０に分散する。少なくともいくつかの実施形態において、エッジルータ１０４は、パブリックＩＰアドレスをクライアント１６０に公表し、入口ノード１１０は、同一のパブリックＩＰアドレスをエッジルータ１０４にすべて広告する。エッジルータは、レイヤ４の送信元ポート及び宛先ポートをエッジルータ１０４のフローハッシュの部分として使用して、着信パケットを入口ノード１１０の中に分散する。このことにより、通常、同一の入口ノード１１０に対してルーティングされた各接続に関するパケットを保持することになる。

【0041】

９０２に示されるように、入口ノードは、データフローを目標のサーバノード１３０に転送する。少なくともいくつかの実施形態において、入口ノード１１０は、そのデータフローについて一次及び二次フロー追跡部ノードと対話して、そのデータフローを目標のサーバノード１３０にマッピングする。したがって、各々の入口ノード１１０は、受信されたパケットを適切に目標のサーバノード１３０に対して転送するために使用されるノード１１０を介して、アクティブなデータフローのマッピングを維持する。

【0042】

９０６から９１０までの要素は、入口ノード１１０の障害を検出すること及びそこから回復することに関する。９０６に示されるように、入口ノード１１０は、例えば本明細書に記載されているヘルスチェック技法に従って、入口ノード１１０がダウンしたことを検出する。ノード１１０のダウンが検出されると、その隣接ノード１１０はエッジルータ１０４に対する広告を停止する。少なくともいくつかの実施形態において、このことは、それぞれのＢＧＰセッションにおいてエッジルータ１０４に対してＴＣＰ Ｃｌｏｓｅを送信することを含む。

【0043】

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

【0044】

９１０に示されるように、入口ノード１１０は、必要に応じてマッピングを回復し、且つそのデータフローを適切な目標のサーバノードに転送する。入口ノード１１０上でノード１１０の障害から回復するための方法については、本明細書の他のところで説明する。１つの実施例として、入口ノード１１０は、現在のマッピングの対象ではないパケットを受信したときは、コンシステントハッシュリングに従ってコンシステントハッシュ機能を用いて、データフローに対応するフロー追跡部ノードを決定して、当該フロー追跡部ノードからマッピングを回復する。
非対称のパケットフロー

【0045】

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

【0046】

少なくともいくつかの実施形態において、出口サーバ１１４を選択するためにサーバノード１３０によって使用される方法及びデータは、エッジルータ１０４によって実行される入口サーバ１１２を選択するために使用される方法及びデータとは異なる。異なる方法及びデータを使用すると、一般的には、その接続に対する入口ノードとして選択されたロードバランサノード１１０ではなく、ある所定の接続に対する出口ノードとして選択されている異なるロードバランサノード１１０を生じる結果となり、入口ノードとしての機能を果たす単一のロードバランサノード１１０を通る接続についての発信トラフィックを取り扱うべき出口ノードとして選択されている多数のロードバランサノード１１０を生じる結果にもなる。

【0047】

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

【0048】

クライアントトラフィックを受信すべきサーバノード１３０をどれにするか決定するために、ロードバランサノード１１０がコンシステントハッシュ法を使用することが可能である一方で、いくつかの接続の長い寿命のために、新たなサーバノード１３０がコンシステントハッシュのメンバーシップに加わる場合や、その後の入口のロードバランサノード１１０障害が存在する場合には、この方法は存在しているフローを維持することができない。このシナリオにおいて、障害が発生したノード１１０からフローを引き継ぐロードバランサノード１１０は、異なるメンバーシップを持つことになるサーバ１３０に対するコンシステントハッシュリングとして選択された元のマッピングを決定することができない。このため、少なくともいくつかの実施形態においては、ロードバランサノード１１０によって分散型ハッシュテーブル（ＤＨＴ）技術が使用されて、接続に対するサーバノード１３０を選択し、且つ、その選択されたサーバノード１３０に対してパケットをルーティングする。ＤＨＴに従って、特定の接続を受信するために一旦サーバノード１３０が選択されると、そのサーバノード１３０が健康のままでいて、且つ、（例えば、接続公開によって）ＤＨＴへのそのようなアクティブな接続の状態を定期的に送信することによって、サーバノード１３０上のロードバランサモジュール１３２がリースの延長を継続すると仮定した場合、ＤＨＴは、その接続が完了するまでそのマッピングを保持することになる。入口ノード１１０の障害が、エッジルータ１０４から残りのロードバランサノード１１０に対するパケットの分散に衝撃を与えると、そのロードバランサノード１１０は異なる組み合わせのクライアント接続からトラフィックを受信する結果になる。しかしながら、ＤＨＴはすべてのアクティブな接続を追跡するので、ロードバランサノード１１０はＤＨＴに問い合わせを行って任意のアクティブなマッピングに関するリースを取得することができる。その結果、すべてのロードバランサノード１１０は、正しいサーバノード１３０に対してトラフィックを渡すので、入口ロードバランサノード１１０に障害が発生する事態があっても、アクティブなクライアント接続の障害を回避する。
分散型ロードバランシングシステムにおけるパケットフロー

【0049】

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

【0050】

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

【0051】

２０２において、入口サーバ１１２が、ＴＣＰパケットフローに対応するマッピングを持たない場合には、そのパケットは、クライアント１６０からのＴＣＰ同期（ＳＹＮ）パケットである。２０６に示されるように、ＳＹＮパケットを受信すると、入口サーバ１１２は、そのＳＹＮパケットからデータを抽出して、そのデータを、例えばＵＤＰメッセージの中で、一次フロー追跡部１１６Ａに転送する。少なくともいくつかの実施形態において、入口サーバ１１２は、コンシステントハッシュ機能に従って、ＴＣＰフローに対する一次フロー追跡部１１６Ａ及び／または二次フロー追跡部１１６Ｂを決定できる。２０８において、一次フロー追跡部１１６Ａは、そのデータを例えばハッシュテーブルの中に記憶し、ＴＣＰ接続のサーバノード１３０側に対する最初のＴＣＰシーケンス番号を生成し、そのデータ及びＴＣＰシーケンス番号を二次フロー追跡部１１６Ｂに転送する。２１０において、二次フロー追跡部１１６Ｂもまた、そのデータを記憶するとともに、ＳＹＮ／ＡＣＫパケットを作成し且つクライアント１６０に送信するが、そのＳＹＮ／ＡＣＫパケットには少なくともＴＣＰシーケンス番号が含まれている。

【0052】

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

【0053】

図９Ｂの２２０に示されるように、ロードバランサモジュール１３２は、作成されたＳＹＮメッセージに応答して、サーバノード１３０の１以上のメトリクスを調べて、サーバノード１３０が接続を受諾することができるかどうかを判定する。２２２において、ロードバランサモジュール１３２は、当該サーバノード１３０が現在においては接続を受諾することができないと判定した場合には、２２４において、ロードバランサモジュール１３２は二次フロー追跡部１１６Ｂに伝達する。二次フロー追跡部１１６Ｂは、以前に記憶したフローに関する情報を消去する。２２６において、二次フロー追跡部１１６Ｂは、一次フロー追跡部１１６Ａに伝達する。図９Ａの２１６に示されるように、一次フロー追跡部１１６Ａは、その後、新たな目標のサーバノード１３０を選択して、二次フロー追跡部１１６Ｂに伝達する。

【0054】

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

【0055】

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

【0056】

２４０において、ロードバランサモジュール１３２は、データフローに対応する出口サーバ１１４をランダムに選択する。サーバ１３４からのアウトバウンドＴＣＰパケットは、ロードバランサモジュール１３２によって中断され、ＵＤＰに従ってカプセル化され、任意に選択された出口サーバ１１４に転送される。出口サーバ１１４は、その発信パケットをデカプセル化して、そのＴＣＰパケットをクライアント１６０に送信する。

【0057】

上記したように、２０２において、入口サーバ１１２が、受信されたパケットのＴＣＰフローに対応するマッピングを持たない場合には、そのパケットは、クライアント１６０からのＴＣＰ同期（ＳＹＮ）パケットである。しかしながら、そのパケットは、ＴＣＰ ＳＹＮパケットではない。例えば、ロードバランサノード１１０の追加または障害のせいで、ロードバランサノード１１０のメンバーシップが変化した場合には、エッジルータ１０４は、マッピングを持たない入口サーバ１１２に対して、１以上のＴＣＰフローに対応するパケットのルーティングを開始する。少なくともいくつかの実施形態において、対応するマッピングを持たない入口サーバ１１２がこのようなパケットを受信すると、その入口サーバ１１２は、コンシステントハッシュ機能を用いて、コンシステントハッシュリングに従ってＴＣＰフローに対応する一次フロー追跡部１１６Ａ及び／または二次フロー追跡部１１６Ｂを決定し、一次フロー追跡部１１６Ａまたは二次フロー追跡部１１６Ｂのいずれかに伝達してマッピングを要求する。入口サーバ１１２は、フロー追跡部１１６からＴＣＰフローに対応するマッピングを受信すると、そのマッピングを記憶して、ＴＣＰフローに対応するＴＣＰパケットのカプセル化及び正しい宛先サーバノード１３０に対する転送を開始することができる。
ロードバランサノードの細部

【0058】

少なくともいくつかの実施形態において、ロードバランサノード１１０の各々は３つの役割を持つ。
● 入口−クライアント接続においてクライアント１６０からすべての着信パケットを受信すること、マッピングが分かっている場合にサーバノード１３０にパケットをルーティングすること、またはマッピングが分かっていない場合にフロー追跡部に伝達すること。入力ノードからの発信パケットは、入口ノードによって（例えば、ＵＤＰに従って）カプセル化される。
● フロー追跡処理−接続状態（例えば、どのサーバノード１３０／サーバ１３４が各クライアント接続を提供するために割り当てられているか）の記録をつけること。フロー追跡部もまた、クライアント１６０とサーバ１３４との間の接続を確立することに参加する。
● 出口−サーバ１３４から受信されたアウトバウンドパケットをデカプセル化すること及びクライアント１６０に転送すること。

【0059】

少なくともいくつかの実施形態において、入口の役割の中で、ロードバランサノード１１０は、クライアントからサーバへのマッピングが分かっている場合には、サーバ１３４に対してパケットを転送する役割を担い、または、マッピングが分かっていない場合には、フロー追跡部に対して要求を転送する役割を担う。特定のクライアント接続／データフローについて入口ノードとしての機能を果たしているロードバランサノード１１０は、クライアント接続に対して、一次フロー追跡部または二次フロー追跡部のいずれとしての機能も果たすが、両方としての機能を果たすことはない。

【0060】

少なくともいくつかの実施形態において、フロー追跡部の役割の中で、ロードバランサノード１１０は、確立された接続に対応するクライアントからサーバへのマッピングを維持する役割を担うだけでなく、引き続き確立されている接続の状態を維持する役割をも担う。２つのフロー追跡部は、各々が個別のクライアント接続にかかわり、一次フロー追跡部及び二次フロー追跡部と称される。少なくともいくつかの実施形態において、クライアント接続に関連するフロー追跡部は、コンシステントハッシュアルゴリズムを用いて決定される。フロー追跡部もまた、新たなクライアント接続の各々に対応するサーバノード１３０を擬似ランダムに選択することを含むロードバランシングの機能を実行するが、これに限定されるものではない。選択されたサーバノード１３０上のローカルロードバランサモジュール１３２は、サーバ１３４が接続を取り扱うことができないと判定した場合には、接続要求を拒絶する。このことが起こった場合には、フロー追跡部は、他のサーバノード１３０を選択して、他のサーバノード１３０に対して接続要求を送信する。少なくともいくつかの実施形態において、所定の接続に対する一次フロー追跡部の役割及び二次フロー追跡部の役割は、異なるロードバランサノード１１０によって実行される。

【0061】

少なくともいくつかの実施形態において、出口の役割の中で、ロードバランサノード１１０は、ステートレスであり、サーバノード１３０から受信された着信パケットをデカプセル化し、いくつかの確認を実行し、それぞれのクライアント１６０に対してアウトバウンドＴＣＰパケットを転送する。少なくともいくつかの実施形態において、サーバノード１３０上のローカルロードバランサモジュール１３２は、所定の接続に対応するロードバランサノード１１０を任意に選択する。
ロードバランサノードのコンシステントハッシュリング接続形態

【0062】

少なくともいくつかの実施形態において、ロードバランサノード１１０は、入力キー空間（クライアントエンドポイント、公開エンドポイント）のコンシステントハッシュ法に基づいてリング接続形態を形成する。その入力キー空間は、使用できるフロー追跡部ノードの間で分割され、すべてのフロー追跡部ノードは、そのキー空間に対応する問い合わせに答える義務を負う。少なくともいくつかの実施形態において、データは、コンシステントハッシュリングにおける後続（例えば、コンシステントハッシュリングにおいて、二次フロー追跡部ノードは、一次フロー追跡部ノードの後続ノードまたは次のノード）に基づいて、一次及び二次フロー追跡部ノードに対して複製される。フロー追跡部ノードがなんらかの理由でダウンに至る場合には、コンシステントハッシュリングにおける次のロードバランサノードは、障害が発生したノードのキー空間を要求する。新たなフロー追跡部ノードが加わった場合には、他のロードバランサノードがロードバランサ実装の中で、したがってコンシステントハッシュリングの中で、構成変更について学習するように、そのノードは自分のエンドポイントを（例えば、図１に示されるような構成サービス１２２により）記録する。フロー追跡部の追加及び障害を取り扱うことについては、図１１Ａないし１１Ｄを参照して、さらに詳細に説明する。
入口ノード対フロー追跡部ノードの通信

【0063】

少なくともいくつかの実施形態において、入口ノードとしての機能を果たしているロードバランサノード１１０は、フロー追跡部ノードとしての機能を果たしているロードバランサノード１１０について構成サービス１２２から学習する。入口ノードは、ロードバランサ実装の中で、したがってコンシステントハッシュリングの中で、メンバーシップの変化について、構成サービス１２２を監視する。入口ノードは、その入口ノードが対応するマッピングを持たないクライアント１６０からパケットを受信したときは、その入口ノードは、コンシステントハッシュ機能を用いて、パケットにサービスすべきフロー追跡部ノードをどれにするかを決定する。少なくともいくつかの実施形態において、ハッシュ機能への入力は、パケットからの対（クライアントエンドポイント、公開エンドポイント）である。少なくともいくつかの実施形態において、入口ノード及びフロー追跡部ノードは、ＵＤＰメッセージを用いて通信する。

【0064】

一次フロー追跡部ノードが新たなパケットフローについて入口ノードからメッセージを受信した場合には、その一次フロー追跡部ノードは、ＴＣＰシーケンス番号をランダムに決定して、他のメッセージを二次フロー追跡部ノードに転送する。二次フロー追跡部ノードは、クライアントに対応するＴＣＰ ＳＹＮ／ＡＣＫメッセージを生成する。両方のフロー追跡部は、クライアント接続のエンドポイント対及びＴＣＰシーケンス番号を記憶し、メモリの圧迫または有効期限切れが原因で状態が除去されるまでは、この情報を保持する。

【0065】

一次フロー追跡部ノードが、ＴＣＰ ＡＣＫパケットを受信した入口ノードからメッセージを受信した場合には、その一次フロー追跡部ノードは、承認されたＴＣＰシーケンス番号が、ＳＹＮ／ＡＣＫパケットの中で送信されて記憶された値と一致することを検証し、要求にサービスすべきサーバノード１３０を選択し、二次フロー追跡部ノードに対してメッセージを転送する。二次フロー追跡部ノードは、その選択されたサーバノード１３０上のロードバランサモジュール１３２に対してメッセージを送信して、サーバノード１３０上のＴＣＰスタックによって実際のＴＣＰ接続を開始し、次にサーバノード１３０からの承認応答を待つ。

【0066】

二次フロー追跡部ノードが、サーバノード１３０上のロードバランサモジュール１３２から接続承認を受信した場合には、一次フロー追跡部を通って入口ノードに至り、両方のノードにおいて関連するサーバノード１３０に関する情報を記憶する折り返しメッセージフローが起動される。このポイントの転送から、入口ノードにおいて受信された追加のＴＣＰパケットは、サーバノード１３０上のロードバランサモジュール１３２に直接に転送される。
ロードバランサモジュール対ロードバランサノードの通信

【0067】

少なくともいくつかの実施形態において、すべてのロードバランサモジュール１３２は、自分のエンドポイントを構成サービス１２２によって記録し、ロードバランサノードのレイヤにおいて、メンバーシップの変化について連続的に構成サービス１２２を監視する。少なくともいくつかの実施形態において、ロードバランサモジュール１３２の機能について、以下説明する。
● 接続公開−定期的に（例えば、１秒ごとに）または不定期に、それぞれのサー バノード１３０上のアクティブな接続の組み合わせ（クライアントエンドポイント、パブリックエンドポイント）を、これらの接続に対応するロードバランサモジュール１３２に対して最後にパケットを送信した入口ノードに対してだけでなく、これらの接続について責任を負う一次及び二次フロー追跡部ノードの両方に対しても公開する。接続公開の機能は、責任を負うロードバランサノード１１０における接続状態についてのリースを更新する。
● ロードバランサレイヤにおけるメンバーシップの変化の監視。メンバーシップが変化した場合には、ロードバランサモジュール１３２は、この変更情報を用いて、その接続に対してこれから責任を負うロードバランサノードに対して直ちにアクティブな接続を送信する。
分散型ロードバランシングシステムにおけるパケットフローの細部

【0068】

分散型ロードバランシングシステムは、多数のロードバランサノード１１０を有する。少なくともいくつかの実施形態において、分散型ロードバランシングシステムにおける各ロードバランサノード１１０は、サーバ１３４に対するクライアント１６０の接続に関して、フロー追跡部ノードの役割、出口ノードの役割、及び入口ノードの役割を果たす。分散型ロードバランシングシステムはまた、各サーバノード１３０上にロードバランサモジュール１３２を含む。

【0069】

少なくともいくつかの実施形態において、図１０Ａないし１０Ｇは、分散型ロードバランシングシステム内のパケットフローを示している。図１０Ａないし１０Ｇにおいて、ロードバランサノード１１０の間で交換されたパケット、及び、ロードバランサノード１１０とサーバノード１３０との間で交換されたパケットは、ＵＤＰメッセージまたはＵＤＰカプセル化されたクライアントＴＣＰパケットのいずれかである。少なくともいくつかの実施形態において、クライアントＴＣＰパケットのみが境界ルータ１０２との間で移動して、ロードバランサノード１１０の北側のネットワーク１００上にカプセル化された形式で存在する（図１を参照）。図１０Ａないし１０Ｇにおいて、矢印付きの実線はＴＣＰパケットを表わし、一方、矢印付きの点線はＵＤＰパケットを表わしていることに留意されたい。

【0070】

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

【0071】

クライアントからのＴＣＰ接続の各々はＴＣＰフローと称され、そのＴＣＰフローは、クライアントＩＰアドレス、クライアントポート、サーバ（パブリック）ＩＰアドレス、及びサーバポートからなる４タプルによって一意に識別される。この識別子は、クライアント及びパブリックエンドポイント対を示すＣＰまたはＣｃＰｐと略称される。任意の所定のＴＣＰフロー（またはＣＰ対）に関係するパケットは、上流のエッジルータ１０４からのハッシュ化等価マルチパス（ＥＣＭＰ）フロー分散のために、入口サーバ１１２として動作する任意のロードバランサノード１１０上に現れることができる。しかしながら、ＴＣＰフローに対応するパケットは、通常、転送されるＴＣＰフローを引き起こすリンクまたはロードバランサノード１１０の障害が存在しない限り、同じロードバランサノード１１０に到達し続ける。上流のルータ１０４からのＴＣＰフローに対応するパケットを受信するロードバランサノード１１０は、そのＴＣＰフローに対応する入口ノードと称される。

【0072】

少なくともいくつかの実施形態において、コンシステントハッシュ法が使用されるは、ＴＣＰフローに対して入口ノードとしての機能を果たすロードバランサノード１１０にパケットが到達した場合に、当該入口ノードがＴＣＰフローに対応する状態（すなわち、フロー追跡部ノード）を収容するのがどのロードバランサノード１１０であるかを決定することができるからである。ＣＰ対は、入口ノードによってコンシステントハッシュリングの中にハッシュ化されて、ＴＣＰフローに関する状態を維持することに責任を持っているのがどのロードバランサノード１１０であるかを決定する。このノードは、ＴＣＰフローに対して一次フロー追跡部ノードとしての機能を果たす。コンシステントハッシュリングにおける後続ノードは、ＴＣＰフローに対して二次フロー追跡部としての機能を果たす。

【0073】

少なくともいくつかの実施形態において、すべてのロードバランサノード１１０は、入口ノード、一次フロー追跡部ノード、及び二次フロー追跡部ノードとしての機能を果たす。ＴＣＰフローに対するコンシステントハッシュの結果に依存して、そのＴＣＰフローに対して入口ノードとしての機能を果たしているロードバランサノード１１０は、そのＴＣＰフローに対して一次または二次フロー追跡部ノードとしての機能も果たす。しかしながら、少なくともいくつかの実施形態において、異なる物理的なロードバランサノード１１０は、そのＴＣＰフローに対して一次及び二次フロー追跡部ノードの役割を実行する。
接続の確立

【0074】

図１０Ａを参照すると、クライアント１６０からの新たな接続は、クライアントＴＣＰ同期（ＳＹＮ）パケットによって起動される。ロードバランサノード１１０は、そのＳＹＮパケットを受信したとき、実際には、サーバノード１３０との間で接続を確立しないだけでなく、その接続を受信すべきサーバノード１３０を直ちに選択することもない。その代わり、ロードバランサノード１１０は、クライアントのＳＹＮパケットからの関連データを記憶して、まだ選択されていないサーバノード１３０の代わりにＳＹＮ／ＡＣＫパケットを生成する。図１０Ｃを参照すると、一旦クライアント１６０がＴＣＰのスリーウェイハンドシェイクにおいて最初のＡＣＫに応答すると、ロードバランサノード１１０は、サーバノード１３０を選択して、当該サーバノード１３０に対する等価なＳＹＮパケットを生成し、そのサーバノード１３０との実際のＴＣＰ接続を確立しようとする。

【0075】

再び図１０Ａを参照すると、ＴＣＰフローに対して入口サーバ１１２としての機能を果たしているロードバランサノード１１０においてクライアントＳＹＮパケットを受信すると、入口サーバ１１２は、ＳＹＮパケットからデータフィールドを抽出して、そのデータをＴＣＰフローに対する一次フロー追跡部１１６Ａに転送する。一次フロー追跡部１１６Ａは、そのデータを例えばハッシュテーブルに記憶し、（ＴＣＰ接続のサーバ側の）最初のＴＣＰシーケンス番号を生成し、同じデータを二次フロー追跡部１１６Ｂに転送する。二次フロー追跡部１１６Ｂは、そのＴＣＰシーケンス番号を含むクライアント１６０に対するＳＹＮ／ＡＣＫパケットを作成する。

【0076】

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

【0077】

図１０Ｃを参照すると、非ＳＹＮパケットが入口サーバ１１２に到達した場合には、その入口サーバ１１２は、どのサーバノード１３０にそのパケットを転送するかを知っているかまたは知らないかのいずれかである。ＴＣＰフローに対する入口サーバ１１２に到達する最初の非ＳＹＮパケットは、ＴＣＰのスリーウェイハンドシェイクにおける最初のＴＣＰ承認（ＡＣＫ）パケット（または、ことによると後続のデータパケット）のはずである。そこでは、ＴＣＰ承認番号のフィールドは、図１０ＡにおけるＳＹＮ／ＡＣＫパケットの中で送信されたサーバシーケンス番号（＋１）と一致する。入口サーバ１１２が、対応するサーバマッピングを持たない非ＳＹＮパケットを受信した場合には、入口サーバ１１２は、ＴＣＰフローに対応する一次フロー追跡部１１６Ａに対してメッセージを転送する。そのメッセージは、シーケンス番号などのＡＣＫパケットからの情報を含み、またはＡＣＫパケット自身を含む。少なくともある場合においては、一次フロー追跡部１１６Ａは、ＴＣＰフローについて記憶されたデータを覚えており、承認シーケンス番号（＋１）とＳＹＮ／ＡＣＫパケットの中でクライアント１６０に対して送信された値とが一致することを確認する。一次フロー追跡部は、その後、ＴＣＰフローに対応するサーバノード１３０を選択し、ＴＣＰフローについて以前に記憶されたデータを含む他のメッセージ、サーバシーケンス番号、及び選択されたサーバノード１３０上のロードバランサモジュール１３２についてのＩＰアドレスを、二次フロー追跡部１１６Ｂに対して転送する。二次フロー追跡部１１６Ｂは、サーバシーケンス番号を確認し、その情報を記録し、生成されたＳＹＮメッセージを選択されたサーバノード１３０上のロードバランサモジュール１３２に対して送信する。ＴＣＰフローのＣＰエンドポイント対は、この時からロードバランサモジュール１３２／サーバノード１３０にマッピングされる。サーバノード１３０上のロードバランサモジュール１３２は、二次フロー追跡部１１６Ｂから生成されたＳＹＮメッセージを受信した場合には、サーバノード１３０上のサーバ１３４に対する正当なＴＣＰ ＳＹＮパケットを作成する責任がある。ＳＹＮパケットの生成において、送信元ＩＰアドレスがクライアント１６０の実際のＩＰアドレスに追加されるのは、サーバ１３４がクライアント１６０から直接的なＴＣＰ接続要求を受信したことを信用するからである。ロードバランサモジュール１３２は、ＴＣＰフローについて関連する細部を例えばローカルなハッシュテーブルに記憶し、ＴＣＰ ＳＹＮパケットをサーバ１３４に送信する（例えば、ＳＹＮパケットをサーバ１３４のＬｉｎｕｘカーネルの中に挿入する）。

【0078】

図１０Ｃにおいて、入口サーバ１１２、一次フロー追跡部１１６Ａ、及び二次フロー追跡部１１６Ｂの役割は、異なるロードバランサノード１１０によって各々実行される。しかしながら、いくつか場合においては、ＴＣＰフローに対して入口サーバ１１２としての機能を果たしているロードバランサノード１１０は、ＴＣＰフローに対して一次フロー追跡部１１６Ａまたは二次フロー追跡部１１６Ｂとしての機能を果たしている同じノード１１０である（ただし、両方ではない）。例えば、図１０Ｄにおいて、二次フロー追跡部１１６Ｂは、ＴＣＰフローに対して入口サーバ１１２として同じロードバランサノード１１０Ａ上に存在し、一方、一次フロー追跡部１１６Ａは、異なるロードバランサノード１１０Ｂ上に存在する。

【0079】

図１０Ｅを参照すると、サーバ１３４（例えば、Ｌｉｎｕｘカーネル）は、ロードバランサモジュール１３２も中断するＳＹＮ／ＡＣＫパケットに応答する。ＳＹＮ／ＡＣＫパケットは、二次フロー追跡部１１６Ｂからの生成されたＳＹＮ／ＡＣＫにおいて、クライアント１６０に最初に配信されたＴＣＰシーケンス番号とは異なるＴＣＰシーケンス番号を含む（図１０Ａ参照）。ロードバランサモジュール１３２は、着信パケット及び発信パケットにシーケンス番号デルタを適用する責任がある。サーバ１３４からのＳＹＮ／ＡＣＫパケットもまた、ロードバランサモジュール１３２から二次フロー追跡部１１６Ｂに戻るメッセージ（例えば、ＵＤＰメッセージ）を起動して、選択されたサーバノード１３０／ロードバランサモジュール１３２／サーバ１３４に対する接続が成功したことを知らせる。二次フロー追跡部１１６Ａは、このメッセージを受信すると、クライアント１６０とサーバ１３４との間において、クライアント及びパブリックエンドポイント対（ＣＰ）マッピングを約束されたものとして記録し、ＣＰマッピングを同じように記録する一次フロー追跡部１１６Ａに対して同様のメッセージを送信する。一次フロー追跡部１１６Ａは、その後、ＣＰマッピングメッセージを入口サーバ１１２に対して転送し、このことによって、接続について任意にバッファリングされたデータパケットを、入口サーバ１１２はサーバノード１３０上のローカルロードバランサモジュール１３２に対してカプセル化されたデータパケットとして転送させる。

【0080】

図１０Ｆを参照すると、接続のためのＣＰマッピングが入口サーバに分かっているので、入口サーバ１１２によって受信された接続に関する着信ＴＣＰパケットは、（例えば、ＵＤＰに従って）カプセル化され、サーバノード１３０上のローカルロードバランサモジュール１３２に対して、カプセル化されたデータパケットとして直接に転送される。ロードバランサモジュール１３２は、データパケットをデカプセル化して、サーバノード１３０上のサーバ１３４に対し、例えば、カーネルのＴＣＰスタック上にＴＣＰパケットを挿入することによって、ＴＣＰパケットを送信する。サーバ１３４からのアウトバウンドパケットは、サーバノード１３０上のロードバランサモジュール１３２によって中断され、（例えば、ＵＤＰに従って）カプセル化され、ロードバランサモジュール１３２がこの接続に対応する出口サーバ１１４としてランダムに選択する任意のロードバランサノード１１０に対して転送される。出口サーバ１１４は、パケットをデカプセル化して、そのデカプセル化されたパケットをクライアント１１６に対して送信する。選択されたロードバランサノード１１０の出口機能はステートレスであるので、出口サーバとしての機能を果たしているロードバランサノード１１０に障害が発生した場合には、異なるロードバランサノード１１０が接続に対する出口サーバ１１４として選択されることができる。しかしながら、接続の期間中においては、アウトバウンドパケットの再配列を抑制または排除するために、通常は、同じロードバランサノード１１０が出口サーバ１１４として使用される。

【0081】

図１０Ｇを参照すると、少なくともいくつかの実施形態において、一次フロー追跡部１１６Ａによって選択されたサーバノード１３０Ａ（図１０Ｃ参照）上のロードバランサモジュール１３２Ａは、自分が過負荷であると判定した場合には、二次フロー追跡部１１６Ｂから受信された作成されたＳＹＮメッセージ（図１０Ｃ参照）を拒絶する選択権を有する。少なくともいくつかの実施形態において、作成されたＳＹＮメッセージは、生存時間（ＴＴＬ）の値または最大拒絶数をあらかじめ考慮するカウンタを含んでいる。少なくともいくつかの実施形態において、このＴＴＬの値がゼロに達した場合には、ロードバランサモジュール１３２Ａは、接続を受諾するかまたは負荷を減らすために接続を中断する。ロードバランサモジュール１３２Ａが接続を拒絶すると決定した場合には、ＴＴＬの値を減らして、拒絶メッセージを二次フロー追跡部１１６Ｂに送信する。二次フロー追跡部１１６Ｂは、ＣＰマッピングをリセットし、同じことを行うために開放メッセージを一次フロー追跡部１１６Ａに送信する。一次フロー追跡部１１６Ａは、他のサーバノード１３０Ｂ上の新たなロードバランサモジュール１３２Ｂを選択し、新たな目標メッセージを二次フロー追跡部１１６Ｂに返送し、二次フロー追跡部１１６Ｂは新たに作成されたＳＹＮメッセージを新たに選択されたロードバランサモジュール１３２Ｂに対して送信する。パケット廃棄は、このシーケンスが完了することができない結果になることに留意されたい。しかしながら、クライアント１６０からの再送は、一次フロー追跡部１１６Ａにおいてロードバランサモジュールの選択プロセスを再び起動し、一次フロー追跡部１１６Ａは、作成されたＳＹＮパケットの前回の拒絶について学習しなかった場合に、必ずしも必要ではないが、接続に対して同じロードバランサモジュール１３２を選択する。

【0082】

少なくともいくつかの実施形態において、ＴＴＬカウンタは、サーバノード１３０に対して連続的に接続要求が送信されることを回避するために使用され、このことは、例えば、すべてのサーバノード１３０がビジーである場合に発生する。少なくともいくつかの実施形態において、ロードバランサモジュール１３２がそれぞれのサーバノード１３０の代理として、接続要求を拒絶するたびに、当該ロードバランサモジュール１３２はＴＴＬカウンタを減らす。フロー追跡部ノード１１６は、ＴＴＬカウンタを監視して、ＴＴＬカウンタがゼロでない（または、ある特定の閾値を超えない）限り、他のサーバノード１３０を選択して、再度試みる。ＴＴＬカウンタがゼロに達した（または、当該特定の閾値に達した）場合には接続要求は取り下げられ、その接続のために選択されたサーバノード１３０の１つに対して接続要求を送信するためのフロー追跡部ノード１１６によってなされる試みはもはやできない。少なくともいくつかの実施形態において、エラーメッセージがそれぞれのクライアント１６０に送信される。

【0083】

少なくともいくつかの実施形態において、分散型ロードバランサシステムは、多くのパブリックＩＰアドレスをサポートする。したがって、クライアント１６０は、同じクライアントのポート番号から２つの異なるパブリックＩＰアドレスまでの２つのＴＣＰ接続を開始することが可能である。これらのＴＣＰ接続は、クライアント１６０の観点からは区別されるが、内部的には、分散型ロードバランサシステムは同じサーバノード１３０に対して接続をマッピングするので、このことで衝突を生じる結果となる。少なくともいくつかの実施形態において、衝突の可能性を検出し且つ取り扱うためには、ロードバランサモジュール１３２は、図１０Ｃ及び１０Ｄに示されるように、生成されたＳＹＮパケットを二次フロー追跡部１１６Ｂから受信すると、アドレス情報をそのアクティブな接続と比較して、この接続が衝突を引き起こす可能性がある場合には、図１０Ｇに示されるように、その接続要求を拒絶する。
ロードバランサノードの障害及び追加の取り扱い

【0084】

従来の多くのロードバランサにおいて、ロードバランサの障害が発生すると、いくつかのまたはすべての存在している接続は失われる。少なくともいくつかの実施形態では、単一のロードバランサノード１１０の障害発生において、分散型ロードバランシングシステムが少なくともいくつかの確立された接続を維持するのは、クライアント及びサーバが、接続が正常に完了するまで、接続によってパケットの交換を継続できるからである。さらに、分散型ロードバランシングシステムは、障害の時点において確立されているプロセスの中に存在していた接続に対するサービスを継続する。

【0085】

分散型ロードバランシングシステムの少なくともいくつかの実施形態において、単一のロードバランサノード１１０に障害が発生した場合に備えて、存在中のクライアント接続を回復する障害回復プロトコルが実装されている。しかしながら、多数のロードバランサノード１１０に障害が発生すると、クライアント接続の消失を招く結果となる。少なくともいくつかの実施形態において、クライアント１６０とサーバ１３４との間のＴＣＰ再送は、後続のロードバランサノード１１０の障害を回復する手段として使用される。

【0086】

潜在的なロードバランサノード１１０の障害に加えて、新たなロードバランサノード１１０が分散型ロードバランサシステムに追加される。これらの新たなノード１１０は、ロードバランサレイヤに、したがって、コンシステントハッシュリングに追加され、存在中のクライアント接続に関するロードバランサノード１１０の役割は、必要に応じて、当該変更に従って調整される。
フロー追跡部ノードの障害及び追加の取り扱い

【0087】

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

【0088】

図１１Ａないし１１Ｄは、少なくともいくつかの実施形態において、ロードバランサノードコンシステントハッシュリングにおいてメンバー構成に影響する事象の取り扱いを示す。これらの事象は、新たな一次フロー追跡部ノードの追加、新たな二次フロー追跡部ノードの追加、一次フロー追跡部ノードの障害、及び二次フロー追跡部ノードの障害を含んでいるが、これらに限定されない。

【0089】

図１１Ａは、コンシステントハッシュリングへの新たな一次フロー追跡部ノードの追加の取り扱いを示す。図１１Ａの上位の並びは、１以上のクライアント接続に対する一次フロー追跡部としてのフロー追跡部１１６Ａ、及び同じ接続に対する二次フロー追跡部としてのフロー追跡部ノード１１６Ｂを示す。図１１Ａの下位の並びにおいて、新たなフロー追跡部ノード１１６Ｃが追加されており、クライアント接続に対する一次フロー追跡部になっている。コンシステントハッシュリングにおいて、以前は一次フロー追跡部であったフロー追跡部ノード１１６Ａは、二次フロー追跡部になり、一方、以前は二次フロー追跡部であったフロー追跡部ノード１１６Ｂは、次のフロー追跡部になっている。フロー追跡部１１６Ａ及び１１６Ｂによって維持されていたクライアント接続に対する状態情報は、新たな一次フロー追跡部１１６Ｃに提供される。さらに、フロー追跡部１１６Ｂは、二次フロー追跡部の役割において、自分が以前追跡していた接続を「忘れる」。

【0090】

図１１Ｂは、コンシステントハッシュリングへの新たな二次フロー追跡部ノードの追加の取り扱いを示す。図１１Ｂの上位の並びは、１以上のクライアント接続に対する一次フロー追跡部としてのフロー追跡部１１６Ａ、及び同じ接続に対する二次フロー追跡部としてのフロー追跡部ノード１１６Ｂを示す。図１１Ｂの下位の並びにおいて、新たなフロー追跡部ノード１１６Ｃが追加されており、クライアント接続に対する二次フロー追跡部になっている。コンシステントハッシュリングにおいて、フロー追跡部ノード１１６Ａは、接続に対する一次フロー追跡部として残り、一方、以前は二次フロー追跡部であったフロー追跡部ノード１１６Ｂは、次のフロー追跡部になる。フロー追跡部１１６Ａ及び１１６Ｂによって維持されていたクライアント接続に対する状態情報は、新たな二次フロー追跡部１１６Ｃに提供される。さらに、フロー追跡部１１６Ｂは、二次フロー追跡部の役割において、自分が以前追跡していた接続を「忘れる」。

【0091】

図１１Ｃは、コンシステントハッシュリングにおいて、一次フロー追跡部ノードの障害の取り扱いを示す。図１１Ｃの上位の並びは、コンシステントハッシュリングにおいて、１以上のクライアント接続に対する一次フロー追跡部としてのフロー追跡部１１６Ａ、同じ接続に対する二次フロー追跡部としてのフロー追跡部ノード１１６Ｂ、及び次のフロー追跡部としてのフロー追跡部ノード１１６Ｃを示す。図１１Ｃの下位の並びにおいて、一次フロー追跡部ノード１１６Ａには障害は発生している。フロー追跡部ノード１１６Ｂは、接続に対して一次フロー追跡部になり、一方、フロー追跡部ノード１１６Ｃは、接続に対して二次フロー追跡部になる。フロー追跡部１１６Ｂによって維持されていたクライアント接続に対する状態情報は、新たな二次フロー追跡部１１６Ｃに提供される。

【0092】

図１１Ｄは、コンシステントハッシュリングにおいて、二次フロー追跡部ノードの障害の取り扱いを示す。図１１Ｄの上位の並びは、コンシステントハッシュリングにおいて、１以上のクライアント接続に対する一次フロー追跡部としてのフロー追跡部１１６Ａ、同じ接続に対する二次フロー追跡部としてのフロー追跡部ノード１１６Ｂ、及び次のフロー追跡部としてのフロー追跡部ノード１１６Ｃを示す。図１１Ｄの下位の並びにおいて、二次フロー追跡部ノード１１６Ｂには障害は発生している。フロー追跡部ノード１１６Ａは、接続に対する一次フロー追跡部として残り、一方、フロー追跡部ノード１１６Ｃは、接続に対して二次フロー追跡部になる。フロー追跡部１１６Ｂによって維持されていたクライアント接続に対する状態情報は、新たな二次フロー追跡部１１６Ｃに提供される。

【0093】

少なくともいくつかの実施形態において、サーバノード１３０上のロードバランサモジュール１３２は、ロードバランサノード１１０に対して接続公開を実行する。少なくともいくつかの実施形態において、接続公開は、サーバノード１３０からフロー追跡部ノード及び入口ノードとしての機能を果たしているロードバランサノード１１０に対して、現在の接続状態情報を定期的（例えば、１秒ごとに）または不定期に推し進める。当該接続公開は、接続に対する一次及び二次フロー追跡部ノードの両方に対する接続マッピングを更新または回復する役割を果たす。少なくともいくつかの実施形態において、ロードバランサモジュール１３２は、例えば、図１１Ａないし１１Ｄに示されるようなフロー追跡部のメンバーシップの変化を検出する。検出に応答して、ロードバランサモジュール１３２は、一次及び二次フロー追跡部ノードにおける接続に対する状態情報を追加するために接続公開を実行し、それによって、メンバーシップが変化した場合には、接続に対する変更を行う。接続公開は、多数のロードバランサノードに障害が発生した場合に、少なくともいくつかの確立された接続が回復できることに留意されたい。
障害に関するメッセージフロー

【0094】

少なくともいくつかの実施形態において、一次及び二次フロー追跡部ノードの間のプロトコルには、訂正機能または同期機能が含まれる。例えば、図１１Ａを参照すると、新たなフロー追跡部ノード１１６Ｃがコンシステントハッシュリングに加わった場合には、当該新たなフロー追跡部ノード１１６Ｃは、いくつかの接続数（〜１／Ｎ）に関するコンシステントハッシュのキー空間に対して権利を主張し、エッジルータ１０４からのこれらの接続に関するトラフィックの受信を開始する。しかしながら、当該新たなフロー追跡部ノード１１６Ｃは、接続のために記憶された状態をなにも持っていないので、フロー追跡部ノード１１６Ｃは、各パケットに対してあたかもクライアント１６０から受信された最初のパケットであるかのように操作する。一次フロー追跡部は、ＳＹＮパケットに応答してサーバＴＣＰシーケンス番号を生成する責任があり（例えば、図１０Ａ参照）、且つ、クライアント１６０からの最初のＡＣＫパケットに応答してサーバノード１３０を選択する責任があり（例えば、図１参照）、これら生成された値は、以前の一次フロー追跡部（図１１Ａにおけるフロー追跡部ノード１１６Ａ）によって選択された値と一致しない。しかしながら、少なくともいくつかの実施形態におけるコンシステントハッシュアルゴリズムは、以前の一次フロー追跡部（図１１Ａにおけるフロー追跡部ノード１１６Ａ）に対して二次フロー追跡部の役割を割り当て、このフロー追跡部は接続について以前に記憶された状態をなおも保持する。したがって、少なくともいくつかの実施形態において、二次フロー追跡部（図１１Ａにおけるフロー追跡部ノード１１６Ａ）が、一次フロー追跡部１１６Ｃから受信された情報の中に不一致を検出した場合には、二次フロー追跡部は、更新メッセージを一次フロー追跡部１１６Ｃに返送して、接続に対してフロー追跡部としての機能を果たしている２つのロードバランサノード１１０を同期させることができる。同様の方法は、コンシステントハッシュリングのメンバー構成において他の変化があった後にフロー追跡部を同期させるために使用される。
ロードバランサモジュールの詳細

【0095】

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

【0096】

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

【0097】

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

【0098】

少なくともいくつかの実施形態において、サーバノード１３０上のロードバランサモジュール１３２の機能は、以下の１以上を含む、これらに限定されない。
● ロードバランサノード１１０、例えば、クライアント１６０に対する接続を取り扱っている入口サーバ１１２からのＵＤＰトンネルを終端すること。これは、入口サーバ１１２から受信した着信クライアントデータパケットのＵＤＰカプセルを外すことを含む。
● 接続に関する発信トラフィックを受信する出口サーバ１１４を選択すること。
● それぞれのサーバ１３４に対する接続上の発信ＩＰパケットを中断すること、接続に関する出力ＩＰパケットをカプセル化すること、及び当該カプセル化されたパケットを出口サーバ１１４に送信すること。
● 着信及び発信パケット内のシーケンス番号を分解するのは、フロー追跡部ノード１１６がクライアント１６０に対してＳＹＮ／ＡＣＫを送信した際に、シーケンス番号をフロー追跡部ノード１１６によって生成されたシーケンス番号に揃えるからである。
● それぞれのサーバ１３４に対する接続を受諾するかまたは拒絶するかどうかについて、例えば、それぞれのサーバ１３４の現在の負荷を示す１以上のメトリクスに基づいて決定すること。
● クライアントＩＰポートアドレスに対するアクティブな接続が存在する場合に、衝突を回避するために、それぞれのサーバ１３４に対する同じクライアントＩＰポートアドレスからの接続を検出すること及び拒絶すること。
● 接続追跡及び接続公開。
ロードバランサモジュールの構成情報

【0099】

少なくともいくつかの実施形態において、ロードバランサモジュール１３２の各々は、自分の構成に関する１つ以上の情報の組み合わせ、すなわち、ロードバランサノード１１０のエンドポイントの組み合わせ、対応すべき有効なパブリックＩＰアドレスの組み合わせ、及び、それぞれのサーバ１３４が着信接続を受諾するポート番号を取得してローカルに記憶する。ただし、これらの情報に限定するものではない。少なくともいくつかの実施形態において、この情報は、図１に示されるように、分散型ロードバランサシステムの構成サービス１２２の構成要素から取得され、またはアクセス処理若しくは問い合わせ処理によって更新される。いくつかの実施形態においては、情報を取得する他の方法が使用される。
ロードバランサモジュールのパケット取り扱い

【0100】

少なくともいくつかの実施形態におけるインバウンドトラフィック及びアウトバウンドトラフィックに対するロードバランサモジュール１３２の操作について、以下説明する。少なくともいくつかの実施形態において、ロードバランサモジュール１３２によってインバウンドデータトラフィックが受信された場合には、そのデータパケットは、ＵＤＰパケットからデカプセル化されて、そのデカプセル化されたＴＣＰパケット内の宛先アドレスは、構成された有効なパブリックＩＰアドレスの組み合わせに対して最初に確認される。一致しない場合には、パケットは廃棄されるかまたは無視される。少なくともいくつかの実施形態において、ロードバランサモジュール１３２は、シーケンス番号がクライアント１６０に対してＳＹＮ／ＡＣＫパケットを送信したフロー追跡部ノード１１６によって生成されてランダムに選択されたシーケンス番号と一致するように、ＴＣＰヘッダにおいて定数デルタによってシーケンス番号を調整する。ロードバランサモジュール１３２は、「クライアント対パブリック」エンドポイントから「クライアント対サーバ」エンドポイントまでのマッピングを内部状態として記録する。

【0101】

少なくともいくつかの実施形態において、ロードバランサモジュール１３２は、サーバ１３４からのアウトバウンドＴＣＰパケットに関して、その内部状態を最初にチェックして、そのパケットはロードバランサモジュール管理しているアクティブな接続に対するものかどうかを判定する。アウトバウンドＴＣＰパケットがアクティブな接続でない場合には、ロードバランサモジュール１３２は、パケットをすぐに通過させる。アウトバウンドＴＣＰパケットがアクティブな接続である場合には、ロードバランサモジュール１３２は、発信ＴＣＰパケットを、例えば、ＵＤＰに従って、カプセル化して、この接続に対して出口サーバ１１４として選択されたロードバランサノード１１０に対して、そのカプセル化されたパケットを転送する。少なくともいくつかの実施形態において、ロードバランサモジュール１３４は、クライアント１６０に対してＳＹＮ／ＡＣＫパケットを送信したフロー追跡部ノード１１６によって生成されたシーケンス番号に揃えるように、ロードバランサモジュール１３４は、発信ＴＣＰパケットにおいて定数デルタによってＴＣＰシーケンス番号を調整する。
接続追跡
少なくともいくつかの実施形態において、各サーバノード１３０上のロードバランサモジュール１３２は、それぞれのサーバ１３４に対するアクティブなクライアント接続のすべてに関する接続の詳細を含んでいるハッシュテーブルを管理する。少なくともいくつかの実施形態において、ハッシュテーブルに対するキーは、（クライアントＩＰポート、パブリックＩＰポート）タプルである。少なくともいくつかの実施形態において、各クライアント接続に関する接続状態は、以下に示す１以上のものを含むが、これらに限定されない。
● クライアントＩＰポート
● パブリックＩＰポート
● フロー追跡部ノード１１６によって提供された初期サーバＴＣＰシーケンス番号
● サーバＴＣＰシーケンス番号のデルタ
● 最初の一次フロー追跡部ＩＰアドレス
● 最初の二次フロー追跡部ＩＰアドレス
● 最後に検出された入口サーバ１１２のＩＰアドレス
● このエントリに対する有効期限
● 最も過去に使用された（ＬＲＵ）／衝突インデックス

【0102】

少なくともいくつかの実施形態において、各ロードバランサモジュール１３２は、すべてのアクティブなクライアント接続に関して、一次及び二次フロー追跡部ノードに対する接続公開メッセージを定期的に生成する。少なくともいくつかの実施形態において、/ｐｒｏｃ/ｎｅｔ/ｔｃｐの内容が、スキャンされ且つロードバランサモジュールのハッシュテーブルの中で、アクティブな接続と交差するのは、Ｌｉｎｕｘカーネルが接続の追跡を停止するまで、アクティブな接続がフロー追跡部ノードに対する公開を継続するからである。接続公開については、本明細書の中において後で詳細に説明する。
シーケンス番号の分解処理

【0103】

上記したように、少なくともいくつかの実施形態において、ロードバランサノード１１０は、クライアント１６０のＳＹＮパケットに応答して、ＳＹＮ／ＡＣＫパケットをサーバ１３４の代理として生成する。クライアント１６０がＡＣＫパケット（ＴＣＰのスリーウェイシェイクハンド）を送信した後のみしか、ロードバランサモジュール１１０は、サーバノード１３０上のロードバランサモジュール１３２に対して任意のデータを送信することはない。ロードバランサモジュール１３２がクライアント接続を確立することを最初に指示された場合には、ロードバランサモジュール１３２は、ローカルにＳＹＮパケットを生成してサーバノード１３０上のサーバ１３４との間でＴＣＰ接続を開始し、サーバ１３４の対応ＳＹＮ／ＡＣＫパケットを中断する。通常、サーバ１３４（例えば、サーバノード１３０上のＬｉｎｕｘカーネル）は、ロードバランサノード１１０からのＳＹＮ／ＡＣＫパケットにおいて受信されたクライアントのものとは全体的に異なるＴＣＰシーケンス番号を選択する。したがって、少なくともいくつかの実施形態においては、ロードバランサモジュール１３２は、クライアント１６０とサーバ１３４との間のＴＣＰ接続におけるすべてのパケット内のシーケンス番号に対して訂正を行う。少なくともいくつかの実施形態において、ロードバランサモジュール１３２は、ロードバランサノード１１０によって生成されたシーケンス番号とサーバ１３４によって生成されたシーケンス番号との差分を計算して、ＴＣＰ接続に対するハッシュテーブルのエントリに差分をデルタ値として記憶する。接続中にクライアント１６０から着信データパケットが到達した場合には、ＴＣＰヘッダは、サーバ１３４によって使用されるシーケンス番号と整合しない承認番号を有することになるので、ロードバランサモジュール１３２は、（例えば、２つの補数を用いて）ＴＣＰヘッダ内のシーケンス番号の値からデルタ値を減算する。ロードバランサモジュールはまた、接続中にサーバ１３４からクライアント１３０に対するアウトバウンドパケット内のシーケンス番号にデルタ値を加算する。
分散型ロードバランサシステムにおけるヘルスチェック

【0104】

分散型ロードバランサシステムの少なくともいくつかの実施形態において、以下に示す理由の少なくとも一つから、ロードバランサノード１１０は、ロードバランサの実装（すなわち、健康なロードバランサノード１１０及びサーバノード１３０の）において健康なメンバーの一貫した表示を要求する。
● ロードバランシング―ロードバランサノード１１０は、サーバノード１３０の障害を検出し、クライアントトラフィックを受諾できる健康なサーバノード１３０の組み合わせに集中する必要がある。
● 分散化状態の管理−ロードバランサは、（例えば、コンシステントハッシュ法のメカニズムに従って）多数のロードバランサノード１１０に亘って共有され／複製される状態を有する分散型システムである。クライアントトラフィックを適切に取り扱うために、各ロードバランサノード１１０は、ロードバランサの実装において健康なメンバーノード１１０の一貫した表示を必要とする。

【0105】

このことを達成するために、分散型ロードバランサシステムの少なくともいくつかの実施形態において、ロードバランサの実装においてノードを監視するヘルスチェックプロトコルの実施形態を実現して、できるだけ速く不健康なノードを検出する。ヘルスチェックプロトコルは、ロードバランサの実装においてノード間に健康情報を伝搬して、それらのノードが健康なノードの組み合わせに集中することを可能にする方法を提供する。さらに、ヘルスチェックプロトコルは、ロードバランサの実装において、健康な／不健康なノード及び状態の変化を報告するメカニズムを提供する。

【0106】

少なくともいくつかの実施形態において、ヘルスチェックプロトコルは、以下に示す１つ以上の仮定に基づく。しかし、これらに限定されるものではない。
● ロードバランサの実装において、すべてのノードが分かっている（すなわち、ヘルスチェックプロトコルは、発見することを実行しない）。
● すべてのノードの障害はフェイルストップである。
● ノード間のすべてのメッセージは、ステートレスプロトコル（例えば、ＵＤＰ）メッセージであり、当該メッセージは、削除され、遅延され、複製され、または破損される。メッセージ配信についての保障はない。

【0107】

少なくともいくつかの実施形態では、ロードバランサの実装におけるノード（例えば、ロードバランサノード１１０またはサーバノード１３０）は、以下に示す条件のもとでは健康であると見なされる。
● ノードの内部の構成要素のすべてが準備状態（クライアントトラフィックを取り扱うための準備）である。
● （少なくともクライアント・トラフィックフローに関するネットワーク・インターフェイス制御部（ＮＩＣ）についての）ノードの着信／発信ネットワークリンクが健康である。

【0108】

図１２は、少なくともいくつかの実施形態において、ヘルスチェック間隔に従った各ロードバランサノードによって実行されるヘルスチェック方法の上位のフローチャートである。１０００に示されるように、各ロードバランサの間隔、例えば、１００ミリ秒ごとに、各ロードバランサ（ＬＢ）ノード１１０は、少なくとも１つの他のＬＢノード１１０及び少なくとも１つのサーバノード１３０のヘルスチェックをする。１００２に示されるように、ロードバランサノード１１０は、ヘルスチェックに従って、ローカルに記憶された自分の健康情報を更新する。１００４に示されるように、ロードバランサノード１１０は、その後、少なくとも１つの他のロードバランサノード１１０をランダムに選択して、選択されたロードバランサノード１１０に対して自分の健康情報を送信する。少なくともいくつかの実施形態において、ノード１１０はまた、１以上のサーバノード１３０、例えば、ノード１１０によってヘルスチェックされた同じサーバノード１３０に対して、健康なロードバランサノード１１０のリストを送信する。図１２の要素については、以下、詳細に説明する。

【0109】

ヘルスチェックプロトコルの少なくともいくつかの実施形態において、ロードバランサノード１１０は自分自身の健康を他のロードバランサノード１１０に主張することはない。これと反対に、１以上の他のロードバランサノード１１０は、当該ノード１１０にヘルスチェックを行う。例えば、少なくともいくつかの実施形態において、各ロードバランサノード１１０は、定期的または不定期にランダムに１以上の他のノード１１０を選択して、ヘルスチェックを行う。他の実施例のように、少なくともいくつかの実施形態において、１以上の他のロードバランサノード１１０、例えば、コンシステントハッシュリングなどのノード１１０の順序付けリスト中の或る所定のロードバランサノード１１０に最も近くに隣接する２つは、それぞれ定期的または不定期に当該所定のノード１１０のヘルスチェックをする。少なくともいくつかの実施形態において、ノード１１０のヘルスチェックは、図２３に示されるように、ノード１１０上のＮＩＣ１１１４に対して送信される健康ｐｉｎｇの使用を含む。少なくともいくつかの実施形態において、第１のノード１１０がヘルスチェックを介して第２のノード１１０が健康であると判定した場合には、当該第１のノード１１０は、当該ロードバランサノード１１０におけるローカルな健康情報に記憶されている当該第２のノード１１０についての心拍カウンタを更新（例えば、インクリメント）する。第１のノード１１０は、自分のローカルな健康情報を、ロードバランサ実装における１以上の他のロードバランサノード１１０に対して定期的または不定期に送信し、これによって、適宜自分自身のローカルな健康情報を（例えば、第２のノードについての心拍カウンタをインクリメントすることによって）更新し、自分の更新されたローカルな健康情報を、１以上の他のノード１１０に対して送信する。第２のノード１１０についての心拍情報は、その後、ロードバランサ実装における他のノード１１０に対して伝搬される。第２のノード１１０が健康である限り、第２のノード１１０から到達可能な他のすべてのノード１１０はしたがって、常にインクリメントされている第２のノード１１０の心拍カウンタを、例えば、１秒に１度または毎１０秒に１度、監視する必要がある。第２のノード１１０のヘルスチェックをするノード（複数可）１１０によって、第２のノード１１０が不健康であることが検出された場合には、ヘルスチェックをしているノード１１０によって当該ノード１１０についての心拍は送信されず、ある時間の閾値の後、ロードバランサ実装１１０内の他のノード１１０は、当該ノード１１０が不健康であるかまたは故障中であると見なす。

【0110】

少なくともいくつかの実施形態において、ロードバランサノード１１０は、自分自身の内部状態の１以上の態様をチェックして、当該ノード１１０がなんらかの理由で不健康であることを検出した場合には、当該ノード１１０は、自分の健康をチェックする他のノード１１０からの健康ｐｉｎｇに対する応答を停止する。したがって、当該不健康なノード１１０をチェックしているノード１１０は、当該ノード１１０が不健康であると見なし、当該ノード１１０の代理として心拍インクリメントを伝搬することはない。
＜ヘルスチェックプロトコルの詳細＞

【0111】

少なくともいくつかの実施形態において、ヘルスチェックプロトコルは、心拍カウンタ技法及び喧伝プロトコル技術を活用する。ヘルスチェックプロトコルは、２つの主要な部分を有すると見なされる、すなわち、ヘルスチェック及び喧伝／障害検出である。

【0112】

ヘルスチェック−ロードバランサ実装内のすべてのロードバランサノード１１０は、実装中の１以上の他のノード１１０を定期的または不定期にヘルスチェックする。１以上の他のノードが判定される方法については、後述する。ヘルスチェックの基本的な考え方は、ノード１１０が他のノード１１０の健康をチェックして、当該他のノード１１０が健康であると判定した場合には、当該チェックをしているノード１１０は、当該他のノード１１０についての心拍カウンタをインクリメントし且つ伝搬することによって、当該他のノード１１０が健康である旨を主張する。言い換えれば、ノード１１０は自分自身が健康であると他のノード１１０に対して主張しない代わりに、１以上の他のノード１１０はロードバランサ実装内の各ノード１１０の健康をチェックして且つそれを主張する。

【0113】

喧伝／障害検出−少なくともいくつかの実施形態において、ヘルスチェックプロトコルは、喧伝プロトコルを活用して、ロードバランサ実装内のメンバーのロードバランサノード１１０の中にロードバランサノード１１０の健康情報を伝搬する。喧伝プロトコルは、迅速に収束して、分散型ロードバランシングシステムの目的のための十分な最終的な一貫性の保証を提供する。少なくともいくつかの実施形態において、各ロードバランサノード１１０は、喧伝プロトコルを使用することにより、ロードバランサ実装内の他のノード１１０の各々についての心拍カウンタを、例えば、心拍リストの中で維持する。各ロードバランサノード１１０は、上記したように、定期的または不定期に少なくとも１つの他のロードバランサノード１１０のヘルスチェックを実行し、チェックされたノード１１０が健康であることをヘルスチェックによって判定したときは、ノード１１０についての心拍カウンタをインクリメントする。少なくともいくつかの実施形態において、各ロードバランサノード１１０は、定期的または不定期にランダムに、ロードバランサ実装内の少なくとも１つの他のノード１１０を選択して、当該他のノード１１０に対して自分の現在の心拍リストを送信する。ロードバランサノード１１０は、他のノード１１０から心拍リストを受信すると、２つのリスト（受信されたリスト及び自分自身のリスト）内の各ノードについての最大心拍カウンタを判定することによって、且つ、判定された最大心拍カウンタを自分自身の心拍リストにおいて使用することによって、受信されたリスト内の心拍情報と自分自身の心拍リストとを統合する。そして今度は、この心拍リストがランダムに選択された他のノード１１０に送信され、これによって適宜、自分自身の心拍リストを更新し、と同じように続く。この技法を使用すれば、健康なノード１１０の各々についての心拍情報は、最終的に（例えば、数秒間に）ロードバランサ実装内のすべての他のロードバランサノード１１０に伝搬される。所定のロードバランサノード１１０についてその心拍カウンタの増加が続く限り、当該所定のロードバランサノードは、他のノード１１０によって健康であると見なされる。ロードバランサノード１１０の心拍カウンタが、ヘルスチェック及び喧伝処理方法によって、特定の期間にインクリメントされない場合には、他のロードバランサノード１１０は、不健康であると見なされたロードバランサノード１１０に集中する。
ロードバランサノードのヘルスチェック

【0114】

少なくともいくつかの実施形態において、他のロードバランサノード１１０によって実行されるロードバランサノード１１０に対するヘルスチェックの方法について、以下説明する。図２３を参照すると、少なくともいくつかの実施形態において、或るロードバランサノード１１０は、以下の条件のうち１つ以上が当該ノード１１０について判定された場合には、健康であると見なされる。
● ノード１１０のプロセッサスレッド（例えば、基本的なパケット処理コード１１０８スレッド）が準備状態（内部）である。
● ノード１１０がエッジルータ１０４のＩＰアドレス及び／またはＭＡＣアドレス（内部）を知っている。
● ノード１１０におけるすべてのスレッド及び／またはプロトコルハンドらがレディ状態（内部）である。
● 北側（エッジルータ１０４／境界ネットワーク）からの着信リンク及び南側（サーバ１３０／生産ネットワーク）からの出力リンクがアクティブ（外部）である。
● ノード１１０が、ロードバランサ実装内で使用されるネットワーク・インターフェイス制御部（ＮＩＣ）を介して、パケットを受信し且つ送信できる。例えば、図２３に示されるように、例示的なロードバランサノード１１０の実施形態において、ノード１１０は、北向きのＮＩＣ１１１４Ａ及び南向きのＮＩＣ１１１４Ｂを介して、連続的にパケットを良好に受信し且つ送信する。

【0115】

これらの健康条件の１つ以上が、所定のノード１１０において保持されない場合には、当該ノード１１０は健康でないと見なされる。いくつかの実施形態においては、ノード１１０が健康であると見なされるのは、上記条件のすべてが当該ノード１１０において保持されている場合のみであることに留意されたい。

【0116】

少なくともいくつかの実施形態において、上記健康条件に加えて、例えば、コントロールプレーン通信のために使用される各ロードバランサノード１１０上のＮＩＣ１１１４Ｃとして、図２３において示される第３のＮＩＣも、当該ＮＩＣに対してパケットを送信すること且つ当該ＮＩＣからパケットを受信することによりヘルスチェックをしているノード１１０によってチェックされ、第３のＮＩＣのチェックが失敗した場合には、チェックされているノード１１０は不健康と見なされる。

【0117】

図１３は、少なくともいくつかの実施形態において、他のロードバランサノードからロードバランサノードに対するヘルスチェックの例示的な方法を示す。この実施例において、ロードバランサノード１１０Ａは、ロードバランサノード１１０Ｂに対してヘルスチェックを行っている。ノード１１０Ａ及び１１０Ｂの各々は、北向きのＮＩＣ（図２３におけるＮＩＣ１１１４Ａ）及び南向きのＮＩＣ（図２３におけるＮＩＣ１１１４Ｂ）を有する。１で、ノード１１０Ａは、自分の北向きのＮＩＣからノード１１０Ｂの北向きのＮＩＣに対して、エッジルータ１０４を介してパケット（例えば、ｐｉｎｇパケット）を送信する。ノード１１０Ｂは、リストにおいて与えられた上記条件が十分な場合には、自分の北向きのＮＩＣ上でパケットを受信して、２で、自分の北向きのＮＩＣからファブリック１２０を介して、ノード１１０Ａの北向きのＮＩＣに対して応答を送信する。ノード１１０Ａは、応答を自分の北向きのＮＩＣ上で受信した後、３で、自分の南向きのＮＩＣからノード１１０Ｂの南向きのＮＩＣに対して、ファブリック１２０を介してパケット（例えば、ｐｉｎｇパケット）を送信する。ノード１１０Ｂは、リストにおいて与えられた上記条件が十分な場合には、自分の南向きのＮＩＣにおいてパケットを受信して、４で、自分の南向きのＮＩＣからノード１１０Ａの南向きのＮＩＣに対して、エッジルータ１０４を介して応答を送信する。ノード１１０Ａは、自分の南向きのＮＩＣ上で応答を受信すると、ノード１１０Ｂを健康であると見なし、ノード１１０Ｂのローカルな心拍カウンタをインクリメントし、これによって、上記した喧伝プロトコルに従って、他のノード１１０に伝搬される。

【0118】

いくつかの実施形態において、上記に代わる手段として、ロードバランサノード１１０Ｂは、自分の北向きのＮＩＣで受信された第１のｐｉｎｇメッセージに対して、自分の南向きのＮＩＣを介してノード１１０Ａの南向きのＮＩＣに応答し、自分の南向きのＮＩＣで受信された第２のｐｉｎｇメッセージに対して、自分の北向きのＮＩＣを介してノード１１０Ａの北向きのＮＩＣに応答する。

【0119】

さらに、いくつかの実施形態において、ノード１１０Ａもまた、自分自身の第３のＮＩＣからノード１１０Ｂの第３のＮＩＣをｐｉｎｇ処理することによって、且つ、ノード１１０Ｂが健康である場合にノード１１０Ｂの第３のＮＩＣから自分の第３のＮＩＣ上のｐｉｎｇメッセージに対する応答を受信することによって、コントロールプレーン通信（図２３におけるＮＩＣ１１１４Ｃとして示される）のために使用されるノード１１０Ｂの第３のＮＩＣに対してヘルスチェックを行う。ｐｉｎｇメッセージ及び応答は、１つ以上のコントロールプレーン装置１７０、例えば、ネットワークスイッチを通過する。

【0120】

上記説明したヘルスチェックメカニズムは、ノード１１０ＢのすべてのＮＩＣだけでなく、（北、南、及びコントロールプレーンを通過する）すべての方向において、着信リンク、発信リンク、及びノード１１０Ｂのデータ経路のすべてを動かし、さらにｐｉｎｇパケットが内部の待ち行列を渉るときのノード１１０Ｂの内部の健康、及び、クライアントパケットとしての可能性があるときのノード１１０Ｂの送信を検証する。
＜ロードバランサノードに対するヘルスチェック責任の割り当て＞

【0121】

少なくともいくつかの実施形態において、ロードバランサ実装内のすべてのロードバランサノード１１０は、例えば、構成機能によって及びまたは図１に示す構成サービス１２２の構成要素によって、ロードバランサ実装内の他のすべてのロードバランサノード１１０のリスト（例えば、ソートされたリスト）に対するアクセスを有する。少なくともいくつかの実施形態において、各ロードバランサノード１１０は、リスト上の１以上の他のノード１１０をランダムに選択して、ヘルスチェック間隔ごとにヘルスチェックを行い、健康であると判定された場合にそれらの心拍カウンタをインクリメントする。リストは、ロードバランサ実装内のすべてのロードバランサノード１１０が、ヘルスチェックメカニズムを介して、現在、健康と見なされているかまたは不健康と見なされているかどうかということを含み、及び、健康なノード１１０だけでなく、現在、不健康なノード１１０がリストからランダムに選択されて且つヘルスチェックされることに留意されたい。したがって、現在、不健康なノード１１０は、当該ノード１１０に対してヘルスチェックする１以上のノード１１０によって健康であることが判定され、それの心拍カウンタがインクリメントされて、他のノード１１０に伝搬されると、当該不健康なノード１１０は健康な状態に戻る。

【0122】

あるいは、いくつかの実施形態においては、各ロードバランサノード１１０は、リストの中の１以上の他のノード１１０に対してヘルスチェックをすること、及び健康であると判定された場合にはそれらの心拍カウンタをインクリメントすることに対する責任を負う。例えば、いくつかの実施形態において、各ノード１１０は、２つの他のノード、例えば、リストの中で、自分の「左」（または前）及び「右」（または、次）の最も近くの隣接ノード１１０をヘルスチェックする責任を負う。リストは環状と見なされ、リストの「最後」にあるノード１１０は、リストの「先頭」にあるノード１１０をヘルスチェックする責任を負い、逆もまた然りであることに留意されたい。いくつかの実施形態においては、２つの他のノード１１０は、他の方法で、例えば、リスト上の次の最も近くの２つの隣接ノードとして選択される。いくつかの実施形態においては、各ノード１１０は、リスト上で２より大きい他のノード１１０、例えば、３または４の他のノード１１０をヘルスチェックする責任を負う。少なくともいくつかの実施形態において、或るノード１１０によってチェックされている隣接ノード１１０が不健康であると判定された場合には、当該ノード１１０は、当該不健康な隣接ノード１１０がチェックする責任を負っていたリスト上で少なくとも１つのノードをヘルスチェックする責任を負う。少なくともいくつかの実施形態において、自分の隣接ノード１１０（例えば、「左」及び「右」の隣接ノード）のヘルスチェックに加えて、各ロードバランサノード１１０はまた、定期的または不定期的にランダムにリングの中のノード１１０を選択して、当該選択されたノード１１０のヘルスチェックを実行し、それが健康である場合には、当該ランダムなノード１１０の心拍をインクリメントして伝搬する。少なくともいくつかの実施形態において、順序付きリスト中のすべての他のノード１１０は、当該他のノード１１０が以前に健康または不健康と見なされたかどうかにかかわらず、ランダムな選択及びヘルスチェックの対象と見なされる。

【0123】

少なくともいくつかの実施形態において、各ノード１１０は、１以上のランダムに選択されたノード１１０に対してヘルスチェックを実行するか、またはその代わりに自分の隣接ノード１１０及びランダムに選択されたノードに対して、ヘルスチェック間隔と称される一定間隔でヘルスチェックを実行する。例えば、いくつかの実施形態において、心拍間隔は１００ミリ秒であるが、さらに短いまたは長い間隔が使用される。さらに、少なくともいくつかの実施形態において、各ノード１１０は、自分の現在の心拍リストを少なくとも１つの他のランダムに選択されたノード１１０に対して、喧伝間隔と称される一定間隔で送信または「喧伝」する。いくつかの実施形態において、ヘルスチェック間隔と喧伝間隔とは同じであるが、必ずしも同じでなくてもよい。

【0124】

図１４は、少なくともいくつかの実施形態において、１以上のロードバランサノードに対するロードバランサノードのヘルスチェックをグラフィカルに示す。この実施例においては、ロードバランサ実装中に８つのロードバランサノード１１０Ａ〜１１０Ｈが存在する。点線の円は実装中のすべてのノード１１０の順序付きリストを表わす。いくつかの実施形態において、各ノード１１０は、リスト上で１以上のノード１１０をランダムに選択して、各々の間隔でヘルスチェックを行う。また、いくつかの実施形態において、各ロードバランサノード１１０は、順序付きリスト上の１以上の特定のノード１１０に対してチェックの責任を負い、例えば、ノード１１０Ａは、図１４に示される順序付きリストに従って、自分に最も近い２つの隣接ノード１１０Ｂ及び１１０Ｈに対してヘルスチェックの責任を果たす。さらに、ロードバランサノードはまた、順序付きリストからランダムに他のノード１１０をヘルスチェック間隔毎に選択する。この実施例に示されるように、ノード１１０Ａは、ランダムにノード１１０Ｆを選択してヘルスチェックをする。喧伝間隔では、ノード１１０Ａは、いくつかの他の健康なノード１１０、例えば、ノード１１０Ｄをランダムに選択して、その現在の心拍リストを選択された他のノード１１０に対して、例えば、ＵＤＰメッセージの中で送信する。ノード１１０は、他のノード１１０から心拍リストを受信すると、それに従って、自分自身の心拍リストを更新し、当該心拍リストを１以上のランダムに選択されたノード１１０に対して、次の喧伝間隔で伝搬する。
サーバノードのヘルスチェック

【0125】

上記したようなロードバランサノード１１０に対するヘルスチェックに加えて、ヘルスチェックプロトコルの実施形態は、ロードバランサモジュール１３２を含んでいるサーバノード１３０及びサーバノード１３０上のサーバ１３４に対するヘルスチェックを実行する。少なくともいくつかの実施形態において、サーバノード１３０は、以下に示す１つまたは両方の条件が当該ノード１３０のために決定された場合には、健康であると見なされる。
● ロードバランサモジュール１３２が健康である。
● サーバノード１３０が健康ｐｉｎｇ（例えば、Ｌ７健康ｐｉｎｇ）に応答するのに成功する。

【0126】

図１５は、少なくともいくつかの実施形態において、サーバノードに対してヘルスチェックをするロードバランサノードを示す。少なくともいくつかの実施形態において、ロードバランサ実装中のすべてのロードバランサノード１１０は、ロードバランサ実装中のすべてのサーバノード１３０のリストだけでなく、ロードバランサ実装中のすべての他のロードバランサノード１１０のリストに対するアクセスを有する。リストは、例えば、構成機能を介して及び／または図１に示される構成サービス１２２の構成要素を介して、取得され且つ更新される。少なくともいくつかの実施形態において、サーバノード１３０は、図１５に示されているように、健康なロードバランサノード１１０に対してコンシステントハッシュ化を行って、図１５に示されるようなコンシステントハッシュリングを形成する。少なくともいくつかの実施形態において、リング内の各サーバノード１３０は、リング内の２つの健康なロードバランサノード１１０によってヘルスチェックされる。例えば、図１５において、サーバノード１３０Ａは、ロードバランサノード１１０Ａ及び１１０Ｃによってヘルスチェックされる。これら２つのノード１１０は、コンシステントハッシュリングにおいて、サーバノード１３０に対する第１（ノード１１０Ａ）及び第２（ノード１１０Ｂ）のヘルスチェックノード１１０と称される。所定の健康なロードバランサノード１１０は、１より大きいサーバノード１３０をヘルスチェックすることに留意されたい。例えば、図１５において、ロードバランサノード１１０Ａはまた、サーバノード１３０Ｂ及び１３０Ｃをヘルスチェックする。さらに、所定のロードバランサノード１１０は、１以上のサーバノード１３０に対しては第１のヘルスチェックノード１１０であり、１以上の他のサーバノード１３０に対しては第２のヘルスチェックノード１１０である。例えば、図１５において、ロードバランサノード１１０Ａは、サーバノード１３０Ａ及び１３０Ｂに対しては第１のヘルスチェックノードであり、サーバノード１３０Ｃ及び１３０Ｄに対しては第２のヘルスチェックノードである。

【0127】

少なくともいくつかの実施形態において、ロードバランサノード１１０に障害が発生した場合には、コンシステントハッシュリング上のメンバーシップが変わるが、依然として健康な、したがって、依然としてコンシステントハッシュリング上にある１以上の他のロードバランサノード１１０は、当該障害が発生したノード１１０によって以前にヘルスチェックされたサーバノード１３０に対するヘルスチェックの責任を負う。

【0128】

少なくともいくつかの実施形態において、健康なノード１１０の各々は、サーバチェック隔と称される一定間隔で、自分が割り当てられたサーバノード１３０に対するヘルスチェックを実行する。少なくともいくつかの実施形態において、サーバチェック間隔は、上記説明した喧伝間隔より大きいかまたは喧伝間隔と同じである。

【0129】

少なくともいくつかの実施形態において、サーバノード１３０に対するヘルスチェックを実行するために、健康なロードバランサノード１１０（例えば、図１５におけるノード１１０Ａ）は、サーバノード１３０（例えば、図１５におけるサーバノード１３０Ａ）に対して、健康ｐｉｎｇメッセージ（例えば、Ｌ７ ＨＴＴＰ健康ｐｉｎｇメッセージ）を開始する。サーバノード１３０は、健康である場合には、ロードバランサノード１１０に対してｐｉｎｇ応答を返送する。少なくともいくつかの実施形態において、ｐｉｎｇメッセージは、サーバノード１３０上のロードバランサモジュール１３２によって受信され且つ処理されるので、ヘルスチェックｐｉｎｇは、成功すると、サーバノード１３０上のモジュール１３２が健康であると確証する。ロードバランサノード１１０は、当該ｐｉｎｇに対する応答を受信すると、サーバノード１３０を健康であると見なして、サーバノード１３０についての心拍カウンタをインクリメントする。

【0130】

少なくともいくつかの実施形態において、所定の健康なロードバランサノード１１０によってヘルスチェックされたすべてのサーバノード１３０についての心拍カウンタは、他のロードバランサノード１１０に伝搬されるが、それは、例えば、ロードバランサノード１１０の心拍カウンタについて以前に説明した喧伝技法において、各ノード１１０が自分の心拍リストを少なくとも１つの他のランダムに選択されたノード１１０に一定間隔（喧伝間隔）で送信し、受信するノード１１０が自分自身の心拍リストを２つのリストにおける最大値に基づいて更新するという技法に従ってなされる。
障害検出及び喧伝

【0131】

少なくともいくつかの実施形態において、上記したロードバランサノード１１０のヘルスチェック及びサーバノード１３０のヘルスチェックを介して得られた情報は、ロードバランサ実装の中のすべてのノード１１０に伝搬されることを必要とするのは、すべてのロードバランサノード１１０がロードバランサ実装の中の一貫した表示を維持できるからである。上記したように、少なくともいくつかの実施形態において、ロードバランサノード１１０は、喧伝プロトコルに従って互いに通信して、この健康情報を交換し且つ伝搬し、ロードバランサノード１１０及びサーバノード１３０の障害を検出する。

【0132】

少なくともいくつかの実施形態において、各ロードバランサノード１１０は、（喧伝間隔と称される）一定間隔で、他のロードバランサノード１１０をランダムに選択し、ロードバランサノード１１０及びサーバノード１３０についての心拍カウンタとともに、健康なロードバランサノード１１０及びサーバノード１３０についての自分の表示を他のノード１１０に送信する。ロードバランサノードまたはサーバノード１３０は健康である限り、当該ノードは自分のヘルスチェックを合格にし、且つ自分の心拍カウンタは増加を続ける。ノードについての心拍カウンタが、（障害時間間隔と称される）特定間隔において変化しない場合には、当該ノードは、ロードバランサノード１１０によって障害が発生したと疑われる。一旦ノードに障害が発生したと疑われると、ロードバランサノード１１０は、当該ノードが不健康であることを判定する前に、（不健康時間間隔と称される）特定間隔の間待つ。この不健康時間間隔は、すべてのロードバランサノード１１０が当該ノードに障害が発生してしまったことを知るまで、ロードバランサノード１１０が待つことを許可する。

【0133】

図１６は、少なくともいくつかの実施形態において、ロードバランサノード１１０によって維持される（ロードバランサノード１１０またはサーバノード１３０のいずれかの）他のノードの健康に関する状態、またはその表示をグラフィカルに表示する。３００に示されるように、ロードバランサノード１１０が、この問題となるノードが健康であると表示することからスタートすると仮定する。このことは、当該ノードについての心拍カウンタが増加されてきたことを示す。しかしながら、３０２に示されるように、当該ノードの心拍カウンタが特定間隔（障害時間間隔）において増加しない場合には、３０４に示されるように、ロードバランサノード１１０は当該ノードに障害が発生してしまったのではないかと疑う。３０６に示されるように、当該ノードの心拍カウンタが、特定間隔（不健康時間間隔）において増加しない場合には、３０８に示されるように、ロードバランサノード１１０は当該ノードが不健康であると見なす。しかしながら、３１０に示されるように、不健康時間間隔が無効になる前に、当該ノードについての心拍カウンタがインクリメントする場合には、ロードバランサノード１１０は、再び当該ノードが健康な３００であると見なす。同様に、３１２に示されるように、不健康なノードに関して心拍のインクリメントを受信した場合には、当該ノードは健康な３００として見なされることができる。

【0134】

ノードが不健康であるということを判定することは、当該不健康なノードがロードバランサノード１１０であるかまたはサーバノード１３０であるかに依存して、さらにロードバランサノード１１０と不健康なノードとの関係にも依存して、ロードバランサノード１１０による異なる動作を含むが、これについては本明細書の他のところで説明する。
ロードバランサノードのデータ

【0135】

少なくともいくつかの実施形態において、各ロードバランサノード１１０は、ロードバランサ実装の状態に関するデータを維持する。少なくともいくつかの実施形態において、このデータは、各ロードバランサノード１１０上で、健康なロードバランサノードのリスト、疑わしいロードバランサノードのリスト、及び心拍リストが含まれる１以上のデータ構造において維持される。ただし、含まれるものはこれらに限定されない。図１７は、健康なロードバランサノードのリスト３２０、疑わしいロードバランサノードのリスト３２２、不健康なロードバランサノードのリスト３２４、及びロードバランサノードの心拍リスト３２６を維持する例示的なロードバランサノード１１０を示す。

【0136】

少なくともいくつかの実施形態において、各ロードバランサノード１１０は、健康なロードバランサノードのリスト３２０を維持するが、そのリストは、例えば、どのノード１１０が健康であり、したがって喧伝プロトコルに参加しているかどうかを判定するために使用される健康なロードバランサノード１１０のリストである。リスト３２０上のノード１１０のみが、喧伝プロトコルを介してロードバランサ情報の伝搬に含まれ、リスト３２０上のノード１１０のみが、コンシステントハッシュリング内に存在すると見なされ、及びこのリスト上のノード１１０のみが、サーバノード１３０をヘルスチェックする。ノード１１０は、このリスト３２０からランダムに他のノード１１０を選択して、当該選択されたノードに対して自分の心拍情報が送信される。さらに、心拍カウンタは、現在、健康なロードバランサノードのリスト３２０に存在するノード１１０に対してのみ交換される。少なくともいくつかの実施形態において、ロードバランサノードＮは、ノードＮがロードバランサノード１１０によるヘルスチェックに合格する場合、または、ロードバランサノード１１０がノードＮに関する喧伝メッセージをリスト３２０上のいくつかの他のロードバランサノード１１０から受信する場合には、他のロードバランサノード１１０の健康なロードバランサノードリスト３２０に追加されることができる。

【0137】

少なくともいくつかの実施形態において、各ロードバランサノード１１０は、疑わしいロードバランサノードのリスト３２２を維持するが、そのリストは、心拍カウンタ（心拍リスト３２６参照）が（障害時間間隔と称される）特定間隔において増加されなかったロードバランサノードのリストである。ロードバランサノードＥが、ロードバランサノード１１０の疑わしいロードバランサノードのリスト３２２に存在する場合には、ロードバランサノード１１０はノードＥに関して喧伝しない。健康なリスト３２０上のいくつかの他のロードバランサノード１１０が、ノード１１０の心拍リスト３２６内のノードＥにおける心拍カウンタよりも高い心拍カウンタを有するノードＥに関してロードバランサノード１１０に対して喧伝する場合には、ノードＥは疑わしいリスト３２２から健康なリスト３２０に移動される。ノードＥが、（不健康時間間隔と称される）特定間隔において、ロードバランサノード１１０の疑わしいリスト３２２上に留まる場合には、ノードＥはロードバランサノード１１０によって不健康であると見なされ、不健康なノードのリスト３２４に移動される。不健康なノードのリスト３２４上のノード１１０（この実施例では、ノードＧ）は、ノードＧがノード１１０によるヘルスチェックに合格した場合、または、他のノード１１０からノードＧに関する更新された心拍カウンタを受信した場合には、ロードバランサノード１１０の健康なノードのリスト３２０に移動される。

【0138】

少なくともいくつかの実施形態において、各ロードバランサノード１１０は、すべての知られているロードバランサノード１１０についての心拍リスト３２６を維持する。各ノード１１０に関して、このリスト３２６は、心拍カウンタ及び当該心拍カウンタが最後に変化した時を示すタイムスタンプを含む。

【0139】

少なくともいくつかの実施形態において、各ロードバランサノード１１０は、図１７には示されていないが、すべての知られているサーバノードについての心拍リストも維持する。このリストは、ロードバランサノードの心拍リスト３２６に類似している。いくつかの実施形態においては、２つのリストが組み合わされる。少なくともいくつかの実施形態において、サーバノード１３０についての心拍情報は、例えば、喧伝プロトコルに従って、ロードバランサノード１１０についての心拍情報とともに、またはこれに加えて、ロードバランサノード１１０の中に伝搬される。

【0140】

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

【0141】

少なくともいくつかの実施形態において、ノード１３０上のサーバノード１３０及びローカルロードバランサモジュール１３２は、ロードバランサノード１１０とともに喧伝プロトコル内に参加することはない。ロードバランサノード１１０は、ロードバランサノードのヘルスチェック方法によって得られた他のロードバランサノード１１０についての心拍情報、及び、自分達自身の中のみのサーバノードヘルスチェック方法によって得られたサーバノード１３０についての心拍情報を喧伝する（特に、各ロードバランサノード１１０は、現在、自分の健康なロードバランサノードのリスト３２０上のノードのみに対して喧伝する）。

【0142】

しかしながら、各サーバノード１３０／ロードバランサモジュール１３２がロードバランサ実装における健康なロードバランサノード１１０に関する情報を必要とするのは、サーバノード１３０が、発信クライアントトラフィクをサーバノード１３０が転送することができるロードバランサノード１１０（特に、出口ノード）を決定することができ、且つ、接続公開情報が送信されるロードバランサノードをどれにするかを決定することができるからである。少なくともいくつかの実施形態において、この情報をサーバノード１３０に対して提供するために、ロードバランサノード１１０は、現在、健康なロードバランサノード１１０を識別する情報（例えば、図１７における健康なロードバランサノードのリスト３２０）を有するサーバノード１３０を定期的または不定期に更新する。少なくともいくつかの実施形態において、所定のサーバノード１３０（図１５参照）をヘルスチェックすることに対して責任を負うロードバランサノード１１０は、サーバノード１３０に対して、現在、健康なロードバランサノードを識別する情報を提供する責任を負う。例えば、図１５を参照すると、ロードバランサノード１１０Ａは、自分の健康なロードバランサノードのリスト３２０をサーバノード１３０Ａ、１３０Ｂ、１３０Ｃ、及び１３０Ｄに対して送信し、ロードバランサノード１１０Ｂは、自分の健康なロードバランサノードのリスト３２０をサーバノード１３０Ｃ、１３０Ｄ、及び１３０Ｅに対して送信する、と同じように続く。
ロードバランサノードの障害の取り扱い

【0143】

図１８Ａ及び１８Ｂは、少なくともいくつかの実施形態において、ロードバランサノードの障害の取り扱い処理を示す。図１８Ａは、例示的なロードバランサ実装を示す。ロードバランサ実装には、４つのロードバランサノード１１０Ａないし１１０Ｄが存在する。エッジルータ１０４は、クライアント（図示せず）からの着信パケットをロードバランサノード１１０にルーティングする。少なくともいくつかの実施形態において、エッジルータ１０４は、レイヤ４のフロー単位ハッシュ化マルチパス・ルーティング技法、例えば、等価マルチパス（ＥＣＭＰ）ルーティング技法に従って、ルーティングを決定する。少なくともいくつかの実施形態において、エッジルータ１０４は、ロードバランサ実装において現在使用できるロードバランサノード１１０について学び、ロードバランサノード１１０の広告、例えば、ロードバランサノード１１０によって開始された境界ゲートウェイ・プロトコル（ＢＧＰ）技術セッションによる広告を介して、クライアントトラフィックを受信する。しかしながら、少なくともいくつかの実施形態において、ロードバランサノード１１０はＢＧＰセッションを介してエッジルータ１０４に対して自分自身を広告する代わりに、ロードバランサ実装の中の少なくとも１つの他のノード１１０が、ＢＧＰを介してエッジルータ１０４に対してノード１１０を広告する責任を果たす。例えば、図１８Ａにおいて示されるようないくつかの実施形態においては、所定のノード１１０の左及び右の隣接ノード１１０が、当該所定のノード１１０をエッジルータ１０４に対して広告する。例えば、ロードバランサノード１１０Ａはノード１１０Ｂ及び１１０Ｄを広告し、ロードバランサノード１１０Ｂはノード１１０Ａ及び１１０Ｃを広告し、ロードバランサノード１１０Ｃはノード１１０Ｂ及び１１０Ｄを広告する。

【0144】

図１８Ａに示されるように、各ロードバランサノード１１０はまた、１以上の他のロードバランサノード１１０、例えば、１以上のランダムに選択されたノード１１０、ロードバランサノードの順序付きリストによって決定された１以上の隣接ノード１１０、または１以上の隣接ノード及び１以上のランダムに選択されたノードを定期的にヘルスチェックする。さらに、各ロードバランサノード１１０は、少なくとも１つのサーバノード１３０を定期的にヘルスチェックし、健康なロードバランサノード１１０の自分のリストを、それをヘルスチェックするサーバノードに対しても送信する。ロードバランサノード１１０及びサーバノード１３０に関する健康情報は、例えば、喧伝プロトコルに従って、ノード１１０の中に伝搬される。

【0145】

図１８Ｂは、図１８Ａの例示的なロードバランサ実装において、単一のロードバランサノード１１０における障害の取り扱いを示す。この実施例において、ロードバランサノード１１０Ｂは何らかの理由で障害を発生している。例えば、ノード１１０Ａ及び１１０Ｃはノード１１０Ｂをヘルスチェックし、両方がそのヘルスチェックでノード１１０Ｂに障害があることを検出する。したがって、ノード１１０Ａ及び１１０Ｃは、ノード１１０Ｂについての心拍カウンタをインクリメントしない。ノード１１０Ａ及び１１０Ｂの両方からの心拍情報は、喧伝プロトコルに従って、他の健康なロードバランサノード１１０（この実施例においては、他のロードバランサノードはノード１１０Ｄのみである）に伝搬される。すべての健康なロードバランサノード１１０（この実施例においては、ノード１１０Ａ、１１０Ｃ及び１１０Ｄ）は、ノード１１０Ｂの障害に集中するとすぐに、１以上の以下に示すイベントが発生するが、これらに限定されない。これらのイベントは、必ずしもこの順序では発生するものではないことに留意されたい。
● ノード１１０Ａ及び１１０Ｃは、エッジルータ１０４に対してしているノード１１０Ｂの広告を停止する。少なくともいくつかの実施形態において、このことは、ノード１１０Ｂを広告するために、ノード１１０がエッジルータ１０４と確立したＢＧＰセッションを終了することを含む。各ノード１１０は、各他のノード１１０を広告するために、エッジルータ１０４と独立したＢＧＰセッションを確立するので、ノード１１０Ｂに関するＢＧＰセッションを終了することは、広告されている他のノード１１０には影響を及ぼさないことに留意されたい。少なくともいくつかの実施形態において、ノード１１０は、ＴＣＰ ＣｌｏｓｅまたはＢＧＰセッションに関する同様のメッセージをエッジルータ１０４に対して送信することによって、エッジルータ１０４とのＢＧＰセッションを終了する。
● ノード１１０Ｂが、もはやどのノードによっても広告されていないことの検出に応答して、エッジルータ１０４は、ノード１１０Ｂに対するクライアントデータパケットのルーティングを停止する。エッジルータ１０４はまた、マルチパス（例えば、ＥＣＭＰ）ハッシングも調整して、クライアントからのパケットフローを残りの健康なロードバランサノード１１０に対して、特に、当該ノード１１０上の入口サーバ１１２に対して再分散する。入口サーバ１１２に対してルーティングされていた任意のパケットフローに関して、当該入口サーバ１１２はクライアントからサーバへの対応するマッピングを持っていないので、当該マッピングはクライアントからサーバへの接続に関係するフロー追跡部ノードから得られるか、または、その代わりに、新たなクライアントからサーバへの接続が図１０Ａないし１０Ｇに示された技法に従って確立される。
● ノード１１０Ａ及び１１０Ｃは、それぞれエッジルータ１０４に対してＢＧＰセッションを開いてお互いを広告する。ノード１１０Ａ及び１１０Ｃの両方とも、ノード１１０Ｂと同様に、ロードバランサノード１１０Ｄによってエッジルータ１０４に広告されているので、ノード１１０Ｂに障害が発生した場合に、ノード１１０Ｂがエッジルータ１０４に対するノード１１０Ａ及び１１０Ｂの広告を停止する事実は、エッジルータ１０４がこれら２つのノード１１０に対してパケットをルーティングすることを停止する原因にはならないことに留意されたい。
● 少なくともいくつかの実施形態において、ノード１１０Ａ及び１１０Ｃは、互いにヘルスチェックに対する責任を果たすが、それらは今や隣接ノード１１０だからである。ノード１１０Ｂは不健康であると見なされているにもかかわらず、今なお、１以上の他のノード１１０によってランダムにヘルスチェックがなされることに留意されたい。
● １以上の残りの健康なロードバランサノード１１０は、ノード１１０Ｂによって以前にフロー追跡されていた接続をフロー追跡することに対して責任を負う。例えば、ノード１１０Ｃ及び／またはノード１１０Ｄは、ノード１１０Ｂが一次または二次フロー追跡部であった１以上の接続に対して、図１１Ｃ及び１１Ｄに示されているように、一次または二次フロー追跡部として引き継ぐ。
● １以上の残りの健康なロードバランサノード１１０は、ノード１１０Ｂによって以前にヘルスチェックされていたサーバノード１３０をヘルスチェックする責任を負う。サーバノード１３０は、残りのロードバランサノード１１０によって、（今やノード１１０Ｂを含まない）健康なロードバランサノードのリストで更新される。例えば、図１８Ｂにおいて、ロードバランサノード１１０Ａはサーバノード１３０Ｃのヘルスチェック及び更新を開始し、ロードバランサノード１１０Ｃはサーバノード１３０Ｂのヘルスチェック及び更新処理を開始する。
● エッジルータ１０４上において、障害のあるノード１１０ＢからのＢＧＰセッションは、最終的にはタイムアウトになる。また、エッジルータ１０４は、ノード１１０Ｂに障害が発生したことを認識すると、ＢＧＰセッションを終了する。

【0146】

２つのロードバランサノード１１０が同時にまたはほぼ同時に障害になり得る可能性がある。２つのロードバランサノードが互いに隣接していない場合には、その障害は独立しており、図１８Ｂにおいて示された方法に従って、独立した単一のノード１１０の障害として取り扱う。しかしながら、障害になった２つのノードが互いに隣接している場合（例えば、図１８Ａにおけるノード１１０Ｂ及び１１０Ｃ）には、すべての健康なロードバランサノード１１０（この実施例においては、ノード１１０Ａ及び１１０Ｄ）は障害を検出し且つ障害に集中するとすぐに、以下に示す１つ以上のイベントが発生するが、これらには限定されない。これらのイベントは、必ずしもこの順序で発生するものではないことに留意されたい。
● ノード１１０Ａは、エッジルータ１０４に対してノード１１０Ｂに関するＢＧＰセッションを終了する。
● ノード１１０Ｄは、エッジルータ１０４に対してノード１１０Ｃに関するＢＧＰセッションを終了する。
● ノード１１０Ａ及び１１０Ｄは、エッジルータ１０４とのＢＧＰセッションを開始してお互いを広告する。
● ノード１１０Ａ及び１１０Ｄは、お互いのヘルスチェックを開始する。ノード１１０Ａ及び１１０Ｄはまた、障害のあるノード１１０のヘルスチェックを継続することに留意されたい。
● 残りの健康なノード１１０は、健康なロードバランサノードのリストでサーバノード１３０を更新する。
● エッジルータ１０４からノード１１０Ｂ及び／またはノード１１０Ｃへのトラフィックは流れを継続する。何故なら、これら２つのノード１１０は、エッジルータ１０４に対してお互いに広告を継続しているからである。しかしながら、これらのＢＧＰセッションは最終的にはタイムアウトになり、エッジルータ１０４は、適宜残りの広告されているノード１１０に対してフローを再分散することになる。
● ノード１１０Ｂ及び１１０Ｃは、今なおノード１１０Ｂ及び１１０Ｃが健康であると考えている場合には、エッジルータ１０４との間でノード１１０Ａ及び１１０Ｄを広告する自分たちのＢＧＰセッションをていねいに閉じる。
接続公開

【0147】

再び図１を参照すると、少なくともいくつかの実施形態において、ロードバランサ実装におけるロードバランサノード１１０は、サーバ１３０に対するクライアントＴＣＰ接続に関する状態情報を維持する。この状態情報は、ロードバランサノード１１０が、エッジルータ１０４からの着信クライアントパケットをＴＣＰ接続に対して責任のあるサーバノード１３０に対してルーティングできるようにする。サーバノード１３０上のロードバランサモジュール１３２は、自分たちのそれぞれのサーバ１３４に対するアクティブなＴＣＰ接続のリストを維持する。接続公開は、メカニズムであり、それを介して、サーバノード１３０上のロードバランサモジュール１３２がアクティブなＴＣＰ接続についての自分たちのリストをロードバランサノード１１０に対して公開する。少なくともいくつかの実施形態において、接続公開のパケットは、接続公開間隔と称される一定間隔で、ロードバランサモジュール１３２によって形成され、ロードバランサノード１１０に対して公開される。

【0148】

少なくともいくつかの実施形態において、ロードバランサノード１１０によって維持される接続状態情報は、キャッシュの形態とし見なされ、特定の接続についての状態情報を維持することは、当該接続に対するロードバランサノード１１０上のリースを維持することと見なされる。キャッシュエントリが一新されない限り、ロードバランサノード１１０は、データフローを取り扱うサーバノード１３０に対するクライアントデータフローのルーティングができない。接続公開のメカニズムは、ロードバランサノード１１０上のキャッシュ及び、それゆえリースをサーバノード１３０からの現在の接続状態情報で定期的に一新するので、クライアント１６０から適切なサーバノード１３０に対するＴＣＰパケットのフロー処理を維持する。クライアント１６０がサーバ１３４に対するＴＣＰ接続を終了したときは、サーバノード１３０上で当該接続に関連しているロードバランサモジュール１３２は、アクティブな接続についての自分のリストから当該接続を中断し、したがって、接続公開のメカニズムを通じたＴＣＰ接続はもはや公開しない。したがって、接続（特に、接続に対する入口サーバ１１２並びに一次及び二次フロー追跡部１１６）に関連しているロードバランサノード１１０上で接続（１つまたは複数のキャッシュエントリ）に対応する接続状態情報は、もはや一新されず、接続はロードバランサノード１１０によって中断される。少なくともいくつかの実施形態において、接続に対応する１つまたは複数のキャッシュエントリは、メモリがいくつかの他のアクティブな接続を要求するまでは、ロードバランサノード１１０上のキャッシュの中に残る。

【0149】

このように、接続公開のメカニズムは、定期的または不定期に、入口サーバ１１２並びに一次及び二次フロー追跡部１１６上の接続リースを延長して、クライアントトラフィックの流れを継続する。さらに、接続公開のメカニズムは、少なくともいくつかのロードバランサノード１１０の障害から回復するのに役立つ。クライアント接続の状態情報を保持している１以上のロードバランサノード１１０が失敗した場合には、接続公開によって残りのロードバランサノード１１０に供給されているアクティブな接続情報は、あるいくつかの場合には、接続を回復するために使用される。

【0150】

接続公開のメカニズムを使用すれば、サーバノード１３０は、サーバ１３４とクライアント１６０との間の接続の状態に関する信頼できる送信元になる。さらに、サーバ１３４に対する接続を閉じることは、サーバノード１３０上のロードバランサモジュール１３２及びロードバランサノード１１０によって受動的に取り扱われる。サーバノード１３０とロードバランサノード１１０との間では、ハンドシェイクは必要でない。言い換えれば、ロードバランサモジュール１３２は、特定の接続が閉じられているノードを積極的に通知するために、ロードバランサノード１１０に対してメッセージを送信する必要はない。サーバ１３４が接続を閉じた場合には、サーバ１３４は当該接続に関する自分の内部状態を消去する。ロードバランサモジュール１３２は、サーバ１３４の内部状態を用いて、接続公開パケットを追加する。サーバ１３４の内部状態の中には当該接続はもはや存在しないので、当該接続は、ロードバランサノード１１０に対して公開されることはない。このため、ロードバランサノード１１０上の当該接続に関するリースは失効し、ロードバランサノード１１０は、当該接続について受動的に忘れる。したがって、ロードバランサノード１１０のキャッシュにおいて当該接続のために使用されていたメモリは、必要に応じて、他の接続のために使用されることが可能になる。

【0151】

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

【0152】

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

【0153】

図１９Ａ及び１９Ｂは、少なくともいくつかの実施形態において、接続公開の技法をグラフィカルに示す。図１９Ａは、ロードバランサノードに対して、アクティブな接続情報を公開しているロードバランサ（ＬＢ）モジュールを示す。少なくともいくつかの実施形態において、各ロードバランサモジュール１３２は、サーバノード１３０上でアクティブなＴＣＰフローの各々に対する情報を収集して、接続公開パケットを形成する。所定のＴＣＰフローに対する情報は、当該フローに対して入口サーバ１１２としての機能を果たしているロードバランサノード１１０を識別する情報を含む。接続公開の準備ができた場合（例えば、接続公開間隔に到達した時）には、上記したように、ロードバランサモジュール１３２は、例えば、サーバノード１３０をヘルスチェックするロードバランサノード１１０からサーバノード１３０に対して定期的に送信される健康なロードバランサノード１１０のリストから、ランダムにロードバランサノード１１０を選択する。ロードバランサモジュール１３２は、次に、選択されたノード１１０に対して、接続公開パケットを送信する。例えば、図１９Ａにおいて、ロードバランサモジュール１３２Ａは、ロードバランサノード１１０Ａに対して１つの接続公開パケットを送信し、後でロードバランサノード１１０Ｂに対してもう１つの接続公開パケットを送信する。

【0154】

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

【0155】

５０２に示されるように、ロードバランサモジュール１３２は、（１以上の接続公開エントリで、１つのエントリが各アクティブなＴＣＰ接続に対応する）接続公開パケットを送信すべきロードバランサノード１１０をランダムに選択する。少なくともいくつかの実施形態において、ロードバランサモジュール１１０は、ロードバランサモジュール１３２が送信準備のできた接続公開パケットを決定したときに、ランダムに選択される。少なくともいくつかの実施形態において、この決定は、接続公開間隔に従って行われる。限定されない実施例として、接続公開間隔は、１００ミリ秒（ｍｓ）、または１秒である。少なくともいくつかの実施形態において、ロードバランサモジュール１１０は、ロードバランサノード１１０の１つから以前に受信された健康なロードバランサノード１１０のリストから選択される。５０４に示されるように、ロードバランサモジュールは次に、選択されたロードバランサノード１１０に対して、接続公開パケットを公開する。少なくともいくつかの実施形態において、接続公開パケットは、ステートレスパケット、例えば、ＵＤＰパケットである。いくつかの実施形態では、接続公開パケットは、目標のロードバランサノード１１０に対して当該パケットを送信する前に圧縮される。少なくともいくつかの実施形態において、接続公開情報は、目標のロードバランサノード１１０に対して、２以上のパケットの中で送信される。

【0156】

要素５０４から要素５００に戻る矢印に示されるように、ロードバランサモジュール１３２は、連続的に接続公開パケットを構築し、ランダムにノード１１０を選択し、当該パケットを当該選択されたノードに送信する。上記したように、このことは、ロードバランサノード１１０が現在のアクティブな接続情報により相対的且つ規則的に更新されて、ロードバランサノード１１０上の接続リースを維持するように、接続公開間隔に従って実行される。

【0157】

少なくともいくつかの実施形態において、接続公開パケットは、ロードバランサモジュールによってロードバランサノード１１０に対してランダムに分散されるので、当該接続公開パケットを受信するロードバランサノード１１０は、当該接続公開パケット内のアクティブな接続情報を当該接続のための適切な入口／一次／二次ノード１１０に対して分散することに責任がある。図１９Ｂ及び、図２１及び２２は、少なくともいくつかの実施形態において使用されるアクティブな接続情報の分散方法を示す。

【0158】

図１９Ｂは、少なくともいくつかの実施形態において、アクティブな接続情報をロードバランサノード１１０の中に分散することを示す。ロードバランサノード１１０がロードバランサモジュール１３２から接続公開パケットを受信した場合には、ロードバランサノード１１０は、当該フローに対応する入口ノード及び一次及び二次フロー追跡部ノードを決定するために、そこに示された各ＴＣＰフローに関する情報を分析する。ロードバランサノード１１０がフローに関するそれらの役割の１つを果たしている場合には、ロードバランサノード１１０は、当該フローに関する情報を消費する（例えば、状態情報に関する自分のキャッシュを更新することによって）。少なくともいくつかの実施形態において、ロードバランサノード１１０はまた、当該フローに関する他の役割を果たしている１以上の他のノード１１０に対して送信されるパケットの中に、当該フローに関する情報を配置する。接続公開パケットによって示されている残りのフローについて、ロードバランサノード１１０は、アクティブな接続情報を２以上のもっと小さなパケットに分割して、１以上の他のロードバランサノード１１０に送信する。例えば、少なくともいくつかの実施形態において、１以上のフローに関するアクティブな接続情報を有するパケットは、当該フローに対して入口サーバ１１２、一次フロー追跡部１１６Ａ、及び二次フロー追跡部１１６Ｂとしての機能を果たしているロードバランサノード１１０に送信される。

【0159】

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

【0160】

図２１の要素５２２ないし５３０において、ロードバランサモジュール１１０は、受信された接続公開パケットにおいて示されているアクティブなＴＣＰ接続情報を繰り返し処理する。５２２に示されているように、ロードバランサノード１１０は、パケットの中の次のＴＣＰフローにおけるエントリを分析して、それぞれのＴＣＰフローに対応する入口ノード１１０及び一次及び二次フロー追跡部ノード１１０を決定する。少なくともいくつかの実施形態において、ロードバランサノード１１０は、接続公開エントリから入口ノード１１０のアイデンティティを取得する。少なくともいくつかの実施形態において、ＴＣＰフローに対応する一次及び二次フロー追跡部ノード１１０は、コンシステントハッシュ機能に従って決定される。５２４において、ロードバランサノード１１０が検査されているＴＣＰフローに対する役割の１つで機能を果たしている場合には、５２６において、ロードバランサノード１１０は、例えば、状態情報に関する自分のキャッシュを更新することによって、フローに関する情報を消費する。５２８に示されているように、ロードバランサノード１１０は、他のロードバランサノード１１０に対して送信されるべく組み立てられているパケットに、ＴＣＰフローに対する接続公開エントリを追加する。５３０において、接続公開パケットの中にさらなる接続公開エントリが存在する場合には、方法は５２２に戻って、次のエントリを処理する。そうでない場合には、ロードバランサノードは、５３２に示されているように、最初の接続公開パケットからの接続公開エントリのサブセットを各々が含む新たに組み立てられたパケットを、当該パケットに対応する目標のロードバランサノード１１０に送信する。少なくともいくつかの実施形態において、目標のロードバランサノード１１０に送信されたパケットは、ステートレスパケット、例えば、ＵＤＰパケットである。いくつかの実施形態において、パケットは、目標のロードバランサノード１１０に当該パケットが送信される前に圧縮される。

【0161】

したがって、少なくともいくつかの実施形態では、図２１の要素５２２ないし５２８において、フロー追跡部ノード１１０は、受信された接続公開パケットにおける接続公開エントリから５２２で決定される情報に従って、他のノード１１０の特定の１つに各々が送信される１以上のパケット（例えば、ＵＤＰパケット）を組み立てる。少なくともいくつかの実施形態において、他のノード１１０に送信されるパケットは、目標のノード１１０が入口ノード１１０、一次フロー追跡部ノード１１０、または二次フロー追跡部ノード１１０としての機能を果たしているＴＣＰフローについてのエントリを含む。いくつかの実施形態において、所定のロードバランサノード１１０は、ＴＣＰフローに対して入口ノード及び一次フロー追跡部ノードの両方としの機能を果たし、またはＴＣＰフローに対して入口ノード及び二次フロー追跡部ノードの両方としての機能を果たすことに留意されたい。

【0162】

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

【0163】

したがって、ロードバランサモジュール１３２から接続公開パケットを受信するロードバランサノード１１０は、当該接続公開パケットを、他のロードバランサノード１１０のうち特定のものに固有の２以上のより小さなパケットに分割し、それに応じて、当該パケットを分散するが、一方、現在、当該ロードバランサノード１１０によって取り扱われている任意のＴＣＰフローに関するフロー情報を内部で消費する。その間に、他のロードバランサノード１１０もまた、ロードバランサモジュール１３２から接続公開パケットを受信しており、接続公開エントリを多数のより小さいパケットに分割し、当該より小さいパケットを目標のノード１１０に分散して、これによりアクティブな接続情報をノード１１０の中に分散する。
接続公開のトリガ

【0164】

少なくともいくつかの実施形態において、接続公開は、１以上の異なるイベントによってロードバランサモジュール１３２上でトリガされる。前述のように、いくつかの実施形態において、接続公開パケットは生成されて、接続公開間隔、例えば、１００ミリ秒または１秒の間隔に従って、ランダムに選択されたロードバランサノード１１０に対して送信されて、ロードバランサノード１１０上のＴＣＰ接続に対するリースを一新する。いくつかの実施形態において、ロードバランサノード１１０のメンバーシップの変化は、即時の接続公開イベントをトリガする。少なくともいくつかの実施形態において、ロードバランサモジュール１３２は、それぞれのサーバノード１３０をヘルスチェックするロードバランサノード１１０の１つから送信された健康なロードバランサノード１１０のリストから当該変化について学ぶ。リストによって変化（削除または追加のいずれか）を検出したときには、当該変化によって影響を受けるＴＣＰ接続は、当該ロードバランサノード１１０によってさらに迅速に回復されるように、ロードバランサモジュール１３２が接続公開パケットを生成して、ロードバランサノード１１０に送信する。
パケットループの防止

【0165】

接続公開パケットの処理中にロードバランサレイヤのメンバーシップが変化したときは、接続公開パケットのループが発生する。第１のノード１１０がロードバランサモジュール１３２から接続公開パケットを受信し、より小さなパケットを第２のノード１１０に送信する。しかしながら、メンバーシップが変化していた場合には、当該第２のノード１１０は、当該パケットは第１のノード１１０に行くべきだと判定し、このため当該パケットを第１のノード１１０に転送する。少なくともいくつかの実施形態において、このループが発生するのを防ぐために、ロードバランサモジュール１３２から受信される接続公開パケット及びロードバランサノード１１０から受信される接続公開パケットのために異なるポート番号が使用され、ロードバランサノード１１０は、他のロードバランサノード１１０から受信される接続公開パケットを再分配しない。
接続公開パケットの分散の代替

【0166】

上記された接続公開方法において、ロードバランサモジュール１３２は、接続公開パケットが送信されるロードバランサノード１１０をランダムに選択する。しかしながら、いくつかの実施形態において、ロードバランサノード１１０を選択するために他の方法が使用される。例えば、いくつかの実施形態において、ロードバランサノード１３２は、１以上のアクティブなＴＣＰフローを取り扱う特定の入口ノード１１０を各々が目標にする１以上の接続公開パケットを組み立てて、目標の入口ノード１１０に対してパケットを送信した。入口ノード１１０は、アクティブな接続情報を接続に対応する一次及び二次フロー追跡部に再分配するであろう。他の実施例として、いくつかの実施形態において、単一のランダムに選択されたノード１１０に対して接続公開パケットを送信する代わりに、各接続公開パケットは、ロードバランサモジュール１３２によって２以上の健康なノード１１０またはすべての健康なノード１１０に送信される。
ロードバランサノードのアーキテクチャ

【0167】

図２３は、少なくともいくつかの実施形態におけるロードバランサノード１１０についての例示的なソフトウェアスタックのアーキテクチャを示すが、この図に限定する意図ではない。この例示的なソフトウェアスタックのアーキテクチャにおいて、ロードバランササーバのネイティブコード１１０６及びコアパケットのプロセスコード１１０８、例えば、インテル（登録商標）のデータプレーン開発キット（ＤＰＤＫ）技術コードを含むネイティブコードのレイヤを管理するためのＪａｖａネイティブ・インターフェイス（ＪＮＩ：登録商標）１１０４技術を使用する単一のＪａｖａ（登録商標）技術プロセス１１０２の範囲内で、ロードバランサノード１１０は動作する。ネイティブコードは、２つのネットワーク・インターフェイス・コントローラ（ＮＩＣ１１１４Ａ及び１１１４Ｂ）にインターフェイスする。第１のＮＩＣ（ＮＩＣ１１１４Ａ）は、「北」に面していて、すなわち、エッジルータ１０４に向いている。第２のＮＩＣ（ＮＩＣ１１１４Ｂ）は、「南」に面していて、すなわち、サーバノード１３０に向いている。少なくともいくつかの実施形態において、ＮＩＣ１１１４Ａ及び１１１４Ｂは、ＴＣＰスタックを維持しない。したがって、少なくともいくつかの実施形態は、ロードバランサノード１１０がコントロールプレーンを介して、プロセスと通信できるように、また、逆方向も同様にできるように、ＴＣＰ接続をサポートする第３のＮＩＣ１１１４Ｃを備える。また、いくつかの実施形態において、第１の北向きのＮＩＣ１１１４Ａ及び第２の南向きのＮＩＣ１１１Ｂだけは、ロードバランサノード１１０の中に実装され、且つ、第２の南向きのＮＩＣ１１１４ＢはＴＣＰスタックを実装し、それを介したロードバランサノード１１０がコントロールプレーンを介したプロセスと通信する。ロードバランサノード１１０はまた、オペレーティングシステム（ＯＳ）技術ソフトウェア１１１２、例えば、Ｌｉｎｕｘ（登録商標）カーネル、及び、ＯＳ技術ソフトウェア１１１２及びＪＮＩ１１０４技術に加えてＪａｖａ仮想マシン（ＪＶＭ：登録商標）技術ソフトウェア１１１０のレイヤを有する。

【0168】

少なくともいくつかの実施形態において、分散型ロードバランシングシステムのロードバランサノード１１０の各々は、多くのデータフローを高いパケット速度で同時に処理する必要がある。少なくともいくつかの実施形態において、スループットの必要なレベルを達成するためには、ロードバランサノード１１０は、高性能のパケット処理のために、インテル（登録商標）・データプレーン開発キット（ＤＰＤＫ）技術を活用する。ＤＰＤＫ技術は、ユーザ空間のプログラムが、ネットワーク・インターフェイス・コントローラ（ＮＩＣ）から及びネットワーク・インターフェイス・コントローラ（ＮＩＣ）へ直接パケットの読み込み／書き込みすることを可能にし、Ｌｉｎｕｘカーネルの
ネットワーキングスタック（Ｌｉｎｕｓ ｉｘｇｂｅベースのＮＩＣドライバを除く）の多くのレイヤをバイパスする。パケット処理に取り組むＤＰＤＫは、ビジーループの中で直接的にＮＩＣハードウェアをポーリングする専用のＣＰＵコアを優先して、割り込みハンドラベースの入力を拒絶する。この取り組みは、ビジーループの中で専用のＣＰＵコアを連続的に動かすことによる熱出力の増加を犠牲にして、さらに高いパケット速度を実現する。ＤＰＤＫ技術はまた、ＣＰＵコア管理、ロックフリーの待ち行列、メモリプール、及び同期プリミティブを含むパケット処理のためのツールを提供する。図２４に示されているように、ＤＰＤＫ技術では、専用のＣＰＵコア６００が各特定のタスクのために使用され、作業は、無閉鎖の待ち行列６０２を用いて１つのＣＰＵコア６００Ａから他のＣＰＵコア６００Ｂに渡される。

【0169】

ＤＰＤＫ待ち行列６０２は、２つのリングバッファの高速パワーを使用して実装され、単一及び多数の生産者／消費者の変数の型をサポートする。多数の生産者／消費者の変数の型は、すべてがロックフリーではないのは、それらがアクセスを同期するためにコンペア・アンド・スワップ（ＣＡＳ）のループを有するからである。すべてのパケット・バッファメモリは前もってメモリプールに割り当てられているので、バッファに対するポインタのみが、待ち行列６０２について読みだされ且つ書き込まれる。メモリプールは、待ち行列として実装され、メモリのチャネル及びランクに亘ってメモリを分散するために最適化され、不均等メモリアクセス（ＮＵＭＡ）の最適化分配をサポートする。少なくともいくつかの実施形態において、パケット・バッファは、各パケット・バッファにおけるヘッドルーム及びｔａｉｌｒｏｏｍを十分に過剰割り当てするＭｂｕｆパラダイムなどの方法を使用して、バッファのコピーを必要とすることなく、外部ネットワークレイヤのヘッダを追加／削除するカプセル化／デカプセル化の操作をサポートする。

【0170】

ロードバランサノード１１０の少なくともいくつかの実施形態において、コアパケット処理のアーキテクチャは、ＤＰＤＫ技術を活用して実装される。各ロードバランサノード１１０は、コアパケット処理のアーキテクチャに従って、実装されている少なくとも１つのマルチコア・パケット・プロセッサを有する。コアパケット処理のアーキテクチャは、マルチコア・パケット・プロセッサの待ち行列及びコアを通過するパケットフローのために、単一の生産者／単一の消費者のパラダイムを使用する。このパラダイムにおいて、各待ち行列は１つの及び１つのみのコアに入力し、各コアは自分がパケットを供給する他のコアの各々に対する１つの及び１つのみのコアに出力する。さらに、マルチコア・パケット・プロセッサ内のコアによって使用されるメモリは共有ではなく、各コアは自分自身の独立したメモリ領域を有する。したがって、コア間で共有するメモリまたは待ち行列はなく、メモリ競合または待ち行列競合はなく、リクエスト・オブ・オーナーシップ（ＲＦＯ）またはコンペア・アンド・スワップ（ＣＡＳ）などのメモリまたは待ち行列共有メカニズムは必要ない。図２５及び図２６は、コアパケット処理のアーキテクチャに従って、実装されている例示的なマルチコア・パケット・プロセッサを示す。

【0171】

図２５は、少なくともいくつかの実施形態において、ＤＰＤＫ技術を活用してデータフローを処理するコアパケット処理のアーキテクチャに従って、実装されている例示的なマルチコア・パケット・プロセッサを示す。コアパケット処理のアーキテクチャは、単一の生産者／単一の消費者のパラダイムに従って、マルチコア・パケット・プロセッサとして実装される。少なくともいくつかの実施形態において、図２３に示されているように、ロードバランサノード１１０の各々は、２つのネットワーク・インターフェイス・コントローラ（ＮＩＣ）すなわち境界ネットワーク／エッジルータ１０４に面する北向きＮＩＣ１１１４Ａ及び生産ネットワーク／サーバノード１３０に面する南向きＮＩＣ１１１４Ｂを有する。少なくともいくつかの実施形態において、ＮＩＣ１１１４は、１０ＧｂｐｓのＮＩＣである。ロードバランサノード１１０を通って流れる主なパケットは、これら２つのＮＩＣの１つ（ＮＩＣ１１１４Ａまたは１１１４Ｂのいずれか）で受信され、処理され（例えば、カプセル化またはデカプセル化され）、他のＮＩＣ（ＮＩＣ１１１４Ｂまたは１１１４Ａのいずれか）に送信される。

【0172】

図２５を参照すると、少なくともいくつかの実施形態において、ロードバランサノード１１０は、各ＮＩＣ１１１４において、２つのＣＰＵコア、受信（ＲＸ）コア６１０及び送信（ＴＸ）コア６３０をスピンアップする。ロードバランサノード１１０はまた、両方のＮＩＣ１１１４に対するパケットを両方向で処理する多くのワーカーコア６２０をスピンアップする。この実施例においては、４つのワーカーコア６２０Ａないし６２０Ｄが使用される。受信コア６１０は、各受信コア６１０が各ワーカーコア６２０に対応するそれぞれのワーカー入力待ち行列６１２の中にパケットを供給する場合に、それらの入力待ち行列からの着信パケットがＮＩＣ１１１４に到達したときにそのバッチを読み取り、各パケットに対するワークのバルクを実行するワーカーコア６２０に対して当該パケットを分散する。少なくともいくつかの実施形態において、受信コア６１０は、（クライアント接続のＩＰアドレス及びポートによって識別される）任意の特定のクライアント接続が同一のワーカーコア６２０によって処理されることを保証するとともに、各着信パケットに対してレイヤ４の「フローハッシュ」技法（前に説明したように、エッジルータ１０４によって使用される同様のフロー単位ハッシュ化マルチパス・ルーティング技法）を実行し、当該パケットをワーカーコア６２０に分散する。このことは、各ワーカーコア６２０がパケットの同一のサブセットを常に監視することを意味し、ロックが要求されないように、ワーカーコア６２０によって管理されている状態データ上の競合を排除する。受信されたパケットへのポインタは、ワーカーコア６２０が新たな入力について連続的に監視するワーカー待ち行列６２２に亘って分散される。ワーカーコア６２０は、各接続に対する（例えば、割り当てられたサーバノード１３０の）状態を管理する責任を負うとともに、アウトバウンド待ち行列６３２の１つにパケットを転送する前に、パケットに対してＵＤＰのカプセル化またはデカプセル化を実行する。送信コア６３０は、ワーカーコア６２０を介してアウトバウンド待ち行列６３２を循環させ、出力パケットが待ち行列６３２上に現れたときに、それらの対応するＮＩＣ１１１４に対して当該出力パケットを書き込む。

【0173】

図２６は、少なくともいくつかの実施形態において、ＤＰＤＫ技術を活用してデータフローを処理するコアパケット処理のアーキテクチャに従って、実装されている他の例示的なマルチコア・パケット・プロセッサを示す。コアパケット処理のアーキテクチャは、単一の生産者／単一の消費者のパラダイムに従って、マルチコア・パケット・プロセッサとして実装される。少なくともいくつかの実施形態において、高いスループットのクライアントＴＣＰフローに加えて、ロードバランサノード１１０上のＤＰＤＫコアのアーキテクチャが使用され、ＡＲＰ、ＤＨＣＰ、及びＢＧＰなどの他のプロトコルについて、北及び南向きＮＩＣ１１１４上のパケットを送信し且つ受信する。図２６に示されている実施形態において、ワーカーコア６２０Ａは、これらの他のプロトコルにおいてパケットを取り扱うために専用化されている。このワーカーコア６２０Ａは「遅い」ワーカーコアと称されるが、それは一般的にクライアントＴＣＰフローよりも遅い速度で発生するパケットを処理するからである。これに対して、クライアントＴＣＰフローのみを処理する他のワーカーコア６２０Ｂないし６２０Ｄは、速いワーカーコアと称される。北向き及び南向きＮＩＣ１１１４上でそれぞれ着信パケットを取り扱う受信コア６１０Ａ及び６１０Ｂは、遅いワーカーコア６２０Ａによって取り扱われるべきパケットを識別すると、当該パケットを遅いワーカーコア６２０Ａに対応する入力待ち行列６２２に導く。遅いワーカーコア６２０Ａもまた、Ｊａｖａ／ＪＮＩによって生成されたパケットに対応する入力待ち行列６２２、及びＪａｖａ／ＪＮＩに対する出力パケットに対応する出力待ち行列６３４を監視する。遅いワーカーコア６２０Ａは、速いワーカーコア６２０Ｂないし６２０Ｄの各々に対して、パケット、例えば、接続公開パケットを送信できるように、遅いワーカーコア６２０Ａも、速いワーカーコア６２０Ｂないし６２０Ｄの各々に対応する入力待ち行列６２２に対して出力する。遅いワーカーコア６２０Ａはまた、送信コア６３０Ａ及び６３０Ｂの各々に供給するアウトバウンド待ち行列６３２を有する。

【0174】

少なくともいくつかの実施形態において、速いワーカーコア６２０Ｂないし６２０Ｄの各々の第３の入力待ち行列６２２は、遅いワーカーコア６２０Ａからの出力待ち行列である。少なくともいくつかの実施形態において、例えば、この第３の入力待ち行列６２２は、各々が接続状態情報を有している接続公開パケットを受信するため且つ処理するために、速いワーカー待ち行列６２０Ｂないし６２０Ｄによって使用される。これらの接続公開パケットの少なくともいくつかについては、送信コア６３０に対する出力が存在しない。その代わりに、パケットにおける接続状態情報は、例えば、それぞれの速いワーカーコア６２０が維持する１以上のパケットフローに関する記憶された状態を更新することで、速いワーカーコア６２０によって消費される。したがって、速いワーカーコア６２０Ｂないし６２０Ｄに対して入力する遅いワーカーコア６２０Ａからの出力待ち行列は、速いワーカーコアに記憶された状態を更新するために受信コア６１０から直接入力待ち行列６２２以外の経路を提供する。

【0175】

少なくともいくつかの実施形態において、図２５及び２６のマルチコア・パケット・プロセッサは、着信パケットをフィルタ処理して、有効なパケットのみを処理し且つ出力する。例えば、少なくともいくつかの実施形態において、受信コア６１０は、いずれのワーカーコア６２０によってもサポートされていないプロトコルのパケットをフィルタ処理で除外するので、当該パケットをワーカーコア６２０に対して送信しない。少なくともいくつかの実施形態において、ワーカーコア６２０の各々は、パケットを処理する場合に、パケットがさらに処理することが受諾できるものかどうかを判定するため、及び、送信コア６３０に対して出力するため、最初に該当するそれぞれのワーカー入力待ち行列６２２から読み出したパケットを分析して、次に、受諾する送信コア６３０に対する当該パケットのみ処理及び出力を完了する。受諾できないパケットは廃棄される。例えば、ワーカーコア６２０は、各パケットのアドレス情報を調べて、負荷分散されている有効なアドレスに的を絞ったパケットのみ受諾し、すべての他のパケットを廃棄する。
境界ゲートウェイ・プロトコル（ＢＧＰ）データの取り扱い

【0176】

少なくともいくつかの実施形態において、コアのアーキテクチャの内部及び外部でＢＧＰクライアントに関連するパケットフローは、以下のように取り扱われる。ＮＩＣ１１１４Ａ及び１１１４ＢはＬｉｎｕｘカーネルには向かわないので、エッジルータ１０４に対するＴＣＰ接続は、図２６に示されているように、コアのアーキテクチャによって中断され、遅いワーカーコア６２２Ａによって処理され、遅いワーカーコア６２２Ａは、出力待ち行列６３４を介してＪａｖａ空間の中に当該ＢＧＰパケットを渡す。これらのＴＣＰパケットは、ロードバランサノード１１０上の１以上のモジュールによってさらに処理された後、ＴＣＰ接続を管理し且つＴＣＰストリームに当該パケットを有効に変換するＬｉｎｕｘカーネルによる処理を含め、ＢＧＰクライアントに対して配信される。このデザインは、ＢＧＰクライアントが標準のＪａｖａＴＣＰソケットライブラリを用いて書かれるようにする。

【0177】

図２７は、少なくともいくつかの実施形態において、ロードバランサ（ＬＢ）ノード処理部６５０による着信ＢＧＰ ＴＣＰパケットの処理を示す。エッジルータ１０４からのパケットは、北向きＮＩＣ６４０に到達し、受信コア６５２に対応する入力待ち行列６４０の中に進む。受信コア６５２は、待ち行列６４０からパケット、ＢＧＰパケットとして識別されたパケットを読み取り、遅いワーカーコア６５６に対応する入力待ち行列６５４上にパケットを配列する。遅いワーカーコア６５６は、パケットを確認して、ＪＮＩ出力待ち行列６５８上にパケットを配列する。ＪＮＩパケット受信器６６０は、ＪＮＩを介して待ち行列６５８からパケットを読み取り、送信元／宛先アドレスを分解し、ｒａｗソケット６４４に書き込む。Ｌｉｎｕｘカーネル６４６は、未処理パケットを受信し、ＴＣＰプロトコルに従って当該パケットを取り扱い、ＴＣＰソケット入力ストリームにペイロードを追加する。パケットからのデータは、次に、ＢＧＰクライアント６６２の中のＪａｖａ ＴＣＰソケットに対して配信される。

【0178】

図２８は、少なくともいくつかの実施形態において、ロードバランサ（ＬＢ）ノード処理部６５０による発信ＢＧＰ ＴＣＰパケットの処理を示す。ＢＧＰクライアント６６２は、Ｌｉｎｕｘカーネル６４６のＪａｖａ ＴＣＰソケットにデータを書き込む。Ｌｉｎｕｘカーネル６４６は、ＴＣＰプロトコルに従って、データを取り扱い、データをＴＣＰパケットに変換する。少なくともいくつかの実施形態において、ＴＣＰパケットは、１２７．ｘ．ｘ．ｘ ｉｐｔａｂｌｅｓ規則に合致する。ＴＣＰパケットは、出力待ち行列６４８、例えば、Ｎｅｔｆｉｌｔｅｒ ＬＯＣＡＬ＿ＯＵＴの待ち行列に配列される。ＪＮＩを介して待ち行列６４８を監視しているＪＮＩパケット受信器６７０のＪａｖａスレッドは、ＴＣＰパケットを受信し、各ＮＦ＿ＳＴＯＬＥＮを印付けしてカーネル６４６がＴＣＰパケットに関して忘れるようにする。Ｊａｖａスレッドは、送信元／宛先アドレスを分解して、遅いワーカーコア６５６に対応するＪＮＩ入力待ち行列６７２にパケットをＪＮＩを介して追加する。遅いワーカーコア６５６は、自分のＪＮＩ入力待ち行列６７２からＴＣＰパケットを受信し、北向きＮＩＣ６４０の送信コア６６６に対応するアウトバウンド待ち行列６６４上にパケットを配列する。送信コア６６６は、自分の入力待ち行列６６４からＴＣＰパケットを読み取り、北向きＮＩＣ６４０にそれらを書き込む。ＴＣＰパケットは、ＮＩＣ６４０によってエッジルータに送信される。
分散型ロードバランサのシミュレーション及び試験

【0179】

本明細書に記載されているロードバランサは、多数の独立した構成要素（例えば、ルータ、ロードバランサノード、ロードバランサモジュール等）の対話を要求する分散型システムである。ノード障害、メッセージ欠落、及び遅延などのシナリオをシミュレーションするためだけでなく、分散型の構成要素、ロジック、及びプロトコルの試験を実施するために、複雑なネットワークトポロジ（例えば、生産ネットワーク）においてマルチホストに配備されるためのコードを必要とすることなく、対話が試験できるところで、単一のプロセスにおいて動かせる分散型ロードバランサを可能にする試験システムの実施形態を説明する。このことを達成するために、単一のプロセスにおいてまたは単一のプロセスとして多数のロードバランサの構成要素が構成され且つ実行されることを可能にするメッセージバスと称されるソフトウェアのメカニズムを説明する。当該単一のプロセスは、単一のホストシステム上で実行される。メッセージバスのメカニズムは、例えば、単一のホストシステム上で、同時に、ロードバランサの構成要素（例えば、ロードバランサノード及びロードバランサモジュール）が動いているように見える実際の生産ネットワーク上で、分散型ロードバランサシステムが単一のプロセスとして試験されることを可能にする。

【0180】

メッセージバスは、分散型ロードバランサが単一のプロセスとして動くことができるフレームワークを提供する。処理中の１以上のメッセージバスレイヤの各々は、分散型ロードバランサの構成要素間のネットワーク（例えば、イーサネット（登録商標））のセグメントをシミュレーションする。分散型ロードバランサシステムのソフトウェアの構成要素は、メッセージバスの環境の範囲内で当該構成要素が動作できる特定の形態に書き込まれる必要はない。その代わりに、メッセージバスのフレームワークは、分散型ロードバランサシステムの構成要素が生産するパケットを中断する構成要素（メッセージバスＮＩＣまたはパケットアダプタと称される）を提供して、実際の物理的なネットワークの中ではなく、メッセージバスレイヤによって提供されたシミュレーションされたネットワークの中にパケットを導き、目標の構成要素にパケットを配信する。メッセージバスレイヤは、構成要素間の通信に対応するＴＣＰ／ＩＰスタックを実装しない。その代わりに、メッセージバスレイヤは、ホストシステムのオペレーションシステム（ＯＳ）と整合して、ホストシステムのＴＣＰ／ＩＰスタックを使用する。メッセージバスレイヤは、ＯＳによって提供されるＴＣＰ／ＩＰスタックを活用して、メッセージバスが中断し且つ配信する個々のパケットへ、またメッセージバスが中断し且つ配信する個々のパケットから、クライアント及びサーバが期待するＴＣＰストリームを変換する。

【0181】

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

【0182】

メッセージバス・ネットワーク・インターフェイスは、構成要素がメッセージバスＮＩＣを介してメッセージバスに取り付けるためのメカニズムである。メッセージバス・ネットワーク・インターフェイスは、Ｌｉｎｕｘ技術におけるインターフェイス構成（ｉｆｃｏｎｆｉｇ）のインターフェイスと同義であるが、メッセージバス・ネットワーク・インターフェイスが、物理的なネットワークに対してではなく、メッセージバスに対して取り付けることが異なっている。メッセージバス・ネットワーク・インターフェイスは、ＩＰアドレスを有し、メッセージバスＮＩＣの上部に位置する。メッセージバス・ネットワーク・インターフェイスは、メッセージバスからのパケットを受信する構成要素によって使用されることができるパケット送信元インターフェイス、及び、メッセージバスの中にパケットを送信する構成要素によって使用されることができるパケットシンク・インターフェイスを公開する。

【0183】

各ロードバランサノードは、パケット送信元インターフェイス及びパケットシンク・インターフェイスの実装によって配信され且つ送信される個々のネットワーク・パケットを処理する。これらのインターフェイスは、メッセージバス環境の中で動いている場合には、レイヤ２のイーサネットヘッダを追加または削除する（カーネル・ネットワーク・スタックによってこれが実行されると予想するロードバランサノードに対して）メッセージバス・ネットワーク・インターフェイスによって実装される。図２９に示されているような生産環境において、パケット送信元インターフェイス及びパケットシンク・インターフェイスの実装は、実際のネットワーク・インターフェイス上でメッセージバスのパケットを受信し且つ送信する。図３０に示されているようなメッセージバス環境においては、パケット送信元インターフェイス及びパケットシンク・インターフェイスの実装は、メッセージバスレイヤまたは複数のレイヤからパケットを受信し且つそれに対してパケットを送信する。

【0184】

説明を簡単にするために、メッセージバスＮＩＣ及びメッセージバス・インターフェイスは、メッセージバスのパケットアダプタまたは単にパケットアダプタと総称する。図３１及び３２を参照されたい。

【0185】

図２９は、少なくともいくつかの実施形態において、生産環境における分散型ロードバランサ７００を備えた分散型ロードバランシングシステムを示す。ロードバランサ７００は、この記載では簡略化されている。ロードバランサ７００は、当該ロードバランサ７００を実装するデータセンターなどのネットワーク設定の境界ルータ７０２を介して、外部ネットワーク７４０上のクライアント７４２に接続する。ロードバランサ７００は、様々なタイプの構成要素、すなわち少なくとも１つのエッジルータ７０４、２以上のロードバランサ（ＬＢ）ノード７１０、各々が独立したサーバノード（図示せず）上に実装されている２以上のロードバランサ（ＬＢ）モジュール７３２、ルータまたはスイッチなどのファブリック７２０を形成する１以上のネットワーキング構成要素、及び、少なくともいくつかの実施形態における構成サービス７２２を備える。少なくともいくつかの実施形態において、ロードバランサ７００の各構成要素は、汎用のラック収納型演算装置などの独立した演算装置としてまたはその中に実装されている。

【0186】

図３０は、少なくともいくつかの実施形態において、単一のプロセスにおいてまたは単一のプロセスとして多数の分散型ロードバランシングシステムの構成要素が構成され且つ実行されることを可能にするメッセージバスのメカニズムを搭載した分散型ロードバランサ試験システム８００を示す。図２９に示されているロードバランサ７００において、各ロードバランサソフトウェアの構成要素は、独立した演算装置（例えば、ロードバランサノード７１０上のロードバランサソフトウェア、及びサーバノード上のロードバランサモジュール７３２）上でインストールされ且つ実行される。これらのロードバランサソフトウェアの構成要素が単一のプロセスにおいて実行できるようにするためには、ロードバランサソフトウェアの構成要素の内部及び外部のパケットが、物理的なネットワーク上で送信され且つ受信される代わりに、メッセージバスのメカニズムを介して中断され且つルーティングされることができるように、ロードバランサソフトウェアの構成要素の各々（図３０におけるロードバランサ（ＬＢ）ノード８１０及びロードバランサ（ＬＢ）モジュール８３２に示されている）は、当該構成要素のネットワーク接続性を要約するコードを有する。

【0187】

少なくともいくつかの実施形態の分散型ロードバランサ試験システム８００において、メッセージバスのメカニズムは、構成要素間の通信のためのＴＣＰスタックを実装しない。その代わりに、メッセージバスのメカニズムは、ホストシステムのオペレーティングシステム（ＯＳ）に整合して、ホストシステムのＴＣＰスタックを使用する。少なくともいくつかの実施形態において、メッセージバスの機能は、ＩＰテーブルを介してユーザレイヤの下のホストシステムのＯＳのカーネル（例えば、Ｌｉｎｕｘカーネル）、カーネルの機能と結び付く。メッセージバスの機能は、カーネルレベルでＩＰテーブルの中に留まり、パケットを中断し、ルーティングのためにメッセージバスのプロセス内に渡す。

【0188】

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

【0189】

いくつかの構成要素（例えば、シミュレーションされたルータ）は、ネットワークセグメントをシミュレーションする異なるメッセージバスレイヤ８５０に対してパケットを渡すこと、且つ当該レイヤ８５０からパケットを受信するために、２つ以上のメッセージバスのレイヤ８５０に接続される。

【0190】

分散型ロードバランシング試験システム８００のメッセージバスレイヤ８５０に実装されているメッセージバスのメカニズムは、ネットワークセグメントの「ワイヤー」をシミュレーションする。少なくともいくつかの実施形態において、メッセージバスのメカニズムは、構成要素のＭＡＣアドレスに基づいて、分散型ロードバランシング試験システム８００における宛先の構成要素に対してパケットを配信する。したがって、各ロードバランサのソフトウェアの構成要素（ロードバランサノード８１０及びロードバランサモジュール８３２）は、ロードバランサソフトウェアの構成要素が分散型ロードバランシング試験システム８００において、他の構成要素から自分に送信されたパケットを受信することができるように、メッセージバスのレイヤ８５０に対してＭＡＣアドレスを提供し、当該ＭＡＣアドレスに接続される。
＜メッセージバスのパケットアダプタ＞

【0191】

図３１及び３２は、少なくともいくつかの実施形態におけるメッセージバスのパケットアダプタを示す。少なくともいくつかの実施形態において、各ロードバランサ（ＬＢ）ソフトウェアの構成要素は、ＰａｃｋｅｔＳｏｕｒｃｅ及びＰａｃｋｅｔＳｉｎｋインターフェイスの実装によって、配信され且つ送信される個々のネットワーク・パケットを処理する。図３１を参照すると、これらのインターフェイス（パケット送信元・インターフェイス８６２及びパケットシンク・インターフェイス８６４として示されている）は、分散型ロードバランシングシステム８００内で動いている場合には、メッセージバスレイヤ８５０と、カーネルのネットワークスタックによってこれが実行されることを予期する、ロードバランサソフトウェアの構成要素８７０のためにレイヤ２のイーサネットヘッダを追加または削除するロードバランサソフトウェアの構成要素８７０の間のパケットアダプタ８６０に実装される。図２９に示されているような生産環境においては、ロードバランサソフトウェアの構成要素に対するＰａｃｋｅｔＳｏｕｒｃｅインターフェイス及びＰａｃｋｅｔＳｉｎｋインターフェイスの実装は、当該構成要素が実装される物理的な装置の実際のネットワーク・インターフェイス上で、パケットを受信し且つ送信する。

【0192】

図３１を参照すると、少なくともいくつかの実施形態において、ロードバランサソフトウェアの構成要素８７０がパケットを送信する場合には、パケットシンク・インターフェイス８６４の送信パケット方法を呼び出す実行のスレッドは、パケットアダプタ８６０の中において、及びメッセージバスレイヤ８５０の中においても、一連の機能を横断して、その構成要素の入力待ち行列に対してパケットを追加することによって宛先の構成要素に対して最終的にパケットを配信する。少なくともいくつかの実施形態において、ロードバランサソフトウェアの構成要素８７０がパケットを受信する場合には、ロードバランサソフトウェアの構成要素８７０は、パケット送信元インターフェイス８６２の受信パケット方法を呼び出して、自分の入力待ち行列からパケットを読み取る。少なくともいくつかの実施形態において、メッセージバスのメカニズムは、自分自身のいかなる追加スレッドをも要求することなく、パケットを配信する。
メッセージバスのパケットパイプライン

【0193】

図３２を参照すると、少なくともいくつかの実施形態において、パケット送信元インターフェイス８６２及びパケットシンク・インターフェイス８６４のメッセージバス８５０側は、パケットパイプライン機能を提供する。ロードバランサソフトウェアの構成要素８７０がパケットシンク・インターフェイス８６４を介してパケットを送信した場合、パケットは一連の段階（パケットパイプライン８８０）を横断した後に、メッセージバスのレイヤ８５０に到達する。これらの段階は、例えば、パケットを変更し、パケットを破棄し、パケットを複製し、パケットを遅延させる。一旦パケットがパケットパイプライン８８０を横断し、メッセージバスのレイヤ８５０が、宛先の構成要素８７０を選択すると、パケットは、宛先の構成要素８７０に関連する次の一連のパイプライン段階（パケットパイプライン８８２）も横断した後に、宛先の構成要素８７０の入力待ち行列に追加される。
例示的なプロバイダのネットワーク環境

【0194】

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

【0195】

図３３Ａは、少なくともいくつかの実施形態において、例示的なプロバイダ・ネットワーク環境を示す。プロバイダ・ネットワーク１９００は、クライアントがアクセスすること、購入すること、借り受けることを可能にするか、さもなければ、限定はされないが、演算資源及び記憶資源を含み、プロバイダ・ネットワークまたは１以上のデータセンターのネットワーク内の装置上に実装されている仮想化された資源インスタンス１９１２を得ることを可能にする１以上の仮想化サービス１９１０を介して、資源の仮想化をクライアントに提供する。プライベートＩＰアドレス１９１６は資源インスタンス１９１２に関連し、当該プライベートＩＰアドレスはプロバイダ・ネットワーク１９００上の資源インスタンス１９１２の内部ネットワークアドレスである。いくつかの実施形態において、プロバイダ・ネットワーク１９００はまた、クライアントがプロバイダ１９００から取得するパブリックＩＰアドレス１９１４及び／またはパブリックＩＰアドレスの範囲（例えば、インターネット・プロトコル・バージョン４（ＩＰｖ４）またはインターネット・プロトコル・バージョン６（ＩＰｖ６）アドレス）を提供する。

【0196】

従来、プロバイダ・ネットワーク１９００は、仮想化サービス１９１０を介して、サービス・プロバイダのクライアント（例えば、クライアントネットワーク１９５０Ａを操作するクライアント）が、クライアントに対して割り当てられる特定の資源インスタンス１９１２でクライアントに対して割り当てられまたは割り振られる少なくともいくつかのパブリックＩＰアドレス１９１４に動的に対応付けることを可能にする。プロバイダ・ネットワーク１９００はまた、クライアントに割り当てられて以前にマッピングされた１つの仮想化演算資源インスタンス１９１２に対して、これもクライアントに割り当てられた他の仮想化演算資源インスタンス１９１２に対して、パブリックＩＰアドレス１９１４にクライアントが再マッピングすることを可能にする。仮想化演算資源インスタンス１９１２及びサービス・プロバイダによって提供されたパブリックＩＰアドレス１９１４を使用すると、クライアントネットワーク１９５０Ａのオペレータなどのサービス・プロバイダのクライアントは、例えば、クライアント専用アプリケーションを実装して、インターネットなどの中間ネットワーク１９４０上で当該クライアントアプリケーションを提示する。中間ネットワーク１９４０上の他のネットワークエンティティ１９２０は、その後、クライアントネットワーク１９５０Ａによって公開された宛先のパブリックＩＰアドレス１９１４に対するトラフィックを生成し、そのトラフィックはサービス・プロバイダのデータセンターにルーティングされ、データセンターにおいて、ネットワーク基板を介して、宛先のパブリックＩＰアドレス１９１４に現在マッピングされている仮想化演算資源インスタンス１９１２のプライベートＩＰアドレス１９１６に対してルーティングされる。同様に、仮想化演算の資源インスタンス１９１２からの応答トラフィックは、ネットワーク基板を介して、中間ネットワーク１９４０上でルーティングされて送信元エンティティ１９２０に戻る。

【0197】

本明細書で使用されているようなプライベートＩＰアドレスは、プロバイダ・ネットワークにおける資源インスタンスの内部ネットワークアドレスのことを指す。プライベートＩＰアドレスは、プロバイダ・ネットワーク内でのみルーティング可能である。プロバイダ・ネットワークの外部で発生したネットワークトラフィックは、プライベートＩＰアドレスには直接的にルーティングできないが、その代わりに、当該トラフィックは、資源インスタンスにマッピングされているパブリックＩＰアドレスを使用する。プロバイダ・ネットワークは、ネットワーク装置またはネットワークアドレス変換（ＮＡＴ）または同様の機能を実現する専用装置を有し、パブリックＩＰアドレスからプライベートＩＰアドレスへのマッピング及びその逆を実行する。

【0198】

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

【0199】

いくつかのパブリックＩＰアドレスは、プロバイダ・ネットワークのインフラによって特定の資源インスタンスに割り当てられ、これらのパブリックＩＰアドレスは、標準パブリックＩＰアドレスまたは単に標準ＩＰアドレスと称される。少なくともいくつかの実施形態において、資源インスタンスのプライベートＩＰアドレスに対する標準ＩＰアドレスのマッピングは、資源インスタンスのすべてのタイプについてデフォルトの起動構成である。

【0200】

少なくともいくつかのＩＰアドレスは、プロバイダ・ネットワーク１９００のクライアントに対して割り振られ、またはこれらのクライアントによって取得され、次に、クライアントは、それらの割り振られたパブリックＩＰアドレスを当該クライアントに割り振られた特定の資源インスタンスに割り当てる。これらのパブリックＩＰアドレスは、クライアントパブリックＩＰアドレスまたは単にクライアントＩＰアドレスと称される。標準ＩＰアドレスの場合のように、プロバイダ・ネットワーク１９００によって資源インスタンスに割り当てられる代わりに、クライアントＩＰアドレスは、例えば、サービス・プロバイダによって提供されたＡＰＩを介して、クライアントによって資源インスタンスに割り当てられる。標準ＩＰアドレスとは異なり、クライアントＩＰアドレスは、クライアントのアカウントに割り当てられ、必要または要望に応じて、それぞれのクライアントによって他の資源インスタンスに再マッピングされることが可能である。クライアントＩＰアドレスは、クライアントのアカウントに関連するが、特定の資源インスタンスには関連せず、クライアントは、クライアントがそれを開放することを選択するまではそのＩＰアドレスを制御する。従来の静的ＩＰアドレスとは異なり、クライアントＩＰアドレスは、クライアントのパブリックＩＰアドレスをクライアントのアカウントに関連する任意の資源インスタンスに再マッピングすることによって、クライアントが資源インスタンスまたはアベイラビリティゾーンの障害をマスクすることができるようにする。クライアントＩＰアドレスは、例えば、代替の資源インスタンスにクライアントＩＰアドレスを再マッピングすることによって、クライアントの資源インスタンスまたはソフトウェアに関わる問題について、クライアントが処理できるようにする。

【0201】

図３３Ｂは、図３３Ａに示されているような例示的なプロバイダ・ネットワーク環境において、分散型ロードバランサの実装を示す。プロバイダ・ネットワーク１９００は、クライアント１９６０に対して、サービス１９１０、例えば、仮想化記憶サービスを提供する。クライアント１９６０は、例えば、サービス１９１０に対応する１以上のＡＰＩを介して、サービス１９１０にアクセスして、プロバイダ・ネットワーク１９００の生産ネットワーク部分における多数のサーバノード１９９０上に実装された資源（例えば、記憶資源または演算資源）の使用法を取得する。サーバノード１９９０の各々は、ローカルロードバランサ（ＬＢ）モジュール１９９２だけでなく、ウェブサーバまたはアプリケーションサーバなどのサーバ（図示せず）を実装する。１以上の分散型ロードバランサ１９８０は、境界ネットワークと生産ネットワークとの間のロードバランサレイヤの中に実装されている。境界ルータ１９７０は、インターネットなどの中間ネットワーク１９４０を介して、クライアント１９６０からのパケットフローの中のパケット（例えば、ＴＣＰパケット）を受信して、境界ネットワークを介して、分散型ロードバランサ１９８０のエッジルータに対してパケットを転送する。パケットは、分散型ロードバランサ１９８０のエッジルータによって公開されたパブリックＩＰアドレスに向かう。各分散型ロードバランサ１９８０のエッジルータは、それぞれの分散型ロードバランサ１９８０のロードバランサノードの中にパケットフローを分散する。少なくともいくつかの実施形態において、入口ノードとしての機能を果たす各ロードバランサノードは、同じパブリックＩＰアドレスをエッジルータに広告し、エッジルータは、クライアント１９６０からのパケットフローを、フロー単位ハッシュ化マルチパス・ルーティング技法、例えば、等価マルチパス（ＥＣＭＰ）ハッシュ処理技法に従って、入口サーバの中に分散する。ロードバランサノードは、本明細書に記載された接続プロトコルを使用して、パケットフローに対応する目標のサーバノード１９９０を決定し、サーバとクライアント１９６０との間の接続を推進する。接続が確立すると、入口ノードは、フローに関する受信されたパケットをカプセル化して、生産ネットワーク上の目標のサーバノード１９９０に送信し、その一方で、フロー追跡部ノードは、接続に関する状態を維持する。サーバノード１９９０上のロードバランサモジュール１９９２は、サーバノード１９６０上のそれぞれのサーバが接続を受諾するかどうかについて決定を下す。ロードバランサモジュールは、入口ノードからのパケットを受信してデカプセル化して、サーバノード１９９０上のそれぞれのサーバに対して、デカプセル化されたパケット（例えば、ＴＣＰパケット）を送信する。ロードバランサモジュール１９９２はまた、パケットフローに対応する出口ノードとしてのロードバランサノードを選択し、フローに関する発信パケットをカプセル化して、生産ネットワークを介して、選択された出口ノードに対して送信する。出口ノードは、順に、パケットをデカプセル化して、それぞれのクライアント１９６０に対して配信する境界ネットワーク上でデカプセル化されたパケットを送信する。

【0202】

図３４Ａは、少なくともいくつかの実施形態において、分散型ロードバランサ及びサーバノードの例示的な物理的なラック実装を示すが、これに限定される意図ではない。少なくともいくつかの実施形態において、分散型ロードバランサの様々な構成要素は、汎用のラック収納型の演算装置上にまたはそれ自体として実装されている。ラック１９０は、各々がロードバランサノード（ＬＢノード１１０Ａ〜１１０Ｆ）としての機能を果たしている多数の演算装置、及び各々がサーバノード（サーバノード１３０Ａ〜１３０Ｌ）としての機能を果たしている多数の演算装置を含む。ラック１９０はまた、少なくとも１つのエッジルータ１０４、ファブリック１２０を形成する１以上のラック収納型ネットワーク装置（ルータ、スイッチ等）、及び１つ以上の他の構成要素１８０（他のネットワーク装置、パッチパネル、電源、冷却システム、バス等）も備える。図３３Ａ及び３３Ｂのプロバイダ・ネットワーク１９００を実装するデータセンターやセンターなどのネットワーク１００のインストールは、１以上のラック１９０を備える。

【0203】

図３４Ｂは、少なくともいくつかの実施形態において、分散型ロードバランサ及びサーバノードの例示的な物理的なラック実装を示すが、これに限定される意図ではない。図３４Ｂは、スロット収納型演算装置として、例えば、ブレードサーバがラック１９０内に実装されているＬＢノード１１０及びサーバノード１３０を示す。

【0204】

図３５は、少なくともいくつかの実施形態において例示的なネットワーキング環境を示しており、そこでは、別個に実装されたサーバノードを有する１、２または３以上の分散型ロードバランサがネットワークに実装されている。この実施例においては、２つの分散型ロードバランサ１９８０Ａ及び１９８０Ｂが示されている。分散型ロードバランサ１９８０の各々は、境界ネットワークを介して、クライアント１９６０からのパケットフローを受信し、本明細書に記載されたロードバランシング方法を実行して、多数のサーバノード１９９０の中にパケットを分散する。いくつかの実装において、各分散型ロードバランサ１９８０は、サーバノードがロードバランサラックの中にインストールされていないことを除けば、図３４Ａ及び３４Ｂに示されているラック１９０と同様にラック実装である。サーバノード１９９０は、データセンター内において、１以上の独立したラックにインストールされたブレードサーバなどのラック収納型演算装置である。いくつかの実装において、サーバノード１９９０は、異なる１以上のロードバランサ１９８０によって対応される各サービスを含め、プロバイダ・ネットワークによって提供される異なる２以上のサービスを実施する。
例示的なシステム

【0205】

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

【0206】

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

【0207】

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

【0208】

１つの実施形態において、入出力インターフェイス２０３０は、プロセッサ２０１０、システムメモリ２０２０、及びネットワーク・インターフェイス２０４０または他の周辺インターフェイスを含む装置内の任意の周辺装置の間で、入出力トラフィックを調整する構成になっている。いくつかの実施形態において、入出力インターフェイス２０３０は、任意の必要なプロトコル、タイミング、または他のデータ変換を実行して、１つの構成要素（例えば、システムメモリ２０２０）からのデータ信号を他の構成要素（例えば、プロセッサ２０１０）での使用のために適切な形式に変換する。いくつかの実施形態において、入出力インターフェイス２０３０は、例えば、周辺構成要素相互接続（ＰＣＩ）バス標準またはユニバーサルシリアルバス（ＵＳＢ）標準の変形などの様々なタイプの周辺バスを介して接続される装置のためのサポートを含む。いくつかの実施形態において、入出力インターフェイス２０３０の機能は、例えば、ノースブリッジ及びサウスブリッジなどの２以上の独立した構成要素に分かれる。また、いくつかの実施形態において、入出力インターフェイス２０３０のいくつかまたはすべての機能は、システムメモリ２０２０に対するインターフェイスなどのように、プロセッサ２０１０の中に直接組み込まれている。

【0209】

ネットワーク・インターフェイス２０４０は、コンピュータシステム２０００と、１つのネットワークまたはネットワーク２０５０に接続された他の装置２０６０、例えば、図１ないし図３５に例示されているような他のコンピュータシステムまたは装置との間で、データが交換され得るように構成されている。様々な実施形態において、ネットワーク・インターフェイス２０４０は、例えば、イーサネットネットワークのタイプなどの、任意の適切な有線または無線の一般的なデータネットワークを介して、通信をサポートする。さらに、ネットワーク・インターフェイス２０４０は、アナログ音声ネットワークまたはデジタルファイバ通信ネットワークなどの電気通信／電話通信ネットワークを介して、ファイバチャネルＳＡＮなどのストレージエリア・ネットワークを介して、または、任意の他の適切なタイプのネットワーク及び／またはプロトコルを介して、通信をサポートする。

【0210】

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

【0211】

開示された実施形態は、以下の条項の観点で記載されることができる。
１．分散型ロードバランサシステムであって、
複数のロードバランサノード、及び
各々がサーバ及びロードバランサモジュールを有する複数のサーバノードを備え、その中で、
前記複数のロードバランサノードは、１以上のクライアントからのパケットフローを前記複数のサーバノードの中に分散し、前記複数のサーバノードの中に分散するように構成され、
前記複数のロードバランサノードは、前記複数のサーバノードの中からサーバノードを選択し、前記パケットフローについての接続要求を前記クライアントから受信し、且つ、前記接続要求を前記選択されたサーバノードに対して送信するように構成され、
各サーバノード上の前記ロードバランサモジュールは、前記複数のロードバランサノードの１つからのパケットフローについての接続要求を受信し、前記接続が前記サーバノード上の前記サーバによって受諾されるかどうかを判定し、前記サーバが前記接続を受諾できない場合には、前記接続要求を拒絶し、且つ、前記サーバが前記接続を受諾できる場合には、前記複数のロードバランサノードと協働して、前記それぞれのクライアントと前記それぞれのサーバとの間のパケットフローについての接続を確立するように構成されている、
前記分散型ロードバランサシステム。
２．条項１に記載された分散型ロードバランサシステムは、さらに、ハッシュ化マルチパス・ルーティング技法に従って、前記１以上のクライアントからの前記パケットフローを前記複数のロードバランサノードの中に分散するように構成されたルータをさらに備える、
前記分散型ロードバランサシステム。
３．条項１に記載された分散型ロードバランサシステムは、その中で、前記サーバノード上の前記サーバによって前記接続が受諾されるかどうかを判定するために、前記ロードバランサモジュールが、前記サーバノード上の前記サーバの１以上の現在の資源使用量のメトリクスを分析して、前記接続を前記サーバが受諾できるかどうかを判定するように構成され、その中で、前記１以上の現在の資源の使用量のメトリクスが、１以上のＣＰＵの使用、帯域幅の使用量、サーバ待ち時間、及び確立された接続数を含む、
前記分散型ロードバランサシステム。
４．条項１に記載された分散型ロードバランサシステムは、その中で、前記複数のロードバランサノードが、さらに、前記接続要求を受信するため前記複数のサーバノードの中から、ランダムな選択技法に従って前記サーバノードを選択するように構成されている、
前記分散型ロードバランサシステム。
５．条項１に記載された分散型ロードバランサシステムは、その中で、前記複数のロードバランサノードが、さらに、拒絶された接続要求を受信するために前記複数のサーバノードの中から、他のサーバノードを選択し、前記接続要求を前記他のサーバノードに対して送信するように構成されている、
前記分散型ロードバランサシステム。
６．条項１に記載された分散型ロードバランサシステムは、その中で、各パケットフローが伝送制御プロトコル（ＴＣＰ）パケットフローであり、またその中で、クライアントとサーバとの間に確立された各接続がＴＣＰ接続である、
前記分散型ロードバランサシステム。
７．条項１に記載された分散型ロードバランサシステムは、その中で、クライアントとサーバとの間で確立された各接続が、前記クライアントに始まり、前記複数のロードバランサノードの１以上の中を通って、前記サーバによって終端される、
前記分散型ロードバランサシステム。
８．方法であって、
クライアントに対するパケットフローにおけるパケットを受信すること、及び
前記パケットフローについての接続要求を複数のサーバノードの中から選択されたサーバノードに対して送信することを、
１以上の複数のロードバランサノードによって実行し、
前記サーバノード上のサーバが前記接続を受諾できるかまたはできないかどうかを判定すること、
前記サーバが前記接続を受諾できないと判定したときは前記接続要求を拒絶すること、及び
前記サーバが前記接続を受諾できると判定したときは前記接続要求を受諾することを、
前記選択されたサーバノードによって実行する、
前記方法。
９．条項８に記載された方法は、その中で、前記接続要求を受諾することが、前記選択されたサーバノードと前記１以上のロードバランサノードとが協働して前記パケットフローについて前記それぞれのクライアントと前記それぞれのサーバとの間で接続を確立することを含む、
前記方法。
１０．条項９に記載された方法は、その中で、前記パケットフローが伝送制御プロトコル（ＴＣＰ）パケットフローであり、またその中で、前記クライアントと前記サーバとの間で確立された接続がＴＣＰ接続である、
前記方法。
１１．条項９に記載された方法は、その中で、前記確立された接続がクライアントに始まり、前記複数のロードバランサノードの１つの中を通って、前記サーバによって終端される、
前記方法。
１２．条項８に記載された方法は、その中で、１以上のクライアントからのパケットフローをハッシュ化マルチパス・ルーティング技法に従って前記複数のロードバランサノードの中に分散するルータから前記パケットが受信される、
前記方法。
１３．条項８に記載された方法は、その中で、前記サーバノード上のサーバが前記接続を受諾できるかまたはできないかどうかを前記判定することが、前記サーバの１以上の現在の資源使用量のメトリクスを分析して前記接続を受諾できるかどうかを判定することを含む、
前記方法。
１４．条項８に記載された方法は、前記１以上のロードバランサノードが、ランダム選択技法に従って、前記複数のサーバノードの中からサーバノードを選択することをさらに含む、
前記方法。
１５．条項８に記載された方法は、前記選択されたサーバノードが前記接続要求を拒絶した場合に、前記１以上のロードバランサノードが、前記複数のサーバノードの中から選択された他のサーバノードに対して前記接続要求を送信することをさらに含む、
前記方法。
１６．複数のサーバノードの各々の上にロードバランサモジュールを実装するためにコンピュータが実行可能なプログラム命令を記憶するコンピュータ読み取り可能な非一時的記憶媒体であって、各ロードバランサモジュールが、
クライアントからのパケットフローについての接続要求を複数のロードバランサノードの１つから受信し、
前記サーバノード上のサーバが前記接続を受諾できるかまたはできないかどうかを判定し、
前記サーバが前記接続を受諾できないと判定したときは前記接続要求を拒絶し、及び
前記サーバが前記接続を受諾できると判定したときは前記ロードバランサノードと前記サーバとが通信して、前記クライアントと前記サーバとの間に接続を確立する、
ように動作可能である、
前記コンピュータ読み取り可能な非一時的媒体。
１７．条項１６に記載された非一時的なコンピュータ読み取り可能な記憶媒体は、その中で、前記サーバノード上のサーバが前記接続を受諾できるかまたはできないかどうかを判定するために、前記ロードバランサモジュールが、前記サーバの１以上の現在の資源使用量のメトリクスを分析して、前記サーバが前記接続を受諾できるかどうかを決定することを実行できる前記コンピュータ読み取り可能な非一時的媒体。
１８．条項１７に記載された非一時的なコンピュータ読み取り可能な記憶媒体は、その中で、前記１以上の現在の資源使用量のメトリクスが、１以上のＣＰＵの使用、帯域幅の使用量、サーバ待ち時間、及び確立された接続数を含む、
前記コンピュー読み取り可能な非一時的記憶媒体。
１９．条項１６に記載されたコンピュータ読み取り可能な非一時的記憶媒体は、その中で、前記プログラム命令は、さらに、前記接続要求を受信するために前記複数のサーバノードの中からサーバノードをランダムに選択する前記ロードバランサモジュールを実現するようにコンピュータが実行できる、
前記非一時的なコンピュータ読み取り可能な記憶媒体。
２０．条項１６に記載されたコンピュータ読み取り可能な非一時的記憶媒体は、その中で、前記接続要求を拒絶するために、前記接続要求の中の生存時間（ＴＴＬ）カウンタを減じて、前記接続要求を前記ロードバランサノードに対して返送するように前記ロードバランサモジュールが動作でき、その中で、 前記プログラム命令は、さらに、前記ロードバランサノードが、
前記返送された接続要求の中の前記ＴＴＬカウンタを検査し、
前記ＴＴＬカウンタが閾値を超えている場合には、前記接続要求を受信するために前記複数のサーバノードの中から他のサーバノードを選択し、及び
前記ＴＴＬカウンタが前記閾値以下である場合には、前記接続要求を廃棄することを実現するようにコンピュータを実行可能にする、
前記コンピュータ読み取り可能な非一時的記憶媒体。
結論

【0212】

様々な実施形態は、さらに、上記の説明に従って、コンピュータ読み取り可能な媒体に実装される受信処理、送信処理、または記憶処理の命令及び／またはデータを有する。一般に、コンピュータ読み取り可能な媒体は、磁気媒体または光媒体などの記録媒体またはメモリ媒体、例えば、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の揮発性の媒体または不揮発性の媒体を含むが、それと同様に、電気信号、電磁気信号、またはデジタル信号などのように、ネットワーク及び／または無線リンクなどの通信媒体を介して運ばれる伝送媒体または信号も含む。

【0213】

図面及び本明細書に記載しているような様々な方法は、例示的な方法の実施形態を表わす。その方法は、ソフトウェア、ハードウェア、またはそれらの組み合わせの中に実装されている。方法の順序は変えることができ、様々な要素は、追加され、再配列され、組み合わされ、削除され、修正される等が可能である。

【0214】

様々な修正及び変更は、本開示の利益を享受する当業者にとって明らかなようになされるだろう。このような修正及び変更のすべてを包含することは意図されることであり、したがって、上記記載は制限的な意味ではなく例示的な意味に見なされるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図10A】

【図10B】

【図10C】

【図10D】

【図10E】

【図10F】

【図10G】

【図11A】

【図11B】

【図11C】

【図11D】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18A】

【図18B】

【図19A】

【図19B】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32】

【図33A】

【図33B】

【図34A】

【図34B】

【図35】

【図36】