JP6393742B2 - 分散型ロード・バランサでの多重パス経路指定 - Google Patents

分散型ロード・バランサでの多重パス経路指定 Download PDF

Info

Publication number
JP6393742B2
JP6393742B2 JP2016509081A JP2016509081A JP6393742B2 JP 6393742 B2 JP6393742 B2 JP 6393742B2 JP 2016509081 A JP2016509081 A JP 2016509081A JP 2016509081 A JP2016509081 A JP 2016509081A JP 6393742 B2 JP6393742 B2 JP 6393742B2
Authority
JP
Japan
Prior art keywords
node
load balancer
server
packet
nodes
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016509081A
Other languages
English (en)
Other versions
JP2016519533A (ja
Inventor
サード，ジェームズ・クリストファー ソレンソン，ザ
サード，ジェームズ・クリストファー ソレンソン，ザ
ローレンス，ダグラス・スチュワート
Original Assignee
アマゾン・テクノロジーズ・インコーポレーテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by アマゾン・テクノロジーズ・インコーポレーテッド filed Critical アマゾン・テクノロジーズ・インコーポレーテッド
Publication of JP2016519533A publication Critical patent/JP2016519533A/ja
Application granted granted Critical
Publication of JP6393742B2 publication Critical patent/JP6393742B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/24—Multipath
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • H04L45/745—Address table lookup; Address filtering
    • H04L45/7453—Address table lookup; Address filtering using hashing

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Description

従来のロード・バランサは複数のネットワーク・インターフェイス・コントローラ（ＮＩＣ）（例えば８つのＮＩＣ）を含む単一の専用のボックスであり、これらＮＩＣのいくつかはクライアントからのインバウンド・トラフィック／クライアントへのアウトバウンド・トラフィックを扱い、その他のＮＩＣはホスト装置（例えば、ウェブ・サーバなどのサーバ）からのアウトバウンド・トラフィック／ホスト装置へのインバウンド・トラフィックを扱っており、それらはロード・バランシングされている。これら従来のロード・バランサの帯域幅または処理能力は、一般的に、クライアント側で４０ギガビット毎秒（Ｇｂｐｓ）、サーバ側で４０Ｇｂｐｓの範囲にある。ネットワーク・ベースのアプリケーションおよびクラウド・コンピューティング・サービスなどのネットワーク・ベースのサービスの規模と範囲が増大するにつれて、データ・センタはロード・バランシングを必要とする何百または何千ものホスト装置（例えば、ウェブ・サーバ）を収容する場合がある。従来のロード・バランサでは、かかる環境でうまくスケールアップできない。
さらに、従来のロード・バランサは、一般的に、ホスト装置から集められたデータに適用される最大接続、ラウンド・ロビン、及び／または、最小接続などの技法を用いてどのホスト装置が接続を扱うのかを選択する。加えて、従来のロード・バランサは、一般的に、それが面するホスト装置がプロキシの役割をし、したがって、クライアントからの接続（たとえば、通信制御プロトコル（ＴＣＰ）接続）を終了させ、ホスト装置とロード・バランサとの間に確立されたＴＣＰ接続上でクライアント・トラフィックをホスト装置に送る。したがって、ホスト装置とクライアントは、これら従来のロード・バランサを使用するときには直接のＴＣＰ接続上で通信しない。
図１は、少なくともいくつかの実施形態による、分散型ロード・バランサ・システムの一例のブロック図である。 図２は、少なくともいくつかの実施形態による、図１の分散型ロード・バランサ・システムによって実装することができるロード・バランシング法の高レベルのフローチャートである。 図３は、少なくともいくつかの実施形態による、入口コンポーネント、出口コンポーネント、及びフロー・トラッカ・コンポーネントを含むロード・バランサ・ノードの一例を示す。 図４は、少なくともいくつかの実施形態による、分散型ロード・バランサの経路指定及びパケット・フローを示している。 図５は、少なくともいくつかの実施形態による、エッジ・ルータへの入口ノードの広告を示している。 図６は、少なくともいくつかの実施形態による、多重パス経路指定法のフローチャートである。 図７は、少なくともいくつかの実施形態による、非対称パケット・フローを図示している。 図８は、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示している。 図９Ａは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムで接続を確立するときのパケット・フローのフローチャートを提供する。 図９Ｂは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムで接続を確立するときのパケット・フローのフローチャートを提供する。 図１０Ａは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。 図１０Ｂは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。 図１０Ｃは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。 図１０Ｄは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。 図１０Ｅは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。 図１０Ｆは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。 図１０Ｇは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。 図１１Ａは、少なくともいくつかの実施形態による、ロード・バランサ・ノード・コンシステント・ハッシュ・リングのメンバー数に影響を及ぼす事象の取り扱いを示す。 図１１Ｂは、少なくともいくつかの実施形態による、ロード・バランサ・ノード・コンシステント・ハッシュ・リングのメンバー数に影響を及ぼす事象の取り扱いを示す。 図１１Ｃは、少なくともいくつかの実施形態による、ロード・バランサ・ノード・コンシステント・ハッシュ・リングのメンバー数に影響を及ぼす事象の取り扱いを示す。 図１１Ｄは、少なくともいくつかの実施形態による、ロード・バランサ・ノード・コンシステント・ハッシュ・リングのメンバー数に影響を及ぼす事象の取り扱いを示す。 図１２は、少なくともいくつかの実施形態による、健全性チェック間隔にしたがって各ロード・バランサ・ノードが行うことができる健全性チェック法の高レベルなフローチャートである。 図１３は、少なくともいくつかの実施形態による、別のロード・バランサ・ノードからあるロード・バランサ・ノードの健全性のチェックをする方法を示す。 図１４は、少なくともいくつかの実施形態による、１つまたは複数の他のロード・バランサ・ノードの健全性をチェックする１つのロード・バランサ・ノードを図示する。 図１５は、少なくともいくつかの実施形態による、サーバ・ノードの健全性をチェックするロード・バランサ・ノードを示す。 図１６は、少なくともいくつかの実施形態による、ロード・バランサ・ノード１１０により維持することができる別のノードの健全性の図を図示する。 図１７は、少なくともいくつかの実施形態による、各ロード・バランサ・ノードにより維持することができる健全性情報を示す。 図１８Ａは、少なくともいくつかの実施形態による、ロード・バランサ・ノードの故障の取り扱いを示す。 図１８Ｂは、少なくともいくつかの実施形態による、ロード・バランサ・ノードの故障の取り扱いを示す。 図１９Ａ、図１９Ｂは、少なくともいくつかの実施形態による、接続公表技法を図示する。 図２０は、少なくともいくつかの実施形態による、各ロード・バランサ・モジュールにより実施することができる接続公表法の高レベルなフローチャートである。 図２１は、少なくともいくつかの実施形態による、接続公表パケット内で受信されたアクティブな接続情報を標的ロード・バランサ・ノードに分散させる方法のフローチャートである。 図２２は、少なくともいくつかの実施形態による、接続公表パケット内で受信されたアクティブな接続情報を標的ロード・バランサ・ノードに分散させる代替方法のフローチャートである。 図２３は、少なくともいくつかの実施形態によるロード・バランサ・ノードのソフトウェア・スタック・アーキテクチャの例を示す。 図２４は、実施形態に用いることができるコア・パケット処理技術の態様を示す。 図２５は、少なくともいくつかの実施形態による、ロード・バランサ・ノード上のデータ・フローを処理する多重コア・パケット・プロセッサの例を示す。 図２６は、少なくともいくつかの実施形態による、ロード・バランサ・ノード上のデータ・フローを処理する多重コア・パケット・プロセッサの別の例を示す。 図２７は、少なくともいくつかの実施形態による、ロード・バランサ・ノード・プロセスによる着信パケットの処理を示す。 図２８は、少なくともいくつかの実施形態による、ロード・バランサ・ノード・プロセスによる発信パケットの処理を示す。 図２９は、少なくともいくつかの実施形態による、生産環境で分散型ロード・バランサを含むロード・バランシング・システムを示す。 図３０は、少なくともいくつかの実施形態による、複数の分散型ロード・バランシング・システム・コンポーネントが単一のプロセスでまたは単一のプロセスとして構成され実行されることを可能にするメッセージ・バス・メカニズムを取り込んだ分散型ロード・バランサ・テスト・システムを示す。 図３１は、少なくともいくつかの実施形態による、メッセージ・バス・パケット・アダプタ及びパケット・パイプラインを示す。 図３２は、少なくともいくつかの実施形態による、メッセージ・バス・パケット・アダプタ及びパケット・パイプラインを示す。 図３３Ａは、少なくともいくつかの実施形態による、プロバイダ・ネットワーク環境の例を示す。 図３３Ｂは、少なくともいくつかの実施形態による、図３３Ａに示すようなプロバイダ・ネットワーク環境の例における分散型ロード・バランサ実装を示す。 図３４Ａは、少なくともいくつかの実施形態による、分散型ロード・バランサ及びサーバ・ノードの物理的なラック実装の例を示す。 図３４Ｂは、少なくともいくつかの実施形態による、分散型ロード・バランサ及びサーバ・ノードの物理的なラック実装の別の例を示す。 図３５は、少なくともいくつかの実施形態による、１つ、２つまたはそれ以上の分散型ロード・バランサがネットワークに実装されたネットワーキング環境の例を示す。 図３６は、いくつかの実施形態で用いることができるコンピュータ・システムの例を示すブロック・ダイアグラムである。
本明細書でいくつかの実施形態及び説明図面の例により実施形態を説明してきたが、当業者なら、実施形態が説明した実施形態または図面に限定されないことが分かるであろう。図面及びその詳細な説明は、実施形態を開示された特定の形態に限定することを意図せず、反対に、添付した請求項に規定された精神と範疇内に当てはまるすべての修正形態、等価形態、及び代替形態を網羅する意図であることを理解すべきである。本明細書に用いられた表題は構成上の目的のためだけに用いられたものであり、明細書または請求項の範囲を限定するために使用されたものではない。本出願全体にわたって使用されるとき、用語「ｍａｙ」は義務的な意味（すなわち、ねばならないの意味）ではなく許容的な意味（すなわち、〜する可能性を有する意味）で用いられる。同様に用語「ｉｎｃｌｕｄｅ」、「ｉｎｃｌｕｄｉｎｇ」、及び「ｉｎｃｌｕｄｅｓ」は、〜に限定はされないが含む、の意味である。
発明の詳細な説明
ネットワーク環境における分散化されたロード・バランシングの方法及びシステムの様々な実施形態が記載されている。様々なネットワーク環境における分散型ロード・バランサの実施形態により実施することができる分散化されたロード・バランシングの方法及びシステムの実施形態が記載される。分散型ロード・バランサの実施形態は、例えば、インターネット及び宛先などの外部ネットワーク、一般的には、図３３Ａ及び３３Ｂに示されるプロバイダ・ネットワーク１９００などのローカル・ネットワーク上のサーバ（例えば、ウェブ・サーバ、アプリケーション・サーバ、データ・サーバ等）上のクライアント間のパケット・フロー（例えば、ＴＣＰ技術パケット・フロー）を促進および維持するために使用することができる。本明細書では、実施形態が、主としてＴＣＰパケット・フローの処理に関連して記載されているが、実施形態はＴＣＰ以外の他のデータ通信プロトコル及びパケット・フローの処理以外の他のアプリケーションにも適用することができることに留意されたい。
分散型ロード・バランサは、特定のクライアントと選択されたサーバ（例えば、ウェブ・サーバ）との間のＴＣＰパケット・フローを促進及び維持する作用をすることができる。しかし、分散型ロード・バランサは、クライアントからのＴＣＰフローを終了させない、また、従来のロード・バランサにおいてなされるようにサーバに対するプロキシの働きをすることはない。その代わり、分散型ロード・バランサのロード・バランサ・ノードはクライアントから受け取ったＴＣＰパケットを標的サーバに経路指定し、これらのサーバはそのＴＣＰスタックを用いてクライアントへのＴＣＰ接続を管理する。言い換えれば、これらのサーバがクライアントからのＴＣＰパケット・フローを終了させる。
加えて、従来のロード・バランサ技術でなされるようにサーバから集められた情報に適用されるロード・バランシング技法またはアルゴリズムに基づいてどのサーバが接続要請にサービスをするのかをロード・バランサ・ノードが決定する代わりに、ロード・バランサ・ノードは新たな接続要請を受けるサーバをランダムに選択することができ、サーバ・ノードに存在する分散型ロード・バランサのコンポーネントが、選択されたサーバが新たな接続要請を受けるか拒否するかにつきそれぞれのサーバの現状の１つまたは複数の指標に基づいて局所的に決定する。したがって、どのサーバが接続要請を受けるかについての決定は、ロード・バランサ・ノードから接続を扱うであろうサーバ・ノードに移行する。言い換えれば、この決定は、接続要請がサービスを受ける場所および時間のより近くに移行される。
クライアントとサーバとの間のパケット・フローを促進し維持するために、分散型ロード・バランサの実施形態は、限定はされないが、多重パス経路指定技術、コンシステント・ハッシング技術、分散化ハッシュ・テーブル（ＤＨＴ）技術、境界ゲートウェイ・プロトコル（ＢＧＰ）技術、メンバー数の追跡、健全性チェック、接続公表、並びに、パケットのカプセル化及びデカプセル化、を含む様々な技法または技術を採用することができる。分散型ロード・バランシング・システムのこれらの態様並びに他の態様を以下に図面を参照して説明する。
分散型ロード・バランシング・システム
図１は、少なくともいくつかの実施形態による分散型ロード・バランシング・システムの一例のブロック図である。分散型ロード・バランサの実施形態は、ネットワーク１００、例えば図３３Ａ、３３Ｂに示すサービス・プロバイダのプロバイダ・ネットワーク１９００で実装することができる。分散型ロード・バランンサ・システムでのクライアント・パケットの取り扱いの高レベルな概要として、ネットワーク１００の１つまたは複数のクライアント１６０は、例えばインターネットなどの外部ネットワーク１５０を介して、ネットワーク１００の境界ルータ１０２に接続することができる。境界ルータ１０２はクライアント１６０からの着信パケット（例えば、ＴＣＰパケット）を、分散型ロード・バランサ・システムのロード・バランサ・ノード層内のロード・バランサ（ＬＢ）ノード１１０にこれらの着信パケットを経路指定する分散型ロード・バランサのエッジ・ルータ１０４のコンポーネントに経路指定することができる。少なくともいくつかの実施形態において、エッジ・ルータ１０４は、フロー単位ハッシュ化多重パス経路指定技術、例えば、等コスト多重パス（ＥＣＭＰ）ハッシュ技術によって経路指定の決定を行なうことができる。ロード・バランサ・ノード１１０はこれらのパケットを（例えば、ユーザー・データグラム・プロトコル（ＵＤＰ）にしたがって）順次カプセル化しそれらのカプセル化パケットをネットワーク１００のネットワーク・ファブリック１２０（例えば、Ｌ３ネットワーク）を介してサーバ・ノード１３０上のローカル・ロード・バランサ・モジュール１３２に経路指定する。ファブリック１２０は、限定はされないが、スイッチ、ルータ及びケーブルを含む１つまたは複数のネットワークキング装置またはコンポーネントを含むことができる。サーバ・ノード１３０では、ローカル・ロード・バランサ・モジュール１３２がこれらのパケットをデカプセル化しサーバ１３４のＴＣＰスタックにこれらのクライアントＴＣＰパケットを送信する。サーバ・ノード１３０のサーバ１３４は、その後、そのＴＣＰスタックを用いてクライアント１６０への接続を管理する。
図２は、少なくともいくつかの実施形態による図１の分散型ロード・バランサ・システムによって実施することができるロード・バランシング法の高レベルのフローチャートである。分散型ロード・バランサ・システムの実施形態は、従来のロード・バランサで行われるように、多数の宛先（例えばウェブ・サーバ）の間に負荷を割り当てるという困難な問題を解決することができない。例えば、従来のロード・バランサは、一般的に、最大接続、ラウンド・ロビン及び／または最小接続の技法などの技法すなわちアルゴリズムを用いてどのサーバが接続を扱うかを選択する。しかし、これらの技法には欠点があり、特に、ロード・バランシングの決定に用いたデータがしばしばほとんどすぐに古くなる分散型システムにおいては成功裏に行なうのは困難である。分散型ロード・バランサ・システムの少なくともいくつかの実施形態では、従来のロード・バランサで行われるように１つまたは複数のロード・バランシング技術を使用することによってサーバ・ノード１３０を選択して接続要請を満たすように試みる代わりに、ロード・バランサ・ノード層のロード・バランサ・ノード１１０がランダムにサーバ・ノード１３０を決定してクライアントの接続要請を受けることができる。このサーバ・ノード１３０は、自身が過負荷であると考えたときは、ロード・バランサ・ノード１１０にこの接続要請を送り返すことができ、したがって、ロード・バランサ・ノード１１０にサーバ・ノード１３０が現在接続を扱えないことを知らせることができる。ロード・バランサ・ノード層は、その後、接続要請を受け取る別のサーバ・ノード１３０をランダムに決定することができ、あるいはその代わりに、要請中のクライアント１６０にエラー・メッセージを返して現在接続が設定できないことを知らせることもできる。
図２の１０で示したように、分散型ロード・バランサ・システムのロード・バランサ・ノード層は、ソースから通信セッション（例えばＴＣＰ接続）の要請を受ける。このソースは、例えば、分散型ロード・バランサ・システムを実施するネットワーク１００への外部ネットワーク１５０上のクライアント１６０でよい。少なくともいくつかの実施形態では、この要請をネットワーク１００の境界ルータ１０２でクライアント１６０から受けることができ、また、例えば、フロー単位等コスト多重パス（ＥＣＭＰ）ハッシュ技術を用いてクライアント１６０からの特定の接続要請を経路指定するロード・バランサ（ＬＢ）ノード１１０を擬似ランダムに選択して、着信パケットをロード・バランサ・ノード層のロード・バランサ・ノード１１０に経路指定することができるエッジ・ルータ１０４に、経路指定することができる。
２０で示したように、ロード・バランサ・ノード層は、宛先ノードをランダムに選択し、選択した宛先ノードに接続要請を送る。この宛先ノードは、例えば、ロード・バランサによって率いられた複数のサーバ・ノード１３０のうちの１つでよい。少なくともいくつかの実施形態では、ロード・バランサ層のロード・バランサ・ノード１１０は、すべての既知のサーバ・ノード１３０の中から接続要請を受けるサーバ・ノード１３０をランダムに選択することができる。しかし、いくつかの実施形態では、すべての既知のサーバ・ノード１３０の中からの純粋にランダムな選択以外の他の方法を用いて接続要請を受けることもできるサーバ・ノード１３０をランダムに選択することができる。例えば、いくつかの実施形態では、ロード・バランサ・ノード１１０がサーバ・ノード１３０に関する情報を用いてサーバ・ノード１３０のランダムな選択に重み付けすることができる。一例として、ロード・バランサ・ノード１１０が、異なるサーバ・ノード１３０が異なるタイプの装置であるか、または、異なるＣＰＵで構成されており、したがって異なる能力またはキャパシティを持つことを知っている場合、その情報を用いてサーバ・ノード１３０の特定のタイプまたは構成の方に（または、避けて）ランダムな選択にバイアスをかけることができる。
３０で示したように、宛先ノードは自身が通信セッションを受け入れることができるかどうかを判断する。少なくともいくつかの実施形態では、サーバ・ノード１３０上のローカル・ロード・バランサ（ＬＢ）モジュール１３２が、サーバ・ノード１３０上のそれぞれのサーバ１３４の１つまたは複数の指標に基づいてそれぞれのサーバ１３４が新たな接続を受け入れることができるかどうかを判断する。
４０では、接続要請が受理された場合は、５０で示されるようにその後、宛先ノードが自身が接続を扱うことができることをロード・バランサ・ノード層に知らせる。６０で示されるように、その後、ロード・バランサ・ノード層を介してソース（例えば、クライアント１６０）と宛先ノード（例えば、サーバ・ノード１３０上のサーバ１３４）との間に通信セッションが設定される。少なくともいくつかの実施形態では、サーバ・ノード１３０上のサーバ１３４は、ＴＣＰスタックを使用してクライアント１６０への接続を管理する。
４０では、接続要請が受理されなかった場合は、７０で示されるように、その後、宛先ノードがロード・バランサ・ノード層に通知し、本方法はエレメント２０に戻ることができる。ロード・バランサ・ノード層は、その後、２０で別の宛先ノードをランダムに選択することができるか、またはその代わりに、要請中のクライアント１６０に接続が現在設定できないことを知らせることができる。クライアント１６０は、必ずしも必要ではないが、接続要請を再提出して本方法をエレメント１０で再開することもできることに留意されたい。
再度、図１を参照すると、分散型ロード・バランサ・システムの少なくともいくつかの実施形態では、商品ハードウェアを使用してネットワーク１００上のエッジ・ルータ１０４で受けたクライアント・トラフィックをネットワーク１００上のサーバ・ノード１３０に経路指定することができる。分散型ロード・バランサの少なくともいくつかの実施形態では、複数のロード・バランサ・ノード１１０を含んだロード・バランサ・ノード層を含むことができる。少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０はそれぞれ、ロード・バランサ・ノード層での複数の役割のうちの１つまたは複数の役割を果たすことができる。ロード・バランサ・ノード１１０のこれらの役割には、入口ノード、出口ノード、及び、フロー・トラッカ・ノード（所与のパケット・フローの一次フロー・トラッカまたは二次フロー・トラッカとしての）が含まれ得る。少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０は、商品のラックマウントのコンピューティング・デバイスなどの個別のコンピューティング・デバイスとしてまたはそのデバイス上で、ロード・バランサ・ノード層内に実装することができる。少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０は、入口ノード、出口ノード、及び、フロー・トラッカ・ノード（パケット・フローの一次フロー・トラッカまたは二次フロー・トラッカとしての）の３つの役割のそれぞれを果たすことができ、一般には、ロード・バランサ・ノード１１０は特定のパケット・フローに対する役割のうちのただ１つのみ（しかし、可能性としては２つまたは３つ）を果たしている。しかし、少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０は、特定のパケット・フローに対する一次フロー・トラッカ及び二次フロー・トラッカの両方の役割は許容されないことに留意されたい。あるいは、いくつかの実施形態では、各ロード・バランサ・ノード１１０は、３つの役割のうちの１つのみを果たすことができる。この実施形態では、コンピューティング・デバイスの別個の組をロード・バランサ・ノード層に入口ノード、出口ノード及びフロー・トラッカ・ノードとして特異的に実装することができる。
少なくともいくつかの実施形態では、コンシステント・ハッシング技術とコンシステント・ハッシュ・リング技術を適用してパケット・フローに対する一次と二次のフロー・トラッカを決定することができる。クライアントからの各パケット・フローは、例えば、クライアントＩＰアドレス、クライアント・ポート、サーバ（パブリック）ＩＰアドレス及びサーバ・ポートからなる４要素の組によって一意的に識別することができる。この識別子は、クライアント及びパブリックの終点対を示すＣＰまたはＣｃＰｐと短縮することができる。任意の与えられたＴＣＰフロー（またはＣＰ対）に関連したパケットは、エッジ・ルータ１０４からのハッシュ化多重パス（例えば、ＥＣＭＰ）フロー分布のせいで入口サーバ１１２として動作する任意のロード・バランサ・ノード１１０上に現れることができる。コンシステント・ハッシングを用いて、パケットが入口ノードとして働くロード・バランサ・ノード１１０に到達したときにこの入口ノードがパケット・フローの状態を維持する責任を負うロード・バランサ・ノード１１０（すなわち、一次フロー・トラッカ・ノード）を決定することができる。ＣＰ対が入口ノードによってコンシステント・ハッシュ・リングにハッシングされ、どのロード・バランサ・ノード１１０がパケット・フローの状態情報を維持する責任を負うのかを決定することができる。コンシステント・ハッシュ・リング内のパケット・フローのＣＰ対のコンシステント・ハッシングにしたがって決定されるノード１１０は、パケット・フローに対する一次フロー・トラッカとして働くノード１１０である。少なくともいくつかの実施形態では、コンシステント・ハッシュ・リング内のサクセサ・ノードがパケット・フローに対する二次フロー・トラッカとして働く。
図３は、少なくともいくつかの実施形態により３つの役割（入口、出口及びフロー・トラッカ）を実装するコンポーネントを含むロード・バランサ（ＬＢ）ノード１１０の例を示す。この例では、入口サーバ１１２コンポーネントは、クライアントから入ってくるＴＣＰパケットを受け取りこのＴＣＰパケットをカプセル化パケットとしてサーバに送る、入口の役割を行う。出口サーバ１１４コンポーネントは、サーバから出て行くデカプセル化パケットを受け取りこのデカプセル化ＴＣＰパケットをクライアントに送る、出口の役割を行う。フロー・トラッカ１１６コンポーネントは、クライアント１６０とサーバ１３４の間で確立された１つまたは複数のパケット・フローに対する一次または二次フロー・トラッカとして働く。入口サーバ１１２もロード・バランサ・ノード１１０上のフロー・トラッカ１１６または別のロード・バランサ・ノード１１０上のフロー・トラッカ１１６と通信し、クライアントとサーバ１３４のうちの１つの間にそれぞれのクライアント１６０から受けた接続要請に応答してＴＣＰ接続を開始するか、またはパケット・フローのマッピング情報を得ることができる。もし出口サーバが、
ロード・バランサ・ノード
図１を再び参照すると、少なくともいくつかの実施形態では、ロード・バランサ・ノード層内のロード・バランサ・ノード１１０が、ネットワーク上の１つまたは複数のルータ１０４からのクライアント・トラフィック（パケット、例えば、ＴＣＰパケット）を受けファブリック１２０上の分散型ロード・バランサ・システムが用いるプロトコル（例えばユーザ・データグラム・プロトコル（ＵＤＰ））にしたがってこのパケットをカプセル化する。ロード・バランサ・ノード層は、その後、このカプセル化パケットをファブリック１２０上で宛先サーバ・ノード１３０に転送する。各サーバ・ノード１３０は、ロード・バランサ・システムのコンポーネントであるローカル・モジュール１３２を含む。このモジュール１３２は、本明細書では、ロード・バランサ・モジュールまたは単にＬＢモジュールと呼び、サーバ・ノード１３０上のソフトウェア、ハードウェアまたはそれらの組合せで実装することができる。各サーバ・ノード１３０では、それぞれのロード・バランサ・モジュール１３２がパケットをデカプセル化しこのＴＣＰパケットを通常のＴＣＰ処理のためにローカルＴＣＰスタックに送る。少なくともいくつかの実施形態では、ロード・バランサ・ノード層はすべてのクライアント・サーバＴＣＰフローの状態情報を維持することができるが、しかし、ロード・バランサ・ノード層内のロード・バランサ・ノード１１０はＴＣＰフローに関して何も読み取ることができない。各フローは、それぞれのサーバ・ノード１３０上のサーバ１３４とクライアント１６０の間で管理される。分散型ロード・バランサ・システムは、ＴＣＰパケットが正しい宛先サーバ１３４に到着することを保証する。各サーバ・ノード１３０でのロード・バランサ・モジュール１３２は、ロード・バランサ・ノード１１０から受けたクライアント接続要請に応じてそれぞれのサーバ１３４が新しい接続を受けるか拒否するかについての決定を行なう。
少なくともいくつかの実施形態では、分散型ロード・バランシング・システムは、コンシステント・ハッシング技術を使用して、例えば、どのサーバ・ノード１３０が特定のＴＣＰパケット・フローに責任を負うのかを記憶するロード・バランサ・ノード１１０を決定することができる。ロード・バランサ・ノード層内のロード・バランサ・ノード１１０は、コンシステント・ハッシング技術を用いてコンシステント・ハッシュ・リングとして見ることができる。また、ロード・バランサ・ノード１１０は、このリング内のメンバー数のトラックを保持し、コンシステント・ハッシング関数によって特定のパケット・フローに責任を負うリング内の特定のメンバー数を決定することができる。少なくともいくつかの実施形態では、クライアント１６０とサーバ１３４の間の各パケット・フローを追跡する責任を負う２つのロード・バランサ・ノード１１０があり、これらのノード１１０は一次フロー・トラッカ（ＰＦＴ）ノードおよび二次フロー・トラッカ（ＳＦＴ）ノードと呼ぶことができる。少なくともいくつかの実施形態では、一次フロー・トラッカは、フローに対するコンシステント・ハッシュ・リング上の第１ロード・バランサ・ノード１１０であり、二次フロー・トラッカは、一次フロー・トラッカ・ノードとは異なるコンシステント・ハッシュ・リング上の次のまたはその後のロード・バランサ・ノード１１０である。この配置で一次フロー・トラッカ・ノードが失敗した場合は、二次フロー・トラッカ・ノードが新たな一次フロー・トラッカになり、別のロード・バランサ・ノード１１０（例えば、コンシステント・ハッシュ・リング上の次のノード１１０）が二次フロー・トラッカの役割を引き継ぐことができる。少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０が与えられたパケット・フローに対する一次フロー・トラッカと二次フロー・トラッカの両方の働きをすることは許容されないことに留意されたい。コンシステント・ハッシュ・リング内のこのメンバー数の変更及び他のメンバー数の変更については、後ほど本文書で論じる。少なくともいくつかの実施形態では、ロード・バランサ実装（例えば、現在実装されているロード・バランサ・ノード１１０及びサーバ・ノード１３０の正式なリスト）の構成情報は、例えば、ファブリック１２０を介してロード・バランサ・ノード１１０に結合している１つまたは複数のサーバ装置に実装することができる分散型ロード・バランシング・システムの構成サービス１２２コンポーネントにより維持することができる。
少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０は、一次及び二次のフロー・トラッカ・ノードとして働くことに加えて、さらに、与えられたフローに対する他の２つの役割（入口ノードの役割と出口ノードの役割）のうちの１つを果たすこともできる。パケット・フローに対する入口ノードは、エッジ・ルータ１０４からそれぞれのパケット・フローを受け取り、ファブリック１２０を介してサーバ・ノード１３０上の選択されたサーバ１３４へパケット・フロー（カプセル化パケットとして）を転送するロード・バランサ・ノード１１０である。入口ノードは、実際のクライアント・データ（ＴＣＰデータ・パケット）をそれぞれの宛先サーバ・ノード１３０に移動させる唯一のロード・バランサ・ノード１１０である。入口ノードは、宛先サーバ・ノード１３０上のそれぞれのロード・バランサ・モジュール１３２へのＴＣＰフローのマッピングを維持して、入口ノードがどのロード・バランサ・モジュール１３２がクライアント・トラフィックを転送するのかが分かるようにする。出口ノードは、ファブリック１２０を介してサーバ・ノード１３０から受け取ったパケット・フローの応答トラフィックを境界ネットワークを介してそれぞれのクライアント１６０に転送する責任を負ったロード・バランサ・ノード１１０である。ロード・バランサ・モジュール１３２は、ロード・バランサ・プロトコル（例えば、ＵＤＰ）にしたがってサーバ１３４から得た応答パケットをカプセル化して、このカプセル化された応答パケットをファブリック１２０を介してそのフローのそれぞれの出口ノードに送る。出口ノードはステートレスであり、このパケットを単にデカプセル化し、外部ネットワーク１５０を介してそれぞれのクライアント１６０に送達するための境界ネットワーク上の境界ルータ１０２にこの応答パケット（例えば、ＴＣＰパケット）を送る。
先に述べたように、少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０は、異なるパケット・フローに対する入口ノード、出口ノード及び／またはフロー・トラッカ・ノード（一次または二次のフロー・トラッカのうちのいずれかとして)の役割を果たすことができる。ロード・バランサ・ノード層内の単一のロード・バランサ・ノード１１０は、このノードが処理しているパケット・フローに応じて、これら役割のうちの任意の１つを果たすことができる。例えば、少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０は、１つのパケット・フローに対する入口ノード、別のパケット・フローに対する一次または二次のフロー・トラッカ、及び、さらに別のパケット・フローに対する出口ノードとしての役割を果たすことができる。加えて、少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０が同一のパケット・フローに対して複数の役割（例えば、ある与えられたパケット・フローに対する入口ノード及び一次（または二次）フロー・トラッカ・ノードとしての役割）を果たすことができる。しかし、少なくともいくつかの実施形態では、冗長性と回復の目的のために、ロード・バランサ・ノード１１０が同一のパケット・フローに対して一次と二次のフロー・トラッカ・ノード両方の役割を果たすことは許容されない。
上記では、各ロード・バランサ・ノード１１０が、入口サーバ、出口サーバ及びフロー・トラッカの３つの役割のうちの任意の役割を果たすことができる実施形態を説明している。しかし、いくつかの実施形態では、異なるグループのコンピューティング装置はロード・バランシング・システムの異なる役割に割り当てることができる。例えば、いくつかの実施形態では、それぞれが別個のコンピューティング装置上に実装された入口ノード、出口ノード及びフロー・トラッカ・ノードの個別の組が存在できる。別の例として、いくつかの実施形態では、１組のコンピューティング装置が入口ノード及びフロー・トラッカ・ノードの両方の働きをすることができ、他方で、別の組のコンピューティング装置は出口ノードとしてのみ働くことができる。
ロード・バランサ・モジュール
前に述べたように、各サーバ・ノード１３０は、ロード・バランサ・システムのコンポーネントであるローカル・ロード・バランサ・モジュール１３２を含む。モジュール１３２は、サーバ・ノード１３０上のソフトウェア、ハードウェアまたはそれらの組合せにおいて実装することができる。少なくともいくつかの実施形態では、サーバ・ノード１３０上のロード・バランサ・モジュール１３２は３つの主な役割（外出パケットをカプセル化すること、着信パケットをデカプセル化すること及びノード１３０上のサーバ１３４に対するローカル・ロード・バランシングの決定を下し接続を公表すること）を果たすことができる。これらの３つの役割は、以下に簡潔に記述され、その後、本明細書により詳細に記述されている。
少なくとも分散型ロード・バランシング・システムのいくつかの実施形態では、ＴＣＰ接続が終了されず、パケットのなりすましがなされない。すなわち、ロード・バランサ・ノード層によって送られたすべてのパケットのソースと宛先のＩＰアドレスは、パケット・フローに関与する終点（すなわち、クライアント１６０及びサーバ１３４）の実際のＩＰアドレスである。なりすましの代わりに、これらの実施形態では、ファブリック１２０上のロード・バランサ・ノード１１０とサーバ・ノード１３０との間に送られるすべてのパケットが、例えばＵＤＰパケットとしてカプセル化される。パケット・フロー内の入口ノードとして働くロード・バランサ・ノード１１０からサーバ・ノード１３０に到着するパケット・フロー内のインバウンド・パケットはロード・バランサ・ノード１１０によってカプセル化されるので、これらのパケットをデカプセル化しノード１３０上のサーバ１３４のローカルホストＴＣＰフローに向け直す必要がある。ノード１３０上のロード・バランサ・モジュール１３２がこのデカプセル化を行う。同様に、サーバ１３４からのパケット・フローの発信パケットはロード・バランサ・モジュール１３２によってカプセル化され、パケット・フローの出口ノードとして働くロード・バランサ・ノード１１０にファブリック１２０を介して送られる。
少なくともいくつかの実施形態では、サーバ・ノード１３０上のロード・バランサ・モジュール１３２も、それぞれのサーバ・ノード１３０上のサーバ１３４のロード・バランシングに関してローカルに決定を行う。具体的には、ノード１３０上のロード・バランサ・モジュール１３２は、新たなＴＣＰ接続要請を受けてそれぞれのサーバ１３４が別のＴＣＰフローを受けるかどうかを決定する。先に述べたように、ロード・バランサ・ノード１１０がロード・バランサ・モジュール１３２に送られるすべてのパケットをカプセル化し、したがって、ロード・バランサ・モジュール１３２は実際にクライアント１６０からのＴＣＰ同期（ＳＹＮ）パケットを受け取らず、その代わり、ロード・バランサ・モジュール１３２は、カプセル化プロトコル（例えば、ＵＤＰ）にしたがって、ロード・バランサ・モジュール１３２が受理するかまたは拒否することができる接続要請メッセージをフロー・トラッカ１１６から受け取る。ロード・バランサ・モジュール１３２が接続要請メッセージを受理すると、ロード・バランサ・モジュール１３２はローカルホストに向かうＳＹＮパケットを生成する。ローカルホストが接続を受理するときに、これはそれぞれのクライアント接続を扱う実際のＴＣＰスタックになる。
少なくともいくつかの実施形態では、接続要請メッセージを受理すべきかどうかに関する決定をするために、ロード・バランサ・モジュール１３２は、サーバ・ノード１３０上の現在のリソース消費量に関する１つまたは複数の指標を見る。そして、新しい接続を取り扱うことができる十分なリソースがあるならば、ロード・バランサ・モジュール１３２は接続を受理する。少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２が考慮することができるリソース指標は、限定はされないが、ＣＰＵ利用率、最近の帯域幅消費量及び確立した接続数のうちの１つまたは複数のものを含むことができる。いくつかの実施形態では、これらの指標の代わりに、またはそれらに加えて他の指標を考慮することができる。例えば、いくつかの実施形態では、ロード・バランサ・モジュールは、指標としてサーバ待ち時間（すなわち、要請時間はサーバの接続処理待ちで消費される）を考慮することができ、サーバ待ち時間が閾値を超えると接続要請を拒否することができる。これらの指標及び／または他の指標を用いて、ロード・バランサ・モジュール１３２は、それぞれのサーバ１３４につき新たなパケット・フローを受け入れるか拒否するかを決定することができる。少なくともいくつかの実施形態では、リソースの使用割合（例えば、使用率Ｎ％）を指標から個々にまたは閾値（例えば、９０％）との組み合わせ及び比較で決定することができる。決定したリソース使用率が閾値となるかまたは閾値を超えるなら、あるいは、接続を追加すると使用率が閾値を超えるならば、接続要請を拒絶することができる。
少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２は、接続要請メッセージを拒絶すべきかどうかを決定する確立論的方法を実装することができる。リソース使用率が閾値であるか閾値を超えている場合、上記のようにすべての接続要請を拒絶する代わりに、この方法では、２つまたはそれを超える異なるレベルの使用率において異なる確率で接続要請を拒絶することができる。例えば、リソース使用率が８０％ならば、ロード・バランサ・モジュール１３２は２０％の確率で接続要請を拒絶することができ、リソース使用率が９０％ならば、ロード・バランサ・モジュール１３２は２５％の確率で接続要請を拒絶することができ、リソース使用率が９５％ならば、ロード・バランサ・モジュール１３２は５０％の確率で接続要請を拒絶することができ、リソース使用率が９８％ならば、ロード・バランサ・モジュール１３２はすべての接続要請を拒絶することができる。
少なくともいくつかの実施形態では、各接続要請メッセージは、接続要請メッセージがロード・バランサ・モジュール１３２に何回拒絶されたかの表示を含むことができる。ロード・バランサ・モジュール１３０が受け取った接続要請メッセージが閾値の回数を超えて拒絶されたことを表示していれば、ロード・バランサ・モジュール１３０は、たとえサーバ・ノード１３０の性能指標が接続要請を拒絶すべきであると示していても接続を受理することができる。
いくつかの場合では、接続要請メッセージが送られるすべてのロード・バランサ・モジュール１３２が接続要請を拒絶することができる可能性がある。少なくともいくつかの実施形態では、接続要請メッセージが無期限にロード・バランサ・モジュール１３２からロード・バランサ・モジュール１３２に飛び込んでいくのを防ぐために、各接続要請メッセージに生存時間を与えることができる。生存時間が終わると、フロー・トラッカ・ノードは要請を終了し、それぞれのクライアント１６０に要請が現在なされ得ないことを知らせることができる。
少なくともいくつかの実施形態では、サーバ・ノード１３０上のロード・バランサ・モジュール１３２はまた、ロード・バランサ・ノード１１０に接続公表を行うこともできる。少なくともいくつかの実施形態では、定期的にまたは非定期に（例えば、１秒に一回）接続公表を行なうために、各ロード・バランサ・モジュール１３２はサーバ・ノード１３０をルーティング・テーブル（例えば、ネットスタット・ルーティング・テーブル)で見て、ロード・バランサ・ノード１１０にアクティブな接続（ＴＣＰフロー）のリストを公表する。ある所与のパケット・フローの存在につき通知する必要のあるロード・バランサ・ノード１１０は、それぞれのパケット・フローに対する入口ノード及び一次と二次のフロー・トラッカの働きをするロード・バランサ・ノード１１０である。いくつかの実施形態では、ロード・バランサ・モジュール１３２は、コンシステント・ハッシング技術を用いてサーバ・ノード１３０上のアクティブなＴＣＰフローにつき通知する必要のあるロード・バランサ・ノード１１０のリストをフィルタリングすることができる。例えば、ロード・バランサ・モジュール１３２は、コンシステント・ハッシュ・リングによって、どのロード・バランサ・ノード１１０がそれぞれ与えられたパケット・フローに対する一次及び二次のフロー・トラッカとしての働きをしているのかを決定することができる。いくつかの実施形態では、ロード・バランサ・モジュール１３２は、どのバランサ・ノード１１０がロード・バランサ・モジュール１３２に各パケット・フローに対するデータ・パケットを最後に送ったのかを追跡し、この情報を用いてどのロード・バランサ・ノード１１０がパケット・フローの入口ノードとして働くかを決定する。なぜなら、入口ノードのみがクライアント・データをロード・バランサ・モジュール１３２に転送するからである。いくつかの実施形態では、その後、ロード・バランサ・モジュール１３２は、パケット・フローを通知する必要があると自身が決定した各ロード・バランサ・ノード１１０に対するメッセージを策定し、各ロード・バランサ・ノード１１０にメッセージを送信してそれぞれのサーバ・ノード１３０がクライアント１６０への接続を依然として維持していることを当該ノード１１０に知らせる。ロード・バランサ・モジュール１３２がロード・バランサ・ノード１１０に行なうこの接続公表は、ロード・バランサ・ノード１１０のリース期間の延長とみなすことができる。ロード・バランサ・ノード１１０がある時間（例えば、１０秒）内に特別なパケット・フローを示す接続公表メッセージを受け取らないならば、その後、ロード・バランサ・ノード１１０はそれぞれのパケット・フローにつき自由に忘れることができる。
ロード・バランサ・ノードへの多重パス経路指定
図４は、少なくともいくつかの実施形態による、分散型ロード・バランサでの経路指定及びパケット・フローの態様を示す。少なくともいくつかの実施形態では、各入口ノード（入口ノードは入口サーバ１１２として図４に示されている）は、例えば、境界ゲートウェイ・プロトコル（ＢＧＰ）を介して１つまたは複数のパブリック終点（例えば、ＩＰアドレスとポート）を分散型ロード・バランサのエッジ・ルータ１０４に経路指定する自身の能力を広告する。少なくともいくつかの実施形態では、ＢＧＰセッションを介してエッジ・ルータ１０４に自身を広告する各入口ノードではなく、図５に示すように、１つまたは複数の他の入口ノード（例えば、２つの隣接ノード）がエッジ・ルータ１０４とＢＧＰセッションを確立して当該入口ノードを広告することもできる。
従来のロード・バランサは、一般に、単一のパブリック終点のみの働きをすることができる。対照的に、分散型ロード・バランサの実施形態では、多数のロード・バランサ・ノード１１０が単一のパブリック終点を提供することができる。これによって、ルータの能力に依存して、すべての入口サーバ１１２に経路指定された単一のパブリックＩＰアドレスが、エッジ・ルータ１０４によって全帯域幅（例えば、１６０Ｇｂｐｓ）を扱うことができる構成が可能になる。少なくともいくつかの実施形態では、この構成を達成するために、エッジ・ルータ１０４は４層フロー単位ハッシュ化多重パス経路指定技法（例えば、等コスト多重パス（ＥＣＭＰ）経路指定技法）を利用してそれぞれが同じパブリックＩＰアドレスを広告する複数の入口サーバ１１２全体にわたってトラフィックを分散させる。フローの４層ソース及び宛先ポートをエッジ・ルータ１０４の一部として用いて着信パケットをすべての入口サーバ１１２に分散させることで、フロー・ハッシュは、一般的に、乱れたパケットを回避するために入口サーバ１１２として働く同一のロード・バランサ・ノード１１０に経路指定された各接続に対するパケットを保持することができる。しかし、いくつかの実施形態では、エッジ・ルータ１０４は、他の技法を用いてトラフィックを入口サーバ１１２全体にわたって分散させることができることに留意されたい。
図４は、また、２つ以上の分散型ロード・バランサをネットワーク１００上に実装することもできることも示している。これらの２つ以上の分散型ロード・バランサは、それぞれ、複数のサーバ１３０を率い、異なるパブリックＩＰアドレスを広告する独立したロード・バランサとして働くことができる。またはその代わりに、図４に示すように２つ以上の分散型ロード・バランサがそれぞれ同一のＩＰアドレスを広告することもできる。また、ハッシング技術（例えば、４層フロー単位ハッシュ化多重パス経路指定技法）を境界ルータ１０２で用いて、パケット・フローを次々にそれらの対応する入口サーバ１１２に分散させるエッジ・ルータ１０４にパケット・フローを分散させることができる。
図５は、少なくともいくつかの実施形態により、境界ゲートウェイ・プロトコル（ＢＧＰ）を用いてエッジ・ルータに入口ノードを広告することを示す。この例において、ロード・バランサ実装で入口ノード１１０Ａ〜１１０Ｄの働きをする４つのロード・バランサ・ノードが存在する。エッジ・ルータ１０４はクライアント（図示せず）からロード・バランサ・ノード１１０まで着信パケットを経路指定する。少なくともいくつかの実施形態では、エッジ・ルータ１０４が、４層フロー単位ハッシュ化多重パス経路指定技法（例えば、等コスト多重パス（ＥＣＭＰ）経路指定技法）によって経路指定の決定をすることができる。
少なくともいくつかの実施形態では、エッジ・ルータ１０４は、ロード・バランサ実装において、入口ノード１１０によって開始されたセッションを広告する境界ゲートウェイ・プロトコル（ＢＧＰ）技術を介してクライアント・トラフィックを現在受け取ることができる入口ノード１１０を見つける。各入口ノード１１０はＢＧＰを用いて自身をエッジ・ルータ１０４に広告することができるはずである。しかし、ＢＧＰは、一般的に、収束するのに比較的長い時間（３秒以上）を要する。各入口ノード１１０がＢＧＰを介して自身を広告するこの技法を用いると、入口ノード１１０が故障した場合、エッジ・ルータ１０４上のＢＧＰセッションが中断し、それによって、エッジ・ルータ１０４が故障中止を知り現在のＴＣＰフローを入口ノード１１０に再度経路指定するのに、ネットワーク上の期間としてはかなりの時間（３秒以上）を要し得る。
ＢＧＰに関連する収束問題を回避しノード１１０の故障をより速く回復するために、少なくともいくつかの実施形態では、ＢＧＰセッションを介してエッジ・ルータ１０４に自身を広告する入口ノード１１０の代わりに、ロード・バランサ実装における少なくとも１つの他の入口ノード１１０がＢＧＰセッションを介してエッジ・ルータ１０４に当該の入口ノード１１０を広告する責任を負う。例えば、図５に示すようないくつかの実施形態では、ある与えられた入口ノード１１０の左隣と右隣の入口ノード１１０、例えば、ノード１１０の整列されたリスト（例えば、ノード１１０によって形成されるコンシステント・ハッシュ・リング）での左隣と右隣が、この与えられた入口ノード１１０をエッジ・ルータ１０４に広告することができる。例えば、図５では、入口ノード１１０Ａが入口ノード１１０Ｂ、１１０Ｄを広告し、入口ノード１１０Ｂが入口ノード１１０Ａ、１１０Ｃを広告し、入口ノード１１０Ｃが入口ノード１１０Ｂ、１１０Ｄを広告し、そして、入口ノード１１０Ｄが入口ノード１１０Ｃ、１１０Ａを広告する。入口ノード１１０は、後ほど本明細書で説明するように、互いの健全性をチェックしうわさとして広める。説明されるような健全性チェック法を用いると、不健全なノードを検出し、１秒未満、例えば１００ミリ秒（ｍｓ）、でノード１１０の間にこの情報を広めることができる。ある入口ノード１１０が健全ではないと決定すると、不健全なノードを広告する入口ノード１１０はこの不健全なノード１１０を広告することを直ちに止めることができる。少なくともいくつかの実施形態では、入口ノード１１０は、ＢＧＰセッションに対するＴＣＰ閉鎖メッセージまたは類似のメッセージをエッジ・ルータ１０４に送ることにより、エッジ・ルータ１０４とのＢＧＰセッションを終了する。したがって、あるノード１１０の故障を検出するためにこの故障ノード１１０が確立したＢＧＰセッションの中断を待たなければならないのではなく、故障ノード１１０の代わりに広告し、ノード１１０が不健全であることを検出すると、このノード１１０を広告する他の入口ノードがエッジ・ルータ１０４とのＢＧＰセッションを終了させるときにこの故障ノード１１０を発見することができる。ロード・バランサ・ノードの故障の取り扱いは、本明細書で図１８Ａ、１８Ｂに関して後程論じる。
図６は、分散型ロード・バランシング・システムの少なくともいくつかの実施形態による、多重パス経路指定法のフローチャートである。９００で示されたように、ロード・バランサ実装での入口ノード１１０は、それらの隣接ノード１１０をエッジ・ルータ１０４に広告する。少なくともいくつかの実施形態では、入口ノード１１０は、コンシステント・ハッシュ・リングなどのノード１１０の整列したリストに従ってそれらの隣接ノード１１０を決定することができる。少なくともいくつかの実施形態では、入口ノード１１０は、ＢＧＰセッションを用いてそれらの隣接ノード１１０をエッジ・ルータ１０４に広告し、これらのＢＧＰセッションは広告された各ノード１１０に対して１つのＢＧＰセッションがエッジ・ルータ１０４と確立される。
９０２で示されるように、エッジ・ルータ１０４は、フロー単位ハッシュ化多重パス経路指定技法（例えば、等コスト多重パス（ＥＣＭＰ）経路指定技術）にしたがって、クライアント１６０から受け取ったトラフィックをアクティブな（広告された）入口ノード１１０に分散させる。少なくともいくつかの実施形態では、エッジ・ルータ１０４はクライアント１６０にパブリックＩＰアドレスを公表し、すべての入口ノード１１０がエッジ・ルータ１０４に同じパブリックＩＰアドレスを広告する。エッジ・ルータは、４層ソース及び宛先ポートをエッジ・ルータ１０４のフロー・ハッシュの一部として使用して入口ノード１１０の間に着信パケットを分散させる。これによって、一般的に、同一の入口ノード１１０に経路指定された各接続に対するパケットが保持される。
９０２で示されるように、入口ノードはデータ・フローを標的サーバ・ノード１３０に転送する。少なくともいくつかの実施形態では、入口ノード１１０は、データ・フローに対する一次及び二次のフロー・トラッカ・ノードと相互に作用してデータ・フローを標的サーバ・ノード１３０にマッピングする。したがって、各入口ノード１１０は、標的サーバ・ノード１３０に受け取ったパケットを適切に転送するのに使用することができるノード１１０によってアクティブなデータ・フローのマッピングを維持することができる。
要素９０６〜９１０は、入口ノード１１０の故障を検知し故障から回復することに関する。９０６に示すように、入口ノード１１０は、ある入口ノード１１０が故障したことを、例えば、本明細書で記載したような健全性チェック技法によって、検出することができる。この入口ノード１１０が故障したことを検出すると、その隣接ノード１１０はエッジ・ルータ１０４へのこの入口ノード１１０の広告を停止する。少なくともいくつかの実施形態では、このことはそれぞれのＢＧＰセッションのエッジ・ルータ１０４にＴＣＰ閉鎖メッセージを送ることを伴う。
９０８で示されるように、エッジ・ルータ１０４は、ＢＧＰセッションの閉鎖を介して入口ノード１１０が故障したことを検出すると、フロー単位ハッシュ化多重パス経路指定技法に従って、クライアント１６０からの着信トラフィックを残りの入口ノード１１０に再分散させる。したがって、少なくともいくつかのデータ・フローを異なる入口ノード１１０に経路指定することができる。
９１０で示されるように、入口ノード１１０は、必要に応じて、マッピングを回復し、データ・フローを適切な標的サーバ・ノードに転送することができる。入口ノード１１０のノード１１０故障から回復する方法は、本明細書の別の箇所で論じられる。一例として、ある入口ノード１１０は、現在のマッピングを持っていないパケットを受け取ると、コンシステント・ハッシュ関数を用いてコンシステント・ハッシュ・リングによるデータ・フローに対するフロー・トラッカ・ノードを決定し、このフロー・トラッカ・ノードからマッピングを回復することができる。
非対称なパケット・フロー
少なくともいくつかの実施形態では、入口ノード帯域幅及びＣＰＵ使用を効率的に利用するために、インバウンド・データに対するアウトバウンド・トラフィックの比率が１以上であるときに分散型ロード・バランシング・システムは、図７に示すようにサーバ・ノード１３０から多数の出口ノードへアウトバウンド・パケットを転送する。少なくともいくつかの実施形態では、各接続に対して、それぞれのサーバ・ノード１３０上のロード・バランサ・モジュール１３２は、クライアント終点／パブリック終点の組をハッシングし、コンシステント・ハッシュ・アルゴリズムを用いてそれぞれのアウトバウンド・パケット・フローの出口サーバ１１４の働きをするロード・バランサ・ノード１１０を選択する。しかし、いくつかの実施形態では、他の方法及び／またはデータを用いて接続の出口サーバ１１４を選択することもできる。選択された出口サーバ１１４は、必ずではないが一般的に、接続の入口サーバ１１２の働きをするロード・バランサ・ノード１１０とは異なるロード・バランサ・ノード１１０であり得る。少なくともいくつかの実施形態では、このロード・バランサ・ノード１１０／出口サーバ１１４の故障がなければ、この特別な接続のアウトバウンド・パケットは乱れたパケットを回避するためにすべて同じ出口サーバ１１４に転送されるであろう。
少なくともいくつかの実施形態では、サーバ・ノード１３０による出口サーバ１１４の選択に使用される方法およびデータは、エッジ・ルータ１０４によってなされる入口サーバ１１２の選択に使用される方法及びデータとは異なってよい。異なった方法及びデータを使用することで、一般に、ある与えられた接続の出口ノードとして選択されるロード・バランサ・ノード１１０は、この接続の入口ノードとして選択されたロード・バランサ・ノード１１０とは異なる結果となり得る。そして、多数のロード・バランサ・ノード１１０が選択されて、入口ノードとして働く単一のロード・バランサ・ノード１１０を通過する接続用の発信トラフィックを扱う結果となり得る。
図７は、少なくともいくつかの実施形態による、非対称のパケット・フローを図示している。少なくとも１つの接続が、外部ネットワーク１５０上のクライアント１６０から入口サーバ１１２を通ってサーバ・ノード１３０Ａ、１３０Ｂ、１３０Ｃ、１３０Ｄのそれぞれとに確立される。少なくともいくつかの実施形態では、各接続に対して、接続用出口ノードを選ぶために、それぞれのサーバ・ノード１３０上のロード・バランサ・モジュール１３２は、クライアント終点／パブリック終点の組をハッシングし、コンシステント・ハッシュ・アルゴリズムを用いてそれぞれのアウトバウンド・パケット・フローの出口サーバ１１４として働くべきロード・バランサ・ノード１１０を選択する。例えば、サーバ・ノード１３０Ａはある１つの接続の出口サーバ１１４Ａを選択しており、サーバ・ノード１３０Ｂは１つの接続の出口サーバ１１４Ａと別の接続の出口サーバ１１４Ｂを選択している。しかし、いくつかの実施形態では、他の方法及び／またはデータを用いて接続の出口ノードを選択することができる。
クライアント接続停止のないロード・バランサ・ノード故障からの回復
ロード・バランサ・ノード１１０は、コンシステント・ハッシングを用いてどのサーバ・ノード１３０がクライアント・トラフィックを受け取るべきかを決定することができる一方、いくつかの接続の長い寿命により、この手法は、新しいサーバ・ノード１３０がコンシステント・ハッシングのメンバーに加わり、後に入口ロード・バランサ・ノード１１０の故障が発生した場合、既存のフローを維持できない。この状況では、サーバ１３０のコンシステント・ハッシュ・リングが異なるメンバーを持つはずなので、故障ノード１１０からのフローを引き継ぐロード・バランサ・ノード１１０は、選択された元のマッピングを決定することができない。したがって、少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０が、分散型ハッシュ・テーブル（ＤＨＴ）技術を用いて接続のサーバ・ノード１３０を選び、パケットをこの選択されたサーバ・ノード１３０に経路指定することができる。一旦、サーバ・ノード１３０がＤＨＴによって選択されて特別な接続を受けており、かつ、サーバ・ノード１３０が健全であり続け、サーバ・ノード１３０上のロード・バランサ・モジュール１３２がこのアクティブな接続の状況をＤＨＴに定期的に送信すること（例えば、接続公表を介して）でリース期間を延長し続けたと仮定すると、ＤＨＴは接続が完了するまでマッピングを保持するであろう。入口ノード１１０の故障は、エッジ・ルータ１０４から残りのロード・バランサ・ノード１１０までのパケットの分布に影響を与え、その結果、ロード・バランサ・ノード１１０が異なる組のクライアント接続からのトラフィックを受け取る。しかし、ＤＨＴがアクティブな接続をすべて追跡するので、ロード・バランサ・ノード１１０は、ＤＨＴに尋ねて任意のアクティブなマッピングに対するリースを得ることができる。その結果、すべてのロード・バランサ・ノード１１０は、トラフィックを正しいサーバ・ノード１３０に渡し、これにより、入口ロード・バランサ・ノード１１０の故障の場合でさえアクティブなクライアント接続の失敗を防ぐであろう。
分散型ロード・バランシング・システムでのパケット・フロー
図８は、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムでのパケット・フローを示す。図８で、矢印つき実線はＴＣＰパケットを表わしている一方、矢印つき点線はＵＤＰパケットを表わしていることに留意されたい。図８では、入口サーバ１１２はエッジ・ルータ１０４を介して１つまたは複数のクライアント１６０からＴＣＰパケットを受け取る。ＴＣＰパケットを受け取ると、入口サーバ１１２は、自身がこのＴＣＰパケット・フローのサーバ・ノード１３０へのマッピングを有しているかどうかを判断する。入口サーバ１１２がＴＣＰパケット・フローのマッピングを有しているならば、サーバ１１２は（例えば、ＵＤＰによって）ＴＣＰパケットをカプセル化し、このカプセル化パケットを標的サーバ・ノード１３０に送る。入口サーバ１１２がＴＣＰパケット・フローのマッピングを有していないならば、入口サーバ１１２はＴＣＰパケットから抽出されたＴＣＰパケット・フローに関する情報を含んだＵＤＰメッセージを一次フロー・トラッカ１１６Ａに送りサーバ・ノード１３０への接続を確立することができ、かつ／または、ＴＣＰパケット・フローのマッピングを得ることができる。図９Ａ、９Ｂ、及び図１０Ａ〜１０Ｇは、クライアント１６０とサーバ・ノード１３０との間に接続を確立する方法を示す。サーバ・ノード１３０上のロード・バランサ・モジュール１３２は、サーバ・ノード１３０上のＴＣＰ接続の出口サーバ１１４として働くべきロード・バランサ・ノード１１０をランダムに選択し、出口サーバ１１４を介してＵＤＰカプセル化ＴＣＰ応答パケットをクライアント１６０に送る。
図９Ａ、９Ｂは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システム内で接続を確立する場合のパケット・フローのフローチャートを提供する。図９Ａの２００に示すように、入口サーバ１１２は、エッジ・ルータ１０４を介してクライアント１６０からＴＣＰパケットを受け取る。２０２では、入口サーバ１１２がサーバ・ノード１３０までのＴＣＰフローのマッピングを有していれば、２０４で示すように、入口サーバ１１２はＴＣＰパケットをカプセル化しそれぞれのサーバ・ノード１３０に送る。入口サーバ１１２は、１つ、２つ、またはそれを超えるクライアント１６０からの１つ、２つ、またはそれを超えるＴＣＰフローのパケットを絶えず受け取ることができ、かつ処理することができていることに留意されたい。
２０２では、入口サーバ１１２がＴＣＰフローのマッピングを有していないならば、このパケットはクライアント１６０からのＴＣＰ同期（ＳＹＮ）パケットであり得る。２０６で示されるように、ＳＹＮパケットを受け取ると、入口サーバ１１２はこのＳＹＮパケットからデータを抽出してこのデータを、例えば、ＵＤＰメッセージの形で、一次フロー・トラッカ１１６Ａに転送する。少なくともいくつかの実施形態では、入口サーバ１１２は、コンシステント・ハッシュ関数によりＴＣＰフローの一次フロー・トラッカ１１６Ａ及び／または二次フロー・トラッカ１１６Ｂを決定することができる。２０８で、一次フロー・トラッカ１１６Ａは、データを例えばハッシュ・テーブルに格納し、ＴＣＰ接続のサーバ・ノード１３０側の最初のＴＣＰシーケンス番号を生成し、二次フロー・トラッカ１１６Ｂにデータ及びＴＣＰシーケンス番号を転送する。２１０では、二次フロー・トラッカ１１６Ｂも、データを格納し、少なくともＴＣＰシーケンス番号を含むＳＹＮ／ＡＣＫパケットを作りクライアント１６０に送ることができる。
２１２で示されるように、入口サーバ１１２は、エッジ・ルータ１０４を介してクライアント１６０からＴＣＰ認識（ＡＣＫ）パケットを受け取る。入口サーバ１１２はこの時点でサーバ・ノード１３０へのＴＣＰフローのマッピングを有していない、それ故、２１４で、入口サーバ１１２は、ＡＣＫパケットから抽出されたデータを含むメッセージを一次フロー・トラッカ１１６Ａへ送信する。２１６で示されるように、メッセージを受け取ると、一次フロー・トラッカ１１６Ａは保存されたデータによってＴＣＰフローを確認し、かつＡＣＫパケットからの認識されたシーケンス番号（＋１）がＳＹＮ／ＡＣＫで送られた値と一致することを確認する。一次フロー・トラッカ１１６Ａは、その後、サーバ・ノード１３０を選択してＴＣＰフローを受け取り、データ、ＴＣＰシーケンス番号、及び選択されたサーバ・ノード１３０上のローカル・ロード・バランサ・モジュール１３２のＩＰアドレスを含むメッセージを二次フロー・トラッカ１１６Ｂに送る。２１８で示されるように、二次フロー・トラッカ１１６Ｂはまた、データ及びＴＣＰシーケンス番号を確認し、ＳＹＮメッセージを作製し、この作製したＳＹＮメッセージを選択されたサーバ・ノード１３０上のローカル・ロード・バランサ・モジュール１３２に送る。この手法は、図９Ｂの要素２２０で継続する。
図９Ｂの２２０で示されたように、ロード・バランサ・モジュール１３２は、作製されたＳＹＮメッセージに応答して、サーバ・ノード１３０の１つまたは複数の指標を検査してサーバ・ノード１３０が接続を受理できるかを判断することができる。２２２では、ロード・バランサ・モジュール１３２がサーバ・ノード１３０が現在接続を受理できないと判断するならば、ロード・バランサ・モジュール１３２は２２４で二次フロー・トラッカ１１６Ｂにメッセージを送る。二次フロー・トラッカ１１６Ｂは、以前に格納していたフローの情報を削除することができる。２２６では、二次フロー・トラッカ１１６Ｂが一次フロー・トラッカ１１６Ａにメッセージを送る。一次フロー・トラッカ１１６Ａは、その後、新たな標的サーバ・ノード１３０を選択し、図９Ａの２１６で示されるような二次フロー・トラッカ１１６Ｂにメッセージを送ることができる。
２２２で、ロード・バランサ・モジュール１３２が、サーバ・ノード１３０が接続を受理できると判断すると、図９Ｂの２２８に示されるように、ローカル・ロード・バランサ・モジュール１３２が作製されたＳＹＮからＴＣＰ・ＳＹＮパケットを構築し、このＴＣＰ・ＳＹＮパケットをサーバ・ノード１３０上のサーバ１３４に送る。ＴＣＰ・ＳＹＮパケットのソースＩＰアドレスは、サーバ１３４がクライアント１６０への直接のＴＣＰ接続を受け取ったと信じるようにクライアント１６０の実際のＩＰアドレスで占められている。ロード・バランサ・モジュール１３２は、ＴＣＰフローに関連する詳細を、例えば、ローカル・ハッシュ・テーブルに格納する。２３０で示されるように、サーバ１３４は、ロード・バランサ・モジュール１３２が傍受するＳＹＮ／ＡＣＫパケットに応答する。２３２に示されるように、ロード・バランサ・モジュール１３２は、その後、接続情報を含むメッセージを二次フロー・トラッカ１１６Ｂに送り接続が受理されたことを知らせる。このメッセージを受け取って、二次フロー・トラッカ１１６Ｂは、２３４で、サーバ１３４へのマッピングを記録し、やはりマッピング情報を記録する一次フロー・トラッカ１１６Ａに同様なメッセージを送る。２３６で示されるように、一次フロー・トラッカ１１６Ａは、その後、マッピング・メッセージを入口サーバ１１２へ転送する。入口サーバ１１２は、今や、クライアント１６０からサーバ１３０へのＴＣＰフローのマッピングを有している。
２３８で、入口サーバ１１２は、データ・フローのいかなるバッファされたデータ・パケットもカプセル化し、サーバ・ノード１３０上のローカル・ロード・バランサ・モジュール１３２に転送する。入口サーバ１１２が受け取ったクライアント１６０からのデータ・フローの追加の着信パケットは、カプセル化され、ロード・バランサ・モジュール１３２に直接転送される。ロード・バランサ・モジュール１３２は、このパケットをデカプセル化しサーバ１３４に送る。
２４０では、ロード・バランサ・モジュール１３２が、データ・フローの出口サーバ１１４を任意に選択する。サーバ１３４からの後続のアウトバウンドＴＣＰパケットは、ロード・バランサ・モジュール１３２によって傍受され、ＵＤＰによりカプセル化され、そして、任意に選択された出口サーバ１１４に転送される。出口サーバ１１４は発信パケットをデカプセル化し、ＴＣＰパケットをクライアント１６０に送る。
上で述べたように、２０２で、入口サーバ１１２が受信したパケットのＴＣＰフローのマッピングを有していないならば、このパケットはクライアント１６０からのＴＣＰ同期（ＳＹＮ）パケットであり得る。しかし、このパケットはＴＣＰ・ＳＹＮパケットとなることはできない。例えば、ロード・バランサ・ノード１１０のメンバー数が、ロード・バランサ・ノード１１０の追加または故障のせいで変化すると、エッジ・ルータ１０４は、１つまたは複数のＴＣＰフローのパケットをこのパケットのマッピングを有していない入口サーバ１１２に経路指定することを開始することができる。少なくともいくつかの実施形態では、入口サーバ１１２は、入口サーバ１１２がマッピングを有していないパケットを受け取ると、コンシステント・ハッシュ関数を用いてＴＣＰフローの一次フロー・トラッカ１１６Ａ及び／または二次フロー・トラッカ１１６Ｂをコンシステント・ハッシュ・リングにより決定し、一次フロー・トラッカ１１６Ａまたは二次フロー・トラッカ１１６Ｂのどちらかにメッセージを送りマッピングを要請することができる。フロー・トラッカ１１６からＴＣＰフローのマッピングを受け取ると、入口サーバ１１２はこのマッピングを格納し、ＴＣＰフローのＴＣＰパケットをカプセル化し正しい宛先サーバ・ノード１３０に転送することを開始することができる。
ロード・バランサ・ノードの詳細
少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０には各々３つの役割がある：
・入口−クライアント接続でのクライアント１６０からの着信パケットをすべて受け取り、マッピングが知られているならパケットをサーバ・ノード１３０に経路指定し、マッピングが知られていないならフロー・トラッカにメッセージを送ること。入口ノードからの発信パケットは、この入口ノードによりカプセル化される（例えば、ＵＤＰにより）。
・フロー・トラッキング−接続状況の追跡（例えば、どのサーバ・ノード１３０／サーバ１３４が各クライアント接続にサービスを提供するように割り当てられてきたのかの）を保つこと。フロー・トラッカはまた、クライアント１６０とサーバ１３４の間の接続を確立することに参加もする。
・出口−サーバー１３４から受け取ったアウトバウンド・パケットをデカプセル化しクライアント１６０に転送すること。
少なくともいくつかの実施形態では、入口の役割で、ロード・バランサ・ノード１１０はクライアント->サーバのマッピングが知られているときにパケットをサーバ１３４に転送する責任を負い、またはマッピングが知られていないときに要請をフロー・トラッカに転送する責任を負う。少なくともいくつかの実施形態では、特別なクライアント接続／データ・フローの入口ノードとして働く、ロード・バランサ・ノード１１０はまた、クライアント接続の一次フロー・トラッカまたは二次フロー・トラッカのどちらかの働きをすることもできるが両方の働きはできない。
少なくともいくつかの実施形態では、フロー・トラッカの役割において、ロード・バランサ・ノード１１０は、依然確立されている接続の状態を維持する責任ならびに確立された接続のクライアント->サーバのマッピングを維持する責任を負う。２つのフロー・トラッカは個々のクライアント接続にかかわり、一次フロー・トラッカ及び二次フロー・トラッカと呼ばれる。少なくともいくつかの実施形態では、クライアント接続に関連したフロー・トラッカをコンシステント・ハッシュ・アルゴリズムを用いて決定することができる。フロー・トラッカはまた、限定はされないが、新たなクライアント接続それぞれのサーバ・ノード１３０を擬似ランダムに選択することを含むロード・バランシング機能も果たす。選択されたサーバ・ノード１３０上のローカル・ロード・バランサ・モジュール１３２がサーバ１３４は接続を扱うことができないと判断するならば、このローカル・ロード・バランサ・モジュール１３２は接続要請を拒絶することができることに留意されたい。このことが起きたならばフロー・トラッカは別のサーバ・ノード１３０を選択しこの別のサーバ・ノード１３０に接続要請を送ることができる。少なくともいくつかの実施形態では、与えられた接続の一次フロー・トラッカの役割及び二次フロー・トラッカの役割は、異なるロード・バランサ・ノード１１０によって果たされる。
少なくともいくつかの実施形態では、出口の役割において、ロード・バランサ・ノード１１０はステートレスであり、サーバ・ノード１３０から受け取った着信パケットをデカプセル化し、いくつかの検証を行い、そして、アウトバウンドＴＣＰパケットをそれぞれのクライアント１６０に転送する。少なくともいくつかの実施形態では、サーバ・ノード１３０上のローカル・ロード・バランサ・モジュール１３２はある与えられた接続のロード・バランサ・ノード１１０を任意に選択することができる。
ロード・バランサ・ノード・コンシステント・ハッシュ・リングのトポロジ
少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０は、入力キー空間（クライアント終点、パブリック終点）のコンシステント・ハッシングに基づいてリング・トポロジを形成する。入力キー空間は利用可能なフロー・トラッカ・ノードの間で分割することができる。そして、すべてのフロー・トラッカ・ノードはそのキー空間に対応する質問に答える責任を持つことができる。少なくともいくつかの実施形態では、コンシステント・ハッシュ・リング（例えば、二次のフロー・トラッカ・ノードがサクセサ・ノード、またはコンシステント・ハッシュ・リング内の一次フロー・トラッカ・ノードに対するネクスト・ノード）内のサクセサに基づいて、データを一次及び二次のフロー・トラッカ・ノードに複製することができる。あるフロー・トラッカ・ノードがなんらかの理由で故障したならば、コンシステント・ハッシュ・リング内のネクスト・ロード・バランサー・ノードが故障したノードのキー空間を獲得する。新たなフロー・トラッカ・ノードが加わるときに、このノードは、他のロード・バランサ・ノードがロード・バランサ実装内の構成変化、したがって、コンシステント・ハッシュ・リング内の構成変化につき学習することができるように、自身の終点を登録する（例えば、図１に示すような構成サービス１２２により）。コンシステント・ハッシュ・リング内でのフロー・トラッカの追加及び故障の取り扱いは図１１Ａ〜図１１Ｄを参照してより詳細に論じる。
入口ノード<->フロー・トラッカ・ノードの通信
少なくともいくつかの実施形態では、入口ノードとして働くロード・バランサ・ノード１１０は、構成サービス１２２からのフロー・トラッカ・ノードとして働くロード・バランサ・ノード１１０につき学習することができる。入口ノードは、ロード・バランサ実装内の、したがってコンシステント・ハッシュ・リング内のメンバー数の変化につき構成サービス１２２をモニターすることができる。入口ノードがクライアント１６０からのパッケットを受け取りそのパケットに対するマッピングを有していないときに、この入口ノードはコンシステント・ハッシュ関数を用いてどのフロー・トラッカ・ノードがパケットにサービスすべきかを決定することができる。少なくともいくつかの実施形態では、ハッシュ関数への入力は、パケットからの（クライアント終点、パブリック終点の）ペアである。少なくともいくつかの実施形態では、入口ノードとフロー・トラッカ・ノードは、ＵＤＰメッセージを用いて通信する。
一次フロー・トラッカ・ノードが新たなパケット・フローの入口ノードからメッセージを受け取るとき、一次フロー・トラッカ・ノードはランダムにＴＣＰシーケンス番号を決定し、二次フロー・トラッカ・ノードへ別のメッセージを転送する。二次フロー・トラッカ・ノードは、クライアントに対するＴＣＰ・ＳＹＮ／ＡＣＫメッセージを生成する。両フロー・トラッカはクライアント接続終点ペアとＴＣＰシーケンス番号を思い出し、メモリ圧力及び期限切れによって状態が除去されるまで、この情報を保持する。
一次フロー・トラッカ・ノードがＴＣＰ・ＡＣＫパケットを受信した入口ノードからメッセージを受け取るときに、一次フロー・トラッカ・ノードは認識されたＴＣＰシーケンス番号がＳＹＮ／ＡＣＫパケット内に送られていた格納値と一致することを検証し、要請にサービスすべきサーバ・ノード１３０を選択し、そして、二次フロー・トラッカ・ノードへメッセージを転送する。二次フロー・トラッカ・ノードは、選択されたサーバ・ノード１３０上のロード・バランサ・モジュール１３２にメッセージを送って、サーバ・ノード１３０上のＴＣＰスタックとの実際のＴＣＰ接続を開始し、その後、サーバ・ノード１３０からの認識応答を待つ。
二次フロー・トラッカ・ノードが、サーバ・ノード１３０上のロード・バランサ・モジュール１３２から接続認識を受け取るときに、両ノードのサーバ・ノード１３０に関連する情報を格納した、一次フロー・トラッカを通じた入口ノードへの逆向きのメッセージ・フローが起きる。これ以降、入口ノードに受信された追加のＴＣＰパケットはサーバ・ノード１３０上のロード・バランサ・モジュール１３２に直接転送される。
ロード・バランサ・モジュール<->ロード・バランサ・ノードの通信
少なくともいくつかの実施形態では、すべてのロード・バランサ・モジュール１３２は、自身の終点を構成サービス１２２に登録し、ロード・バランサ・ノード層のメンバー数変化につき構成サービス１２２を絶えずモニターする。以下に、少なくともいくつかの実施形態によるロード・バランサ・モジュール１３２の機能につき説明する。
・接続公表：各サーバ・ノード１３０上のアクティブな接続（クライアント終点、パブリック終点）の組を、これらの接続に責任を負う一次及び二次の両フロー・トラッカ・ノード、ならびにこれらの接続に対するロード・バランサ・モジュール１３２のパケットを最後に送信した入口ノードに、定期的にまたは不定期に公表する。この接続公表機能は、責任のあるロード・バランサ・ノード１１０での接続状態のリースを更新する。
・ロード・バランサ層のメンバー数変化のモニター：メンバー数が変化したならば、ロード・バランサ・モジュール１３２は、この変化情報を用いて現在接続に責任を負っているロード・バランサ・ノードにアクティブな接続を直ちに送ることができる。
分散型ロード・バランシング・システム内のパケット・フロー：詳細
分散型ロード・バランシング・システムは多数のロード・バランサ・ノード１１０を含むことができる。少なくともいくつかの実施形態では、分散型ロード・バランシング・システム内の各ロード・バランサ・ノード１１０は、サーバ１３４へのクライアント１６０接続に対するフロー・トラッカ・ノード、出口ノード及び入口ノードの役割を果たすことができる。分散型ロード・バランシング・システムはまた、各サーバ・ノード１３０上にロード・バランサ・モジュール１３２を含むこともできる。
図１０Ａ〜１０Ｇは、少なくともいくつかの実施形態による、分散型ロード・バランシング・システム内のパケット・フローを示す。図１０Ａ〜１０Ｇでは、ロード・バランサ・ノード１１０間で交換されたパケット及びロード・バランサ・ノード１１０とサーバ・ノード１３０との間で交換されたパケットは、ＵＤＰメッセージまたはＵＤＰカプセル化クライアントＴＣＰパケットのどちらかである。少なくともいくつかの実施形態では、クライアントＴＣＰパケットは、境界ルータ１０２へのトランシット及び境界ルータ１０２からのトランシットにおいてロード・バランサ・ノード１１０の北側でネットワーク１００上にデカプセル化された形でのみ存在できる(図１参照)。図１０Ａ〜１０Ｇで実線矢印はＴＣＰパケットを表す一方、点線矢印はＵＤＰパケットを表すことに留意されたい。
少なくともいくつかの実施形態では、分散型ロード・バランシング・システムは、単一のロード・バランサ・ノード１１０が故障した際に、確立されている接続を保つように試みることができる。少なくともいくつかの実施形態では、一次フロー・トラッカ・ノードと二次フロー・トラッカ・ノードの接続詳細を複製して、これらのノードのどちらかが故障すれば、残りのフロー・トラッカ・ノードによって接続のクライアント->サーバのマッピングが回復できるようにすることで、これを実現することができる。少なくともいくつかの実施形態では、ノード故障の際にいくらかのパケット損失が生じ得るが、しかし、クライアント／サーバのＴＣＰパケット再送信によって失われたパケットを回復することができる。
クライアントからのＴＣＰ接続はそれぞれＴＣＰフローと呼ぶことができ、クライアントＩＰアドレス、クライアント・ポート、サーバ（パブリック）ＩＰアドレス及びサーバ・ポートから成る４要素の組により一意的に識別される。この識別子は、クライアント終点とパブリック終点のペアを示すＣＰまたはＣｃＰｐと短縮することができる。任意の与えられたＴＣＰフロー(またはＣＰペア)に関連するパケットは、上流のエッジ・ルータ１０４からのハッシュ化等コスト多重パス（ＥＣＭＰ）フロー分布のせいで、入口サーバ１１２として作動する任意のロード・バランサ・ノード１１０に現れることができる。しかし、ＴＣＰフローのパケットは一般的に、ＴＣＰフローの向きを変えるリンクまたはロード・バランサ・ノード１１０の故障がなければ、同じロード・バランサ・ノード１１０に到着し続けることができる。上流のルータ１０４からのＴＣＰフローのパケットを受信するロード・バランサ・ノード１１０は、ＴＣＰフローの入口ノードと呼ばれる。
少なくともいくつかの実施形態では、コンシステント・ハッシングを用いて、パケットがＴＣＰフローの入口ノードとして働くロード・バランサ・ノード１１０に到着するときにこの入口ノードがどのロード・バランサ・ノード１１０がＴＣＰフローの状態を含む（すなわち、フロー・トラッカ・ノードである）のかを判断することができるようにする。ＣＰペアを入口ノードによってコンシステント・ハッシュ・リング内にハッシングして、どのロード・バランサ・ノード１１０がＴＣＰフローに関する状態を維持する責任があるのかを判断することができる。このノードはＴＣＰフローの一次フロー・トラッカとして働く。コンシステント・ハッシュ・リング内のサクセサ・ノードはＴＣＰフローの二次フロー・トラッカとして働く。
少なくともいくつかの実施形態では、すべてのロード・バランサ・ノード１１０が入口ノード、一次フロー・トラッカ・ノード及び二次フロー・トラッカ・ノードの働きをすることができる。ＴＣＰフローのコンシステント・ハッシングの結果に応じて、ＴＣＰフローの入口ノードとして働くロード・バランサ・ノード１１０がＴＣＰフローの一次または二次のフロー・トラッカ・ノードとして働くこともできる。しかし、少なくともいくつかの実施形態では、異なる物理的なロード・バランサ・ノード１１０が、ＴＣＰフローの一次フロー・トラッカ及び二次フロー・トラッカの役割を果たす。
接続を確立させること
図１０Ａを参照すると、クライアント１６０からの新たな接続がクライアントＴＣＰ同期（ＳＹＮ）パケットによって引き起こされ得る。ロード・バランサ・ノード１１０はＳＹＮパケットを受信した際に、サーバ・ノード１３０との接続を実際に確立させない、また、これらは、サーバ・ノード１３０を直ちに選択して接続を受け取ることもしない。代わりに、ロード・バランサ・ノード１１０は、クライアントのＳＹＮパケットから関連データを格納し、まだ選択されていないサーバ・ノード１３０の代わりにＳＹＮ／ＡＣＫパケットを生成する。図１０Ｃを参照すると、一旦クライアント１６０がＴＣＰ３方向ハンドシェイク内の第一のＡＣＫパケットに応答すると、ロード・バランサ・ノード１１０はサーバ・ノード１３０を選択し、サーバ・ノード１３０の等価ＳＹＮパケットを生成し、サーバ・ノード１３０と実際のＴＣＰ接続を確立しようと試みる。
再度、図１０Ａを参照すると、ＴＣＰフローの入口サーバ１１２として働くロード・バランサ・ノード１１０でクライアントＳＹＮパケットを受信した際に、入口サーバ１１２はＳＹＮパケットからデータ・フィールドを抽出し、ＴＣＰフローの一次フロー・トラッカ１１６Ａにデータを転送する。一次フロー・トラッカ１１６Ａはデータを、例えば、ハッシュ・テーブルに格納し、最初のＴＣＰシーケンス番号（ＴＣＰ接続のサーバ側の）を生成し、同じデータを二次フロー・トラッカ１１６Ｂに転送する。二次フロー・トラッカ１１６Ｂは、クライアント１６０の、このサーバＴＣＰシーケンス番号を含むＳＹＮ／ＡＣＫパケットを作製する。
図１０Ａで、入口サーバ１１２、一次フロー・トラッカ１１６Ａ及び二次フロー・トラッカ１１６Ｂの役割がそれぞれ、異なるロード・バランサ・ノード１１０によって果たされる。しかし、いくつかの事例では、ＴＣＰフローの入口サーバ１１２として働くロード・バランサ・ノード１１０は、ＴＣＰフローの一次フロー・トラッカ１１６Ａまたは二次フロー・トラッカ１１６Ｂとして働く（しかし、両方ではない）のと同じノード１１０となることができる。パケット・フローの入口サーバ１１２がこのフローのフロー・トラッカ１１６と同じノード１１０上にあることができるのは、エッジ・ルータ１０４がフロー単位ハッシュ化多重パス経路指定技法（例えば、ＥＣＭＰ経路指定技法）によって擬似ランダムに入口サーバ１１２を選択し、一方で、パケット・フローのフロー・トラッカ１１６はパケット・フローのアドレス情報に適用されたコンシステント・ハッシュ関数によりコンシステント・ハッシュ・リング上に決定されるという理由からである。パケット・フローの入口サーバ１１２がパケット・フローのフロー・トラッカ１１６と同じノード１１０上にあるならば、ＳＹＮパケットからのデータを、入口サーバ１１２を実装するノード１１０から他のフロー・トラッカ１１６ノード１１０に転送するだけでよい。例えば、図１０Ｂでは、一次フロー・トラッカ１１６ＡがＴＣＰフローの入口サーバ１１２と同じロード・バランサ・ノード１１０Ａ上にある一方で、二次フロー・トラッカ１１６Ｂが異なるロード・バランサ・ノード１１０Ｂ上にあり、したがって、ＳＹＮパケットからのデータは、（フロー・トラッカ１１６Ａによって）ノード１１０Ａからロード・バランサ・ノード１１０Ｂ上の二次フロー・トラッカ１１６Ｂに転送される
図１０Ｃを参照すると、この入口サーバ１１２は、非ＳＹＮパケットが入口サーバ１１２に到着するときに、どのサーバ・ノード１３０にパケットを転送するのかを知っているか知らないのかのどちらかである。ＴＣＰフローの入口サーバ１１２に到着すべき第一の非ＳＹＮパケットは、ＴＣＰの３方向ハンドシェイク内の第一ＴＣＰ認識（ＡＣＫ）パケット（できるだけ後続のデータ・パケット）であるべきであり、このＴＣＰ認識番号フィールドは図１０ＡのＳＹＮ／ＡＣＫパケットに送られたサーバ・シーケンス番号（＋１）と一致する。入口サーバ１１２がそのサーバ・マッピングを持っていない非ＳＹＮパケットを受信するとき、入口サーバ１１２は、シーケンス番号などのＡＣＫパケットからの情報を含むか、またはその代わりにＡＣＫパケット自体を含んだメッセージをＴＣＰフローの一次フロー・トラッカ１１６Ａに転送する。少なくともいくつかの事例では、一次フロー・トラッカ１１６ＡはＴＣＰフローの保存されたデータを引き出し、認識されたシーケンス番号（＋１）がＳＹＮ／ＡＣＫパケット内のクライアント１６０に送られていた値と一致することを確認する。一次フロー・トラッカは、その後、ＴＣＰフローのサーバ・ノード１３０を選択し、以前に格納したＴＣＰフローのデータ、サーバ・シーケンス番号、及びその選択されたサーバ・ノード１３０上のロード・バランサ・モジュール１３２のＩＰアドレスを含む別のメッセージを二次フロー・トラッカ１１６Ｂに転送する。二次フロー・トラッカ１１６Ｂはサーバ・シーケンス番号を確認し、情報を記録し、作製されたＳＹＮメッセージを選択されたサーバ・ノード１３０上のロード・バランサ・モジュール１３２に送る。今や、ＴＣＰフローのＣＰ終点ペアが、ロード・バランサ・モジュール１３２／サーバ・ノード１３０にマッピングされる。サーバ・ノード１３０上のロード・バランサ・モジュール１３２は、作製されたＳＹＮメッセージを二次フロー・トラッカ１１６Ｂから受信するとき、サーバ・ノード１３０上のサーバ１３４の正当なＴＣＰ・ＳＹＮパケットを作製する責任を負う。ＳＹＮパケットを作製する際に、ソースＩＰアドレスは、サーバ１３４がクライアント１６０から直接のＴＣＰ接続要請を受け取ったと信じるように、クライアント１６０の実際のＩＰアドレスで占められる。ロード・バランサ・モジュール１３２は、ＴＣＰフローに関連する詳細を、例えば、ローカル・ハッシュ・テーブルに格納し、ＴＣＰ・ＳＹＮパケットをサーバ１３４に送信する（例えば、サーバ１３４のＬｉｎｕｘカーネルにＳＹＮパケットを注入する）。
図１０Ｃでは、入口サーバ１１２、一次フロー・トラッカ１１６Ａ及び二次フロー・トラッカ１１６Ｂの役割はそれぞれ、相異なるロード・バランサ・ノード１１０によって果たされる。しかし、いくつかの事例では、ＴＣＰフローの入口サーバ１１２として働くロード・バランサ・ノード１１０は、ＴＣＰフローの一次フロー・トラッカ１１６Ａまたは二次フロー・トラッカ１１６Ｂとして働く（しかし、両方ではない）同じノード１１０になるであろう。例えば、図１０Ｄでは、二次フロー・トラッカ１１６Ｂが、ＴＣＰフローの入口サーバ１１２と同じロード・バランサ・ノード１１０Ａ上にある一方で、一次フロー・トラッカ１１６Ａは異なるロード・バランサ・ノード１１０Ｂ上にある。
図を１０Ｅ参照すると、サーバ１３４（例えば、Ｌｉｎｕｘカーネル）は、ロード・バランサ・モジュール１３２にも傍受されるＳＹＮ／ＡＣＫパケットに応答する。このＳＹＮ／ＡＣＫパケットは、生成されたＳＹＮ／ＡＣＫ内のクライアント１６０に二次フロー・トラッカ１１６Ｂからもともと配られたものとは異なるＴＣＰシーケンス番号を含むことができる（図１０Ａ参照）。ロード・バランサ・モジュール１３２は、着信パケット及び発信パケットにシーケンス番号デルタを適用する責任を負う。サーバ１３４からのＳＹＮ／ＡＣＫパケットもまた、ロード・バランサ・モジュール１３２から二次フロー・トラッカ１１６Ｂに戻るメッセージ（例えば、ＵＤＰメッセージ）を発して選択されたサーバ・ノード１３０／ロード・バランサ・モジュール１３２／サーバ１３４への接続が成功したことを示す。このメッセージを受信した際に、二次フロー・トラッカ１１６Ａは、委託されたように、クライアント１６０とサーバ１３４間のクライアント終点及びパブリック終点ペア（ＣＰ）のマッピングを記録することができ、同様なメッセージをやはりＣＰマッピングを記録する一次フロー・トラッカ１１６Ａに送信する。一次フロー・トラッカ１１６Ａは、その後、ＣＰマッピング・メッセージを入口サーバ１１２に転送することができ、これは、入口サーバ１１２に、接続のいかなるバッファされたデータ・パケットもカプセル化データ・パケットとしてサーバ・ノード１３０上のローカル・ロード・バランサ・モジュール１３２へ転送させる。
図１０Ｆを参照すると、接続のＣＰマッピングは入口サーバに知られており、接続用の入口サーバ１１２が受信した着信ＴＣＰパケットは、カプセル化でき（例えば、ＵＤＰにより）、カプセル化データ・パケットとしてサーバ・ノード１３０上のローカル・ロード・バランサ・モジュール１３２に直接転送され得る。ロード・バランサ・モジュール１３２はデータ・パケットをデカプセル化し、例えば、カーネルのＴＣＰスタック上にＴＣＰパケットを注入することによって、サーバ・ノード１３０上のサーバ１３４にＴＣＰパケットを送信する。サーバ１３４からのアウトバウンド・パケットは、サーバ・ノード１３０上のロード・バランサ・モジュール１３２によって傍受され、カプセル化され（例えば、ＵＤＰにより）、そして、ロード・バランサ・モジュール１３２がこの接続の出口サーバ１１４としてランダムに選択した任意のロード・バランサ・ノード１１０に転送される。出口サーバ１１４はパケットをデカプセル化し、デカプセル化されたパケットをクライアント１１６に送信する。選択されたロード・バランサ・ノード１１０の出口機能はステートレスであり、それゆえ、出口サーバとして働くロード・バランサ・ノード１１０の故障の際に異なるロード・バランサ・ノード１１０を接続の出口サーバ１１４として選択することができる。しかし、一般的には、同じロード・バランサ・ノード１１０が接続の間の出口サーバ１１４として用いられて、アウトバウンド・パケットの再配列が縮小または除去される。
図１０Ｇを参照すると、少なくともいくつかの実施形態では、一次フロー・トラッカ１１６Ａによって選択されたサーバ・ノード１３０Ａの上のロード・バランサ・モジュール１３２Ａ（図１０Ｃ参照）は、自身が過負荷であると判断したならば、二次フロー・トラッカ１１６Ｂ（図１０Ｃ参照）から受け取った作製されたＳＹＮメッセージを拒絶する選択肢を有している。少なくともいくつかの実施形態では、作製されたＳＹＮメッセージは寿命（ＴＴＬ）値すなわち拒絶の最大数を考慮したカウンタを含む。少なくともいくつかの実施形態では、このＴＴＬ値がゼロになるならば、ロード・バランサ・モジュール１３２Ａは接続を受理するかまたは接続を止めて負荷を減らすかのどちらかを行うことができる。ロード・バランサ・モジュール１３２Ａが接続を拒絶することを決定するならば、それはＴＴＬ値を減少させ、二次フロー・トラッカ１１６Ｂに拒絶メッセージを送る。二次フロー・トラッカ１１６ＢはＣＰマッピングをリセットし、同じことをするために一次フロー・トラッカ１１６Ａに開放メッセージを送る。一次フロー・トラッカ１１６Ａは、別のサーバ・ノード１３０Ｂ上の新たなロード・バランサ・モジュール１３２Ｂを選び、そして、新たな標的メッセージを、新たに作製したＳＹＮメッセージを新たに選ばれたロード・バランサ・モジュール１３２Ｂに送る二次フロー・トラッカ１１６Ｂに送る。パケット停止の結果このシーケンス減衰が終了し得るが、しかし、クライアント１６０からの再送信によってロード・バランサ・モジュール選択プロセスを一次フロー・トラッカ１１６Ａで再度開始させることができ、この一次フロー・トラッカ１１６Ａは、必ずではないが、作製されたＳＹＮパケットの以前の拒絶を学習していないならば、接続に同じロード・バランサ・モジュール１３２を選択することができることに留意されたい。
少なくともいくつかの実施形態では、ＴＴＬカウンタを用いてサーバ・ノード１３０に連続的に接続要請を送ること（これは、例えば、サーバ・ノード１３０がすべて使用中ならば起こり得る）を防ぐことができる。少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２がそれぞれのサーバ・ノード１３０の代わりに接続要請を拒絶する度に、ロード・バランサ・モジュール１３２はＴＴＬカウンタを減少させる。フロー・トラッカ・ノード１１６は、ＴＴＬカウンタをモニターすることができ、また、ＴＴＬカウンタがゼロ（またはある指定された閾値を超える値）でない限り、別のサーバ・ノード１３０を選択して再度試みることができる。ＴＴＬカウンタがゼロ（または指定された閾値を超える値）になるならば、接続要請は停止され、フロー・トラッカ・ノード１１６はその接続のサーバ・ノード１３０のうちの選択された１つに更なる接続要請を試みない。少なくともいくつかの実施形態では、それぞれのクライアント１６０にエラー・メッセージを送ることができる。
少なくともいくつかの実施形態では、分散型ロード・バランサ・システムが多数のパブリックＩＰアドレスを支援する。これによって、クライアント１６０が同じクライアント・ポート番号から２つの異なるパブリックＩＰアドレスへの２つのＴＣＰ接続を開始することができる。これらのＴＣＰ接続は、クライアント１６０の視点とは異なるが、しかし、内部では、分散型ロード・バランサは、同じサーバ・ノード１３０への接続をマッピングする可能性があり、衝突に帰着するはずである。少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２は、図１０Ｃ、１０Ｄに示すように二次フロー・トラッカ１１６Ｂから作製されたＳＹＮパケットを受け取る際に、可能性のある衝突を検出し対処するためにアドレス情報を自身のアクティブな接続と比較して、接続が衝突を起こすようであれば、図１０Ｇに示すように接続要請を拒絶することができる。
ロード・バランサ・ノードの故障及び追加の取り扱い
多くの従来のロード・バランサでは、いくつかのまたはすべての既存の接続がロード・バランサの故障の際に失われる。少なくともいくつかの実施形態では、分散型ロード・バランシング・システムは、単一のロード・バランサ・ノード１１０の故障の際には、少なくとも確立している接続のうちのいくつかを維持して、接続を介して接続が正常に完了するまでクライアントとサーバがパケットを交換し続けることができるようにすることができる。加えて、この分散型ロード・バランシング・システムは、故障時に確立される過程にあった接続サービスを維持することができる。
分散型ロード・バランシング・システムの少なくともいくつかの実施形態では、単一のロード・バランサ・ノード１１０の故障の際に既存のクライアント接続を回復することができる故障回復プロトコルを実装することができる。しかし、多数のロード・バランサ・ノード１１０の故障はクライアント接続の喪失に帰着し得る。少なくともいくつかの実施形態では、クライアント１６０とサーバ１３４との間のＴＣＰ再送信をロード・バランサ・ノード１１０の故障に続く回復手段として使用することができる。
ロード・バランサ・ノード１１０の潜在的な故障に加えて、新たなロード・バランサ・ノード１１０が分散型ロード・バランサ・システムに加えられる場合がある。これらの新たなノード１１０は、ロード・バランサ層に、したがってコンシステント・ハッシュ・リングに加えられることができる。そして、既存のクライアント接続に関するロード・バランサ・ノード１１０の役割は、この変化により必要に応じて調整することができる。
少なくともいくつかの実施形態では、各接続が確立される（例えば、図１０Ａ〜１０Ｇ参照）につれて、接続状態情報が、ハッシュ関数入力として例えば、(クライアントＩＰ：ポート、パブリックＩＰ：ポート)の組を用いるコンシステント・ハッシュ・アルゴリズムを用いて決定され得る一次及び二次フロー・トラッカと呼ばれる２つのロード・バランサ・ノード１１０に通される。単一のロード・バランサ・ノード１１０の故障の際には、少なくとも１つの残存するロード・バランサ・ノード１１０が、コンシステント・ハッシュ関数を介してマッピングされ続け、パケットを選択された接続用サーバ・ノード１３０に向けるのに必要な接続状態情報を含むことができる。加えて、ロード・バランサ・ノード１１０をコンシステント・ハッシュ・リングに追加する事例では、接続状態情報を適切なフロー・トラッカに対してリフレッシュすることができる。
図１１Ａ〜１１Ｄは、少なくともいくつかの実施形態による、ロード・バランサ・ノードのコンシステント・ハッシュ・リング内のメンバー数に影響を及ぼす事象の取り扱いを示す。これらの事象には、限定はされないが、新たな一次フロー・トラッカ・ノードを追加すること、新たな二次フロー・トラッカ・ノードを追加すること、一次フロー・トラッカ・ノードの故障及び二次フロー・トラッカ・ノードの故障が含まれ得る。
図１１Ａは、コンシステント・ハッシュ・リングに新たな一次フロー・トラッカ・ノードを追加する取り扱いを示す。図１１Ａの上列は、１つまたは複数のクライアント接続の一次フロー・トラッカとしてのフロー・トラッカ１１６Ａ及び同じ接続の二次フロー・トラッカとしてのフロー・トラッカ・ノード１１６Ｂを示す。図１１Ａの下列では、新たなフロー・トラッカ・ノード１１６Ｃが追加され、クライアント接続の一次フロー・トラッカとなる。フロー・トラッカ・ノード１１６Ａ（以前は、一次フロー・トラッカ）が二次フロー・トラッカになる一方、フロー・トラッカ・ノード１１６Ｂ（以前は、二次フロー・トラッカ）がコンシステント・ハッシュ・リング内の次のフロー・トラッカになる。フロー・トラッカ１１６Ａ及び１１６Ｂが維持したクライアント接続の状態情報を新たな一次フロー・トラッカ１１６Ｃに提供することができる。加えて、フロー・トラッカ１１６Ｂは、二次フロー・トラッカの役割で以前に追跡していた接続を「忘れる」ことができる。
図１１Ｂは、コンシステント・ハッシュ・リングに新たな二次フロー・トラッカ・ノードを追加する取り扱いを示す。図１１Ｂの上列は、１つまたは複数のクライアント接続の一次フロー・トラッカとしてのフロー・トラッカ１１６Ａ及び同じ接続の二次フロー・トラッカとしてのフロー・トラッカ・ノード１１６Ｂを示す。図１１Ｂの下列では、新たなフロー・トラッカ・ノード１１６Ｃが追加され、クライアント接続の二次フロー・トラッカとなる。フロー・トラッカ・ノード１１６Ａは接続の一次フロー・トラッカとして残る一方、フロー・トラッカ・ノード１１６Ｂ（以前は、二次フロー・トラッカ）はコンシステント・ハッシュ・リング内の次のフロー・トラッカになる。フロー・トラッカ１１６Ａ及び１１６Ｂが維持したクライアント接続の状態情報を新たな二次フロー・トラッカ１１６Ｃに提供することができる。加えて、フロー・トラッカ１１６Ｂは、二次フロー・トラッカの役割で以前に追跡していた接続を「忘れる」ことができる。
図１１Ｃはコンシステント・ハッシュ・リング内の一次フロー・トラッカ・ノードの故障の取り扱いを示す。図１１Ｃの上列は、１つまたは複数のクライアント接続の一次フロー・トラッカとしてのフロー・トラッカ１１６Ａ、同じ接続の二次フロー・トラッカとしてのフロー・トラッカ・ノード１１６Ｂ及びコンシステント・ハッシュ・リング内の次のフロー・トラッカとしてのフロー・トラッカ・ノード１１６Ｃを示す。図１１Ｃの下列では、一次フロー・トラッカ・ノード１１６Ａが故障している。フロー・トラッカ・ノード１１６Ｂが接続の一次フロー・トラッカとなる一方、フロー・トラッカ・ノード１１６Ｃは接続の二次フロー・トラッカとなる。クライアント接続の状態情報はフロー・トラッカ１１６Ｂに維持され、新たな二次フロー・トラッカ１１６Ｃに提供され得る。
図１１Ｄはコンシステント・ハッシュ・リング内の二次フロー・トラッカ・ノードの故障の取り扱いを示す。図１１Ｄの上列は、１つまたは複数のクライアント接続の一次フロー・トラッカとしてのフロー・トラッカ１１６Ａ、同じ接続の二次フロー・トラッカとしてのフロー・トラッカ・ノード１１６Ｂ及びコンシステント・ハッシュ・リング内の次のフロー・トラッカとしてのフロー・トラッカ・ノード１１６Ｃを示す。図１１Ｄの下列では、二次フロー・トラッカ・ノード１１６Ｂが故障している。フロー・トラッカ・ノード１１６Ａは接続の一次フロー・トラッカとして残る一方、フロー・トラッカ・ノード１１６Ｃは接続の二次フロー・トラッカとなる。クライアント接続の状態情報はフロー・トラッカ１１６Ｂに維持され、新たな二次フロー・トラッカ１１６Ｃに提供され得る。
少なくともいくつかの実施形態では、サーバ・ノード１３０上のロード・バランサ・モジュール１３２は、ロード・バランサ・ノード１１０に接続公表を行なう。少なくともいくつかの実施形態では、接続公表は、定期的に（例えば、１秒に一回）または非定期にサーバ・ノード１３０からの現在の接続状態情報をフロー・トラッカ・ノード及び入口ノードとして働くロード・バランサ・ノード１１０に公表する。このことは、接続の一次と二次の両フロー・トラッカ・ノードに対する接続マッピングをリフレッシュまたは回復させる働きをする。少なくともいくつかの実施形態では、例えば、図１１Ａ〜１１Ｄに示すように、ロード・バランサ・モジュール１３２はフロー・トラッカのメンバー数変化を検出することができる。これを受けて、ロード・バランサ・モジュール１３２は、接続公表を行って一次及び二次のフロー・トラッカ・ノード内にメンバー数が変化したときに接続に対して変わったかもしれない接続状態情報を読み込むことができる。接続公表は、複数のロード・バランサ・ノードの故障の際に、少なくともいくつかの確立された接続を回復させることができることに留意されたい。
故障に関連したメッセージ・フロー
少なくともいくつかの実施形態では、一次及び二次のフロー・トラッカ・ノード間のプロトコルは、補正機能または同期機能を含むことができる。例えば、図１１Ａを参照すると、新たな一次フロー・トラッカ・ノード１１６Ｃがコンシステント・ハッシュ・リングに加わるときに、この新たなノード１１６Ｃはいくらかの数(約１／Ｎ)の接続のコンシステント・ハッシュのキー空間の権利を主張し、エッジ・ルータ１０４からこれらの接続に関するトラフィックの受け取りを開始することができる。しかし、新たな一次フロー・トラッカ・ノード１１６Ｃは、これらの接続に対して格納されたいかなる状態も有していないので、各パケット上でパケットがあたかもクライアント１６０から受け取られた最初のパケットであるかのように動作することができる。一次フロー・トラッカは、ＳＹＮパケット（例えば、図１０Ａ参照）に応じてサーバのＴＣＰシーケンス番号を生成し、かつ、クライアント１６０からの最初のＡＣＫパケット（例えば、図１参照）に応答してサーバ・ノード１３０を選択する責任を負う。これらの生成された値は、以前の一次フロー・トラッカ（図１１Ａのフロー・トラッカ・ノード１１６Ａ）によって選ばれた値と一致しない場合がある。しかし、少なくともいくつかの実施形態では、コンシステント・ハッシュ・アルゴリズムは前の一次フロー・トラッカ（図１１Ａのフロー・トラッカ・ノード１１６Ａ）に二次フロー・トラッカの役割を割り当て、このフロー・トラッカは以前格納していた接続状態を依然として保持している。したがって、少なくともいくつかの実施形態では、二次フロー・トラッカ（図１１Ａのフロー・トラッカ・ノード１１６Ａ）は、一次フロー・トラッカ１１６Ｃから受け取った情報に矛盾を検出したときに、一次フロー・トラッカ１１６Ｃに最新版メッセージを逆に送ってフロー・トラッカとして働く２つのロード・バランサ・ノード１１０を同期させることができる。コンシステント・ハッシュ・リングのメンバー数のその他の変化の後にも同様な方法を用いてフロー・トラッカを同期させることができる。
ロード・バランサ・モジュールの詳細
少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２は、サーバ・ノード１３０それぞれの上にある分散型ロード・バランサ・システムのコンポーネントである。ロード・バランサ・ノード１３２の役割には、限定はされないが、ロード・バランサ・ノード１１０から受信したパケットをデカプセル化し、デカプセル化されたパケットをサーバ・ノード１３０上のサーバ１３４に送ること、及び、サーバ１３４からの発信パケットをカプセル化し、カプセル化されたパケットをロード・バランサ・ノード１１０に送信することが含まれる。
少なくともいくつかの実施形態では、入口サーバ１１２として働くロード・バランサ・ノード１１０からサーバ・ノード１３０上のロード・バランサ・モジュール１３２への着信パケットは、実際のクライアント・データ・パケットをカプセル化するステートレス・プロトコル（例えば、ＵＤＰ）パケットである。各カプセル化クライアント・データ・パケットは、ソース・アドレスとしてそれぞれのクライアント１６０の元のクライアントＩＰポート及び宛先アドレスとしてサーバ１３４のパブリックＩＰポートを有する。ロード・バランサ・モジュール１３２はクライアント・データ・パケットからカプセルを剥ぎ、例えば、このパケットをローカルホストのＴＣＰフローに転送することによりサーバ・ノード１３０上のそれぞれのサーバ１３４にパケットを送信する。
少なくともいくつかの実施形態では、サーバ１３４から出口サーバ１１４として働くロード・バランサ・ノード１１０への発信パケットは、発信ＩＰパケットをカプセル化するステートレス・プロトコル（例えば、ＵＤＰ）パケットである。ロード・バランサ・モジュール１３２は発信ＩＰパケットをカプセル化し、ファブリック１２０を介してこのカプセル化パケットを出口サーバ１１４に送信する。各カプセル化発信ＩＰパケットは、ソース・アドレスとしてサーバ１３４のパブリックＩＰ：ポート及び宛先アドレスとしてそれぞれのクライアント１６０のクライアントＩＰ：ポートを有する。
ロード・バランサ・モジュールの機能
少なくともいくつかの実施形態では、サーバ・ノード１３０上のロード・バランサ・モジュール１３２の機能は、限定はされないが、以下のうちの１つまたは複数の機能を含むことができる。
・ロード・バランサ・ノード１１０からの、例えば、接続を扱う入口サーバ１１２からクライアント１６０までの、ＵＤＰトンネルを終了させること。これには、入口サーバ１１２から受信した着信クライアント・データ・パケットからＵＤＰカプセル化を剥ぐことが含まれる。
・接続の発信トラフィックを受信する出口サーバ１１４を選択すること。
・それぞれのサーバ１３４への接続上の発信ＩＰパケットを傍受し、接続の発信ＩＰパケットをカプセル化し、出口サーバ１１４にカプセル化されたパケットを送信すること。
・着信パケット及び発信パケット内のシーケンス番号をマングリングして、フロー・トラッカ・ノード１１６がＳＹＮ／ＡＣＫをクライアント１６０に送信したときにこのシーケンス番号がフロー・トラッカ・ノード１１６によって生成されるシーケンス番号とつながるようにすること。
・それぞれのサーバ１３４の接続を受け入れるか、または拒絶するかの決定を、例えば、それぞれのサーバ１３４の現在の負荷を示す１つまたは複数の指標に基づいて、行うこと。
・クライアントＩＰ：ポート・アドレスからそれぞれのサーバ１３４への接続を検出し、クライアントＩＰ：ポート・アドレスに対するアクティブな接続が存在するならば、衝突を回避するために同じクライアントＩＰ：ポート・アドレスからそれぞれのサーバ１３４への接続を拒絶すること。
・接続を追跡すること及び接続を公表すること。
ロード・バランサ・モジュール構成の情報
少なくともいくつかの実施形態では、各ロード・バランサ・モジュール１３２は、限定はされないが、その構造に対する以下の情報の組のうちの１つまたは複数の組を獲得し、ローカルに格納することができる。
一組のロード・バランサ・ノード１１０の終点
ロード・バランサ・モジュール１３２がサービスを提供する一組の有効なパブリックＩＰアドレス
それぞれのサーバ１３４が着信接続を受け入れるポート数
少なくともいくつかの実施形態では、この情報は、図１に示すような分散型ロード・バランサ・システムの構成サービス１２２コンポーネントにアクセスするか尋ねることにより、得られるか、更新することができる。いくつかの実施形態では、情報を得る他の方法を用いることもできる。
ロード・バランサ・モジュールのパケットの取り扱い
下記に、少なくともいくつかの実施形態による、インバウンド・トラフィック及びアウトバウンド・トラフィックに対するロード・バランサ・モジュール１３２の取り扱いにつき説明する。少なくともいくつかの実施形態では、インバウンド・データ・パケットがロード・バランサ・モジュール１３２によって受信されるとき、データ・パケットはＵＤＰパケットからデカプセル化され、デカプセル化されたＴＣＰパケット内の宛先アドレスが構成された１組の有効なパブリックＩＰアドレスにつき最初に確認される。一致しないならば、このパケットは除かれるかまたは無視される。少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２は、コンスタント・デルタによってＴＣＰヘッダ内のシーケンス番号を調整してこのシーケンス番号がＳＹＮ／ＡＣＫパケットをクライアント１６０に送ったフロー・トラッカ・ノード１１６によって生成されランダムに選ばれたシーケンス番号と一致するようにすることができる。ロード・バランサ・モジュール１３２は、〔クライアント：パブリック〕終点から〔クライアント：サーバ〕終点までのマッピングを内部状態として記録する。
少なくともいくつかの実施形態では、サーバ１３４からのアウトバウンドＴＣＰパケットに対して、ロード・バランサ・モジュール１３２は、先ず、その内部状態をチェックしてこのパケットがロード・バランサ・モジュールが管理しているアクティブな接続に対するものかどうかを判断する。もし、それがそうでなければ、ロード・バランサ・モジュール１３２はパケットを単に通過させる。もし、それがそうであるならば、ロード・バランサ・モジュール１３２は発信ＴＣＰパケットを例えばＵＤＰによってカプセル化し、カプセル化されたパケットをこの接続の出口サーバ１１４として選ばれたロード・バランサ・ノード１１０に転送する。少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３４は発信ＴＣＰパケット内のシーケンス番号をコンスタント・デルタによって調整してこのシーケンス番号がＳＹＮ／ＡＣＫパケットをクライアント１６０に送信したフロー・トラッカ・ノード１１６によって生成されたシーケンス番号とつながるようにすることができる。
接続の追跡
少なくともいくつかの実施形態では、各サーバ・ノード１３０上のロード・バランサ・モジュール１３２は、それぞれのサーバ１３４へのすべてのアクティブな接続の接続詳細を含むハッシュ・テーブルを管理する。少なくともいくつかの実施形態では、ハッシュ・テーブルのキーは（クライアントＩＰ：ポート、パブリックＩＰ：ポート）の組である。少なくともいくつかの実施形態では、各クライアント接続の接続状態は、限定はされないが、以下のうちの１つまたは複数のものを含むことができる。
・クライアントＩＰ：ポート
・パブリックＩＰ：ポート
・フロー・トラッカ・ノード１１６によって提供される最初のサーバＴＣＰシーケンス番号
・サーバＴＣＰシーケンス番号デルタ
・元の一次フロー・トラッカのＩＰアドレス
・元の二次フロー・トラッカのＩＰアドレス
・最後の検出された入口サーバ１１２のＩＰアドレス。
・このエントリーの認証有効時間
・最も長く使用されていない（ＬＲＵ）／衝突インデックス
少なくともいくつかの実施形態では、各ロード・バランサ・モジュール１３２は、すべてのアクティブなクライアント接続の一次及び二次のフロー・トラッカ・ノードへの接続公表メッセージを生成する。少なくともいくつかの実施形態では、Ｌｉｎｕｘカーネルが接続の追跡を止めるまで／ｐｒｏｃ／ｎｅｔ／ｔｃｐのコンテントがこれらの接続がフロー・トラッカ・ノードに公表され続けられるように、ロード・バランサ・モジュールのハッシュ・テーブルのアクティブな接続でスキャンされ傍受される。接続公表については、本明細書で後ほど詳細に論じる。
シーケンス番号のマングリング
以前に説明したように、少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０はサーバ１３４の代わりにクライアント１６０のＳＹＮパケットに応答してＳＹＮ／ＡＣＫパケットを生成する。クライアント１６０がＡＣＫパケット（ＴＣＰ３方向ハンドシェイク）を送信した後にだけ、ロード・バランサ・モジュール１１０は、サーバ・ノード１３０上のロード・バランサ・モジュール１３２に任意のデータを送る。クライアント接続を確立するように最初に指示されたときに、ロード・バランサ・モジュール１３２はＳＹＮパケットをローカルに作製してサーバ・ノード１３０上のサーバ１３４とＴＣＰ接続を開始し、サーバ１３４の対応するＳＹＮ／ＡＣＫパケットを傍受する。一般的に、サーバ１３４（例えば、サーバ・ノード１３０上のＬｉｎｕｘカーネル）は、クライアントがＳＹＮ／ＡＣＫパケット内でロード・バランサ・ノード１１０から受け取ったものとは完全に異なるＴＣＰシーケンス番号を選択する。したがって、少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２は、クライアント１６０とサーバ１３４との間のＴＣＰ接続でのすべてのパケット内のシーケンス番号を訂正することができる。少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２は、ロード・バランサ・ノード１１０によって生成されたシーケンス番号と、サーバ１３４によって生成されたシーケンス番号間の差を計算し、この差をデルタ値としてＴＣＰ接続のハッシュ・テーブルのエントリに格納する。接続中のクライアント１６０から着信データ・パケットが到着するとき、ＴＣＰヘッダはサーバ１３４によって使用されるシーケンス番号とつながらない認識番号を含むであろう。したがって、ロード・バランサ・モジュール１３２はＴＣＰヘッダ内のシーケンス番号値からデルタ値（例えば、２の補数を使用して）を差し引く。ロード・バランサ・モジュールは、また、接続中のサーバ１３４からクライアント１３０までのアウトバウンド・パケット内のシーケンス番号へのデルタ値の加算もおこなう。
分散型ロード・バランサ・システムにおける健全性のチェック
分散型ロード・バランサ・システムの少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０には、少なくとも以下の理由により、ロード・バランサ実装時に健全なメンバー（すなわち、健全なロード・バランサ・ノード１１０及びサーバ・ノード１３０）のコンシスタントな視野を必要とする。
・ロード・バランシング：ロード・バランサ・ノード１１０は、サーバ・ノード１３０の故障を検出し、クライアント・トラフィックを受信することができる健全なサーバ・ノード１３０の組に集まる必要がある。
・分散状態の管理：ロード・バランサは、複数のロード・バランサ・ノード１１０にわたって状態が共有／複製されている分散型システム（例えば、コンシステント・ハッシング・メカニズムによる）である。クライアント・トラフィックを適切に取り扱うために、各ロード・バランサ・ノード１１０は、ロード・バランサ実装時に健全なメンバー・ノード１１０の最終的にコンシスタントな視野を有する必要がある。
これを達成するために、分散ロード・バランサ・システムの少なくともいくつかの実施形態では、ロード・バランサ実装時のノードをモニターし、できるだけ早く健全でないノードを検出する健全性チェック・プロトコルの実施形態を実装することができる。健全性チェック・プロトコルは、ロード・バランサ実装時のノード間で健全性情報を伝達することができ、また、ノードが一組の健全なノードに集まることができるようにする方法を提供することができる。加えて、健全性チェック・プロトコルは、ロード・バランサ実装時の健全／非健全なノード及び状態変化を報告するメカニズムを提供することができる。
少なくともいくつかの実施形態では、健全性チェック・プロトコルは、次の仮定の１つ以上に基づくことができるが、これに限定されない。
・ロード・バランサ実装時のすべてのノードが知られている。（すなわち、健全性チェック・プロトコルは、発見をすることができない）
・すべてのノード故障は、フェイル・ストップである。
・ノード間のすべてのメッセージはステートレス・プロトコル（例えば、ＵＤＰ）メッセージであり、メッセージは脱落、遅延、重複、または破損する場合がある。メッセージの送達が保証されない。
少なくともいくつかの実施形態では、ロード・バランサ実装時のノード（例えば、ロード・バランサ・ノード１１０またはサーバ・ノード１３０）を、次の条件に基づいて健全であるとみなすことができる。
・ノードの全ての内部コンポーネントが、レディ状態（クライアント・トラフィックを処理する準備ができている）である。
・ノードの着信／送信ネットワーク・リンクが健全である（少なくともクライアント・トラフィックが流れるネットワーク・インターフェイス・コントローラ（ＮＩＣ）に対して)。
図１２は、少なくともいくつかの実施形態による、各ロード・バランサ・ノードが健全性チェックのインターバルにより行うことができる健全性チェック法の高レベルのフローチャートである。１０００に示すように、例えば１００ミリ秒ごとの各ロード・バランサのインターバルにおいて、各ロード・バランサ（ＬＢ）ノード１１０は、少なくとも他の１つのＬＢノード１１０及び少なくとも１つのサーバ・ノード１３０の健全性をチェックすることができる。１００２に示すように、ロード・バランサ・ノード１１０は、健全性チェックより、ローカルに格納された健全性情報を更新することができる。１００４に示すように、ロード・バランサ・ノード１１０は、さらに、少なくとも他の１つのロード・バランサ・ノード１１０をランダムに選択することができ、その健全性情報を選択したロード・バランサ・ノード１１０に送信することができる。少なくともいくつかの実施形態では、ノード１１０は、健全なロード・バランサ・ノード１１０のリストを、１つまたは複数のサーバ・ノード１３０、例えば、ノード１１０が健全性をチェックした同一のサーバ・ノード１３０に送信することもできる。図１２の各要素については、次の論議で更に詳細に説明する。
少なくともいくつかの健全性チェック・プロトコルの実施形態では、ロード・バランサ・ノード１１０は、それ自身の健全性を、他のロード・バランサ・ノード１１０に表明しない。代わりに、他の１つまたは複数のロード・バランサ・ノード１１０が、このノード１１０の健全性をチェックすることができる。例えば、少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０は、健全性チェックのために他の１つまたは複数のノード１１０を定期的にまたは非定期にランダムに選択することができる。別の例として、少なくともいくつかの実施形態では、他の１つまたは複数のロード・バランサ・ノード１１０、例えば、コンシステント・ハッシュ・リングなどの整列したノード１１０のリスト上にある所定のロード・バランサ・ノード１１０の最近接の２つのロード・バランサ・ノード１１０は、それぞれ、その所定のノード１１０の健全性を定期的にまたは非定期にチェックすることができる。少なくともいくつかの実施形態では、ノード１１０の健全性チェックは、図２３に図示するノード１１０上のＮＩＣ１１１４に送信する健全性についてのピングを用いることを含むことができる。少なくともいくつかの実施形態において、第１のノード１１０は、健全性チェックによって第２のノード１１０を健全であると決定する場合、ロード・バランサ・ノード１１０のローカルな健全性情報の中に蓄積する第２のノード１１０の鼓動カウンタを更新する（例えば、増加させる）ことができる。第１のノード１１０は、自身のローカルな健全性情報を、ロード・バランサ実装中の他の１つ以上のロード・バランサ・ノード１１０に、定期的にまたは非定期に送信する。これらのロード・バランサ・ノード１１０は、その情報に応じて、自身のローカルな健全性情報を（例えば、第２のノードの鼓動カウンタを増加させることによって）更新することができる。また、その更新したローカルな健全性情報を他の１つまたは複数のノード１１０に送信することができる。第２のノード１１０の鼓動情報を、ロード・バランサ実装時の他のノード１１０にこのように伝達することができる。第２のノード１１０が健全な限り、第２のノード１１０から到達可能な他のすべてのノード１１０は、このように、例えば１秒につき１回または１０秒ごとに１回の一貫した基調に基づいて増加される第２のノード１１０の鼓動カウンタを見るべきである。第２のノード１１０の健全性をチェックするノード１１０が、第２のノード１１０を非健全であると検出する場合、健全性をチェックするノード１１０は、第２のノード１１０の鼓動を送信しない。さらに、ある時間の限度を超えた後に、ロード・バランサ実装時の他のノード１１０は、問題のノード１１０を非健全、または故障しているとみなす。
少なくともいくつかの実施形態において、ロード・バランサ・ノード１１０は、自身の内部状態の１つまたは複数の側面をチェックすることができる。また、そのノード１１０が何らかの理由で非健全であることを、自身が検出する場合、そのノード１１０は、その健全性をチェックする他のノード１１０からの健全性についてのピングに応答することを止めることができる。したがって、非健全なノード１１０の健全性をチェックするノード１１０は、このノード１１０を非健全であるとみなすことができるので、このノード１１０の代わりに鼓動の増加を伝達することができない。
健全性チェック・プロトコルの詳細
少なくともいくつかの実施形態において、健全性チェック・プロトコルには、鼓動カウンタ技法及びゴシップ・プロトコル技術を活用することができる。この健全性チェック・プロトコルは、２つの主要部分：健全性のチェック、及びゴシップ／故障の検出、を有するとみなすことができる。
健全性のチェック：ロード・バランサ実装時のすべてのロード・バランサ・ノード１１０は、定期的にまたは非定期に、実装された他の１つまたは複数のノード１１０の健全性をチェックすることができる。他の１つ以上のノードを決定する方法は、後で述べる。健全性のチェックの中核となる考え方は、あるノード１１０が、別のノード１１０の健全性をチェックして、その別のノード１１０が健全であると判断するならば、チェックを行うノード１１０が、その別ノード１１０の鼓動カウンタを増加させ、伝達することによって、その別のノード１１０が健全であると、主張することである。換言すれば、このノード１１０は、他のノードに対して自身の健全性を主張しない。代わりに、他の１つまたは複数のノード１１０が、ロード・バランサ実装時の各ノード１１０の健全性をチェックし、主張する。
ゴシップ／故障検出：少なくともいくつかの実施形態では、健全性チェック・プロトコルには、ロード・バランサ実装時に、そのメンバーであるロード・バランサ・ノード１１０の間にロード・バランサ・ノード１１０の健全性情報を伝達するために、ゴシップ・プロトコルを活用することができる。このゴシップ・プロトコルは、急速に集まって、分散型ロード・バランシング・システムのために充分となる、最終的一貫性に対する保証を提供する。少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０は、ゴシップ・プロトコルを用いて、ロード・バランサ実装時の他の各ノード１１０の鼓動カウンタを、例えば、鼓動リスト内に保持する。各ロード・バランサ・ノード１１０は、上記の少なくとも他の１つのロード・バランサ・ノード１１０の健全性チェックを定期的にまたは非定期に行い、チェックされたノード１１０が健全であることを健全性チェックを経て決定すると直ちに、ノード１１０の鼓動カウンタを増加させる。少なくともいくつかの実施形態において、各ロード・バランサ・ノード１１０は、その時点の鼓動リストを送る、ロード・バランサ実装時の他の少なくとも１つのノード１１０を、定期的にまたは非定期にランダムに選択する。別のノード１１０からの鼓動リストを受信すると直ちに、ロード・バランサ・ノード１１０は、この２種類のリスト（受信したリスト及び自身のリスト）のノード１１０ごとに最大の鼓動カウンタを決定し、決定した最大の鼓動カウンタを自身の鼓動リストに用いることによって、受信したリストの鼓動情報を自身の鼓動リストと組み合わせる。今度は、この鼓動リストが別のランダムに選択されたノード１１０に送信され、それに応じて、そのノード１１０が自身の鼓動リストを更新する。以下同様に行われる。この技法を用いて、個々の健全なノード１１０の鼓動情報は、やがて（例えば、数秒で）、ロード・バランサ実装時の他の全てのロード・バランサ・ノード１１０に伝達される。所定のロード・バランサ・ノード１１０について、鼓動カウンタが増加し続ける限り、そのノード１１０は、他のノード１１０から健全であるとみなされる。ロード・バランサ・ノード１１０の鼓動カウンタが、指定された時間、健全性チェック及びゴシップの方法で増加しないならば、他のロード・バランサ・ノード１１０は、非健全であるとみなされたロード・バランサ・ノード１１０に集中することができる。
ロード・バランサ・ノードの健全性チェック
以下は、少なくともいくつかの実施形態による、ロード・バランサ・ノード１１０が実施することのできる、別のロード・バランサ・ノード１１０の健全性をチェックする方法を述べている。図２３を参照すると、少なくともいくつかの実施形態では、以下の条件のうち一つまたは複数のものがロード・バランサ・ノード１１０で確認されるならば、そのノード１１０を健全であるとみなすことができる。
・ノード１１０のプロセッサ・スレッド（例えば、コア・パケット処理コード１１０８のスレッド）がレディ状態（内部）である。
・ノード１１０が、エッジ・ルータ１０４のＩＰアドレス及び／またはＭＡＣアドレス（内部）を認知している。
・ノード１１０の全てのスレッド及び／またはプロトコル・ハンドラがレディ状態（内部）である。
・北側（エッジルータ１０４／境界ネットワーク）及び南側（サーバ１３０／生産ネットワーク）からの着信リンク及び発信リンクがアクティブ（外部）である。
・ノード１１０は、ロード・バランサ実装時に用いられるネットワーク・インターフェイス・コントローラ（ＮＩＣ）を介して、パケットを受信し、発信することができる。例えば、図２３に示すロード・バランサ・ノード１１０の実施形態の例において、このノード１１０は、北向きのＮＩＣ１１１４Ａ及び南向きのＮＩＣ１１１４Ｂを介してパケットを受信すること及び発信することに成功するはずである。
これらの健全性の条件のうち１つまたは複数のものが所定のノード１１０にあてはまらないならば、そのノード１１０は健全でないとみなすことができる。なお、いくつかの実施形態では、上記の条件の全てがノード１１０にあてはまるならば、ノード１１０は必ず健全であるとみなされることに留意されたい。
少なくともいくつかの実施形態では、上記の健全性についての条件に加えて、例えばコントロール・プレーンの通信のために用いることができる、ＮＩＣ１１１４Ｃとして図２３に示す、各ロード・バランサ・ノード１１０上の第３のＮＩＣも、このＮＩＣに対してパケットを送信し、そこからパケットを受信することによって、健全性をチェックするノード１１０でチェックすることもできる。この第３のＮＩＣのチェックが失敗するならば、チェックを受けているノード１１０は健全ではないとみなすことができる。
図１３は、少なくともいくつかの実施形態による、ロード・バランサ・ノードの健全性を、別のロード・バランサ・ノードからチェックする方法の例を示している。この例では、ロード・バランサ・ノード１１０Ａが、ロード・バランサ・ノード１１０Ｂの健全性をチェックしている。各ノード１１０Ａ及び１１０Ｂは、北向きのＮＩＣ（図２３のＮＩＣ１１１４Ａ）、及び南向きのＮＩＣ（図２３のＮＩＣ１１１４Ｂ）を有する。１で、ノード１１０Ａがエッジ・ルータ１０４を介して北向きのＮＩＣからノード１１０Ｂの北向きのＮＩＣまでパケット（例えば、ピングパケット）を送信する。ノード１１０Ｂが、その北向きのＮＩＣにパケットを受信し、上記リストに示した条件が満たされるとすると、２で、ファブリック１２０を介してその北向きのＮＩＣからノード１１０Ａの北向きのＮＩＣに応答を送信する。ノード１１０Ａが、その北向きのＮＩＣでこの応答を受信した後に、３で、ファブリック１２０を介してその南向きのＮＩＣからノード１１０Ｂの南向きのＮＩＣまでパケット（例えば、ピングパケット）を送信する。ノード１１０Ｂが、その南向きのＮＩＣでパケットを受信し、上記リストに示した条件が満たされるなら、４で、エッジ・ルータ１０４を介してその南向きのＮＩＣからノード１１０Ａの南向きのＮＩＣに応答を送信する。ノード１１０Ａは、その南向きのＮＩＣでこの応答を受信すると直ちに、ノード１１０Ｂが健全であるとみなし、ノード１１０Ｂのローカルな鼓動カウンタを増加させる。その後、このことを、以前に説明したようなゴシップ・プロトコルにより他のノード１１０にさらに伝達することができる。
上記に代わるものとして、いくつかの実施形態では、ロード・バランサ・ノード１１０Ｂは、その北向きのＮＩＣで受信した最初のピング・メッセージに対して、その南向きのＮＩＣを介してノード１１０Ａの南向きのＮＩＣへと応答することができ、その南向きのＮＩＣで受信した２つ目のピング・メッセージに対して、その北向きのＮＩＣを介してノード１１０Ａの北向きのＮＩＣへと応答することができる。
加えて、いくつかの実施形態では、ノード１１０Ａは、自身の第３のＮＩＣからノード１１０Ｂの第３のＮＩＣのネットワーク接続を確認すること、及び、ノード１１０Ｂが健全であるならば、ノード１１０Ｂの第３のＮＩＣから自身の第３のＮＩＣにピング・メッセージへの応答を受信することによって、コントロール・プレーンの通信に用いるノード１１０Ｂの第３のＮＩＣ（図２３にＮＩＣ１１１４Ｃとして示す）の健全性をチェックすることもできる。ピング・メッセージ及びその応答は、１つまたは複数のコントロール・プレーン・デバイス１７０、例えば、ネットワークスイッチを通過することができる。
上記の健全性チェック・メカニズムは、全方向（北、南、及びコントロール・プレーン通過）へのノード１１０Ｂの全ての着信リンクと発信リンク及びデータ経路、並びにノード１１０Ｂの全てのＮＩＣを動作させる。また、同メカニズムは、ピング・パケットが、クライアント・パケットと同様にノード１１０Ｂの内部キュー及びディスパッチングを通り抜けるとき、ノード１１０Ｂの内部の健全性を確かめる。
ロード・バランサ・ノードへの健全性チェックの責任の割り当て
少なくともいくつかの実施形態では、ロード・バランサ実装時の各ロード・バランサ・ノード１１０は、ロード・バランサ実装時に他の全てのロード・バランサ・ノード１１０のリスト（例えば、整列リスト）に、例えばコンフィギュレーション機能によって、及び／または、図１に示すコンフィギュレーション・サービス１２２のコンポーネントによってアクセスする。少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０は、このリスト上の他の１つまたは複数のノード１１０をランダムに選択し、健全性チェック・インターバルごとに健全性をチェックし、健全である判断した場合、その鼓動カウンタを増加させることができる。なお、このリストは、その時点で健全性チェック機構が健全、または非健全のいずれとみなすかにかかわらず、ロード・バランサ実装時のすべてのロード・バランサ・ノード１１０を含む。そして、その時点で非健全なノード１１０をこのリストからランダムに選択し、健全なノード１１０と同様に健全性をチェックすることができる。したがって、ノード１１０の健全性をチェックする１つまたは複数のノード１１０は、その時点で非健全なノード１１０を健全であると判断することができ、その鼓動カウンタを増加させ、他のノード１１０に伝達することができ、したがって、非健全なノード１１０を、健全なステータスに戻すことができる。
あるいはこの代わりに、いくつかの実施形態では、各ロード・バランサ・ノード１１０は、このリスト中の他の１つまたは複数のノード１１０の健全性をチェックし、健全であると判断した場合、その鼓動カウンタを増加させることに対して責任を負うことができる。例えば、いくつかの実施形態では、各ノード１１０は、他の２つのノード、例えば、このリスト中にある「左」（または、前）及び「右」（または、次）の最近接のノード１１０に対して責任を負うことができる。なお、このリストは円形であるとみなすことができ、このリストの「最後」のノード１１０はこのリストの「最初」のノード１１０の健全性のチェックに責任を負うことができる。逆もまた同じ。いくつかの実施形態では、他の２つのノード１１０を、例えばこのリスト上の次にある最近接の２つとして、別途選択することができる。いくつかの実施形態では、各ノード１１０は、このリスト上の他の２つ以上のノード１１０、例えば、他の３つまたは４つのノード１１０の健全性チェックについての責任を負うことができる。少なくともいくつかの実施形態では、ノード１１０がチェックする隣接のノード１１０を非健全であると判断するならば、このノード１１０は、この非健全な隣接ノード１１０がチェックする義務を負っていたリスト上の少なくとも１つのノードの健全性をチェックする責任を負うことができる。少なくともいくつかの実施形態では、その隣接ノード１１０（例えば、「左」及び「右」の近傍ノード）の健全性をチェックすることに加えて、各ロード・バランサ・ノード１１０は、また、定期的にまたは非定期にリングの中のノード１１０をランダムに選択することができ、そのランダムに選択したノード１１０の健全性をチェックすることができ、健全であれば、このランダムなノード１１０の鼓動を増加させ、伝達することができる。少なくともいくつかの実施形態では、この順序リストの他の全てのノード１１０を、それが以前健全であるとみなされたかどうかに関わらず、ランダム抽出及び健全性チェックの対象として考慮する。
少なくともいくつかの実施形態では、各ノード１１０は、ランダムに選択した１つまたは複数のノード１１０、または、代替的に、隣接ノード１１０及びランダムに選択したノードの健全性チェックを、健全性チェック・インターバルと呼ぶことができる通常の間隔で行う。例えば、いくつかの実施形態では、鼓動インターバルは１００ミリ秒であってもよいが、より短いか、またはより長いインターバルを用いることもできる。加えて、少なくともいくつかの実施形態では、各ノード１１０は、その時点の鼓動リストを少なくとも１つのランダムに選択した他のノード１１０に、ゴシップ・インターバルと呼ぶことができる通常のインターバルで送信、または「うわさを広める」。いくつかの実施形態では、健全性チェック・インターバル及びゴシップ・インターバルは同じであってもよいが、必ずしも同じではない。
図１４は、少なくともいくつかの実施形態による、他の１つまたは複数のロード・バランサ・ノードの健全性をチェックするロード・バランサ・ノードを視覚的に示している。この例では、ロード・バランサ実装時に８つのロード・バランサ・ノード１１０Ａ〜１１０Ｈがある。ドットの円は、実装されたすべてのノード１１０の順序リストを表現している。いくつかの実施形態では、各ノード１１０は、各インターバルで健全性をチェックするために、リスト上の１つまたは複数の他のノード１１０をランダムに選択することができる。選択肢の１つとして、いくつかの実施形態では、各ロード・バランサ・ノード１１０は、順序リスト上の１つまたは複数の特定のノード１１０をチェックする責任を負うことができる。例えば、ノード１１０Ａは、図１４に示す、順序リストに従った、ノード１１０Ａの最隣接の２つのノード１１０Ｂ及び１１０Ｈの健全性をチェックする責任を負うことができる。加えて、ロード・バランサ・ノードは、個々の健全性チェック・インターバルで順序リストから別のノード１１０をランダムに選択することもできる。この例に示すように、ノード１１０Ａは、健全性をチェックするノード１１０Ｆもランダムに選択している。ゴシップ・インターバルで、ノード１１０Ａは、ある他の健全なノード１１０、例えばノード１１０Ｄをランダムに選択して、その時点の鼓動リストを選択した他のノード１１０に、例えば、ＵＤＰメッセージで送信する。ノード１１０は、別のノード１１０から鼓動リストを受信すると直ちに、それに応じて自身の鼓動リストを更新し、この鼓動リストを、ランダムに選択した１つまたは複数のノード１１０に、次のゴシップ・インターバルで伝達することができる。
サーバ・ノードの健全性のチェック
ロード・バランサ・ノード１１０の健全性を、上述したようにチェックすることに加えて、この健全性チェック・プロトコルの実施形態は、サーバ・ノード１３０上のロード・バランサ・モジュール１３２及びサーバ１３４を含むサーバ・ノード１３０の健全性をチェックすることができる。少なくともいくつかの実施形態では、以下の条件の一方または両方がサーバ・ノード１３０に確認される場合、サーバ・ノード１３０を健全であるとみなすことができる：
・ロード・バランサ・モジュール１３２が健全である。
・サーバ・ノード１３０が健全性ピング（例えば、Ｌ７健全性ピング）への応答に成功する。
図１５は、少なくともいくつかの実施形態による、サーバ・ノードの健全性をチェックするロード・バランサ・ノードを示している。少なくともいくつかの実施形態では、ロード・バランサ実装時の各ロード・バランサ・ノード１１０は、ロード・バランサ実装時の他の全てのロード・バランサ・ノード１１０のリスト、及び、ロード・バランサ実装時の全てのサーバ・ノード１３０のリストにアクセスする。リストは、例えば、コンフィギュレーション機能によって、及び／または、図１に示すコンフィギュレーション・サービス１２２のコンポーネントによって取得及び更新することができる。少なくともいくつかの実施形態では、サーバ・ノード１３０を、図１５に示したコンシステント・ハッシュ・リングを形成する健全なロード・バランサ・ノード１１０に対してコンシステント・ハッシュすることができる。少なくともいくつかの実施形態では、このリングの中の各サーバ・ノード１３０の健全性を、このリングの中の２つの健全なロード・バランサ・ノード１１０でチェックする。例えば、図１５において、サーバ・ノード１３０Ａの健全性を、ロード・バランサ・ノード１１０Ａ及び１１０Ｃによってチェックする。この２つのノード１１０を、コンシステント・ハッシュ・リングの中のサーバ・ノード１３０に対する第１（ノード１１０Ａ）及び第２（ノード１１０Ｂ）の健全性チェック・ノード１１０と呼ぶことができる。なお、所定の健全なロード・バランサ・ノード１１０は、１つまたは複数のサーバ・ノード１３０の健全性をチェックすることができる。例えば、図１５において、ロード・バランサ・ノード１１０Ａは、サーバ・ノード１３０Ｂ及び１３０Ｃの健全性もチェックする。加えて、所定のロード・バランサ・ノード１１０は、１つまたは複数のサーバ・ノード１３０の第１の健全性チェック・ノード、及び１つまたは複数の他のサーバ・ノード１３０の第２の健全性チェック・ノードとなることができる。例えば、図１５において、ロード・バランサ・ノード１１０Ａは、サーバ・ノード１３０Ａ及び１３０Ｂの第１の健全性チェッカ・ノードであり、サーバ・ノード１３０Ｃ及び１３０Ｄの第２の健全性チェッカ・ノードである。
少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０が故障している場合、コンシステント・ハッシュ・リングの帰属関係が変化し、なお健全で、したがって、なおコンシステント・ハッシュ・リングに留まる、他の１つまたは複数のロード・バランサ・ノード１１０が、故障しているノード１１０が以前健全性をチェックしていたサーバ・ノード１３０の健全性チェックに対する責任を負うことができる。
少なくともいくつかの実施形態では、各健全なノード１１０は、割り当てられたサーバ・ノード１３０の健全性チェックを、通常のインターバルで行う。このインターバルを、サーバ・チェック・インターバルと呼ぶことができる。少なくともいくつかの実施形態では、サーバ・チェック・インターバルは、前述したゴシップ・インターバルより長いかまたは同じでよい。
少なくともいくつかの実施形態では、サーバ・ノード１３０の健全性チェックを行うために、健全なロード・バランサ・ノード１１０（例えば、図１５のノード１１０Ａ）は、サーバ・ノード１３０（例えば、図１５のサーバ・ノード１３０Ａ）に、健全性ピング・メッセージ（例えば、Ｌ７ ＨＴＴＰ健全性ピング・メッセージ）送信を開始する。健全であれば、サーバ・ノード１３０は、ピング応答をロード・バランサ・ノード１１０に送り返す。少なくともいくつかの実施形態では、サーバ・ノード１３０上のロード・バランサ・モジュール１３２がピング・メッセージを受信し、処理するので、成功すれば、サーバ・ノード１３０上のモジュール１３２が健全であることが、健全性チェック・ピングによって証明される。このピングに対する応答を受信すると直ちに、ロード・バランサ・ノード１１０はサーバ・ノード１３０が健全であるとみなし、サーバ・ノード１３０の鼓動カウンタを増加させる。
少なくともいくつかの実施形態では、所定の健全なロード・バランサ・ノード１１０によって健全性をチェックした全てのサーバ・ノード１３０の鼓動カウンタを、他のロード・バランサ・ノード１１０に伝達することができる。この伝達は、例えば、ロード・バランサ・ノード１１０の鼓動カウンタに関して前述したゴシップ技法に従う。このゴシップ技法では、各ノード１１０が、その鼓動リストを、通常のインターバル（ゴシップ・インターバル）でランダムに選択した少なくとも他の１つのノード１１０に送信し、受信ノード１１０が、２種類のリスト中の最大値によって自身の鼓動リストを更新する。
故障検出及びゴシップ
少なくともいくつかの実施形態では、ロード・バランサ実装時の全てのロード・バランサ・ノードがコンシステントな視野を保持できるように、上述したロード・バランサ・ノード１１０及びサーバ・ノード１３０の健全性チェックによって得た情報を、ロード・バランサ実装時のすべてのノード１１０に伝達することが必要である場合がある。上述したように、少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０は、ゴシップ・プロトコルによって互いに通信し、この健全性情報を交換し、伝達し、ロード・バランサ・ノード１１０及びサーバ・ノード１３０の故障を検出することができる。
少なくともいくつかの実施形態では、通常のインターバル（ゴシップ・インターバルと呼ぶことができる）で、各ロード・バランサ・ノード１１０は、別のロード・バランサ・ノード１１０をランダムに選択し、その別のノード１１０に、ロード・バランサ・ノード１１０及びサーバ・ノード１３０の鼓動カウンタとともに健全なロード・バランサ・ノード１１０及びサーバ・ノード１３０についての自身の見解を送信する。ロード・バランサ・ノードまたはサーバ・ノード１３０が健全な限り、当該のノードは健全性チェックを合格し、その鼓動カウンタは増加し続ける。あるノードの鼓動カウンタが指定されたインターバル（これは、故障のタイム・インターバルと呼ぶことができる）の間変化しないならば、ロード・バランサ・ノード１１０は、そのノードが故障していると疑う。いったんノードが故障していると疑うと、ロード・バランサ・ノード１１０は、このノードを非健全であると判断する前に、指定されたインターバル（これを、非健全なタイム・インターバルと呼ぶことができる）を待つことができる。この非健全なタイム・インターバルによって、ロード・バランサ・ノード１１０は、このノードが故障していることをすべてのロード・バランサ・ノード１１０が知るまで待つことができる。
図１６は、少なくともいくつかの実施形態による、ロード・バランサ・ノード１１０が保持することのできる、別のノード（ロード・バランサ・ノード１１０またはサーバ・ノード１３０）の健全性の状態、または健全性についての見解を視覚的に示している。３００で示すように、ロード・バランサ・ノード１１０が、問題とするノードが健全であるとの見解からスタートすることを仮定されたい。これは、このノードの鼓動カウンタがそれまで増加していたことを示唆する。しかし、ノードの鼓動カウンタが３０２に示すように指定されたインターバル（故障タイム・インターバル）の間増加しないならば、ロード・バランサ・ノード１１０は、３０４に示すように、このノードが故障していると疑う。ノードの鼓動カウンタが３０６に示すように指定されたインターバル（非健全なタイム・インターバル）の間増加しないならば、ロード・バランサ・ノード１１０は、３０８に示すように、このノードを非健全であるとみなす。しかし、非健全なタイム・インターバルが終了する前に、３１０に示すようにノードの鼓動カウンタが増加するならば、ロード・バランサ・ノード１１０は、このノードを健全である３００と再びみなす。同様に、３１２に示すように、非健全なノードに対する鼓動の増加を受信すれば、このノードを健全である３００とみなすことができる。
ノードが非健全であると判断すると、非健全なノードがロード・バランサ・ノード１１０であるかサーバ・ノード１３０であるかによって、また、ロード・バランサ・ノード１１０の非健全なノードとの関係によって、本明細書の他の箇所でも述べているように、ロード・バランサ・ノード１１０を様々に動作させることができる。
ロード・バランサ・ノードのデータ
少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０は、ロード・バランサ実装時の状態についてのデータを保持することができる。少なくともいくつかの実施形態では、このデータを、１つまたは複数のデータ構造で、各ロード・バランサ・ノード１１０上に保持することができる。このデータ構造は、限定はされないが、健全なロード・バランサ・ノード・リスト、疑惑のロード・バランサ・ノード・リスト及び鼓動リストを含む。図１７は、健全なロード・バランサ・ノード・リスト３２０、疑惑のロード・バランサ・ノード・リスト３２２、非健全なロード・バランサ・ノード・リスト３２４及びロード・バランサ・ノード鼓動リスト３２６を保持するロード・バランサ・ノード１１０の例を示す。
少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０は、健全なロード・バランサ・ノード・リスト３２０を保持することができる。このリストは、例えば、どのノード１１０が健全であり、したがってゴシップ・プロトコルに関与しているかを決定するために用いることができる健全なロード・バランサ・ノード１１０のリストである。リスト３２０上のノード１１０のみが、ゴシップ・プロトコルによるロード・バランサ情報の伝達に関与し、リスト３２０上のノード１１０のみが、コンシステント・ハッシュ・リングに存在するとみなされ、また、このリストのノード１１０のみが、サーバ・ノード１３０の健全性をチェックする。ノード１１０は、このリスト３２０から、鼓動情報を送信する先とする別のノード１１０をランダムに選択することができる。加えて、鼓動カウンタを、健全なロード・バランサ・ノード・リスト３２０にその時あるノード１１０とのみ交換する。少なくともいくつかの実施形態では、ロード・バランサ・ノードＮがロード・バランサ・ノード１１０による健全性チェックに合格する場合、または、ロード・バランサ・ノード１１０が、ある他のリスト３２０上のロード・バランサ・ノードからノードＮについてのゴシップ・メッセージを受信するならば、ノードＮを、別のロード・バランサ・ノード１１０の健全なロード・バランサ・ノード・リスト３２０に追加することができる。
少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０は、疑惑のロード・バランサ・ノード・リスト３２２を保持することができる。これは、指定されたインターバル（故障タイム・インターバルと呼ばれる）の間、その鼓動カウンタ（鼓動リスト３２６を参照）が増加しなかったロード・バランサ・ノードのリストである。ロード・バランサ・ノードＥがロード・バランサ・ノード１１０の疑惑のロード・バランサ・ノード・リスト３２２の中にあるならば、ロード・バランサ・ノード１１０は、ノードＥについてゴシップしない。健全なリスト３２０上の、ある他のロード・バランサ・ノード１１０が、ノード１１０の鼓動リスト３２６のノードＥのカウンタより高い鼓動カウンタでノードＥについてロード・バランサ・ノード１１０にうわさを広めるならば、ノードＥは、疑惑のリスト３２２から健全なリスト３２０に移動される。ノードＥがロード・バランサ・ノード１１０の疑惑のリスト３２２に指定されたインターバル（非健全なタイム・インターバルと呼ばれる）の間留まる場合、ノードＥは、ロード・バランサ・ノード１１０によって非健全であるとみなされ、非健全なノード・リスト３２４上に移動される。ノードＧがノード１１０による健全性チェックに合格すると直ちに、または、別のノード１１０からのノードＧの鼓動カウンタの更新を受信すると直ちに、非健全なノード・リスト３２４上のノード１１０（この例では、ノードＧ）を、ロード・バランサ・ノード１１０の健全なノード・リスト３２０に移動させることができる。
少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０は、すべての既知のロード・バランサ・ノード１１０の鼓動リスト３２６を保持することができる。各ノード１１０に対して、このリスト３２６は、鼓動カウンタがいつ最後に変化したかを示す鼓動カウンタ及びタイムスタンプを含むことができる。
少なくともいくつかの実施形態では、各ロード・バランサ・ノード１１０は、すべての既知のサーバ・ノードの鼓動リストを保持することもできる。これは、図１７には示していない。このリストは、ロード・バランサ・ノード鼓動リスト３２６に類似していてもよい。いくつかの実施形態では、２種類のリストを併合することができる。少なくともいくつかの実施形態では、サーバ・ノード１３０についての鼓動情報を、例えばゴシップ・プロトコルにより、ロード・バランサ・ノード１１０についての鼓動情報とともに、または、それに加えてロード・バランサ・ノード１１０の間に伝達することができる。
図１７は４つの分離したリストを示すが、２個以上のリストを単一のリストに結合することができる点に注意するべきである。例えば、いくつかの実施形態では、すべてのノード１１０についての単一のリストを、各ロード・バランサ・ノード１１０上に保持することができ、各ノードがその時点で健全であるか、疑わしいか、または非健全であるかどうかを示すために、ビット・フラグまたは他のデータ構造を用いることができる。
サーバ・ノードのデータ
少なくともいくつかの実施形態では、サーバ・ノード１３０、及びノード１３０上のローカル・ロード・バランサ・モジュール１３２は、ロード・バランサ・ノード１１０を用いたゴシップ・プロトコルに関与しない。ロード・バランサ・ノード１１０は、それら自身の間でのみ、ロード・バランサ・ノードに対する健全性チェックの方法によって得られる、他のロード・バランサ・ノード１１０についての鼓動情報、及び、サーバ・ノードに対する健全性チェックの方法によって得られる、サーバ・ノード１３０についての鼓動情報を広める（具体的には、各ロード・バランサ・ノード１１０は、その時点で、健全なロード・バランサ・ノード・リスト３２０上にあるノードのみに情報を伝える）。
しかし、サーバ・ノード１３０が出力クライアント・トラフィックを転送することのできる先であるロード・バランサ・ノード１１０（とりわけ、出口ノード）を、サーバ・ノード１３０が決定できるように、また、どのロード・バランサ・ノードに接続公表情報を送信するべきであるかをサーバ・ノード１３０が判断できるように、各サーバ・ノード１３０／ロード・バランサ・モジュール１３２は、ロード・バランサ実装時の健全なロード・バランサ・ノード１１０についての情報を必要とする場合がある。少なくともいくつかの実施形態では、この情報をサーバ・ノード１３０に提供するために、ロード・バランサ・ノード１１０は、その時点での健全なロード・バランサ・ノード１１０を識別する情報（例えば、図１７の健全なロード・バランサ・ノード・リスト３２０）で、サーバ・ノード１３０を定期的にまたは非定期に更新することができる。少なくともいくつかの実施形態では、所定のサーバ・ノード１３０（図１５を参照）の健全性をチェックする責任を負うロード・バランサ・ノード１１０は、その時点の健全なロード・バランサ・ノードを識別する情報をサーバ１３０に提供する責任を負う。例えば、図１５では、ロード・バランサ・ノード１１０Ａは、その健全なロード・バランサ・ノードリスト３２０を、サーバ・ノード１３０Ａ、１３０Ｂ、１３０Ｃ及び１３０Ｄに送信することができる。また、ロード・バランサ・ノード１１０Ｂは、その健全なロード・バランサ・ノードリスト３２０を、サーバ・ノード１３０Ｃ、１３０Ｄ及び１３０Ｅに送ることができる。以下同様である。
ロード・バランサ・ノード故障の取り扱い
図１８Ａ，１８Ｂは、少なくともいくつかの実施形態による、ロード・バランサ・ノード故障への対処を示している。図１８Ａは、ロード・バランサ実装の例を示す。ここではロード・バランサ実装中の４つのロード・バランサ・ノード１１０Ａ〜１１０Ｄがある。エッジ・ルータ１０４は、着信パケットをクライアント（図示せず）からロード・バランサ・ノード１１０まで経路指定する。少なくともいくつかの実施形態では、エッジ・ルータ１０４は、４層フロー単位ハッシュ化多重パス経路指定技法、例えば等コスト・多重パス（ＥＣＭＰ）経路指定技法により経路指定を行うことができる。少なくともいくつかの実施形態では、エッジ・ルータ１０４は、ロード・バランサ・ノード１１０の広告、例えば、このロード・バランサ・ノード１１０で開始される境界ゲートウェイ・プロトコル（ＢＧＰ）技術セッションを介した広告によって、クライアント・トラフィックを受信するためにロード・バランサ実装時に利用できるロード・バランサ・ノード１１０についての情報を得る。しかし、少なくともいくつかの実施形態では、ＢＧＰセッションによって自身をエッジ・ルータ１０４に広告するロード・バランサ・ノード１１０の代わりに、ロード・バランサ実装時の他の少なくとも１つのノード１１０が、ＢＧＰによってそのノード１１０をエッジ・ルータ１０４に広告する責任を負う。例えば、図１８Ａに示すいくつかの実施形態では、所定のノード１１０の左右に隣接するノード１１０が、その所定のノード１１０をエッジ・ルータ１０４に広告する。例えば、ロード・バランサ・ノード１１０Ａはノード１１０Ｂ及び１１０Ｄを広告し、ロード・バランサ・ノード１１０Ｂはノード１１０Ａ及び１１０Ｃを広告し、また、ロード・バランサ・ノード１１０Ｃはノード１１０Ｂ及び１１０Ｄを広告する。
また、図１８Ａの例に示すように、各ロード・バランサ・ノード１１０は、他の１つまたは複数のロード・バランサ・ノード１１０の健全性を定期的にチェックする。例えば、１つまたは複数のランダムに選択されたノード１１０、ロード・バランサ・ノードの順序リストによって決定された１つまたは複数の隣接するノード１１０、または、１つまたは複数の隣接するノード１１０及び１つまたは複数のランダムに選択されたノードである。加えて、各ロード・バランサ・ノード１１０は、少なくとも１つのサーバ・ノード１３０の健全性を定期的にチェックすることができるし、健全なロード・バランサ・ノード１１０についてのリストを、健全性チェックを行うサーバ・ノードに送信することもできる。ロード・バランサ・ノード１１０及びサーバ・ノード１３０の健全性情報をノード１１０の間で伝達することができるが、これを、例えばゴシップ・プロトコルによって行うことができる。
図１８Ｂは、図１８Ａのロード・バランサ実装時の例において、１つのロード・バランサ・ノード１１０の故障の取り扱いを示している。この例では、ロード・バランサ・ノード１１０Ｂが、何かの理由で故障している。例えば、ノード１１０Ａ及び１１０Ｃはノード１１０Ｂの健全性をチェックすることができ、両方とも、ノード１１０Ｂがその健全性チェックに不合格であることを検出することができる。例えば、ノード１１０Ａ及び１１０Ｃは、ノード１１０Ｂの鼓動カウンタを増加させない。ノード１１０Ａ及び１１０Ｂの双方からの鼓動情報を、他の健全なロード・バランサ・ノード１１０（この例では、唯一の他のロード・バランサ・ノードはノード１１０Ｄである）に、ゴシップ・プロトコルによって伝達する。全ての健全なロード・バランサ・ノード１１０（この例では、ノード１１０Ａ、１１０Ｃ及び１１０Ｄ）がノード１１０Ｂの故障に集中するとすぐに、限定はされないが、１つまたは複数の次の事象が生じる可能性がある。なお、これらの事象は必ずしもこの順序で起こるわけではない。
・ノード１１０Ａ及び１１０Ｃは、ノード１１０Ｂをエッジ・ルータ１０４に広告するのを止める。これは、少なくともいくつかの実施形態では、ノード１１０がノード１１０Ｂを広告するためにエッジ・ルータ１０４と確立したＢＧＰセッションを終わらせることを含む。なお、各ノード１１０は、エッジ・ルータ１０４と、広告する他のノードごとに、別々のＢＧＰセッションを確立するので、ノード１１０Ｂに対するＢＧＰセッションを終わらせても、他の広告されているノード１１０に影響を及ぼさない。少なくともいくつかの実施形態では、ノード１１０は、ＢＧＰセッションに対するエッジ・ルータ１０４へのＴＣＰ終了または類似のメッセージを送信することによって、エッジ・ルータ１０４とのＢＧＰセッションを終了させる。
・エッジ・ルータ１０４は、ノード１１０Ｂが、もはやいずれのノードからも広告されていないことが検出されたことに応答して、ノード１１０Ｂに対するクライアント・データ・パケットの経路指定を停止する。また、エッジ・ルータ１０４は、クライアントからのパケット・フローを、残っている健全なロード・バランサ・ノード１１０、特に、ノード１１０上の入口サーバ１１２に再分散させるために、多重パス（例えば、ＥＣＭＰ）ハッシングを調整する。入口サーバ１１２に経路指定されたパケット・フローであって、それに対して入口サーバ１１２がクライアント->サーバ・マッピングを有していない、いかなるパケット・フローについても、そのマッピングを、このクライアント->サーバ接続のフロー・トラッカ・ノード（ｆｌｏｗ ｔｒａｃｋｅｒ ｎｏｄｅ）から得ることができる。または、代わりに、図１０Ａ〜１０Ｇに図示する技法に従って、新しいクライアント->サーバ接続を確立することができる。
・ノード１１０Ａ及び１１０Ｃは、相互に広告するために、それぞれ、エッジ・ルータ１０４にＢＧＰセッションを開設することができる。なお、ノード１１０Ａ及び１１０Ｃはともに、ロード・バランサ・ノード１１０Ｂ同様、ノード１１０Ｄによってもエッジ・ルータ１０４に広告されるので、ノード１１０Ｂが故障しているときノード１１０Ａ及び１１０Ｂの広告を停止することができるという事実によって、エッジ・ルータ１０４が、これら２つのノード１１０へのパケットの経路指定を停止するということにはならない。
・少なくともいくつかの実施形態では、ノード１１０Ａ及び１１０Ｃは、今や隣接するノード１１０であるので、相互に健全性をチェックする責任を負うことができる。なお、ノード１１０Ｂを非健全であるとみなしているにもかかわらず、他の１つまたは複数のノード１１０は、それでもランダムに健全性をチェックすることができる。
・残っている１つまたは複数の健全なロード・バランサ・ノード１１０は、以前にノード１１０Ｂによってフローをトラッキングしたフロー・トラッキング接続の責任を負うことができる。例えば、ノード１１０Ｃ及び／またはノード１１０Ｄは、ノード１１０Ｂがその一次またはニ次のフロー・トラッカであった１つまたは複数の接続を、図１１Ｃおよび１１Ｄに示す一次またはニ次のフロー・トラッカとして引き継ぐことができる。
・残っている１つまたは複数の健全なロード・バランサ・ノード１１０は、以前ノード１１０Ｂが健全性をチェックしたサーバ・ノード１３０の健全性をチェックする責任を負うことができる。サーバ・ノード１３０を、残っているロード・バランサ・ノード１１０による健全なロード・バランサ・ノード・リスト（今やノード１１０Ｂを含んでいない）で更新する。例えば、図１８Ｂにおいて、ロード・バランサ・ノード１１０Ａはサーバ・ノード１３０Ｃの健全性チェック及び更新を開始し、ロード・バランサ・ノード１１０Ｃは、サーバ・ノード１３０Ｂの健全性チェック及び更新を開始する。
・エッジ・ルータ１０４上では、故障しているノード１１０ＢからのＢＧＰセッションが、やがてタイムアウトになる。あるいは、エッジ・ルータ１０４が、ノード１１０Ｂの故障を認識して、ＢＧＰセッションを終了することができる。
２つのロード・バランサ・ノード１１０が、同時に、または、ほとんど同時に故障する場合がありうる。２つの故障したロード・バランサ・ノードが互いに隣接していない場合、故障は独立しており、別々の単独のノード１１０故障として図１８Ｂに示す方法によって取り扱うことができる。しかし、２つの故障したノードが互いに隣接している場合（例えば、図１８Ａのノード１１０Ｂ及び１１０Ｃ）、全ての健全なロード・バランサ・ノード１１０（この例では、ノード１１０Ａ及び１１０Ｄ）が故障を検出し、故障に集中すると直ちに、限定はされないが、１つまたは複数の、次の事象が生じる場合がある。なお、これらの事象は必ずしもこの順序で生じるわけではないことに留意されたい。
・ノード１１０Ａが、ノード１１０Ｂの代わりにエッジ・ルータ１０４に対するＢＧＰセッションを終了させる。
・ノード１１０Ｄが、ノード１１０Ｃの代わりにエッジ・ルータ１０４に対するＢＧＰセッションを終了させる。
・ノード１１０Ａ及び１１０Ｄが、互いを広告するエッジ・ルータ１０４とのＢＧＰセッションを開始する。
・ノード１１０Ａ及び１１０Ｄは、互いの健全性チェックを開始することができる。なお、ノード１１０Ａ及び１１０Ｄは、故障しているノード１１０の健全性チェックを継続することもできる。
・残っている健全なノード１１０が、健全なロード・バランサ・ノード・リストでサーバ・ノード１３０を更新する。
・ノード１１０Ｂ及びノード１１０Ｃが互いをエッジ・ルータ１０４に広告し続けることができるので、トラフィックがエッジ・ルータ１０４からノード１１０Ｂ及び／またはノード１１０Ｃに流れ続けることができる。しかし、これらのＢＧＰセッションはやがてタイムアウトになり、それに応じてエッジ・ルータ１０４が残っている広告されたノード１１０にこのフローを再分散させる。
・ノード１１０Ｂ及び１１０Ｃがノード１１０Ａ及び１１０Ｄをなお健全であると考えているならば、ノード１１０Ｂ及び１１０Ｃは、それぞれがノード１１０Ａ及び１１０Ｄを広告する先であるエッジ・ルータ１０４とのＢＧＰセッションを閉じることができる。
接続公表
再び図１を参照すると、少なくともいくつかの実施形態では、ロード・バランサ実装時のロード・バランサ・ノード１１０は、サーバ１３０に対するクライアントのＴＣＰ接続の状態情報を保持している。この状態情報は、ロード・バランサ・ノード１１０が、エッジ・ルータ１０４からＴＣＰ接続に対して責任を負うサーバ・ノード１３０まで着信クライアント・トラフィックを経路指定できるようにする。サーバ・ノード１３０上のロード・バランサ・モジュール１３２は、それぞれのサーバ１３４に対するアクティブなＴＣＰ接続のリストを保持している。接続公表は、サーバ・ノード１３０上のロード・バランサ・モジュール１３２がロード・バランサ・ノード１１０に対するアクティブなクライアントＴＣＰ接続のリストを公表することができるメカニズムであり、このメカニズムによってそれを公表する。少なくともいくつかの実施形態では、接続公表パケットを、通常のインターバルでロード・モジュール１３２によってロード・バランサ・ノード１１０に対して形成し、公表する。この通常のインターバルを接続公表インターバルと呼ぶことができる。
少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０が保持する接続状態情報を、キャッシュの形態で見ることができる。また、特定の接続についての状態情報を保持することは、その接続についてロード・バランサ・ノード１１０に対するリースを継続することとみることができる。キャッシュエントリが更新されない限り、ロード・バランサ・ノード１１０はデータ・フローを取り扱うサーバ・ノード１３０にクライアント・データ・フローを経路指定することができてはいけない。接続公表メカニズムは定期的に、サーバ・ノード１３０からのその時点の接続状態を有する、ロード・バランサ・ノード１１０上のキャッシュを、したがってリースを更新し、こうして、クライアント１６０から適切なサーバ・ノード１３０へのＴＣＰパケットの流れを保持する。クライアント１６０がサーバ１３４へのＴＣＰ接続を終了するとき、この接続と関連するサーバ・ノード１３０上のロード・バランサ・モジュール１３２は、そのアクティブな接続のリストからこの接続を削除し、したがって、このＴＣＰ接続を、もはや接続公表メカニズムを通じて公表しない。したがって、この接続（とりわけ、この接続のための入口サーバ１１２並びに一次及び二次のフロー・トラッカ１１６）と関連するロード・バランサ・ノード１１０上のこの接続の接続状態情報（キャッシュ・エントリ）はもはや更新されず、この接続は、ロード・バランサ・ノード１１０から外される。少なくともいくつかの実施形態では、この接続の１つまたは複数のキャッシュ・エントリは、他のなんらかのアクティブな接続のためにメモリが求められるまで、ロード・バランサ・ノード１１０上のキャッシュに残ることができる。
こうして、接続公表メカニズムは、入口サーバ１１２並びに一次及び二次のフロー・トラッカ１１６に関する接続リースを定期的または非定期に延長し、クライアント・トラフィックの流れを保持する。加えて、接続公表メカニズムは、少なくともいくつかのロード・バランサ・ノード１１０の故障からの回復を支援することができる。クライアント接続の状態情報を保持する１つまたは複数のロード・バランサ・ノード１１０が故障しているときに、いくつかの事例で、残っているロード・バランサ・ノード１１０に接続公表によって提供されるアクティブな接続情報を用いて接続を回復することができる。
接続公表メカニズムを用いることで、サーバ・ノード１３０は、サーバ１３４とクライアント１６０の間の接続状態に関する信頼すべき情報源となる。加えて、サーバ１３４への接続の終了は、サーバ・ノード１３０上のロード・バランサ・モジュール１３２とロード・バランサ・ノード１１０により受動的に取り扱われる。ハンドシェイキングは、サーバ・ノード１３０とロード・バランサ・ノード１１０の間では求められない。換言すれば、ロード・バランサ・モジュール１３２は、特定の接続が終了したことをロード・バランサ・ノード１１０に積極的に通知するために、このノードにメッセージを送信する必要はない。サーバ１３４が接続を終了するときに、サーバ１３４は接続に関する内部状態を消去する。ロード・バランサ・モジュール１３２は、サーバ１３４の内部状態を用いて接続公表パケットにデータを追加する。この接続はもはやサーバ１３４の内部状態にないので、接続は、ロード・バランサ・ノード１１０に公表されない。ロード・バランサ・ノード１１０上での接続のリースはこのように終了し、ロード・バランサ・ノード１１０はこの接続に関して受動的に忘れる。この接続に用いられたロード・バランサ・ノード１１０のキャッシュ内のメモリは、その後、必要に応じて、他の接続に用いることができる。
いくつかの実施形態では、ロード・バランサ・ノード１１０によって維持される接続のリースには、キャッシュ内の、接続に関するタイムスタンピング・エントリを含めることができる。接続についてのリースを接続公表パケットによって更新するときには、タイムスタンプを更新することができる。接続が、サーバ・ノード１３０上のロード・バランサ・モジュール１３２によりもはや公表されていないという理由で、接続についてのリースが更新されないならば、タイムスタンプはもはや更新されない。少なくともいくつかの実施形態では、接続についてのエントリをメモリが必要となるまでキャッシュ内に残すことのできるレイジィー・ガーベジ・コレクション法を用いることができる。例えば、少なくともいくつかの実施形態では、キャッシュ・エントリに対するタイムスタンプは、リース更新時の閾値と比較することができ、キャッシュ・エントリに対するタイムスタンプがこの閾値よりも古いならば、このエントリは古いままであり再利用することができる。しかし、いくつかの実施形態では、古いままであるエントリを、積極的にガーベジ・コレクションすることができる。
受け側の接続公表
少なくともいくつかの実施形態では、クライアントＴＣＰ接続ごとに、接続状態を維持する３つのロード・バランサ・ノード１１０：入口サーバ１１２として働くノード１１０、一次フロー・トラッカ１１６として働くノード１１０、及び二次フロー・トラッカ１１６として働くノード、がある。所定のＴＣＰフローに対して、例えばロード・バランサ・ノード１１０によって、コンシステント・ハッシュ関数をＴＣＰフローに適用して、一次フロー・トラッカ１１６ノード及び、それを継承するコンシステント・ハッシュ・リング内のノードを見つけることによって、一次及び二次のフロー・トラッカ１１６を決定することができる。ＴＣＰフローに対して入口サーバ１１２として働くロード・バランサ・ノード１１０は、エッジ・ルータ１０４の内部多重パス（例えば、ＥＣＭＰ）ハッシュ関数に基づいてエッジ・ルータ１０４からのＴＣＰフローのトラフィックを受信するノード１１０である。ノード１１０の故障または追加があるならば、入口サーバ１１２として働くロード・バランサ・ノード１１０は、多くのアクティブなＴＣＰフローに対して変わることができる。そして、少なくともいくつかのアクティブなＴＣＰフローのフロー・トラッカとして働くロード・バランサ・ノード１１０は、変わることができる（図１１Ａ〜１１Ｄ参照）。サーバ・ノード１３０上のサーバ１３２に対するＴＣＰフローごとに、どのロード・バランサ・ノード１１０がそのＴＣＰフローの入口サーバ１１２であるかを示す状態情報を、サーバ・ノード１３０上のロード・バランサ・モジュール１３２が維持している。それは、そのロード・バランサ・モジュール１３２がそのロード・バランサ・ノード１１０からトラフィックを受信するからである。しかし、少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２は、ＴＣＰフローに対して、どのロード・バランサ・ノード１１０が一次及び二次のフロー・トラッカとして働くのかを知ることはできないし、決定する能力を有することはできない。なぜなら、ロード・バランサ・モジュール１３２は、用いられるコンシステント・ハッシュ関数を知ることができないからである。換言すれば、少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２は、コンシステント・ハッシングを行わない。
アクティブな接続情報の公表
図１９Ａ、１９Ｂは、少なくともいくつかの実施形態による、接続公表技法を視覚的に示している。図１９Ａは、ロード・バランサ・ノードに対してアクティブな接続の情報を公表するロード・バランサ（ＬＢ）モジュールを示す。少なくともいくつかの実施形態では、各ロード・バランサ・モジュール１３２は、サーバ・ノード１３０上でアクティブなＴＣＰフローごとに情報を収集して、接続公表パケットを形成する。所定のＴＣＰフローの情報は、フローに対する入口サーバ１１２として働くロード・バランサ・ノード１１０を識別する情報を含む。接続公表パケットの準備ができている（例えば、接続公表インターバルに達しているとき）とき、ロード・バランサ・モジュール１３２は、ロード・バランサ・ノード１１０をランダムに選択するが、その選択は、例えば、健全なロード・バランサ・ノード１１０のリストからであり、そのリストはロード・バランサ・ノード１１０からサーバ・ノード１３０に定期的に送信され、そのロード・バランサ・ノード１１０は、前述のとおりサーバ・ノード１３０の健全性をチェックする。その後、ロード・バランサ・モジュール１３２は、選択したノード１１０に接続公表パケットを送信する。例えば、図１９Ａにおいて、ロード・バランサ・モジュール１３２Ａは、ロード・バランサ・ノード１１０Ａに１つの接続公表パケットを既に送信しているが、その後、ロード・バランサ・ノード１１０Ｂに、別の接続公表パケットを送る。
図２０は、少なくともいくつかの実施形態による、各ロード・バランサ・モジュール１３２が行うことのできる接続公表方法についてのハイレベルのフローチャートである。５００に示すように、ロード・バランサ（ＬＢ）モジュール１３２は、それぞれのサーバ・ノード１３０上のアクティブな各ＴＣＰフローに対して接続公表エントリを作成する。少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２が、サーバ・ノード１３０上のサーバ１３４が対処するアクティブなＴＣＰ接続の一式を、例えばサーバ・ノード１３０上の／ｐｒｏｃ／ｎｅｔ／ｔｃｐから読み出す。アクティブな各ＴＣＰ接続に対して、ロード・バランサ・モジュール１３２は、（例えば、ローカルに保持されているアクティブな接続の表の中で）そのＴＣＰフローに対して入口サーバ１１２の役割を果たすロード・バランサ・ノード１１０を探し、この接続に対するＴＣＰタプルを示す接続公表エントリ（例えば、以下からなる４−タプル：クライアントＩＰアドレス、クライアント・ポート、サーバの（公開）ＩＰアドレス、及びサーバ・ポート）並びにこの接続のための入口サーバ１１２を作成する。なお、各ロード・バランサ・モジュール１３２は、アクティブなＴＣＰ接続ごとの情報を保持し、その情報は、その接続が受け取ったパケットの出所である最後のロード・バランサ・ノード１１０を示すことに留意されたい。また、ロード・バランサ・モジュール１３２は、この情報を、個々のアクティブな接続に対する入口ノード１１０を識別するために用いることができる。
５０２に示すように、ロード・バランサ・モジュール１３２は、（１つまたは複数の接続公表エントリを含み、アクティブなＴＣＰ接続ごとに１つのエントリを有する）接続公表パケットが送信されることになっているロード・バランサ・ノード１１０をランダムに選択する。少なくともいくつかの実施形態では、接続公表パケットを送信する準備ができているとロード・バランサ・モジュール１３２が判断したとき、ロード・バランサ・モジュール１１０を、ランダムに選択することができる。少なくともいくつかの実施形態では、この判断を、接続公表インターバルに従って行う。非限定的な例として、この接続公表インターバルを、１００ミリ秒（ｍｓ）または１秒とすることができる。少なくともいくつかの実施形態では、ロード・バランサ・モジュール１１０を、ロード・バランサ・ノード１１０のうちの１つから以前に受信した健全なロード・バランサ・ノード１１０のリストから選択する。５０４で示すように、ロード・バランサ・モジュールは、この後、接続公表パケットを、選択したロード・バランサ・ノード１１０に公表する。少なくともいくつかの実施形態では、接続公表パケットはステートレス・パケット、例えばＵＤＰパケットである。いくつかの実施形態では、この接続公表パケットを、標的のロード・バランサ・ノード１１０に送信する前に圧縮することができる。少なくともいくつかの実施形態では、接続公表情報を、２つ以上のパケットで標的のロード・バランサ・ノード１１０に送信することができる。
要素５０４から要素５００に返っている矢で示すように、ロード・バランサ・モジュール１３２は、連続的に、接続公表パケットを構築し、ランダムなノード１１０を選択し、また、選択したノードにパケットを送信することができる。上記したように、これを、接続公表インターバルに従って行うことができるので、ロード・バランサ・ノード１１０を、その時点のアクティブな接続の情報で比較的定期的にリフレッシュすることができ、ロード・バランサ・ノード１１０上の接続リースを継続することができる。
少なくともいくつかの実施形態では、接続公表パケットは、ロード・バランサ・モジュールによってロード・バランサ・ノード１１０にランダムに分散されるので、接続公表パケットを受信するロード・バランサ・ノード１１０は、接続公表パケット内のアクティブな接続情報を、接続の正しい入口／一次／二次の各ノード１１０に分散させる義務を負う。図１９Ｂ及び図２１、２２は、少なくともいくつかの実施形態で用いることができるアクティブな接続情報を分散させる方法を示す。
図１９Ｂは、少なくともいくつかの実施形態による、ロード・バランサ・ノード１１０の間へのアクティブな接続情報の分散化を示している。ロード・バランサ・ノード１１０がロード・バランサ・モジュール１３２から接続公表パケットを受信するとき、ロード・バランサ・ノード１１０は、そのときに示されるＴＣＰフローごとの情報を分析して、そのフローの入口ノード並びに一次及びニ次のフロー・トラッカ・ノードを決定することができる。ロード・バランサ・ノード１１０がフローに対してそれらの役割の１つの働きをしているならば、ロード・バランサ・ノード１１０は、（例えば、状態情報についてそのキャッシュを更新することによって）フローの情報を消費する。少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０はまた、パケットにフローの情報を入れて、フローに対する他の役割を担う１つまたは複数の他のノード１１０に送信することもできる。接続公表パケットが示す残りのフローに対しては、ロード・バランサ・ノード１１０は、アクティブな接続情報を２つ以上のより小さなパケットに分割して、それぞれのパケットを１つまたは複数の他のロード・バランサ・ノード１１０に送信する。例えば、少なくともいくつかの実施形態では、１つまたは複数のフローのアクティブな接続情報を含むパケットを、フローの入口サーバ１１２、一次フロー・トラッカ１１６Ａ及び二次フロー・トラッカ１１６Ｂとして働くロード・バランサ・ノード１１０に送信することができる。
図２１は、少なくともいくつかの実施形態による、接続公表パケット内に受信されたアクティブな接続情報を、標的ロード・バランサ・ノード１１０に分散させる方法のフローチャートである。５２０に示すように、ロード・バランサ・ノード１１０はロード・バランサ・モジュール１３２から接続公表パケットを受信する。このロード・バランサ・モジュール１３２は、例えば、図１９Ａ、２０を参照して上記で説明したように、パケットを生成して、このパケットを受信するロード・バランサ・ノード１１０を選択した。接続公表パケットは、パケットを受信するサーバ・ノード１３０を識別する情報（例えば、サーバ・ノード１３０上のロード・バランサ・モジュール１３２のＩＰアドレス）、及びアクティブなＴＣＰ接続を識別するエントリのリスト（例えば、各接続に対するクライアントＩＰアドレス、クライアント・ポート、サーバの（パブリック）ＩＰアドレス、及びサーバ・ポートの４要素からなる組）を含むことができる。
図２１の要素５２２〜５３０において、ロード・バランサ・モジュール１１０は、受信した接続公表パケットに示されるアクティブなＴＣＰ接続情報を繰り返し処理する。５２２に示すように、ロード・バランサ・ノード１１０は、パケット内の次のＴＣＰフローのエントリを分析して、それぞれのＴＣＰフローの入口ノード１１０並びに一次及び二次のフロー・トラッカ・ノード１１０を決定する。少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０は、この接続公表エントリから入口ノード１１０の識別情報を得る。少なくともいくつかの実施形態では、ＴＣＰフローの一次及び二次のフロー・トラッカ・ノード１１０を、コンシステント・ハッシュ関数により決定することができる。５２４では、ロード・バランサ・ノード１１０が、調査中のＴＣＰフローに対して１つの役割を担うならば、その後、５２６で、ロード・バランサ・ノード１１０は、例えば、そのキャッシュを状態情報に対して更新することによって、このフローの情報を消費する。５２８で示されるように、ロード・バランサ・ノード１１０は、ＴＣＰフローの接続公表エントリを、別のロード・バランサ・ノード１１０に送信されるべき構築中のパケットに追加することができる。５３０では、接続公表パケット内に、フローの接続公表エントリがもっとあるならば、この方法は、５２２に戻って次のエントリを処理する。そうでないならば、ロード・バランサ・ノードは、それぞれが、元の接続公表パケットからの接続公表エントリのサブセットを含む新らたに構築されたパケットを、５３２で示すように、パケットの標的ロード・バランサ・ノード１１０に送信する。少なくともいくつかの実施形態では、標的ロード・バランサ・ノード１１０に送信されたパケットは、ステートレス・パケット、例えば、ＵＤＰパケットである。いくつかの実施形態では、このパケットを、標的のロード・バランサ・ノード１１０に送信する前に圧縮することができる。
このように、少なくともいくつかの実施形態では、図２１の要素５２２〜５２８において、フロー・トラッカ・ノード１１０は、受信した接続公表パケット内の接続公表エントリから、５２２で決定された情報によりそれぞれ他のノード１１０のうちの特定の１つに送信される１つまたは複数のパケット（例えば、ＵＤＰパケット）を構築する。少なくともいくつかの実施形態では、別のノード１１０に送信されたパケットは、ＴＣＰフローのエントリを含み、この標的ノード１１０はＴＣＰフローの入口ノード１１０、一次フロー・トラッカ・ノード１１０または二次フロー・トラッカ・ノード１１０として働く。なお、いくつかの実施形態では、所定のロード・バランサ・ノード１１０は、ＴＣＰフローの入口ノード及び一次フロー・トラッカ・ノードの両方、または、ＴＣＰフローの入口ノード及びニ次フロー・トラッカ・ノードの両方の働きをすることができることに留意されたい。
図２２は、少なくともいくつかの実施形態による、接続公表パケット内に受信されたアクティブな接続情報を、標的ロード・バランサ・ノード１１０に分散させる代替の方法を示している。５５０に示すように、ロード・バランサ・ノード１１０は、ロード・バランサ・モジュール１３２から、接続公表パケットを受信する。この方法では、５５２で示すように、ロード・バランサ・モジュール１１０上のプロセスが、このパケット内の接続公表エントリを分析し、それに応じて、この受信したパケットを１つまたは複数のより小さなパケットに分割する。ロード・バランサ・モジュール１１０は、このプロセスの間、フロー情報をローカルに消費しない。一旦、接続公表パケットが１つまたは複数のパケットに分割されると、これらのパケットは、その後、５５４〜５６０に示すように処理される。５５４では、パケットの標的ノード１１０がこのロード・バランサ・ノード１１０であれば、このロード・バランサ・ノード１１０は、５５６で示すようにパケットをローカルに消費する。そうでないなら、このパケットは、標的ロード・バランサ・ノード１１０に送信される。５６０で、処理するべきパケットがもっとあれば、この方法は、次に５５４に戻る。そうでないなら、この方法は終了される。
このように、ロード・バランサ・モジュール１３２から接続公表パケットを受信するロード・バランサ・ノード１１０は、接続公表パケットを他のロード・バランサ・ノード１１０のうちの特定のものに特異的な２つ以上のより小さなパケットに分割し、それに応じてパケットを分散させることができ、一方、ロード・バランサ・ノード１１０がその時点で取り扱ういかなるＴＣＰフローについても、そのフロー情報が内部的に消費される。その間に、他のロード・バランサ・ノード１１０は、ロード・バランサ・モジュール１３２から接続公表パケットを受信し、接続公表エントリを複数のより小さなパケットに分割し、さらに、これらのより小さなパケットを標的ノード１１０に送信し、それによって、アクティブな接続情報をノード１１０間に分散させることもできる。
接続公表のトリガ
少なくともいくつかの実施形態では、接続公表は、１つまたは複数の異なる事象によって、ロード・バランサ・モジュール１３２上で始動され得る。既に述べたように、いくつかの実施形態では、接続公表パケットが生成され、接続公表インターバル、例えば１００ミリ秒または１秒のインターバルにより、ランダムに選択されたロード・バランサ・ノード１１０に送信されて、このロード・バランサ・ノード１１０上のＴＣＰ接続のリースが更新され得る。いくつかの実施形態では、ロード・バランサ・ノード１１０のメンバー数の変化は、接続公表の事象を直ちに始動させることができる。少なくともいくつかの実施形態では、ロード・バランサ・モジュール１３２は、それぞれのサーバ・ノード１３０の健全性をチェックするロード・バランサ・ノード１１０のうちの１つが送る健全なロード・バランサ・ノード１１０のリストから、変化について知ることができる。ロード・バランサ・モジュール１３２は、このリストによる変化（削除または追加）を検出すると直ちに、接続公表パケットを生成し、ロード・バランサ・ノード１１０に送信することができるので、この変化に影響を受けたＴＣＰ接続を、ロード・バランサ・ノード１１０によって、より速く回復させることができる。
パケット・ループの防止
接続公表パケットを処理している間にロード・バランサ層のメンバー数が変化するならば、接続公表パケット・ループが生じる可能性がある。第１のノード１１０は、ロード・バランサ・モジュール１３２から接続公表パケットを受信し、より小さなパケットを第２のノード１１０に送信することができる。しかし、メンバー数が変化したならば、第２のノードは、パケットが第１のノード１１０に行くこと決定することができ、このため、パケットを第１のノード１１０に転送することができる。少なくともいくつかの実施形態では、このループの発生を防止するために、さまざまなポート番号を、ロード・バランサ・モジュール１３２及びロード・バランサ・ノード１１０から受信する接続公表パケットに用いることができる。また、ロード・バランサ・ノード１１０は、別のロード・バランサ・ノード１１０から受信した接続公表パケットを再分散させない。
接続公表パケット分散の代替案
上記の接続公表の方法において、ロード・バランサ・モジュール１３２は、接続公表パケットを送信する相手であるロード・バランサ・ノード１１０をランダムに選択する。しかし、いくつかの実施形態では、他の方法を用いてロード・バランサ・ノード１１０を選択することができる。例えば、いくつかの実施形態では、ロード・バランサ・ノード１３２は、１つまたは複数のアクティブなＴＣＰフローを取り扱う特定の入口ノード１１０にそれぞれ向けられた１つまたは複数の接続公表パケットを構築することができ、パケットを標的入口ノード１１０に送信した。この入口ノード１１０は、アクティブな接続情報を、その接続の一次及び二次のフロー・トラッカに、さらに再分散させた。他の例として、いくつかの実施形態では、接続公表パケットを、ランダムに選択した単一のノード１１０に送信する代わりに、各接続公表パケットを、ロード・バランサ・モジュール１３２によって、２つ以上の健全なノード１１０、または、全ての健全なノード１１０に送信することができる。
ロード・バランサ・ノードのアーキテクチャ
図２３は、少なくともいくつかの実施形態によるロード・バランサ・ノード１１０のソフトウェア・スタックのアーキテクチャの例を示したものであり、これに限定する意図はない。このソフトウェア・スタック・アーキテクチャの例では、ロード・バランサ・ノード１１０は、ジャバ・ネイティブ・インターフェイス（ＪＮＩTM）１１０４を用いて、ロード・バランサ・サーバのネイティブ・コード１１０６及び、例えば、インテルTM・データプレーン開発キット（ＤＰＤＫ）技術コードのコア・パケット処理コード１１０８を含むことができるネイティブ・コードの層を管理する単一のジャバTM技術プロセス１１０２内で動作する。このネイティブ・コードは２つのネットワーク・インターフェイス・コントローラ（ＮＩＣ１１１４Ａ及び１１１４Ｂ）をインターフェイス接続することができる。第一のＮＩＣ（ＮＩＣ１１１４Ａ）は「北」、すなわち、エッジ・ルータ１０４の方に面することができる。第二のＮＩＣ（ＮＩＣ１１１４Ｂ）は「南」、すなわち、サーバ・ノード１３０の方に面することができる。少なくともいくつかの実施形態では、ＮＩＣ１１１４Ａ及び１１１４ＢはＴＣＰスタックを維持することができない。したがって、少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０が制御プレーンを介してプロセスと通信することができるように、ＴＣＰ接続をサポートする第三のＮＩＣ１１１４Ｃを含むことができるし、逆もまた同様である。あるいは、いくつかの実施形態では、ロード・バランサ・ノード１１０は北に面する第一のＮＩＣ１１１４Ａと南に面する第二のＮＩＣ１１１４Ｂのみを実装することができて、南に面するＮＩＣ１１１４ＢがＴＣＰスタックを実装することができ、それを介してロード・バランサ・ノード１１０がプロセスとのコントロール・プレーンを介した通信をすることができる。ロード・バランサ・ノード１１０はまた、オペレーティング・システム（ＯＳ）技術ソフトウェア１１１２（例えば、リナックスTMカーネル）並びに、ＯＳ技術ソフトウェア１１１２及びＪＮＩ１１０４技術の上にあるジャバ・バーチャル・マシーン（ＪＶＭTM）技術ソフトウェア１１１０レイヤー、も含む。
少なくともいくつかの実施形態では、分散型ロード・バランシング・システム内の各ロード・バランサ・ノード１１０は、高いパケット・レートで多くのデータ・フローを同時に処理しなければならない場合がある。少なくともいくつかの実施形態では、処理能力の必要なレベルを達成するために、ロード・バランサ・ノード１１０は高性能パケット処理用のインテルTM・データプレーン開発キット（ＤＰＤＫ）技術を利用することができる。ＤＰＤＫ技術は、ユーザ空間プログラムがパケットを直接ネットワーク・インターフェイス・コントローラ（ＮＩＣ）から読み取り／ネットワーク・インターフェイス・コントローラ（ＮＩＣ）に書き込むことを可能にし、リナックス・カーネル・ネットワーキング・スタック（リナックスｉｘｇｂｅベースＮＩＣドライバを除く）の多くの層を迂回する。パケット処理へのＤＰＤＫアプローチは、ビジー・ループにＮＩＣハードウェアを直接投入する専用のＣＰＵコアを選択して割り込みハンドラーベースの入力を拒絶する。このアプローチは、ビジー・ループ内に専用のＣＰＵコアを連続的に走らせることによる熱出力の増加を犠牲にして、はるかに高いパケット・レートを可能にすることができる。ＤＰＤＫ技術はまた、ＣＰＵコア・マネジメント、ロックフリー・キュー、メモリ・プール及び同期プリミティブを含むパケット処理ツールを提供することができる。図２４に示すように、ＤＰＤＫ技術では、専用のＣＰＵコア６００を個々の特別なタスクに使用することができる。そして、作業は非停止キュー６０２を用いてあるＣＰＵコア６００Ａから別のＣＰＵコア６００Ｂに渡される。
ＤＰＤＫキュー６０２は高速の２の累乗リング・バッファを用いて実装され、単一及び多数の生産者／消費者のバリアントを支援することができる。この多数の生産者／消費者のバリアントは比較交換（ＣＡＳ）ループを含んでアクセスを同期させるので、真にロック・フリーではない。パケット・バッファ・メモリはすべて、バッファへのポインタだけがキュー６０２に読み書きされるようにメモリ・プール内にあらかじめ割り当てることができる。メモリ・プールは、キューとして実装することができ、最適化してメモリ・チャンネルとランク全体にわたって分散させることができ、不均等メモリ・アクセス（ＮＵＭＡ）で最適化された割り当てをサポートすることができる。少なくともいくつかの実施形態では、パケット・バッファは、各パケット・バッファ内に十分なヘッドルーム及びテイルルームを過剰に割り当てて、バッファのコピーを必要とせずに外部ネットワーク層のヘッダを追加／削除することができるカプセル化／デカプセル化の操作をサポートするエムバフ（Ｍｂｕｆ）パラダイムなどの方法を用いることができる。
ロード・バランサ・ノード１１０の少なくともいくつかの実施形態では、ＤＰＤＫ技術を活用するコア・パケット処理アーキテクチャを実装することができる。各ロード・バランサ・ノード１１０は、コア・パケット処理アーキテクチャにより実装された少なくとも１つの多重コア・パケット・プロセッサを含むことができる。コア・パケット処理アーキテクチャは、多重コア・パケット・プロセッサのキュー及びコアによって単一生産者／単一消費者のパラダイムをパケット・フローに用いることができる。このパラダイムでは、各キューは、それがパケットを供給するコアを唯一のコアに入力し、各コアはそれがパケットを供給するコアを唯一のコアに互いに出力する。加えて、多重コア・パケット・プロセッサ内のコアが使用するメモリは共有されない。すなわち、各コアは固有の分離したメモリ領域を有している。したがって、コア間でのメモリまたはキューの共有はなく、メモリまたはキューのコンテンションはなく、かつ、所有権の要求（ＲＦＯ）または比較交換（ＣＡＳ）などのメモリまたはキューを共有するメカニズムの必要性はない。図２５、２６は、コア・パケット処理アーキテクチャにより実装された多重コア・パケット・プロセッサの例を示す。
図２５は、少なくともいくつかの実施形態による、データ・フロー処理にＤＰＤＫ技術を活用するコア・パケット処理アーキテクチャにより実装された多重コア・パケット・プロセッサの例を示す。コア・パケット処理アーキテクチャは、単一生産者／単一消費者のパラダイムによる多重コア・パケット・プロセッサとして実装することができる。少なくともいくつかの実施形態では、図２３に示すように、ロード・バランサ・ノード１１０は各々２つのネットワーク・インターフェイス・コントローラ（ＮＩＣ）、すなわち、境界ネットワーク／エッジ・ルータ１０４に面する北向きＮＩＣ１１１４Ａと生産ネットワーク／サーバ・ノード１３０に面する南向きＮＩＣ１１１４Ｂ、を有する。少なくともいくつかの実施形態では、ＮＩＣ１１１４は１０ＧｐｂｓＮＩＣであってよい。ロード・バランサ・ノード１１０を通って流れる大多数のパケットは、これらの２つのＮＩＣのうちの１つ（ＮＩＣ１１１４ＡまたはＮＩＣ１１１４Ｂのいずれか）で受け取られ、処理され（例えば、カプセル化されるか、またはデカプセル化される)、そして、他のＮＩＣ（ＮＩＣ１１１４ＢまたはＮＩＣ１１１４Ａのいずれか）に送信される。
図２５を参照すると、少なくともいくつかの実施形態では、ロード・バランサ・ノード１１０は、各ＮＩＣ１１１４に対して、２つのＣＰＵコア、受信（ＲＸ）コア６１０および送信（ＴＸ）コア６３０に回転をつける。ロード・バランサ・ノード１１０はまた、両方向の両ＮＩＣ１１１４のパケットを処理するいくつかのワーカ・コア６２０にも回転をつけ、この例では、ワーカ・コア６２０Ａ〜６２０Ｄが使用されている。受信コア６１０はそれらの入力キューからの着信パケット群がＮＩＣ１１１４に到達したときこれらを読み、各パケットに対する作業のほとんどを行うワーカ・コア６２０にこれらのパケットを分散させるが、その際、各受信コア６１０は各ワーカ・コア６２０のそれぞれのワーカ入力キュー６１２にパケットを供給する。少なくともいくつかの実施形態では、受信コア６１０は、いかなる特別なクライアント接続（そのＩＰアドレスとポートによって区別される）も同じワーカ・コア６２０で処理されることを保障しつつ各着信パケットに４層「フロー・ハッシュ」技法（以前に説明したような、エッジ・ルータ１０４が用いることができるフロー単位ハッシュ化多重パス経路指定技法に類似）を実施してワーカ・コア６２０にパケットを分散させることができる。これは、各ワーカ・コア６２０がパケットの同じサブセットを常に見ることができ、ロックを必要としないように、ワーカ・コア６２０によって管理されたステート・データ上のコンテンションを除去することを意味する。受信パケットへのポインタは、ワーカ・コア６２０が絶えず新しい入力をモニターするワーカ・キュー６２２全体にわたって分散させることができる。ワーカ・コア６２０は、各接続の状態（例えば、指定されたサーバ・ノード１３０）を管理する責任を負い、パケットを自身のアウトバウンド・キュー６３２の１つに転送する前にパケットのＵＤＰカプセル化またはデカプセル化を行うことができる。送信コア６３０は、ワーカ・コア６２０のアウトバウンド・キュー６３２を巡回して出力パケットがキュー６３２上に現れるときにこの出力パケットを自身の対応するＮＩＣ１１１４に記入する。
図２６は、少なくともいくつかの実施形態による、データ・フロー処理のＤＰＤＫ技術を活用するコア・パケット処理アーキテクチャによって実装された別の多重コア・パケット・プロセッサの例を示す。コア・パケット処理アーキテクチャは、単一生産者／単一消費者のパラダイムによる多重コア・パケット・プロセッサとして実装することができる。少なくともいくつかの実施形態では、高スループット・クライアントＴＣＰフローの処理に加えて、ロード・バランサ・ノード１１０に関するＤＰＤＫコア・アーキテクチャはまた、ＡＲＰ、ＤＨＣＰ及びＢＧＰなどの他のプロトコルの場合に北及び南に面するＮＩＣ１１１４上でパケットを送受信するために使用することもできる。図２６に示される実施形態では、ワーカ・コア６２０Ａはこれら他のプロトコルの場合のパケットの取り扱いに専念する。これらのパケットの処理が一般にクライアントＴＣＰフローの処理よりゆっくりと起こるので、このワーカ・コア６２０Ａを「遅い」ワーカ・コアと呼ぶ場合があり、一方、クライアントＴＣＰフローのみを処理する他のワーカ・コア６２０Ｂ−６２０Ｄを速いワーカ・コアと呼ぶ場合がある。北に面するＮＩＣ１１１４及び南に面するＮＩＣ１１１４上の着信パケットを取り扱う受信コア６１０Ａ及び受信コア６１０Ｂは、それぞれ、遅いワーカ・コア６２０Ａで取り扱われるべきパケットを識別し、これらのパケットを遅いワーカ・コア６２０Ａの入力キュー６２２に向けることができる。遅いワーカ・コア６２０Ａはまた、Ｊａｖａ／ＪＮＩによって生成されたパケットの入力キュー６２２及びＪａｖａ／ＪＮＩへの出力パケットの出力キュー６３４をモニターすることもできる。遅いワーカ・コア６２０Ａはまた、遅いワーカ・コア６２０Ａが、速いワーカ・コア６２０Ｂ〜６２０Ｄのそれぞれにパケット（例えば、接続公表パケット）を送ることができるように、速いワーカ・コア６２０Ｂ〜６２０Ｄのそれぞれの入力キュー６２２に出力もする。遅いワーカ・コア６２０Ａはまた、送信コア６３０Ａ及び６３０Ｂのそれぞれに配給されるアウトバウンド・キュー６３２も有している。
少なくともいくつかの実施形態では、速いワーカ・コア６２０Ｂ〜６２０Ｄそれぞれの第三の入力キュー６２２は、遅いワーカ・コア６２０Ａからの出力キューである。少なくともいくつかの実施形態では、この第三の入力キュー６２２は、例えば、それぞれが接続状態情報を含む接続公表パケットを速いワーカ・キュー６２０Ｂ〜６２０Ｄが受信し処理するのに用いることができる。これらの接続公表パケットの少なくともいくつかに関しては、送信コア６３０への出力が存在しない場合がある。その代わり、パケット内の接続状態情報は、速いワーカ・コア６２０により、例えば、それぞれの速いワーカ・コア６２０が維持する格納された１つまたは複数のパケット・フローの状態を更新するのに消費される場合がある。したがって、速いワーカ・コア６２０Ｂ〜６２０Ｄに入力する、遅いワーカ・コア６２０Ａからの出力キューは、入力キュー６２２以外の、速いワーカ・コアに格納された状態を更新する受信コア６１０からの直接的な経路を提供することができる。
少なくともいくつかの実施形態では、図２５、２６の多重コア・パケット・プロセッサは、着信パケットにフィルターをかけ、有効なパケットだけを処理し出力することができる。例えば、少なくともいくつかの実施形態では、受理コア６１０は、パケットにフィルターをかけてワーカ・コア６２０のどれにも支援されないプロトコルのパケットを取り除き、これらのパケットがワーカ・コア６２０に送られないようにすることができる。少なくともいくつかの実施形態では、ワーカ・コア６２０はそれぞれ、パケットを処理する際に、それぞれのワーカ入力キュー６２２から読んだパケットを先ず分析してこれらのパケットを更に処理して送信コア６３０に出力することが受理されるかどうかを判断し、受理されたパケットの処理及び送信コア６３０への出力のみを終了し、受理されないパケットを廃棄することができる。例えば、ワーカ・コア６２０は各パケットのアドレス情報を見て、負荷分散された有効なアドレスで標的とされたパケットのみを受理し、他のいかなるパケットも廃棄することができる。
境界ゲートウェイ・プロトコル（ＢＧＰ）データの取り扱い
少なくともいくつかの実施形態では、コア・アーキテクチャの中外でＢＧＰクライアントに関連したパケット・フローは、以下のように扱うことができる。ＮＩＣ１１１４Ａ及び１１１４Ｂは、リナックス・カーネルに結合していないので、エッジ・ルータ１０４へのＴＣＰ接続は、図２６に示すようなコア・アーキテクチャによって傍受され、出力キュー６３４経由でＢＧＰパケットをジャバ空間に伝える遅いワーカ・コア６２２Ａによって処理される。これらのＴＣＰパケットは、ＴＣＰ接続を管理しパケットを効果的にＴＣＰストリーム内に移動させるためのリナックス・カーネルによる処理を含んで、ＢＧＰクライアントに送達される前にロード・バランサ・ノード１１０上の１つまたは複数のモジュールによってさらに処理される。このデザインにより、標準的なジャバＴＣＰソケット・ライブラリを用いてＢＧＰクライアントを書くことが可能になる。
図２７は、少なくともいくつかの実施形態にしたがう、ロード・バランサ（ＬＢ）ノード・プロセス６５０による着信ＢＧＰ ＴＣＰパケットの処理を示す。エッジ・ルータ１０４からのパケットは北に面するＮＩＣ６４０に到着し、受信コア６５２の入力キュー６４０に入る。受信コア６５２は、キュー６４０からのパケットを読み、このパケットをＢＧＰパケットとして識別し、遅いワーカ・コア６５６の入力キュー６５４にパケットを載置する。遅いワーカ・コア６５６はパケットを認証し、ＪＮＩ出力キュー６５８にそれを載置する。ＪＮＩパケットのレシーバ６６０はＪＮＩを介してキュー６５８からのパケットを読み、ソース／宛先アドレスをマングリングし、パケットをロウ（ｒａｗ）ソケット６４４に書きこむ。リナックス・カーネル６４６は、ロウ（ｒａｗ）パケットを受信し、それをＴＣＰプロトコルにより取り扱い、ペイロード・データをＴＣＰソケットの入力ストリームに追加する。パケットからのデータは、その後、ＢＧＰクライアント６６２内のジャバＴＣＰソケットに送達される。
図２８は、少なくともいくつかの実施形態による、ロード・バランサ（ＬＢ）ノード・プロセス６５０による発信ＢＧＰ・ＴＣＰパケットの処理を示す。ＢＧＰクライアント６６２はリナックス・カーネル６４６のジャバＴＣＰソケットにデータを書きこむ。リナックス・カーネル６４６はＴＣＰプロトコルによってデータを取り扱い、データをＴＣＰパケットに変換する。少なくともいくつかの実施形態では、ＴＣＰパケットは１２７．ｘ．ｘ．ｘ ｉpｔａｂｌｅｓ規則と一致する。ＴＣＰパケットは出力キュー６４８、例えば、Ｎｅｔｆｉｌｔｅｒ ＬＯＣＡＬ＿ＯＵＴキューに載置される。ＪＮＩを介してキュー６４８をモニターするＪＮＩパケット・レシーバ６７０のジャバ・スレッドは、ＴＣＰパケットを受信し、各ＮＦ＿ＳＴＯＬＥＮをマークしてカーネル６４６にそれらを忘れさせる。ジャバ・スレッドは、ソース／宛先アドレスをマングリングし、ＪＮＩを介して遅いワーカ・コア６５６のＪＮＩ入力キュー６７２にパケットを加える。遅いワーカ・コア６５６はそのＪＮＩ入力キュー６７２からＴＣＰパケットを受信し、このパケットを北に面するＮＩＣ６４０の送信コア６６６のアウトバウンド・キュー６６４に載置する。送信コア６６６はその入力キュー６６４からＴＣＰパケットを読み取り、それらを北に面するＮＩＣ６４０に書き込む。ＴＣＰパケットはＮＩＣ６４０によりエッジ・ルータ１０４に送られる。
分散型ロード・バランサのシミュレーション及びテスト
本明細書に記述されたロード・バランサは、多くの独立したコンポーネント（例えば、ルータ、ロード・バランサ・ノード、ロード・バランサ・モジュールなど）の相互作用を必要とする分散型システムである。分散されたコンポーネント、ロジック、プロトコルのテストを行ない、かつ、ノード故障、メッセージ欠落、遅延などのシナリオをシュミュレートするために、複雑なネットワーク技術（例えば、生産ネットワーク）における多数のホストに設置すべきコードを必要とせずに相互作用をテストできる単一のプロセスで分散型ロード・バランサを動作させることができるテスト・システムの実施形態が記述される。これを達成するために、ロード・バランサの多数のコンポーネントが構成され、単一のプロセスでまたは単一のプロセスとして実行されることが可能となるメッセージ・バスと呼ばれるソフトウェア・メカニズムが記述される。この単一のプロセスは単一のホスト・システム上で実行することができる。メッセージ・バスのメカニズムは、分散型ロード・バランサ・システムを、例えば、単一のホスト・システム上で、単一のシステムとしてテストできるようにする。一方、ロード・バランサのコンポーネント（例えば、ロード・バランサ・ノード及びロード・バランサ・モジュール）に対しては、これらのコンポーネントは実際の生産ネットワーク上で動作するように見える。
メッセージ・バスは、分散型ロード・バランサが単一のプロセスとして動作できるようにする枠組みを提供する。このプロセスでの１つまたは複数のメッセージ・バス層のそれぞれは、分散型ロード・バランサのコンポーネント間のネットワーク（例えば、イーサネット）セグメントをシミュレートする。分散型ロード・バランサ・システムのソフトウェア・コンポーネントは、コンポーネントがメッセージ・バス環境で動作できるようにするために特別な様式で書かれる必要はない。代わりに、メッセージ・バスの枠組みでは、分散型ロード・バランサ・システムのコンポーネントが生成するパケットを傍受し、実際の物理的なネットワークではなくメッセージ・バス層によって提供されるシミュレートされたネットワークにパケットを向け、標的のコンポーネント＜メッセージ・バスＮＩＣまたはパケット・アダプタと処され得る）にパケットを送達する。メッセージ・バス層は、コンポーネント間の通信用のＴＣＰ／ＩＰスタックを実装しない。代わりに、メッセージ・バス層は、ホスト・システムのオペレーティングシステム（ＯＳ）とインターフェイス接続し、ホスト・システムのＴＣＰ／ＩＰスタックを使用する。メッセージ・バス層は、ＯＳによって提供されるＴＣＰ／ＩＰスタックを利用して、クライアントとサーバが予測するＴＣＰストリームをメッセージ・バスが傍受して送達する個々のパケットに変換し、かつそれらのパケットから変換する。
少なくともいくつかの実施形態では、メッセージ・バスとインターフェイス接続するために、ロード・バランサのコンポーネントが、それぞれが有効なメディア・アクセス・コントロール（ＭＡＣ）アドレスを有しており、物理的なネットワークではなくメッセージ・バス擬似ネットワーク環境にパケットを送信し、そこからパケットを受信する少なくとも１つのメッセージ・バス・ネットワーク・インターフェイス・コントローラ（ＮＩＣ）を備えることができる。メッセージ・バスＮＩＣは、物理的なネットワークにではなくメッセージ・バスに取り付けられた仮想のネットワーク・インターフェイス・コントローラである。メッセージ・バスによって通信する必要のあるロード・バランサのコンポーネントは、それぞれ、少なくとも１つのメッセージ・バスＮＩＣを必要とする。メッセージ・バスＮＩＣは、メッセージ・バスへのパイプライン出口及びコンポーネントへのパイプライン入口の働きをする。コンポーネントは、各メッセージ・バスＮＩＣに対する多数のメッセージ・バス・ネットワーク・インターフェイスを実証することができる。
メッセージ・バス・ネットワーク・インターフェイスは、コンポーネントがメッセージ・バスＮＩＣを介してメッセージ・バスに結合するメカニズムである。メッセージ・バス・ネットワーク・インターフェイスは、メッセージ・バス・ネットワーク・インターフェイスが物理的なネットワークにではなくメッセージ・バスに結合するという違いはあるが、リナックス技術でのインターフェイス構成（ｉｆｃｏｎｆｉｇ）インターフェイスと同意語であり得る。メッセージ・バス・ネットワーク・インターフェイスは、ＩＰアドレスを有しており、メッセージ・バスＮＩＣの上に位置する。メッセージ・バス・ネットワーク・インターフェイスは、コンポーネントがメッセージ・バスからパケットを受け取るために使用することができるパケット・ソース・インターフェイスと、コンポーネントがメッセージ・バスにパケットを送るために使用することができるパケット・シンク・インターフェイスとを露出させる。
各ロード・バランサ・ノードは、パケット・ソース・インターフェイスとパケット・シンク・インターフェイスの実装によって送達され送られた個々のネットワーク・パケットを処理する。メッセージ・バス環境内で動作するときは、これらのインターフェイスは、２層イーサネット・ヘッダ（これがカーネル・ネットワーク・スタックによって行なわれることを予測するロード・バランサ・ノードの）を追加または除去するメッセージ・バス・ネットワーク・インターフェイスによって実装される。図２９に示すような生産環境では、パケット・ソース・インターフェイスとパケット・シンク・インターフェイスの実装で、実際のネットワーク・インターフェイス上でパケットを送受信する。図３０に示すようなメッセージ・バス環境では、パケット・ソース・インターフェイスとパケット・シンク・インターフェイスの実装で、メッセージ・バス層からパケットを受信し、メッセージ・バス層にパケットを送信する。
単純化のために、メッセージ・バスＮＩＣ及びメッセージ・バス・インターフェイスをメッセージ・バス・パケット・アダプタ、または単にパケット・アダプタと総称することができる。例えば、図３１、３２を参照されたい。
図２９は、少なくともいくつかの実施形態による、生産環境での分散型ロード・バランサ７００を含むロード・バランシング・システムを示す。ロード・バランサ７００はこの説明では単純化されている。ロード・バランサ７００は、ロード・バランサ７００を実装するデータ・センタなどのネットワーク設備の境界ルータ７０２を介して外部ネットワーク７４０上のクライアント７４２と接続することができる。ロード・バランサ７００は、数種類のコンポーネント、すなわち、それぞれ分離したサーバ・ノード（図示せず）上に実装された、少なくとも１つのエッジ・ルータ７０４、２つまたはそれ以上のロード・バランサ（ＬＢ）ノード７１０、２つまたはそれ以上のロード・バランサ（ＬＢ）モジュール７３２、ルータまたはスイッチなどのファブリック７２０を形成する２つまたはそれ以上のネットワーク・コンポーネント、及び、少なくともいくつかの実施形態では、構成サービス７２２を、含む。少なくともいくつかの実施形態では、ロード・バランサ７００の各コンポーネントは、市販のラックマウント方式のコンピューティング・デバイスなどの個別のコンピュータとして実装することができ、または個別のコンピューティング・デバイス上に実装することができる。
図３０は、少なくともいくつかの実施形態による、分散型ロード・バランシング・システムの多数のコンポーネントが構成され単一のプロセスでまたは単一のプロセスとして実施できるようにするメッセージ・バス・メカニズムを組込んだ分散型ロード・バランサ評価システム８００を示す。図２９に示すロード・バランサ７００には、各ロード・バランサ・ソフトウェア・コンポーネントが別個のコンピューティング・デバイス（例えば、ロード・バランサ・ノード７１０上のロード・バランサ・ソフトウェア、及びサーバ・ノード上のロード・バランサ・モジュール７３２）にインストールされ実行される。これらのロード・バランサ・ソフトウェア・コンポーネントが単一のプロセスで実行できるようにするために、各ロード・バランサ・ソフトウェア・コンポーネント（図３０にロード・バランサ（ＬＢ）ノード８１０及びロード・バランサ（ＬＢ）モジュール８３２として示す）は、ロード・バランサ・ソフトウェアの内外のパケットも、物理的なネットワーク上に送受信されるのではなくメッセージ・バス・メカニズムによって傍受され経路指定され得るようにコンポーネントのネットワーク接続性を抽象化するコードを含むことができる。
少なくともいくつかの実施形態では、分散型ロード・バランサ・テスト・システム８００では、メッセージ・バス・メカニズムは、コンポーネント間の通信用のＴＣＰスタックを実装していない。代わりに、メッセージ・バス・メカニズムは、ホスト・システムのオペレーティング・システム（ＯＳ）とインターフェイス接続し、ホスト・システムのＴＣＰスタックを使用する。少なくともいくつかの実施形態では、メッセージ・バスの機能性は、ＩＰテーブルを介して、ユーザ層の下のホスト・システムのＯＳのカーネル（例えば、リナックス・カーネル）に、すなわち、カーネルの機能性に結合する。メッセージ・バスの機能性は、カーネルのレベルでＩＰテーブルに接続し、パケットを傍受し、経路指定用のメッセージ・バス・プロセスにこれらのパケットを送る。
図３０の擬似のエッジ・ルータ８６２及び擬似のファブリック８６４により示されるように、物理的なネットワーク・コンポーネント（例えば、図２９のエッジ・ルータ７０４及びファブリック７２０）の機能は、クライアント８６０、サーバ８３４及び構成サービス８６６ができるように、ソフトウェアの中でシミュレーションすることができる。しかし、少なくともいくつかの実施形態では、擬似ではない実際のサーバ８３４を、分散型ロード・バランサ・テスト・システム８００で使用することができることに留意されたい。図３０のメッセージ・バス層８５０は物理的なネットワーク・インフラに置き換わる。したがって、ロード・バランサ・ソフトウェア・コンポーネント（ロード・バランサ・ノード８１０及びロード・バランサ・モジュール８３２）は、図２９に示すような生産ネットワーク環境で実行していないことに気付かずにロード・バランサ・テスト・システム８００内で動作することができる。
いくつかのコンポーネント（例えば、擬似のルータ）は、ネットワーク・セグメントをシミュレーションする相異なるメッセージ・バス層８５０にパケットを渡しかつそれらのメッセージ・バス層８５０からパケットを受け取るために、２つ以上のメッセージ・バス層８５０に接続することができる。
分散型ロード・バランス・テスト・システム８００のメッセージ・バス層８５０に実装されたメッセージ・バス・メカニズムは、ネットワーク・セグメントの「ワイヤ」をシミュレーションする。少なくともいくつかの実施形態では、メッセージ・バス・メカニズムは、コンポーネントのＭＡＣアドレスに基づいて分散型ロード・バランス・テスト・システム８００の宛先コンポーネントにパケットを送達する。したがって、各ロード・バランサ・ソフトウェア・コンポーネント（ロード・バランサ・ノード８１０およびロード・バランサ・モジュール８３２）は、ロード・バランサ・ソフトウェア・コンポーネントが分散型ロード・バランス・テスト・システム８００の他のコンポーネントから送られたパケットを受信できるように接続されているメッセージ・バス層８５０にＭＡＣアドレスを提供する。
メッセージ・バス・パケット・アダプタ
図３１、３２は、少なくともいくつかの実施形態による、メッセージ・バス・パケット・アダプタを示す。少なくともいくつかの実施形態では、ロード・バランサ（ＬＢ）ソフトウェアの各コンポーネントは、パケット・ソース・インターフェイス及びパケット・シンク・インターフェイスの実装を通して送達され送られる個々のネットワーク・パケットを有している。図３１を参照すると、分散型ロード・バランス・テスト・システム８００で動作するとき、これらのインターフェイス（パケット・ソース・インターフェイス８６２及びパケット・シンク・インターフェイス８６４として示されている）は、メッセージ・バス層８５０とロード・バランサ・ソフトウェア・コンポーネント８７０の間のパケット・アダプタ８６０によって実装されることができる。このパケット・アダプタ８６０は、これがカーネル・ネットワーク・スタックによって行われると予測するロード・バランサ・ソフトウェア・コンポーネント８７０に対する２層イーサネット・ヘッダを加えるかまたは削除する。図２９に示すような生産環境では、ロード・バランサ・ソフトウェア・コンポーネントに対してパケット・ソース及びパケット・シンクを実装することにより、これらのコンポーネントが実装されている物理的なデバイスの実際のネットワーク・インターフェイス上のパケットが送受信される。
図３１を参照すると、少なくともいくつかの実施形態では、ロード・バランサ・ソフトウェア・コンポーネント８７０がパケットを送信するときに、パケット・シンク・インターフェイス８６４の送信パケット法を呼び出す実行スレッドは、パケット・アダプタ８６０内及びメッセージ・バス層８５０内の一連の機能を横切っていき宛先コンポーネントの入力キューにパケットを加えることにより最終的に宛先コンポーネントのパケットを送達する。少なくともいくつかの実施形態では、ロード・バランサ・ソフトウェア・コンポーネント８７０がパケットを受信するときに、ロード・バランサ・ソフトウェア・コンポーネント８７０はパケット・ソース・インターフェイス８６２の受信パケット法を呼び出し、その入力キューからパケットを読む。少なくともいくつかの実施形態では、メッセージ・バス・メカニズムは、パケットを送達するのに自身のどんな追加のスレッドも必要としない。
メッセージ・バス・パケット・パイプライン
図３２を参照すると、少なくともいくつかの実施形態では、パケット・ソース・インターフェイス８６２及びパケット・シンク・インターフェイス８６４のメッセージ・バス８５０側に、パケット・パイプラインのフィーチャーが提供される。ロード・バランサ・ソフトウェア・コンポーネント８７０がパケット・シンク・インターフェイス８６４を介してパケットを送信するとき、パケット・データはメッセージ・バス層８５０に到達する前に一連の段階（パケット・パイプライン８８０）を横切っていくことができる。これらの段階では、パケットを修正し、パケットを落とし、パケットを複製し、パケットを遅らせる等のことができる。一旦、パケットがパケット・パイプライン８８０を横切っていき、メッセージ・バス層８５０が宛先コンポーネント８７０を選択すると、パケットはまた、宛先コンポーネント８７０の入力キューに加えられる前に宛先コンポーネント８７０に関連した２番目の一連のパイプライン段階（パケット・パイプライン８８２）を横切っていくこともできる。
プロバイダ・ネットワーク環境の例
このセクションでは、分散型ロード・バランシングの方法及び装置の実施形態を実装することができるプロバイダ・ネットワーク環境について説明する。しかし、これらのプロバイダ・ネットワーク環境の例は、それらに限定することは意図されていない。
図３３Ａは、少なくともいくつかの実施形態による、プロバイダ・ネットワーク環境の例を示す。プロバイダ・ネットワーク１９００は、クライアントが、限定するものではないが、プロバイダ・ネットワーク内あるいは１つまたは複数のデータ・センタ内のデバイスに実装された計算リソース及びストレージ・リソースを含む仮想化されたリソースの実例１９１２にアクセスし、それを購入し、それを借り、または別の方法でそれを取得することができるようにする１つまたは複数の仮想化サービス１９１０を介して、クライアントにリソース仮想化を提供することができる。プライベートＩＰアドレス１９１６は、リソースの実例１９１２と関連付けることができ、プライベートＩＰアドレスは、プロバイダ・ネットワーク１９００上のリソース実例１９１２の内部ネットワーク・アドレスである。いくつかの実施形態では、プロバイダ１９００はまた、クライアントがプロバイダ１９００から得ることができるパブリックＩＰアドレス１９１４及び／またはパブリックＩＰアドレス領域（例えばインターネット・プロトコル・バージョン４（ＩＰｖ４）またはインターネット・プロトコル・バージョン６（ＩＰｖ６）のアドレス）も提供することができる。
従来は、プロバイダ・ネットワーク１９００は、仮想化サービス１９１０を介して、サービス・プロバイダのクライアント（例えばクライアント・ネットワーク１９５０Ａを運営するクライアント）がクライアントに割り当てられた少なくともいくつかのパブリックＩＰアドレス１９１４をクライアントに割り当てられた特別なリソース実例１９１２を結びつけることができるようにする。プロバイダ・ネットワーク１９００はまた、クライアントが、クライアントに割り当てられた１つの仮想化計算リソース実例１９１２に以前にマッピングされたパブリックＩＰアドレス１９１４を、クライアントに割り当てられた別の仮想化計算リソース実例１９１２に再マッピングすることができるようにする。サービス・プロバイダに提供された仮想化計算リソース実例１９１２とパブリックＩＰアドレス１９１４を用いて、クライアント・ネットワーク１９５０Ａのオペレータなどのサービス・プロバイダのクライアントは、例えば、クライアントに特有なアップリケーションを実装し、インターネットなどの中間ネットワーク１９４０上にクライアントのアプリケーションを提示することができる。中間のネットワーク１９４０上の他のネットワーク実体１９２０は、その後、クライアント・ネットワーク１９５０Ａによって公表された、宛先パブリックＩＰアドレス１９１４へのトラフィックを生成することができる。このトラフィックは、サービス・プロバイダ・データ・センタに経路指定され、このデータ・センタでネットワーク基板を介して宛先パブリックＩＰアドレス１９１４に現在マッピングされている仮想化計算リソース実例１９１２のプライベートＩＰアドレス１９１６に経路指定される。同様に、仮想化計算リソース実例１９１２からの応答トラフィックはネットワーク基板を介して中間ネットワーク１９４０に戻ってソース実体１９２０まで経路指定され得る。
本明細書で使用されるようなプライベートＩＰアドレスは、プロバイダ・ネットワークでのリソース・インスタンスの内部ネットワーク・アドレスを参照する。プライベートＩＰアドレスは、プロバイダ・ネットワーク内でのみ経路指定することができる。プロバイダ・ネットワークの外部に起因するネットワーク・トラフィックはプライベートＩＰアドレスに直接経路指定されず、代わりに、このトラフィックはリソース・インスタンスにマッピングされたパブリックＩＰアドレスを用いる。プロバイダ・ネットワークは、ネットワーク・アドレス変換（ＮＡＴ）または類似の機能を提供してパブリックＩＰアドレスからプライベートＩＰアドレスへのマッピング及びその逆も行うネットワーク・デバイスまたはアプライアンスを含むことができる。
本明細書で使用されるようなパブリックＩＰアドレスは、サービス・プロバイダまたはクライアントのどちらかによってリソース・インスタンスに割り当てられる、インターネット経路指定可能なネットワーク・アドレスである。パブリックＩＰアドレスに経路指定されたトラフィックは、例えば、１：１ネットワーク・アドレス変換（ＮＡＴ）を介して変換され、リソース・インスタンスのそれぞれのプライベートＩＰアドレスに転送される。
いくつかのパブリックＩＰアドレスを、プロバイダ・ネットワーク・インフラによって特別のリソース・インスタンスに割り当てることができ、これらのパブリックＩＰアドレスは、標準パブリックＩＰアドレスまたは単に標準ＩＰアドレスと呼ぶことができる。少なくともいくつかの実施形態では、標準ＩＰアドレスのリソース・インスタンスのプライベートＩＰアドレスへのマッピングは、リソース・インスタンス・タイプすべての初期立上げ構成である。
少なくともいくつかのパブリックＩＰアドレスはプロバイダ・ネットワーク１９００のクライアントに割り当てられるか、またはこのクライアントが獲得することができる。その後、クライアントはこれらの割り当てられたパブリックＩＰアドレスをクライアントに割り当てられた特別なリソース・インスタンスにあてがうことができる。これらのパブリックＩＰアドレスをクライアント・パブリックＩＰアドレス、または単にクライアントＩＰアドレスと呼ぶことができる。クライアントＩＰアドレスは、標準ＩＰアドレスの場合のようにプロバイダ・ネットワーク１９００によりリソース・インスタンスにあてがわれる代わりに、クライアントにより、例えば、サービス・プロバイダにより提供されたＡＰＩを介してあてがわれることができる。標準ＩＰアドレスとは異なり、クライアントＩＰアドレスは、それぞれのクライアントによりクライアント・アカウントに割り当てられ、必要に応じて、または望むなら、他のリソース・インスタンスに再マッピングされることができる。クライアントＩＰアドレスは特別のリソース・インスタンスにではなくクライアントのアカウントに関連付けられている。そして、クライアントがこのＩＰアドレスを手放すことを選択するまで、クライアントはこのＩＰアドレスをコントロールする。従来の静的なＩＰアドレスと異なり、クライアントＩＰアドレスは、クライアントがクライアントのアカウントに関連付けられた任意のリソース・インスタンスにクライアントのパブリックＩＰアドレスを再マッピングすることにより、リソース・インスタンスまたは利用可能ゾーンの故障を覆うことができるようにする。クライアントＩＰアドレスは、例えば、クライアントが、代替リソース・インスタンスにクライアントＩＰアドレスを再マッピングすることでクライアントのリソース・インスタンスまたはソフトウェアの問題を、巧みに処理できるようにする。
図３３Ｂは、少なくともいくつかの実施形態による、図３３Ａで示したプロバイダ・ネットワーク環境の例における分散型ロード・バランサの実装を示す。プロバイダ・ネットワーク１９００は、クライアント１９６０に、サービス１９１０、例えば、仮想化ストレージ・サービスを提供することができる。クライアント１９６０は、例えば、サービス１９１０への１つまたは複数のＡＰＩを介して、サービス１９１０にアクセスしてプロバイダ・ネットワーク１９００の生産ネットワーク部の複数のサーバ・ノード１９９０上に実装されたリソース（例えば、ストレージ・リソースまたは計算リソース）の利用を得ることができる。サーバ・ノード１９９０はそれぞれ、サーバ(図示せず)（例えば、ウェブ・サーバまたはアプリケーション・サーバ）、並びに、ローカル・ロード・バランサ（ＬＢ）モジュール１９９２を実装することができる。１つまたは複数の分散型ロード・バランサ１９８０は、境界ネットワークと生産ネットワークの間のロード・バランサ層に実装することができる。境界ルータ１９７０は、インターネットなどの中間ネットワーク１９４０を介して、クライアント１９６０からのパケット・フローのパケット（例えば、ＴＣＰパケット）を受信し、境界ネットワークを介して分散型ロード・バランサ１９８０のエッジ・ルータにこれらのパケットを転送することができる。パケットは、分散型ロード・バランサ１９８０のエッジ・ルータによって公表されたパブリックＩＰアドレスを標的にすることができる。各分散型ロード・バランサ１９８０のエッジ・ルータは、分散型ロード・バランサ１９８０それぞれのロード・バランサ・ノード間にパケット・フローを分散させることができる。少なくともいくつかの実施形態では、入口ノードとして働くロード・バランサ・ノードはそれぞれ、同じパブリックＩＰアドレスをエッジ・ルータに広告し、エッジ・ルータは、クライアント１９６０からのパケット・フローを、フロー単位ハッシュ化多重パス経路指定技法（例えば、等コスト多重パス（ＥＣＭＰ）ハッシング技法）により、入口サーバ間に分散させる。ロード・バランサ・ノードは、本明細書で説明した接続プロトコルを用いてパケット・フローの標的サーバ・ノード１９９０を決定し、サーバとクライアント１９６０の間の接続を促すことができる。一旦接続が確立されれば、入口ノードは、フロー・トラッカ・ノードが接続の状態を維持する間に、生産ネットワーク上の標的サーバ・ノード１９９０へのフロー用に受信したパケットをカプセル化し送信する。サーバ・ノード１９９０上のロード・バランサ・モジュール１９９２は、サーバ・ノード１９６０上のそれぞれのサーバが接続を受理するかどうかについての決定を行うことができる。ロード・バランサ・モジュールは入口ノードからパケットを受信してデカプセル化し、サーバ・ノード１９９０上のそれぞれのサーバにデカプセル化したパケット（例えば、ＴＣＰパケット）を送信する。ロード・バランサ・モジュール１９９２はまた、パケット・フローの出口ノードとしてロード・バランサ・ノードを選択し、生産ネットワークを介して、選択した出口ノードにフローの発信パケットを送信することもできる。出口ノードは、次に、パケットをデカプセル化し、それぞれのクライアント１９６０に送達するためにデカプセル化パケットを境界ネットワークに送信する。
図３４Ａは、少なくともいくつかの実施形態による分散型ロード・バランサ及びサーバ・ノードの物理的なラック実装の例を示すが、これに限定する意図はない。少なくともいくつかの実施形態では、分散型ロード・バランサの様々なコンポーネントを市販のラック・マウント方式のコンピューティング・デバイス上にまたはかかるコンピューティング・デバイスとして実装することができる。ラック１９０は、それぞれロード・バランサ・ノード（ＬＢノード１１０Ａ〜１１０Ｆ）として働く複数のコンピューティング・デバイス及びそれぞれサーバ・ノード（サーバ・ノード１３０Ａ〜１３０Ｌ）として働く複数のコンピューティング・デバイスを含むことができる。ラック１９０はまた、少なくとも１つのエッジ・ルータ１０４、ファブリック１２０を形成する１つまたは複数のラックマウント方式のネットワーキング・デバイス（ルータ、スイッチなど）、及び１つまたは複数の他のコンポーネント１８０（他のネットワーキング・デバイス、パッチパネル、電源、冷却システム、バスなど）も含むことができる。図３３Ａ、３３Ｂのプロバイダ・ネットワーク１９００を実装する１つまたは複数のデータ・センタなどのネットワーク１００の設備は１つまたは複数のラック１９０を含むことができる。
図３４Ｂは、少なくともいくつかの実施形態による分散型ロード・バランサ及びサーバ・ノードの物理的なラック実装の別の例を示すが、これに限定する意図はない。図３４Ｂは、スロット・マウント方式のコンピューティング・デバイス、例えば、ラック１９０内のブレード・サーバとして実装されたＬＢノード１１０及びサーバ・ノード１３０を示す。
図３５は、少なくともいくつかの実施形態による、サーバ・ノードが別個に実装されて１つ、２つまたはそれ以上の分散型ロード・バランサがネットワークに実装できるネットワーキング環境の例を示す。この例では、２つの分散型ロード・バランサ１９８０Ａ、１９８０Ｂが示されている。分散型ロード・バランサ１９８０はそれぞれ、境界ネットワークを介してクライアント１９６０からパケット・フローを受信し、本明細書で説明したロード・バランシング法を行って複数のサーバ・ノード１９９０全体にわたってパケット・フローを分散させることができる。いくつかの実装形態では、各分散型ロード・バランサ１９８０は図３４Ａ、３４Ｂに示したラック１９０に類似しているが、ロード・バランサ・ラックに取り付けられたサーバ・ノードがないラック実装形態であり得る。サーバ・ノード１９９０は、データ・センタ内の１つまたは複数の別個のラックに取り付けられたブレード・サーバなどのラックマウント方式のコンピューティング・デバイスでよい。いくつかの実装形態では、サーバ・ノード１９９０は、プロバイダ・ネットワークによって提供される２つ以上の異なるサービスを実装することができ、各サービスは異なる１つまたは複数のロード・バランサ１９８０よって率いられる。
例示的システム
少なくともいくつかの実施形態では、本明細書で説明したような分散型ロード・バランシングの方法及び装置の一部またはすべてを実装するサーバは、図３６に示したようなコンピュータ・システム２０００などの１つまたは複数のコンピュータ・アクセス可能なメディアを含むか、または、かかるメディアにアクセスするように構成された汎用コンピュータ・システムを含むことができる。例示した実施形態では、コンピュータ・システム２０００は、入出力（Ｉ／Ｏ）インターフェイス２０３０を介してシステム・メモリ２０２０に結合した１つまたは複数のプロセッサ２０１０を含む。コンピュータ・システム２０００は、Ｉ／Ｏインターフェイス２０３０に結合したネットワーク・インターフェイス２０４０をさらに含む。
様々な実施形態では、コンピュータ・システム２０００は、１つのプロセッサ２０１０を含むユニプロセッサ・システム、または数個（例えば２、４、８個またはその他の適切な個数）のプロセッサ２０１０を含む多重プロセッサ・システムであってよい。プロセッサ２０１０は命令を実行することができる任意の適切なプロセッサであってよい。例えば、様々な実施形態では、プロセッサ２０１０は、ｘ８６、パワーＰＣ、ＳＰＡＲＣ、またはＭＩＰＳ・ＩＳＡなどの様々な任意の命令セット・アーキテクチャ（ＩＳＡ）、あるいは他の任意の適切なＩＳＡを実装している汎用プロセッサまたは埋め込みプロセッサであってよい。重プロセッサ・システムでは、各プロセッサ２０１０は、必ずではないが、通常、同じＩＳＡを実装することができる。
システム・メモリ２０２０は、プロセッサ２０１０によりアクセス可能な命令及びデータを格納するように構成することができる。様々な実施形態では、システム・メモリ２０２０は、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ）、シンクロナス・ダイナミックＲＡＭ（ＳＤＲＡＭ）、不揮発性／フラッシュ型メモリ、または、他の任意のタイプのメモリなどの任意の適切なメモリ技術を用いて実装され得る。例示した実施形態では、分散型ロード・バランシングの方法と装置につき上記で説明した方法、技術、及びデータの機能などの１つまたは複数の所望の機能を実装するプログラム命令及びデータが、システム・メモリ２０２０内にコード２０２４及びデータ２０２６として格納されて示されている。
１つの実施形態では、Ｉ／Ｏインターフェイス２０３０は、プロセッサ２０１０、システム・メモリ２０２０、及び、ネットワーク・インターフェイス２０４０または他の周辺インターフェイスを含むデバイス内の任意の周辺デバイスの間のＩ／Ｏトラフィックを調整するように構成することができる。いくつかの実施形態では、Ｉ／Ｏインターフェイス２０３０は、いかなる必要なプロトコル、タイミングまたは他のデータの変換も実行して、１つのコンポーネント（例えば、システム・メモリ２０２０）からのデータ信号を別のコンポーネント（例えば、プロセッサ２０１０）が用いるのに適したフォーマットに変換することができる。いくつかの実施形態では、例えば、Ｉ／Ｏインターフェイス２０３０は、例えば、周辺装置相互接続（ＰＣＩ）バス標準または汎用シリアル・バス（ＵＳＢ）標準の変形などの様々なタイプの周辺バスを通して取り付けられたデバイス用のサポートを含むことができる。いくつかの実施形態では、Ｉ／Ｏインターフェイス２０３０の機能を、例えば、北ブリッジ及び南ブリッジなどの１つまたは複数の別個のコンポーネントに分割することができる。また、いくつかの実施形態では、システム・メモリ２０２０に対するインターフェイスなどのＩ／Ｏインターフェイス２０３０の機能のいくつかまたはすべてを直接プロセッサ２０１０に組み込むこともできる。
ネットワーク・インターフェイス２０４０は、例えば、図１〜３５で説明したような他のコンピュータシステムまたはデバイスのような、ネットワーク２０５０に取り付けられたコンピュータ・システム２０００及び他のデバイス２０６０の間でデータが交換されることを可能とするよう構成されてよい。様々な実施形態において、ネットワーク・インターフェイス２０４０は、例えば、イーサネット・ネットワークのタイプのような、任意の適切な有線若しくは無線の一般データ・ネットワークを介した通信をサポートすることができる。加えて、ネットワーク・インターフェイス２０４０は、アナログ・ボイス・ネットワーク若しくはディジタル・ファイバー・コミュニケーション・ネットワークのようなテレコミュニケーション／テレフォニー・ネットワーク、ファイバー・チャンネル・ＳＡＮのようなストレージ・エリア・ネットワーク、または、任意の他の適切なタイプのネットワーク及び／またはプロトコル、を介した通信をサポートすることができる。
いくつかの実施形態では、システム・メモリ２０２０は、分散型ロード・バランシング・システムの実施形態の実装に対して上記で図１〜３５につき説明したようなプログラム命令及びデータを格納するように構成されたコンピュータ・アクセス可能な媒体の一実施形態でよい。しかし、他の実施形態では、プログラム命令及び／またはデータを、異なるタイプのコンピュータ・アクセス可能な媒体で受信し、かかる媒体に送信し、またはかかる媒体に格納することができる。一般的にいえば、コンピュータ・アクセス可能な媒体は、磁気媒体または光学媒体（例えば、Ｉ／Ｏインターフェイス２０３０を介してコンピュータ・システム２０００に結合したディスク、またはＤＶＤ／ＣＤ）などの非一時的なストレージ媒体またはメモリ媒体を含むことができる。非一時的なコンピュータ・アクセス可能なストレージ媒体はまた、コンピュータ・システム２０００のいくつかの実施形態でシステム・メモリ２０２０または別のタイプのメモリとして含むことができるＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭなどの任意の揮発性または不揮発性の媒体を含むこともできる。さらに、コンピュータ・アクセス可能な媒体は、伝送媒体または、ネットワーク・インターフェイス２０４０を介して実装できるようなネットワーク及び／または無線リンクなどの通信媒体を介して伝えられる電気信号、電磁気信号またはディジタル信号などの伝送信号を含むことができる。
本開示の実施形態は、以下の条項を考慮して説明することができる：
[項１]
１つまたは複数のクライアントからのパケット・フロー内のパケットを自身の単一のパブリックＩＰアドレスにより受信するように構成されたルータと、
複数のサーバ・ノードと、
前記分散型ロード・バランサ・システムの入口サーバとしてそれぞれ構成された複数のロード・バランサ・ノードと、
を含み、
前記入口サーバはすべて前記同じ単一のパブリックＩＰアドレスを前記ルータに広告し、
前記ルータは、さらに、前記パケット・フロー内の前記パケットのソース及び宛先アドレス情報に適用されたハッシュ化多重パス経路指定技法により前記複数の入口サーバ間に前記パケット・フローを分散させるように構成され、
各入口サーバは、さらに、前記ルータからの１つまたは複数のパケット・フロー内のパケットを受信し、前記パケット・フローのそれぞれにマッピングされた１つまたは複数の前記サーバ・ノードに前記パケットを分散させる、分散型ロード・バランサ・システム。
[項２]
前記ハッシュ化多重パス経路指定技法が、等コスト多重パス（ＥＣＭＰ）経路指定技法である、項１に記載された分散型ロード・バランサ・システム。
[項３]
各ロード・バランサ・ノードが１つまたは複数の他のロード・バランサ・ノードにより前記ルータに広告される、項１に記載された分散型ロード・バランサ・システム。
[項４]
前記１つまたは複数の他のロード・バランサ・ノードのそれぞれが前記ルータと境界ゲートウェイ・プロトコル（ＢＧＰ）セッションを確立して前記ロード・バランサ・ノードを前記ルータに広告する、項３に記載された分散型ロード・バランサ・システム。
[項５]
前記ロード・バランサ・ノードを前記ルータに広告する前記１つまたは複数の他のロード・バランサ・ノードのそれぞれがさらに、
前記ルータに広告されている前記ロード・バランサ・ノードが故障したことを検出し、
前記検出に応答して、前記ロード・バランサ・ノードを前記ルータに広告するＢＧＰセッションを終了する、
ように構成されている、項４に記載された分散型ロード・バランサ・システム。
[項６]
前記ルータが、さらに、前記１つまたは複数の他のロード・バランサ・ノードがＢＧＰセッションを終了するのに応答して、前記ハッシュ化多重パス経路指定技法により前記複数の入口サーバの間に前記パケット・フローを再分散させるように構成された、項５に記載された分散型ロード・バランサ・システム。
[項７]
パケットの前記ソース及び宛先アドレス情報が、クライアントＩＰアドレス、クライアント・ポート、サーバ・パブリックＩＰアドレス、及びサーバ・ポートを含む、項１に記載された分散型ロード・バランサ・システム。
[項８]
ルータで、パブリックＩＰアドレスにより１つまたは複数のクライアントからのパケット・フロー内のパケットを受信することと、
前記ルータで、前記パケット・フロー内の前記パケットのソース及び宛先アドレス情報に適用されたハッシュ化多重パス経路指定技法により複数のロード・バランサ・ノード間に前記パケット・フローを分散させ、ここで、複数のロード・バランサ・ノードが１つまたは複数のＩＰアドレスを共有し、することと、
前記１つまたは複数のロード・バランサ・ノードのそれぞれで、前記ルータから受信した１つまたは複数のパケット・フロー内の前記パケットを、前記それぞれのパケット・フローにマッピングされた複数のサーバ・ノードのうちの複数のサーバ・ノードのうちの１つまたは複数のサーバ・ノードに分散させることと、
を含む、
方法。
[項９]
前記ハッシュ化多重パス経路指定技法が、等コスト多重パス（ＥＣＭＰ）経路指定技法である、項８に記載された方法。
[項１０]
各ロード・バランサが他の少なくとも１つのロード・バランサ・ノードを前記ルータに広告することをさらに含み、各ロード・バランサ・ノードは、１つまたは複数の前記他のロード・バランサ・ノードによって前記ルータに広告される、項８に記載された方法。
[項１１]
ロード・バランサ・ノードを広告する前記１つまたは複数の他のロード・バランサ・ノードが、前記ロード・バランサ・ノードの特定の順序付けに従う前記ロード・バランサ・ノードの左右の隣接ロード・バランサ・ノードを含む、項１０に記載された方法。
[項１２]
前記広告が、前記ロード・バランサ・ノードが広告する他のそれぞれのロード・バランサ・ノードの前記ルータと境界ゲートウェイ・プロトコル（ＢＧＰ）セッションを確立する各ロード・バランサ・ノードから成る、請求項１０に記載された方法。
[項１３]
ロード・バランサ・ノードによって前記ルータに広告されている別のロード・バランサ・ノードが故障したことを前記ロード・バランサ・ノードで検出することと、
前記検出することに応答して、前記他のロード・バランサ・ノードを広告する前記ルータとの前記ＢＧＰセッションを終了することと、
をさらに含む、項１２に記載された方法。
[項１４]
前記ルータで、ロード・バランサ・ノードを広告する１つまたは複数のＢＧＰセッションが終了したと判断することに応答して、前記ハッシュ化多重パス経路指定技法により前記パケット・フローを前記複数のロード・バランサ・ノードの間に再分散させること、をさらに含む、項１３に記載された方法。
[項１５]
パケットの前記ソース及び宛先アドレス情報が、クライアントＩＰアドレス、クライアント・ポート、サーバＩＰアドレス、及びサーバ・ポートを含む、項８に記載された方法。
[項１６]
複数のロード・バランサ・ノードで、前記ロード・バランサ・ノードに共有されている１つまたは複数のパブリックＩＰアドレスをルータに広告することと、
前記ルータで、単一のパブリックＩＰアドレスにより１つまたは複数のクライアントからのパケット・フロー内のパケットを受信することと、
前記ルータで、前記パケット・フロー内の前記パケットのソース及び宛先アドレス情報に適用されたハッシュ化多重パス経路指定技法により複数のロード・バランサ・ノード間に前記パケット・フローを分散させることと、
１つまたは複数のロード・バランサ・ノードのそれぞれで、前記ルータから受信した１つまたは複数のパケット・フロー内の前記パケットを、複数のサーバ・ノードのうちの１つまたは複数のサーバ・ノードに分散させることと、
を実装するためのコンピュータ実行可能なプログラム命令を格納する、非一時的コンピュータ・アクセス可能なストレージ媒体。
[項１７]
前記広告において、各ロード・バランサー・ノードが、他のロード・バランサー・ノードの１つまたは複数により前記ルータに広告される、項１６に記載された非一時的コンピュータ・アクセス可能なストレージ媒体。
[項１８]
他のロード・バランサー・ノードの１つまたは複数のそれぞれが、前記ルータと境界ゲートウェイ・プロトコル（ＢＧＰ）セッションを確立して、前記ロード・バランサ・ノードを前記ルータに広告する、請求項１７に記載された非一時的コンピュータ・アクセス可能なストレージ媒体。
[項１９]
前記プログラム命令が、
ロード・バランサ・ノードによって前記ルータに広告されている別のロード・バランサ・ノードが故障したことを前記ロード・バランサ・ノードで検出することと、
前記検出することに応答して、前記他のロード・バランサ・ノードを広告する前記ルータとの前記ＢＧＰセッションを終了することと、
をさらに実装するためのコンピュータ実行可能なものである、項１７に記載された非一時的コンピュータ・アクセス可能なストレージ媒体。
[項２０]
前記プログラム命令が、前記ルータで、前記複数のロード・バランサ・ノードのうちの１つが前記他のロード・バランサ・ノードによって広告されていないと判断することに応答して、前記ハッシュ化多重パス経路指定技法により、前記パケット・フローを前記複数のロード・バランサ・ノードの間に再分散させることをさらに実装するためのコンピュータ実行可能なものである、項１７に記載された非一時的コンピュータ・アクセス可能なストレージ媒体。
結論
様々な実施形態は、先の説明に従って実装された命令及び／またはデータを、コンピュータ・アクセス可能な媒体上で、受信し、送信し、格納することをさらに含むことができる。一般的に言って、コンピュータ・アクセス可能な媒体は、例えば、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ等）などの揮発性または非揮発性媒体、ＲＯＭ等、並びに、ネットワーク及び／または無線リンクなどの通信媒体を介して伝えられる電気信号、電磁気信号またはディジタル信号などの伝送媒体または信号を含むことができる。
図で示され、本明細書で説明されたような様々な方法は、方法の例示的な実施形態を表わしている。これらの方法は、ソフトウェア、ハードウェアまたそれらの組合せで実装することができる。方法の順序は変えることができ、様々な要素を追加し、記録し、組み合わせ、省略し、修正する等のことが可能である。
本開示の利益を有する当業者なら明白であるはずであるが、本開示の様々な修正および変更を加えることができる。かかる修正及び変更のすべてが包含されることが意図されており、したがって、上記の説明は限定する意味ではなく例示的なものであるとみなすべきである。

