JP6445621B2 - 分散型ロードバランサ - Google Patents

分散型ロードバランサ Download PDF

Info

Publication number
JP6445621B2
JP6445621B2 JP2017112933A JP2017112933A JP6445621B2 JP 6445621 B2 JP6445621 B2 JP 6445621B2 JP 2017112933 A JP2017112933 A JP 2017112933A JP 2017112933 A JP2017112933 A JP 2017112933A JP 6445621 B2 JP6445621 B2 JP 6445621B2
Authority
JP
Japan
Prior art keywords
node
load balancer
server
packet
connection
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
JP2017112933A
Other languages
English (en)
Other versions
JP2017184272A (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 JP2017184272A publication Critical patent/JP2017184272A/ja
Application granted granted Critical
Publication of JP6445621B2 publication Critical patent/JP6445621B2/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
    • 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
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • 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
    • H04L67/1004—Server selection for load balancing
    • H04L67/1023—Server selection for load balancing based on a hash applied to IP addresses or costs
    • 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
    • H04L67/1038—Load balancing arrangements to avoid a single path through a load balancer
    • 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/2866—Architectures; Arrangements
    • H04L67/288—Distributed intermediate devices, i.e. intermediate devices for interaction with other intermediate devices on the same level
    • 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/72—Routing based on the source address
    • 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
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Description

本発明は、分散型ロードバランサに関する。
従来のロードバランサは、通常、単一且つ専用のボックスで、多数のネットワーク・イ
ンターフェイス制御部（ＮＩＣ）、例えば８個のＮＩＣを有し、いくつかのＮＩＣはクラ
イアントとの間でインバウンドトラフィックやアウトバウンドトラフィックを取り扱い、
他のＮＩＣは負荷分散されているホスト装置（例えば、ウェブサーバなどのサーバ）との
間でアウトバウンドトラフィックやインバウンドトラフィックを取り扱う。これら従来の
ロードバランサにおける帯域幅またはスループットは、通常、クライアント側においても
４０ギガビット／秒（Ｇｂｐｓ）及びサーバ側においても４０Ｇｂｐｓの範囲内である。
クラウド・コンピュータ・サービスなどのネットワークベースのアプリケーション及びネ
ットワークベースのサービスの規模や範囲は増加してきているので、データセンターは、
負荷分散をするためのホスト装置（例えば、ウェブサーバ）を数百ないし数千に達するま
で収容するようになっていく。従来のロードバランサはこのような環境にうまくスケール
を変更することができない。
さらに、従来のロードバランサは、ホスト装置から収集したデータに対して、通常、最
大接続（またはｍａｘ ｃｏｎｎｓ）、ラウンド・ロビン、及び／または最小の接続（ｌ
ｅａｓｔ ｃｏｎｎｓ）などの技法を使用して、接続を取り扱ういずれかのホスト装置を
選択する。また、従来のロードバランサは、クライアントからの接続（例えば、伝送制御
プロトコル（ＴＣＰ）接続）を受けて、それゆえ終了させるホスト装置に対して、通常、
プロキシとしての機能を果たし、ホスト装置とロードバランサとの間で確立されたＴＣＰ
接続上でクライアントトラフィックをホスト装置に送信する。したがって、これら従来の
ロードバランサを使用した場合に、ホスト装置とクライアントとは直接のＴＣＰ接続によ
っては通信しない。
少なくともいくつかの実施形態において、分散型ロードバランシングシステムの実施例のブロック図である。 少なくともいくつかの実施形態において、図１の分散型ロードバランサシステムによって実施されるロードバランシング方法の上位のフローチャートである。 少なくともいくつかの実施形態において、入口、出口及びフロー追跡部の構成要素を有するロードバランサノードの実施例を示す。 少なくともいくつかの実施形態において、分散型ロードバランサ内のルーティング及びパケットフローを示す。 少なくともいくつかの実施形態において、エッジルータに対して広告している入口ノードを示す。 少なくともいくつかの実施形態において、マルチパス・ルーティング方法のフローチャートである。 少なくともいくつかの実施形態において、非対称のパケットフローをグラフィカルに示す。 少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。 少なくともいくつかの実施形態において、分散型ロードバランシングシステム内で接続を確立した場合のパケットフローのフローチャートを提供する。 少なくともいくつかの実施形態において、分散型ロードバランシングシステム内で接続を確立した場合のパケットフローのフローチャートを提供する。 少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。 少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。 少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。 少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。 少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。 少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。 少なくともいくつかの実施形態において、分散型ロードバランシングシステム内のパケットフローを示す。 少なくともいくつかの実施形態において、ロードバランサノードのコンシステントハッシュリングにおけるメンバーシップに影響を与えるイベントの取り扱いを示す。 少なくともいくつかの実施形態において、ロードバランサノードのコンシステントハッシュリングにおけるメンバーシップに影響を与えるイベントの取り扱いを示す。 少なくともいくつかの実施形態において、ロードバランサノードのコンシステントハッシュリングにおけるメンバーシップに影響を与えるイベントの取り扱いを示す。 少なくともいくつかの実施形態において、ロードバランサノードのコンシステントハッシュリングにおけるメンバーシップに影響を与えるイベントの取り扱いを示す。 少なくともいくつかの実施形態において、ヘルスチェック間隔に従って各ロードバランサノードによって実行されるヘルスチェック方法の上位のフローチャートである。 少なくともいくつかの実施形態において、他のロードバランサノードからロードバランサノードをヘルスチェックする方法を示す。 少なくともいくつかの実施形態において、１以上の他のロードバランサノードをヘルスチェックするロードバランサをグラフィカルに示す。 少なくともいくつかの実施形態において、サーバノードをヘルスチェックするロードバランサを示す。 少なくともいくつかの実施形態において、ロードバランサノード１１０によって維持される他のノードのヘルスの表示をグラフィカルに示す。 少なくともいくつかの実施形態において、各ロードバランサノードによって維持される健康情報を示す。 少なくともいくつかの実施形態において、ロードバランサノードの障害の取り扱いを示す。 少なくともいくつかの実施形態において、ロードバランサノードの障害の取り扱いを示す。 少なくともいくつかの実施形態において、接続公開技法をグラフィカルに示す。 少なくともいくつかの実施形態において、接続公開技法をグラフィカルに示す。 少なくともいくつかの実施形態において、各ロードバランサモジュールによって実行される接続公開方法の上位のフローチャートである。 少なくともいくつかの実施形態において、接続公開パケット内で受信されたアクティブな接続情報を目標のロードバランサノードに対して分散する方法のフローチャートである。 少なくともいくつかの実施形態において、接続公開パケット内で受信されたアクティブな接続情報を目標のロードバランサノードに対して分散する代替方法を示す。 少なくともいくつかの実施形態において、ロードバランサノードに対する例示的なソフトウェア・スタック・アーキテクチャを示す。 実施形態において使用されるコアパケット処理技術の態様を示す。 少なくともいくつかの実施形態において、ロードバランサノード上でデータフローを処理する例示的なマルチコア・パケット・プロセッサを示す。 少なくともいくつかの実施形態において、ロードバランサノード上でデータフローを処理する他の例示的なマルチコア・パケット・プロセッサを示す。 少なくともいくつかの実施形態において、ロードバランサノードのプロセスによる着信パケットの処理を示す。 少なくともいくつかの実施形態において、ロードバランサノードのプロセスによる発信パケットの処理を示す。 少なくともいくつかの実施形態において、生産環境の中で分散型ロードバランサを含むロードバランシングシステムを示す。 少なくともいくつかの実施形態において、単一のプロセスの中でまたは単一のプロセスとして多数の分散型ロードバランシングシステムの構成要素が構成され且つ実行されることを可能にするメッセージバスのメカニズムを組み込む分散型ロードバランサ試験システムを示す。 少なくともいくつかの実施形態において、メッセージバスのパケットアダプタ及びパケットパイプラインを示す。 少なくともいくつかの実施形態において、メッセージバスのパケットアダプタ及びパケットパイプラインを示す。 少なくともいくつかの実施形態において、例示的なプロバイダ・ネットワーク環境を示す。 少なくともいくつかの実施形態において、分散型ロードバランサの実装を図３３Ａにみられうようなプロバイダ・ネットワーク環境の例で示す。 少なくともいくつかの実施形態において、分散型ロードバランサ及びサーバノードの例示的な物理的なラック実装を示す。 少なくともいくつかの実施形態において、分散型ロードバランサ及びサーバノードの他の例示的な物理的なラック実装を示す。 少なくともいくつかの実施形態において、ネットワーク内に１つ、２つまたはそれより大きい分散型ロードバランサが実装された例示的なネットワーク環境を示す。 いくつかの実施形態において使用される例示的なコンピュータシステムを示すブロック図である。
いくつかの実施形態及び説明図についての実施例として実施形態が本明細書に記載され
るが、当業者であれば、記載された当該実施形態及び図面には実施形態が限定されないと
いうことを認識するであろう。図面及びそれについての詳細な記述は、開示された特定の
形態に実施形態を限定する意図はなく、その反対に、添付された特許請求の範囲によって
画定される趣旨及び範囲に包含される、すべての変形、等価物、及び代替に及ぶという意
図であることを理解する必要がある。ここで使用された見出しは、構成上の目的のための
みであり、本明細書の範囲または特許請求の範囲を限定するために使用されるものではな
い。この出願を通して使用されるように、「ｍａｙ（〜する）」の用語は、強制的な意味
（すなわち、しなければならない（ｍｕｓｔ）の意味）ではなく、許容的な意味（すなわ
ち、可能性を持つの意味）に使用されている。同様に、「ｉｎｌｃｕｄｅ」、「ｉｎｃｌ
ｕｄｉｎｇ」、「ｉｎｃｕｌｕｄｅｓ」の用語は含んでいることを意味し、制限する意味
ではない。
ネットワーク環境における分散型ロードバランシング方法及びシステムの様々な実施形
態について説明する。様々なネットワーク環境における分散型ロードバランサの実施形態
に従って、実装される分散型ロードバランシング方法及びシステムの実施形態について説
明する。分散型ロードバランサの実施形態は、例えば、インターネットなどの外部ネット
ワーク上のクライアントと、図３３Ａ及び３３Ｂに示されるようなプロバイダ・ネットワ
ーク１９００などのローカルネットワーク上の宛先、一般的には、サーバ（例えば、ウェ
ブサーバ、アプリケーションサーバ、データサーバ等）との間で、パケットフロー、例え
ば、伝送制御プロトコル（ＴＣＰ）技術のパケットフローを推進するため及び維持するた
めに使用される。実施形態は、ＴＣＰパケットフローの処理に関して本明細書において主
に説明するが、ＴＣＰ以外の他のデータ通信プロトコル、及びパケットフロー処理以外の
他のアプリケーションにも適用されることに留意されたい。
分散型ロードバランサは、特定のクライアントと選択されたサーバ（例えば、ウェブサ
ーバ）との間でＴＣＰパケットフローを推進し維持するために作用する。しかしながら、
分散型ロードバランサは、従来のロードバランサにおいて行われているように、クライア
ントからのＴＣＰフローを終了させることはなく、且つ、サーバに対してプロキシとして
の役割をすることはない。その代わり、分散型ロードバランサのロードバランサノードは
、クライアントから受信されたＴＣＰパケットを目標のサーバにルーティングし、サーバ
がそれらのＴＣＰスタックを使用してクライアントに対するＴＣＰ接続を管理する。言い
換えれば、サーバがクライアントからのＴＣＰパケットフローを終了させる。
さらに、従来のロードバランサ技術において行われているように、サーバから収集され
た情報に適用されるロードバランシング技法またはアルゴリズムに基づいて、どのサーバ
が接続要求に対応するかに関してロードバランサノードが決定を下す代わりに、ロードバ
ランサノードは、新たな接続要求を受信するサーバをランダムに選択して、当該サーバノ
ード上に属する分散型ロードバランサの構成要素が、それぞれのサーバの現在の状態の１
以上のメトリクスに基づいて、選択されたサーバが新たな接続要求を受理するかまたは拒
絶するかどうかに関してローカルに決定を下す。したがって、どのサーバが接続要求を受
理すべきかに関する決定は、ロードバランサノードから接続を取り扱うサーバノードに移
管される。言い換えれば、決定は、接続要求が対応されるより近い場所及び時間に移管さ
れる。
クライアントとサーバとの間のパケットフローを推進及び維持するために、分散型ロー
ドバランサの実施形態は、限定はされないが、マルチパス・ルーティング技術、コンシス
テントハッシュ法の技術、分散型ハッシュテーブル（ＤＨＴ）技術、境界ゲートウェイ・
プロトコル（ＢＧＰ）技術、メンバーシップ追跡処理、健康ヘルスチェック、接続公開、
及びパケットのカプセル化とデカプセル化を含む様々な技法や技術を利用してよい。これ
らは、分散型負荷分散システムの他の態様と同様、図面と関連して以下説明する。
分散型ロードバランシングシステム
図１は、少なくともいくつかの実施形態において、例示的な分散型ロードバランシング
システムのブロック図である。分散型ロードバランサの実施形態は、ネットワーク１００
、例えば、図３３Ａ及び３３Ｂに示されるようなサービス・プロバイダのプロバイダ・ネ
ットワーク１９００の中に実装される。分散型ロードバランサシステムにおけるクライア
ントパケットの取り扱いの上位の概要として、ネットワーク１００の１以上のクライアン
ト１６０は、例えば、インターネットなどの外部ネットワーク１５０を介して、ネットワ
ーク１００の境界ルータ１０２に接続してよい。境界ルータ１０２は、クライアント１６
０からの着信パケット（例えば、ＴＣＰパケット）を、分散型ロードバランサシステムの
ロードバランサノードレイヤにおけるロードバランサ（ＬＢ）ノード１１０に着信パケッ
トをルーティングする分散型ロードバランサのエッジルータ１０４の構成要素にルーティ
ングする。少なくともいくつかの実施形態において、エッジルータ１０４は、フロー単位
のハッシュ化マルチパス・ルーティング技法、例えば、等価マルチパス（ＥＣＭＰ）ハッ
シュ法の技法に従って、ルーティングの決定を下す。ロードバランサノード１１０は、今
度は、パケットを（例えば、ユーザ・データグラム・プロトコル（ＵＤＰ）に従って）カ
プセル化し、ネットワーク１００上のネットワークファブリック１２０（例えば、Ｌ３ネ
ットワーク）を介してサーバノード１３０上のローカルロードバランサモジュール１３２
にカプセル化されたパケットをルーティングする。ファブリック１２０は、１以上のネッ
トワーク装置、または、限定はされないが、スイッチ、ルータ、及びケーブルを含む構成
要素を含んでよい。サーバノード１３０上において、ローカルロードバランサモジュール
１３２は、パケットをデカプセル化し、サーバ１３４のＴＣＰスタックにクライアントＴ
ＣＰパケットを送信する。サーバノード１３０上のサーバ１３４は、次に、それらのＴＣ
Ｐスタックを使用してクライアント１６０に対する接続を管理する。
図２は、少なくともいくつかの実施形態において、図１の分散型ロードバランサシステ
ムによって実行されるロードバランシング方法の上位のフローチャートである。分散型ロ
ードバランサシステムの実施形態は、従来のロードバランサにおいて行われているような
、多数の宛先（例えば、ウェブサーバ）の中に負荷を対応付けている困難な問題を解決す
ることができない。例えば、従来のロードバランサは、一般的に、最大接続、ラウンド・
ロビン、及び／または、最小接続の技法などの技法またはアルゴリズムを使用して、接続
を取り扱うべきいずれかのサーバを選択する。しかしながら、これらの技法は欠点があり
、特に、ロードバランシングの決定をするために使用されるデータがほとんど急速に古く
なるようなことが多い場所での分散型システムにおいては特に成功裏に実行することが困
難である。分散型ロードバランサシステムの少なくともいくつかの実施形態において、従
来のロードバランサにおいて行われているような、１以上のロードバランシング技法を使
用して、接続要求を満たすサーバノード１３０を選択する試みに代えて、ロードバランサ
ノードレイヤにおけるロードバランサノード１１０が、クライアント接続のための要求を
受信するサーバノード１３０をランダムに決定してもよい。サーバノード１３０が自身を
過負荷であると判断した場合には、当該サーバノード１３０は接続要求をロードバランサ
ノード１１０に送信して戻すので、当該サーバノード１３０が現在は接続を取り扱うこと
ができないことをロードバランサノード１１０に通知する。ロードバランサノードレイヤ
は、次に、接続要求を受信すべき他のサーバノード１３０をランダムに決定するか、ある
いは、要求しているクライアント１６０に対してエラーメッセージを返送して、接続が現
在は確立できないことをクライアント１６０に通知する。
図２の１０に示されるように、分散型ロードバランサシステムのロードバランサノード
レイヤは、通信セッション（例えば、ＴＣＰ接続）についての要求を送信元から受信する
。送信元は、例えば、分散型平衡器システムを実装するネットワーク１００に対する外部
ネットワーク１５０上のクライアント１６０であってよい。少なくともいくつかの実施形
態において、要求はネットワーク１００の境界ルータ１０２においてクライアント１６０
から受信され、例えば、クライアント１６０からの特定の接続要求がルーティングされる
ロードバランサノード１１０を擬似ランダムに選択するためのフロー単位の等価マルチパ
ス（ＥＣＭＰ）ハッシュ処理の技法を用いて、ロードバランサノードレイヤにおけるロー
ドバランサ（ＬＢ）ノード１１０に対して着信パケットをルーティングするエッジルータ
１０４に対してルーティングされる。
２０に示されるように、ロードバランサノードレイヤは、宛先ノードをランダムに選択
して、その選択された宛先ノードに接続要求を転送する。宛先ノードは、例えば、ロード
バランサによって対応させられた複数のサーバノード１３０の１つであってよい。少なく
ともいくつかの実施形態において、ロードバランサレイヤにおけるロードバランサノード
１１０は、すべての既知のサーバノード１３０の中から接続要求を受信すべきサーバノー
ド１３０をランダムに選択してよい。しかしながら、すべての既知のサーバノード１３０
の中からの単なるランダムな選択ではなく、いくつかの実施形態においては、接続要求を
受信すべきサーバノード１３０を選択するために、他の方法が使用されてもよい。例えば
、いくつかの実施形態において、サーバノード１３０に関する情報が、サーバノード１３
０のランダムな選択の重みづけをするロードバランサノード１１０によって使用される。
実施例のように、ロードバランサノード１１０が、異なるサーバノード１３０が異なるタ
イプの装置であるか、または、異なるＣＰＵで構成されており、そのため異なる能力また
は容量を持っていることを認識している場合には、サーバノード１３０の特定のタイプま
たは構成に向かう（または、離れる）ようにランダムな選択に偏りを持たせるためにその
情報が使用されてもよい。
３０に示されるように、宛先ノードは、通信セッションを受諾することができるかどう
かを判定する。少なくともいくつかの実施形態において、サーバノード１３０上のローカ
ルロードバランサ（ＬＢ）モジュール１３２は、サーバノード１３０上のそれぞれのサー
バ１３４がそれぞれのサーバ１３４の現在の状態の１以上のメトリクスに基づいて新たな
接続を受諾できるかどうかを判定する。
４０において、接続要求が受諾された場合には、５０に示されるように宛先ノードは、
宛先ノードが接続を取り扱うことができる旨をロードバランサノードレイヤに通知する。
６０に示されるように、ロードバランサノードレイヤを介して、送信元（例えば、クライ
アント１６０）と宛先ノード（例えば、サーバノード１３０上のサーバ１３４）との間に
通信セッションが確立されることになる。少なくともいくつかの実施形態において、サー
バノード１３０上のサーバ１３４は、ＴＣＰスタックを使用してクライアント１６０に対
する接続を管理する。
４０において、接続要求が受理されない場合には、７０に示されるように、宛先ノード
はロードバランサノードレイヤに通知し、方法は要素２０に戻る。その後、ロードバラン
サノードレイヤは、２０において他の宛先ノードをランダムに選択するか、または、要求
しているクライアント１６０に対して、現在は接続を確立することができない旨を通知す
ることができる。クライアント１６０は、必ずしも接続要求を再実行する必要はなく、要
素１０において再び方法を開始することに留意されたい。
再び図１を参照すると、分散型ロードバランサシステムの少なくともいくつかの実施形
態分散型は、汎用のハードウェアを使用して、ネットワーク１００上のエッジルータ１０
４において受信されたクライアントトラフィックをネットワーク１００上のサーバノード
１３０にルーティングする。分散型ロードバランサの少なくともいくつかの実施形態は、
多数のロードバランサノード１１０を含むロードバランサノードレイヤを含んでもよい。
少なくともいくつかの実施形態において、各ロードバランサノード１１０は、ロードバラ
ンサノードレイヤにおいて１以上の多数の役割を果たす。ロードバランサノード１１０の
これらの役割は、入口ノード、及び出口ノード、及びフロー追跡部ノード（所定のパケッ
トフローに対する一次フロー追跡部または二次フロー追跡部として）を含む。少なくとも
いくつかの実施形態において、各ロードバランサノード１１０は、汎用のラック収容型演
算装置などの独立した演算装置としてまたはその上で、ロードバランサノードレイヤの中
に実装されてもよい。少なくともいくつかの実施形態において、各ロードバランサノード
１１０は、入口ノード、出口ノード、及びフロー追跡部ノード（パケットフローに対する
一次または二次フロー追跡部として）の３つの役割の各々を果たすが、通常は、ロードバ
ランサノード１１０は、特定のパケットフローに対する複数の役割の中の１つの役割だけ
に従事する（ただし、２つまたは３つの役割に従事することも可能）。しかしながら、少
なくともいくつかの実施形態において、ロードバランサノード１１０は、特定のパケット
フローに対する一次フロー追跡部及び二次フロー追跡部の両方としての役割を果たすこと
は許されないことに留意されたい。あるいは、いくつかの実施形態において、各ロードバ
ランサノード１１０は、３つの役割の中の１つの役割のみを果たす。この実施形態におい
ては、演算装置の独立した組み合わせは、特に、入口ノード、出口ノード、及びフロー追
跡部ノードとして、ロードバランサノードレイヤの中に実装されてもよい。
少なくともいくつかの実施形態において、コンシステントハッシュ法及びコンシステン
トハッシュリング技術は、パケットフローに対する一次及び二次フロー追跡部を決定する
ために適用されてもよい。クライアントからの各パケットフローは、例えば、クライアン
トＩＰアドレス、クライアントポート、サーバ（パブリック）ＩＰアドレス、及びサーバ
ポートから構成される４つのタプルによって一意に認証される。この識別子は、クライア
ント及び公開エンドポイント対を示すＣＰまたはＣｃＰｐとして略すことができる。任意
の所定のＴＣＰフロー（またはＣＰ対）に関連するパケットは、エッジルータ１０４から
のハッシュ化マルチパス（例えば、ＥＣＭＰ）フロー分散のせいで、入口サーバ１１２と
して動作する任意のロードバランサノード１１０上に出現し得る。入口ノードとして機能
しているロードバランサノード１１０にパケットが到達した場合には、入口ノードは、パ
ケットフロー（すなわち、一次フロー追跡部ノード）に対応する状態を維持することを担
うのにどのロードバランサノード１１０にするかを決定することができるように、コンシ
ステントハッシュ法が使用される。ＣＰ対は、入口ノードによってハッシュ化されてコン
システントハッシュリングに入り、パケットフローに関する状態情報を維持することを担
うのにどのロードバランサノード１１０にするかを決定する。コンシステントハッシュリ
ングにおいてパケットフローに対応するＣＰ対のコンシステントハッシュに従って決定さ
れたノード１１０は、パケットフローに対して一次フロー追跡部としての機能を果たすノ
ード１１０である。少なくともいくつかの実施形態において、コンシステントハッシュリ
ングの中で後に続くノードは、パケットフローに対して二次フロー追跡部としての機能を
果たす。
図３は、少なくともいくつかの実施形態において、すべての３つの役割（入口、出口、
及びフロー追跡部）を実施する構成要素を含む例示的なロードバランサ（ＬＢ）ノード１
１０を示す。この実施例において、入口サーバ１１２の構成要素は、クライアントからの
インバウンドのＴＣＰパケットを受信して、そのＴＣＰパケットをカプセル化されたパケ
ットとしてサーバに送信する入口の役割を実行する。出口サーバ１１４の構成要素は、サ
ーバからのアウトバウンドのカプセル化されたパケットを受信して、デカプセル化された
ＴＣＰパケットをクライアントに対して送信する出口の役割を実行する。フロー追跡部１
１６の構成要素は、クライアント１６０とサーバ１３４との間に確立された１または２以
上のパケットフローに対応する一次または二次フロー追跡部として実行する。入口サーバ
１１２はまた、ロードバランサノード１１０上のフロー追跡部１１６または他のロードバ
ランサノード１１０上のフロー追跡部１１６と通信し、それぞれのクライアント１６０か
ら受信した接続要求に応答して、クライアントとサーバ１３４の１つとの間のＴＣＰ接続
を開始し、または、パケットフローに対するマッピング情報を取得する。
＜ロードバランサノード＞
再び図１を参照すると、少なくともいくつかの実施形態において、ロードバランサノー
ドレイヤにおけるロードバランサノード１１０は、ネットワーク上の１以上のルータ１０
４からのクライアントトラフィック（パケット、例えば、ＴＣＰパケット）を受信して、
ファブリック１２０上の分散型ロードバランサシステムによって使用されるプロトコル（
例えば、ユーザ・データグラム・プロトコル（ＵＤＰ））に従って、そのパケットをカプ
セル化する。次に、ロードバランサノードレイヤは、そのカプセル化されたパケットを宛
先サーバノード１３０に対してファブリック１２０を介して転送する。各サーバノード１
３０は、ロードバランサシステムの構成要素であるローカルモジュール１３２を含む。モ
ジュール１３２は、ここにおいてはロードバランサモジュールまたは単にＬＢモジュール
と称され、サーバノード１３０上のソフトウェア、ハードウェア、またはこれらの複合内
に実装されてもよい。各サーバノード１３０において、それぞれのロードバランサモジュ
ール１３２は、パケットをデカプセル化して、正常なＴＣＰ処理のためにローカルＴＣＰ
スタックに対してＴＣＰパケットを送信する。少なくともいくつかの実施形態において、
ロードバランサノードレイヤは、すべてのクライアント−サーバＴＣＰフローにおける状
態情報を維持するが、しかし、ロードバランサノードレイヤにおけるロードバランサノー
ド１１０は、ＴＣＰフローに関するいかなるものも解釈することはない。各フローは、そ
れぞれのサーバノード１３０上のサーバ１３４とクライアント１６０との間で管理される
。分散型ロードバランサシステムは、ＴＣＰパケットが正しい宛先サーバ１３４に到達す
ることを保証する。各サーバノード１３０におけるロードバランサモジュール１３２は、
それぞれのサーバ１３４がロードバランサノード１１０から受信したクライアント接続要
求に応答する新たな接続を受諾するかまたは拒絶するかどうかについて決定を下す。
少なくともいくつかの実施形態において、分散型ロードバランシングシステムは、コン
システントハッシュ法の技術を使用して、例えば、どのサーバノード１３０が特定のＴＣ
Ｐパケットフローに対して責任を負うかについて、どのロードバランサノード１１０が記
憶すべきかを決定する。コンシステントハッシュ法の技術を使用することにより、ロード
バランサノードレイヤにおけるロードバランサノード１１０は、コンシステントハッシュ
リングとして見られ、ロードバランサノード１１０はそのリング内のメンバーシップを追
跡し、コンシステントハッシュ法の機能に従って、特定のパケットフローに対して責任を
負うそのリング内の特定のメンバーを決定する。少なくともいくつかの実施形態において
、クライアント１６０とサーバ１３４との間における各パケットフローの追跡に対して責
任を負う２つのロードバランサノード１１０が存在するが、これらのノード１１０は一次
フロー追跡部（ＰＦＴ）ノード及び二次フロー追跡部（ＳＦＴ）ノードと称される。少な
くともいくつかの実施形態において、一次フロー追跡部は、フローについてのコンシステ
ントハッシュリング上の第１のロードバランサノード１１０であり、二次フロー追跡部は
、一次フロー追跡部ノードとは異なる、コンシステントハッシュリング上の次のまたはそ
れに続くロードバランサノード１１０である。この配列において、一次フロー追跡部ノー
ドに障害が生じた場合には、二次フロー追跡部ノードが新たな一次フロー追跡部になり、
他のロードバランサノード１１０（例えば、コンシステントハッシュリング上の次のノー
ド１１０）が二次フロー追跡部の役割を負う。少なくともいくつかの実施形態において、
ロードバランサノード１１０は、所定のパケットフローに対する一次フロー追跡部及び二
次フロー追跡部の両方としての機能を果たすことは許されないことに留意されたい。コン
システントハッシュリングにおけるこのメンバーシップの変更及び他のメンバーシップの
変更については、本明細書において後述する。少なくともいくつかの実施形態において、
ロードバランサの実装についての構成情報（例えば、現在実装されているロードバランサ
ノード１１０及びサーバノード１３０の信頼できるリスト）は、分散型ロードバランシン
グシステムの構成サービス１２２の構成要素によって維持され、例えば、ファブリック１
２０を介してロードバランサノード１１０に結合された１以上のサーバ装置上に実装され
てもよい。
少なくともいくつかの実施形態において、一次及び二次フロー追跡部ノードとして機能
することに加えて、ロードバランサノード１１０はまた、所定のフローに対する２つの他
の役割、すなわち、入口ノードの役割及び出口ノードの役割のうち１つを実行してもよい
。パケットフローに対する入口ノードは、エッジルータ１０４からのそれぞれのパケット
フローを受信して、サーバノード１３０上の選択されたサーバ１３４に対してファブリッ
ク１２０を介してそのパケットフローを（カプセル化されたパケットとして）転送するロ
ードバランサノード１１０である。入口ノードは、実際のクライアントデータ（ＴＣＰデ
ータパケット）をそれぞれの宛先サーバノード１３０に対して移動する唯一のロードバラ
ンサノード１１０である。入口ノードがクライアントトラフィックをどのロードバランサ
モジュール１３２に対して転送すべきかを知るように、その入口ノードは宛先サーバノー
ド１３０上のそれぞれのロードバランサモジュール１３２に対するＴＣＰフローのマッピ
ングを維持する。出口ノードは、ファブリック１２０を介してサーバノード１３０から受
信したパケットフローについての応答トラフィックを、境界ネットワークを介してそれぞ
れのクライアント１６０に転送することに対して責任を負うロードバランサノード１１０
である。ロードバランサモジュール１３２は、サーバ１３４から得られた応答パケットを
ロードバランサプロトコル（例えば、ＵＤＰ）に従ってカプセル化して、そのカプセル化
された応答パケットをフローに対応するそれぞれの出口ノードにファブリック１２０を介
して送信する。出口ノードは、ステートレスであり、単にパケットをデカプセル化し、境
界ネットワーク上の応答パケット（例えば、ＴＣＰパケット）を境界ルータ１０２に送信
して、それぞれのクライアント１６０に外部ネットワーク１５０を介して配信する。
上記したように、少なくともいくつかの実施形態において、各ロードバランサノード１
１０は、異なるパケットフローに対して入口ノード、出口ノード、及び／またはフロー追
跡部ノード（一次または二次フロー追跡部のいずれかとして）の役割を実行する。ロード
バランサノードレイヤにおける単一のロードバランサノード１１０は、ノードが処理して
いるパケットフローが何であるかに依存して、役割のいずれか１つを実行する。例えば、
少なくともいくつかの実施形態において、ロードバランサノード１１０は、１つのパケッ
トフローに対しては入口ノードとして、他のパケットフローに対しては一次もしくは二次
フロー追跡部として、さらに他のパケットフローに対しては出口ノードとして実行しても
よい。さらに、少なくともいくつかの実施形態において、ロードバランサノード１１０は
、同一のパケットフローに対して例えば、所定のパケットフローに対して入口ノードとし
て且つ一次（または二次）フロー追跡部ノードとして多重の役割を実行する。しかしなが
ら、少なくともいくつかの実施形態において、冗長性及び回復の目的のために、ロードバ
ランサノード１１０は、同一のパケットフローに対して一次及び二次フロー追跡部ノード
の両方としての役割を果たすことは許されない。
各ロードバランサノード１１０が入口サーバ、出口サーバ、及びフロー追跡部の３つの
役割のいずれかを果たす実施形態について、上記説明した。しかしながら、いくつかの実
施形態においては、演算装置の異なるグループは、ロードバランシングシステムにおいて
異なる役割を割り当てられてもよい。例えば、いくつかの実施形態においては、入口ノー
ド、出口ノード、及びフロー追跡部ノードの各々が独立した演算装置に実装された異なる
組み合わせが存在してもよい。いくつかの実施形態における他の実施例として、演算装置
の１つの組み合わせは入口ノード及びフロー追跡部ノードの両方としての役割を果たし、
その一方、演算装置の他の組み合わせは出口ノードのみとしての役割を果たす。
ロードバランサモジュール
上記したように、各サーバノード１３０は、ロードバランサシステムの構成要素である
ローカルロードバランサモジュール１３２を含む。モジュール１３２は、サーバノード１
３０上でソフトウェア、ハードウェア、またはこれらの組み合わせの中に実装されてもよ
い。少なくともいくつかの実施形態において、サーバノード１３０上のロードバランサモ
ジュール１３２は、３つの主な役割、すなわち、発信パケットのカプセル化及び着信パケ
ットのデカプセル化、ノード１３０上のサーバ１３４に対するローカルロードバランシン
グの決定、及び接続公開を実行してもよい。これら３つの役割について以下に簡単に説明
し、さらに詳細について本明細書において後述する。
分散型ロードバランシングシステムの少なくともいくつかの実施形態において、ＴＣＰ
接続を終了させてはならず、且つ、パケットをスプーフしてはならない。ロードバランサ
ノードレイヤによって送信されたすべてのパケットの送信元ＩＰアドレス及び宛先ＩＰア
ドレスは、パケットフローに含まれているエンドポイント（すなわち、クライアント１６
０及びサーバ１３４）の実際のＩＰアドレスである。スプーフィングの代わりに、これら
の実施形態は、ファブリック１２０上のロードバランサノード１１０及びサーバノード１
３０の間で送信されるすべてのパケットを、例えば、ＵＤＰパケットとしてカプセル化す
る。フローに対して入口ノードとして機能するロードバランサノード１１０からサーバノ
ード１３０に到着するパケットフロー内のインバウンドパケットは、ロードバランサノー
ド１１０によってカプセル化されるので、そのパケットはデカプセル化され、且つ、ノー
ド１３０上のサーバ１３４に対するローカルホストＴＣＰフローに対してリダイレクトさ
れる必要がある。ノード１３０上のロードバランサモジュール１３２は、このデカプセル
化を実行する。同様に、サーバ１３４からのパケットフローにおける発信パケットは、ロ
ードバランサモジュール１３２によってカプセル化され、ファブリック１２０を介して、
パケットフローにおける出口ノードとして機能するロードバランサノード１１０に送信さ
れる。
少なくともいくつかの実施形態において、サーバノード１３０上のロードバランサモジ
ュール１３２もまた、それぞれのサーバノード１３０上のサーバ１３４に対するロードバ
ランシングに関連するローカルな決定を下す。特に、ノード１３０上のロードバランサモ
ジュール１３２は、新たなＴＣＰ接続のための要求の受信に応答して他のＴＣＰフローを
それぞれのサーバ１３４が受諾するかどうかを決定する。上記したように、ロードバラン
サノード１１０はロードバランサモジュール１３２に送信されるすべてのパケットをカプ
セル化するので、ロードバランサモジュール１３２は実際にはクライアント１６０からの
ＴＣＰ同期（ＳＹＮ）パケットを受信しない。その代わりに、ロードバランサモジュール
１３２は、ロードバランサモジュール１３２が受諾または拒絶のいずれかが可能なフロー
追跡部１１６からのカプセル化プロトコル（例えば、ＵＤＰ）に従って、接続要求メッセ
ージを受信する。ロードバランサモジュール１３２が接続要求メッセージを受諾した場合
には、ロードバランサモジュール１３２はローカルホスト宛てのＳＹＮパケットを生成す
る。ローカルホストが接続を受諾した場合には、これはそれぞれのクライアント接続を取
り扱う実際のＴＣＰスタックになる。
少なくともいくつかの実施形態において、接続要求メッセージを受諾すべきかどうかに
ついて決定を下すために、ロードバランサモジュール１３２は、サーバノード１３０上の
現在の資源使用量に関する１以上のメトリクスを観察し、新たな接続を取り扱うのに使用
できる十分な資源が存在する場合には、ロードバランサモジュール１３２はその接続を受
諾する。少なくともいくつかの実施形態において、ロードバランサモジュール１３２によ
って判断された資源のメトリクスは、１以上のＣＰＵの使用、直前の帯域幅の使用量、及
び確立された接続数を含んでもよいが、これらには限定されない。いくつかの実施形態に
おいては、これらのメトリクスの代わりにまたはこれらのメトリクスに加えて、他のメト
リクスが検討できる。例えば、いくつかの実施形態において、ロードバランサモジュール
は、サーバの待ち時間（すなわち、サーバ接続の未処理分の中で使われている時間要求の
量）をメトリックとして判断し、サーバの待ち時間が閾値を超えている場合には、接続要
求を拒絶する。これらのメトリクス及びまたは他のメトリクスを使用することで、ロード
バランサモジュール１３２は、それぞれのサーバ１３４に対して、そのサーバ１３４が新
たなパケットフローを受諾すべきかまたは拒絶すべきかどうか決定できる。少なくともい
くつかの実施形態において、資源の利用率（例えば、Ｎ％の利用率）は、単独にまたは組
み合わせて、且つ、閾値（例えば、９０％の利用率）と比較されたメトリクスから決定さ
れてもよい。決定された資源の利用率が、閾値以上である場合、あるいは、これから追加
される接続が閾値を超える利用率に移行するおそれがある場合には、接続要求は拒絶され
る。
少なくともいくつかの実施形態において、ロードバランサモジュール１３２は、接続要
求メッセージが拒絶されるかどうかを判定するために、確率論的方法を実施してもよい。
上記したように、資源の利用率が閾値以上である場合にすべての接続要求を拒絶する代わ
りに、この方法は、２以上の異なる利用のレベルにおいて異なる確率で接続要求を拒絶し
てもよい。例えば、資源の利用が８０％である場合には、ロードバランサモジュール１３
２は２０％の確率で接続要求を拒絶し、資源の利用が９０％である場合には、ロードバラ
ンサモジュール１３２は２５％の確率で接続要求を拒絶し、資源の利用が９５％である場
合には、ロードバランサモジュール１３２は５０％の確率で接続要求を拒絶し、９８％以
上である場合には、ロードバランサモジュール１３２はすべての接続要求を拒絶する。
少なくともいくつかの実施形態において、各接続要求メッセージは、ロードバランサモ
ジュール１３２によって接続要求メッセージがこれまで何回拒絶されたかの指示を含んで
もよい。ロードバランサモジュール１３０によって受信された接続要求メッセージが、閾
値の回数を超えて拒絶されたことを示す場合には、ロードバランサモジュール１３０は、
サーバノード１３０の性能メトリクスがたとえ接続要求を拒絶すべきであることを示す場
合であっても、接続を受諾してもよい。
場合によっては、接続要求メッセージを送信されたロードバランサモジュール１３２の
すべてが接続要求を拒絶する可能性もある。少なくともいくつかの実施形態において、接
続要求メッセージが無期限にロードバランサモジュール１３２からロードバランサモジュ
ール１３２に戻されることを回避するために、各接続要求メッセージに生存時間が与えら
れてもよい。この生存時間が切れたときは、フロー追跡部ノードは、要求を終結し、現在
は要求に対応できないことをそれぞれのクライアント１６０に通知することができる。
少なくともいくつかの実施形態において、サーバノード１３０上のロードバランサモジ
ュール１３２もまた、ロードバランサノード１１０に対して接続公開を実行する。少なく
ともいくつかの実施形態において、接続公開を実行するために、定期的（例えば、１秒に
１回）または不定期に、各ロードバランサモジュール１３２は、サーバノード１３０上の
ルーティングテーブル（例えば、ｎｅｔｓｔａｔルーティングテーブル）を観察し、アク
ティブな接続（ＴＣＰフロー）のリストを公開してロードバランサノード１１０に戻す。
所定のパケットフローの存在について情報を必要とするロードバランサノード１１０は、
それぞれのパケットフローに対して入口ノードとして且つ一次及び二次フロー追跡部とし
ての役割を果たすロードバランサノード１１０である。いくつかの実施形態においては、
ロードバランサモジュール１３２は、コンシステントハッシュ法の技法を用いて、サーバ
ノード１３０上のアクティブなＴＣＰフローについて情報を必要とするロードバランサノ
ード１１０のリストをフィルタリングする。例えば、ロードバランサモジュール１３２は
、コンシステントハッシュリングに従って所定のパケットフローに対して一次及び二次フ
ロー追跡部としての役割を果たすのがどのロードバランサノード１１０であるかを判定す
ることができる。いくつかの実施形態において、ロードバランサモジュール１３２は、各
パケットフローについてロードバランサモジュール１３２にデータパケットを最後に送信
したのがどのロードバランサノード１１０であるかを追跡し、この情報を用いてパケット
フローに対して入口ノードとして対応しているのがどのロードバランサノード１１０であ
るかを追跡するが、それは入口ノードのみがクライアントデータをロードバランサモジュ
ール１３２に転送するからである。いくつかの実施形態において、ロードバランサモジュ
ール１３２は、次に、パケットフローについて情報を必要とすることを決定したロードバ
ランサノード１１０の各々に関するメッセージを公式化し、そのメッセージをロードバラ
ンサノード１１０に送信し、それぞれのサーバノード１３０がクライアント１６０に対す
る接続をまだ維持していることをノード１１０に通知する。ロードバランサモジュール１
３２によるロードバランサノード１１０へのこの接続公開は、ロードバランサノード１１
０におけるリースの延長と見なされてもよい。ロードバランサノード１１０が、一定の期
間（例えば、１０秒）内の特定のパケットフローを示す接続公開メッセージを受信しなか
った場合には、ロードバランサノード１１０は、解放されてそれぞれのパケットフローの
ことを忘れる。
ロードバランサノードに対するマルチパス・ルーティング
図４は、少なくともいくつかの実施形態において、分散型ロードバランサにおけるルー
ティング及びパケットフローの態様を示す。少なくともいくつかの実施形態において、各
入口ノード（入口ノードは、図４においては入口サーバ１１２として示さる）は、１以上
の公開エンドポイント（例えば、ＩＰアドレス及びポート）にルーティングできる自分の
能力を、例えば、境界ゲートウェイ・プロトコル（ＢＧＰ）を経由して、分散型ロードバ
ランサに関するエッジルータ１０４に広告する。少なくともいくつかの実施形態において
は、各入口ノードがＢＧＰセッション経由でエッジルータ１０４に自身を広告するという
よりむしろ、図５に示されるように、１以上の他の入口ノード、例えば、２つの隣接する
ノードが、エッジルータ１０４とＢＧＰセッションを確立して当該入口ノードを広告する
。
従来のロードバランサは、通常、単一の公開エンドポイントの役割を果たすことのみが
できる。反対に、分散型ロードバランサの実施形態によって、多数のロードバランサノー
ド１１０が単一の公開エンドポイントの役割を果たすことを可能にする。ルータの能力に
依存するならば、このことにより、すべての入口サーバ１１２に対してルーティングされ
た単一のパブリックＩＰアドレスが、エッジルータ１０４を介して全体の帯域幅（例えば
、１６０Ｇｂｐｓ）を取り扱うことができる構成を可能にする。少なくともいくつかの実
施形態において、このことを遂行するために、エッジルータ１０４は、レイヤ４のフロー
単位ハッシュ化マルチパス・ルーティング技法、例えば、等価マルチパス（ＥＣＭＰ）ル
ーティング技法を利用して、各々が同一のパブリックＩＰアドレスを広告する多数の入口
サーバ１１２の全体に亘ってトラフィックを分散する。エッジルータ１０４のフローハッ
シュの部分として、フローに対するレイヤ４の送信元ポート及び宛先ポートを使用して、
入口サーバ１１２のすべてに対して着信パケットを分散することにより、一般的には、入
口サーバ１１２として機能している同一のロードバランサノード１１０にルーティングさ
れた各接続のためにパケットを保持して、パケットが順序から外れるのを回避する。しか
しながら、いくつかの実施形態においては、エッジルータ１０４は、他の技法を使用して
入口サーバ１１２の全体に亘ってトラフィックを分散することに留意されたい。
図４もまた、ネットワーク１００上に実装される２以上の分散型ロードバランサを示す
。２以上の分散型ロードバランサは、各々が複数のサーバ１３０に対応するとともに、各
々が異なるパブリックＩＰアドレスを広告する独立したロードバランサとして各々が行動
し、あるいは、図４に示されるように、２以上の分散型ロードバランサが、各々同一のＩ
Ｐアドレスを広告し、ハッシュ法の技法（例えば、レイヤ４のフロー単位ハッシュ化マル
チパス・ルーティング技法）が境界ルータ１０２において使用されて、パケットフローを
エッジルータ１０４に区分し、そして今度は、エッジルータ１０４がパケットフローを対
応するそれぞれの入口サーバ１１２に分散する。
図５は、少なくともいくつかの実施形態において、入口ノードをエッジルータに広告す
るために境界ゲートウェイ・プロトコル（ＢＧＰ）を使用することを示す。この実施例に
おいて、ロードバランサ実装の中に、入口ノード１１０Ａないし１１０Ｄとしての役割を
果たす４つのロードバランサノードがある。エッジルータ１０４は、クライアント（図示
せず）からの着信パケットをロードバランサノード１１０にルーティングする。少なくと
もいくつかの実施形態において、エッジルータ１０４は、レイヤ４のフロー単位ハッシュ
化マルチパス・ルーティング技法、例えば、等価マルチパス（ＥＣＭＰ）ルーティング技
法に従って、ルーティングの決定を下す。
少なくともいくつかの実施形態において、エッジルータ１０４は、入口ノード１１０に
よって開始されたセッションを広告する境界ゲートウェイ・プロトコル（ＢＧＰ）技術を
介して、ロードバランサ実装の中でクライアントトラフィックを受信するために現在使用
できる入口ノード１１０について学習する。各入口ノード１１０は、エッジルータ１０４
に対して自身を広告するためにＢＧＰを使用することができる。しかしながら、ＢＧＰは
、一般に、収束するのに比較的長い時間（３秒以上）がかかる。各入口ノード１１０がＢ
ＧＰを介して自身を広告する際にこの技法を使用すると、入口ノード１１０がダウンに至
る場合には、エッジルータ１０４上でのＢＧＰセッションがネットワーキングの期間の中
では相当な時間（３秒以上）を要して時間切れになるので、エッジルータ１０４は障害閉
鎖について学習する結果になり、現在のＴＣＰフローを入口ノード１１０に再びルーティ
ングすることになる。
ＢＧＰに伴う収束の問題を回避するため、且つ、ノード１１０を障害からより迅速に回
復させるために、少なくともいくつかの実施形態においては、入口ノード１１０がＢＧＰ
セッションを介してエッジルータ１０４に自身を広告する代わりに、ロードバランサ実装
の中で少なくとも１つの他の入口ノード１１０が、ＢＧＰを介してエッジルータ１０４に
対して入口ノード１１０を広告するための責任を負う。例えば、図５に示すようないくつ
かの実施形態において、所定の入口ノード１１０の左右の隣接する入口ノード１１０、例
えば、ノード１１０の順序リストの左右の隣接物、例えば、ノード１１０によって形成さ
れたコンシステントハッシュリングが、当該所定の入口ノード１１０をエッジルータ１０
４に対して広告してもよい。例えば、図５において、入口ノード１１０Ａは入口ノード１
１０Ｂ及び１１０Ｄを広告し、入口ノード１１０Ｂは入口ノード１１０Ａ及び１１０Ｃを
広告し、入口ノード１１０Ｃは入口ノード１１０Ｂ及び１１０Ｄを広告し、そして入口ノ
ード１１０Ｄは入口ノード１１０Ｃ及び１１０Ａを広告する。入口ノード１１０は、本明
細書において後述するように、お互いの健康をチェックし且つ喧伝する。上記したように
ヘルスチェック方法を使用すれば、不健康なノードを検出することができ、且つ、その情
報を１秒未満、例えば、１００ミリ秒（ｍｓ）でノード１１０の間に伝達することができ
る。ある入口ノード１１０が健康でないと決定されると、その不健康な入口ノードを広告
する入口ノード１１０は、直ちにその不健康なノード１１０の広告を停止する。少なくと
もいくつかの実施形態において、入口ノード１１０は、ＢＧＰセッションについてのＴＣ
Ｐ Ｃｌｏｓｅメッセージまたは同様のメッセージをエッジルータ１０４に送信すること
によって、エッジルータ１０４との間のＢＧＰセッションを終了する。このように、ノー
ド１１０の障害を検出するために、障害のある入口ノード１１０によって確立されたＢＧ
Ｐセッションが時間切れになるのを待つのではなく、障害のある入口ノード１１０の代理
として広告する他の入口ノード１１０が、当該ノード１１０が不健康であることを検出し
たことで、エッジルータ１０４との間で当該入口ノード１１０を広告するＢＧＰセッショ
ンを終了するときに、エッジルータ１０４は障害のあるノード１１０を発見する。ロード
バランサノードの障害を取り扱うことについては、図１８Ａ及び１８Ｂに関連して、本明
細書においてさらに説明する。
図６は、分散型ロードバランシングシステムの少なくともいくつかの実施形態において
、マルチパス・ルーティング方法のフローチャートである。９００に示されるように、ロ
ードバランサ実装の中の入口ノード１１０は、それらに隣接するノード１１０をエッジル
ータ１０４に広告する。少なくともいくつかの実施形態において、入口ノード１１０は、
コンシステントハッシュリングなどのノード１１０の順序リストに従って、それらに隣接
するノード１１０を決定する。少なくともいくつかの実施形態において、入口ノード１１
０は、各々の広告されたノード１１０に対応してエッジルータ１０４に対して確立された
１つのＢＧＰセッションと共に、ＢＧＰセッションを使用して、それらに隣接するノード
１１０をエッジルータ１０４に対して広告する。
９０２に示されるように、エッジルータ１０４は、フロー単位ハッシュ化マルチパス・
ルーティング技法、例えば、等価マルチパス（ＥＣＭＰ）ルーティング技法に従って、ク
ライアント１６０から受信されたトラフィックをアクティブな（広告された）入口ノード
１１０に分散する。少なくともいくつかの実施形態において、エッジルータ１０４は、パ
ブリックＩＰアドレスをクライアント１６０に公表し、入口ノード１１０は、同一のパブ
リックＩＰアドレスをエッジルータ１０４にすべて広告する。エッジルータは、レイヤ４
の送信元ポート及び宛先ポートをエッジルータ１０４のフローハッシュの部分として使用
して、着信パケットを入口ノード１１０の中に分散する。このことにより、通常、同一の
入口ノード１１０に対してルーティングされた各接続に関するパケットを保持することに
なる。
９０２に示されるように、入口ノードは、データフローを目標のサーバノード１３０に
転送する。少なくともいくつかの実施形態において、入口ノード１１０は、そのデータフ
ローについて一次及び二次フロー追跡部ノードと対話して、そのデータフローを目標のサ
ーバノード１３０にマッピングする。したがって、各々の入口ノード１１０は、受信され
たパケットを適切に目標のサーバノード１３０に対して転送するために使用されるノード
１１０を介して、アクティブなデータフローのマッピングを維持する。
９０６から９１０までの要素は、入口ノード１１０の障害を検出すること及びそこから
回復することに関する。９０６に示されるように、入口ノード１１０は、例えば本明細書
に記載されているヘルスチェック技法に従って、入口ノード１１０がダウンしたことを検
出する。ノード１１０のダウンが検出されると、その隣接ノード１１０はエッジルータ１
０４に対する広告を停止する。少なくともいくつかの実施形態において、このことは、そ
れぞれのＢＧＰセッションにおいてエッジルータ１０４に対してＴＣＰ Ｃｌｏｓｅを送
信することを含む。
９０８に示されるように、エッジルータ１０４は、ＢＧＰセッションの終了によって入
口ノード１１０がダウンしたことを検出すると、フロー単位ハッシュ化マルチパス・ルー
ティング技法に従って、クライアント１６０からの着信トラフィックを残りの入口ノード
１１０に対して再分散する。したがって、少なくともいくつかのデータフローは、異なる
入口ノード１１０に対してルーティングされる。
９１０に示されるように、入口ノード１１０は、必要に応じてマッピングを回復し、且
つそのデータフローを適切な目標のサーバノードに転送する。入口ノード１１０上でノー
ド１１０の障害から回復するための方法については、本明細書の他のところで説明する。
１つの実施例として、入口ノード１１０は、現在のマッピングの対象ではないパケットを
受信したときは、コンシステントハッシュリングに従ってコンシステントハッシュ機能を
用いて、データフローに対応するフロー追跡部ノードを決定して、当該フロー追跡部ノー
ドからマッピングを回復する。
非対称のパケットフロー
少なくともいくつかの実施形態において、インバウンドデータに対するアウトバウンド
トラフィックの比率が１より大きい場合に、入口ノードの帯域幅とＣＰＵの使用を効率的
に利用するために、分散型ロードバランシングシステムは、図７に示されるように、サー
バノード１３０からのアウトバウンドパケットを多数の出口ノードに転送する。少なくと
もいくつかの実施形態において、それぞれのサーバノード１３０上のロードバランサモジ
ュール１３２は、各接続に対して、クライアントのエンドポイント／公開エンドポイント
タプルをハッシュ化し、且つ、コンシステントハッシュアルゴリズムを使用して、それぞ
れのアウトバウンドパケットフローに対して出口サーバ１１４としての機能を果たすロー
ドバランサノード１１０を選択する。しかしながら、いくつかの実施形態においては、接
続に対する出口サーバ１１４を選択するために他の方法及び／またはデータが使用される
。選択された出口サーバ１１４は、通常、接続に対する入口サーバ１１２としての機能を
果たすロードバランサノード１１０とは異なるロードバランサノード１１０であるが、必
ずしも必須でない。少なくともいくつかの実施形態においては、そのようなロードバラン
サノード１１０／出口サーバ１１４の障害が存在する場合を除いて、特定の接続に対する
アウトバウンドパケットのすべては、パケットの乱れを避けるために、同一の出口サーバ
１１４に対して転送される。
少なくともいくつかの実施形態において、出口サーバ１１４を選択するためにサーバノ
ード１３０によって使用される方法及びデータは、エッジルータ１０４によって実行され
る入口サーバ１１２を選択するために使用される方法及びデータとは異なる。異なる方法
及びデータを使用すると、一般的には、その接続に対する入口ノードとして選択されたロ
ードバランサノード１１０ではなく、ある所定の接続に対する出口ノードとして選択され
ている異なるロードバランサノード１１０を生じる結果となり、入口ノードとしての機能
を果たす単一のロードバランサノード１１０を通る接続についての発信トラフィックを取
り扱うべき出口ノードとして選択されている多数のロードバランサノード１１０を生じる
結果にもなる。
少なくともいくつかの実施形態において、図７は、非対称のパケットフローをグラフィ
カルに示す。少なくとも１つの接続が、外部ネットワーク１５０上のクライアント１６０
からサーバノード１３０Ａ、１３０Ｂ、１３０Ｃ、及び１３０Ｄの各々まで、入口サーバ
１１２を介して確立されている。少なくともいくつかの実施形態において、接続に対応す
る出口ノードを選択するために、各接続について、それぞれのサーバノード１３０上のロ
ードバランサモジュール１３２は、クライアントのエンドポイント／公開エンドポイント
タプルをハッシュ化し、且つ、コンシステントハッシュアルゴリズムを使用してそれぞれ
のアウトバウンドパケットフローに対して出口サーバ１１４としての機能を果たすロード
バランサノード１１０を選択する。例えば、サーバノード１３０Ａは接続に対する出口サ
ーバ１１４Ａを選択しており、サーバノード１３０Ｂは１つの接続に対する出口サーバ１
１４Ａ及び他の接続に対する出口サーバ１１４Ｂを選択している。しかしながら、いくつ
かの実施形態においては、接続に対する出口ノードを選択するために、他の方法及び／ま
たはデータが使用される。
クライアント接続を欠落せずにロードバランサノード障害から回復する
クライアントトラフィックを受信すべきサーバノード１３０をどれにするか決定するため
に、ロードバランサノード１１０がコンシステントハッシュ法を使用することが可能であ
る一方で、いくつかの接続の長い寿命のために、新たなサーバノード１３０がコンシステ
ントハッシュのメンバーシップに加わる場合や、その後の入口のロードバランサノード１
１０障害が存在する場合には、この方法は存在しているフローを維持することができない
。このシナリオにおいて、障害が発生したノード１１０からフローを引き継ぐロードバラ
ンサノード１１０は、異なるメンバーシップを持つことになるサーバ１３０に対するコン
システントハッシュリングとして選択された元のマッピングを決定することができない。
このため、少なくともいくつかの実施形態においては、ロードバランサノード１１０によ
って分散型ハッシュテーブル（ＤＨＴ）技術が使用されて、接続に対するサーバノード１
３０を選択し、且つ、その選択されたサーバノード１３０に対してパケットをルーティン
グする。ＤＨＴに従って、特定の接続を受信するために一旦サーバノード１３０が選択さ
れると、そのサーバノード１３０が健康のままでいて、且つ、（例えば、接続公開によっ
て）ＤＨＴへのそのようなアクティブな接続の状態を定期的に送信することによって、サ
ーバノード１３０上のロードバランサモジュール１３２がリースの延長を継続すると仮定
した場合、ＤＨＴは、その接続が完了するまでそのマッピングを保持することになる。入
口ノード１１０の障害が、エッジルータ１０４から残りのロードバランサノード１１０に
対するパケットの分散に衝撃を与えると、そのロードバランサノード１１０は異なる組み
合わせのクライアント接続からトラフィックを受信する結果になる。しかしながら、ＤＨ
Ｔはすべてのアクティブな接続を追跡するので、ロードバランサノード１１０はＤＨＴに
問い合わせを行って任意のアクティブなマッピングに関するリースを取得することができ
る。その結果、すべてのロードバランサノード１１０は、正しいサーバノード１３０に対
してトラフィックを渡すので、入口ロードバランサノード１１０に障害が発生する事態が
あっても、アクティブなクライアント接続の障害を回避する。
分散型ロードバランシングシステムにおけるパケットフロー
図８は、少なくともいくつかの実施形態において、分散型ロードバランシングシステム
におけるパケットフローを示す。図８における矢印付きの実線はＴＣＰパケットを表わし
、一方、矢印付きの点線はＵＤＰパケットを表わすことに留意されたい。図８において、
入口サーバ１１２は、エッジルータ１０４を介して、１以上のクライアント１６０からの
ＴＣＰパケットを受信する。ＴＣＰパケットを受信すると、入口サーバ１１２は、サーバ
ノード１３０へのＴＣＰパケットフローに対応するマッピングを自身が持っているかどう
かを判定する。入口サーバ１１２が、ＴＣＰパケットフローに対応するマッピングを有す
る場合には、サーバ１１２は、そのＴＣＰパケットを（例えば、ＵＤＰに従って）カプセ
ル化して、そのカプセル化されたパケットを目標のサーバノード１３０に送信する。入口
サーバ１１２が、ＴＣＰパケットフローに対応するマッピングを持たない場合には、入口
サーバ１１２は、ＴＣＰパケットから抽出されたＴＣＰパケットフローに関する情報を含
むＵＤＰメッセージを一次フロー追跡部１１６Ａに送信して、サーバノード１３０に対す
る接続を確立し、及び／または、ＴＣＰパケットについてのマッピングを取得する。図９
Ａ、９Ｂ、及び図１０Ａないし１０Ｇは、クライアント１６０とサーバノード１３０との
間における接続を確立する方法を示す。サーバノード１３０上のロードバランサモジュー
ル１３２は、サーバノード１３０上のＴＣＰ接続に対する出口サーバ１１４としての機能
を果たすロードバランサノード１１０をランダムに選択し、且つ、出口サーバ１１４を介
して、ＵＤＰカプセル化されたＴＣＰ応答パケットをクライアント１６０に送信する。
図９Ａ及び９Ｂは、少なくともいくつかの実施形態において、分散型ロードバランシン
グシステムにおける接続が確立した場合のパケットフローのフローチャートを提供する。
図９Ａの２００に示されるように、入口サーバ１１２は、エッジルータ１０４を介して、
クライアント１６０からＴＣＰパケットを受信する。２０２において、入口サーバ１１２
が、サーバノード１３０へのＴＣＰフローに対応するマッピングを有する場合には、２０
４に示されるように、入口サーバ１１２は、ＴＣＰパケットをカプセル化して、それぞれ
のサーバノード１３０に送信する。入口サーバ１１２は、１、２または３以上のクライア
ント１６０からの１、２または３以上のＴＣＰフローを連続的に受信し且つ処理すること
に留意されたい。
２０２において、入口サーバ１１２が、ＴＣＰパケットフローに対応するマッピングを
持たない場合には、そのパケットは、クライアント１６０からのＴＣＰ同期（ＳＹＮ）パ
ケットである。２０６に示されるように、ＳＹＮパケットを受信すると、入口サーバ１１
２は、そのＳＹＮパケットからデータを抽出して、そのデータを、例えばＵＤＰメッセー
ジの中で、一次フロー追跡部１１６Ａに転送する。少なくともいくつかの実施形態におい
て、入口サーバ１１２は、コンシステントハッシュ機能に従って、ＴＣＰフローに対する
一次フロー追跡部１１６Ａ及び／または二次フロー追跡部１１６Ｂを決定できる。２０８
において、一次フロー追跡部１１６Ａは、そのデータを例えばハッシュテーブルの中に記
憶し、ＴＣＰ接続のサーバノード１３０側に対する最初のＴＣＰシーケンス番号を生成し
、そのデータ及びＴＣＰシーケンス番号を二次フロー追跡部１１６Ｂに転送する。２１０
において、二次フロー追跡部１１６Ｂもまた、そのデータを記憶するとともに、ＳＹＮ／
ＡＣＫパケットを作成し且つクライアント１６０に送信するが、そのＳＹＮ／ＡＣＫパケ
ットには少なくともＴＣＰシーケンス番号が含まれている。
２１２に示されるように、入口サーバ１１２は、エッジルータ１０４を介して、クライ
アント１６０からのＴＣＰ確認（ＡＣＫ）を受信する。入口ノード１１２は、その時点に
おいて、サーバノード１３０に対するＴＣＰフローに対応するマッピングを持たないので
、２１４において、入口サーバ１１２は、そのＡＣＫパケットから抽出されたデータを含
むメッセージを一次フロー追跡部１１６Ａに送信する。２１６に示されるように、一次フ
ロー追跡部１１６Ａは、そのメッセージを受信すると、記憶されているデータに従ってＴ
ＣＰフローを確認し、ＡＣＫパケットからの承認されたシーケンス番号（＋１）がＳＹＮ
／ＡＣＫの中で送信された値と一致することを確認する。次に、一次フロー追跡部１１６
Ａは、ＴＣＰフローを受信するサーバノード１３０を選択し、データ、ＴＣＰシーケンス
番号、及び選択されたサーバノード１３０上のローカルロードバランサモジュール１３２
のＩＰアドレスを含むメッセージを二次フロー追跡部１１６Ｂに送信する。２１８に示さ
れるように、二次フロー追跡部１１６Ｂもまた、データ及びＴＣＰシーケンス番号を確認
し、ＳＹＮメッセージを作成し、その作成されたＳＹＮメッセージを、選択されたサーバ
ノード１３０上のローカルロードバランサモジュール１３２に送信する。その方法は、図
９Ｂの要素２２０において続く。
図９Ｂの２２０に示されるように、ロードバランサモジュール１３２は、作成されたＳ
ＹＮメッセージに応答して、サーバノード１３０の１以上のメトリクスを調べて、サーバ
ノード１３０が接続を受諾することができるかどうかを判定する。２２２において、ロー
ドバランサモジュール１３２は、当該サーバノード１３０が現在においては接続を受諾す
ることができないと判定した場合には、２２４において、ロードバランサモジュール１３
２は二次フロー追跡部１１６Ｂに伝達する。二次フロー追跡部１１６Ｂは、以前に記憶し
たフローに関する情報を消去する。２２６において、二次フロー追跡部１１６Ｂは、一次
フロー追跡部１１６Ａに伝達する。図９Ａの２１６に示されるように、一次フロー追跡部
１１６Ａは、その後、新たな目標のサーバノード１３０を選択して、二次フロー追跡部１
１６Ｂに伝達する。
２２２において、ロードバランサモジュール１３２は、サーバノード１３０が接続を受
諾できると判定した場合には、図９Ｂの２２８に示されるように、ロードバランサモジュ
ール１３２は、作成されたＳＹＮからＴＣＰ ＳＹＮパケットを構成して、サーバノード
１３０上のサーバ１３４にそのＴＣＰ ＳＹＮパケットを送信する。ＴＣＰ ＳＹＮパケ
ットの送信元ＩＰアドレスは、サーバ１３４がクライアント１６０に対する直接のＴＣＰ
接続を受信したことを確信するように、クライアント１６０の実際のＩＰアドレスが追加
される。ロードバランサモジュール１３２は、ＴＣＰフローについて関連する細部を例え
ばローカルハッシュテーブルの中に記憶する。２３０に示されるように、サーバ１３４は
、ロードバランサモジュール１３２が中断するＳＹＮ／ＡＣＫパケットに応答する。２３
２に示されるように、ロードバランサモジュール１３２は次に、接続情報を含むメッセー
ジを二次フロー追跡部１１６Ｂに送信して、接続が受諾されたことを知らせる。二次フロ
ー追跡部１１６Ｂは、このメッセージを受信すると、２３４において、サーバ１３４に対
するマッピングを記録し、同様のメッセージを一次フロー追跡部１１６Ａに送信し、一次
フロー追跡部１１６Ａもまた、そのマッピング情報を記録する。２３６に示されるように
、一次フロー追跡部１１６Ａは次に、入口サーバ１１２に対してマッピングメッセージを
転送する。入口サーバ１１２は、この後からは、クライアント１６０からサーバ１３０へ
のＴＣＰフローに対応するマッピングを有することになる。
２３８において、入口サーバ１１２は、データフローのために任意にバッファリングさ
れたデータパケットをカプセル化して、サーバノード１３０上のローカルロードバランサ
モジュール１３２に対して転送する。入口サーバ１１２によって受信されたクライアント
１６０からのデータフローのための追加の着信パケットは、カプセル化されて、ロードバ
ランサモジュール１３２に対して直接に転送され、ロードバランサモジュール１３２は、
そのパケットをデカプセル化して、サーバ１３４にデータパケットを送信する。
２４０において、ロードバランサモジュール１３２は、データフローに対応する出口サ
ーバ１１４をランダムに選択する。サーバ１３４からのアウトバウンドＴＣＰパケットは
、ロードバランサモジュール１３２によって中断され、ＵＤＰに従ってカプセル化され、
任意に選択された出口サーバ１１４に転送される。出口サーバ１１４は、その発信パケッ
トをデカプセル化して、そのＴＣＰパケットをクライアント１６０に送信する。
上記したように、２０２において、入口サーバ１１２が、受信されたパケットのＴＣＰ
フローに対応するマッピングを持たない場合には、そのパケットは、クライアント１６０
からのＴＣＰ同期（ＳＹＮ）パケットである。しかしながら、そのパケットは、ＴＣＰ
ＳＹＮパケットではない。例えば、ロードバランサノード１１０の追加または障害のせい
で、ロードバランサノード１１０のメンバーシップが変化した場合には、エッジルータ１
０４は、マッピングを持たない入口サーバ１１２に対して、１以上のＴＣＰフローに対応
するパケットのルーティングを開始する。少なくともいくつかの実施形態において、対応
するマッピングを持たない入口サーバ１１２がこのようなパケットを受信すると、その入
口サーバ１１２は、コンシステントハッシュ機能を用いて、コンシステントハッシュリン
グに従ってＴＣＰフローに対応する一次フロー追跡部１１６Ａ及び／または二次フロー追
跡部１１６Ｂを決定し、一次フロー追跡部１１６Ａまたは二次フロー追跡部１１６Ｂのい
ずれかに伝達してマッピングを要求する。入口サーバ１１２は、フロー追跡部１１６から
ＴＣＰフローに対応するマッピングを受信すると、そのマッピングを記憶して、ＴＣＰフ
ローに対応するＴＣＰパケットのカプセル化及び正しい宛先サーバノード１３０に対する
転送を開始することができる。
ロードバランサノードの細部
少なくともいくつかの実施形態において、ロードバランサノード１１０の各々は３つ
の役割を持つ。
● 入口−クライアント接続においてクライアント１６０からすべての着信パケットを
受信すること、マッピングが分かっている場合にサーバノード１３０にパケットをルーテ
ィングすること、またはマッピングが分かっていない場合にフロー追跡部に伝達すること
。入力ノードからの発信パケットは、入口ノードによって（例えば、ＵＤＰに従って）カ
プセル化される。
● フロー追跡処理−接続状態（例えば、どのサーバノード１３０／サーバ１３４が各
クライアント接続を提供するために割り当てられているか）の記録をつけること。フロー
追跡部もまた、クライアント１６０とサーバ１３４との間の接続を確立することに参加す
る。
● 出口−サーバ１３４から受信されたアウトバウンドパケットをデカプセル化するこ
と及びクライアント１６０に転送すること。
少なくともいくつかの実施形態において、入口の役割の中で、ロードバランサノード１
１０は、クライアントからサーバへのマッピングが分かっている場合には、サーバ１３４
に対してパケットを転送する役割を担い、または、マッピングが分かっていない場合には
、フロー追跡部に対して要求を転送する役割を担う。特定のクライアント接続／データフ
ローについて入口ノードとしての機能を果たしているロードバランサノード１１０は、ク
ライアント接続に対して、一次フロー追跡部または二次フロー追跡部のいずれとしての機
能も果たすが、両方としての機能を果たすことはない。
少なくともいくつかの実施形態において、フロー追跡部の役割の中で、ロードバランサ
ノード１１０は、確立された接続に対応するクライアントからサーバへのマッピングを維
持する役割を担うだけでなく、引き続き確立されている接続の状態を維持する役割をも担
う。２つのフロー追跡部は、各々が個別のクライアント接続にかかわり、一次フロー追跡
部及び二次フロー追跡部と称される。少なくともいくつかの実施形態において、クライア
ント接続に関連するフロー追跡部は、コンシステントハッシュアルゴリズムを用いて決定
される。フロー追跡部もまた、新たなクライアント接続の各々に対応するサーバノード１
３０を擬似ランダムに選択することを含むロードバランシングの機能を実行するが、これ
に限定されるものではない。選択されたサーバノード１３０上のローカルロードバランサ
モジュール１３２は、サーバ１３４が接続を取り扱うことができないと判定した場合には
、接続要求を拒絶する。このことが起こった場合には、フロー追跡部は、他のサーバノー
ド１３０を選択して、他のサーバノード１３０に対して接続要求を送信する。少なくとも
いくつかの実施形態において、所定の接続に対する一次フロー追跡部の役割及び二次フロ
ー追跡部の役割は、異なるロードバランサノード１１０によって実行される。
少なくともいくつかの実施形態において、出口の役割の中で、ロードバランサノード１
１０は、ステートレスであり、サーバノード１３０から受信された着信パケットをデカプ
セル化し、いくつかの確認を実行し、それぞれのクライアント１６０に対してアウトバウ
ンドＴＣＰパケットを転送する。少なくともいくつかの実施形態において、サーバノード
１３０上のローカルロードバランサモジュール１３２は、所定の接続に対応するロードバ
ランサノード１１０を任意に選択する。
ロードバランサノードのコンシステントハッシュリング接続形態
少なくともいくつかの実施形態において、ロードバランサノード１１０は、入力キー空
間（クライアントエンドポイント、公開エンドポイント）のコンシステントハッシュ法に
基づいてリング接続形態を形成する。その入力キー空間は、使用できるフロー追跡部ノー
ドの間で分割され、すべてのフロー追跡部ノードは、そのキー空間に対応する問い合わせ
に答える義務を負う。少なくともいくつかの実施形態において、データは、コンシステン
トハッシュリングにおける後続（例えば、コンシステントハッシュリングにおいて、二次
フロー追跡部ノードは、一次フロー追跡部ノードの後続ノードまたは次のノード）に基づ
いて、一次及び二次フロー追跡部ノードに対して複製される。フロー追跡部ノードがなん
らかの理由でダウンに至る場合には、コンシステントハッシュリングにおける次のロード
バランサノードは、障害が発生したノードのキー空間を要求する。新たなフロー追跡部ノ
ードが加わった場合には、他のロードバランサノードがロードバランサ実装の中で、した
がってコンシステントハッシュリングの中で、構成変更について学習するように、そのノ
ードは自分のエンドポイントを（例えば、図１に示されるような構成サービス１２２によ
り）記録する。フロー追跡部の追加及び障害を取り扱うことについては、図１１Ａないし
１１Ｄを参照して、さらに詳細に説明する。
入口ノード対フロー追跡部ノードの通信
少なくともいくつかの実施形態において、入口ノードとしての機能を果たしているロー
ドバランサノード１１０は、フロー追跡部ノードとしての機能を果たしているロードバラ
ンサノード１１０について構成サービス１２２から学習する。入口ノードは、ロードバラ
ンサ実装の中で、したがってコンシステントハッシュリングの中で、メンバーシップの変
化について、構成サービス１２２を監視する。入口ノードは、その入口ノードが対応する
マッピングを持たないクライアント１６０からパケットを受信したときは、その入口ノー
ドは、コンシステントハッシュ機能を用いて、パケットにサービスすべきフロー追跡部ノ
ードをどれにするかを決定する。少なくともいくつかの実施形態において、ハッシュ機能
への入力は、パケットからの対（クライアントエンドポイント、公開エンドポイント）で
ある。少なくともいくつかの実施形態において、入口ノード及びフロー追跡部ノードは、
ＵＤＰメッセージを用いて通信する。
一次フロー追跡部ノードが新たなパケットフローについて入口ノードからメッセージを
受信した場合には、その一次フロー追跡部ノードは、ＴＣＰシーケンス番号をランダムに
決定して、他のメッセージを二次フロー追跡部ノードに転送する。二次フロー追跡部ノー
ドは、クライアントに対応するＴＣＰ ＳＹＮ／ＡＣＫメッセージを生成する。両方のフ
ロー追跡部は、クライアント接続のエンドポイント対及びＴＣＰシーケンス番号を記憶し
、メモリの圧迫または有効期限切れが原因で状態が除去されるまでは、この情報を保持す
る。
一次フロー追跡部ノードが、ＴＣＰ ＡＣＫパケットを受信した入口ノードからメッセ
ージを受信した場合には、その一次フロー追跡部ノードは、承認されたＴＣＰシーケンス
番号が、ＳＹＮ／ＡＣＫパケットの中で送信されて記憶された値と一致することを検証し
、要求にサービスすべきサーバノード１３０を選択し、二次フロー追跡部ノードに対して
メッセージを転送する。二次フロー追跡部ノードは、その選択されたサーバノード１３０
上のロードバランサモジュール１３２に対してメッセージを送信して、サーバノード１３
０上のＴＣＰスタックによって実際のＴＣＰ接続を開始し、次にサーバノード１３０から
の承認応答を待つ。
二次フロー追跡部ノードが、サーバノード１３０上のロードバランサモジュール１３２
から接続承認を受信した場合には、一次フロー追跡部を通って入口ノードに至り、両方の
ノードにおいて関連するサーバノード１３０に関する情報を記憶する折り返しメッセージ
フローが起動される。このポイントの転送から、入口ノードにおいて受信された追加のＴ
ＣＰパケットは、サーバノード１３０上のロードバランサモジュール１３２に直接に転送
される。
ロードバランサモジュール対ロードバランサノードの通信
少なくともいくつかの実施形態において、すべてのロードバランサモジュール１３２は
、自分のエンドポイントを構成サービス１２２によって記録し、ロードバランサノードの
レイヤにおいて、メンバーシップの変化について連続的に構成サービス１２２を監視する
。少なくともいくつかの実施形態において、ロードバランサモジュール１３２の機能につ
いて、以下説明する。
● 接続公開−定期的に（例えば、１秒ごとに）または不定期に、それぞれのサー バ
ノード１３０上のアクティブな接続の組み合わせ（クライアントエンドポイント、パブリ
ックエンドポイント）を、これらの接続に対応するロードバランサモジュール１３２に対
して最後にパケットを送信した入口ノードに対してだけでなく、これらの接続について責
任を負う一次及び二次フロー追跡部ノードの両方に対しても公開する。接続公開の機能は
、責任を負うロードバランサノード１１０における接続状態についてのリースを更新する
。
● ロードバランサレイヤにおけるメンバーシップの変化の監視。メンバーシップが変
化した場合には、ロードバランサモジュール１３２は、この変更情報を用いて、その接続
に対してこれから責任を負うロードバランサノードに対して直ちにアクティブな接続を送
信する。
分散型ロードバランシングシステムにおけるパケットフローの細部
分散型ロードバランシングシステムは、多数のロードバランサノード１１０を有する。
少なくともいくつかの実施形態において、分散型ロードバランシングシステムにおける各
ロードバランサノード１１０は、サーバ１３４に対するクライアント１６０の接続に関し
て、フロー追跡部ノードの役割、出口ノードの役割、及び入口ノードの役割を果たす。分
散型ロードバランシングシステムはまた、各サーバノード１３０上にロードバランサモジ
ュール１３２を含む。
少なくともいくつかの実施形態において、図１０Ａないし１０Ｇは、分散型ロードバラ
ンシングシステム内のパケットフローを示している。図１０Ａないし１０Ｇにおいて、ロ
ードバランサノード１１０の間で交換されたパケット、及び、ロードバランサノード１１
０とサーバノード１３０との間で交換されたパケットは、ＵＤＰメッセージまたはＵＤＰ
カプセル化されたクライアントＴＣＰパケットのいずれかである。少なくともいくつかの
実施形態において、クライアントＴＣＰパケットのみが境界ルータ１０２との間で移動し
て、ロードバランサノード１１０の北側のネットワーク１００上にカプセル化された形式
で存在する（図１を参照）。図１０Ａないし１０Ｇにおいて、矢印付きの実線はＴＣＰパ
ケットを表わし、一方、矢印付きの点線はＵＤＰパケットを表わしていることに留意され
たい。
少なくともいくつかの実施形態において、分散型ロードバランシングシステムは、単一
ロードバランサノード１１０の障害が発生したときは、確立されている接続を維持しよう
とする。少なくともいくつかの実施形態において、このことは、一次フロー追跡部ノード
及び二次フロー追跡部ノードにおける接続を細部にわたって複製ことによって達成される
が、それは、これらのノードのいずれかに障害が発生した場合に、接続のクライアントか
らサーバへのマッピングは、残っているフロー追跡部ノードによって回復されるからであ
る。少なくともいくつかの実施形態において、いくつかのパケットの消失は、ノードの障
害が発生した場合に起こるが、クライアント／サーバＴＣＰパケット再送が消失パケット
を復元する。
クライアントからのＴＣＰ接続の各々はＴＣＰフローと称され、そのＴＣＰフローは、
クライアントＩＰアドレス、クライアントポート、サーバ（パブリック）ＩＰアドレス、
及びサーバポートからなる４タプルによって一意に識別される。この識別子は、クライア
ント及びパブリックエンドポイント対を示すＣＰまたはＣｃＰｐと略称される。任意の所
定のＴＣＰフロー（またはＣＰ対）に関係するパケットは、上流のエッジルータ１０４か
らのハッシュ化等価マルチパス（ＥＣＭＰ）フロー分散のために、入口サーバ１１２とし
て動作する任意のロードバランサノード１１０上に現れることができる。しかしながら、
ＴＣＰフローに対応するパケットは、通常、転送されるＴＣＰフローを引き起こすリンク
またはロードバランサノード１１０の障害が存在しない限り、同じロードバランサノード
１１０に到達し続ける。上流のルータ１０４からのＴＣＰフローに対応するパケットを受
信するロードバランサノード１１０は、そのＴＣＰフローに対応する入口ノードと称され
る。
少なくともいくつかの実施形態において、コンシステントハッシュ法が使用されるは、
ＴＣＰフローに対して入口ノードとしての機能を果たすロードバランサノード１１０にパ
ケットが到達した場合に、当該入口ノードがＴＣＰフローに対応する状態（すなわち、フ
ロー追跡部ノード）を収容するのがどのロードバランサノード１１０であるかを決定する
ことができるからである。ＣＰ対は、入口ノードによってコンシステントハッシュリング
の中にハッシュ化されて、ＴＣＰフローに関する状態を維持することに責任を持っている
のがどのロードバランサノード１１０であるかを決定する。このノードは、ＴＣＰフロー
に対して一次フロー追跡部ノードとしての機能を果たす。コンシステントハッシュリング
における後続ノードは、ＴＣＰフローに対して二次フロー追跡部としての機能を果たす。
少なくともいくつかの実施形態において、すべてのロードバランサノード１１０は、入
口ノード、一次フロー追跡部ノード、及び二次フロー追跡部ノードとしての機能を果たす
。ＴＣＰフローに対するコンシステントハッシュの結果に依存して、そのＴＣＰフローに
対して入口ノードとしての機能を果たしているロードバランサノード１１０は、そのＴＣ
Ｐフローに対して一次または二次フロー追跡部ノードとしての機能も果たす。しかしなが
ら、少なくともいくつかの実施形態において、異なる物理的なロードバランサノード１１
０は、そのＴＣＰフローに対して一次及び二次フロー追跡部ノードの役割を実行する。
接続の確立
図１０Ａを参照すると、クライアント１６０からの新たな接続は、クライアントＴＣＰ
同期（ＳＹＮ）パケットによって起動される。ロードバランサノード１１０は、そのＳＹ
Ｎパケットを受信したとき、実際には、サーバノード１３０との間で接続を確立しないだ
けでなく、その接続を受信すべきサーバノード１３０を直ちに選択することもない。その
代わり、ロードバランサノード１１０は、クライアントのＳＹＮパケットからの関連デー
タを記憶して、まだ選択されていないサーバノード１３０の代わりにＳＹＮ／ＡＣＫパケ
ットを生成する。図１０Ｃを参照すると、一旦クライアント１６０がＴＣＰのスリーウェ
イハンドシェイクにおいて最初のＡＣＫに応答すると、ロードバランサノード１１０は、
サーバノード１３０を選択して、当該サーバノード１３０に対する等価なＳＹＮパケット
を生成し、そのサーバノード１３０との実際のＴＣＰ接続を確立しようとする。
再び図１０Ａを参照すると、ＴＣＰフローに対して入口サーバ１１２としての機能を果
たしているロードバランサノード１１０においてクライアントＳＹＮパケットを受信する
と、入口サーバ１１２は、ＳＹＮパケットからデータフィールドを抽出して、そのデータ
をＴＣＰフローに対する一次フロー追跡部１１６Ａに転送する。一次フロー追跡部１１６
Ａは、そのデータを例えばハッシュテーブルに記憶し、（ＴＣＰ接続のサーバ側の）最初
のＴＣＰシーケンス番号を生成し、同じデータを二次フロー追跡部１１６Ｂに転送する。
二次フロー追跡部１１６Ｂは、そのＴＣＰシーケンス番号を含むクライアント１６０に対
するＳＹＮ／ＡＣＫパケットを作成する。
図１０Ａにおいて、入口サーバ１１２、一次フロー追跡部１１６Ａ、及び二次フロー追
跡部１１６Ｂの役割は、異なるロードバランサノード１１０によって各々実行される。し
かしながら、いくつか場合においては、ＴＣＰフローに対して入口サーバ１１２としての
機能を果たしているロードバランサノード１１０は、ＴＣＰフローに対して一次フロー追
跡部１１６Ａまたは二次フロー追跡部１１６Ｂとしての機能を果たしている同じノード１
１０である（ただし、両方はない）。パケットフローに対応する入口サーバ１１２が、そ
のフローに対応するフロー追跡部１１６として同じノード１１０上にあるという理由は、
エッジルータ１０４が、フロー単位ハッシュ化マルチパス・ルーティング技法（例えば、
ＥＣＭＰルーティング技法）に従って、フローに対応する入口サーバ１１２を擬似ランダ
ムに選択するからである。その一方、パケットフローに対応するフロー追跡部１１６は、
パケットフローのアドレス情報に適用されるコンシステントハッシュ機能に従って、コン
システントハッシュリング上で決定される。パケットフローに対応する入口サーバ１１２
が、そのパケットフローに対応するフロー追跡部１１６として同じノード１１０上に存在
する場合には、ＳＹＮパケットからのデータが入口サーバ１１２を実装するノード１１０
から他のフロー追跡部１１６ノード１１０に転送されるだけである。例えば、図１０Ｂに
おいて、一次フロー追跡部１１６Ａは、ＴＣＰフローに対する入口サーバ１１２として同
じロードバランサノード１１０Ａ上に存在するが、一方、二次フロー追跡部１１６Ｂは、
異なるロードバランサノード１１０Ｂ上に存在するので、ＳＹＮパケットからのデータは
、（フロー追跡部１１６Ａによって）ノード１１０Ａからロードバランサノード１１０Ｂ
上の二次フロー追跡部１１６Ｂに転送される。
図１０Ｃを参照すると、非ＳＹＮパケットが入口サーバ１１２に到達した場合には、そ
の入口サーバ１１２は、どのサーバノード１３０にそのパケットを転送するかを知ってい
るかまたは知らないかのいずれかである。ＴＣＰフローに対する入口サーバ１１２に到達
する最初の非ＳＹＮパケットは、ＴＣＰのスリーウェイハンドシェイクにおける最初のＴ
ＣＰ承認（ＡＣＫ）パケット（または、ことによると後続のデータパケット）のはずであ
る。そこでは、ＴＣＰ承認番号のフィールドは、図１０ＡにおけるＳＹＮ／ＡＣＫパケッ
トの中で送信されたサーバシーケンス番号（＋１）と一致する。入口サーバ１１２が、対
応するサーバマッピングを持たない非ＳＹＮパケットを受信した場合には、入口サーバ１
１２は、ＴＣＰフローに対応する一次フロー追跡部１１６Ａに対してメッセージを転送す
る。そのメッセージは、シーケンス番号などのＡＣＫパケットからの情報を含み、または
ＡＣＫパケット自身を含む。少なくともある場合においては、一次フロー追跡部１１６Ａ
は、ＴＣＰフローについて記憶されたデータを覚えており、承認シーケンス番号（＋１）
とＳＹＮ／ＡＣＫパケットの中でクライアント１６０に対して送信された値とが一致する
ことを確認する。一次フロー追跡部は、その後、ＴＣＰフローに対応するサーバノード１
３０を選択し、ＴＣＰフローについて以前に記憶されたデータを含む他のメッセージ、サ
ーバシーケンス番号、及び選択されたサーバノード１３０上のロードバランサモジュール
１３２についてのＩＰアドレスを、二次フロー追跡部１１６Ｂに対して転送する。二次フ
ロー追跡部１１６Ｂは、サーバシーケンス番号を確認し、その情報を記録し、生成された
ＳＹＮメッセージを選択されたサーバノード１３０上のロードバランサモジュール１３２
に対して送信する。ＴＣＰフローのＣＰエンドポイント対は、この時からロードバランサ
モジュール１３２／サーバノード１３０にマッピングされる。サーバノード１３０上のロ
ードバランサモジュール１３２は、二次フロー追跡部１１６Ｂから生成されたＳＹＮメッ
セージを受信した場合には、サーバノード１３０上のサーバ１３４に対する正当なＴＣＰ
ＳＹＮパケットを作成する責任がある。ＳＹＮパケットの生成において、送信元ＩＰア
ドレスがクライアント１６０の実際のＩＰアドレスに追加されるのは、サーバ１３４がク
ライアント１６０から直接的なＴＣＰ接続要求を受信したことを信用するからである。ロ
ードバランサモジュール１３２は、ＴＣＰフローについて関連する細部を例えばローカル
なハッシュテーブルに記憶し、ＴＣＰ ＳＹＮパケットをサーバ１３４に送信する（例え
ば、ＳＹＮパケットをサーバ１３４のＬｉｎｕｘカーネルの中に挿入する）。
図１０Ｃにおいて、入口サーバ１１２、一次フロー追跡部１１６Ａ、及び二次フロー追
跡部１１６Ｂの役割は、異なるロードバランサノード１１０によって各々実行される。し
かしながら、いくつか場合においては、ＴＣＰフローに対して入口サーバ１１２としての
機能を果たしているロードバランサノード１１０は、ＴＣＰフローに対して一次フロー追
跡部１１６Ａまたは二次フロー追跡部１１６Ｂとしての機能を果たしている同じノード１
１０である（ただし、両方ではない）。例えば、図１０Ｄにおいて、二次フロー追跡部１
１６Ｂは、ＴＣＰフローに対して入口サーバ１１２として同じロードバランサノード１１
０Ａ上に存在し、一方、一次フロー追跡部１１６Ａは、異なるロードバランサノード１１
０Ｂ上に存在する。
図１０Ｅを参照すると、サーバ１３４（例えば、Ｌｉｎｕｘカーネル）は、ロードバラ
ンサモジュール１３２も中断するＳＹＮ／ＡＣＫパケットに応答する。ＳＹＮ／ＡＣＫパ
ケットは、二次フロー追跡部１１６Ｂからの生成されたＳＹＮ／ＡＣＫにおいて、クライ
アント１６０に最初に配信されたＴＣＰシーケンス番号とは異なるＴＣＰシーケンス番号
を含む（図１０Ａ参照）。ロードバランサモジュール１３２は、着信パケット及び発信パ
ケットにシーケンス番号デルタを適用する責任がある。サーバ１３４からのＳＹＮ／ＡＣ
Ｋパケットもまた、ロードバランサモジュール１３２から二次フロー追跡部１１６Ｂに戻
るメッセージ（例えば、ＵＤＰメッセージ）を起動して、選択されたサーバノード１３０
／ロードバランサモジュール１３２／サーバ１３４に対する接続が成功したことを知らせ
る。二次フロー追跡部１１６Ａは、このメッセージを受信すると、クライアント１６０と
サーバ１３４との間において、クライアント及びパブリックエンドポイント対（ＣＰ）マ
ッピングを約束されたものとして記録し、ＣＰマッピングを同じように記録する一次フロ
ー追跡部１１６Ａに対して同様のメッセージを送信する。一次フロー追跡部１１６Ａは、
その後、ＣＰマッピングメッセージを入口サーバ１１２に対して転送し、このことによっ
て、接続について任意にバッファリングされたデータパケットを、入口サーバ１１２はサ
ーバノード１３０上のローカルロードバランサモジュール１３２に対してカプセル化され
たデータパケットとして転送させる。
図１０Ｆを参照すると、接続のためのＣＰマッピングが入口サーバに分かっているので
、入口サーバ１１２によって受信された接続に関する着信ＴＣＰパケットは、（例えば、
ＵＤＰに従って）カプセル化され、サーバノード１３０上のローカルロードバランサモジ
ュール１３２に対して、カプセル化されたデータパケットとして直接に転送される。ロー
ドバランサモジュール１３２は、データパケットをデカプセル化して、サーバノード１３
０上のサーバ１３４に対し、例えば、カーネルのＴＣＰスタック上にＴＣＰパケットを挿
入することによって、ＴＣＰパケットを送信する。サーバ１３４からのアウトバウンドパ
ケットは、サーバノード１３０上のロードバランサモジュール１３２によって中断され、
（例えば、ＵＤＰに従って）カプセル化され、ロードバランサモジュール１３２がこの接
続に対応する出口サーバ１１４としてランダムに選択する任意のロードバランサノード１
１０に対して転送される。出口サーバ１１４は、パケットをデカプセル化して、そのデカ
プセル化されたパケットをクライアント１１６に対して送信する。選択されたロードバラ
ンサノード１１０の出口機能はステートレスであるので、出口サーバとしての機能を果た
しているロードバランサノード１１０に障害が発生した場合には、異なるロードバランサ
ノード１１０が接続に対する出口サーバ１１４として選択されることができる。しかしな
がら、接続の期間中においては、アウトバウンドパケットの再配列を抑制または排除する
ために、通常は、同じロードバランサノード１１０が出口サーバ１１４として使用される
。
図１０Ｇを参照すると、少なくともいくつかの実施形態において、一次フロー追跡部１
１６Ａによって選択されたサーバノード１３０Ａ（図１０Ｃ参照）上のロードバランサモ
ジュール１３２Ａは、自分が過負荷であると判定した場合には、二次フロー追跡部１１６
Ｂから受信された作成されたＳＹＮメッセージ（図１０Ｃ参照）を拒絶する選択権を有す
る。少なくともいくつかの実施形態において、作成されたＳＹＮメッセージは、生存時間
（ＴＴＬ）の値または最大拒絶数をあらかじめ考慮するカウンタを含んでいる。少なくと
もいくつかの実施形態において、このＴＴＬの値がゼロに達した場合には、ロードバラン
サモジュール１３２Ａは、接続を受諾するかまたは負荷を減らすために接続を中断する。
ロードバランサモジュール１３２Ａが接続を拒絶すると決定した場合には、ＴＴＬの値を
減らして、拒絶メッセージを二次フロー追跡部１１６Ｂに送信する。二次フロー追跡部１
１６Ｂは、ＣＰマッピングをリセットし、同じことを行うために開放メッセージを一次フ
ロー追跡部１１６Ａに送信する。一次フロー追跡部１１６Ａは、他のサーバノード１３０
Ｂ上の新たなロードバランサモジュール１３２Ｂを選択し、新たな目標メッセージを二次
フロー追跡部１１６Ｂに返送し、二次フロー追跡部１１６Ｂは新たに作成されたＳＹＮメ
ッセージを新たに選択されたロードバランサモジュール１３２Ｂに対して送信する。パケ
ット廃棄は、このシーケンスが完了することができない結果になることに留意されたい。
しかしながら、クライアント１６０からの再送は、一次フロー追跡部１１６Ａにおいてロ
ードバランサモジュールの選択プロセスを再び起動し、一次フロー追跡部１１６Ａは、作
成されたＳＹＮパケットの前回の拒絶について学習しなかった場合に、必ずしも必要では
ないが、接続に対して同じロードバランサモジュール１３２を選択する。
少なくともいくつかの実施形態において、ＴＴＬカウンタは、サーバノード１３０に対
して連続的に接続要求が送信されることを回避するために使用され、このことは、例えば
、すべてのサーバノード１３０がビジーである場合に発生する。少なくともいくつかの実
施形態において、ロードバランサモジュール１３２がそれぞれのサーバノード１３０の代
理として、接続要求を拒絶するたびに、当該ロードバランサモジュール１３２はＴＴＬカ
ウンタを減らす。フロー追跡部ノード１１６は、ＴＴＬカウンタを監視して、ＴＴＬカウ
ンタがゼロでない（または、ある特定の閾値を超えない）限り、他のサーバノード１３０
を選択して、再度試みる。ＴＴＬカウンタがゼロに達した（または、当該特定の閾値に達
した）場合には接続要求は取り下げられ、その接続のために選択されたサーバノード１３
０の１つに対して接続要求を送信するためのフロー追跡部ノード１１６によってなされる
試みはもはやできない。少なくともいくつかの実施形態において、エラーメッセージがそ
れぞれのクライアント１６０に送信される。
少なくともいくつかの実施形態において、分散型ロードバランサシステムは、多くのパ
ブリックＩＰアドレスをサポートする。したがって、クライアント１６０は、同じクライ
アントのポート番号から２つの異なるパブリックＩＰアドレスまでの２つのＴＣＰ接続を
開始することが可能である。これらのＴＣＰ接続は、クライアント１６０の観点からは区
別されるが、内部的には、分散型ロードバランサシステムは同じサーバノード１３０に対
して接続をマッピングするので、このことで衝突を生じる結果となる。少なくともいくつ
かの実施形態において、衝突の可能性を検出し且つ取り扱うためには、ロードバランサモ
ジュール１３２は、図１０Ｃ及び１０Ｄに示されるように、生成されたＳＹＮパケットを
二次フロー追跡部１１６Ｂから受信すると、アドレス情報をそのアクティブな接続と比較
して、この接続が衝突を引き起こす可能性がある場合には、図１０Ｇに示されるように、
その接続要求を拒絶する。
ロードバランサノードの障害及び追加の取り扱い
従来の多くのロードバランサにおいて、ロードバランサの障害が発生すると、いくつか
のまたはすべての存在している接続は失われる。少なくともいくつかの実施形態では、単
一のロードバランサノード１１０の障害発生において、分散型ロードバランシングシステ
ムが少なくともいくつかの確立された接続を維持するのは、クライアント及びサーバが、
接続が正常に完了するまで、接続によってパケットの交換を継続できるからである。さら
に、分散型ロードバランシングシステムは、障害の時点において確立されているプロセス
の中に存在していた接続に対するサービスを継続する。
分散型ロードバランシングシステムの少なくともいくつかの実施形態において、単一の
ロードバランサノード１１０に障害が発生した場合に備えて、存在中のクライアント接続
を回復する障害回復プロトコルが実装されている。しかしながら、多数のロードバランサ
ノード１１０に障害が発生すると、クライアント接続の消失を招く結果となる。少なくと
もいくつかの実施形態において、クライアント１６０とサーバ１３４との間のＴＣＰ再送
は、後続のロードバランサノード１１０の障害を回復する手段として使用される。
潜在的なロードバランサノード１１０の障害に加えて、新たなロードバランサノード１
１０が分散型ロードバランサシステムに追加される。これらの新たなノード１１０は、ロ
ードバランサレイヤに、したがって、コンシステントハッシュリングに追加され、存在中
のクライアント接続に関するロードバランサノード１１０の役割は、必要に応じて、当該
変更に従って調整される。
フロー追跡部ノードの障害及び追加の取り扱い
少なくともいくつかの実施形態において、各々の接続が確立されている場合には（例え
ば、図１０Ａないし１０Ｇ参照）、その接続状態情報は、一次及び二次フロー追跡部と称
される、２つのロードバランサノード１１０を通る。一次及び二次フロー追跡部は、例え
ば、ハッシュ機能入力として（クライアントＩＰ：ポート、パブリックＩＰ：ポート）タ
プルを使用するコンシステントハッシュアルゴリズムを使用して決定される。単一のロー
ドバランサノード１１０に障害が発生した場合に、少なくとも１つの生き残っているロー
ドバランサノード１１０は、コンシステントハッシュ機能によるマッピングを継続し、接
続に対して選択されたサーバノード１３０に対してパケットを導くための接続に関する必
要な状態情報を有する。さらに、コンシステントハッシュリングにロードバランサノード
１１０が追加された場合には、接続に関する状態情報は、適切なフロー追跡部に対して更
新される。
図１１Ａないし１１Ｄは、少なくともいくつかの実施形態において、ロードバランサノ
ードコンシステントハッシュリングにおいてメンバー構成に影響する事象の取り扱いを示
す。これらの事象は、新たな一次フロー追跡部ノードの追加、新たな二次フロー追跡部ノ
ードの追加、一次フロー追跡部ノードの障害、及び二次フロー追跡部ノードの障害を含ん
でいるが、これらに限定されない。
図１１Ａは、コンシステントハッシュリングへの新たな一次フロー追跡部ノードの追加
の取り扱いを示す。図１１Ａの上位の並びは、１以上のクライアント接続に対する一次フ
ロー追跡部としてのフロー追跡部１１６Ａ、及び同じ接続に対する二次フロー追跡部とし
てのフロー追跡部ノード１１６Ｂを示す。図１１Ａの下位の並びにおいて、新たなフロー
追跡部ノード１１６Ｃが追加されており、クライアント接続に対する一次フロー追跡部に
なっている。コンシステントハッシュリングにおいて、以前は一次フロー追跡部であった
フロー追跡部ノード１１６Ａは、二次フロー追跡部になり、一方、以前は二次フロー追跡
部であったフロー追跡部ノード１１６Ｂは、次のフロー追跡部になっている。フロー追跡
部１１６Ａ及び１１６Ｂによって維持されていたクライアント接続に対する状態情報は、
新たな一次フロー追跡部１１６Ｃに提供される。さらに、フロー追跡部１１６Ｂは、二次
フロー追跡部の役割において、自分が以前追跡していた接続を「忘れる」。
図１１Ｂは、コンシステントハッシュリングへの新たな二次フロー追跡部ノードの追加
の取り扱いを示す。図１１Ｂの上位の並びは、１以上のクライアント接続に対する一次フ
ロー追跡部としてのフロー追跡部１１６Ａ、及び同じ接続に対する二次フロー追跡部とし
てのフロー追跡部ノード１１６Ｂを示す。図１１Ｂの下位の並びにおいて、新たなフロー
追跡部ノード１１６Ｃが追加されており、クライアント接続に対する二次フロー追跡部に
なっている。コンシステントハッシュリングにおいて、フロー追跡部ノード１１６Ａは、
接続に対する一次フロー追跡部として残り、一方、以前は二次フロー追跡部であったフロ
ー追跡部ノード１１６Ｂは、次のフロー追跡部になる。フロー追跡部１１６Ａ及び１１６
Ｂによって維持されていたクライアント接続に対する状態情報は、新たな二次フロー追跡
部１１６Ｃに提供される。さらに、フロー追跡部１１６Ｂは、二次フロー追跡部の役割に
おいて、自分が以前追跡していた接続を「忘れる」。
図１１Ｃは、コンシステントハッシュリングにおいて、一次フロー追跡部ノードの障害
の取り扱いを示す。図１１Ｃの上位の並びは、コンシステントハッシュリングにおいて、
１以上のクライアント接続に対する一次フロー追跡部としてのフロー追跡部１１６Ａ、同
じ接続に対する二次フロー追跡部としてのフロー追跡部ノード１１６Ｂ、及び次のフロー
追跡部としてのフロー追跡部ノード１１６Ｃを示す。図１１Ｃの下位の並びにおいて、一
次フロー追跡部ノード１１６Ａには障害は発生している。フロー追跡部ノード１１６Ｂは
、接続に対して一次フロー追跡部になり、一方、フロー追跡部ノード１１６Ｃは、接続に
対して二次フロー追跡部になる。フロー追跡部１１６Ｂによって維持されていたクライア
ント接続に対する状態情報は、新たな二次フロー追跡部１１６Ｃに提供される。
図１１Ｄは、コンシステントハッシュリングにおいて、二次フロー追跡部ノードの障害
の取り扱いを示す。図１１Ｄの上位の並びは、コンシステントハッシュリングにおいて、
１以上のクライアント接続に対する一次フロー追跡部としてのフロー追跡部１１６Ａ、同
じ接続に対する二次フロー追跡部としてのフロー追跡部ノード１１６Ｂ、及び次のフロー
追跡部としてのフロー追跡部ノード１１６Ｃを示す。図１１Ｄの下位の並びにおいて、二
次フロー追跡部ノード１１６Ｂには障害は発生している。フロー追跡部ノード１１６Ａは
、接続に対する一次フロー追跡部として残り、一方、フロー追跡部ノード１１６Ｃは、接
続に対して二次フロー追跡部になる。フロー追跡部１１６Ｂによって維持されていたクラ
イアント接続に対する状態情報は、新たな二次フロー追跡部１１６Ｃに提供される。
少なくともいくつかの実施形態において、サーバノード１３０上のロードバランサモジ
ュール１３２は、ロードバランサノード１１０に対して接続公開を実行する。少なくとも
いくつかの実施形態において、接続公開は、サーバノード１３０からフロー追跡部ノード
及び入口ノードとしての機能を果たしているロードバランサノード１１０に対して、現在
の接続状態情報を定期的（例えば、１秒ごとに）または不定期に推し進める。当該接続公
開は、接続に対する一次及び二次フロー追跡部ノードの両方に対する接続マッピングを更
新または回復する役割を果たす。少なくともいくつかの実施形態において、ロードバラン
サモジュール１３２は、例えば、図１１Ａないし１１Ｄに示されるようなフロー追跡部の
メンバーシップの変化を検出する。検出に応答して、ロードバランサモジュール１３２は
、一次及び二次フロー追跡部ノードにおける接続に対する状態情報を追加するために接続
公開を実行し、それによって、メンバーシップが変化した場合には、接続に対する変更を
行う。接続公開は、多数のロードバランサノードに障害が発生した場合に、少なくともい
くつかの確立された接続が回復できることに留意されたい。
障害に関するメッセージフロー
少なくともいくつかの実施形態において、一次及び二次フロー追跡部ノードの間のプロ
トコルには、訂正機能または同期機能が含まれる。例えば、図１１Ａを参照すると、新た
なフロー追跡部ノード１１６Ｃがコンシステントハッシュリングに加わった場合には、当
該新たなフロー追跡部ノード１１６Ｃは、いくつかの接続数（〜１／Ｎ）に関するコンシ
ステントハッシュのキー空間に対して権利を主張し、エッジルータ１０４からのこれらの
接続に関するトラフィックの受信を開始する。しかしながら、当該新たなフロー追跡部ノ
ード１１６Ｃは、接続のために記憶された状態をなにも持っていないので、フロー追跡部
ノード１１６Ｃは、各パケットに対してあたかもクライアント１６０から受信された最初
のパケットであるかのように操作する。一次フロー追跡部は、ＳＹＮパケットに応答して
サーバＴＣＰシーケンス番号を生成する責任があり（例えば、図１０Ａ参照）、且つ、ク
ライアント１６０からの最初のＡＣＫパケットに応答してサーバノード１３０を選択する
責任があり（例えば、図１参照）、これら生成された値は、以前の一次フロー追跡部（図
１１Ａにおけるフロー追跡部ノード１１６Ａ）によって選択された値と一致しない。しか
しながら、少なくともいくつかの実施形態におけるコンシステントハッシュアルゴリズム
は、以前の一次フロー追跡部（図１１Ａにおけるフロー追跡部ノード１１６Ａ）に対して
二次フロー追跡部の役割を割り当て、このフロー追跡部は接続について以前に記憶された
状態をなおも保持する。したがって、少なくともいくつかの実施形態において、二次フロ
ー追跡部（図１１Ａにおけるフロー追跡部ノード１１６Ａ）が、一次フロー追跡部１１６
Ｃから受信された情報の中に不一致を検出した場合には、二次フロー追跡部は、更新メッ
セージを一次フロー追跡部１１６Ｃに返送して、接続に対してフロー追跡部としての機能
を果たしている２つのロードバランサノード１１０を同期させることができる。同様の方
法は、コンシステントハッシュリングのメンバー構成において他の変化があった後にフロ
ー追跡部を同期させるために使用される。
ロードバランサモジュールの詳細
少なくともいくつかの実施形態において、ロードバランサモジュール１３２は、サーバ
ノード１３０の各々の上に存在する分散型ロードバランサシステムの構成要素である。ロ
ードバランサモジュール１３２の役割は、ロードバランサノード１１０から受信されたパ
ケットをデカプセル化すること及びそのデカプセル化されたパケットをサーバノード１３
０上のサーバ１３４に対して送信すること、及び、サーバ１３４からの発信パケットをカ
プセル化すること、及びそのカプセル化されたパケットをロードバランサノード１１０に
対して送信することが含まれるが、これらに限定されない。
少なくともいくつかの実施形態において、入口サーバ１１２としての機能を果たしてい
るロードバランサノード１１０からサーバノード１３０上のロードバランサモジュール１
３２に対する着信パケットは、実際のクライアントデータパケットをカプセル化するステ
ートレスプロトコル（例えば、ＵＤＰ）のパケットである。カプセル化されたクライアン
トデータパケットの各々は、送信元アドレスとしてのそれぞれのクライアント１６０の最
初のクライアントＩＰポート及び宛先アドレスとしてのサーバ１３４のパブリックＩＰポ
ートを有する。ロードバランサモジュール１３２は、クライアントデータパケットのカプ
セル化を外して、例えば、ローカルホストのＴＣＰフローに対してパケットを転送するこ
とによって、そのパケットをサーバノード１３０上のそれぞれのサーバ１３４に対して送
信する。
少なくともいくつかの実施形態において、サーバ１３４から出口サーバ１１４としての
機能を果たしているロードバランサノード１１０に対する発信パケットは、発信ＩＰパケ
ットをカプセル化するステートレスプロトコル（例えば、ＵＤＰ）のパケットである。ロ
ードバランサモジュール１３２は、発信ＩＰパケットをカプセル化して、そのカプセル化
されたパケットを出口サーバ１１４に対してファブリック１２０を介して送信する。カプ
セル化された発信ＩＰパケットの各々は、送信元アドレスとしてのサーバ１３４のパブリ
ックＩＰポート及び宛先アドレスとしてのそれぞれのクライアント１６０のクライアント
ＩＰポートを有する。
ロードバランサモジュールの機能
少なくともいくつかの実施形態において、サーバノード１３０上のロードバランサモジ
ュール１３２の機能は、以下の１以上を含む、これらに限定されない。
● ロードバランサノード１１０、例えば、クライアント１６０に対する接続を取り扱
っている入口サーバ１１２からのＵＤＰトンネルを終端すること。これは、入口サーバ１
１２から受信した着信クライアントデータパケットのＵＤＰカプセルを外すことを含む。
● 接続に関する発信トラフィックを受信する出口サーバ１１４を選択すること。
● それぞれのサーバ１３４に対する接続上の発信ＩＰパケットを中断すること、接続
に関する出力ＩＰパケットをカプセル化すること、及び当該カプセル化されたパケットを
出口サーバ１１４に送信すること。
● 着信及び発信パケット内のシーケンス番号を分解するのは、フロー追跡部ノード１
１６がクライアント１６０に対してＳＹＮ／ＡＣＫを送信した際に、シーケンス番号をフ
ロー追跡部ノード１１６によって生成されたシーケンス番号に揃えるからである。
● それぞれのサーバ１３４に対する接続を受諾するかまたは拒絶するかどうかについ
て、例えば、それぞれのサーバ１３４の現在の負荷を示す１以上のメトリクスに基づいて
決定すること。
● クライアントＩＰポートアドレスに対するアクティブな接続が存在する場合に、衝
突を回避するために、それぞれのサーバ１３４に対する同じクライアントＩＰポートアド
レスからの接続を検出すること及び拒絶すること。
● 接続追跡及び接続公開。
ロードバランサモジュールの構成情報
少なくともいくつかの実施形態において、ロードバランサモジュール１３２の各々は、
自分の構成に関する１つ以上の情報の組み合わせ、すなわち、ロードバランサノード１１
０のエンドポイントの組み合わせ、対応すべき有効なパブリックＩＰアドレスの組み合わ
せ、及び、それぞれのサーバ１３４が着信接続を受諾するポート番号を取得してローカル
に記憶する。ただし、これらの情報に限定するものではない。少なくともいくつかの実施
形態において、この情報は、図１に示されるように、分散型ロードバランサシステムの構
成サービス１２２の構成要素から取得され、またはアクセス処理若しくは問い合わせ処理
によって更新される。いくつかの実施形態においては、情報を取得する他の方法が使用さ
れる。
ロードバランサモジュールのパケット取り扱い
少なくともいくつかの実施形態におけるインバウンドトラフィック及びアウトバウンド
トラフィックに対するロードバランサモジュール１３２の操作について、以下説明する。
少なくともいくつかの実施形態において、ロードバランサモジュール１３２によってイン
バウンドデータトラフィックが受信された場合には、そのデータパケットは、ＵＤＰパケ
ットからデカプセル化されて、そのデカプセル化されたＴＣＰパケット内の宛先アドレス
は、構成された有効なパブリックＩＰアドレスの組み合わせに対して最初に確認される。
一致しない場合には、パケットは廃棄されるかまたは無視される。少なくともいくつかの
実施形態において、ロードバランサモジュール１３２は、シーケンス番号がクライアント
１６０に対してＳＹＮ／ＡＣＫパケットを送信したフロー追跡部ノード１１６によって生
成されてランダムに選択されたシーケンス番号と一致するように、ＴＣＰヘッダにおいて
定数デルタによってシーケンス番号を調整する。ロードバランサモジュール１３２は、「
クライアント対パブリック」エンドポイントから「クライアント対サーバ」エンドポイン
トまでのマッピングを内部状態として記録する。
少なくともいくつかの実施形態において、ロードバランサモジュール１３２は、サーバ
１３４からのアウトバウンドＴＣＰパケットに関して、その内部状態を最初にチェックし
て、そのパケットはロードバランサモジュール管理しているアクティブな接続に対するも
のかどうかを判定する。アウトバウンドＴＣＰパケットがアクティブな接続でない場合に
は、ロードバランサモジュール１３２は、パケットをすぐに通過させる。アウトバウンド
ＴＣＰパケットがアクティブな接続である場合には、ロードバランサモジュール１３２は
、発信ＴＣＰパケットを、例えば、ＵＤＰに従って、カプセル化して、この接続に対して
出口サーバ１１４として選択されたロードバランサノード１１０に対して、そのカプセル
化されたパケットを転送する。少なくともいくつかの実施形態において、ロードバランサ
モジュール１３４は、クライアント１６０に対してＳＹＮ／ＡＣＫパケットを送信したフ
ロー追跡部ノード１１６によって生成されたシーケンス番号に揃えるように、ロードバラ
ンサモジュール１３４は、発信ＴＣＰパケットにおいて定数デルタによってＴＣＰシーケ
ンス番号を調整する。
接続追跡
少なくともいくつかの実施形態において、各サーバノード１３０上のロードバランサモ
ジュール１３２は、それぞれのサーバ１３４に対するアクティブなクライアント接続のす
べてに関する接続の詳細を含んでいるハッシュテーブルを管理する。少なくともいくつか
の実施形態において、ハッシュテーブルに対するキーは、（クライアントＩＰポート、パ
ブリックＩＰポート）タプルである。少なくともいくつかの実施形態において、各クライ
アント接続に関する接続状態は、以下に示す１以上のものを含むが、これらに限定されな
い。
● クライアントＩＰポート
● パブリックＩＰポート
● フロー追跡部ノード１１６によって提供された初期サーバＴＣＰシーケンス番号
● サーバＴＣＰシーケンス番号のデルタ
● 最初の一次フロー追跡部ＩＰアドレス
● 最初の二次フロー追跡部ＩＰアドレス
● 最後に検出された入口サーバ１１２のＩＰアドレス
● このエントリに対する有効期限
● 最も過去に使用された（ＬＲＵ）／衝突インデックス
少なくともいくつかの実施形態において、各ロードバランサモジュール１３２は、すべ
てのアクティブなクライアント接続に関して、一次及び二次フロー追跡部ノードに対する
接続公開メッセージを定期的に生成する。少なくともいくつかの実施形態において、/ｐ
ｒｏｃ/ｎｅｔ/ｔｃｐの内容が、スキャンされ且つロードバランサモジュールのハッシュ
テーブルの中で、アクティブな接続と交差するのは、Ｌｉｎｕｘカーネルが接続の追跡を
停止するまで、アクティブな接続がフロー追跡部ノードに対する公開を継続するからであ
る。接続公開については、本明細書の中において後で詳細に説明する。
シーケンス番号の分解処理
上記したように、少なくともいくつかの実施形態において、ロードバランサノード１１
０は、クライアント１６０のＳＹＮパケットに応答して、ＳＹＮ／ＡＣＫパケットをサー
バ１３４の代理として生成する。クライアント１６０がＡＣＫパケット（ＴＣＰのスリー
ウェイシェイクハンド）を送信した後のみしか、ロードバランサモジュール１１０は、サ
ーバノード１３０上のロードバランサモジュール１３２に対して任意のデータを送信する
ことはない。ロードバランサモジュール１３２がクライアント接続を確立することを最初
に指示された場合には、ロードバランサモジュール１３２は、ローカルにＳＹＮパケット
を生成してサーバノード１３０上のサーバ１３４との間でＴＣＰ接続を開始し、サーバ１
３４の対応ＳＹＮ／ＡＣＫパケットを中断する。通常、サーバ１３４（例えば、サーバノ
ード１３０上のＬｉｎｕｘカーネル）は、ロードバランサノード１１０からのＳＹＮ／Ａ
ＣＫパケットにおいて受信されたクライアントのものとは全体的に異なるＴＣＰシーケン
ス番号を選択する。したがって、少なくともいくつかの実施形態においては、ロードバラ
ンサモジュール１３２は、クライアント１６０とサーバ１３４との間のＴＣＰ接続におけ
るすべてのパケット内のシーケンス番号に対して訂正を行う。少なくともいくつかの実施
形態において、ロードバランサモジュール１３２は、ロードバランサノード１１０によっ
て生成されたシーケンス番号とサーバ１３４によって生成されたシーケンス番号との差分
を計算して、ＴＣＰ接続に対するハッシュテーブルのエントリに差分をデルタ値として記
憶する。接続中にクライアント１６０から着信データパケットが到達した場合には、ＴＣ
Ｐヘッダは、サーバ１３４によって使用されるシーケンス番号と整合しない承認番号を有
することになるので、ロードバランサモジュール１３２は、（例えば、２つの補数を用い
て）ＴＣＰヘッダ内のシーケンス番号の値からデルタ値を減算する。ロードバランサモジ
ュールはまた、接続中にサーバ１３４からクライアント１３０に対するアウトバウンドパ
ケット内のシーケンス番号にデルタ値を加算する。
分散型ロードバランサシステムにおけるヘルスチェック
分散型ロードバランサシステムの少なくともいくつかの実施形態において、以下に示す
理由の少なくとも一つから、ロードバランサノード１１０は、ロードバランサの実装（す
なわち、健康なロードバランサノード１１０及びサーバノード１３０の）において健康な
メンバーの一貫した表示を要求する。
● ロードバランシング―ロードバランサノード１１０は、サーバノード１３０の障害
を検出し、クライアントトラフィックを受諾できる健康なサーバノード１３０の組み合わ
せに集中する必要がある。
● 分散化状態の管理−ロードバランサは、（例えば、コンシステントハッシュ法のメ
カニズムに従って）多数のロードバランサノード１１０に亘って共有され／複製される状
態を有する分散型システムである。クライアントトラフィックを適切に取り扱うために、
各ロードバランサノード１１０は、ロードバランサの実装において健康なメンバーノード
１１０の一貫した表示を必要とする。
このことを達成するために、分散型ロードバランサシステムの少なくともいくつかの実
施形態において、ロードバランサの実装においてノードを監視するヘルスチェックプロト
コルの実施形態を実現して、できるだけ速く不健康なノードを検出する。ヘルスチェック
プロトコルは、ロードバランサの実装においてノード間に健康情報を伝搬して、それらの
ノードが健康なノードの組み合わせに集中することを可能にする方法を提供する。さらに
、ヘルスチェックプロトコルは、ロードバランサの実装において、健康な／不健康なノー
ド及び状態の変化を報告するメカニズムを提供する。
少なくともいくつかの実施形態において、ヘルスチェックプロトコルは、以下に示す１
つ以上の仮定に基づく。しかし、これらに限定されるものではない。
● ロードバランサの実装において、すべてのノードが分かっている（すなわち、ヘル
スチェックプロトコルは、発見することを実行しない）。
● すべてのノードの障害はフェイルストップである。
● ノード間のすべてのメッセージは、ステートレスプロトコル（例えば、ＵＤＰ）メ
ッセージであり、当該メッセージは、削除され、遅延され、複製され、または破損される
。メッセージ配信についての保障はない。
少なくともいくつかの実施形態では、ロードバランサの実装におけるノード（例えば、
ロードバランサノード１１０またはサーバノード１３０）は、以下に示す条件のもとでは
健康であると見なされる。
● ノードの内部の構成要素のすべてが準備状態（クライアントトラフィックを取り扱
うための準備）である。
● （少なくともクライアント・トラフィックフローに関するネットワーク・インター
フェイス制御部（ＮＩＣ）についての）ノードの着信／発信ネットワークリンクが健康で
ある。
図１２は、少なくともいくつかの実施形態において、ヘルスチェック間隔に従った各ロ
ードバランサノードによって実行されるヘルスチェック方法の上位のフローチャートであ
る。１０００に示されるように、各ロードバランサの間隔、例えば、１００ミリ秒ごとに
、各ロードバランサ（ＬＢ）ノード１１０は、少なくとも１つの他のＬＢノード１１０及
び少なくとも１つのサーバノード１３０のヘルスチェックをする。１００２に示されるよ
うに、ロードバランサノード１１０は、ヘルスチェックに従って、ローカルに記憶された
自分の健康情報を更新する。１００４に示されるように、ロードバランサノード１１０は
、その後、少なくとも１つの他のロードバランサノード１１０をランダムに選択して、選
択されたロードバランサノード１１０に対して自分の健康情報を送信する。少なくともい
くつかの実施形態において、ノード１１０はまた、１以上のサーバノード１３０、例えば
、ノード１１０によってヘルスチェックされた同じサーバノード１３０に対して、健康な
ロードバランサノード１１０のリストを送信する。図１２の要素については、以下、詳細
に説明する。
ヘルスチェックプロトコルの少なくともいくつかの実施形態において、ロードバランサ
ノード１１０は自分自身の健康を他のロードバランサノード１１０に主張することはない
。これと反対に、１以上の他のロードバランサノード１１０は、当該ノード１１０にヘル
スチェックを行う。例えば、少なくともいくつかの実施形態において、各ロードバランサ
ノード１１０は、定期的または不定期にランダムに１以上の他のノード１１０を選択して
、ヘルスチェックを行う。他の実施例のように、少なくともいくつかの実施形態において
、１以上の他のロードバランサノード１１０、例えば、コンシステントハッシュリングな
どのノード１１０の順序付けリスト中の或る所定のロードバランサノード１１０に最も近
くに隣接する２つは、それぞれ定期的または不定期に当該所定のノード１１０のヘルスチ
ェックをする。少なくともいくつかの実施形態において、ノード１１０のヘルスチェック
は、図２３に示されるように、ノード１１０上のＮＩＣ１１１４に対して送信される健康
ｐｉｎｇの使用を含む。少なくともいくつかの実施形態において、第１のノード１１０が
ヘルスチェックを介して第２のノード１１０が健康であると判定した場合には、当該第１
のノード１１０は、当該ロードバランサノード１１０におけるローカルな健康情報に記憶
されている当該第２のノード１１０についての心拍カウンタを更新（例えば、インクリメ
ント）する。第１のノード１１０は、自分のローカルな健康情報を、ロードバランサ実装
における１以上の他のロードバランサノード１１０に対して定期的または不定期に送信し
、これによって、適宜自分自身のローカルな健康情報を（例えば、第２のノードについて
の心拍カウンタをインクリメントすることによって）更新し、自分の更新されたローカル
な健康情報を、１以上の他のノード１１０に対して送信する。第２のノード１１０につい
ての心拍情報は、その後、ロードバランサ実装における他のノード１１０に対して伝搬さ
れる。第２のノード１１０が健康である限り、第２のノード１１０から到達可能な他のす
べてのノード１１０はしたがって、常にインクリメントされている第２のノード１１０の
心拍カウンタを、例えば、１秒に１度または毎１０秒に１度、監視する必要がある。第２
のノード１１０のヘルスチェックをするノード（複数可）１１０によって、第２のノード
１１０が不健康であることが検出された場合には、ヘルスチェックをしているノード１１
０によって当該ノード１１０についての心拍は送信されず、ある時間の閾値の後、ロード
バランサ実装１１０内の他のノード１１０は、当該ノード１１０が不健康であるかまたは
故障中であると見なす。
少なくともいくつかの実施形態において、ロードバランサノード１１０は、自分自身の
内部状態の１以上の態様をチェックして、当該ノード１１０がなんらかの理由で不健康で
あることを検出した場合には、当該ノード１１０は、自分の健康をチェックする他のノー
ド１１０からの健康ｐｉｎｇに対する応答を停止する。したがって、当該不健康なノード
１１０をチェックしているノード１１０は、当該ノード１１０が不健康であると見なし、
当該ノード１１０の代理として心拍インクリメントを伝搬することはない。
＜ヘルスチェックプロトコルの詳細＞
少なくともいくつかの実施形態において、ヘルスチェックプロトコルは、心拍カウンタ
技法及び喧伝プロトコル技術を活用する。ヘルスチェックプロトコルは、２つの主要な部
分を有すると見なされる、すなわち、ヘルスチェック及び喧伝／障害検出である。
ヘルスチェック−ロードバランサ実装内のすべてのロードバランサノード１１０は、実
装中の１以上の他のノード１１０を定期的または不定期にヘルスチェックする。１以上の
他のノードが判定される方法については、後述する。ヘルスチェックの基本的な考え方は
、ノード１１０が他のノード１１０の健康をチェックして、当該他のノード１１０が健康
であると判定した場合には、当該チェックをしているノード１１０は、当該他のノード１
１０についての心拍カウンタをインクリメントし且つ伝搬することによって、当該他のノ
ード１１０が健康である旨を主張する。言い換えれば、ノード１１０は自分自身が健康で
あると他のノード１１０に対して主張しない代わりに、１以上の他のノード１１０はロー
ドバランサ実装内の各ノード１１０の健康をチェックして且つそれを主張する。
喧伝／障害検出−少なくともいくつかの実施形態において、ヘルスチェックプロトコル
は、喧伝プロトコルを活用して、ロードバランサ実装内のメンバーのロードバランサノー
ド１１０の中にロードバランサノード１１０の健康情報を伝搬する。喧伝プロトコルは、
迅速に収束して、分散型ロードバランシングシステムの目的のための十分な最終的な一貫
性の保証を提供する。少なくともいくつかの実施形態において、各ロードバランサノード
１１０は、喧伝プロトコルを使用することにより、ロードバランサ実装内の他のノード１
１０の各々についての心拍カウンタを、例えば、心拍リストの中で維持する。各ロードバ
ランサノード１１０は、上記したように、定期的または不定期に少なくとも１つの他のロ
ードバランサノード１１０のヘルスチェックを実行し、チェックされたノード１１０が健
康であることをヘルスチェックによって判定したときは、ノード１１０についての心拍カ
ウンタをインクリメントする。少なくともいくつかの実施形態において、各ロードバラン
サノード１１０は、定期的または不定期にランダムに、ロードバランサ実装内の少なくと
も１つの他のノード１１０を選択して、当該他のノード１１０に対して自分の現在の心拍
リストを送信する。ロードバランサノード１１０は、他のノード１１０から心拍リストを
受信すると、２つのリスト（受信されたリスト及び自分自身のリスト）内の各ノードにつ
いての最大心拍カウンタを判定することによって、且つ、判定された最大心拍カウンタを
自分自身の心拍リストにおいて使用することによって、受信されたリスト内の心拍情報と
自分自身の心拍リストとを統合する。そして今度は、この心拍リストがランダムに選択さ
れた他のノード１１０に送信され、これによって適宜、自分自身の心拍リストを更新し、
と同じように続く。この技法を使用すれば、健康なノード１１０の各々についての心拍情
報は、最終的に（例えば、数秒間に）ロードバランサ実装内のすべての他のロードバラン
サノード１１０に伝搬される。所定のロードバランサノード１１０についてその心拍カウ
ンタの増加が続く限り、当該所定のロードバランサノードは、他のノード１１０によって
健康であると見なされる。ロードバランサノード１１０の心拍カウンタが、ヘルスチェッ
ク及び喧伝処理方法によって、特定の期間にインクリメントされない場合には、他のロー
ドバランサノード１１０は、不健康であると見なされたロードバランサノード１１０に集
中する。
ロードバランサノードのヘルスチェック
少なくともいくつかの実施形態において、他のロードバランサノード１１０によって実
行されるロードバランサノード１１０に対するヘルスチェックの方法について、以下説明
する。図２３を参照すると、少なくともいくつかの実施形態において、或るロードバラン
サノード１１０は、以下の条件のうち１つ以上が当該ノード１１０について判定された場
合には、健康であると見なされる。
● ノード１１０のプロセッサスレッド（例えば、基本的なパケット処理コード１１０
８スレッド）が準備状態（内部）である。
● ノード１１０がエッジルータ１０４のＩＰアドレス及び／またはＭＡＣアドレス（
内部）を知っている。
● ノード１１０におけるすべてのスレッド及び／またはプロトコルハンドらがレディ
状態（内部）である。
● 北側（エッジルータ１０４／境界ネットワーク）からの着信リンク及び南側（サー
バ１３０／生産ネットワーク）からの出力リンクがアクティブ（外部）である。
● ノード１１０が、ロードバランサ実装内で使用されるネットワーク・インターフェ
イス制御部（ＮＩＣ）を介して、パケットを受信し且つ送信できる。例えば、図２３に示
されるように、例示的なロードバランサノード１１０の実施形態において、ノード１１０
は、北向きのＮＩＣ１１１４Ａ及び南向きのＮＩＣ１１１４Ｂを介して、連続的にパケッ
トを良好に受信し且つ送信する。
これらの健康条件の１つ以上が、所定のノード１１０において保持されない場合には、
当該ノード１１０は健康でないと見なされる。いくつかの実施形態においては、ノード１
１０が健康であると見なされるのは、上記条件のすべてが当該ノード１１０において保持
されている場合のみであることに留意されたい。
少なくともいくつかの実施形態において、上記健康条件に加えて、例えば、コントロー
ルプレーン通信のために使用される各ロードバランサノード１１０上のＮＩＣ１１１４Ｃ
として、図２３において示される第３のＮＩＣも、当該ＮＩＣに対してパケットを送信す
ること且つ当該ＮＩＣからパケットを受信することによりヘルスチェックをしているノー
ド１１０によってチェックされ、第３のＮＩＣのチェックが失敗した場合には、チェック
されているノード１１０は不健康と見なされる。
図１３は、少なくともいくつかの実施形態において、他のロードバランサノードからロ
ードバランサノードに対するヘルスチェックの例示的な方法を示す。この実施例において
、ロードバランサノード１１０Ａは、ロードバランサノード１１０Ｂに対してヘルスチェ
ックを行っている。ノード１１０Ａ及び１１０Ｂの各々は、北向きのＮＩＣ（図２３にお
けるＮＩＣ１１１４Ａ）及び南向きのＮＩＣ（図２３におけるＮＩＣ１１１４Ｂ）を有す
る。１で、ノード１１０Ａは、自分の北向きのＮＩＣからノード１１０Ｂの北向きのＮＩ
Ｃに対して、エッジルータ１０４を介してパケット（例えば、ｐｉｎｇパケット）を送信
する。ノード１１０Ｂは、リストにおいて与えられた上記条件が十分な場合には、自分の
北向きのＮＩＣ上でパケットを受信して、２で、自分の北向きのＮＩＣからファブリック
１２０を介して、ノード１１０Ａの北向きのＮＩＣに対して応答を送信する。ノード１１
０Ａは、応答を自分の北向きのＮＩＣ上で受信した後、３で、自分の南向きのＮＩＣから
ノード１１０Ｂの南向きのＮＩＣに対して、ファブリック１２０を介してパケット（例え
ば、ｐｉｎｇパケット）を送信する。ノード１１０Ｂは、リストにおいて与えられた上記
条件が十分な場合には、自分の南向きのＮＩＣにおいてパケットを受信して、４で、自分
の南向きのＮＩＣからノード１１０Ａの南向きのＮＩＣに対して、エッジルータ１０４を
介して応答を送信する。ノード１１０Ａは、自分の南向きのＮＩＣ上で応答を受信すると
、ノード１１０Ｂを健康であると見なし、ノード１１０Ｂのローカルな心拍カウンタをイ
ンクリメントし、これによって、上記した喧伝プロトコルに従って、他のノード１１０に
伝搬される。
いくつかの実施形態において、上記に代わる手段として、ロードバランサノード１１０
Ｂは、自分の北向きのＮＩＣで受信された第１のｐｉｎｇメッセージに対して、自分の南
向きのＮＩＣを介してノード１１０Ａの南向きのＮＩＣに応答し、自分の南向きのＮＩＣ
で受信された第２のｐｉｎｇメッセージに対して、自分の北向きのＮＩＣを介してノード
１１０Ａの北向きのＮＩＣに応答する。
さらに、いくつかの実施形態において、ノード１１０Ａもまた、自分自身の第３のＮＩ
Ｃからノード１１０Ｂの第３のＮＩＣをｐｉｎｇ処理することによって、且つ、ノード１
１０Ｂが健康である場合にノード１１０Ｂの第３のＮＩＣから自分の第３のＮＩＣ上のｐ
ｉｎｇメッセージに対する応答を受信することによって、コントロールプレーン通信（図
２３におけるＮＩＣ１１１４Ｃとして示される）のために使用されるノード１１０Ｂの第
３のＮＩＣに対してヘルスチェックを行う。ｐｉｎｇメッセージ及び応答は、１つ以上の
コントロールプレーン装置１７０、例えば、ネットワークスイッチを通過する。
上記説明したヘルスチェックメカニズムは、ノード１１０ＢのすべてのＮＩＣだけでな
く、（北、南、及びコントロールプレーンを通過する）すべての方向において、着信リン
ク、発信リンク、及びノード１１０Ｂのデータ経路のすべてを動かし、さらにｐｉｎｇパ
ケットが内部の待ち行列を渉るときのノード１１０Ｂの内部の健康、及び、クライアント
パケットとしての可能性があるときのノード１１０Ｂの送信を検証する。
＜ロードバランサノードに対するヘルスチェック責任の割り当て＞
少なくともいくつかの実施形態において、ロードバランサ実装内のすべてのロードバラ
ンサノード１１０は、例えば、構成機能によって及びまたは図１に示す構成サービス１２
２の構成要素によって、ロードバランサ実装内の他のすべてのロードバランサノード１１
０のリスト（例えば、ソートされたリスト）に対するアクセスを有する。少なくともいく
つかの実施形態において、各ロードバランサノード１１０は、リスト上の１以上の他のノ
ード１１０をランダムに選択して、ヘルスチェック間隔ごとにヘルスチェックを行い、健
康であると判定された場合にそれらの心拍カウンタをインクリメントする。リストは、ロ
ードバランサ実装内のすべてのロードバランサノード１１０が、ヘルスチェックメカニズ
ムを介して、現在、健康と見なされているかまたは不健康と見なされているかどうかとい
うことを含み、及び、健康なノード１１０だけでなく、現在、不健康なノード１１０がリ
ストからランダムに選択されて且つヘルスチェックされることに留意されたい。したがっ
て、現在、不健康なノード１１０は、当該ノード１１０に対してヘルスチェックする１以
上のノード１１０によって健康であることが判定され、それの心拍カウンタがインクリメ
ントされて、他のノード１１０に伝搬されると、当該不健康なノード１１０は健康な状態
に戻る。
あるいは、いくつかの実施形態においては、各ロードバランサノード１１０は、リスト
の中の１以上の他のノード１１０に対してヘルスチェックをすること、及び健康であると
判定された場合にはそれらの心拍カウンタをインクリメントすることに対する責任を負う
。例えば、いくつかの実施形態において、各ノード１１０は、２つの他のノード、例えば
、リストの中で、自分の「左」（または前）及び「右」（または、次）の最も近くの隣接
ノード１１０をヘルスチェックする責任を負う。リストは環状と見なされ、リストの「最
後」にあるノード１１０は、リストの「先頭」にあるノード１１０をヘルスチェックする
責任を負い、逆もまた然りであることに留意されたい。いくつかの実施形態においては、
２つの他のノード１１０は、他の方法で、例えば、リスト上の次の最も近くの２つの隣接
ノードとして選択される。いくつかの実施形態においては、各ノード１１０は、リスト上
で２より大きい他のノード１１０、例えば、３または４の他のノード１１０をヘルスチェ
ックする責任を負う。少なくともいくつかの実施形態において、或るノード１１０によっ
てチェックされている隣接ノード１１０が不健康であると判定された場合には、当該ノー
ド１１０は、当該不健康な隣接ノード１１０がチェックする責任を負っていたリスト上で
少なくとも１つのノードをヘルスチェックする責任を負う。少なくともいくつかの実施形
態において、自分の隣接ノード１１０（例えば、「左」及び「右」の隣接ノード）のヘル
スチェックに加えて、各ロードバランサノード１１０はまた、定期的または不定期的にラ
ンダムにリングの中のノード１１０を選択して、当該選択されたノード１１０のヘルスチ
ェックを実行し、それが健康である場合には、当該ランダムなノード１１０の心拍をイン
クリメントして伝搬する。少なくともいくつかの実施形態において、順序付きリスト中の
すべての他のノード１１０は、当該他のノード１１０が以前に健康または不健康と見なさ
れたかどうかにかかわらず、ランダムな選択及びヘルスチェックの対象と見なされる。
少なくともいくつかの実施形態において、各ノード１１０は、１以上のランダムに選択
されたノード１１０に対してヘルスチェックを実行するか、またはその代わりに自分の隣
接ノード１１０及びランダムに選択されたノードに対して、ヘルスチェック間隔と称され
る一定間隔でヘルスチェックを実行する。例えば、いくつかの実施形態において、心拍間
隔は１００ミリ秒であるが、さらに短いまたは長い間隔が使用される。さらに、少なくと
もいくつかの実施形態において、各ノード１１０は、自分の現在の心拍リストを少なくと
も１つの他のランダムに選択されたノード１１０に対して、喧伝間隔と称される一定間隔
で送信または「喧伝」する。いくつかの実施形態において、ヘルスチェック間隔と喧伝間
隔とは同じであるが、必ずしも同じでなくてもよい。
図１４は、少なくともいくつかの実施形態において、１以上のロードバランサノードに
対するロードバランサノードのヘルスチェックをグラフィカルに示す。この実施例におい
ては、ロードバランサ実装中に８つのロードバランサノード１１０Ａ〜１１０Ｈが存在す
る。点線の円は実装中のすべてのノード１１０の順序付きリストを表わす。いくつかの実
施形態において、各ノード１１０は、リスト上で１以上のノード１１０をランダムに選択
して、各々の間隔でヘルスチェックを行う。また、いくつかの実施形態において、各ロー
ドバランサノード１１０は、順序付きリスト上の１以上の特定のノード１１０に対してチ
ェックの責任を負い、例えば、ノード１１０Ａは、図１４に示される順序付きリストに従
って、自分に最も近い２つの隣接ノード１１０Ｂ及び１１０Ｈに対してヘルスチェックの
責任を果たす。さらに、ロードバランサノードはまた、順序付きリストからランダムに他
のノード１１０をヘルスチェック間隔毎に選択する。この実施例に示されるように、ノー
ド１１０Ａは、ランダムにノード１１０Ｆを選択してヘルスチェックをする。喧伝間隔で
は、ノード１１０Ａは、いくつかの他の健康なノード１１０、例えば、ノード１１０Ｄを
ランダムに選択して、その現在の心拍リストを選択された他のノード１１０に対して、例
えば、ＵＤＰメッセージの中で送信する。ノード１１０は、他のノード１１０から心拍リ
ストを受信すると、それに従って、自分自身の心拍リストを更新し、当該心拍リストを１
以上のランダムに選択されたノード１１０に対して、次の喧伝間隔で伝搬する。
サーバノードのヘルスチェック
上記したようなロードバランサノード１１０に対するヘルスチェックに加えて、ヘルス
チェックプロトコルの実施形態は、ロードバランサモジュール１３２を含んでいるサーバ
ノード１３０及びサーバノード１３０上のサーバ１３４に対するヘルスチェックを実行す
る。少なくともいくつかの実施形態において、サーバノード１３０は、以下に示す１つま
たは両方の条件が当該ノード１３０のために決定された場合には、健康であると見なされ
る。
● ロードバランサモジュール１３２が健康である。
● サーバノード１３０が健康ｐｉｎｇ（例えば、Ｌ７健康ｐｉｎｇ）に応答するのに
成功する。
図１５は、少なくともいくつかの実施形態において、サーバノードに対してヘルスチェ
ックをするロードバランサノードを示す。少なくともいくつかの実施形態において、ロー
ドバランサ実装中のすべてのロードバランサノード１１０は、ロードバランサ実装中のす
べてのサーバノード１３０のリストだけでなく、ロードバランサ実装中のすべての他のロ
ードバランサノード１１０のリストに対するアクセスを有する。リストは、例えば、構成
機能を介して及び／または図１に示される構成サービス１２２の構成要素を介して、取得
され且つ更新される。少なくともいくつかの実施形態において、サーバノード１３０は、
図１５に示されているように、健康なロードバランサノード１１０に対してコンシステン
トハッシュ化を行って、図１５に示されるようなコンシステントハッシュリングを形成す
る。少なくともいくつかの実施形態において、リング内の各サーバノード１３０は、リン
グ内の２つの健康なロードバランサノード１１０によってヘルスチェックされる。例えば
、図１５において、サーバノード１３０Ａは、ロードバランサノード１１０Ａ及び１１０
Ｃによってヘルスチェックされる。これら２つのノード１１０は、コンシステントハッシ
ュリングにおいて、サーバノード１３０に対する第１（ノード１１０Ａ）及び第２（ノー
ド１１０Ｂ）のヘルスチェックノード１１０と称される。所定の健康なロードバランサノ
ード１１０は、１より大きいサーバノード１３０をヘルスチェックすることに留意された
い。例えば、図１５において、ロードバランサノード１１０Ａはまた、サーバノード１３
０Ｂ及び１３０Ｃをヘルスチェックする。さらに、所定のロードバランサノード１１０は
、１以上のサーバノード１３０に対しては第１のヘルスチェックノード１１０であり、１
以上の他のサーバノード１３０に対しては第２のヘルスチェックノード１１０である。例
えば、図１５において、ロードバランサノード１１０Ａは、サーバノード１３０Ａ及び１
３０Ｂに対しては第１のヘルスチェックノードであり、サーバノード１３０Ｃ及び１３０
Ｄに対しては第２のヘルスチェックノードである。
少なくともいくつかの実施形態において、ロードバランサノード１１０に障害が発生し
た場合には、コンシステントハッシュリング上のメンバーシップが変わるが、依然として
健康な、したがって、依然としてコンシステントハッシュリング上にある１以上の他のロ
ードバランサノード１１０は、当該障害が発生したノード１１０によって以前にヘルスチ
ェックされたサーバノード１３０に対するヘルスチェックの責任を負う。
少なくともいくつかの実施形態において、健康なノード１１０の各々は、サーバチェッ
ク隔と称される一定間隔で、自分が割り当てられたサーバノード１３０に対するヘルスチ
ェックを実行する。少なくともいくつかの実施形態において、サーバチェック間隔は、上
記説明した喧伝間隔より大きいかまたは喧伝間隔と同じである。
少なくともいくつかの実施形態において、サーバノード１３０に対するヘルスチェック
を実行するために、健康なロードバランサノード１１０（例えば、図１５におけるノード
１１０Ａ）は、サーバノード１３０（例えば、図１５におけるサーバノード１３０Ａ）に
対して、健康ｐｉｎｇメッセージ（例えば、Ｌ７ ＨＴＴＰ健康ｐｉｎｇメッセージ）を
開始する。サーバノード１３０は、健康である場合には、ロードバランサノード１１０に
対してｐｉｎｇ応答を返送する。少なくともいくつかの実施形態において、ｐｉｎｇメッ
セージは、サーバノード１３０上のロードバランサモジュール１３２によって受信され且
つ処理されるので、ヘルスチェックｐｉｎｇは、成功すると、サーバノード１３０上のモ
ジュール１３２が健康であると確証する。ロードバランサノード１１０は、当該ｐｉｎｇ
に対する応答を受信すると、サーバノード１３０を健康であると見なして、サーバノード
１３０についての心拍カウンタをインクリメントする。
少なくともいくつかの実施形態において、所定の健康なロードバランサノード１１０に
よってヘルスチェックされたすべてのサーバノード１３０についての心拍カウンタは、他
のロードバランサノード１１０に伝搬されるが、それは、例えば、ロードバランサノード
１１０の心拍カウンタについて以前に説明した喧伝技法において、各ノード１１０が自分
の心拍リストを少なくとも１つの他のランダムに選択されたノード１１０に一定間隔（喧
伝間隔）で送信し、受信するノード１１０が自分自身の心拍リストを２つのリストにおけ
る最大値に基づいて更新するという技法に従ってなされる。
障害検出及び喧伝
少なくともいくつかの実施形態において、上記したロードバランサノード１１０のヘル
スチェック及びサーバノード１３０のヘルスチェックを介して得られた情報は、ロードバ
ランサ実装の中のすべてのノード１１０に伝搬されることを必要とするのは、すべてのロ
ードバランサノード１１０がロードバランサ実装の中の一貫した表示を維持できるからで
ある。上記したように、少なくともいくつかの実施形態において、ロードバランサノード
１１０は、喧伝プロトコルに従って互いに通信して、この健康情報を交換し且つ伝搬し、
ロードバランサノード１１０及びサーバノード１３０の障害を検出する。
少なくともいくつかの実施形態において、各ロードバランサノード１１０は、（喧伝間
隔と称される）一定間隔で、他のロードバランサノード１１０をランダムに選択し、ロー
ドバランサノード１１０及びサーバノード１３０についての心拍カウンタとともに、健康
なロードバランサノード１１０及びサーバノード１３０についての自分の表示を他のノー
ド１１０に送信する。ロードバランサノードまたはサーバノード１３０は健康である限り
、当該ノードは自分のヘルスチェックを合格にし、且つ自分の心拍カウンタは増加を続け
る。ノードについての心拍カウンタが、（障害時間間隔と称される）特定間隔において変
化しない場合には、当該ノードは、ロードバランサノード１１０によって障害が発生した
と疑われる。一旦ノードに障害が発生したと疑われると、ロードバランサノード１１０は
、当該ノードが不健康であることを判定する前に、（不健康時間間隔と称される）特定間
隔の間待つ。この不健康時間間隔は、すべてのロードバランサノード１１０が当該ノード
に障害が発生してしまったことを知るまで、ロードバランサノード１１０が待つことを許
可する。
図１６は、少なくともいくつかの実施形態において、ロードバランサノード１１０によ
って維持される（ロードバランサノード１１０またはサーバノード１３０のいずれかの）
他のノードの健康に関する状態、またはその表示をグラフィカルに表示する。３００に示
されるように、ロードバランサノード１１０が、この問題となるノードが健康であると表
示することからスタートすると仮定する。このことは、当該ノードについての心拍カウン
タが増加されてきたことを示す。しかしながら、３０２に示されるように、当該ノードの
心拍カウンタが特定間隔（障害時間間隔）において増加しない場合には、３０４に示され
るように、ロードバランサノード１１０は当該ノードに障害が発生してしまったのではな
いかと疑う。３０６に示されるように、当該ノードの心拍カウンタが、特定間隔（不健康
時間間隔）において増加しない場合には、３０８に示されるように、ロードバランサノー
ド１１０は当該ノードが不健康であると見なす。しかしながら、３１０に示されるように
、不健康時間間隔が無効になる前に、当該ノードについての心拍カウンタがインクリメン
トする場合には、ロードバランサノード１１０は、再び当該ノードが健康な３００である
と見なす。同様に、３１２に示されるように、不健康なノードに関して心拍のインクリメ
ントを受信した場合には、当該ノードは健康な３００として見なされることができる。
ノードが不健康であるということを判定することは、当該不健康なノードがロードバラ
ンサノード１１０であるかまたはサーバノード１３０であるかに依存して、さらにロード
バランサノード１１０と不健康なノードとの関係にも依存して、ロードバランサノード１
１０による異なる動作を含むが、これについては本明細書の他のところで説明する。
ロードバランサノードのデータ
少なくともいくつかの実施形態において、各ロードバランサノード１１０は、ロードバ
ランサ実装の状態に関するデータを維持する。少なくともいくつかの実施形態において、
このデータは、各ロードバランサノード１１０上で、健康なロードバランサノードのリス
ト、疑わしいロードバランサノードのリスト、及び心拍リストが含まれる１以上のデータ
構造において維持される。ただし、含まれるものはこれらに限定されない。図１７は、健
康なロードバランサノードのリスト３２０、疑わしいロードバランサノードのリスト３２
２、不健康なロードバランサノードのリスト３２４、及びロードバランサノードの心拍リ
スト３２６を維持する例示的なロードバランサノード１１０を示す。
少なくともいくつかの実施形態において、各ロードバランサノード１１０は、健康なロ
ードバランサノードのリスト３２０を維持するが、そのリストは、例えば、どのノード１
１０が健康であり、したがって喧伝プロトコルに参加しているかどうかを判定するために
使用される健康なロードバランサノード１１０のリストである。リスト３２０上のノード
１１０のみが、喧伝プロトコルを介してロードバランサ情報の伝搬に含まれ、リスト３２
０上のノード１１０のみが、コンシステントハッシュリング内に存在すると見なされ、及
びこのリスト上のノード１１０のみが、サーバノード１３０をヘルスチェックする。ノー
ド１１０は、このリスト３２０からランダムに他のノード１１０を選択して、当該選択さ
れたノードに対して自分の心拍情報が送信される。さらに、心拍カウンタは、現在、健康
なロードバランサノードのリスト３２０に存在するノード１１０に対してのみ交換される
。少なくともいくつかの実施形態において、ロードバランサノードＮは、ノードＮがロー
ドバランサノード１１０によるヘルスチェックに合格する場合、または、ロードバランサ
ノード１１０がノードＮに関する喧伝メッセージをリスト３２０上のいくつかの他のロー
ドバランサノード１１０から受信する場合には、他のロードバランサノード１１０の健康
なロードバランサノードリスト３２０に追加されることができる。
少なくともいくつかの実施形態において、各ロードバランサノード１１０は、疑わしい
ロードバランサノードのリスト３２２を維持するが、そのリストは、心拍カウンタ（心拍
リスト３２６参照）が（障害時間間隔と称される）特定間隔において増加されなかったロ
ードバランサノードのリストである。ロードバランサノードＥが、ロードバランサノード
１１０の疑わしいロードバランサノードのリスト３２２に存在する場合には、ロードバラ
ンサノード１１０はノードＥに関して喧伝しない。健康なリスト３２０上のいくつかの他
のロードバランサノード１１０が、ノード１１０の心拍リスト３２６内のノードＥにおけ
る心拍カウンタよりも高い心拍カウンタを有するノードＥに関してロードバランサノード
１１０に対して喧伝する場合には、ノードＥは疑わしいリスト３２２から健康なリスト３
２０に移動される。ノードＥが、（不健康時間間隔と称される）特定間隔において、ロー
ドバランサノード１１０の疑わしいリスト３２２上に留まる場合には、ノードＥはロード
バランサノード１１０によって不健康であると見なされ、不健康なノードのリスト３２４
に移動される。不健康なノードのリスト３２４上のノード１１０（この実施例では、ノー
ドＧ）は、ノードＧがノード１１０によるヘルスチェックに合格した場合、または、他の
ノード１１０からノードＧに関する更新された心拍カウンタを受信した場合には、ロード
バランサノード１１０の健康なノードのリスト３２０に移動される。
少なくともいくつかの実施形態において、各ロードバランサノード１１０は、すべての
知られているロードバランサノード１１０についての心拍リスト３２６を維持する。各ノ
ード１１０に関して、このリスト３２６は、心拍カウンタ及び当該心拍カウンタが最後に
変化した時を示すタイムスタンプを含む。
少なくともいくつかの実施形態において、各ロードバランサノード１１０は、図１７に
は示されていないが、すべての知られているサーバノードについての心拍リストも維持す
る。このリストは、ロードバランサノードの心拍リスト３２６に類似している。いくつか
の実施形態においては、２つのリストが組み合わされる。少なくともいくつかの実施形態
において、サーバノード１３０についての心拍情報は、例えば、喧伝プロトコルに従って
、ロードバランサノード１１０についての心拍情報とともに、またはこれに加えて、ロー
ドバランサノード１１０の中に伝搬される。
図１７は、４つの別々のリストを示すが、２以上のリストは単一のリストに組み合わさ
れることに留意されたい。例えば、いくつかの実施形態においては、すべてのノード１１
０の単一のリストが、各ロードバランサノード１１０上で維持され、ビットフラグまたは
他のデータ構造が、各ノードが現在、健康であるか、疑わしいか、または不健康かどうか
を示すために使用される。
＜サーバノードのデータ＞
少なくともいくつかの実施形態において、ノード１３０上のサーバノード１３０及びロ
ーカルロードバランサモジュール１３２は、ロードバランサノード１１０とともに喧伝プ
ロトコル内に参加することはない。ロードバランサノード１１０は、ロードバランサノー
ドのヘルスチェック方法によって得られた他のロードバランサノード１１０についての心
拍情報、及び、自分達自身の中のみのサーバノードヘルスチェック方法によって得られた
サーバノード１３０についての心拍情報を喧伝する（特に、各ロードバランサノード１１
０は、現在、自分の健康なロードバランサノードのリスト３２０上のノードのみに対して
喧伝する）。
しかしながら、各サーバノード１３０／ロードバランサモジュール１３２がロードバラ
ンサ実装における健康なロードバランサノード１１０に関する情報を必要とするのは、サ
ーバノード１３０が、発信クライアントトラフィクをサーバノード１３０が転送すること
ができるロードバランサノード１１０（特に、出口ノード）を決定することができ、且つ
、接続公開情報が送信されるロードバランサノードをどれにするかを決定することができ
るからである。少なくともいくつかの実施形態において、この情報をサーバノード１３０
に対して提供するために、ロードバランサノード１１０は、現在、健康なロードバランサ
ノード１１０を識別する情報（例えば、図１７における健康なロードバランサノードのリ
スト３２０）を有するサーバノード１３０を定期的または不定期に更新する。少なくとも
いくつかの実施形態において、所定のサーバノード１３０（図１５参照）をヘルスチェッ
クすることに対して責任を負うロードバランサノード１１０は、サーバノード１３０に対
して、現在、健康なロードバランサノードを識別する情報を提供する責任を負う。例えば
、図１５を参照すると、ロードバランサノード１１０Ａは、自分の健康なロードバランサ
ノードのリスト３２０をサーバノード１３０Ａ、１３０Ｂ、１３０Ｃ、及び１３０Ｄに対
して送信し、ロードバランサノード１１０Ｂは、自分の健康なロードバランサノードのリ
スト３２０をサーバノード１３０Ｃ、１３０Ｄ、及び１３０Ｅに対して送信する、と同じ
ように続く。
ロードバランサノードの障害の取り扱い
図１８Ａ及び１８Ｂは、少なくともいくつかの実施形態において、ロードバランサノー
ドの障害の取り扱い処理を示す。図１８Ａは、例示的なロードバランサ実装を示す。ロー
ドバランサ実装には、４つのロードバランサノード１１０Ａないし１１０Ｄが存在する。
エッジルータ１０４は、クライアント（図示せず）からの着信パケットをロードバランサ
ノード１１０にルーティングする。少なくともいくつかの実施形態において、エッジルー
タ１０４は、レイヤ４のフロー単位ハッシュ化マルチパス・ルーティング技法、例えば、
等価マルチパス（ＥＣＭＰ）ルーティング技法に従って、ルーティングを決定する。少な
くともいくつかの実施形態において、エッジルータ１０４は、ロードバランサ実装におい
て現在使用できるロードバランサノード１１０について学び、ロードバランサノード１１
０の広告、例えば、ロードバランサノード１１０によって開始された境界ゲートウェイ・
プロトコル（ＢＧＰ）技術セッションによる広告を介して、クライアントトラフィックを
受信する。しかしながら、少なくともいくつかの実施形態において、ロードバランサノー
ド１１０はＢＧＰセッションを介してエッジルータ１０４に対して自分自身を広告する代
わりに、ロードバランサ実装の中の少なくとも１つの他のノード１１０が、ＢＧＰを介し
てエッジルータ１０４に対してノード１１０を広告する責任を果たす。例えば、図１８Ａ
において示されるようないくつかの実施形態においては、所定のノード１１０の左及び右
の隣接ノード１１０が、当該所定のノード１１０をエッジルータ１０４に対して広告する
。例えば、ロードバランサノード１１０Ａはノード１１０Ｂ及び１１０Ｄを広告し、ロー
ドバランサノード１１０Ｂはノード１１０Ａ及び１１０Ｃを広告し、ロードバランサノー
ド１１０Ｃはノード１１０Ｂ及び１１０Ｄを広告する。
図１８Ａに示されるように、各ロードバランサノード１１０はまた、１以上の他のロー
ドバランサノード１１０、例えば、１以上のランダムに選択されたノード１１０、ロード
バランサノードの順序付きリストによって決定された１以上の隣接ノード１１０、または
１以上の隣接ノード及び１以上のランダムに選択されたノードを定期的にヘルスチェック
する。さらに、各ロードバランサノード１１０は、少なくとも１つのサーバノード１３０
を定期的にヘルスチェックし、健康なロードバランサノード１１０の自分のリストを、そ
れをヘルスチェックするサーバノードに対しても送信する。ロードバランサノード１１０
及びサーバノード１３０に関する健康情報は、例えば、喧伝プロトコルに従って、ノード
１１０の中に伝搬される。
図１８Ｂは、図１８Ａの例示的なロードバランサ実装において、単一のロードバランサ
ノード１１０における障害の取り扱いを示す。この実施例において、ロードバランサノー
ド１１０Ｂは何らかの理由で障害を発生している。例えば、ノード１１０Ａ及び１１０Ｃ
はノード１１０Ｂをヘルスチェックし、両方がそのヘルスチェックでノード１１０Ｂに障
害があることを検出する。したがって、ノード１１０Ａ及び１１０Ｃは、ノード１１０Ｂ
についての心拍カウンタをインクリメントしない。ノード１１０Ａ及び１１０Ｂの両方か
らの心拍情報は、喧伝プロトコルに従って、他の健康なロードバランサノード１１０（こ
の実施例においては、他のロードバランサノードはノード１１０Ｄのみである）に伝搬さ
れる。すべての健康なロードバランサノード１１０（この実施例においては、ノード１１
０Ａ、１１０Ｃ及び１１０Ｄ）は、ノード１１０Ｂの障害に集中するとすぐに、１以上の
以下に示すイベントが発生するが、これらに限定されない。これらのイベントは、必ずし
もこの順序では発生するものではないことに留意されたい。
● ノード１１０Ａ及び１１０Ｃは、エッジルータ１０４に対してしているノード１１
０Ｂの広告を停止する。少なくともいくつかの実施形態において、このことは、ノード１
１０Ｂを広告するために、ノード１１０がエッジルータ１０４と確立したＢＧＰセッショ
ンを終了することを含む。各ノード１１０は、各他のノード１１０を広告するために、エ
ッジルータ１０４と独立したＢＧＰセッションを確立するので、ノード１１０Ｂに関する
ＢＧＰセッションを終了することは、広告されている他のノード１１０には影響を及ぼさ
ないことに留意されたい。少なくともいくつかの実施形態において、ノード１１０は、Ｔ
ＣＰ ＣｌｏｓｅまたはＢＧＰセッションに関する同様のメッセージをエッジルータ１０
４に対して送信することによって、エッジルータ１０４とのＢＧＰセッションを終了する
。
● ノード１１０Ｂが、もはやどのノードによっても広告されていないことの検出に応
答して、エッジルータ１０４は、ノード１１０Ｂに対するクライアントデータパケットの
ルーティングを停止する。エッジルータ１０４はまた、マルチパス（例えば、ＥＣＭＰ）
ハッシングも調整して、クライアントからのパケットフローを残りの健康なロードバラン
サノード１１０に対して、特に、当該ノード１１０上の入口サーバ１１２に対して再分散
する。入口サーバ１１２に対してルーティングされていた任意のパケットフローに関して
、当該入口サーバ１１２はクライアントからサーバへの対応するマッピングを持っていな
いので、当該マッピングはクライアントからサーバへの接続に関係するフロー追跡部ノー
ドから得られるか、または、その代わりに、新たなクライアントからサーバへの接続が図
１０Ａないし１０Ｇに示された技法に従って確立される。
● ノード１１０Ａ及び１１０Ｃは、それぞれエッジルータ１０４に対してＢＧＰセッ
ションを開いてお互いを広告する。ノード１１０Ａ及び１１０Ｃの両方とも、ノード１１
０Ｂと同様に、ロードバランサノード１１０Ｄによってエッジルータ１０４に広告されて
いるので、ノード１１０Ｂに障害が発生した場合に、ノード１１０Ｂがエッジルータ１０
４に対するノード１１０Ａ及び１１０Ｂの広告を停止する事実は、エッジルータ１０４が
これら２つのノード１１０に対してパケットをルーティングすることを停止する原因には
ならないことに留意されたい。
● 少なくともいくつかの実施形態において、ノード１１０Ａ及び１１０Ｃは、互いに
ヘルスチェックに対する責任を果たすが、それらは今や隣接ノード１１０だからである。
ノード１１０Ｂは不健康であると見なされているにもかかわらず、今なお、１以上の他の
ノード１１０によってランダムにヘルスチェックがなされることに留意されたい。
● １以上の残りの健康なロードバランサノード１１０は、ノード１１０Ｂによって以
前にフロー追跡されていた接続をフロー追跡することに対して責任を負う。例えば、ノー
ド１１０Ｃ及び／またはノード１１０Ｄは、ノード１１０Ｂが一次または二次フロー追跡
部であった１以上の接続に対して、図１１Ｃ及び１１Ｄに示されているように、一次また
は二次フロー追跡部として引き継ぐ。
● １以上の残りの健康なロードバランサノード１１０は、ノード１１０Ｂによって以
前にヘルスチェックされていたサーバノード１３０をヘルスチェックする責任を負う。サ
ーバノード１３０は、残りのロードバランサノード１１０によって、（今やノード１１０
Ｂを含まない）健康なロードバランサノードのリストで更新される。例えば、図１８Ｂに
おいて、ロードバランサノード１１０Ａはサーバノード１３０Ｃのヘルスチェック及び更
新を開始し、ロードバランサノード１１０Ｃはサーバノード１３０Ｂのヘルスチェック及
び更新処理を開始する。
● エッジルータ１０４上において、障害のあるノード１１０ＢからのＢＧＰセッショ
ンは、最終的にはタイムアウトになる。また、エッジルータ１０４は、ノード１１０Ｂに
障害が発生したことを認識すると、ＢＧＰセッションを終了する。
２つのロードバランサノード１１０が同時にまたはほぼ同時に障害になり得る可能性が
ある。２つのロードバランサノードが互いに隣接していない場合には、その障害は独立し
ており、図１８Ｂにおいて示された方法に従って、独立した単一のノード１１０の障害と
して取り扱う。しかしながら、障害になった２つのノードが互いに隣接している場合（例
えば、図１８Ａにおけるノード１１０Ｂ及び１１０Ｃ）には、すべての健康なロードバラ
ンサノード１１０（この実施例においては、ノード１１０Ａ及び１１０Ｄ）は障害を検出
し且つ障害に集中するとすぐに、以下に示す１つ以上のイベントが発生するが、これらに
は限定されない。これらのイベントは、必ずしもこの順序で発生するものではないことに
留意されたい。
● ノード１１０Ａは、エッジルータ１０４に対してノード１１０Ｂに関するＢＧＰセ
ッションを終了する。
● ノード１１０Ｄは、エッジルータ１０４に対してノード１１０Ｃに関するＢＧＰセ
ッションを終了する。
● ノード１１０Ａ及び１１０Ｄは、エッジルータ１０４とのＢＧＰセッションを開始
してお互いを広告する。
● ノード１１０Ａ及び１１０Ｄは、お互いのヘルスチェックを開始する。ノード１１
０Ａ及び１１０Ｄはまた、障害のあるノード１１０のヘルスチェックを継続することに留
意されたい。
● 残りの健康なノード１１０は、健康なロードバランサノードのリストでサーバノー
ド１３０を更新する。
● エッジルータ１０４からノード１１０Ｂ及び／またはノード１１０Ｃへのトラフィ
ックは流れを継続する。何故なら、これら２つのノード１１０は、エッジルータ１０４に
対してお互いに広告を継続しているからである。しかしながら、これらのＢＧＰセッショ
ンは最終的にはタイムアウトになり、エッジルータ１０４は、適宜残りの広告されている
ノード１１０に対してフローを再分散することになる。
● ノード１１０Ｂ及び１１０Ｃは、今なおノード１１０Ｂ及び１１０Ｃが健康である
と考えている場合には、エッジルータ１０４との間でノード１１０Ａ及び１１０Ｄを広告
する自分たちのＢＧＰセッションをていねいに閉じる。
接続公開
再び図１を参照すると、少なくともいくつかの実施形態において、ロードバランサ実装
におけるロードバランサノード１１０は、サーバ１３０に対するクライアントＴＣＰ接続
に関する状態情報を維持する。この状態情報は、ロードバランサノード１１０が、エッジ
ルータ１０４からの着信クライアントパケットをＴＣＰ接続に対して責任のあるサーバノ
ード１３０に対してルーティングできるようにする。サーバノード１３０上のロードバラ
ンサモジュール１３２は、自分たちのそれぞれのサーバ１３４に対するアクティブなＴＣ
Ｐ接続のリストを維持する。接続公開は、メカニズムであり、それを介して、サーバノー
ド１３０上のロードバランサモジュール１３２がアクティブなＴＣＰ接続についての自分
たちのリストをロードバランサノード１１０に対して公開する。少なくともいくつかの実
施形態において、接続公開のパケットは、接続公開間隔と称される一定間隔で、ロードバ
ランサモジュール１３２によって形成され、ロードバランサノード１１０に対して公開さ
れる。
少なくともいくつかの実施形態において、ロードバランサノード１１０によって維持さ
れる接続状態情報は、キャッシュの形態とし見なされ、特定の接続についての状態情報を
維持することは、当該接続に対するロードバランサノード１１０上のリースを維持するこ
とと見なされる。キャッシュエントリが一新されない限り、ロードバランサノード１１０
は、データフローを取り扱うサーバノード１３０に対するクライアントデータフローのル
ーティングができない。接続公開のメカニズムは、ロードバランサノード１１０上のキャ
ッシュ及び、それゆえリースをサーバノード１３０からの現在の接続状態情報で定期的に
一新するので、クライアント１６０から適切なサーバノード１３０に対するＴＣＰパケッ
トのフロー処理を維持する。クライアント１６０がサーバ１３４に対するＴＣＰ接続を終
了したときは、サーバノード１３０上で当該接続に関連しているロードバランサモジュー
ル１３２は、アクティブな接続についての自分のリストから当該接続を中断し、したがっ
て、接続公開のメカニズムを通じたＴＣＰ接続はもはや公開しない。したがって、接続（
特に、接続に対する入口サーバ１１２並びに一次及び二次フロー追跡部１１６）に関連し
ているロードバランサノード１１０上で接続（１つまたは複数のキャッシュエントリ）に
対応する接続状態情報は、もはや一新されず、接続はロードバランサノード１１０によっ
て中断される。少なくともいくつかの実施形態において、接続に対応する１つまたは複数
のキャッシュエントリは、メモリがいくつかの他のアクティブな接続を要求するまでは、
ロードバランサノード１１０上のキャッシュの中に残る。
このように、接続公開のメカニズムは、定期的または不定期に、入口サーバ１１２並び
に一次及び二次フロー追跡部１１６上の接続リースを延長して、クライアントトラフィッ
クの流れを継続する。さらに、接続公開のメカニズムは、少なくともいくつかのロードバ
ランサノード１１０の障害から回復するのに役立つ。クライアント接続の状態情報を保持
している１以上のロードバランサノード１１０が失敗した場合には、接続公開によって残
りのロードバランサノード１１０に供給されているアクティブな接続情報は、あるいくつ
かの場合には、接続を回復するために使用される。
接続公開のメカニズムを使用すれば、サーバノード１３０は、サーバ１３４とクライア
ント１６０との間の接続の状態に関する信頼できる送信元になる。さらに、サーバ１３４
に対する接続を閉じることは、サーバノード１３０上のロードバランサモジュール１３２
及びロードバランサノード１１０によって受動的に取り扱われる。サーバノード１３０と
ロードバランサノード１１０との間では、ハンドシェイクは必要でない。言い換えれば、
ロードバランサモジュール１３２は、特定の接続が閉じられているノードを積極的に通知
するために、ロードバランサノード１１０に対してメッセージを送信する必要はない。サ
ーバ１３４が接続を閉じた場合には、サーバ１３４は当該接続に関する自分の内部状態を
消去する。ロードバランサモジュール１３２は、サーバ１３４の内部状態を用いて、接続
公開パケットを追加する。サーバ１３４の内部状態の中には当該接続はもはや存在しない
ので、当該接続は、ロードバランサノード１１０に対して公開されることはない。このた
め、ロードバランサノード１１０上の当該接続に関するリースは失効し、ロードバランサ
ノード１１０は、当該接続について受動的に忘れる。したがって、ロードバランサノード
１１０のキャッシュにおいて当該接続のために使用されていたメモリは、必要に応じて、
他の接続のために使用されることが可能になる。
いくつかの実施形態において、ロードバランサノード１１０によって維持されている接
続についてのリースは、キャッシュ内で接続についてのタイムスタンプ用のエントリを含
む。接続のリースは接続公開処理パケットによって一新されるとき、タイムスタンプは更
新される。サーバノード１３０上のロードバランサモジュール１３２によって公開されて
いた接続がもはや存在しないことから、接続のリースが一新されない場合には、タイムス
タンプはもはや更新されない。少なくともいくつかの実施形態において、メモリが必要に
なるまで、接続についてのエントリがキャッシュ内に残っているところでは、レイジー・
ガベージコレクション方法が使用される。例えば、少なくともいくつかの実施形態におい
て、キャッシュエントリ上のタイムスタンプは、リースの一新時間の閾値と比較され、キ
ャッシュエントリについてのタイムスタンプが閾値よりも古い場合には、当該エントリは
古いので再利用される。しかしながら、いくつかの実施形態では、古いエントリは、積極
的にガベージ収集される。
接続公開の配信先
少なくともいくつかの実施形態において、各クライアントＴＣＰ接続について、接続状
態を維持する３つのロードバランサノード１１０、すなわち、入口サーバ１１２としての
機能を果たしているノード１１０、一次フロー追跡部１１６としての機能を果たしている
ノード１１０、及び二次フロー追跡部ノード１１６としての機能を果たしているノードが
存在する。所定のＴＣＰフローについて、例えば、ロードバランサノード１１０によって
、コンシステントハッシュリングの中で一次フロー追跡部１１６及びそれに続くノードを
見つけるために、ＴＣＰフローに対してコンシステントハッシュ機能を適用して、一次及
び二次フロー追跡部１１６が判定される。ＴＣＰフローに対して入口サーバ１１２として
の機能を果たしているロードバランサノード１１０は、エッジルータ１０４の内部マルチ
パス（例えば、ＥＣＭＰ）ハッシュ機能に基づくエッジルータ１０４からの当該フローに
関するトラフィックを受信するノード１１０である。ノード１１０の障害または追加があ
る場合には、入口サーバ１１２としての機能を果たしているロードバランサノード１１０
は、多くのアクティブなＴＣＰフローに対して変化し、さらに少なくともいくつかのアク
ティブなＴＣＰフローに対してフロー追跡部として機能しているロードバランサノード１
１０は変化する（例えば、図１１Ａないし１１Ｄ参照）。サーバノード１３０上のサーバ
１３２に対するすべてのＴＣＰフローについて、サーバノード１３０上のロードバランサ
モジュール１３２が、いずれのロードバランサノード１１０が当該ＴＣＰフローに対する
入口サーバ１１２であるかを示している状態情報を維持するのは、それが当該ロードバラ
ンサノード１１０からのトラフィックを受信するからである。しかしながら、少なくとも
いくつかの実施形態において、ロードバランサモジュール１３２が、どのロードバランサ
ノード１１０がＴＣＰフローに対して一次及び二次フロー追跡部としての機能を果たして
いるか分からず、且つ、決定することができないのは、ロードバランサモジュール１３２
は、使用されるコンシステントハッシュ機能が分からないからである。言い換えれば、少
なくともいくつかの実施形態において、ロードバランサモジュール１３２は、コンシステ
ントハッシュ法を行わない。
アクティブな接続情報の公開
図１９Ａ及び１９Ｂは、少なくともいくつかの実施形態において、接続公開の技法をグ
ラフィカルに示す。図１９Ａは、ロードバランサノードに対して、アクティブな接続情報
を公開しているロードバランサ（ＬＢ）モジュールを示す。少なくともいくつかの実施形
態において、各ロードバランサモジュール１３２は、サーバノード１３０上でアクティブ
なＴＣＰフローの各々に対する情報を収集して、接続公開パケットを形成する。所定のＴ
ＣＰフローに対する情報は、当該フローに対して入口サーバ１１２としての機能を果たし
ているロードバランサノード１１０を識別する情報を含む。接続公開の準備ができた場合
（例えば、接続公開間隔に到達した時）には、上記したように、ロードバランサモジュー
ル１３２は、例えば、サーバノード１３０をヘルスチェックするロードバランサノード１
１０からサーバノード１３０に対して定期的に送信される健康なロードバランサノード１
１０のリストから、ランダムにロードバランサノード１１０を選択する。ロードバランサ
モジュール１３２は、次に、選択されたノード１１０に対して、接続公開パケットを送信
する。例えば、図１９Ａにおいて、ロードバランサモジュール１３２Ａは、ロードバラン
サノード１１０Ａに対して１つの接続公開パケットを送信し、後でロードバランサノード
１１０Ｂに対してもう１つの接続公開パケットを送信する。
図２０は、少なくともいくつかの実施形態において、各ロードバランサモジュール１３
２によって実行される接続公開方法の上位のフローチャートである。５００に示されるよ
うに、ロードバランサ（ＬＢ）モジュール１３２は、それぞれのサーバノード１３０上の
すべてのアクティブなＴＣＰフローに対する接続公開エントリを生成する。少なくともい
くつかの実施形態において、ロードバランサモジュール１３２は、例えば、サーバノード
１３０上の/ｐｒｏｃ/ｎｅｔ/ｔｃｐから、サーバノード１３０上のサーバ１３４が取り
扱うアクティブなＴＣＰ接続の組み合わせを検索する。すべてのアクティブなＴＣＰ接続
について、ロードバランサモジュール１３２は、（例えば、ローカルに維持されているア
クティブな接続のテーブルの中で）ＴＣＰフローに対して入口サーバ１１２として機能し
ているロードバランサノード１１０を探索して、接続に対するＴＣＰタプル（例えば、ク
ライアントＩＰアドレス、クライアントポート、サーバ（パブリック）ＩＰアドレス、及
びサーバポートから構成される４タプル）及び接続に対応する入口サーバ１１２を示す接
続公開エントリを生成する。各ロードバランサモジュール１３２は、接続に対してパケッ
トが受信された最後のロードバランサノード１１０を示している各アクティブなＴＣＰ接
続に関する情報を維持し、この情報はロードバランサモジュール１３２によって使用され
て、各アクティブな接続に対する入口ノード１１０を識別することに留意されたい。
５０２に示されるように、ロードバランサモジュール１３２は、（１以上の接続公開エ
ントリで、１つのエントリが各アクティブなＴＣＰ接続に対応する）接続公開パケットを
送信すべきロードバランサノード１１０をランダムに選択する。少なくともいくつかの実
施形態において、ロードバランサモジュール１１０は、ロードバランサモジュール１３２
が送信準備のできた接続公開パケットを決定したときに、ランダムに選択される。少なく
ともいくつかの実施形態において、この決定は、接続公開間隔に従って行われる。限定さ
れない実施例として、接続公開間隔は、１００ミリ秒（ｍｓ）、または１秒である。少な
くともいくつかの実施形態において、ロードバランサモジュール１１０は、ロードバラン
サノード１１０の１つから以前に受信された健康なロードバランサノード１１０のリスト
から選択される。５０４に示されるように、ロードバランサモジュールは次に、選択され
たロードバランサノード１１０に対して、接続公開パケットを公開する。少なくともいく
つかの実施形態において、接続公開パケットは、ステートレスパケット、例えば、ＵＤＰ
パケットである。いくつかの実施形態では、接続公開パケットは、目標のロードバランサ
ノード１１０に対して当該パケットを送信する前に圧縮される。少なくともいくつかの実
施形態において、接続公開情報は、目標のロードバランサノード１１０に対して、２以上
のパケットの中で送信される。
要素５０４から要素５００に戻る矢印に示されるように、ロードバランサモジュール１
３２は、連続的に接続公開パケットを構築し、ランダムにノード１１０を選択し、当該パ
ケットを当該選択されたノードに送信する。上記したように、このことは、ロードバラン
サノード１１０が現在のアクティブな接続情報により相対的且つ規則的に更新されて、ロ
ードバランサノード１１０上の接続リースを維持するように、接続公開間隔に従って実行
される。
少なくともいくつかの実施形態において、接続公開パケットは、ロードバランサモジュ
ールによってロードバランサノード１１０に対してランダムに分散されるので、当該接続
公開パケットを受信するロードバランサノード１１０は、当該接続公開パケット内のアク
ティブな接続情報を当該接続のための適切な入口／一次／二次ノード１１０に対して分散
することに責任がある。図１９Ｂ及び、図２１及び２２は、少なくともいくつかの実施形
態において使用されるアクティブな接続情報の分散方法を示す。
図１９Ｂは、少なくともいくつかの実施形態において、アクティブな接続情報をロード
バランサノード１１０の中に分散することを示す。ロードバランサノード１１０がロード
バランサモジュール１３２から接続公開パケットを受信した場合には、ロードバランサノ
ード１１０は、当該フローに対応する入口ノード及び一次及び二次フロー追跡部ノードを
決定するために、そこに示された各ＴＣＰフローに関する情報を分析する。ロードバラン
サノード１１０がフローに関するそれらの役割の１つを果たしている場合には、ロードバ
ランサノード１１０は、当該フローに関する情報を消費する（例えば、状態情報に関する
自分のキャッシュを更新することによって）。少なくともいくつかの実施形態において、
ロードバランサノード１１０はまた、当該フローに関する他の役割を果たしている１以上
の他のノード１１０に対して送信されるパケットの中に、当該フローに関する情報を配置
する。接続公開パケットによって示されている残りのフローについて、ロードバランサノ
ード１１０は、アクティブな接続情報を２以上のもっと小さなパケットに分割して、１以
上の他のロードバランサノード１１０に送信する。例えば、少なくともいくつかの実施形
態において、１以上のフローに関するアクティブな接続情報を有するパケットは、当該フ
ローに対して入口サーバ１１２、一次フロー追跡部１１６Ａ、及び二次フロー追跡部１１
６Ｂとしての機能を果たしているロードバランサノード１１０に送信される。
図２１は、少なくともいくつかの実施形態において、目標のロードバランサノード１１
０に対する接続公開パケット内で受信されるアクティブな接続情報の配信方法のフローチ
ャートである。５２０に示されているように、ロードバランサノード１１０は、ロードバ
ランサモジュール１３２から接続公開パケットを受信する。ロードバランサモジュール１
３２は、例えば、図１９Ａ及び２０を参照して上記説明したように、パケットを受信する
ため、パケットを生成して、ロードバランサノード１１０を選択した。接続公開パケット
は、そこからのパケットが受信されたサーバノード１３０を識別している情報（例えば、
サーバノード１３０上のロードバランサモジュール１３２のＩＰアドレス）、及び、アク
ティブなＴＣＰ接続（例えば、クライアントＩＰアドレス、クライアントポート、サーバ
（公開）ＩＰアドレス、及び各接続に対応するサーバポートから構成される４タプル）を
識別しているエントリのリストを含む。
図２１の要素５２２ないし５３０において、ロードバランサモジュール１１０は、受信
された接続公開パケットにおいて示されているアクティブなＴＣＰ接続情報を繰り返し処
理する。５２２に示されているように、ロードバランサノード１１０は、パケットの中の
次のＴＣＰフローにおけるエントリを分析して、それぞれのＴＣＰフローに対応する入口
ノード１１０及び一次及び二次フロー追跡部ノード１１０を決定する。少なくともいくつ
かの実施形態において、ロードバランサノード１１０は、接続公開エントリから入口ノー
ド１１０のアイデンティティを取得する。少なくともいくつかの実施形態において、ＴＣ
Ｐフローに対応する一次及び二次フロー追跡部ノード１１０は、コンシステントハッシュ
機能に従って決定される。５２４において、ロードバランサノード１１０が検査されてい
るＴＣＰフローに対する役割の１つで機能を果たしている場合には、５２６において、ロ
ードバランサノード１１０は、例えば、状態情報に関する自分のキャッシュを更新するこ
とによって、フローに関する情報を消費する。５２８に示されているように、ロードバラ
ンサノード１１０は、他のロードバランサノード１１０に対して送信されるべく組み立て
られているパケットに、ＴＣＰフローに対する接続公開エントリを追加する。５３０にお
いて、接続公開パケットの中にさらなる接続公開エントリが存在する場合には、方法は５
２２に戻って、次のエントリを処理する。そうでない場合には、ロードバランサノードは
、５３２に示されているように、最初の接続公開パケットからの接続公開エントリのサブ
セットを各々が含む新たに組み立てられたパケットを、当該パケットに対応する目標のロ
ードバランサノード１１０に送信する。少なくともいくつかの実施形態において、目標の
ロードバランサノード１１０に送信されたパケットは、ステートレスパケット、例えば、
ＵＤＰパケットである。いくつかの実施形態において、パケットは、目標のロードバラン
サノード１１０に当該パケットが送信される前に圧縮される。
したがって、少なくともいくつかの実施形態では、図２１の要素５２２ないし５２８に
おいて、フロー追跡部ノード１１０は、受信された接続公開パケットにおける接続公開エ
ントリから５２２で決定される情報に従って、他のノード１１０の特定の１つに各々が送
信される１以上のパケット（例えば、ＵＤＰパケット）を組み立てる。少なくともいくつ
かの実施形態において、他のノード１１０に送信されるパケットは、目標のノード１１０
が入口ノード１１０、一次フロー追跡部ノード１１０、または二次フロー追跡部ノード１
１０としての機能を果たしているＴＣＰフローについてのエントリを含む。いくつかの実
施形態において、所定のロードバランサノード１１０は、ＴＣＰフローに対して入口ノー
ド及び一次フロー追跡部ノードの両方としの機能を果たし、またはＴＣＰフローに対して
入口ノード及び二次フロー追跡部ノードの両方としての機能を果たすことに留意されたい
。
図２２は、少なくともいくつかの実施形態において、接続公開パケットの中で受信され
たアクティブな接続情報を目標のロードバランサノード１１０に対して分散する他の方法
を示す。５５０に示されているように、ロードバランサノード１１０は、ロードバランサ
モジュール１３２から接続公開パケットを受信する。この方法においては、５５２に示さ
れているように、ロードバランサノード１１０上のプロセスは、パケット内の接続公開エ
ントリを分析し、それに応じて、受信されたパケットを１以上のより小さなパケットに分
割する。ロードバランサノード１１０は、この処理中においてフロー情報をローカルに消
費することはない。一旦接続公開パケットが１以上のパケットに分割されると、当該パケ
ットは、５５４ないし５６０に示されているように処理される。５５４において、パケッ
トに対応する目標のノード１１０がこのロードバランサノード１１０である場合には、当
該ロードバランサノード１１０は、５５６に示されているように、ローカルにパケットを
消費する。そうでない場合には、パケットは目標のロードバランサノード１１０に送信さ
れる。５６０において、さらに処理されるべきパケットが存在する場合には、方法は５５
４に戻る。そうでない場合には、方法は終了する。
したがって、ロードバランサモジュール１３２から接続公開パケットを受信するロード
バランサノード１１０は、当該接続公開パケットを、他のロードバランサノード１１０の
うち特定のものに固有の２以上のより小さなパケットに分割し、それに応じて、当該パケ
ットを分散するが、一方、現在、当該ロードバランサノード１１０によって取り扱われて
いる任意のＴＣＰフローに関するフロー情報を内部で消費する。その間に、他のロードバ
ランサノード１１０もまた、ロードバランサモジュール１３２から接続公開パケットを受
信しており、接続公開エントリを多数のより小さいパケットに分割し、当該より小さいパ
ケットを目標のノード１１０に分散して、これによりアクティブな接続情報をノード１１
０の中に分散する。
接続公開のトリガ
少なくともいくつかの実施形態において、接続公開は、１以上の異なるイベントによっ
てロードバランサモジュール１３２上でトリガされる。前述のように、いくつかの実施形
態において、接続公開パケットは生成されて、接続公開間隔、例えば、１００ミリ秒また
は１秒の間隔に従って、ランダムに選択されたロードバランサノード１１０に対して送信
されて、ロードバランサノード１１０上のＴＣＰ接続に対するリースを一新する。いくつ
かの実施形態において、ロードバランサノード１１０のメンバーシップの変化は、即時の
接続公開イベントをトリガする。少なくともいくつかの実施形態において、ロードバラン
サモジュール１３２は、それぞれのサーバノード１３０をヘルスチェックするロードバラ
ンサノード１１０の１つから送信された健康なロードバランサノード１１０のリストから
当該変化について学ぶ。リストによって変化（削除または追加のいずれか）を検出したと
きには、当該変化によって影響を受けるＴＣＰ接続は、当該ロードバランサノード１１０
によってさらに迅速に回復されるように、ロードバランサモジュール１３２が接続公開パ
ケットを生成して、ロードバランサノード１１０に送信する。
パケットループの防止
接続公開パケットの処理中にロードバランサレイヤのメンバーシップが変化したときは
、接続公開パケットのループが発生する。第１のノード１１０がロードバランサモジュー
ル１３２から接続公開パケットを受信し、より小さなパケットを第２のノード１１０に送
信する。しかしながら、メンバーシップが変化していた場合には、当該第２のノード１１
０は、当該パケットは第１のノード１１０に行くべきだと判定し、このため当該パケット
を第１のノード１１０に転送する。少なくともいくつかの実施形態において、このループ
が発生するのを防ぐために、ロードバランサモジュール１３２から受信される接続公開パ
ケット及びロードバランサノード１１０から受信される接続公開パケットのために異なる
ポート番号が使用され、ロードバランサノード１１０は、他のロードバランサノード１１
０から受信される接続公開パケットを再分配しない。
接続公開パケットの分散の代替
上記された接続公開方法において、ロードバランサモジュール１３２は、接続公開パケ
ットが送信されるロードバランサノード１１０をランダムに選択する。しかしながら、い
くつかの実施形態において、ロードバランサノード１１０を選択するために他の方法が使
用される。例えば、いくつかの実施形態において、ロードバランサノード１３２は、１以
上のアクティブなＴＣＰフローを取り扱う特定の入口ノード１１０を各々が目標にする１
以上の接続公開パケットを組み立てて、目標の入口ノード１１０に対してパケットを送信
した。入口ノード１１０は、アクティブな接続情報を接続に対応する一次及び二次フロー
追跡部に再分配するであろう。他の実施例として、いくつかの実施形態において、単一の
ランダムに選択されたノード１１０に対して接続公開パケットを送信する代わりに、各接
続公開パケットは、ロードバランサモジュール１３２によって２以上の健康なノード１１
０またはすべての健康なノード１１０に送信される。
ロードバランサノードのアーキテクチャ
図２３は、少なくともいくつかの実施形態におけるロードバランサノード１１０につい
ての例示的なソフトウェアスタックのアーキテクチャを示すが、この図に限定する意図で
はない。この例示的なソフトウェアスタックのアーキテクチャにおいて、ロードバランサ
サーバのネイティブコード１１０６及びコアパケットのプロセスコード１１０８、例えば
、インテル（登録商標）のデータプレーン開発キット（ＤＰＤＫ）技術コードを含むネイ
ティブコードのレイヤを管理するためのＪａｖａネイティブ・インターフェイス（ＪＮＩ
：登録商標）１１０４技術を使用する単一のＪａｖａ（登録商標）技術プロセス１１０２
の範囲内で、ロードバランサノード１１０は動作する。ネイティブコードは、２つのネッ
トワーク・インターフェイス・コントローラ（ＮＩＣ１１１４Ａ及び１１１４Ｂ）にイン
ターフェイスする。第１のＮＩＣ（ＮＩＣ１１１４Ａ）は、「北」に面していて、すなわ
ち、エッジルータ１０４に向いている。第２のＮＩＣ（ＮＩＣ１１１４Ｂ）は、「南」に
面していて、すなわち、サーバノード１３０に向いている。少なくともいくつかの実施形
態において、ＮＩＣ１１１４Ａ及び１１１４Ｂは、ＴＣＰスタックを維持しない。したが
って、少なくともいくつかの実施形態は、ロードバランサノード１１０がコントロールプ
レーンを介して、プロセスと通信できるように、また、逆方向も同様にできるように、Ｔ
ＣＰ接続をサポートする第３のＮＩＣ１１１４Ｃを備える。また、いくつかの実施形態に
おいて、第１の北向きのＮＩＣ１１１４Ａ及び第２の南向きのＮＩＣ１１１Ｂだけは、ロ
ードバランサノード１１０の中に実装され、且つ、第２の南向きのＮＩＣ１１１４ＢはＴ
ＣＰスタックを実装し、それを介したロードバランサノード１１０がコントロールプレー
ンを介したプロセスと通信する。ロードバランサノード１１０はまた、オペレーティング
システム（ＯＳ）技術ソフトウェア１１１２、例えば、Ｌｉｎｕｘ（登録商標）カーネル
、及び、ＯＳ技術ソフトウェア１１１２及びＪＮＩ１１０４技術に加えてＪａｖａ仮想マ
シン（ＪＶＭ：登録商標）技術ソフトウェア１１１０のレイヤを有する。
少なくともいくつかの実施形態において、分散型ロードバランシングシステムのロード
バランサノード１１０の各々は、多くのデータフローを高いパケット速度で同時に処理す
る必要がある。少なくともいくつかの実施形態において、スループットの必要なレベルを
達成するためには、ロードバランサノード１１０は、高性能のパケット処理のために、イ
ンテル（登録商標）・データプレーン開発キット（ＤＰＤＫ）技術を活用する。ＤＰＤＫ
技術は、ユーザ空間のプログラムが、ネットワーク・インターフェイス・コントローラ（
ＮＩＣ）から及びネットワーク・インターフェイス・コントローラ（ＮＩＣ）へ直接パケ
ットの読み込み／書き込みすることを可能にし、Ｌｉｎｕｘカーネルの
ネットワーキングスタック（Ｌｉｎｕｓ ｉｘｇｂｅベースのＮＩＣドライバを除く）の
多くのレイヤをバイパスする。パケット処理に取り組むＤＰＤＫは、ビジーループの中で
直接的にＮＩＣハードウェアをポーリングする専用のＣＰＵコアを優先して、割り込みハ
ンドラベースの入力を拒絶する。この取り組みは、ビジーループの中で専用のＣＰＵコア
を連続的に動かすことによる熱出力の増加を犠牲にして、さらに高いパケット速度を実現
する。ＤＰＤＫ技術はまた、ＣＰＵコア管理、ロックフリーの待ち行列、メモリプール、
及び同期プリミティブを含むパケット処理のためのツールを提供する。図２４に示されて
いるように、ＤＰＤＫ技術では、専用のＣＰＵコア６００が各特定のタスクのために使用
され、作業は、無閉鎖の待ち行列６０２を用いて１つのＣＰＵコア６００Ａから他のＣＰ
Ｕコア６００Ｂに渡される。
ＤＰＤＫ待ち行列６０２は、２つのリングバッファの高速パワーを使用して実装され、
単一及び多数の生産者／消費者の変数の型をサポートする。多数の生産者／消費者の変数
の型は、すべてがロックフリーではないのは、それらがアクセスを同期するためにコンペ
ア・アンド・スワップ（ＣＡＳ）のループを有するからである。すべてのパケット・バッ
ファメモリは前もってメモリプールに割り当てられているので、バッファに対するポイン
タのみが、待ち行列６０２について読みだされ且つ書き込まれる。メモリプールは、待ち
行列として実装され、メモリのチャネル及びランクに亘ってメモリを分散するために最適
化され、不均等メモリアクセス（ＮＵＭＡ）の最適化分配をサポートする。少なくともい
くつかの実施形態において、パケット・バッファは、各パケット・バッファにおけるヘッ
ドルーム及びｔａｉｌｒｏｏｍを十分に過剰割り当てするＭｂｕｆパラダイムなどの方法
を使用して、バッファのコピーを必要とすることなく、外部ネットワークレイヤのヘッダ
を追加／削除するカプセル化／デカプセル化の操作をサポートする。
ロードバランサノード１１０の少なくともいくつかの実施形態において、コアパケット
処理のアーキテクチャは、ＤＰＤＫ技術を活用して実装される。各ロードバランサノード
１１０は、コアパケット処理のアーキテクチャに従って、実装されている少なくとも１つ
のマルチコア・パケット・プロセッサを有する。コアパケット処理のアーキテクチャは、
マルチコア・パケット・プロセッサの待ち行列及びコアを通過するパケットフローのため
に、単一の生産者／単一の消費者のパラダイムを使用する。このパラダイムにおいて、各
待ち行列は１つの及び１つのみのコアに入力し、各コアは自分がパケットを供給する他の
コアの各々に対する１つの及び１つのみのコアに出力する。さらに、マルチコア・パケッ
ト・プロセッサ内のコアによって使用されるメモリは共有ではなく、各コアは自分自身の
独立したメモリ領域を有する。したがって、コア間で共有するメモリまたは待ち行列はな
く、メモリ競合または待ち行列競合はなく、リクエスト・オブ・オーナーシップ（ＲＦＯ
）またはコンペア・アンド・スワップ（ＣＡＳ）などのメモリまたは待ち行列共有メカニ
ズムは必要ない。図２５及び図２６は、コアパケット処理のアーキテクチャに従って、実
装されている例示的なマルチコア・パケット・プロセッサを示す。
図２５は、少なくともいくつかの実施形態において、ＤＰＤＫ技術を活用してデータフ
ローを処理するコアパケット処理のアーキテクチャに従って、実装されている例示的なマ
ルチコア・パケット・プロセッサを示す。コアパケット処理のアーキテクチャは、単一の
生産者／単一の消費者のパラダイムに従って、マルチコア・パケット・プロセッサとして
実装される。少なくともいくつかの実施形態において、図２３に示されているように、ロ
ードバランサノード１１０の各々は、２つのネットワーク・インターフェイス・コントロ
ーラ（ＮＩＣ）すなわち境界ネットワーク／エッジルータ１０４に面する北向きＮＩＣ１
１１４Ａ及び生産ネットワーク／サーバノード１３０に面する南向きＮＩＣ１１１４Ｂを
有する。少なくともいくつかの実施形態において、ＮＩＣ１１１４は、１０ＧｂｐｓのＮ
ＩＣである。ロードバランサノード１１０を通って流れる主なパケットは、これら２つの
ＮＩＣの１つ（ＮＩＣ１１１４Ａまたは１１１４Ｂのいずれか）で受信され、処理され（
例えば、カプセル化またはデカプセル化され）、他のＮＩＣ（ＮＩＣ１１１４Ｂまたは１
１１４Ａのいずれか）に送信される。
図２５を参照すると、少なくともいくつかの実施形態において、ロードバランサノード
１１０は、各ＮＩＣ１１１４において、２つのＣＰＵコア、受信（ＲＸ）コア６１０及び
送信（ＴＸ）コア６３０をスピンアップする。ロードバランサノード１１０はまた、両方
のＮＩＣ１１１４に対するパケットを両方向で処理する多くのワーカーコア６２０をスピ
ンアップする。この実施例においては、４つのワーカーコア６２０Ａないし６２０Ｄが使
用される。受信コア６１０は、各受信コア６１０が各ワーカーコア６２０に対応するそれ
ぞれのワーカー入力待ち行列６１２の中にパケットを供給する場合に、それらの入力待ち
行列からの着信パケットがＮＩＣ１１１４に到達したときにそのバッチを読み取り、各パ
ケットに対するワークのバルクを実行するワーカーコア６２０に対して当該パケットを分
散する。少なくともいくつかの実施形態において、受信コア６１０は、（クライアント接
続のＩＰアドレス及びポートによって識別される）任意の特定のクライアント接続が同一
のワーカーコア６２０によって処理されることを保証するとともに、各着信パケットに対
してレイヤ４の「フローハッシュ」技法（前に説明したように、エッジルータ１０４によ
って使用される同様のフロー単位ハッシュ化マルチパス・ルーティング技法）を実行し、
当該パケットをワーカーコア６２０に分散する。このことは、各ワーカーコア６２０がパ
ケットの同一のサブセットを常に監視することを意味し、ロックが要求されないように、
ワーカーコア６２０によって管理されている状態データ上の競合を排除する。受信された
パケットへのポインタは、ワーカーコア６２０が新たな入力について連続的に監視するワ
ーカー待ち行列６２２に亘って分散される。ワーカーコア６２０は、各接続に対する（例
えば、割り当てられたサーバノード１３０の）状態を管理する責任を負うとともに、アウ
トバウンド待ち行列６３２の１つにパケットを転送する前に、パケットに対してＵＤＰの
カプセル化またはデカプセル化を実行する。送信コア６３０は、ワーカーコア６２０を介
してアウトバウンド待ち行列６３２を循環させ、出力パケットが待ち行列６３２上に現れ
たときに、それらの対応するＮＩＣ１１１４に対して当該出力パケットを書き込む。
図２６は、少なくともいくつかの実施形態において、ＤＰＤＫ技術を活用してデータフ
ローを処理するコアパケット処理のアーキテクチャに従って、実装されている他の例示的
なマルチコア・パケット・プロセッサを示す。コアパケット処理のアーキテクチャは、単
一の生産者／単一の消費者のパラダイムに従って、マルチコア・パケット・プロセッサと
して実装される。少なくともいくつかの実施形態において、高いスループットのクライア
ントＴＣＰフローに加えて、ロードバランサノード１１０上のＤＰＤＫコアのアーキテク
チャが使用され、ＡＲＰ、ＤＨＣＰ、及びＢＧＰなどの他のプロトコルについて、北及び
南向きＮＩＣ１１１４上のパケットを送信し且つ受信する。図２６に示されている実施形
態において、ワーカーコア６２０Ａは、これらの他のプロトコルにおいてパケットを取り
扱うために専用化されている。このワーカーコア６２０Ａは「遅い」ワーカーコアと称さ
れるが、それは一般的にクライアントＴＣＰフローよりも遅い速度で発生するパケットを
処理するからである。これに対して、クライアントＴＣＰフローのみを処理する他のワー
カーコア６２０Ｂないし６２０Ｄは、速いワーカーコアと称される。北向き及び南向きＮ
ＩＣ１１１４上でそれぞれ着信パケットを取り扱う受信コア６１０Ａ及び６１０Ｂは、遅
いワーカーコア６２０Ａによって取り扱われるべきパケットを識別すると、当該パケット
を遅いワーカーコア６２０Ａに対応する入力待ち行列６２２に導く。遅いワーカーコア６
２０Ａもまた、Ｊａｖａ／ＪＮＩによって生成されたパケットに対応する入力待ち行列６
２２、及びＪａｖａ／ＪＮＩに対する出力パケットに対応する出力待ち行列６３４を監視
する。遅いワーカーコア６２０Ａは、速いワーカーコア６２０Ｂないし６２０Ｄの各々に
対して、パケット、例えば、接続公開パケットを送信できるように、遅いワーカーコア６
２０Ａも、速いワーカーコア６２０Ｂないし６２０Ｄの各々に対応する入力待ち行列６２
２に対して出力する。遅いワーカーコア６２０Ａはまた、送信コア６３０Ａ及び６３０Ｂ
の各々に供給するアウトバウンド待ち行列６３２を有する。
少なくともいくつかの実施形態において、速いワーカーコア６２０Ｂないし６２０Ｄの
各々の第３の入力待ち行列６２２は、遅いワーカーコア６２０Ａからの出力待ち行列であ
る。少なくともいくつかの実施形態において、例えば、この第３の入力待ち行列６２２は
、各々が接続状態情報を有している接続公開パケットを受信するため且つ処理するために
、速いワーカー待ち行列６２０Ｂないし６２０Ｄによって使用される。これらの接続公開
パケットの少なくともいくつかについては、送信コア６３０に対する出力が存在しない。
その代わりに、パケットにおける接続状態情報は、例えば、それぞれの速いワーカーコア
６２０が維持する１以上のパケットフローに関する記憶された状態を更新することで、速
いワーカーコア６２０によって消費される。したがって、速いワーカーコア６２０Ｂない
し６２０Ｄに対して入力する遅いワーカーコア６２０Ａからの出力待ち行列は、速いワー
カーコアに記憶された状態を更新するために受信コア６１０から直接入力待ち行列６２２
以外の経路を提供する。
少なくともいくつかの実施形態において、図２５及び２６のマルチコア・パケット・プ
ロセッサは、着信パケットをフィルタ処理して、有効なパケットのみを処理し且つ出力す
る。例えば、少なくともいくつかの実施形態において、受信コア６１０は、いずれのワー
カーコア６２０によってもサポートされていないプロトコルのパケットをフィルタ処理で
除外するので、当該パケットをワーカーコア６２０に対して送信しない。少なくともいく
つかの実施形態において、ワーカーコア６２０の各々は、パケットを処理する場合に、パ
ケットがさらに処理することが受諾できるものかどうかを判定するため、及び、送信コア
６３０に対して出力するため、最初に該当するそれぞれのワーカー入力待ち行列６２２か
ら読み出したパケットを分析して、次に、受諾する送信コア６３０に対する当該パケット
のみ処理及び出力を完了する。受諾できないパケットは廃棄される。例えば、ワーカーコ
ア６２０は、各パケットのアドレス情報を調べて、負荷分散されている有効なアドレスに
的を絞ったパケットのみ受諾し、すべての他のパケットを廃棄する。
境界ゲートウェイ・プロトコル（ＢＧＰ）データの取り扱い
少なくともいくつかの実施形態において、コアのアーキテクチャの内部及び外部でＢＧ
Ｐクライアントに関連するパケットフローは、以下のように取り扱われる。ＮＩＣ１１１
４Ａ及び１１１４ＢはＬｉｎｕｘカーネルには向かわないので、エッジルータ１０４に対
するＴＣＰ接続は、図２６に示されているように、コアのアーキテクチャによって中断さ
れ、遅いワーカーコア６２２Ａによって処理され、遅いワーカーコア６２２Ａは、出力待
ち行列６３４を介してＪａｖａ空間の中に当該ＢＧＰパケットを渡す。これらのＴＣＰパ
ケットは、ロードバランサノード１１０上の１以上のモジュールによってさらに処理され
た後、ＴＣＰ接続を管理し且つＴＣＰストリームに当該パケットを有効に変換するＬｉｎ
ｕｘカーネルによる処理を含め、ＢＧＰクライアントに対して配信される。このデザイン
は、ＢＧＰクライアントが標準のＪａｖａＴＣＰソケットライブラリを用いて書かれるよ
うにする。
図２７は、少なくともいくつかの実施形態において、ロードバランサ（ＬＢ）ノード処
理部６５０による着信ＢＧＰ ＴＣＰパケットの処理を示す。エッジルータ１０４からの
パケットは、北向きＮＩＣ６４０に到達し、受信コア６５２に対応する入力待ち行列６４
０の中に進む。受信コア６５２は、待ち行列６４０からパケット、ＢＧＰパケットとして
識別されたパケットを読み取り、遅いワーカーコア６５６に対応する入力待ち行列６５４
上にパケットを配列する。遅いワーカーコア６５６は、パケットを確認して、ＪＮＩ出力
待ち行列６５８上にパケットを配列する。ＪＮＩパケット受信器６６０は、ＪＮＩを介し
て待ち行列６５８からパケットを読み取り、送信元／宛先アドレスを分解し、ｒａｗソケ
ット６４４に書き込む。Ｌｉｎｕｘカーネル６４６は、未処理パケットを受信し、ＴＣＰ
プロトコルに従って当該パケットを取り扱い、ＴＣＰソケット入力ストリームにペイロー
ドを追加する。パケットからのデータは、次に、ＢＧＰクライアント６６２の中のＪａｖ
ａ ＴＣＰソケットに対して配信される。
図２８は、少なくともいくつかの実施形態において、ロードバランサ（ＬＢ）ノード処
理部６５０による発信ＢＧＰ ＴＣＰパケットの処理を示す。ＢＧＰクライアント６６２
は、Ｌｉｎｕｘカーネル６４６のＪａｖａ ＴＣＰソケットにデータを書き込む。Ｌｉｎ
ｕｘカーネル６４６は、ＴＣＰプロトコルに従って、データを取り扱い、データをＴＣＰ
パケットに変換する。少なくともいくつかの実施形態において、ＴＣＰパケットは、１２
７．ｘ．ｘ．ｘ ｉｐｔａｂｌｅｓ規則に合致する。ＴＣＰパケットは、出力待ち行列６
４８、例えば、Ｎｅｔｆｉｌｔｅｒ ＬＯＣＡＬ＿ＯＵＴの待ち行列に配列される。ＪＮ
Ｉを介して待ち行列６４８を監視しているＪＮＩパケット受信器６７０のＪａｖａスレッ
ドは、ＴＣＰパケットを受信し、各ＮＦ＿ＳＴＯＬＥＮを印付けしてカーネル６４６がＴ
ＣＰパケットに関して忘れるようにする。Ｊａｖａスレッドは、送信元／宛先アドレスを
分解して、遅いワーカーコア６５６に対応するＪＮＩ入力待ち行列６７２にパケットをＪ
ＮＩを介して追加する。遅いワーカーコア６５６は、自分のＪＮＩ入力待ち行列６７２か
らＴＣＰパケットを受信し、北向きＮＩＣ６４０の送信コア６６６に対応するアウトバウ
ンド待ち行列６６４上にパケットを配列する。送信コア６６６は、自分の入力待ち行列６
６４からＴＣＰパケットを読み取り、北向きＮＩＣ６４０にそれらを書き込む。ＴＣＰパ
ケットは、ＮＩＣ６４０によってエッジルータに送信される。
分散型ロードバランサのシミュレーション及び試験
本明細書に記載されているロードバランサは、多数の独立した構成要素（例えば、ルー
タ、ロードバランサノード、ロードバランサモジュール等）の対話を要求する分散型シス
テムである。ノード障害、メッセージ欠落、及び遅延などのシナリオをシミュレーション
するためだけでなく、分散型の構成要素、ロジック、及びプロトコルの試験を実施するた
めに、複雑なネットワークトポロジ（例えば、生産ネットワーク）においてマルチホスト
に配備されるためのコードを必要とすることなく、対話が試験できるところで、単一のプ
ロセスにおいて動かせる分散型ロードバランサを可能にする試験システムの実施形態を説
明する。このことを達成するために、単一のプロセスにおいてまたは単一のプロセスとし
て多数のロードバランサの構成要素が構成され且つ実行されることを可能にするメッセー
ジバスと称されるソフトウェアのメカニズムを説明する。当該単一のプロセスは、単一の
ホストシステム上で実行される。メッセージバスのメカニズムは、例えば、単一のホスト
システム上で、同時に、ロードバランサの構成要素（例えば、ロードバランサノード及び
ロードバランサモジュール）が動いているように見える実際の生産ネットワーク上で、分
散型ロードバランサシステムが単一のプロセスとして試験されることを可能にする。
メッセージバスは、分散型ロードバランサが単一のプロセスとして動くことができるフ
レームワークを提供する。処理中の１以上のメッセージバスレイヤの各々は、分散型ロー
ドバランサの構成要素間のネットワーク（例えば、イーサネット（登録商標））のセグメ
ントをシミュレーションする。分散型ロードバランサシステムのソフトウェアの構成要素
は、メッセージバスの環境の範囲内で当該構成要素が動作できる特定の形態に書き込まれ
る必要はない。その代わりに、メッセージバスのフレームワークは、分散型ロードバラン
サシステムの構成要素が生産するパケットを中断する構成要素（メッセージバスＮＩＣま
たはパケットアダプタと称される）を提供して、実際の物理的なネットワークの中ではな
く、メッセージバスレイヤによって提供されたシミュレーションされたネットワークの中
にパケットを導き、目標の構成要素にパケットを配信する。メッセージバスレイヤは、構
成要素間の通信に対応するＴＣＰ／ＩＰスタックを実装しない。その代わりに、メッセー
ジバスレイヤは、ホストシステムのオペレーションシステム（ＯＳ）と整合して、ホスト
システムのＴＣＰ／ＩＰスタックを使用する。メッセージバスレイヤは、ＯＳによって提
供されるＴＣＰ／ＩＰスタックを活用して、メッセージバスが中断し且つ配信する個々の
パケットへ、またメッセージバスが中断し且つ配信する個々のパケットから、クライアン
ト及びサーバが期待するＴＣＰストリームを変換する。
少なくともいくつかの実施形態において、ロードバランサの構成要素は、メッセージバ
スと整合するために、各々が有効なメディアアクセス制御（ＭＡＣ）アドレスを有する少
なくとも１つのメッセージバス・ネットワーク・インターフェイス・コントローラ（ＮＩ
Ｃ）を備えており、各ＮＩＣは、物理的なネットワークとの間ではなく、シミュレーショ
ンされたネットワーク環境におけるメッセージバスとの間でパケットを送信し且つパケッ
トを受信する。メッセージバスＮＩＣは、物理的なネットワークではなく、メッセージバ
スに取り付ける仮想のネットワーク・インターフェイス・コントローラである。メッセー
ジバスを介して通信することを必要とする各ロードバランサの構成要素は、少なくとも１
つのメッセージバスＮＩＣを要求する。メッセージバスＮＩＣは、メッセージバスに対す
るパイプラインの出口として及び構成要素に対するパイプラインの入口としての機能を果
たす。構成要素は、各メッセージバスＮＩＣに対する多数のメッセージバス・インターフ
ェイスをインスタンス化できる。
メッセージバス・ネットワーク・インターフェイスは、構成要素がメッセージバスＮＩ
Ｃを介してメッセージバスに取り付けるためのメカニズムである。メッセージバス・ネッ
トワーク・インターフェイスは、Ｌｉｎｕｘ技術におけるインターフェイス構成（ｉｆｃ
ｏｎｆｉｇ）のインターフェイスと同義であるが、メッセージバス・ネットワーク・イン
ターフェイスが、物理的なネットワークに対してではなく、メッセージバスに対して取り
付けることが異なっている。メッセージバス・ネットワーク・インターフェイスは、ＩＰ
アドレスを有し、メッセージバスＮＩＣの上部に位置する。メッセージバス・ネットワー
ク・インターフェイスは、メッセージバスからのパケットを受信する構成要素によって使
用されることができるパケット送信元インターフェイス、及び、メッセージバスの中にパ
ケットを送信する構成要素によって使用されることができるパケットシンク・インターフ
ェイスを公開する。
各ロードバランサノードは、パケット送信元インターフェイス及びパケットシンク・イ
ンターフェイスの実装によって配信され且つ送信される個々のネットワーク・パケットを
処理する。これらのインターフェイスは、メッセージバス環境の中で動いている場合には
、レイヤ２のイーサネットヘッダを追加または削除する（カーネル・ネットワーク・スタ
ックによってこれが実行されると予想するロードバランサノードに対して）メッセージバ
ス・ネットワーク・インターフェイスによって実装される。図２９に示されているような
生産環境において、パケット送信元インターフェイス及びパケットシンク・インターフェ
イスの実装は、実際のネットワーク・インターフェイス上でメッセージバスのパケットを
受信し且つ送信する。図３０に示されているようなメッセージバス環境においては、パケ
ット送信元インターフェイス及びパケットシンク・インターフェイスの実装は、メッセー
ジバスレイヤまたは複数のレイヤからパケットを受信し且つそれに対してパケットを送信
する。
説明を簡単にするために、メッセージバスＮＩＣ及びメッセージバス・インターフェイ
スは、メッセージバスのパケットアダプタまたは単にパケットアダプタと総称する。図３
１及び３２を参照されたい。
図２９は、少なくともいくつかの実施形態において、生産環境における分散型ロードバ
ランサ７００を備えた分散型ロードバランシングシステムを示す。ロードバランサ７００
は、この記載では簡略化されている。ロードバランサ７００は、当該ロードバランサ７０
０を実装するデータセンターなどのネットワーク設定の境界ルータ７０２を介して、外部
ネットワーク７４０上のクライアント７４２に接続する。ロードバランサ７００は、様々
なタイプの構成要素、すなわち少なくとも１つのエッジルータ７０４、２以上のロードバ
ランサ（ＬＢ）ノード７１０、各々が独立したサーバノード（図示せず）上に実装されて
いる２以上のロードバランサ（ＬＢ）モジュール７３２、ルータまたはスイッチなどのフ
ァブリック７２０を形成する１以上のネットワーキング構成要素、及び、少なくともいく
つかの実施形態における構成サービス７２２を備える。少なくともいくつかの実施形態に
おいて、ロードバランサ７００の各構成要素は、汎用のラック収納型演算装置などの独立
した演算装置としてまたはその中に実装されている。
図３０は、少なくともいくつかの実施形態において、単一のプロセスにおいてまたは単
一のプロセスとして多数の分散型ロードバランシングシステムの構成要素が構成され且つ
実行されることを可能にするメッセージバスのメカニズムを搭載した分散型ロードバラン
サ試験システム８００を示す。図２９に示されているロードバランサ７００において、各
ロードバランサソフトウェアの構成要素は、独立した演算装置（例えば、ロードバランサ
ノード７１０上のロードバランサソフトウェア、及びサーバノード上のロードバランサモ
ジュール７３２）上でインストールされ且つ実行される。これらのロードバランサソフト
ウェアの構成要素が単一のプロセスにおいて実行できるようにするためには、ロードバラ
ンサソフトウェアの構成要素の内部及び外部のパケットが、物理的なネットワーク上で送
信され且つ受信される代わりに、メッセージバスのメカニズムを介して中断され且つルー
ティングされることができるように、ロードバランサソフトウェアの構成要素の各々（図
３０におけるロードバランサ（ＬＢ）ノード８１０及びロードバランサ（ＬＢ）モジュー
ル８３２に示されている）は、当該構成要素のネットワーク接続性を要約するコードを有
する。
少なくともいくつかの実施形態の分散型ロードバランサ試験システム８００において、
メッセージバスのメカニズムは、構成要素間の通信のためのＴＣＰスタックを実装しない
。その代わりに、メッセージバスのメカニズムは、ホストシステムのオペレーティングシ
ステム（ＯＳ）に整合して、ホストシステムのＴＣＰスタックを使用する。少なくともい
くつかの実施形態において、メッセージバスの機能は、ＩＰテーブルを介してユーザレイ
ヤの下のホストシステムのＯＳのカーネル（例えば、Ｌｉｎｕｘカーネル）、カーネルの
機能と結び付く。メッセージバスの機能は、カーネルレベルでＩＰテーブルの中に留まり
、パケットを中断し、ルーティングのためにメッセージバスのプロセス内に渡す。
図３０においてシミュレーションされたエッジルータ８６２及びシミュレーションされ
たファブリック８６４によって示されているように、物理的なネットワークの構成要素（
例えば、図２９におけるエッジルータ７０４及びファブリック７２０）の機能は、ソフト
ウェアの中でシミュレーションされ、同様に、クライアント８６０、サーバ８３４、及び
構成サービス８６６もシミュレーションが可能である。しかしながら、少なくともいくつ
かの実施形態において、シミュレーションされたサーバ８３４でなく実際のものが分散型
ロードバランサ試験システム８００において使用されることに留意されたい。図３０にお
けるメッセージバスのレイヤ８５０は、物理的なネットワークのインフラに取って代わる
。したがって、ロードバランサのソフトウェアの構成要素（ロードバランサノード８１０
及びロードバランサモジュール８３２）は、ロードバランサ試験システム８００において
動作するが、その一方で、これらのソフトウェアの構成要素は、図２９に示されているよ
うな生産ネットワーク環境において実行しないことは意識していない。
いくつかの構成要素（例えば、シミュレーションされたルータ）は、ネットワークセグ
メントをシミュレーションする異なるメッセージバスレイヤ８５０に対してパケットを渡
すこと、且つ当該レイヤ８５０からパケットを受信するために、２つ以上のメッセージバ
スのレイヤ８５０に接続される。
分散型ロードバランシング試験システム８００のメッセージバスレイヤ８５０に実装さ
れているメッセージバスのメカニズムは、ネットワークセグメントの「ワイヤー」をシミ
ュレーションする。少なくともいくつかの実施形態において、メッセージバスのメカニズ
ムは、構成要素のＭＡＣアドレスに基づいて、分散型ロードバランシング試験システム８
００における宛先の構成要素に対してパケットを配信する。したがって、各ロードバラン
サのソフトウェアの構成要素（ロードバランサノード８１０及びロードバランサモジュー
ル８３２）は、ロードバランサソフトウェアの構成要素が分散型ロードバランシング試験
システム８００において、他の構成要素から自分に送信されたパケットを受信することが
できるように、メッセージバスのレイヤ８５０に対してＭＡＣアドレスを提供し、当該Ｍ
ＡＣアドレスに接続される。
＜メッセージバスのパケットアダプタ＞
図３１及び３２は、少なくともいくつかの実施形態におけるメッセージバスのパケット
アダプタを示す。少なくともいくつかの実施形態において、各ロードバランサ（ＬＢ）ソ
フトウェアの構成要素は、ＰａｃｋｅｔＳｏｕｒｃｅ及びＰａｃｋｅｔＳｉｎｋインター
フェイスの実装によって、配信され且つ送信される個々のネットワーク・パケットを処理
する。図３１を参照すると、これらのインターフェイス（パケット送信元・インターフェ
イス８６２及びパケットシンク・インターフェイス８６４として示されている）は、分散
型ロードバランシングシステム８００内で動いている場合には、メッセージバスレイヤ８
５０と、カーネルのネットワークスタックによってこれが実行されることを予期する、ロ
ードバランサソフトウェアの構成要素８７０のためにレイヤ２のイーサネットヘッダを追
加または削除するロードバランサソフトウェアの構成要素８７０の間のパケットアダプタ
８６０に実装される。図２９に示されているような生産環境においては、ロードバランサ
ソフトウェアの構成要素に対するＰａｃｋｅｔＳｏｕｒｃｅインターフェイス及びＰａｃ
ｋｅｔＳｉｎｋインターフェイスの実装は、当該構成要素が実装される物理的な装置の実
際のネットワーク・インターフェイス上で、パケットを受信し且つ送信する。
図３１を参照すると、少なくともいくつかの実施形態において、ロードバランサソフト
ウェアの構成要素８７０がパケットを送信する場合には、パケットシンク・インターフェ
イス８６４の送信パケット方法を呼び出す実行のスレッドは、パケットアダプタ８６０の
中において、及びメッセージバスレイヤ８５０の中においても、一連の機能を横断して、
その構成要素の入力待ち行列に対してパケットを追加することによって宛先の構成要素に
対して最終的にパケットを配信する。少なくともいくつかの実施形態において、ロードバ
ランサソフトウェアの構成要素８７０がパケットを受信する場合には、ロードバランサソ
フトウェアの構成要素８７０は、パケット送信元インターフェイス８６２の受信パケット
方法を呼び出して、自分の入力待ち行列からパケットを読み取る。少なくともいくつかの
実施形態において、メッセージバスのメカニズムは、自分自身のいかなる追加スレッドを
も要求することなく、パケットを配信する。
メッセージバスのパケットパイプライン
図３２を参照すると、少なくともいくつかの実施形態において、パケット送信元インタ
ーフェイス８６２及びパケットシンク・インターフェイス８６４のメッセージバス８５０
側は、パケットパイプライン機能を提供する。ロードバランサソフトウェアの構成要素８
７０がパケットシンク・インターフェイス８６４を介してパケットを送信した場合、パケ
ットは一連の段階（パケットパイプライン８８０）を横断した後に、メッセージバスのレ
イヤ８５０に到達する。これらの段階は、例えば、パケットを変更し、パケットを破棄し
、パケットを複製し、パケットを遅延させる。一旦パケットがパケットパイプライン８８
０を横断し、メッセージバスのレイヤ８５０が、宛先の構成要素８７０を選択すると、パ
ケットは、宛先の構成要素８７０に関連する次の一連のパイプライン段階（パケットパイ
プライン８８２）も横断した後に、宛先の構成要素８７０の入力待ち行列に追加される。
例示的なプロバイダのネットワーク環境
このセクションでは、分散型ロードバランシング方法及び装置の実施形態が実装される
例示的なプロバイダ・ネットワーク環境について説明する。しかしながら、これらの例示
的なプロバイダ・ネットワーク環境に限定される意図ではない。
図３３Ａは、少なくともいくつかの実施形態において、例示的なプロバイダ・ネットワ
ーク環境を示す。プロバイダ・ネットワーク１９００は、クライアントがアクセスするこ
と、購入すること、借り受けることを可能にするか、さもなければ、限定はされないが、
演算資源及び記憶資源を含み、プロバイダ・ネットワークまたは１以上のデータセンター
のネットワーク内の装置上に実装されている仮想化された資源インスタンス１９１２を得
ることを可能にする１以上の仮想化サービス１９１０を介して、資源の仮想化をクライア
ントに提供する。プライベートＩＰアドレス１９１６は資源インスタンス１９１２に関連
し、当該プライベートＩＰアドレスはプロバイダ・ネットワーク１９００上の資源インス
タンス１９１２の内部ネットワークアドレスである。いくつかの実施形態において、プロ
バイダ・ネットワーク１９００はまた、クライアントがプロバイダ１９００から取得する
パブリックＩＰアドレス１９１４及び／またはパブリックＩＰアドレスの範囲（例えば、
インターネット・プロトコル・バージョン４（ＩＰｖ４）またはインターネット・プロト
コル・バージョン６（ＩＰｖ６）アドレス）を提供する。
従来、プロバイダ・ネットワーク１９００は、仮想化サービス１９１０を介して、サー
ビス・プロバイダのクライアント（例えば、クライアントネットワーク１９５０Ａを操作
するクライアント）が、クライアントに対して割り当てられる特定の資源インスタンス１
９１２でクライアントに対して割り当てられまたは割り振られる少なくともいくつかのパ
ブリックＩＰアドレス１９１４に動的に対応付けることを可能にする。プロバイダ・ネッ
トワーク１９００はまた、クライアントに割り当てられて以前にマッピングされた１つの
仮想化演算資源インスタンス１９１２に対して、これもクライアントに割り当てられた他
の仮想化演算資源インスタンス１９１２に対して、パブリックＩＰアドレス１９１４にク
ライアントが再マッピングすることを可能にする。仮想化演算資源インスタンス１９１２
及びサービス・プロバイダによって提供されたパブリックＩＰアドレス１９１４を使用す
ると、クライアントネットワーク１９５０Ａのオペレータなどのサービス・プロバイダの
クライアントは、例えば、クライアント専用アプリケーションを実装して、インターネッ
トなどの中間ネットワーク１９４０上で当該クライアントアプリケーションを提示する。
中間ネットワーク１９４０上の他のネットワークエンティティ１９２０は、その後、クラ
イアントネットワーク１９５０Ａによって公開された宛先のパブリックＩＰアドレス１９
１４に対するトラフィックを生成し、そのトラフィックはサービス・プロバイダのデータ
センターにルーティングされ、データセンターにおいて、ネットワーク基板を介して、宛
先のパブリックＩＰアドレス１９１４に現在マッピングされている仮想化演算資源インス
タンス１９１２のプライベートＩＰアドレス１９１６に対してルーティングされる。同様
に、仮想化演算の資源インスタンス１９１２からの応答トラフィックは、ネットワーク基
板を介して、中間ネットワーク１９４０上でルーティングされて送信元エンティティ１９
２０に戻る。
本明細書で使用されているようなプライベートＩＰアドレスは、プロバイダ・ネットワ
ークにおける資源インスタンスの内部ネットワークアドレスのことを指す。プライベート
ＩＰアドレスは、プロバイダ・ネットワーク内でのみルーティング可能である。プロバイ
ダ・ネットワークの外部で発生したネットワークトラフィックは、プライベートＩＰアド
レスには直接的にルーティングできないが、その代わりに、当該トラフィックは、資源イ
ンスタンスにマッピングされているパブリックＩＰアドレスを使用する。プロバイダ・ネ
ットワークは、ネットワーク装置またはネットワークアドレス変換（ＮＡＴ）または同様
の機能を実現する専用装置を有し、パブリックＩＰアドレスからプライベートＩＰアドレ
スへのマッピング及びその逆を実行する。
本明細書で使用されているようなパブリックＩＰアドレスは、サービス・プロバイダま
たはクライアントのいずれかによって資源インスタンスに割り当てられたインターネット
のルーティング可能なネットワークアドレスである。パブリックＩＰアドレスにルーティ
ングされたトラフィックは、例えば、１対１のネットワークアドレス変換（ＮＡＴ）を介
して変換され、資源インスタンスのそれぞれのプライベートＩＰアドレスに転送される。
いくつかのパブリックＩＰアドレスは、プロバイダ・ネットワークのインフラによって
特定の資源インスタンスに割り当てられ、これらのパブリックＩＰアドレスは、標準パブ
リックＩＰアドレスまたは単に標準ＩＰアドレスと称される。少なくともいくつかの実施
形態において、資源インスタンスのプライベートＩＰアドレスに対する標準ＩＰアドレス
のマッピングは、資源インスタンスのすべてのタイプについてデフォルトの起動構成であ
る。
少なくともいくつかのＩＰアドレスは、プロバイダ・ネットワーク１９００のクライア
ントに対して割り振られ、またはこれらのクライアントによって取得され、次に、クライ
アントは、それらの割り振られたパブリックＩＰアドレスを当該クライアントに割り振ら
れた特定の資源インスタンスに割り当てる。これらのパブリックＩＰアドレスは、クライ
アントパブリックＩＰアドレスまたは単にクライアントＩＰアドレスと称される。標準Ｉ
Ｐアドレスの場合のように、プロバイダ・ネットワーク１９００によって資源インスタン
スに割り当てられる代わりに、クライアントＩＰアドレスは、例えば、サービス・プロバ
イダによって提供されたＡＰＩを介して、クライアントによって資源インスタンスに割り
当てられる。標準ＩＰアドレスとは異なり、クライアントＩＰアドレスは、クライアント
のアカウントに割り当てられ、必要または要望に応じて、それぞれのクライアントによっ
て他の資源インスタンスに再マッピングされることが可能である。クライアントＩＰアド
レスは、クライアントのアカウントに関連するが、特定の資源インスタンスには関連せず
、クライアントは、クライアントがそれを開放することを選択するまではそのＩＰアドレ
スを制御する。従来の静的ＩＰアドレスとは異なり、クライアントＩＰアドレスは、クラ
イアントのパブリックＩＰアドレスをクライアントのアカウントに関連する任意の資源イ
ンスタンスに再マッピングすることによって、クライアントが資源インスタンスまたはア
ベイラビリティゾーンの障害をマスクすることができるようにする。クライアントＩＰア
ドレスは、例えば、代替の資源インスタンスにクライアントＩＰアドレスを再マッピング
することによって、クライアントの資源インスタンスまたはソフトウェアに関わる問題に
ついて、クライアントが処理できるようにする。
図３３Ｂは、図３３Ａに示されているような例示的なプロバイダ・ネットワーク環境に
おいて、分散型ロードバランサの実装を示す。プロバイダ・ネットワーク１９００は、ク
ライアント１９６０に対して、サービス１９１０、例えば、仮想化記憶サービスを提供す
る。クライアント１９６０は、例えば、サービス１９１０に対応する１以上のＡＰＩを介
して、サービス１９１０にアクセスして、プロバイダ・ネットワーク１９００の生産ネッ
トワーク部分における多数のサーバノード１９９０上に実装された資源（例えば、記憶資
源または演算資源）の使用法を取得する。サーバノード１９９０の各々は、ローカルロー
ドバランサ（ＬＢ）モジュール１９９２だけでなく、ウェブサーバまたはアプリケーショ
ンサーバなどのサーバ（図示せず）を実装する。１以上の分散型ロードバランサ１９８０
は、境界ネットワークと生産ネットワークとの間のロードバランサレイヤの中に実装され
ている。境界ルータ１９７０は、インターネットなどの中間ネットワーク１９４０を介し
て、クライアント１９６０からのパケットフローの中のパケット（例えば、ＴＣＰパケッ
ト）を受信して、境界ネットワークを介して、分散型ロードバランサ１９８０のエッジル
ータに対してパケットを転送する。パケットは、分散型ロードバランサ１９８０のエッジ
ルータによって公開されたパブリックＩＰアドレスに向かう。各分散型ロードバランサ１
９８０のエッジルータは、それぞれの分散型ロードバランサ１９８０のロードバランサノ
ードの中にパケットフローを分散する。少なくともいくつかの実施形態において、入口ノ
ードとしての機能を果たす各ロードバランサノードは、同じパブリックＩＰアドレスをエ
ッジルータに広告し、エッジルータは、クライアント１９６０からのパケットフローを、
フロー単位ハッシュ化マルチパス・ルーティング技法、例えば、等価マルチパス（ＥＣＭ
Ｐ）ハッシュ処理技法に従って、入口サーバの中に分散する。ロードバランサノードは、
本明細書に記載された接続プロトコルを使用して、パケットフローに対応する目標のサー
バノード１９９０を決定し、サーバとクライアント１９６０との間の接続を推進する。接
続が確立すると、入口ノードは、フローに関する受信されたパケットをカプセル化して、
生産ネットワーク上の目標のサーバノード１９９０に送信し、その一方で、フロー追跡部
ノードは、接続に関する状態を維持する。サーバノード１９９０上のロードバランサモジ
ュール１９９２は、サーバノード１９６０上のそれぞれのサーバが接続を受諾するかどう
かについて決定を下す。ロードバランサモジュールは、入口ノードからのパケットを受信
してデカプセル化して、サーバノード１９９０上のそれぞれのサーバに対して、デカプセ
ル化されたパケット（例えば、ＴＣＰパケット）を送信する。ロードバランサモジュール
１９９２はまた、パケットフローに対応する出口ノードとしてのロードバランサノードを
選択し、フローに関する発信パケットをカプセル化して、生産ネットワークを介して、選
択された出口ノードに対して送信する。出口ノードは、順に、パケットをデカプセル化し
て、それぞれのクライアント１９６０に対して配信する境界ネットワーク上でデカプセル
化されたパケットを送信する。
図３４Ａは、少なくともいくつかの実施形態において、分散型ロードバランサ及びサー
バノードの例示的な物理的なラック実装を示すが、これに限定される意図ではない。少な
くともいくつかの実施形態において、分散型ロードバランサの様々な構成要素は、汎用の
ラック収納型の演算装置上にまたはそれ自体として実装されている。ラック１９０は、各
々がロードバランサノード（ＬＢノード１１０Ａ〜１１０Ｆ）としての機能を果たしてい
る多数の演算装置、及び各々がサーバノード（サーバノード１３０Ａ〜１３０Ｌ）として
の機能を果たしている多数の演算装置を含む。ラック１９０はまた、少なくとも１つのエ
ッジルータ１０４、ファブリック１２０を形成する１以上のラック収納型ネットワーク装
置（ルータ、スイッチ等）、及び１つ以上の他の構成要素１８０（他のネットワーク装置
、パッチパネル、電源、冷却システム、バス等）も備える。図３３Ａ及び３３Ｂのプロバ
イダ・ネットワーク１９００を実装するデータセンターやセンターなどのネットワーク１
００のインストールは、１以上のラック１９０を備える。
図３４Ｂは、少なくともいくつかの実施形態において、分散型ロードバランサ及びサー
バノードの例示的な物理的なラック実装を示すが、これに限定される意図ではない。図３
４Ｂは、スロット収納型演算装置として、例えば、ブレードサーバがラック１９０内に実
装されているＬＢノード１１０及びサーバノード１３０を示す。
図３５は、少なくともいくつかの実施形態において例示的なネットワーキング環境を示
しており、そこでは、別個に実装されたサーバノードを有する１、２または３以上の分散
型ロードバランサがネットワークに実装されている。この実施例においては、２つの分散
型ロードバランサ１９８０Ａ及び１９８０Ｂが示されている。分散型ロードバランサ１９
８０の各々は、境界ネットワークを介して、クライアント１９６０からのパケットフロー
を受信し、本明細書に記載されたロードバランシング方法を実行して、多数のサーバノー
ド１９９０の中にパケットを分散する。いくつかの実装において、各分散型ロードバラン
サ１９８０は、サーバノードがロードバランサラックの中にインストールされていないこ
とを除けば、図３４Ａ及び３４Ｂに示されているラック１９０と同様にラック実装である
。サーバノード１９９０は、データセンター内において、１以上の独立したラックにイン
ストールされたブレードサーバなどのラック収納型演算装置である。いくつかの実装にお
いて、サーバノード１９９０は、異なる１以上のロードバランサ１９８０によって対応さ
れる各サービスを含め、プロバイダ・ネットワークによって提供される異なる２以上のサ
ービスを実施する。
例示的なシステム
少なくともいくつかの実施形態において、本明細書に記載されているような分散型ロー
ドバランシング方法及び装置の一部または全部を実行するサーバは、図３６に示されてい
るコンピュータシステム２０００のような、コンピュータアクセス可能な１以上の媒体を
有するか、またはそれにアクセスする構成の汎用のコンピュータシステムを備える。例示
された実施形態において、コンピュータシステム２０００は、入出力（Ｉ／Ｏ）インター
フェイス２０３０を介して、システムメモリ２０２０に接続された１以上のプロセッサ２
０１０を備える。コンピュータシステム２０００は、さらに、入出力インターフェイス２
０３０に接続されたネットワーク・インターフェイス２０４０を備えている。
様々な実施形態において、コンピュータシステム２０００は、１つのプロセッサ２０１
０を有するユニプロセッサシステム、または数個（例えば、２、４、８、または他の適切
な数）のプロセッサ２０１０を有するマルチプロセッサシステムである。プロセッサ２０
１０は、命令を実行することができる任意の適切なプロセッサである。例えば、様々な実
施形態において、プロセッサ２０１０は、汎用のプロセッサ、または任意の様々な命令セ
ットアーキテクチャ（ＩＳＡ）、例えば、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、または
ＭＩＰＳＩＳＡ若しくは任意の他の適切なＩＳＡを実装している内臓型プロセッサである
。マルチプロセッサシステムにおいて、プロセッサ２０１０の各々は、必須でないが、同
じＩＳＡを一般に実装する。
システムメモリ２０２０は、プロセッサ２０１０によってアクセス可能な命令及びデー
タを記憶するように構成されている。様々な実施形態において、システムメモリ２０２０
は、スタティックＲＡＭ（ＳＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、不揮発性
／フラッシュタイプのメモリ、または任意の他のタイプのメモリなどの任意の適切なメモ
リ技術を使用して実装される。例示された実施形態において、分散型ロードバランシング
方法及び装置について上記した方法、技法、及びデータなどの以上の所望の機能を実施す
るプログラム命令及びデータは、システムメモリ２０２０内に示されるようにコード２０
２４及びデータ２０２６として記憶されている。
１つの実施形態において、入出力インターフェイス２０３０は、プロセッサ２０１０、
システムメモリ２０２０、及びネットワーク・インターフェイス２０４０または他の周辺
インターフェイスを含む装置内の任意の周辺装置の間で、入出力トラフィックを調整する
構成になっている。いくつかの実施形態において、入出力インターフェイス２０３０は、
任意の必要なプロトコル、タイミング、または他のデータ変換を実行して、１つの構成要
素（例えば、システムメモリ２０２０）からのデータ信号を他の構成要素（例えば、プロ
セッサ２０１０）での使用のために適切な形式に変換する。いくつかの実施形態において
、入出力インターフェイス２０３０は、例えば、周辺構成要素相互接続（ＰＣＩ）バス標
準またはユニバーサルシリアルバス（ＵＳＢ）標準の変形などの様々なタイプの周辺バス
を介して接続される装置のためのサポートを含む。いくつかの実施形態において、入出力
インターフェイス２０３０の機能は、例えば、ノースブリッジ及びサウスブリッジなどの
２以上の独立した構成要素に分かれる。また、いくつかの実施形態において、入出力イン
ターフェイス２０３０のいくつかまたはすべての機能は、システムメモリ２０２０に対す
るインターフェイスなどのように、プロセッサ２０１０の中に直接組み込まれている。
ネットワーク・インターフェイス２０４０は、コンピュータシステム２０００と、１つ
のネットワークまたはネットワーク２０５０に接続された他の装置２０６０、例えば、図
１ないし図３５に例示されているような他のコンピュータシステムまたは装置との間で、
データが交換され得るように構成されている。様々な実施形態において、ネットワーク・
インターフェイス２０４０は、例えば、イーサネットネットワークのタイプなどの、任意
の適切な有線または無線の一般的なデータネットワークを介して、通信をサポートする。
さらに、ネットワーク・インターフェイス２０４０は、アナログ音声ネットワークまたは
デジタルファイバ通信ネットワークなどの電気通信／電話通信ネットワークを介して、フ
ァイバチャネルＳＡＮなどのストレージエリア・ネットワークを介して、または、任意の
他の適切なタイプのネットワーク及び／またはプロトコルを介して、通信をサポートする
。
少なくともいくつかの実施形態において、システムメモリ２０２０は、分散型ロードバ
ランシングシステムの実施形態を実装するために、図１ないし３５について上記したよう
に、プログラム命令及びデータを記憶するように構成されたコンピュータ読み取り可能な
媒体の１つの実施形態である。しかしながら、他の実施形態においては、プログラム命令
及び／またはデータは、異なるタイプのコンピュータ読み取り可能な媒体上で、受信され
、送信され、または記憶される。一般に、コンピュータ読み取り可能な媒体は、非一時的
記憶媒体、またはメモリ媒体、例えば、入出力インターフェイス２０３０を介してコンピ
ュータシステム２０００に接続された、ディスクまたはＤＶＤ／ＣＤの磁気または光媒体
などを含む。非一時的なコンピュータ読み取り可能な媒体はまた、ＲＡＭ（例えば、ＳＤ
ＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭなどのような、任意の
揮発性または不揮発性の媒体を含み、システムメモリ２０２０または他のタイプのメモリ
として、コンピュータシステム２０００のいくつかの実施形態に含まれている。さらに、
コンピュータアクセス可能な媒体は、伝送媒体、またはネットワーク及び／または無線リ
ンクなどの通信媒体を介して伝送される電気信号、電磁気信号、またはデジタル信号など
の信号を有し、例えば、ネットワーク・インターフェイス２０４０を介して実装される。
開示された実施形態は、以下の条項の観点で記載されることができる。
１．分散型ロードバランサシステムであって、
複数のロードバランサノード、及び
各々がサーバ及びロードバランサモジュールを有する複数のサーバノードを備え、その
中で、
前記複数のロードバランサノードは、１以上のクライアントからのパケットフローを前
記複数のサーバノードの中に分散し、前記複数のサーバノードの中に分散するように構成
され、
前記複数のロードバランサノードは、前記複数のサーバノードの中からサーバノードを
選択し、前記パケットフローについての接続要求を前記クライアントから受信し、且つ、
前記接続要求を前記選択されたサーバノードに対して送信するように構成され、
各サーバノード上の前記ロードバランサモジュールは、前記複数のロードバランサノー
ドの１つからのパケットフローについての接続要求を受信し、前記接続が前記サーバノー
ド上の前記サーバによって受諾されるかどうかを判定し、前記サーバが前記接続を受諾で
きない場合には、前記接続要求を拒絶し、且つ、前記サーバが前記接続を受諾できる場合
には、前記複数のロードバランサノードと協働して、前記それぞれのクライアントと前記
それぞれのサーバとの間のパケットフローについての接続を確立するように構成されてい
る、
前記分散型ロードバランサシステム。
２．条項１に記載された分散型ロードバランサシステムは、さらに、ハッシュ化マルチ
パス・ルーティング技法に従って、前記１以上のクライアントからの前記パケットフロー
を前記複数のロードバランサノードの中に分散するように構成されたルータをさらに備え
る、
前記分散型ロードバランサシステム。
３．条項１に記載された分散型ロードバランサシステムは、その中で、前記サーバノー
ド上の前記サーバによって前記接続が受諾されるかどうかを判定するために、前記ロード
バランサモジュールが、前記サーバノード上の前記サーバの１以上の現在の資源使用量の
メトリクスを分析して、前記接続を前記サーバが受諾できるかどうかを判定するように構
成され、その中で、前記１以上の現在の資源の使用量のメトリクスが、１以上のＣＰＵの
使用、帯域幅の使用量、サーバ待ち時間、及び確立された接続数を含む、
前記分散型ロードバランサシステム。
４．条項１に記載された分散型ロードバランサシステムは、その中で、前記複数のロー
ドバランサノードが、さらに、前記接続要求を受信するため前記複数のサーバノードの中
から、ランダムな選択技法に従って前記サーバノードを選択するように構成されている、
前記分散型ロードバランサシステム。
５．条項１に記載された分散型ロードバランサシステムは、その中で、前記複数のロー
ドバランサノードが、さらに、拒絶された接続要求を受信するために前記複数のサーバノ
ードの中から、他のサーバノードを選択し、前記接続要求を前記他のサーバノードに対し
て送信するように構成されている、
前記分散型ロードバランサシステム。
６．条項１に記載された分散型ロードバランサシステムは、その中で、各パケットフロ
ーが伝送制御プロトコル（ＴＣＰ）パケットフローであり、またその中で、クライアント
とサーバとの間に確立された各接続がＴＣＰ接続である、
前記分散型ロードバランサシステム。
７．条項１に記載された分散型ロードバランサシステムは、その中で、クライアントと
サーバとの間で確立された各接続が、前記クライアントに始まり、前記複数のロードバラ
ンサノードの１以上の中を通って、前記サーバによって終端される、
前記分散型ロードバランサシステム。
８．方法であって、
クライアントに対するパケットフローにおけるパケットを受信すること、及び
前記パケットフローについての接続要求を複数のサーバノードの中から選択されたサー
バノードに対して送信することを、
１以上の複数のロードバランサノードによって実行し、
前記サーバノード上のサーバが前記接続を受諾できるかまたはできないかどうかを判定
すること、
前記サーバが前記接続を受諾できないと判定したときは前記接続要求を拒絶すること、
及び
前記サーバが前記接続を受諾できると判定したときは前記接続要求を受諾することを、
前記選択されたサーバノードによって実行する、
前記方法。
９．条項８に記載された方法は、その中で、前記接続要求を受諾することが、前記選択
されたサーバノードと前記１以上のロードバランサノードとが協働して前記パケットフロ
ーについて前記それぞれのクライアントと前記それぞれのサーバとの間で接続を確立する
ことを含む、
前記方法。
１０．条項９に記載された方法は、その中で、前記パケットフローが伝送制御プロトコ
ル（ＴＣＰ）パケットフローであり、またその中で、前記クライアントと前記サーバとの
間で確立された接続がＴＣＰ接続である、
前記方法。
１１．条項９に記載された方法は、その中で、前記確立された接続がクライアントに始
まり、前記複数のロードバランサノードの１つの中を通って、前記サーバによって終端さ
れる、
前記方法。
１２．条項８に記載された方法は、その中で、１以上のクライアントからのパケットフ
ローをハッシュ化マルチパス・ルーティング技法に従って前記複数のロードバランサノー
ドの中に分散するルータから前記パケットが受信される、
前記方法。
１３．条項８に記載された方法は、その中で、前記サーバノード上のサーバが前記接続
を受諾できるかまたはできないかどうかを前記判定することが、前記サーバの１以上の現
在の資源使用量のメトリクスを分析して前記接続を受諾できるかどうかを判定することを
含む、
前記方法。
１４．条項８に記載された方法は、前記１以上のロードバランサノードが、ランダム選
択技法に従って、前記複数のサーバノードの中からサーバノードを選択することをさらに
含む、
前記方法。
１５．条項８に記載された方法は、前記選択されたサーバノードが前記接続要求を拒絶
した場合に、前記１以上のロードバランサノードが、前記複数のサーバノードの中から選
択された他のサーバノードに対して前記接続要求を送信することをさらに含む、
前記方法。
１６．複数のサーバノードの各々の上にロードバランサモジュールを実装するためにコ
ンピュータが実行可能なプログラム命令を記憶するコンピュータ読み取り可能な非一時的
記憶媒体であって、各ロードバランサモジュールが、
クライアントからのパケットフローについての接続要求を複数のロードバランサノードの
１つから受信し、
前記サーバノード上のサーバが前記接続を受諾できるかまたはできないかどうかを判定
し、
前記サーバが前記接続を受諾できないと判定したときは前記接続要求を拒絶し、及び
前記サーバが前記接続を受諾できると判定したときは前記ロードバランサノードと前記
サーバとが通信して、前記クライアントと前記サーバとの間に接続を確立する、
ように動作可能である、
前記コンピュータ読み取り可能な非一時的媒体。
１７．条項１６に記載された非一時的なコンピュータ読み取り可能な記憶媒体は、その
中で、前記サーバノード上のサーバが前記接続を受諾できるかまたはできないかどうかを
判定するために、前記ロードバランサモジュールが、前記サーバの１以上の現在の資源使
用量のメトリクスを分析して、前記サーバが前記接続を受諾できるかどうかを決定するこ
とを実行できる前記コンピュータ読み取り可能な非一時的媒体。
１８．条項１７に記載された非一時的なコンピュータ読み取り可能な記憶媒体は、その
中で、前記１以上の現在の資源使用量のメトリクスが、１以上のＣＰＵの使用、帯域幅の
使用量、サーバ待ち時間、及び確立された接続数を含む、
前記コンピュー読み取り可能な非一時的記憶媒体。
１９．条項１６に記載されたコンピュータ読み取り可能な非一時的記憶媒体は、その中
で、前記プログラム命令は、さらに、前記接続要求を受信するために前記複数のサーバノ
ードの中からサーバノードをランダムに選択する前記ロードバランサモジュールを実現す
るようにコンピュータが実行できる、
前記非一時的なコンピュータ読み取り可能な記憶媒体。
２０．条項１６に記載されたコンピュータ読み取り可能な非一時的記憶媒体は、その中
で、前記接続要求を拒絶するために、前記接続要求の中の生存時間（ＴＴＬ）カウンタを
減じて、前記接続要求を前記ロードバランサノードに対して返送するように前記ロードバ
ランサモジュールが動作でき、その中で、 前記プログラム命令は、さらに、前記ロード
バランサノードが、
前記返送された接続要求の中の前記ＴＴＬカウンタを検査し、
前記ＴＴＬカウンタが閾値を超えている場合には、前記接続要求を受信するために前記
複数のサーバノードの中から他のサーバノードを選択し、及び
前記ＴＴＬカウンタが前記閾値以下である場合には、前記接続要求を廃棄することを実
現するようにコンピュータを実行可能にする、
前記コンピュータ読み取り可能な非一時的記憶媒体。
結論
様々な実施形態は、さらに、上記の説明に従って、コンピュータ読み取り可能な媒体に
実装される受信処理、送信処理、または記憶処理の命令及び／またはデータを有する。一
般に、コンピュータ読み取り可能な媒体は、磁気媒体または光媒体などの記録媒体または
メモリ媒体、例えば、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、ＲＡＭ（例えば、ＳＤＲＡ
Ｍ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の揮発性の媒体または不揮発性の媒体
を含むが、それと同様に、電気信号、電磁気信号、またはデジタル信号などのように、ネ
ットワーク及び／または無線リンクなどの通信媒体を介して運ばれる伝送媒体または信号
も含む。
図面及び本明細書に記載しているような様々な方法は、例示的な方法の実施形態を表わ
す。その方法は、ソフトウェア、ハードウェア、またはそれらの組み合わせの中に実装さ
れている。方法の順序は変えることができ、様々な要素は、追加され、再配列され、組み
合わされ、削除され、修正される等が可能である。
様々な修正及び変更は、本開示の利益を享受する当業者にとって明らかなようになされ
るだろう。このような修正及び変更のすべてを包含することは意図されることであり、し
たがって、上記記載は制限的な意味ではなく例示的な意味に見なされるべきである。

Claims (12)

  1. 分散型ロードバランサシステムであって、
    各々がサーバ及びロードバランサモジュールを備える複数のサーバノード、及び
    １以上のクライアントからのパケットフローを前記複数のサーバノードの中に分散するように構成される複数のロードバランサノードと、
    を備え、
    前記複数のロードバランサノードのうちの１以上のロードバランサノードは、
    前記クライアントのうちの１つからのパケットフローのための同期パケットを受信し、
    前記複数のサーバノードの中から前記パケットフローのためのサーバノードを選択し、
    前記パケットフローに対する接続要求を生成し、
    前記接続要求を、前記選択された前記サーバノード上の前記ロードバランサモジュールに送信する、
    ように構成され、
    前記選択された前記サーバノード上の前記ロードバランサモジュールは、
    前記接続要求を、前記複数のロードバランサノードのうちの１つから受信し、
    前記パケットフローに対する接続が前記サーバノード上の前記サーバによって受諾されるかどうかを、前記サーバの１以上の現在の資源使用量のメトリクスの分析に少なくとも部分的に基づいて判定し、前記１以上の現在の資源使用量のメトリクスは、１以上のＣＰＵの使用、帯域幅の使用量、サーバ待ち時間、及び確率された接続数を含み、
    前記サーバが前記接続を受諾できない場合は、前記ロードバランサノードに前記接続が拒絶されたことを示すメッセージを送信し、
    前記サーバが前記接続を受諾できる場合には、
    前記接続要求のための同期パケットを生成し、
    前記同期パケットを前記サーバノード上の前記サーバに送信し、
    前記サーバノード上の前記サーバからの確認パケットを中断し、
    前記ロードバランサノードに、前記接続が受諾されたことを示すメッセージを送信する、
    ように構成される、分散型ロードバランサシステム。
  2. 前記接続が受諾された後、前記ロードバランサモジュールはさらに、
    前記接続に対する発信トラフィックを受信するための出口サーバとして動作する、前記複数のロードバランサノードのうちの１つを選択し、
    前記接続におけるカプセル化された着信ＩＰパケットを前記接続のための入口サーバとして動作する前記複数のロードバランサノードのうちの１つから受信し、前記着信ＩＰパケットをデカプセル化し、前記デカプセル化した前記着信ＩＰパケットを前記サーバに送信し、
    前記サーバからの前記接続における発信ＩＰパケットを中断し、前記発信ＩＰパケットをカプセル化し、前記カプセル化されたＩＰパケットを前記選択された前記出口サーバへ送信する、
    ように構成される、請求項１に記載の分散型ロードバランサシステム。
  3. 前記接続要求から前記ロードバランサモジュールによって生成された前記同期パケットの送信元ＩＰアドレスは前記クライアントのＩＰアドレスである、請求項１に記載の分散型ロードバランサシステム。
  4. 前記１以上のロードバランサノードはさらに、
    前記ロードバランサモジュールから前記接続が受諾されたことを示す前記メッセージを受信する前に、前記クライアントからの前記パケットフローで受信された１以上のＩＰパケットをバッファリングし、
    前記ロードバランサモジュールから前記接続が受諾されたことを示す前記メッセージを受信した後に、前記バッファリングされた前記1以上のＩＰパケットをカプセル化し、前記カプセル化されたＩＰパケットを前記ロードバランサモジュールへ転送する、
    ように構成される、請求項１に記載の分散型ロードバランサシステム。
  5. 前記ロードバランサノードに前記接続が拒絶されたことを示すメッセージを送信するために、前記ロードバランサモジュールは、前記接続要求の中の生存時間（ＴＴＬ）カウンタを減じて、前記接続要求を前記ロードバランサノードに対して返送するように構成され、前記ロードバランサノードは、
    前記返送された接続要求の中の前記ＴＴＬカウンタを検査し、
    前記ＴＴＬカウンタが閾値を超えている場合には、前記複数のサーバノードの中から他のサーバノードを選択し、前記接続要求を前記他のサーバノードに送信し、
    前記ＴＴＬカウンタが前記閾値以下である場合には、前記接続要求を廃棄する
    ように構成されている、請求項１に記載の分散型ロードバランサシステム。
  6. ハッシュ化マルチパス・ルーティング技法に従って、前記１以上のクライアントからの前記パケットフローを前記複数のロードバランサノードの中に分散するように構成されたルータをさらに備える、請求項１に記載の分散型ロードバランサシステム。
  7. 複数のロードバランサノードのうちの１以上のロードバランサノードによって、
    クライアントに対するパケットフローにおけるパケットを受信すること、及び
    前記パケットフローについての接続要求を複数のサーバノードの中から選択されたサーバノードに対して送信すること、
    を実行し、
    前記選択されたサーバノード上のロードバランサモジュールによって、
    前記複数のロードバランサモジュールのうちの１つから前記接続要求を受信し、
    それぞれの前記パケットフローに対する接続が前記サーバノード上のサーバによって受諾されるか否かを、前記サーバの１以上の現在の資源使用量のメトリクスの分析に少なくとも部分的に基づいて判定し、前記１以上の現在の資源使用量のメトリクスは、１以上のＣＰＵの使用、帯域幅の使用量、サーバ待ち時間、及び確率された接続数を含み、
    前記サーバが前記接続を受諾できない場合は、前記ロードバランサノードに前記接続が拒絶されたことを示すメッセージを送信し、
    前記サーバが前記接続を受諾できる場合には、
    前記接続要求のための同期パケットを前記サーバノード上の前記サーバに送信し、
    前記サーバノード上の前記サーバからの確認パケットを中断し、
    前記ロードバランサノードに、前記接続が受諾されたことを示すメッセージを送信する、
    ことを実行することを備える方法。
  8. 前記接続が受諾された後、前記選択されたサーバノード上の前記ロードバランサモジュールによって、
    前記接続に対する発信トラフィックを受信するための出口サーバとして動作する、前記複数のロードバランサノードのうちの１つを選択し、
    前記接続におけるカプセル化された着信ＩＰパケットを前記接続のための入口サーバとして動作する前記複数のロードバランサノードのうちの１つから受信し、前記着信ＩＰパケットをデカプセル化し、前記デカプセル化した前記着信ＩＰパケットを前記サーバに送信し、
    前記サーバからの前記接続における発信ＩＰパケットを中断し、前記発信ＩＰパケットをカプセル化し、前記カプセル化されたＩＰパケットを前記選択された前記出口サーバへ送信する、
    ことをさらに実行することを備える、請求項７に記載の方法。
  9. 前記サーバに送信された前記同期パケットの送信元ＩＰアドレスは前記クライアントのＩＰアドレスである、請求項７に記載の方法。
  10. 前記１以上のロードバランサノードによって、
    前記ロードバランサモジュールから前記接続が受諾されたことを示す前記メッセージを受信する前に、前記クライアントからの前記パケットフローで受信された１以上のＩＰパケットをバッファリングし、
    前記ロードバランサモジュールから前記接続が受諾されたことを示す前記メッセージを受信した後に、前記バッファリングされた前記1以上のＩＰパケットをカプセル化し、前記カプセル化されたＩＰパケットを前記ロードバランサモジュールへ転送する、
    ことをさらに実行することを備える、請求項７に記載の方法。
  11. 接続が前記サーバノード上のサーバによって受諾されるか否かを前記判定することが、
    前記サーバのための資源の利用率を前記１以上の現在の資源使用量から判定し、
    前記資源の利用率を２以上の利用のレベルと比較し、
    前記接続が前記２以上の利用のレベルにおいて異なる確率で拒絶される、
    ことを備える、請求項７に記載の方法。
  12. 前記接続が拒絶されたことを示す前記メッセージに応答して、前記１以上のロードバランサノードが前記接続要求を前記複数のサーバノードの中から選択された他のサーバノードに送信することをさらに備える、請求項７に記載の方法。
JP2017112933A 2013-04-16 2017-06-07 分散型ロードバランサ Active JP6445621B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/864,167 2013-04-16
US13/864,167 US10069903B2 (en) 2013-04-16 2013-04-16 Distributed load balancer

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2016509084A Division JP6194100B2 (ja) 2013-04-16 2014-04-16 分散型ロードバランサ

Publications (2)

Publication Number Publication Date
JP2017184272A JP2017184272A (ja) 2017-10-05
JP6445621B2 true JP6445621B2 (ja) 2018-12-26

Family

ID=51687576

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2016509084A Active JP6194100B2 (ja) 2013-04-16 2014-04-16 分散型ロードバランサ
JP2017112933A Active JP6445621B2 (ja) 2013-04-16 2017-06-07 分散型ロードバランサ

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2016509084A Active JP6194100B2 (ja) 2013-04-16 2014-04-16 分散型ロードバランサ

Country Status (10)

Country Link
US (2) US10069903B2 (ja)
EP (2) EP3651440B1 (ja)
JP (2) JP6194100B2 (ja)
KR (2) KR101790315B1 (ja)
CN (2) CN110166568B (ja)
AU (1) AU2016277754B2 (ja)
BR (1) BR112015026342B1 (ja)
CA (1) CA2909621C (ja)
SG (1) SG11201508556RA (ja)
WO (1) WO2014172500A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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

Families Citing this family (167)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8560634B2 (en) * 2007-10-17 2013-10-15 Dispersive Networks, Inc. Apparatus, systems and methods utilizing dispersive networking
ES2639643T3 (es) 2010-06-23 2017-10-27 Telefonaktiebolaget Lm Ericsson (Publ) Gestión de interferencias de señales de referencia en despliegues de redes heterogéneas
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
JP6182861B2 (ja) * 2012-12-28 2017-08-23 富士通株式会社 情報処理装置、情報処理端末、情報検索プログラム及び情報検索方法
US10069903B2 (en) 2013-04-16 2018-09-04 Amazon Technologies, Inc. Distributed load balancer
CN104144120A (zh) * 2013-05-07 2014-11-12 杭州华三通信技术有限公司 转发信息配置方法及装置
US9225638B2 (en) 2013-05-09 2015-12-29 Vmware, Inc. Method and system for service switching using service tags
US9391919B2 (en) 2013-08-14 2016-07-12 International Business Machines Corporation Adaptive algorithm for cloud admission policies
US9843540B2 (en) 2013-08-26 2017-12-12 Vmware, Inc. Traffic and load aware dynamic queue management
US9348602B1 (en) 2013-09-03 2016-05-24 Amazon Technologies, Inc. Resource allocation for staged execution pipelining
US20150081400A1 (en) * 2013-09-19 2015-03-19 Infosys Limited Watching ARM
US9379982B1 (en) * 2013-09-30 2016-06-28 Juniper Networks, Inc. Adaptive stateless load balancing
US10063458B2 (en) 2013-10-13 2018-08-28 Nicira, Inc. Asymmetric connection with external networks
CN104811396A (zh) * 2014-01-23 2015-07-29 中兴通讯股份有限公司 一种负荷均衡的方法及系统
US9602424B1 (en) * 2014-03-31 2017-03-21 Amazon Technologies, Inc. Connection balancing using attempt counts at distributed storage systems
US10021028B2 (en) * 2014-06-16 2018-07-10 International Business Machines Corporation Controlling incoming traffic
US10122605B2 (en) 2014-07-09 2018-11-06 Cisco Technology, Inc Annotation of network activity through different phases of execution
DE102014109906B4 (de) * 2014-07-15 2016-03-03 Fujitsu Technology Solutions Intellectual Property Gmbh Verfahren zum Freischalten externer Computersysteme in einer Computernetz-Infrastruktur, verteiltes Rechnernetz mit einer solchen Computernetz-Infrastruktur sowie Computerprogramm-Produkt
US10123232B2 (en) 2014-07-22 2018-11-06 Parallel Wireless, Inc. Signaling storm reduction from radio networks
US11159980B2 (en) 2014-07-22 2021-10-26 Parallel Wireless, Inc. Signaling storm reduction from radio networks
US9755898B2 (en) 2014-09-30 2017-09-05 Nicira, Inc. Elastically managing a service node group
US10257095B2 (en) 2014-09-30 2019-04-09 Nicira, Inc. Dynamically adjusting load balancing
US10225137B2 (en) 2014-09-30 2019-03-05 Nicira, Inc. Service node selection by an inline service switch
US9876714B2 (en) 2014-11-14 2018-01-23 Nicira, Inc. Stateful services on stateless clustered edge
US9866473B2 (en) 2014-11-14 2018-01-09 Nicira, Inc. Stateful services on stateless clustered edge
US11533255B2 (en) * 2014-11-14 2022-12-20 Nicira, Inc. Stateful services on stateless clustered edge
US10044617B2 (en) 2014-11-14 2018-08-07 Nicira, Inc. Stateful services on stateless clustered edge
US9485310B1 (en) * 2014-12-23 2016-11-01 EMC IP Holding Company LLC Multi-core storage processor assigning other cores to process requests of core-affined streams
US9690576B2 (en) * 2015-02-11 2017-06-27 Dell Software, Inc. Selective data collection using a management system
US20160255013A1 (en) * 2015-02-27 2016-09-01 Ixia Dynamic Resource Management For Load Balancing In Network Packet Communication Systems
US9985875B1 (en) 2015-03-31 2018-05-29 Juniper Networks, Inc. Route signalling based resilient application overlay network
US10250562B1 (en) 2015-03-31 2019-04-02 Juniper Networks, Inc. Route signaling driven service management
US10609091B2 (en) 2015-04-03 2020-03-31 Nicira, Inc. Method, apparatus, and system for implementing a content switch
US20160301575A1 (en) * 2015-04-07 2016-10-13 Quanta Computer Inc. Set up and verification of cabling connections in a network
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
US20170032300A1 (en) * 2015-07-31 2017-02-02 International Business Machines Corporation Dynamic selection of resources on which an action is performed
US9900377B2 (en) * 2015-08-07 2018-02-20 International Business Machines Corporation Dynamic healthchecking load balancing gateway
US10169172B2 (en) * 2015-08-11 2019-01-01 International Business Machines Corporation Passive detection of live systems during controller failover in distributed environments
US9942153B2 (en) * 2015-08-14 2018-04-10 Dell Products L.P. Multiple persistant load balancer system
BR112018002477A2 (pt) 2015-09-25 2018-09-18 Deutsche Telekom Ag método para manipulação melhorada de pelo menos uma troca de comunicação entre uma rede de telecomunicações e pelo menos um equipamento de usuário, rede de elecomunicações, equipamento de usuário, sistema, programa e produto de programa de computador
US10666574B2 (en) 2015-09-28 2020-05-26 Amazon Technologies, Inc. Distributed stream-based database triggers
US10623319B1 (en) 2015-09-28 2020-04-14 Amazon Technologies, Inc. Load rebalancing in a network-based system
US10033645B2 (en) * 2015-09-29 2018-07-24 Dell Products L.P. Programmable data plane hardware load balancing system
US10205677B2 (en) 2015-11-24 2019-02-12 Cisco Technology, Inc. Cloud resource placement optimization and migration execution in federated clouds
US10296394B2 (en) * 2015-12-04 2019-05-21 Nec Corporation Consistent hashing
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
US20170214627A1 (en) * 2016-01-21 2017-07-27 Futurewei Technologies, Inc. Distributed Load Balancing for Network Service Function Chaining
JP6126259B1 (ja) * 2016-02-25 2017-05-10 日本電信電話株式会社 監視装置、監視方法、及びプログラム
US10291706B1 (en) * 2016-03-24 2019-05-14 EMC IP Holding Company LLC Container image distribution acceleration
US10432709B2 (en) * 2016-03-28 2019-10-01 Industrial Technology Research Institute Load balancing method, load balancing system, load balancing device and topology reduction method
US10574741B2 (en) 2016-04-18 2020-02-25 Nokia Technologies Oy Multi-level load balancing
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
US10567344B2 (en) 2016-08-23 2020-02-18 Cisco Technology, Inc. Automatic firewall configuration based on aggregated cloud managed information
US10938668B1 (en) * 2016-09-30 2021-03-02 Amazon Technologies, Inc. Safe deployment using versioned hash rings
KR102567971B1 (ko) * 2016-11-10 2023-08-17 삼성전자주식회사 스토리지 어레이를 공유하는 다수의 서버 노드들을 포함하는 메모리 시스템 및 그 동작 방법
CN110326252B (zh) 2016-11-14 2022-05-17 诚信保安服务有限责任公司 设备的安全供应和管理
CN108173775A (zh) * 2016-12-08 2018-06-15 北京京东尚科信息技术有限公司 用于服务器限流的方法与系统
US10742746B2 (en) 2016-12-21 2020-08-11 Nicira, Inc. Bypassing a load balancer in a return path of network traffic
CN108259370A (zh) * 2016-12-28 2018-07-06 航天信息股份有限公司 数据传输的方法及装置
US10735996B2 (en) * 2017-01-23 2020-08-04 Parallel Wireless, Inc. Systems and methods for a scalable heterogeneous network orchestrator
US10320683B2 (en) 2017-01-30 2019-06-11 Cisco Technology, Inc. Reliable load-balancer using segment routing and real-time application monitoring
US9787671B1 (en) * 2017-01-30 2017-10-10 Xactly Corporation Highly available web-based database interface system
US10671571B2 (en) 2017-01-31 2020-06-02 Cisco Technology, Inc. Fast network performance in containerized environments for network function virtualization
US10476945B2 (en) * 2017-02-01 2019-11-12 Juniper Networks, Inc. Consistent flow assignment in load balancing
US11005731B2 (en) 2017-04-05 2021-05-11 Cisco Technology, Inc. Estimating model parameters for automatic deployment of scalable micro services
US10491520B2 (en) * 2017-04-06 2019-11-26 Ca, Inc. Container-based software appliance
US10693951B2 (en) 2017-06-01 2020-06-23 Salesforce.Com, Inc. Decentralized, resource aware load distribution in a distributed system
US10713223B2 (en) * 2017-06-01 2020-07-14 Salesforce.Com, Inc. Opportunistic gossip-type dissemination of node metrics in server clusters
US10382274B2 (en) 2017-06-26 2019-08-13 Cisco Technology, Inc. System and method for wide area zero-configuration network auto configuration
US10439877B2 (en) 2017-06-26 2019-10-08 Cisco Technology, Inc. Systems and methods for enabling wide area multicast domain name system
US10432513B2 (en) 2017-07-14 2019-10-01 Nicira, Inc. Asymmetric network elements sharing an anycast address
US10250493B2 (en) 2017-07-14 2019-04-02 Nicira, Inc. Asymmetric network elements sharing an anycast address
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
US11570092B2 (en) 2017-07-31 2023-01-31 Nicira, Inc. Methods for active-active stateful network service cluster
US10951584B2 (en) 2017-07-31 2021-03-16 Nicira, Inc. Methods for active-active stateful network service cluster
US11296984B2 (en) 2017-07-31 2022-04-05 Nicira, Inc. Use of hypervisor for active-active stateful network service cluster
US10834230B2 (en) * 2017-08-25 2020-11-10 International Business Machines Corporation Server request management
CN109510855B (zh) * 2017-09-15 2020-07-28 腾讯科技（深圳）有限公司 事件分发系统、方法及装置
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
CN107743152B (zh) * 2017-12-07 2020-09-22 南京易捷思达软件科技有限公司 一种OpenStack云平台中负载均衡器的高可用的实现方法
US10705882B2 (en) 2017-12-21 2020-07-07 Cisco Technology, Inc. System and method for resource placement across clouds for data intensive workloads
US11223565B2 (en) * 2017-12-22 2022-01-11 Nokia Technologies Oy Designs of an MPTCP-aware load balancer and load balancer using the designs
US11595474B2 (en) 2017-12-28 2023-02-28 Cisco Technology, Inc. Accelerating data replication using multicast and non-volatile memory enabled nodes
US10659252B2 (en) 2018-01-26 2020-05-19 Nicira, Inc Specifying and utilizing paths through a network
US10797910B2 (en) 2018-01-26 2020-10-06 Nicira, Inc. Specifying and utilizing paths through a network
CN108306771B (zh) * 2018-02-09 2021-06-18 腾讯科技（深圳）有限公司 日志上报方法、装置及系统
US11153122B2 (en) 2018-02-19 2021-10-19 Nicira, Inc. Providing stateful services deployed in redundant gateways connected to asymmetric network
JP6888567B2 (ja) * 2018-02-26 2021-06-16 日本電信電話株式会社 通信装置、通信方法、及びプログラム
US11005925B2 (en) * 2018-02-28 2021-05-11 International Business Machines Corporation Load balancing with power of random choices
US11012410B2 (en) * 2018-03-13 2021-05-18 Charter Communications Operating, Llc Distributed denial-of-service prevention using floating internet protocol gateway
US10728174B2 (en) 2018-03-27 2020-07-28 Nicira, Inc. Incorporating layer 2 service between two interfaces of gateway device
US10805192B2 (en) 2018-03-27 2020-10-13 Nicira, Inc. Detecting failure of layer 2 service using broadcast messages
US10511534B2 (en) * 2018-04-06 2019-12-17 Cisco Technology, Inc. Stateless distributed load-balancing
US11876684B1 (en) * 2018-05-22 2024-01-16 Amazon Technologies, Inc. Controlled cross-cell migration of data in cell-based distributed computing architecture
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
US10680955B2 (en) * 2018-06-20 2020-06-09 Cisco Technology, Inc. Stateless and reliable load balancing using segment routing and TCP timestamps
US10819571B2 (en) 2018-06-29 2020-10-27 Cisco Technology, Inc. Network traffic optimization using in-situ notification system
AU2019300777A1 (en) * 2018-07-07 2021-01-07 Integrity Security Services Llc Scalable certificate management system architectures
US11075984B1 (en) * 2018-07-16 2021-07-27 Amazon Technologies, Inc. Workload management at streaming data service supporting persistent connections for reads
CN110769464A (zh) * 2018-07-25 2020-02-07 慧与发展有限责任合伙企业 分发任务
US10904342B2 (en) 2018-07-30 2021-01-26 Cisco Technology, Inc. Container networking using communication tunnels
WO2020026335A1 (ja) * 2018-07-31 2020-02-06 Quadrac株式会社 サーバ装置及びシステム
US11650862B2 (en) 2018-07-31 2023-05-16 Parallel Wireless, Inc. Service bus for telecom infrastructure
US10681091B2 (en) * 2018-07-31 2020-06-09 Juniper Networks, Inc. N:1 stateful application gateway redundancy model
JP6544817B1 (ja) * 2018-07-31 2019-07-17 Quadrac株式会社 サーバ装置及びシステム
US10855590B2 (en) * 2018-08-31 2020-12-01 Gigamon Inc. Elastic modification of application instances in a network visibility infrastructure
US10944673B2 (en) 2018-09-02 2021-03-09 Vmware, Inc. Redirection of data messages at logical network gateway
US11595250B2 (en) 2018-09-02 2023-02-28 Vmware, Inc. Service insertion at logical network gateway
US11144340B2 (en) * 2018-10-04 2021-10-12 Cisco Technology, Inc. Placement of container workloads triggered by network traffic for efficient computing at network edge devices
US10826832B2 (en) 2018-11-21 2020-11-03 Amazon Technologies, Inc. Load balanced access to distributed scaling endpoints using global network addresses
US11418581B2 (en) * 2019-01-31 2022-08-16 T-Mobile Usa, Inc. Load balancer shared session cache
US11604666B2 (en) 2019-02-22 2023-03-14 Vmware, Inc. Service path generation in load balanced manner
US10855580B2 (en) 2019-03-27 2020-12-01 Amazon Technologies, Inc. Consistent route announcements among redundant controllers in global network access point
US11144226B2 (en) 2019-04-11 2021-10-12 Samsung Electronics Co., Ltd. Intelligent path selection and load balancing
US11570100B2 (en) * 2019-04-25 2023-01-31 Advanced New Technologies Co., Ltd. Data processing method, apparatus, medium and device
US11540170B2 (en) * 2019-05-20 2022-12-27 Commscope Technologies Llc Load-testing a cloud radio access network
US11216190B2 (en) 2019-06-10 2022-01-04 Samsung Electronics Co., Ltd. Systems and methods for I/O transmissions in queue pair-based NVMeoF initiator-target system
US11704617B2 (en) * 2019-06-20 2023-07-18 Stripe, Inc. Systems and methods for modeling and analysis of infrastructure services provided by cloud services provider systems
US10908834B2 (en) * 2019-06-28 2021-02-02 Hitachi, Ltd. Load balancing for scalable storage system
US11301316B2 (en) 2019-07-12 2022-04-12 Ebay Inc. Corrective database connection management
US11038952B2 (en) 2019-07-12 2021-06-15 Ebay Inc. Connection service discovery and load rebalancing
US11240294B2 (en) 2019-08-23 2022-02-01 Samsung Electronics Co., Ltd. Systems and methods for spike detection and load balancing resource management
US11095480B2 (en) 2019-08-30 2021-08-17 Vmware, Inc. Traffic optimization using distributed edge services
US11070469B1 (en) * 2019-09-11 2021-07-20 Juniper Networks, Inc. Scaling border gateway protocol services
US11140081B2 (en) * 2019-10-01 2021-10-05 At&T Intellectual Property I, L.P. Extending distributed hash table-based software network functions to switching hardware
KR102235100B1 (ko) * 2019-10-08 2021-04-01 브이에스아이 주식회사 공유 버스를 통해 복수의 서버들에 예비 통신로를 제공할 수 있는 시스템
US11038793B2 (en) 2019-10-15 2021-06-15 Cisco Technology, Inc. Service assurance of ECMP using virtual network function hashing algorithm
US11025534B2 (en) * 2019-10-15 2021-06-01 Cisco Technology, Inc. Service-based node-centric ECMP health
US20210127296A1 (en) * 2019-10-25 2021-04-29 Qualcomm Incorporated Reducing feedback latency for network coding in wireless backhaul communications networks
US11283717B2 (en) 2019-10-30 2022-03-22 Vmware, Inc. Distributed fault tolerant service chain
CN110795250B (zh) * 2019-10-30 2023-05-12 腾讯科技（深圳）有限公司 负载调度方法、装置、设备及存储介质
US11140218B2 (en) 2019-10-30 2021-10-05 Vmware, Inc. Distributed service chain across multiple clouds
CN111010342B (zh) * 2019-11-21 2023-04-07 天津卓朗科技发展有限公司 一种分布式负载均衡实现方法及装置
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
US11438257B2 (en) 2020-04-06 2022-09-06 Vmware, Inc. Generating forward and reverse direction connection-tracking records for service paths at a network edge
US11429452B2 (en) 2020-04-16 2022-08-30 Paypal, Inc. Method for distributing keys using two auxiliary hashing functions
CN111694663B (zh) * 2020-06-02 2023-11-03 中国工商银行股份有限公司 服务器集群的负载均衡方法、装置及系统
CN113783904B (zh) * 2020-06-09 2023-05-09 比亚迪股份有限公司 负载均衡方法、路由服务器及负载均衡系统
US11606294B2 (en) 2020-07-16 2023-03-14 Vmware, Inc. Host computer configured to facilitate distributed SNAT service
US11616755B2 (en) 2020-07-16 2023-03-28 Vmware, Inc. Facilitating distributed SNAT service
US11611613B2 (en) * 2020-07-24 2023-03-21 Vmware, Inc. Policy-based forwarding to a load balancer of a load balancing cluster
US11451413B2 (en) 2020-07-28 2022-09-20 Vmware, Inc. Method for advertising availability of distributed gateway service and machines at host computer
US11902050B2 (en) 2020-07-28 2024-02-13 VMware LLC Method for providing distributed gateway service at host computer
US11394636B1 (en) 2020-12-10 2022-07-19 Amazon Technologies, Inc. Network connection path obfuscation using global access points
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
CN112799811A (zh) * 2021-01-26 2021-05-14 重庆邮电大学 一种边缘网关的高并发线程池任务调度方法
WO2022187645A1 (en) * 2021-03-05 2022-09-09 Fastly, Inc. System and method for deterministic hash addressing
US11706193B2 (en) * 2021-08-09 2023-07-18 Juniper Networks, Inc. Intelligent flow state synchronization to improve resiliency, availability, and/or performance of redundant network security devices
US11799761B2 (en) 2022-01-07 2023-10-24 Vmware, Inc. Scaling edge services with minimal disruption
WO2024035634A1 (en) * 2022-08-11 2024-02-15 Cisco Technology, Inc. Scalable creation of connections
KR102530913B1 (ko) * 2023-02-08 2023-05-10 주식회사 파이오링크 패킷의 콘텐츠 기반으로 dsr 로드 밸런싱을 수행하는 방법 및 패킷 콘텐츠 기반 dsr 로드 밸런싱 시스템

Family Cites Families (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
JP3556476B2 (ja) 1998-07-13 2004-08-18 富士通株式会社 ロードシェアシステム及び処理要求中継プログラムを記録したコンピュータ読み取り可能な記録媒体
EP1368736A2 (en) 2001-01-11 2003-12-10 Z-Force Communications, Inc. File switch and switched file system
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 ネットワークシステム及び負荷分散方法
CN1150464C (zh) * 2001-07-26 2004-05-19 华为技术有限公司 一种在应用层交换中提高服务器响应速度的系统及方法
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 Ｎｅｃアクセステクニカ株式会社 負荷分散方法、コンテンツ配信システム及び負荷分散装置
JP2003163689A (ja) * 2001-11-28 2003-06-06 Hitachi Ltd ネットワーク連携情報処理システムおよびその複数負荷分散機間のアクセス移動方法
JP3898498B2 (ja) 2001-12-06 2007-03-28 富士通株式会社 サーバ負荷分散システム
US7644436B2 (en) * 2002-01-24 2010-01-05 Arxceo Corporation Intelligent firewall
US7088718B1 (en) * 2002-03-19 2006-08-08 Cisco Technology, Inc. Server load balancing using IP option field approach to identify route to selected server
US7260645B2 (en) * 2002-04-26 2007-08-21 Proficient Networks, Inc. Methods, apparatuses and systems facilitating determination of network path metrics
US7380002B2 (en) * 2002-06-28 2008-05-27 Microsoft Corporation Bi-directional affinity within a load-balancing multi-node network interface
US7480737B2 (en) * 2002-10-25 2009-01-20 International Business Machines Corporation Technique for addressing a cluster of network servers
US7353276B2 (en) * 2003-02-13 2008-04-01 Microsoft Corporation Bi-directional affinity
JPWO2004088940A1 (ja) * 2003-03-31 2006-07-06 富士通株式会社 負荷分散システム
CN1300986C (zh) * 2003-04-14 2007-02-14 华为技术有限公司 实现快速五七层交换的方法
CN100581157C (zh) * 2003-04-18 2010-01-13 智邦科技股份有限公司 将第七层负载平衡器的工作负荷转移至服务器端来处理的方法
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
US7567504B2 (en) 2003-06-30 2009-07-28 Microsoft Corporation Network load balancing with traffic routing
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
US20050027862A1 (en) 2003-07-18 2005-02-03 Nguyen Tien Le System and methods of cooperatively load-balancing clustered servers
US20050050187A1 (en) * 2003-09-03 2005-03-03 International Business Machines Corporation Method and apparatus for support of bottleneck avoidance in an intelligent adapter
US20050071469A1 (en) * 2003-09-26 2005-03-31 Mccollom William G. Method and system for controlling egress traffic load balancing between multiple service providers
US20060112170A1 (en) * 2004-05-03 2006-05-25 Craig Sirkin Geo-locating load balancing
US7020090B2 (en) * 2004-06-21 2006-03-28 Cisco Technology, Inc. System and method for loadbalancing in a network environment using feedback information
JP2006195904A (ja) * 2005-01-17 2006-07-27 Sharp Corp 処理実行方法、処理実行システム、処理実行装置、処理要求装置、コンピュータプログラム及び記録媒体
US7496653B2 (en) * 2005-01-31 2009-02-24 International Business Machines Corporation Method, system, and computer program product for providing quality of service guarantees for clients of application servers
US8315172B2 (en) * 2005-12-30 2012-11-20 Telefonaktiebolaget Lm Ericsson (Publ) Monitoring access nodes in a distributed radio access network
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
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 深圳市金蝶中间件有限公司 会话控制方法、装置及系统
KR101104249B1 (ko) * 2008-12-11 2012-01-11 한국전자통신연구원 단말기의 캐리어 선택 방법 및 그것의 호 접속 방법
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> 仮想通信路接続システムおよび仮想通信路接続方法
US8848728B1 (en) * 2010-04-08 2014-09-30 Marvell Israel (M.I.S.L) Ltd. Dynamic load balancing switch architecture
CN102859949B (zh) 2010-04-30 2015-12-02 惠普发展公司，有限责任合伙企业 用于在胖树网络中路由数据分组的方法
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 日本電信電話株式会社 サーバ負荷分散システム及び方法
US8351329B2 (en) * 2010-09-14 2013-01-08 Cisco Technology, Inc. Universal load-balancing tunnel encapsulation
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
US8776207B2 (en) * 2011-02-16 2014-07-08 Fortinet, Inc. Load balancing in a network with session information
US8676980B2 (en) 2011-03-22 2014-03-18 Cisco Technology, Inc. Distributed load balancer in a virtual machine environment
CN102882699B (zh) * 2011-07-14 2015-07-29 华为技术有限公司 边缘节点的分配方法和装置及边缘节点控制器
US9590820B1 (en) * 2011-09-02 2017-03-07 Juniper Networks, Inc. Methods and apparatus for improving load balancing in overlay networks
CN103023797B (zh) * 2011-09-23 2016-06-15 百度在线网络技术（北京）有限公司 数据中心系统及装置和提供服务的方法
US20130185586A1 (en) * 2012-01-18 2013-07-18 LineRate Systems, Inc. Self-healing of network service modules
US8825867B2 (en) 2012-05-04 2014-09-02 Telefonaktiebolaget L M Ericsson (Publ) Two level packet distribution with stateless first level packet distribution to a group of servers and stateful second level packet distribution to a server within the group
US9325785B2 (en) 2012-06-29 2016-04-26 Rodolfo Kohn Device, system, and method for client-governed session persistency between one or more clients and servers of a data center
US20140025800A1 (en) * 2012-07-23 2014-01-23 Radisys Corporation Systems and methods for multi-blade load balancing
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
US10069903B2 (en) * 2013-04-16 2018-09-04 Amazon Technologies, Inc. Distributed load balancer
US10038626B2 (en) 2013-04-16 2018-07-31 Amazon Technologies, Inc. Multipath routing in a distributed load balancer

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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

Also Published As

Publication number Publication date
JP2017184272A (ja) 2017-10-05
JP6194100B2 (ja) 2017-09-06
CA2909621C (en) 2019-06-04
EP2987304A1 (en) 2016-02-24
EP3651440B1 (en) 2023-06-07
EP3651440A1 (en) 2020-05-13
AU2016277754B2 (en) 2018-02-01
CN105308929A (zh) 2016-02-03
KR20170121311A (ko) 2017-11-01
CN110166568A (zh) 2019-08-23
JP2016518081A (ja) 2016-06-20
CA2909621A1 (en) 2014-10-23
KR20150140819A (ko) 2015-12-16
CN105308929B (zh) 2019-06-07
SG11201508556RA (en) 2015-11-27
US10069903B2 (en) 2018-09-04
KR101790315B1 (ko) 2017-10-26
BR112015026342B1 (pt) 2022-12-06
WO2014172500A1 (en) 2014-10-23
US20180375928A1 (en) 2018-12-27
BR112015026342A8 (pt) 2019-12-24
EP2987304B1 (en) 2020-01-22
BR112015026342A2 (pt) 2017-07-25
AU2014253953A1 (en) 2015-11-12
AU2016277754A1 (en) 2017-02-02
US11843657B2 (en) 2023-12-12
US20140310418A1 (en) 2014-10-16
AU2014253953B2 (en) 2016-09-29
EP2987304A4 (en) 2016-11-23
CN110166568B (zh) 2022-04-15
KR101863024B1 (ko) 2018-05-30

Similar Documents

Publication Publication Date Title
JP6445621B2 (ja) 分散型ロードバランサ
JP6526848B2 (ja) 分散型ロード・バランサでの多重パス経路指定
JP6030807B2 (ja) 分散型ロードバランサでの接続公開
JP6169251B2 (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: 20180406

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180424

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180724

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: 20181113

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181129

R150 Certificate of patent or registration of utility model

Ref document number: 6445621

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