Claims (13)

  1. 分散型ロード・バランサ・システムであって、
    １つまたは複数のクライアントからのパケット・フロー内のパケットを単一のパブリックＩＰアドレスにより受信するように構成されたルータと、
    複数のサーバ・ノードと、
    前記分散型ロード・バランサ・システムの入口サーバとしてそれぞれ構成された複数のロード・バランサ・ノードと、
    を含み、
    前記入口サーバはすべて同じ前記単一のパブリックＩＰアドレスを前記ルータに広告し、
    前記ルータは、さらに、前記パケット・フロー内の前記パケットのソース及び宛先アドレス情報に適用されたハッシュ化多重パス経路指定技法により前記複数の入口サーバ間に前記パケット・フローを分散させるように構成され、
    各入口サーバは、前記ルータによって前記入口サーバに分散されたそれぞれのパケット・フローのために、前記複数のサーバ・ノード間から前記パケット・フローを受信するサーバ・ノードを、ランダムに選択し、選択された前記サーバ・ノードへの前記パケット・フローのマッピングを維持するように構成され、
    前記ルータからの１つまたは複数のパケット・フロー内のパケットを受信し、前記パケット・フローのそれぞれにマッピングされた前記複数のサーバ・ノードの１つまたは複数に前記パケットを分散させ、
    各ロード・バランサ・ノードが１つまたは複数の他のロード・バランサ・ノードにより前記ルータに広告される、
    分散型ロード・バランサ・システム。
  2. 前記ハッシュ化多重パス経路指定技法が、等コスト多重パス（ＥＣＭＰ）経路指定技法である、請求項１に記載された分散型ロード・バランサ・システム。
  3. 前記１つまたは複数の他のロード・バランサ・ノードのそれぞれが前記ルータと境界ゲートウェイ・プロトコル（ＢＧＰ）セッションを確立して前記ロード・バランサ・ノードを前記ルータに広告する、請求項１に記載された分散型ロード・バランサ・システム。
  4. 前記ロード・バランサ・ノードを前記ルータに広告する前記１つまたは複数の他のロード・バランサ・ノードのそれぞれがさらに、
    前記ルータに広告されている前記ロード・バランサ・ノードが故障したことを検出し、
    前記検出に応答して、前記ロード・バランサ・ノードを前記ルータに広告するＢＧＰセッションを終了する、
    ように構成されている、請求項３に記載された分散型ロード・バランサ・システム。
  5. 前記ルータが、さらに、前記１つまたは複数の他のロード・バランサ・ノードが前記ＢＧＰセッションを終了するのに応答して、前記ハッシュ化多重パス経路指定技法により前記複数の入口サーバの間に前記パケット・フローを再分散させるように構成された、請求項４に記載された分散型ロード・バランサ・システム。
  6. パケットの前記ソース及び宛先アドレス情報が、クライアントＩＰアドレス、クライアント・ポート、サーバ・パブリックＩＰアドレス、及びサーバ・ポートを含む、請求項１に記載された分散型ロード・バランサ・システム。
  7. ルータで、パブリックＩＰアドレスにより１つまたは複数のクライアントからのパケット・フロー内のパケットを受信することと、
    前記ルータで、前記パケット・フロー内の前記パケットのソース及び宛先アドレス情報に適用されたハッシュ化多重パス経路指定技法により、１つまたは複数のＩＰアドレスを共有する複数のロード・バランサ・ノード間に前記パケット・フローを分散させることと、
    前記複数のロード・バランサ・ノードのそれぞれで、複数のサーバ・ノード間から、前記ルータによって対応する前記ロード・バランサ・ノードに分散されたそれぞれのパケット・フローを受信するサーバ・ノードを、ランダムに選択することと、選択された前記サーバ・ノードへの前記パケット・フローのマッピングを維持することと、
    前記複数のロード・バランサ・ノードのそれぞれで、前記ルータから受信した１つまたは複数のパケット・フロー内の前記パケットを、前記それぞれのパケット・フローにマッピングされた複数のサーバ・ノードのうちの１つまたは複数のサーバ・ノードに分散させることと、
    各ロード・バランサ・ノードが他の少なくとも１つのロード・バランサ・ノードを前記ルータに広告することをさらに含み、各ロード・バランサ・ノードは、１つまたは複数の前記他のロード・バランサ・ノードによって前記ルータに広告されること、
    を含む、
    方法。
  8. 前記ハッシュ化多重パス経路指定技法が、等コスト多重パス（ＥＣＭＰ）経路指定技法である、請求項７に記載された方法。
  9. ロード・バランサ・ノードを広告する前記１つまたは複数の他のロード・バランサ・ノードが、前記ロード・バランサ・ノードの特定の順序付けに従う前記ロード・バランサ・ノードの左右の隣接ロード・バランサ・ノードを含む、請求項７に記載された方法。
  10. 前記広告が、前記ロード・バランサ・ノードが前記ルータに広告する他のそれぞれのロード・バランサ・ノードの前記ルータと境界ゲートウェイ・プロトコル（ＢＧＰ）セッションを確立する各ロード・バランサ・ノードから成る、請求項７に記載された方法。
  11. ロード・バランサ・ノードによって前記ルータに広告されている別のロード・バランサ・ノードが故障したことを前記ロード・バランサ・ノードで検出することと、
    前記検出することに応答して、前記他のロード・バランサ・ノードを広告する前記ルータとの前記ＢＧＰセッションを終了することと、
    をさらに含む、請求項１０に記載された方法。
  12. 前記ルータで、ロード・バランサ・ノードを広告する１つまたは複数のＢＧＰセッションが終了したと判断することに応答して、前記ハッシュ化多重パス経路指定技法により前記パケット・フローを前記複数のロード・バランサ・ノードの間に再分散させること、をさらに含む、請求項１１に記載された方法。
  13. パケットの前記ソース及び宛先アドレス情報が、クライアントＩＰアドレス、クライアント・ポート、サーバＩＰアドレス、及びサーバ・ポートを含む、請求項７に記載された方法。
JP2016509081A 2013-04-16 2014-04-16 分散型ロード・バランサでの多重パス経路指定 Active JP6393742B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/864,162 US10038626B2 (en) 2013-04-16 2013-04-16 Multipath routing in a distributed load balancer
US13/864,162 2013-04-16
PCT/US2014/034423 WO2014172497A1 (en) 2013-04-16 2014-04-16 Multipath routing in a distributed load balancer

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018007068A Division JP6526848B2 (ja) 2013-04-16 2018-01-19 分散型ロード・バランサでの多重パス経路指定

Publications (2)

Publication Number Publication Date
JP2016519533A JP2016519533A (ja) 2016-06-30
JP6393742B2 true JP6393742B2 (ja) 2018-09-19

Family

ID=51687565

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2016509081A Active JP6393742B2 (ja) 2013-04-16 2014-04-16 分散型ロード・バランサでの多重パス経路指定
JP2018007068A Active JP6526848B2 (ja) 2013-04-16 2018-01-19 分散型ロード・バランサでの多重パス経路指定

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2018007068A Active JP6526848B2 (ja) 2013-04-16 2018-01-19 分散型ロード・バランサでの多重パス経路指定

Country Status (7)

Country Link
US (2) US10038626B2 (ja)
EP (1) EP2987305B1 (ja)
JP (2) JP6393742B2 (ja)
CN (1) CN105264865B (ja)
CA (1) CA2911269C (ja)
ES (1) ES2654400T3 (ja)
WO (1) WO2014172497A1 (ja)

Families Citing this family (109)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9736065B2 (en) 2011-06-24 2017-08-15 Cisco Technology, Inc. Level of hierarchy in MST for traffic localization and load balancing
US8908698B2 (en) 2012-01-13 2014-12-09 Cisco Technology, Inc. System and method for managing site-to-site VPNs of a cloud managed network
EP2747386A1 (en) * 2012-12-20 2014-06-25 Telefonica S.A. Method and System for the creation, modification and removal of a distributed virtual customer premises equipment
US9900252B2 (en) * 2013-03-08 2018-02-20 A10 Networks, Inc. Application delivery controller and global server load balancer
US10069903B2 (en) 2013-04-16 2018-09-04 Amazon Technologies, Inc. Distributed load balancer
US9225638B2 (en) 2013-05-09 2015-12-29 Vmware, Inc. Method and system for service switching using service tags
US9509614B2 (en) * 2013-06-20 2016-11-29 Cisco Technology, Inc. Hierarchical load balancing in a network environment
US9094323B2 (en) * 2013-06-26 2015-07-28 Cisco Technology, Inc. Probe packet discovery of entropy values causing specific paths to be taken through a network
US9391919B2 (en) 2013-08-14 2016-07-12 International Business Machines Corporation Adaptive algorithm for cloud admission policies
US10110684B1 (en) 2013-08-15 2018-10-23 Avi Networks Transparent network service migration across service devices
US9843520B1 (en) * 2013-08-15 2017-12-12 Avi Networks Transparent network-services elastic scale-out
CN104660508B (zh) * 2013-11-25 2018-03-16 华为技术有限公司 一种报文转发方法及装置
JP6244894B2 (ja) * 2013-12-24 2017-12-13 富士通株式会社 通信システム、通信方法および呼制御サーバ装置
US9779127B2 (en) * 2014-03-31 2017-10-03 Wal-Mart Stores, Inc. Integrating database management system and external cache
US10025710B2 (en) 2014-04-30 2018-07-17 Walmart Apollo, Llc Pattern for integrating primary and secondary data stores in a sharded data domain
US10122605B2 (en) 2014-07-09 2018-11-06 Cisco Technology, Inc Annotation of network activity through different phases of execution
US9774537B2 (en) 2014-09-30 2017-09-26 Nicira, Inc. Dynamically adjusting load balancing
US10129077B2 (en) 2014-09-30 2018-11-13 Nicira, Inc. Configuring and operating a XaaS model in a datacenter
US9825810B2 (en) * 2014-09-30 2017-11-21 Nicira, Inc. Method and apparatus for distributing load among a plurality of service nodes
CN104301417B (zh) * 2014-10-22 2018-08-07 网宿科技股份有限公司 一种负载均衡方法及装置
US20160134543A1 (en) * 2014-11-06 2016-05-12 Mediatek Singapore Pte. Ltd. Method and associated network device for managing network traffic
JP2018501723A (ja) * 2014-12-18 2018-01-18 ノキア ソリューションズ アンド ネットワークス オサケユキチュア ネットワーク負荷バランサー
US11283697B1 (en) 2015-03-24 2022-03-22 Vmware, Inc. Scalable real time metrics management
WO2016155826A1 (en) * 2015-04-01 2016-10-06 Telefonaktiebolaget Lm Ericsson (Publ) System, apparatus and method for load balancing
US10609091B2 (en) 2015-04-03 2020-03-31 Nicira, Inc. Method, apparatus, and system for implementing a content switch
US10476982B2 (en) 2015-05-15 2019-11-12 Cisco Technology, Inc. Multi-datacenter message queue
US10034201B2 (en) * 2015-07-09 2018-07-24 Cisco Technology, Inc. Stateless load-balancing across multiple tunnels
CN105471761A (zh) * 2015-08-07 2016-04-06 北京汉柏科技有限公司 一种交换设备负载调整方法及装置
US10623319B1 (en) 2015-09-28 2020-04-14 Amazon Technologies, Inc. Load rebalancing in a network-based system
US10205677B2 (en) 2015-11-24 2019-02-12 Cisco Technology, Inc. Cloud resource placement optimization and migration execution in federated clouds
US10084703B2 (en) 2015-12-04 2018-09-25 Cisco Technology, Inc. Infrastructure-exclusive service forwarding
US10367914B2 (en) 2016-01-12 2019-07-30 Cisco Technology, Inc. Attaching service level agreements to application containers and enabling service assurance
CN105577567B (zh) * 2016-01-29 2018-11-02 国家电网公司 基于Intel DPDK的网络数据包并行处理方法
CN106101107A (zh) * 2016-06-16 2016-11-09 中国科学院半导体研究所 一种基于ip地址跳变的碎片化传输技术的保密通信方法
US10432532B2 (en) 2016-07-12 2019-10-01 Cisco Technology, Inc. Dynamically pinning micro-service to uplink port
US10382597B2 (en) 2016-07-20 2019-08-13 Cisco Technology, Inc. System and method for transport-layer level identification and isolation of container traffic
US20180054475A1 (en) * 2016-08-16 2018-02-22 Microsoft Technology Licensing, Llc Load balancing system and method for cloud-based network appliances
JPWO2018037893A1 (ja) * 2016-08-23 2019-06-20 日本電気株式会社 ポータルサーバを管理する方法、装置およびシステム
US10567344B2 (en) 2016-08-23 2020-02-18 Cisco Technology, Inc. Automatic firewall configuration based on aggregated cloud managed information
US10320683B2 (en) 2017-01-30 2019-06-11 Cisco Technology, Inc. Reliable load-balancer using segment routing and real-time application monitoring
US10671571B2 (en) 2017-01-31 2020-06-02 Cisco Technology, Inc. Fast network performance in containerized environments for network function virtualization
US11005731B2 (en) 2017-04-05 2021-05-11 Cisco Technology, Inc. Estimating model parameters for automatic deployment of scalable micro services
US10439877B2 (en) 2017-06-26 2019-10-08 Cisco Technology, Inc. Systems and methods for enabling wide area multicast domain name system
US10382274B2 (en) 2017-06-26 2019-08-13 Cisco Technology, Inc. System and method for wide area zero-configuration network auto configuration
US10425288B2 (en) 2017-07-21 2019-09-24 Cisco Technology, Inc. Container telemetry in data center environments with blade servers and switches
US10601693B2 (en) 2017-07-24 2020-03-24 Cisco Technology, Inc. System and method for providing scalable flow monitoring in a data center fabric
US10541866B2 (en) 2017-07-25 2020-01-21 Cisco Technology, Inc. Detecting and resolving multicast traffic performance issues
US10594725B2 (en) * 2017-07-27 2020-03-17 Cypress Semiconductor Corporation Generating and analyzing network profile data
US9853900B1 (en) * 2017-08-07 2017-12-26 Mellanox Technologies Tlv Ltd. Using consistent hashing for ECMP routing
US10834230B2 (en) * 2017-08-25 2020-11-10 International Business Machines Corporation Server request management
US10797966B2 (en) 2017-10-29 2020-10-06 Nicira, Inc. Service operation chaining
US11012420B2 (en) 2017-11-15 2021-05-18 Nicira, Inc. Third-party service chaining using packet encapsulation in a flow-based forwarding element
US10705882B2 (en) 2017-12-21 2020-07-07 Cisco Technology, Inc. System and method for resource placement across clouds for data intensive workloads
US11595474B2 (en) 2017-12-28 2023-02-28 Cisco Technology, Inc. Accelerating data replication using multicast and non-volatile memory enabled nodes
US10797910B2 (en) 2018-01-26 2020-10-06 Nicira, Inc. Specifying and utilizing paths through a network
US10659252B2 (en) 2018-01-26 2020-05-19 Nicira, Inc Specifying and utilizing paths through a network
US10812392B2 (en) * 2018-03-05 2020-10-20 Schweitzer Engineering Laboratories, Inc. Event-based flow control in software-defined networks
US10911296B2 (en) * 2018-03-23 2021-02-02 Juniper Networks, Inc. Targeted selection of cascade ports
US10805192B2 (en) 2018-03-27 2020-10-13 Nicira, Inc. Detecting failure of layer 2 service using broadcast messages
US10728174B2 (en) 2018-03-27 2020-07-28 Nicira, Inc. Incorporating layer 2 service between two interfaces of gateway device
US10511534B2 (en) 2018-04-06 2019-12-17 Cisco Technology, Inc. Stateless distributed load-balancing
US10728361B2 (en) 2018-05-29 2020-07-28 Cisco Technology, Inc. System for association of customer information across subscribers
US10904322B2 (en) 2018-06-15 2021-01-26 Cisco Technology, Inc. Systems and methods for scaling down cloud-based servers handling secure connections
US10764266B2 (en) 2018-06-19 2020-09-01 Cisco Technology, Inc. Distributed authentication and authorization for rapid scaling of containerized services
US11019083B2 (en) 2018-06-20 2021-05-25 Cisco Technology, Inc. System for coordinating distributed website analysis
US10819571B2 (en) 2018-06-29 2020-10-27 Cisco Technology, Inc. Network traffic optimization using in-situ notification system
US10904342B2 (en) 2018-07-30 2021-01-26 Cisco Technology, Inc. Container networking using communication tunnels
US11595250B2 (en) 2018-09-02 2023-02-28 Vmware, Inc. Service insertion at logical network gateway
US10944673B2 (en) 2018-09-02 2021-03-09 Vmware, Inc. Redirection of data messages at logical network gateway
US11750441B1 (en) * 2018-09-07 2023-09-05 Juniper Networks, Inc. Propagating node failure errors to TCP sockets
US10848427B2 (en) * 2018-11-21 2020-11-24 Amazon Technologies, Inc. Load balanced access to distributed endpoints using global network addresses and connection-oriented communication session handoff
CN109510770B (zh) * 2018-12-07 2021-05-04 北京金山云网络技术有限公司 负载均衡节点之间的信息同步方法、装置和处理设备
JP2020136743A (ja) * 2019-02-13 2020-08-31 日本電信電話株式会社 通信制御装置、通信制御プログラム、通信制御システム及び通信制御方法
US11194610B2 (en) 2019-02-22 2021-12-07 Vmware, Inc. Service rule processing and path selection at the source
US10855580B2 (en) * 2019-03-27 2020-12-01 Amazon Technologies, Inc. Consistent route announcements among redundant controllers in global network access point
US11296783B2 (en) 2019-03-27 2022-04-05 Juniper Networks, Inc. Managing satellite devices within a branch network
CN111859062B (zh) * 2019-04-30 2023-09-22 大唐移动通信设备有限公司 一种基于dpdk的网络数据处理方法和装置
US10956056B2 (en) 2019-05-31 2021-03-23 International Business Machines Corporation Applying dynamic routing protocols to route DSN access requests
US10812576B1 (en) * 2019-05-31 2020-10-20 Microsoft Technology Licensing, Llc Hardware load balancer gateway on commodity switch hardware
US11064020B2 (en) 2019-06-25 2021-07-13 Western Digital Technologies, Inc. Connection load distribution in distributed object storage systems
US11343308B2 (en) 2019-06-25 2022-05-24 Western Digital Technologies, Inc. Reduction of adjacent rack traffic in multi-rack distributed object storage systems
US11609931B2 (en) 2019-06-27 2023-03-21 Datadog, Inc. Ring replication system
CN112217843B (zh) * 2019-07-09 2023-08-22 阿里巴巴集团控股有限公司 服务单元切换方法、系统及设备
EP3997577A4 (en) * 2019-07-25 2022-08-17 Snapt, Inc CONTROL A DESTINATION OF NETWORK TRAFFIC
US11140218B2 (en) 2019-10-30 2021-10-05 Vmware, Inc. Distributed service chain across multiple clouds
US11283717B2 (en) 2019-10-30 2022-03-22 Vmware, Inc. Distributed fault tolerant service chain
US11223494B2 (en) 2020-01-13 2022-01-11 Vmware, Inc. Service insertion for multicast traffic at boundary
US11153406B2 (en) 2020-01-20 2021-10-19 Vmware, Inc. Method of network performance visualization of service function chains
US11659061B2 (en) 2020-01-20 2023-05-23 Vmware, Inc. Method of adjusting service function chains to improve network performance
US11196679B2 (en) * 2020-03-27 2021-12-07 Arista Networks, Inc. Methods and systems for resource optimization
US11212356B2 (en) 2020-04-06 2021-12-28 Vmware, Inc. Providing services at the edge of a network using selected virtual tunnel interfaces
US11855834B2 (en) 2020-06-02 2023-12-26 Apple Inc. Traffic sink interface
US11812428B2 (en) * 2020-06-23 2023-11-07 Qualcomm Incorporated Controlling an admission probability of a resource pool for configured grant uplink communication
CN111800499B (zh) * 2020-06-30 2022-04-15 北京百度网讯科技有限公司 一种数据传输方法、装置及电子设备
US11425030B2 (en) 2020-10-08 2022-08-23 Cisco Technology, Inc. Equal cost multi-path (ECMP) failover within an automated system (AS)
US11310309B1 (en) 2020-12-11 2022-04-19 Amazon Technologies, Inc. Arc jump: per-key selection of an alternative server when implemented bounded loads
US11140220B1 (en) * 2020-12-11 2021-10-05 Amazon Technologies, Inc. Consistent hashing using the power of k choices in server placement
US11734043B2 (en) 2020-12-15 2023-08-22 Vmware, Inc. Providing stateful services in a scalable manner for machines executing on host computers
US11611625B2 (en) 2020-12-15 2023-03-21 Vmware, Inc. Providing stateful services in a scalable manner for machines executing on host computers
CN112738339B (zh) * 2020-12-29 2022-09-23 杭州东信北邮信息技术有限公司 一种电信域微服务架构下的服务实例无损扩缩容方法
US11743233B2 (en) * 2021-02-12 2023-08-29 Oracle International Corporation Scaling IP addresses in overlay networks
US11765083B2 (en) 2021-05-27 2023-09-19 Cisco Technology, Inc. Service discovery for control plane and establishing border gateway protocol sessions
CN114422427B (zh) * 2021-12-27 2024-03-08 天翼云科技有限公司 一种流量均衡方法、装置、电子设备和存储介质
CN114598704B (zh) * 2022-03-16 2024-05-17 浪潮云信息技术股份公司 基于四层负载均衡集群的tcp连接容错方法
CN114640682B (zh) * 2022-05-11 2022-07-19 军事科学院系统工程研究院网络信息研究所 一种基于改进无状态哈希的负载均衡方法和系统
CN115334035B (zh) * 2022-07-15 2023-10-10 天翼云科技有限公司 一种报文转发方法、装置、电子设备及存储介质
CN115665049A (zh) * 2022-10-11 2023-01-31 浪潮云信息技术股份公司 一种云平台针对多活负载均衡分配权重的方法
US11895182B1 (en) 2023-01-23 2024-02-06 Bank Of America Corporation Systems, methods, and apparatuses for dynamically determining data center transmissions by implementing load balancers in an electronic network
CN116760764B (zh) * 2023-08-18 2023-11-17 深圳捷誊技术有限公司 路由公告方法、服务器节点、信息公告板及存储介质

Family Cites Families (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3556476B2 (ja) 1998-07-13 2004-08-18 富士通株式会社 ロードシェアシステム及び処理要求中継プログラムを記録したコンピュータ読み取り可能な記録媒体
US20030237016A1 (en) * 2000-03-03 2003-12-25 Johnson Scott C. System and apparatus for accelerating content delivery throughout networks
WO2002048823A2 (en) * 2000-12-14 2002-06-20 Flash Networks Ltd. A system and a method for load balancing
JP2005502096A (ja) 2001-01-11 2005-01-20 ゼット−フォース コミュニケイションズ インコーポレイテッド ファイルスイッチ及び交換ファイルシステム
US20030009559A1 (en) * 2001-07-09 2003-01-09 Naoya Ikeda Network system and method of distributing accesses to a plurality of server apparatus in the network system
JP2003131961A (ja) 2001-07-09 2003-05-09 Hitachi Ltd ネットワークシステム及び負荷分散方法
WO2003009539A1 (fr) * 2001-07-10 2003-01-30 Fujitsu Limited Systeme de communication a terminal mobile et procede de communication
US7283556B2 (en) 2001-07-31 2007-10-16 Nishan Systems, Inc. Method and system for managing time division multiplexing (TDM) timeslots in a network switch
JP3645852B2 (ja) 2001-11-19 2005-05-11 Ｎｅｃアクセステクニカ株式会社 負荷分散方法、コンテンツ配信システム及び負荷分散装置
JP3898498B2 (ja) 2001-12-06 2007-03-28 富士通株式会社 サーバ負荷分散システム
US7512702B1 (en) * 2002-03-19 2009-03-31 Cisco Technology, Inc. Method and apparatus providing highly scalable server load balancing
US7380002B2 (en) 2002-06-28 2008-05-27 Microsoft Corporation Bi-directional affinity within a load-balancing multi-node network interface
US7774473B2 (en) * 2002-07-31 2010-08-10 Oracle America, Inc. System and method for sticky routing of requests within a server farm
US7480737B2 (en) 2002-10-25 2009-01-20 International Business Machines Corporation Technique for addressing a cluster of network servers
US20040088410A1 (en) * 2002-11-06 2004-05-06 Flynn Thomas J. Computer network architecture
US7353276B2 (en) 2003-02-13 2008-04-01 Microsoft Corporation Bi-directional affinity
JPWO2004088940A1 (ja) 2003-03-31 2006-07-06 富士通株式会社 負荷分散システム
US20040246895A1 (en) 2003-06-09 2004-12-09 Telefonaktiebolaget Lm Ericsson (Publ) Bandwidth-limited supervisory packet transmission to control congestion and call establishment in packet-based networks
US7636917B2 (en) 2003-06-30 2009-12-22 Microsoft Corporation Network load balancing with host status information
US7606929B2 (en) 2003-06-30 2009-10-20 Microsoft Corporation Network load balancing with connection manipulation
US7567504B2 (en) 2003-06-30 2009-07-28 Microsoft Corporation Network load balancing with traffic routing
US7454489B2 (en) * 2003-07-01 2008-11-18 International Business Machines Corporation System and method for accessing clusters of servers from the internet network
US20050027862A1 (en) 2003-07-18 2005-02-03 Nguyen Tien Le System and methods of cooperatively load-balancing clustered servers
US20050071469A1 (en) 2003-09-26 2005-03-31 Mccollom William G. Method and system for controlling egress traffic load balancing between multiple service providers
US7436838B2 (en) 2004-12-29 2008-10-14 Cisco Technology, Inc. Automatic prioritization of BGP next-hop in IGP
US7769886B2 (en) 2005-02-25 2010-08-03 Cisco Technology, Inc. Application based active-active data center network using route health injection and IGP
US7991867B2 (en) * 2006-07-13 2011-08-02 Cisco Technology, Inc. Server checking using health probe chaining
US20080259797A1 (en) * 2007-04-18 2008-10-23 Aladdin Knowledge Systems Ltd. Load-Balancing Bridge Cluster For Network Nodes
US8238237B2 (en) 2007-06-18 2012-08-07 Sony Computer Entertainment Inc. Load balancing distribution of data to multiple recipients on a peer-to-peer network
US8867341B2 (en) 2007-11-09 2014-10-21 International Business Machines Corporation Traffic management of client traffic at ingress location of a data center
US8996683B2 (en) * 2008-06-09 2015-03-31 Microsoft Technology Licensing, Llc Data center without structural bottlenecks
US8180896B2 (en) * 2008-08-06 2012-05-15 Edgecast Networks, Inc. Global load balancing on a content delivery network
US20100036903A1 (en) 2008-08-11 2010-02-11 Microsoft Corporation Distributed load balancer
JP4931881B2 (ja) 2008-08-13 2012-05-16 日本電信電話株式会社 ホワイトリストを利用したサーバ割り当てシステムおよびその方法
CN101364930A (zh) * 2008-09-24 2009-02-11 深圳市金蝶中间件有限公司 会话控制方法、装置及系统
US8218553B2 (en) * 2009-02-25 2012-07-10 Juniper Networks, Inc. Load balancing network traffic on a label switched path using resource reservation protocol with traffic engineering
US8416692B2 (en) 2009-05-28 2013-04-09 Microsoft Corporation Load balancing across layer-2 domains
US8769541B2 (en) 2009-12-31 2014-07-01 Facebook, Inc. Load balancing web service by rejecting connections
US8549146B2 (en) * 2010-01-28 2013-10-01 Telefonaktiebolaget L M Ericsson (Publ) Stateless forwarding of load balanced packets
JP2011182070A (ja) 2010-02-26 2011-09-15 Nippon Telegr & Teleph Corp <Ntt> 仮想通信路接続システムおよび仮想通信路接続方法
WO2011136807A1 (en) 2010-04-30 2011-11-03 Hewlett-Packard Development Company, L.P. Method for routing data packets in a fat tree network
US8499093B2 (en) 2010-05-14 2013-07-30 Extreme Networks, Inc. Methods, systems, and computer readable media for stateless load balancing of network traffic flows
EP2395710B1 (en) 2010-06-08 2013-11-06 Alcatel Lucent Device and method for data load balancing
JP5489917B2 (ja) 2010-08-23 2014-05-14 日本電信電話株式会社 サーバ負荷分散システム及び方法
JP5580706B2 (ja) 2010-09-29 2014-08-27 Ｋｄｄｉ株式会社 再送制御プロトコルを用いるデータ転送装置、プログラム及び方法
US8711703B2 (en) 2010-10-29 2014-04-29 Telefonaktiebolaget L M Ericsson (Publ) Load balancing in shortest-path-bridging networks
US8755283B2 (en) 2010-12-17 2014-06-17 Microsoft Corporation Synchronizing state among load balancer components
US8780896B2 (en) * 2010-12-29 2014-07-15 Juniper Networks, Inc. Methods and apparatus for validation of equal cost multi path (ECMP) paths in a switch fabric system
US8676980B2 (en) 2011-03-22 2014-03-18 Cisco Technology, Inc. Distributed load balancer in a virtual machine environment
US9083710B1 (en) * 2012-01-03 2015-07-14 Google Inc. Server load balancing using minimally disruptive hash tables
US10454997B2 (en) * 2012-09-07 2019-10-22 Avigilon Corporation Distributed physical security system
US9397912B2 (en) * 2013-03-13 2016-07-19 Arista Networks, Inc. Method and system for active fabric management using unicast reachability monitoring

Also Published As

Publication number Publication date
EP2987305A1 (en) 2016-02-24
CN105264865A (zh) 2016-01-20
US20180359177A1 (en) 2018-12-13
JP2016519533A (ja) 2016-06-30
WO2014172497A1 (en) 2014-10-23
US20140310391A1 (en) 2014-10-16
ES2654400T3 (es) 2018-02-13
CA2911269C (en) 2020-03-24
EP2987305A4 (en) 2016-09-28
CA2911269A1 (en) 2014-10-23
US10038626B2 (en) 2018-07-31
EP2987305B1 (en) 2017-12-20
CN105264865B (zh) 2019-04-23
JP6526848B2 (ja) 2019-06-05
US10999184B2 (en) 2021-05-04
JP2018082497A (ja) 2018-05-24

Similar Documents

Publication Publication Date Title
JP6526848B2 (ja) 分散型ロード・バランサでの多重パス経路指定
US11843657B2 (en) Distributed load balancer
JP6169251B2 (ja) 分散型ロードバランサにおける非対称パケットフロー
JP6030807B2 (ja) 分散型ロードバランサでの接続公開
US9432245B1 (en) Distributed load balancer node architecture
US9559961B1 (en) Message bus for testing distributed load balancers
US9871712B1 (en) Health checking in a distributed load balancer
AU2014253953B9 (en) Distributed load balancer

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20161026

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161108

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20170208

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170410

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20170919

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180119

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20180126

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180403

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180628

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180731

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180827

R150 Certificate of patent or registration of utility model

Ref document number: 6393742

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250