ネットワーク環境内の分散型ロードバランシングのための方法及びシステムの様々な実施形態を説明する。様々なネットワーク環境内の分散型ロードバランサの実施形態に従って実装することができる分散型ロードバランシングの方法及びシステムの実施形態を説明する。例えば、分散型ロードバランサの実施形態は、パケットフロー、例えば伝送制御プロトコル(TCP)技術パケットフローを、インターネットのような外部ネットワーク上のクライアントと図33A及び33Bに例示されるプロバイダネットワーク1900のようなローカルネットワーク上の送信先、典型的にはサーバ(例えば、ウェブサーバ、アプリケーションサーバ、データーサーバなど)との間に、促進し、維持するように使用することができる。実施形態は、主にTCPパケットフローを処理することに関連して本明細書で説明されるが、実施形態は、TCP以外の他のデータ通信プロトコルに、及びパケットフローを処理すること以外の他のアプリケーションに、適用できることに留意されたい。
分散型ロードバランサは、TCPパケットフローを、特定のクライアントと選択されたサーバ(例えば、ウェブサーバ)との間に、促進し、維持するように動作することができる。しかしながら、分散型ロードバランサは、従来のロードバランサで行われるように、クライアントからのTCPフローを終了せず、かつサーバに対してプロキシとして動作しない。その代りに、分散型ロードバランサのロードバランサノードは、クライアントから受け取ったTCPパケットを対象となるサーバにルーティングし、そのサーバは、それらのTCPスタックを使用してクライアントへのTCP接続を管理する。言い換えれば、サーバは、クライアントからのTCPパケットフローを終了する。
さらに、ロードバランサノード(複数可)が、従来のロードバランサ技術で行われるようにサーバから収集された情報に適用されるロードバランシング技術またはアルゴリズムに基づいて、どのサーバが接続要求にサービスするかについて決定する代わりに、ロードバランサノードは、新規の接続要求を受け取るサーバを無作為に選択することができ、サーバノードに存在する分散型ロードバランサの構成要素は、選択されたサーバが、それぞれのサーバの現在の状態の1つ以上のメトリックに基づいて、新規の接続要求を受け入れるかまたは拒否するかについて、ローカルで決定する。したがって、どのサーバが接続要求を受け入れるべきかについての決定は、ロードバランサノード(複数可)から接続を取り扱うサーバノードに移行される。言い換えれば、決定は、接続要求がサービスされる場所及び時間へより近接するように移行される。
クライアント及びサーバの間にパケットフローを促進し、維持するために、分散型ロードバランサの実施形態は、限定されるものではないが、マルチパスルーティング技術、コンシステントハッシング技術、分散型ハッシュテーブル(DHT)技術、ボーダーゲートウェイプロトコル(BGP)技術、メンバーシップ追跡、ヘルスチェック、接続公開、並びにパケットカプセル化及びデカプセル化を含む様々な技術または技術(複数)を用いることができる。分散型ロードバランシングシステムのこれらの、及び同様な他の態様は、図に関連して以下で説明される。
分散型ロードバランシングシステム
図1は、少なくともいくつかの実施形態に従う、例となる分散型ロードバランシングシステムのブロック図である。分散型ロードバランサの実施形態は、ネットワーク100、例えば図33A及び33Bに例示されるサービスプロバイダのプロバイダネットワーク1900に、実装することができる。分散型ロードバランサシステムのクライアントパケットの取り扱いの高レベルの概要として、ネットワーク100の1つ以上のクライアント160は、例えばインターネットのような外部ネットワーク150を介して、ネットワーク100のボーダールータ102に接続することができる。ボーダールータ102は、分散型ロードバランサシステムのロードバランサノード層のロードバランサ(LB)ノード110に着信パケットをルーティングする分散型ロードバランサのエッジルータ104の構成要素へクライアント160から着信パケット(例えば、TCPパケット)をルーティングすることができる。少なくともいくつかの実施形態では、エッジルータ104は、フロー毎ハッシュ化マルチパスルーティング技術、例えば、等価コストマルチパス(ECMP)ハッシング技術に従って、ルーティング決定を行うことができる。ロードバランサノード110は、今度は、パケットをカプセル化し(例えば、ユーザーデータグラムプロトコル(UDP)に従って)、カプセル化パケットを、ネットワーク100のネットワークファブリック120(例えば、L3ネットワーク)を介して、サーバノード130のローカルのロードバランサモジュール132にルーティングする。ファブリック120は、限定するものではないが、スイッチ、ルータ、及びケーブルを含む1つ以上のネットワーキングデバイスまたは構成要素を含むことができる。サーバノード130では、ローカルのロードバランサモジュール132が、パケットをデカプセル化し、クライアントTCPパケットをサーバ134のTCPスタックに送る。サーバノード130のサーバ134は、次にそれらのTCPスタックを使用し、クライアント160への接続を管理する。
図2は、少なくともいくつかの実施形態に従う、図1の分散型ロードバランサシステムによって実装することができるロードバランシング方法の高レベルのフローチャートである。分散型ロードバランサシステムの実施形態は、ロードを複数の送信先(例えば、ウェブサーバ)に割り当てる困難な問題を、従来のロードバランサで行われるように解決しないことが可能である。例えば、従来のロードバランサは、典型的には、最大接続、ラウンドロビン、及び/または最少接続技術のような技術またはアルゴリズムを使用し、どのサーバが接続を取り扱うべきかを選択する。しかしながら、これらの技術は、欠点を有し、具体的には、ロードバランシングの決定を行うために使用されるデータが多くの場合ほとんど直ぐに古くなっている分散型システムでは、首尾よく行うことが困難である。分散型ロードバランサシステムの少なくともいくつかの実施形態では、従来のロードバランサで行われるような1つ以上のロードバランシング技術を使用して接続要求を満たすようにサーバノード130を選択することを試みる代わりに、ロードバランサノード層のロードバランサノード110は、クライアント接続の要求を受け取るサーバノード130を無作為に決定することができる。そのサーバノード130がそれ自体をオーバーロード状態と見なす場合、サーバノード130は、接続要求をロードバランサノード110に送り返すことができ、したがって、サーバノード130が接続を現在取り扱うことができないことをロードバランサノード110に通知することができる。ロードバランサノード層は、次に、接続要求を受け取る別のサーバノード130を無作為に決定することができ、またはあるいは、エラーメッセージを要求元のクライアント160に返し、クライアント160に接続を現在確立できないことを通知することができる。
図2の10で示されるように、分散型ロードバランサシステムのロードバランサノード層は、通信セッション(例えば、TCP接続)の要求を送信元から受け取る。送信元は、例えば、分散型ロードバランサシステムを実装するネットワーク100への外部ネットワーク150上のクライアント160であることができる。少なくともいくつかの実施形態では、要求は、ネットワーク100のボーダールータ102でクライアント160から受け取られ、かつ着信パケットを例えばフロー毎等価コストマルチパス(ECMP)ハッシング技術を使用してロードバランサノード層のロードバランサ(LB)ノード110にルーティングするエッジルータ104にルーティングされ、クライアント160からの特定の接続要求がルーティングされるロードバランサノード110を疑似無作為に選択することができる。
20に示されるように、ロードバランサノード層は、送信先ノードを無作為に選択し、接続要求を選択された送信先ノードに転送する。送信先ノードは、例えば、ロードバランサが前部に配置された複数のサーバノード130のうちの1つであることができる。少なくともいくつかの実施形態では、ロードバランサ層のロードバランサノード110は、接続要求を受け取るサーバノード130を全て既知のサーバノード130のうちから無作為に選択することができる。しかしながら、全て既知のサーバノード130のうちから純粋に無作為に選択する以外の他の方法は、いくつかの実施形態では、接続要求を受け取るサーバノード130を選択するために使用することができる。例えば、いくつかの実施形態では、サーバノード130に関する情報は、サーバノード130の無作為の選択を重み付けするために、ロードバランサノード110によって使用することができる。実施例として、異なるサーバノード130が、異なるタイプのデバイスであり、または異なるCPUで構成されて異なる能力または容量を有している、ことをロードバランサノード110が知っている場合、情報は、無作為の選択をサーバノード130の特定のタイプ(複数可)または構成(複数可)に向かう方向に(または、そこから離れる方向に)バイアスするために使用することができる。
30に示されるように、送信先ノードは、それが通信セッションを受け入れることができるかどうかを決定する。少なくともいくつかの実施形態では、サーバノード130のローカルのロードバランサ(LB)モジュール132は、サーバノード130のそれぞれのサーバ134が、それぞれのサーバ134の現在の状態の1つ以上のメトリックに基づいて、新規の接続を受け入れることができるかを決定する。
40で、接続要求が受け入られると、次に50に示されるように、送信先ノードは、送信先ノードが接続を取り扱うことができることをロードバランサノード層に通知する。60に示されるように、通信セッションは、次に、ロードバランサノード層を介して送信元(例えば、クライアント160)と送信先ノード(例えば、サーバノード130のサーバ134)との間に確立される。少なくともいくつかの実施形態では、サーバノード130のサーバ134は、TCPスタックを使用し、クライアント160への接続を管理する。
40で、接続要求が受け入られない場合、次に70に示されるように、送信先ノードはロードバランサノード層に通知し、方法は要素20に戻ることができる。ロードバランサノード層は、次に、20で別の送信先ノードを無作為に選択することができ、またはあるいは、要求元のクライアント160に接続を現在確立できないことを通知することができる。クライアント160は、必ずしもではないが、接続要求を再提出し、要素10で方法を再び開始することができることに留意されたい。
図1を再び参照すると、分散型ロードバランサシステムの少なくともいくつかの実施形態は、コモディティハードウェアを使用し、ネットワーク100上のエッジルータ104で受け取ったクライアントトラフィックを、ネットワーク100上のサーバノード130にルーティングすることができる。分散型ロードバランサの少なくともいくつかの実施形態は、複数のロードバランサノード110を含むロードバランサノード層を含むことができる。少なくともいくつかの実施形態では、各々のロードバランサノード110は、ロードバランサノード層の複数の役割のうちの1つ以上で機能することができる。ロードバランサノード110のこれらの役割は、入口ノード、及び出口ノード、及びフロートラッカーノード(所与のパケットフローのための1次フロートラッカーまたは2次フロートラッカーとして)の役割を含むことができる。少なくともいくつかの実施形態では、各々のロードバランサノード110は、コモディティラックマウント型コンピューティングデバイスのような別個のコンピューティングデバイスとしてまたはその上のロードバランサノード層に実装することができる。少なくともいくつかの実施形態では、各々のロードバランサノード110は、入口ノード、出口ノード、及びフロートラッカーノード(パケットフローのための1次または2次フロートラッカーとして)の3つの役割の各々で機能することができ、特定のパケットフローに対して、ロードバランサノード110は、概して、役割のうちの1つのみ(場合によっては2つまたは3つ)で機能することができる。しかしながら、少なくともいくつかの実施形態では、ロードバランサノード110は、特定のパケットフローに対して、1次フロートラッカー及び2次フロートラッカーの両方として機能することができない。あるいは、いくつかの実施形態では、各々のロードバランサノード110は、3つの役割のうちの1つのみで機能することができる。この実施形態では、コンピューティングデバイスの別個のセットは、具体的には入口ノード、出口ノード、及びフロートラッカーノードとしてロードバランサノード層に実装することができる。
少なくともいくつかの実施形態では、コンシステントハッシング及びコンシステントハッシュリング技術を適用し、パケットフローのための1次及び2次フロートラッカーを決定することができる。クライアントからの各々パケットフローは、例えば、クライアントIPアドレス、クライアントポート、サーバ(パブリック)IPアドレス、及びサーバポートからなる4タプルによって一意的に識別することができる。この識別子は、クライアント及びパブリックエンドポイントのペアを示すCPまたはCcPpとして略記することある。任意の所与のTCPフロー(またはCPペア)に関連付けられたパケットは、エッジルータ104からのハッシュ化マルチパス(例えば、ECMP)フロー分散により、入口サーバ112として動作する任意のロードバランサノード110上に現れることができる。コンシステントハッシングを使用することにより、パケットが入口ノードとして機能するロードバランサノード110に到着すると、入口ノードは、どのロードバランサノード110がパケットフローの状態を維持することを担当するかを決定することができる(すなわち、1次フロートラッカーノード)。CPペアは、どのロードバランサノード110がパケットフローの状態情報を維持することを担当するかを決定するために、入口ノードによってコンシステントハッシュリングにハッシュ化することができる。コンシステントハッシュリング内のパケットフローのCPペアのコンシステントハッシュに従って決定されるノード110は、パケットフローのための1次フロートラッカーとして機能するノード110である。少なくともいくつかの実施形態では、コンシステントハッシュリング内の後継ノードは、パケットフローのための2次フロートラッカーとして機能する。
図3は、少なくともいくつかの実施形態に従って、全ての3つの役割(入口、出口、及びフロートラッカー)を実装する構成要素を含む例となるロードバランサ(LB)ノード110を示す。この実施例では、入口サーバ112の構成要素は、クライアント(複数可)からのインバウンドTCPパケットを受け取ること、及びTCPパケットをカプセル化パケットとしてサーバ(複数可)に送ることからなる入口役割を行う。出口サーバ114の構成要素は、サーバ(複数可)からアウトバウンドカプセル化パケットを受け取ること、及びデカプセル化TCPパケットをクライアント(複数可)に送ることとからなる出口役割を行う。フロートラッカー116の構成要素は、クライアント(複数可)160とサーバ(複数可)134との間に確立された1つ以上のパケットフローのための1次または2次フロートラッカーとして働く。入口サーバ112はまた、ロードバランサノード110のフロートラッカー116と、または別のロードバランサノード110のフロートラッカー116と、通信し、それぞれのクライアント160から受け取る接続要求に応じてクライアントとサーバ134のうちの1つとの間のTCP接続を開始し、またはパケットフローのマッピング情報を取得することができる。
ロードバランサノード
図1を再び参照すると、少なくともいくつかの実施形態では、ロードバランサノード層のロードバランサノード110は、クライアントトラフィック(パケット、例えば、TCPパケット)をネットワーク上の1つ以上のルータ104から受け取り、ファブリック120の分散型ロードバランサシステムによって使用されるプロトコル(例えば、ユーザーデータグラムプロトコル(UDP))に従ってパケットをカプセル化する。ロードバランサノード層は、次にカプセル化パケットを、ファブリック120を介して送信先サーバノード130に転送する。各々のサーバノード130は、ロードバランサシステムの構成要素であるローカルのモジュール132を含む。モジュール132は、本明細書ではロードバランサモジュールまたは単にLBモジュールと呼ぶことができ、サーバノード130にソフトウェア、ハードウェア、またはそれらの組み合わせで実装することができる。各々のサーバノード130では、それぞれのロードバランサモジュール132は、パケットをデカプセル化し、TCPパケットを通常のTCP処理のためにローカルのTCPスタックに送る。少なくともいくつかの実施形態では、ロードバランサノード層は、あらゆるクライアントサーバTCPフローの状態情報を維持することができるが、ロードバランサノード層のロードバランサノード110は、TCPフローについて何も解釈しなくてもよい。各々のフローは、それぞれのサーバノード130のサーバ134とクライアント160との間で管理される。分散型ロードバランサシステムは、TCPパケットが正しい送信先サーバ134に到着することを保証する。各々のサーバノード130のロードバランサモジュール132は、それぞれのサーバ134がロードバランサノード110から受け取るクライアント接続要求に応じて、新規の接続を受け入れるかまたは拒否するかについて決定する。
少なくともいくつかの実施形態では、分散型ロードバランシングシステムは、コンシステントハッシング技術を使用し、例えば、どのサーバノード130が特定のTCPパケットフローを担当しているかをどのロードバランサノード(複数可)110が覚えるべきかを決定することができる。コンシステントハッシング技術を使用し、ロードバランサノード層のロードバランサノード110は、コンシステントハッシュリングと見なすことができ、ロードバランサノード110は、リング内のメンバーシップを追跡し、コンシステントハッシング機能に従って特定のパケットフローを担当するリング内の特定のメンバーを決定することができる。少なくともいくつかの実施形態では、クライアント160とサーバ134との間の各々のパケットフローを追跡することを担当する2つのロードバランサノード110が存在し、これらのノード110は、1次フロートラッカー(PFT)ノード及び2次フロートラッカー(SFT)ノードと呼ぶことができる。少なくともいくつかの実施形態では、1次フロートラッカーは、フローのためのコンシステントハッシュリング上の第1のロードバランサノード110であり、2次フロートラッカーは、1次フロートラッカーノードとは異なるコンシステントハッシュリング上の次のまたは後続のロードバランサノード110である。この配設では、1次フロートラッカーノードに障害が発生する場合、次に2次フロートラッカーノードが新規の1次フロートラッカーになることができ、別のロードバランサノード110(例えば、コンシステントハッシュリング上の次のノード110)が2次フロートラッカーの役割を担うことができる。少なくともいくつかの実施形態では、ロードバランサノード110は、所与のパケットフローに対して1次フロートラッカー及び2次フロートラッカーの両方として機能することができないことに留意されたい。コンシステントハッシュリング内のこの及び他のメンバーシップの変更は、この明細書の後半で説明する。少なくともいくつかの実施形態では、ロードバランサ実現形態に関する構成情報(例えば、現在実現形態にあるロードバランサノード110及びサーバノード130の信頼できるリスト(複数可))は、分散型ロードバランシングシステムの構成サービス122の構成要素によって維持することができ、それは、例えばファブリック120を介してロードバランサノード110に結合された1つ以上のサーバデバイスに実装することができる。
少なくともいくつかの実施形態では、1次及び2次フロートラッカーノードとして機能することに加えて、ロードバランサノード110はまた、所与のフローに対して2つの他の役割、入口ノードの役割及び出口ノードの役割、のうちの1つで行うことができる。パケットフローのための入口ノードは、エッジルータ104からそれぞれのパケットフローを受け取り、パケットフローを(カプセル化パケットとして)ファブリック120を介してサーバノード130の選択されたサーバ134に転送するロードバランサノード110である。入口ノードは、実際のクライアントデータ(TCPデータパケット)をそれぞれの送信先サーバノード130に移動する唯一のロードバランサノード110である。入口ノードは、送信先サーバノード130のそれぞれのロードバランサモジュール132へのTCPフローのマッピングを維持し、その結果、入口ノードは、どのロードバランサモジュール132にクライアントトラフィックを転送するかを認知する。出口ノードは、ファブリック120を介してサーバノード130から受け取ったパケットフローに対する応答トラフィックを、ボーダーネットワークを介してそれぞれのクライアント160に転送することを担当するロードバランサノード110である。ロードバランサモジュール132は、ロードバランサプロトコル(例えば、UDP)に従ってサーバ134から取得した応答パケットをカプセル化し、カプセル化応答パケットを、ファブリック120を介してフローのためのそれぞれの出口ノードに送る。出口ノードは、ステートレスであり、単にパケットをデカプセル化し、応答パケット(例えば、TCPパケット)を、外部ネットワーク150を介してそれぞれのクライアント160に配信するためにボーダールータ102へのボーダーネットワークに送る。
前述のように、少なくともいくつかの実施形態では、各々ロードバランサノード110は、異なるパケットフローに対して、入口ノード、出口ノード、及び/またはフロートラッカーノード(1次または2次フロートラッカーのいずれかとして)の役割を行うことができる。ロードバランサノード層の単一のロードバランサノード110は、ノードがどんなパケットフローを処理しているかに依存して役割のいずれか1つで働くことができる。例えば、少なくともいくつかの実施形態では、ロードバランサノード110は、1つのパケットフローのための入口ノードとして、別のパケットフローのための1次または2次フロートラッカーとして、及び更に別のパケットフローのための出口ノードとして働くことができる。更に、少なくともいくつかの実施形態では、ロードバランサノード110は、同じパケットフローに対して複数の役割、例えば所与のパケットフローのための入口ノードとしてかつ1次(または2次)フロートラッカーノードとして、を行うことができる。しかしながら、少なくともいくつかの実施形態では、冗長性及びリカバリの目的のために、ロードバランサノード110は、同じパケットフローのための1次及び2次フロートラッカーノードの両方として機能することができない。
上記は、各々のロードバランサノード110が、入口サーバ、出口サーバ、及びフロートラッカーの3つの役割のいずれかで機能することができる実施形態を説明する。しかしながら、いくつかの実施形態では、コンピューティングデバイスの異なるグループは、ロードバランシングシステムの異なる役割に割り付けることができる。例えば、いくつかの実施形態では、別個のコンピューティングデバイスに各々が実装された入口ノード、出口ノード、及びフロートラッカーノードの異なるセットが存在してもよい。別の実施例として、いくつかの実施形態では、コンピューティングデバイスの1つのセットが入口ノード及びフロートラッカーノードの両方として機能することができ、一方コンピューティングデバイスの別のセットは出口ノードとしてのみ機能することができる。
ロードバランサモジュール
前述のように、各々のサーバノード130は、ロードバランサシステムの構成要素であるローカルのロードバランサモジュール132を含む。モジュール132は、サーバノード130に、ソフトウェア、ハードウェア、またはそれらの組み合わせで実装することができる。少なくともいくつかの実施形態では、サーバノード130のロードバランサモジュール132は、3つの主要な役割、発信パケットのカプセル化及び着信パケットのデカプセル化、ノード130のサーバ134についてのローカルのロードバランシングの決定、並びに接続公開、を行うことができる。これらの3つの役割は以下で簡単に説明し、この明細書の後半でより詳細に説明する。
分散型ロードバランシングシステムの少なくともいくつかの実施形態は、TCP接続を終了することなく、またパケットをなりすますことなく、ロードバランサノード層を介して送られる全てのパケットの送信元及び送信先IPアドレスは、パケットフロー内に含まれるエンドポイント(すなわち、クライアント160及びサーバ134)の実際のIPアドレスである。なりすましの代わりに、これらの実施形態は、ロードバランサノード110とファブリック120のサーバノード130との間に送られる全てのパケットを、例えばUDPパケットとしてカプセル化する。フローのための入口ノードとして働くロードバランサノード110からサーバノード130に到着するパケットフロー内のインバウンドパケットは、ロードバランサノード110によってカプセル化されるので、パケットは、デカプセル化され、かつノード130のサーバ134のためのローカルホストTCPフローにリダイレクトされる必要がある。ノード130のロードバランサモジュール132は、このデカプセル化を行う。同様に、サーバ134からのパケットフローのための発信パケットは、ロードバランサモジュール132によってカプセル化され、パケットフローのための出口ノードとして働くロードバランサノード110にファブリック120を介して送られる。
少なくともいくつかの実施形態では、サーバノード130のロードバランサモジュール132はまた、それぞれのサーバノード130のサーバ134に対するロードバランシングに関連するローカルの決定を行う。具体的には、ノード130のロードバランサモジュール132は、それぞれのサーバ134が、新規のTCP接続の要求の受け取りに応じて、別のTCPフローを受け入れるかどうかを決定する。前述のように、ロードバランサノード110は、ロードバランサモジュール132に送られた全てのパケットをカプセル化し、その結果、ロードバランサモジュール132は、TCP同期(SYN)パケットをクライアント160から実際に受け取ることなく、その代わりに、ロードバランサモジュール132は、ロードバランサモジュール132が受け入れるか拒否することができるフロートラッカー116からのカプセル化プロトコル(例えば、UDP)に従う接続要求メッセージを受け取る。ロードバランサモジュール132が接続要求メッセージを受け入れる場合、ロードバランサモジュール132は、ローカルホストに宛てられたSYNパケットを作成する。ローカルホストが接続を受け入れると、これは、それぞれのクライアント接続を取り扱う実際のTCPスタックになる。
少なくともいくつかの実施形態では、接続要求メッセージを受け入れるべきかどうかについての決定を行うために、ロードバランサモジュール132は、サーバノード130の現在のリソース消費量に関する1つ以上のメトリックを調べ、新規の接続を取り扱うために利用可能である十分なリソースがある場合、ロードバランサモジュール132は、接続を受け入れる。少なくともいくつかの実施形態では、ロードバランサモジュール132によって検討することができるリソースメトリックは、限定されるものではないが、CPU使用率、最近の帯域幅使用量、及び確立された接続の数のうちの1つ以上を含むことができる。いくつかの実施形態では、それらのメトリックの代わりに、またはそれらに加えて、他のメトリックを検討することができる。例えば、いくつかの実施形態では、ロードバランサモジュールは、サーバのレイテンシ(すなわち、要求がサーバ接続バックログで費やされる時間量)をメトリックとして検討することができ、サーバのレイテンシが閾値を超える場合、接続要求を拒否することができる。これらの及び/または他のメトリックを使用し、ロードバランサモジュール132は、それぞれのサーバ134について、サーバ134が新規のパケットフローを受け入れるか拒否するかを決定することができる。少なくともいくつかの実施形態では、リソース利用率(例えば、Nパーセント利用)は、個別にまたは組み合わせてメトリック(複数可)から決定され、閾値(例えば、90%利用)と比較することができる。決定されたリソース利用率が閾値以上である場合、または接続を追加することによってその率が閾値を超える場合は、接続要求を拒否することができる。
少なくともいくつかの実施形態では、ロードバランサモジュール132は、接続要求メッセージを拒否すべきかを決定するための確率的方法を実装することができる。上述のようにリソース利用率が閾値以上の場合に全ての接続要求を拒否する代わりに、この方法では、利用率の2つ以上の異なるレベルにおいて、異なる確率で、接続要求を拒否することができる。例えば、リソース利用率が80%の場合、ロードバランサモジュール132は、20%の確率で接続要求を拒否することができ、リソース利用率が90%の場合、ロードバランサモジュール132は、25%の確率で接続要求を拒否することができ、リソース利用率が95%の場合、ロードバランサモジュール132は、50%の確率で接続要求を拒否することができ、98%以上では、ロードバランサモジュール132は、全ての接続要求を拒否することができる。
少なくともいくつかの実施形態では、各々の接続要求メッセージは、接続要求メッセージがロードバランサモジュール132によって何回拒否されたかの指示を含むことができる。ロードバランサモジュール130によって受け取られた接続要求メッセージが、それが閾値回数を超えて拒否されたことを示す場合、サーバノード130の性能メトリックが接続要求を拒否すべきであることを指示していても、ロードバランサモジュール130は、接続を受け入れることができる。
いくつかの場合では、接続要求メッセージが送られたロードバランサモジュール132の全てが接続要求を拒否することが可能である。少なくともいくつかの実施形態では、接続要求メッセージがロードバランサモジュール132からロードバランサモジュール132に無期限にわたって跳ね返されることを防ぐために、各々の接続要求メッセージには有効時間を与えることができる。この有効時間が過ぎると、フロートラッカーノードは、要求を終了し、要求を現在サービスできないことをそれぞれのクライアント160に通知することができる。
少なくともいくつかの実施形態では、サーバノード130のロードバランサモジュール132はまた、ロードバランサノード110への接続公開を行う。少なくともいくつかの実施形態では、接続公開を行うために、周期的にまたは非周期的に(例えば、1秒に1回)各々のロードバランサモジュール132は、サーバノード130のルーティングテーブル(例えば、ネットスタット(netstat)ルーティングテーブル)を調べ、アクティブな接続(TCPフロー)のリストを公開し、ロードバランサノード110に返す。所与のパケットフローの存在について通知される必要があるロードバランサノード110は、それぞれのパケットフローのための入口ノードとしてかつ1次及び2次フロートラッカーとして機能しているロードバランサノード110である。いくつかの実施形態では、ロードバランサモジュール132は、コンシステントハッシング技術を使用し、サーバノード130のアクティブなTCPフローについて通知される必要があるロードバランサノード110のリストをフィルター処理することができる。例えば、ロードバランサモジュール132は、どのロードバランサノード110が、コンシステントハッシュリングに従って、所与のパケットフローのための1次及び2次フロートラッカーとして機能しているかを決定することができる。いくつかの実施形態では、ロードバランサモジュール132は、どのロードバランサノード110が最後に各々のパケットフローについてデータパケットをロードバランサモジュール132に送ったかを追跡し、この情報を使用し、入口ノードのみがクライアントデータをロードバランサモジュール132に転送するので、どのロードバランサノード110がパケットフローに対する入口ノードとして機能しているかを決定する。いくつかの実施形態では、ロードバランサモジュール132は、次に、ロードバランサノード110の各々のために、それがパケットフローについて通知される必要があると決定されたというメッセージを定式化し、メッセージをロードバランサノード110に送り、それぞれのサーバノード130が、クライアント(複数可)160への接続(複数可)をまだ維持していることをノード110に通知する。ロードバランサモジュール132によるロードバランサノード110へのこの接続公開は、ロードバランサノード110でリース期間を延長するものとして見なすことができる。ロードバランサノード110が特定のパケットフローを示す接続公開メッセージを期間(例えば、10秒)内に受け取らなかった場合には、ロードバランサノード110は、それぞれのパケットフローを任意で忘れることができる。
ロードバランサノードへのマルチパスルーティング
図4は、少なくともいくつかの実施形態に従う、分散型ロードバランサ内のルーティング及びパケットフローの態様を例示する。少なくともいくつかの実施形態では、各々の入口ノード(入口ノードは、図4では入口サーバ112として示されている)は、例えばボーダーゲートウェイプロトコル(BGP)を介して、1つ以上のパブリックエンドポイント(例えば、IPアドレス及びポート)を分散型ロードバランサのためのエッジルータ104にルーティングするその能力を広告する。少なくともいくつかの実施形態では、各々入口ノードがBGPセッションを介してそれ自体をエッジルータ104に広告するのではなく、図5に示されるように、1つ以上の他の入口ノード、例えば2つの近傍のノードが、BGPセッションをエッジルータ104と確立し、入口ノードを広告することができる。
従来のロードバランサは、典型的には、単一のパブリックエンドポイントを提供することができるだけである。対照的に、分散型ロードバランサの実施形態は、複数のロードバランサノード110が単一のパブリックエンドポイントをサービスすることを可能にする。ルータ能力に依存して、これは、全ての入口サーバ112にルーティングされる単一のパブリックIPアドレスがエッジルータ(複数可)104を介して帯域幅全体(例えば、160Gbps)を取り扱うことができる構成を可能にする。少なくともいくつかの実施形態では、これを達成するために、エッジルータ(複数可)104は、層4のフロー毎ハッシュ化マルチパスルーティング技術、例えば等価コストマルチパス(ECMP)ルーティング技術を利用し、トラフィックを各々が同じパブリックIPアドレスを広告する複数の入口サーバ112にわたって分散することができる。層4のフローための送信元及び送信先ポートをエッジルータ(複数可)104のフローハッシュの一部として使用して着信パケットを入口サーバ112の全てに分散することは、概して、入口サーバ112として機能する同じロードバランサノード110にルーティングされる各々の接続のためのパケットを保持することができ、順番の乱れたパケットを回避することができる。しかしながら、エッジルータ(複数可)104は、いくつかの実施形態では、他の技術を使用してトラフィックを入口サーバ112にわたって分散することができることに留意されたい。
図4はまた、2つ以上の分散型ロードバランサがネットワーク100に実装され得ることを示す。2つ以上の分散型ロードバランサは、複数のサーバ130を前部に備え、かつ各々が異なるパブリックIPアドレスを広告する独立したロードバランサとして各々が動作することができ、またはあるいは、図4に示されるように、2つ以上の分散型ロードバランサは、同じIPアドレスを各々が広告することができ、ハッシング技術(例えば、層4のフロー毎ハッシュ化マルチパスルーティング技術)をボーダールータ(複数可)102で使用してエッジルータ104に送り出されるパケットフローを分割することができ、それは、今度は、パケットフローをそれらのそれぞれの入口サーバ112に分散する。
図5は、少なくともいくつかの実施形態に従って、ボーダーゲートウェイプロトコル(BGP)を使用して入口ノードをエッジルータに広告することを例示する。この実施例では、ロードバランサ実現形態で入口ノード110A〜110Dとして機能する4つのロードバランサノードが存在する。エッジルータ104は、着信パケットをクライアント(図示せず)からロードバランサノード110にルーティングする。少なくともいくつかの実施形態では、エッジルータ104は、層4のフロー毎ハッシュ化マルチパスルーティング技術、例えば等価コストマルチパス(ECMP)ルーティング技術に従って、ルーティング決定を行うことができる。
少なくともいくつかの実施形態では、エッジルータ104は、ロードバランサ実現形態で現在利用可能である入口ノード110について学習し、ボーダーゲートウェイプロトコル(BGP)技術を介して入口ノード110によって開始されるセッションを広告するクライアントトラフィックを受け取る。各々の入口ノード110は、BGPを使用し、それ自体をエッジルータ104に広告することができる。しかしながら、BGPは、典型的には、収束するために比較的長い時間を要する(3秒間以上)。各々の入口ノード110がBGPを介してそれ自体を広告するこの技術を使用し、入口ノード110がダウンした場合、エッジルータ104でのBGPセッションがタイムアウトするのに、したがってエッジルータ104が障害クローズダウンについて学習し、かつ現在のTCPフローを入口ノード110に再ルーティングするのに、ネットワーキング期間中にかなりの時間(3秒間以上)を要する場合がある。
少なくともいくつかの実施形態では、BGPで収束問題を回避するために、かつノード110の障害の時により迅速にリカバリするために、入口ノード110がBGPセッションを介してそれ自体をエッジルータ104に広告する代わりに、ロードバランサ実現形態の少なくとも1つの他の入口ノード110が、BGPを介して入口ノード110をエッジルータ104に広告することを担当する。例えば、図5に示されるようないくつかの実施形態では、所与の入口ノード110の左及び右の近傍の入口ノード110、例えば、ノード110の順序付けリスト、例えばノード110によって形成されるコンシステントハッシュリング内の左及び右の近傍のものは、所与の入口ノード110をエッジルータ104に広告することができる。例えば、図5では、入口ノード110Aは、入口ノード110B及び110Dを広告し、入口ノード110Bは、入口ノード110A及び110Cを広告し、入口ノード110Cは、入口ノード110B及び110Dを広告し、入口ノード110Dは、入口ノード110C及び110Aを広告する。入口ノード110は、本明細書で後述されるように互いのヘルスをチェックし、広める。記載のヘルスチェック方法を使用し、不健全であるノードを検出することができ、情報は、1秒未満で、例えば100ミリ秒(ms)で、ノード110にわたって伝搬することができる。入口ノード110が健全でないことが決定されると、不健全なノードを広告する入口ノード110は、不健全なノード110を広告することを即座に停止することができる。少なくともいくつかの実施形態では、入口ノード110は、TCPクローズまたはBGPセッションについての同様のメッセージをエッジルータ104に送ることにより、エッジルータ104とのBGPセッションを終了する。したがって、ノード110の障害を検出するために障害が発生したノード110によって確立されるBGPセッションがタイムアウトするのを待機することではなく、ノード110が不健全であることが検出されると、障害が発生したノード110に代わって広告する他の入口ノード110が、ノード110を広告するエッジルータ104とのBGPセッションを終了するときに、エッジルータ104は障害が発生したノード110を発見することができる。ロードバランサノードの障害の取り扱いは、本明細書の後半で図18A及び18Bに関連して更に説明される。
図6は、分散型ロードバランシングシステムの少なくともいくつかの実施形態に従う、マルチパスルーティング方法のフローチャートである。900に示されるように、ロードバランサ実現形態の入口ノード110は、それらの近傍のノード110をエッジルータ104に広告する。少なくともいくつかの実施形態では、入口ノード110は、コンシステントハッシュリングのようなノード110の順序付けリストに従って、それらの近傍のノード110を決定することができる。少なくともいくつかの実施形態では、入口ノード110は、各々の広告されるノード110について1つのBGPセッションがエッジルータ104に確立されるBGPセッションを使用し、それらの近傍のノード(複数可)110をエッジルータ104に広告する。
902で示されるように、エッジルータ104は、フロー毎ハッシュ化マルチパスルーティング技術、例えば等価コストマルチパス(ECMP)ルーティング技術に従って、クライアント160から受け取るトラフィックを、アクティブな(広告される)入口ノード110に分散する。少なくともいくつかの実施形態では、エッジルータ104は、パブリックIPアドレスをクライアント160に公開し、入口ノード110は全て、同じパブリックIPアドレスをエッジルータ104に広告する。エッジルータは、層4の送信元及び送信先ポートをエッジルータ104のフローハッシュの一部として使用し、着信パケットを入口ノード110にわたって分散する。これは、概して、同じ入口ノード110にルーティングされる各々接続のためのパケットを保持する。
902に示されるように、入口ノードは、データフローを対象となるサーバノード130に転送する。少なくともいくつかの実施形態では、入口ノード110は、データフローのための1次及び2次フロートラッカーノードと相互作用し、データフローを対象となるサーバノード130にマッピングする。各々入口ノード110は、受け取ったパケットを対象となるサーバノード130に適切に転送するために使用することができるノード110を介するアクティブなデータフローのマッピングを維持することができる。
要素906〜910は、入口ノード110の障害の検出及びそこからのリカバリに関する。906に示されるように、入口ノード110は、例えば本明細書に記載のヘルスチェック技術に従って、入口ノード110がダウンしていることを検出することができる。ノード110がダウンしていることが検出されると、その近傍のノード110は、ノード110をエッジルータ104に広告することを停止する。少なくともいくつかの実施形態では、これは、それぞれのBGPセッションについてTCPクローズをエッジルータ104に送ることを含む。
908で示されるように、エッジルータ104は、入口ノード110がダウンしていることがBGPセッションのクローズを介して検出されると、フロー毎ハッシュ化マルチパスルーティング技術に従って、クライアント160からの着信トラフィックをその他の入口ノード110に再分配する。したがって、少なくともいくつかのデータフローは、異なる入口ノード110にルーティングすることができる。
910に示されるように、入口ノード110は、必要に応じてマッピングをリカバリし、データフローを適切な対象となるサーバノードに転送することができる。入口ノード110のノード110の障害からリカバリするための方法は、この明細書で別に説明される。一実施例では、入口ノード110は、現在のマッピングを有していないパケットを受け取ると、コンシステントハッシュ関数を使用し、コンシステントハッシュリングに従ってデータフローのためのフロートラッカーノードを決定し、フロートラッカーノードからマッピングをリカバリすることができる。
非対称のパケットフロー
少なくともいくつかの実施形態では、インバウンドデータに対するアウトバウンドトラフィックの比が1よりも大きいとき、入口ノードの帯域幅及びCPU使用率を効率的に利用するために、図7に示されるように分散型ロードバランシングシステムはサーバノード130からのアウトバウンドパケットを複数の出口ノードに転送する。少なくともいくつかの実施形態では、各々の接続について、それぞれのサーバノード130のロードバランサモジュール132は、クライアントエンドポイント/パブリックエンドポイントタプルをハッシュし、コンシステントハッシュアルゴリズムを使用し、それぞれのアウトバウンドパケットフローのための出口サーバ114として機能するロードバランサノード110を選択する。しかしながら、いくつかの実施形態では、他の方法及び/またはデータを使用して接続のための出口サーバ114を選択することができる。選択された出口サーバ114は、典型的には、必ずしもではないが、接続のための入口サーバ112として機能するロードバランサノード110とは異なるロードバランサノード110であってよい。少なくともいくつかの実施形態では、そのロードバランサノード110/出口サーバ114の障害が存在しない限り、特定の接続のためのアウトバウンドパケットの全ては、順番の乱れたパケットを回避するために同じ出口サーバ114に転送される。
少なくともいくつかの実施形態では、サーバノード130によって出口サーバ114を選択するために使用される方法及びデータは、エッジルータ(複数可)104によって行われる入口サーバ112を選択するために使用される方法及びデータとは異なってもよい。異なる方法及びデータを使用することは、概して、接続のための入口ノードとして選択されたロードバランサノード110とは異なるロードバランサノード110が所与の接続のための出口ノードとして選択されることをもたらすことができ、更に入口ノードとして機能する単一のロードバランサノード110を通過する接続のための発信トラフィックを取り扱うための出口ノードとして複数のロードバランサノード110が選択されることをもたらすことができる。
図7は、少なくともいくつかの実施形態に従って、非対称のパケットフローをグラフィカルに例示する。少なくとも1つの接続は、外部ネットワーク150上のクライアント160から入口サーバ112を介してサーバノード130A、130B、130C、及び130Dの各々に確立されている。少なくともいくつかの実施形態では、各々の接続について、接続のための出口ノードを選択するために、それぞれのサーバノード130のロードバランサモジュール132は、クライアントエンドポイント/パブリックエンドポイントタプルをハッシュし、コンシステントハッシュアルゴリズムを使用し、それぞれのアウトバウンドパケットフローのための出口サーバ114として機能するロードバランサノード110を選択する。例えば、サーバノード130Aは、接続のための出口サーバ114Aを選択しており、サーバノード130Bは、1つの接続のための出口サーバ114A及び別の接続のための出口サーバ114Bを選択している。しかしながら、いくつかの実施形態では、他の方法及び/またはデータを使用し、接続のための出口ノードを選択することができる。
クライアント接続をドロップすることがないロードバランサノードの障害からのリカバリ
ロードバランサノード110がコンシステントハッシングを使用してどのサーバノード130がクライアントトラフィックを受け取るべきかを決定することは可能であるが、いくつかの接続の長い存続期間が原因で、この手法は、新規のサーバノード130がコンシステントハッシュメンバーシップに加入し、かつその後の入口ロードバランサノード110の障害が存在する場合には、既存のフローを維持することができないことがある。このシナリオでは、障害が発生したノード110からフローを引き継ぐロードバランサノード110は、サーバ130のためのコンシステントハッシュリングが異なるメンバーシップを有しているので、選択されたオリジナルのマッピングを決定することができないことがある。したがって、少なくともいくつかの実施形態では、分散型ハッシュテーブル(DHT)技術は、接続のためのサーバノード130を選択し、かつ選択されたサーバノード130にパケットをルーティングするために、ロードバランサノード110によって使用され得る。サーバノード130が特定の接続を受け取るためにDHTに従って一旦選択され、かつサーバノード130が健全のままであること、及びサーバノード130のロードバランサモジュール132が、そのアクティブな接続の状態をDHTに(例えば、接続公開を介して)周期的に送信することにより継続してリース期間を延長すること、を前提とすると、DHTは、接続が完了するまでマッピングを保持する。入口ノード110の障害は、エッジルータ104からその他のロードバランサノード110へのパケットの分散に影響を与え、ロードバランサノード110がクライアント接続の異なるセットからトラフィックを受け取ることをもたらす。しかしながら、DHTは全てのアクティブな接続を追跡するので、ロードバランサノード110は、DHTに照会して任意のアクティブなマッピングのためのリース期間を取得することができる。その結果、全てのロードバランサノード110は、トラフィックを正しいサーバノード130に渡し、それにより、入口ロードバランサノード110の障害が発生した場合でもアクティブなクライアント接続の障害を防ぐ。
分散型ロードバランシングシステムにおけるパケットフロー
図8は、少なくともいくつかの実施形態に従う、分散型ロードバランシングシステムにおけるパケットフローを例示する。図8の矢印付きの実線はTCPパケットを表し、一方矢印付きの点線はUDPパケットを表すことに留意されたい。図8では、入口サーバ112は、TCPパケットを1つ以上のクライアント160からエッジルータ104を介して受け取る。TCPパケットを受け取ると、入口サーバ112は、サーバノード130へのTCPパケットフローのマッピングを有しているかを決定する。入口サーバ112がTCPパケットフローのマッピングを有している場合は、サーバ112は、TCPパケットをカプセル化し(例えば、UDPに従って)、カプセル化パケットを対象となるサーバノード130に送る。入口サーバ112がTCPパケットフローのマッピングを有していない場合は、入口サーバ112は、TCPパケットから抽出されたTCPパケットフローに関する情報を含むUDPメッセージを1次フロートラッカー116Aに送って、サーバノード130への接続を確立し、かつ/またはTCPパケットフローのマッピングを取得することができる。図9A及び9B並びに図10A〜10Gは、クライアント160とサーバノード130との間に接続を確立するための方法を例示する。サーバノード130のロードバランサモジュール132は、サーバノード130でTCP接続(複数可)のための出口サーバ(複数可)114として機能するロードバランサノード(複数可)110を無作為に選択し、UDPカプセル化TCP応答パケットを、出口サーバ(複数可)114を介してクライアント(複数可)160に送る。
図9A及び9Bは、少なくともいくつかの実施形態に従う、分散型ロードバランシングシステムで接続を確立するときのパケットフローのフローチャートを提供する。図9Aの200で示されるように、入口サーバ112は、TCPパケットをクライアント160からエッジルータ104を介して受け取る。202で、入口サーバ112がサーバノード130へのTCPフローのマッピングを有している場合は、入口サーバ112は、204で示されるようにTCPパケットをカプセル化してそれぞれのサーバノード130に送る。入口サーバ112は、1つ、2つ、またはそれ以上のクライアント160からの1つ、2つ、またはそれ以上のTCPフローのためのパケットを連続して受け取り、かつ処理することができることに留意されたい。
202で、入口サーバ112がTCPフローのマッピングを有していない場合、パケットは、クライアント160からのTCP同期(SYN)パケットであってもよい。206で示されるように、SYNパケットを受け取ると、入口サーバ112は、SYNパケットからデータを抽出し、データを例えばUDPメッセージで1次フロートラッカー116Aに転送する。少なくともいくつかの実施形態では、入口サーバ112は、コンシステントハッシュ関数に従って、TCPフローのための1次フロートラッカー116A及び/または2次フロートラッカー116Bを決定することができる。208で、1次フロートラッカー116Aは、データを例えばハッシュテーブルに格納し、TCP接続のサーバノード130の側のための初期TCPシーケンス番号を生成し、データ及びTCPシーケンス番号を2次フロートラッカー116Bに転送する。210で、2次フロートラッカー116Bもまた、データを格納し、SYN/ACKパケットを作成してクライアント160に送り、SYN/ACKパケットは少なくともTCPシーケンス番号を含む。
212で、入口サーバ112は、TCP受信確認(ACK)パケットをクライアント160からエッジルータ104から受け取る。入口サーバ112は、この時点で、サーバ130ノードへのTCPフローのマッピングを有していないので、214で、入口サーバ112は、ACKパケットから抽出されたデータを含むメッセージを1次フロートラッカー116Aに送る。216に示されるように、メッセージを受け取ると、1次フロートラッカー116Aは、格納されたデータに従ってTCPフローを確認し、ACKパケットからの確認応答されたシーケンス番号(+1)がSYN/ACKで送られた値に一致することを確認する。1次フロートラッカー116Aは、次に、TCPフローを受け取るサーバノード130を選択し、データ、TCPシーケンス番号、及び選択されたサーバノード130のローカルのロードバランサモジュール132のIPアドレスを含むメッセージを、2次フロートラッカー116Bに送る。218で示されるように、2次フロートラッカー116Bもまた、データ及びTCPシーケンス番号を確認し、SYNメッセージを作成し、作成されたSYNメッセージを選択されたサーバノード130のローカルのロードバランサモジュール132に送る。方法は、図9Bの要素220で継続する。
図9Bの220で示されるように、作成されたSYNメッセージに応じて、ロードバランサモジュール132は、サーバノード130の1つ以上のメトリックを調べ、サーバノード130が接続を受け入れることができるかを決定することができる。222で、サーバノード130が接続を現在受け入れることができないことをロードバランサモジュール132が決定する場合は、224で、ロードバランサモジュール132は、2次フロートラッカー116Bに連絡する。2次フロートラッカー116Bは、それが以前に格納したフローに関する情報を削除することができる。226で、2次フロートラッカー116Bは、1次フロートラッカー116Aに連絡する。1次フロートラッカー116Aは、次に、図9Aの216で示されるように、新規の対象となるサーバノード130を選択し、2次フロートラッカー116Bに連絡する。
222で、サーバノード130が接続を受け入れることができることをロードバランサモジュール132が決定する場合は、図9Bの228で示されるように、ローカルのロードバランサモジュール132は、作成されたSYNからTCP SYNパケットを構築し、TCP SYNパケットをサーバノード130のサーバ134に送る。TCP SYNパケットの送信元IPアドレスは、クライアント160の実際のIPアドレスが取り込まれているので、サーバ134は、クライアント160への直接のTCP接続を受け取ったことを確信する。ロードバランサモジュール132は、TCPフローについての関連する詳細を、例えばローカルのハッシュテーブルに格納する。230で示されるように、サーバ134は、ロードバランサモジュール132が傍受するSYN/ACKパケットで応答する。232で示されるように、ロードバランサモジュール132は、次に、接続情報を含むメッセージを2次フロートラッカー116Bに送り、接続が受け入れられたことを示す。このメッセージを受け取ると、234で、2次フロートラッカー116Bは、サーバ134へのマッピングを記録し、同様のメッセージを1次フロートラッカー116Aに送り、それもまたマッピング情報を記録する。236に示されるように、1次フロートラッカー116Aは、次に、マッピングメッセージを入口サーバ112に転送する。入口サーバ112は、これで、クライアント160からサーバ130へのTCPフローのマッピングを有する。
238で、入口サーバ112は、データフローのための任意のバッファされたデータパケットをカプセル化し、サーバノード130のローカルのロードバランサモジュール132に転送する。入口サーバ112によって受け取られるクライアント160からのデータフローのための追加の着信パケットは、カプセル化されてロードバランサモジュール132に直接に転送され、それはパケットをデカプセル化し、データパケットをサーバ134に送る。
240で、ロードバランサモジュール132は、データフローのための出口サーバ114を無作為に選択する。サーバ134からの後続のアウトバウンドTCPパケットは、ロードバランサモジュール132によって傍受され、UDPに従ってカプセル化され、任意に選択された出口サーバ114に転送される。出口サーバ114は、発信パケットをデカプセル化し、TCPパケットをクライアント160に送る。
上述のように、202で、入口サーバ112が受け取ったパケットのTCPフローのマッピングを有していない場合、パケットはクライアント160からのTCP同期(SYN)パケットであってよい。しかしながら、パケットはTCP SYNパケットでなくてもよい。例えば、ロードバランサノード110のメンバーシップがロードバランサノード110の追加または障害によって変わる場合、エッジルータ104は、入口サーバ112がマッピングを有していない1つ以上のTCPフローのためのパケットを、入口サーバ112にルーティングすることを開始することができる。少なくともいくつかの実施形態では、入口サーバ112がマッピングを有していないそのようなパケットを受け取ると、入口サーバ112は、コンシステントハッシュ関数を使用し、コンシステントハッシュリングに従ってTCPフローのための1次フロートラッカー116A及び/または2次フロートラッカー116Bを決定し、1次フロートラッカー116Aまたは2次フロートラッカー116Bのいずれかに連絡してマッピングを要求することができる。TCPフローのマッピングをフロートラッカー116から受け取ると、入口サーバ112は、マッピングを格納し、かつTCPフローのためのTCPパケット(複数可)をカプセル化して正しい送信先サーバノード130に転送することを開始することができる。
ロードバランサノードの詳細
少なくともいくつかの実施形態では、ロードバランサノード110は、各々3つの役割を有し、
・入口−クライアント接続で全ての着信パケットをクライアント160から受け取り、マッピングが既知の場合、パケットをサーバノード130にルーティングし、マッピングが既知でない場合、フロートラッカーに連絡する。入口ノードからの発信パケットは、入口ノードによってカプセル化される(例えば、UDPに従って)。
・フロー追跡−接続状態の追跡を維持する(例えば、各々のクライアント接続をサービスするために、どのサーバノード130/サーバ134が割り付けられたか)。フロートラッカーもまた、クライアント160及びサーバ134との間に接続を確立することに参加する。
・出口−サーバ134から受け取ったアウトバウンドパケットをデカプセル化し、クライアント160に転送する。
少なくともいくつかの実施形態では、入口の役割において、ロードバランサノード110は、クライアント−>サーバのマッピングが既知のとき、パケットをサーバ134に転送し、またはマッピングが既知でないとき、要求をフロートラッカーに転送することを担当する。少なくともいくつかの実施形態では、特定のクライアント接続/データフローのための入口ノードとして機能するロードバランサノード110はまた、そのクライアント接続のための1次フロートラッカーまたは2次フロートラッカーのいずれかとして、しかし両方ではなく、機能することができる。
少なくともいくつかの実施形態では、フロートラッカーの役割において、ロードバランサノード110は、まだ確立されている接続の状態を維持すること、並びに確立された接続のためのクライアント−>サーバのマッピングを維持することを担当する。2つのフロートラッカーは、各々の個別のクライアント接続に関与し、1次フロートラッカー及び2次フロートラッカーと呼ばれる。少なくともいくつかの実施形態では、クライアント接続に関連するフロートラッカーは、コンシステントハッシュアルゴリズムを使用して決定することができる。フロートラッカーはまた、限定するものではないが、各々の新規のクライアント接続のためのサーバノード130を擬似無作為的に選択することを含むロードバランシング機能を行う。選択されたサーバノード130のローカルのロードバランサモジュール132は、サーバ134が接続を取り扱うことができないことを決定する場合、接続要求を拒否することができることに留意されたい。このことが起こると、次にフロートラッカーは、別のサーバノード130を選択し、接続要求を他のサーバノード130に送ることができる。少なくともいくつかの実施形態では、所定の接続のための1次フロートラッカーの役割及び2次フロートラッカーの役割は、異なるロードバランサノード110によって行われる。
少なくともいくつかの実施形態では、出口の役割において、ロードバランサノード110は、ステートレスであり、サーバノード130から受け取った着信パケットをデカプセル化し、いくつかの検証を行い、アウトバウンドTCPパケットをそれぞれのクライアント160に転送する。少なくともいくつかの実施形態では、サーバノード130のローカルのロードバランサモジュール132は、所与の接続のためのロードバランサノード110を任意で選択することができる。
ロードバランサノードのコンシステントハッシュリングトポロジ
少なくともいくつかの実施形態では、ロードバランサノード110は、入力鍵空間(クライアントエンドポイント、パブリックエンドポイント)のコンシステントハッシングに基づいて、リングトポロジを形成する。入力鍵空間は、利用可能なフロートラッカーノード間で分割することができ、全てのフロートラッカーノードは、その鍵空間に対応するクエリに答えることを担当することができる。少なくともいくつかの実施形態では、データは、コンシステントハッシュリングの後継に基づいて1次及び2次フロートラッカーノードに複製することができる(例えば、2次フロートラッカーノードは、1次フロートラッカーノードに対して、後継ノード、すなわちコンシステントハッシュリングの次のノードである)。フロートラッカーノードが何らかの理由でダウンした場合、コンシステントハッシュリングの次のロードバランサノードは、障害が発生したノードの鍵空間を取得する。新規のフロートラッカーノードが加わると、ノードはそのエンドポイントを記録し(例えば、図1に示されるような構成サービス122で)、その結果、他のロードバランサノードは、ロードバランサ実現形態、したがってコンシステントハッシュリングの構成の変更に関して学習することができる。コンシステントハッシュリングのフロートラッカーの追加及び障害の取り扱いは、図11A〜11Dを参照してより詳細に説明する。
入口ノード<−>フロートラッカーノードの通信
少なくともいくつかの実施形態では、入口ノードとして機能するロードバランサノード110は、構成サービス122からフロートラッカーノードとして機能するロードバランサノード110に関して学習することができる。入口ノードは、ロードバランサ実現形態、したがってコンシステントハッシュリングのメンバーシップの変更に関して構成サービス122を監視することができる。入口ノードがマッピングを有していないパケットを入口ノードがクライアント160から受け取ると、入口ノードは、コンシステントハッシュ関数を使用し、どのフロートラッカーノードがパケットをサービスすべきかを決定することができる。少なくともいくつかの実施形態では、ハッシュ関数への入力は、パケットからの(クライアントエンドポイント、パブリックエンドポイント)ペアである。少なくともいくつかの実施形態では、入口ノード及びフロートラッカーノードは、UDPメッセージを使用して通信する。
1次フロートラッカーノードが、新規のパケットフローのための入口ノードからメッセージを受け取ると、1次フロートラッカーノードは、TCPシーケンス番号を無作為に決定し、別のメッセージを2次フロートラッカーノードに転送する。2次フロートラッカーノードは、クライアントのためのTCP SYN/ACKメッセージを生成する。両方のフロートラッカーは、クライアント接続エンドポイントペア及びTCPシーケンス番号を記憶しており、メモリプレッシャーまたは有効期限によって状態が一掃されるまで、この情報を保持する。
1次フロートラッカーノードが、TCP ACKパケットを受け取ったというメッセージを入口ノードから受け取ると、1次フロートラッカーノードは、確認応答されたTCPシーケンス番号がSYN/ACKパケットで送られた格納された値に一致することを検証し、要求をサービスするサーバノード130を選択し、メッセージを2次フロートラッカーノードに転送する。2次フロートラッカーノードは、メッセージを選択されたサーバノード130のロードバランサモジュール132に送って、サーバノード130のTCPスタックとの実際のTCP接続を開始し、その後、サーバノード130からの受信確認応答を待機する。
2次フロートラッカーノードがサーバノード130のロードバランサモジュール132からの接続受信確認を受け取ると、両方のノードにおいて関連するサーバノード130に関する情報を格納する1次フロートラッカーを介する入口ノードへの逆メッセージフローが始動される。この時点から、入口ノードで受け取られる追加のTCPパケットは、サーバノード130のロードバランサモジュール132に直接に転送される。
ロードバランサモジュール<−>ロードバランサノードの通信
少なくともいくつかの実施形態では、全てのロードバランサモジュール132は、構成サービス122でそのエンドポイントを記録し、ロードバランサノード層のメンバーシップの変更に関して構成サービス122を継続的に監視する。以下では、少なくともいくつかの実施形態に従う、ロードバランサモジュール132の機能を説明する、
・接続公開−接続を担当する1次及び2次フロートラッカーノードの両方への、並びにパケットを接続のためのロードバランサモジュール132に最後に送った入口ノードへの、それぞれのサーバノード130上のアクティブな接続のセット(クライアントエンドポイント、パブリックエンドポイント)を、周期的(例えば、1秒に1回)または非周期的に公開する。接続公開機能は、担当しているロードバランサノード110での接続状態のリース期間を更新する。
・ロードバランサ層のメンバーシップの変更を監視する。メンバーシップが変更されると、ロードバランサモジュール132は、この変更情報を使用して、即座に現在接続を担当しているロードバランサノードへアクティブな接続を送ることが出来る。
分散型ロードバランシングシステム内のパケットフロー−詳細
分散型ロードバランシングシステムは、複数のロードバランサノード110を含むことができる。少なくともいくつかの実施形態では、分散型ロードバランシングシステムの各々のロードバランサノード110は、サーバ134へのクライアント160の接続のためのフロートラッカーノード、出口ノード、及び入口ノードの役割で機能することができる。分散型ロードバランシングシステムはまた、各々のサーバノード130にロードバランサモジュール132を含むことができる。
図10A〜10Gは、少なくともいくつかの実施形態に従う、分散型ロードバランシングシステム内のパケットフローを例示する。図10A〜10Gでは、ロードバランサノード110間で交換されるパケット及びロードバランサノード110とサーバノード130との間で交換されるパケットは、UDPメッセージまたはUDPカプセル化クライアントTCPパケットのいずれかである。少なくともいくつかの実施形態では、クライアントTCPパケットは、ボーダールータ102(図1を参照)への及びそこからの転送中に、ロードバランサノード110のノース側にデカプセル化形態でネットワーク100に存在するだけである。図10A〜10Gの矢印付きの実線はTCPパケットを表し、一方矢印付きの点線はUDPパケットを表すことに留意されたい。
少なくともいくつかの実施形態では、分散型ロードバランシングシステムは、確立された接続を単一のロードバランサノード110の障害発生時に維持するように試みることができる。少なくともいくつかの実施形態では、これは、1次フロートラッカーノード及び2次フロートラッカーノードの接続の詳細を複製し、その結果、これらのノードのいずれかに障害が発生した場合、接続のクライアント−>サーバのマッピングが残りのフロートラッカーノードによって復元することができることによって、達成することができる。少なくともいくつかの実施形態では、ノードの障害が発生すると一部のパケットの損失が発生することがあるが、クライアント/サーバTCPパケット再送信は、失われたパケットをリカバリすることができる。
クライアントからの各々のTCP接続は、TCPフローと呼ぶことができ、クライアントIPアドレス、クライアントポート、サーバ(パブリック)IPアドレス、及びサーバポートからなる4タプルによって一意的に識別される。この識別子は、クライアント及びパブリックエンドポイントのペアを示すCPまたはCcPpと略記することができる。任意の所与のTCPフロー(またはCPペア)に関連付けられたパケットは、上流側のエッジルータ104からのハッシュ化等価コストマルチパス(ECMP)フロー分散によって、入口サーバ112として動作する任意のロードバランサノード110に現れることができる。しかしながら、TCPフローのためのパケットは、概して、TCPフローをリダイレクトする原因となるリンクまたはロードバランサノード110の障害が存在しない限り、同じロードバランサノード110に継続して到着することができる。上流側のルータ104からTCPフローのためのパケットを受け取るロードバランサノード110は、TCPフローのための入口ノードと呼ばれる。
少なくともいくつかの実施形態では、コンシステントハッシングを使用し、それにより、パケットがTCPフローのための入口ノードとして機能するロードバランサノード110に到着すると、入口ノードは、どのロードバランサノード110がTCPフローについての状態を含んでいるか(すなわち、フロートラッカーノード)を決定することができる。CPペアは、どのロードバランサノード110がTCPフローに関連する状態を維持することを担当しているか決定するために、入口ノードによってコンシステントハッシュリングにハッシュ化することができる。このノードは、TCPフローのための1次フロートラッカーとして機能する。コンシステントハッシュリングの後継ノードは、TCPフローのための2次フロートラッカーとして機能する。
少なくともいくつかの実施形態では、全てのロードバランサノード110は、入口ノード、1次フロートラッカーノード、及び2次フロートラッカーノードとして機能することができる。TCPフローのコンシステントハッシュの結果に依存して、TCPフローのための入口ノードとして機能するロードバランサノード110はまた、TCPフローのための1次または2次フロートラッカーノードとして機能することができる。しかしながら、少なくともいくつかの実施形態では、異なる物理的ロードバランサノード110がTCPフローのための1次及び2次フロートラッカーの役割を行う。
接続の確立
図10Aを参照すると、クライアント160からの新規の接続は、クライアントTCP同期(SYN)パケットによって始動することができる。ロードバランサノード110は、SYNパケットを受け取ると、サーバノード130との接続を実際に確立せず、また接続を受け取るためのサーバノード130を即座に選択もしない。その代りに、ロードバランサノード110は、クライアントのSYNパケットから関連のデータを格納し、選択されることになるサーバノード130に代わって、SYN/ACKパケットを生成する。図10Cを参照すると、クライアント160がTCPスリーウェイハンドシェイクにおいて第1のACKパケットで一旦応答すると、ロードバランサノード110は、サーバノード130を選択し、そのサーバノード130のための等価SYNパケットを生成し、サーバノード130との実際のTCP接続を確立することを試みる。
図10Aを再び参照すると、TCPフローのための入口サーバ112として機能するロードバランサノード110でクライアントSYNパケットを受け取ると、入口サーバ112は、SYNパケットからデータフィールドを抽出し、データをTCPフローのための1次フロートラッカー116Aに転送する。1次フロートラッカー116Aは、データを、例えばハッシュテーブルに格納し、初期TCPシーケンス番号(TCP接続のサーバ側のための)を生成し、同じデータを2次フロートラッカー116Bに転送する。2次フロートラッカー116Bは、サーバTCPシーケンス番号を含むクライアント160のためのSYN/ACKパケットを作成する。
図10Aでは、入口サーバ112、1次フロートラッカー116A、及び2次フロートラッカー116Bの役割は、各々異なるロードバランサノード110によって行われる。しかしながら、いくつかの場合では、TCPフローのための入口サーバ112として機能するロードバランサノード110は、TCPフローのための1次フロートラッカー116Aまたは2次フロートラッカー116Bとして機能する同じノード110であってもよい(しかし、両方ではない)。パケットフローのための入口サーバ112がそのフローのためのフロートラッカー116と同じノード110にあってもよいことの理由は、エッジルータ104は、フロー毎ハッシュ化マルチパスルーティング技術(例えば、ECMPルーティング技術)に従って、そのフローのための入口サーバ112を擬似無作為的に選択し、一方そのパケットフローのためのフロートラッカー116は、パケットフローのアドレス情報に適用されるコンシステントハッシュ関数に従って、コンシステントハッシュリング上で決定されるということである。パケットフローのための入口サーバ112が、そのパケットフローのためのフロートラッカー116と同じノード110にある場合、SYNパケットからのデータは、入口サーバ112を実装するノード110から他のフロートラッカー116ノード110に転送されるだけでよい。例えば、図10Bでは、1次フロートラッカー116Aは、TCPフローのための入口サーバ112と同じロードバランサノード110Aにあり、一方2次フロートラッカー116Bは、異なるロードバランサノード110Bにあり、したがってSYNパケットからのデータは、ノード110Aから(フロートラッカー116Aによって)ロードバランサノード110Bの2次フロートラッカー116Bに転送される。
図10Cを参照すると、非SYNパケットが入口サーバ112に到着すると、入口サーバ112は、パケットをどのサーバノード130に転送すべきかを既知であるか、または既知でないかのいずれかである。TCPフローのための入口サーバ112に到着する第1の非SYNパケットは、TCPスリーウェイハンドシェイクにおける第1のTCP受信確認(ACK)パケット(または、おそらく後続のデータパケット)であるべきであり、TCP受信確認番号フィールドは、図10AのSYN/ACKパケットで送られたサーバシーケンス番号(+1)に一致する。入口サーバ112が、サーバマッピングを有していない非SYNパケットを受け取ると、それは、TCPフローのための1次フロートラッカー116Aにメッセージを転送し、メッセージは、シーケンス番号のようなACKパケットからの情報を含み、またはあるいは、ACKパケット自体を含む。少なくともいくつかの場合では、1次フロートラッカー116Aは、TCPフローのための格納されたデータを記憶し、受信確認されたシーケンス番号(+1)がSYN/ACKパケットでクライアント160に送られた値に一致することを確認する。1次フロートラッカーは、次に、TCPフローのためのサーバノード130を選択し、TCPフローのための以前に格納されたデータ、サーバのシーケンス番号、及び選択されたサーバノード130のロードバランサモジュール132のIPアドレスを含む別のメッセージを、2次フロートラッカー116Bに転送する。2次フロートラッカー116Bは、サーバのシーケンス番号を確認し、情報を記録し、作成されたSYNメッセージを選択されたサーバノード130のロードバランサモジュール132に送る。TCPフローのCPエンドポイントのペアは、この時点で、ロードバランサモジュール132/サーバノード130にマッピングされる。サーバノード130のロードバランサモジュール132は、作成されたSYNメッセージを2次フロートラッカー116Bから受け取ると、サーバノード130のサーバ134のための正規のTCP SYNパケットを作成することを担当する。SYNパケットを作成する際に、送信元IPアドレスにクライアント160の実際のIPアドレスが取り込まれ、その結果、サーバ134は、クライアント160から直接のTCP接続要求を受け取ったと確信する。ロードバランサモジュール132は、TCPフローに関する関連の詳細を、例えばローカルのハッシュテーブルに格納し、TCP SYNパケットをサーバ134に送る(例えば、SYNパケットをサーバ134のLinuxカーネルに注入する)。
図10Cでは、入口サーバ112、1次フロートラッカー116A、及び2次フロートラッカー116Bの役割は、各々異なるロードバランサノード110によって行われる。しかしながら、いくつかの場合では、TCPフローのための入口サーバ112として機能するロードバランサノード110は、TCPフローのための1次フロートラッカー116Aまたは2次フロートラッカー116Bとして機能する同じノード110であってもよい(しかし、両方ではない)。例えば、図10Dでは、2次フロートラッカー116Bは、TCPフローのための入口サーバ112と同じロードバランサノード110Aにあり、一方1次フロートラッカー116Aは、異なるロードバランサノード110Bにある。
図10Eを参照すると、サーバ134(例えば、Linuxカーネル)は、ロードバランサモジュール132もまた傍受するSYN/ACKパケットで応答する。SYN/ACKパケットは、2次フロートラッカー116Bから生成されたSYN/ACKでクライアント160に元々配信された(図10Aを参照)ものとは異なるTCPシーケンス番号を含むことができる。ロードバランサモジュール132は、シーケンス番号デルタを着信及び発信パケットに適用することを担当する。サーバ134からのSYN/ACKパケットはまた、ロードバランサモジュール132から2次フロートラッカー116Bに戻されるメッセージ(例えば、UDPメッセージ)を始動し、選択されたサーバノード130/ロードバランサモジュール132/サーバ134への接続が成功したことを示す。このメッセージを受け取ると、2次フロートラッカー116Aは、クライアント160とサーバ134との間のクライアント及びパブリックエンドポイント(CP)マッピングをコミットされたものとして記録し、同様のメッセージを、CPマッピングを同様に記録する1次フロートラッカー116Aに送ることができる。1次フロートラッカー116Aは、次に、CPマッピングメッセージを入口サーバ112に転送することができ、それは入口サーバ112に、サーバノード130のローカルのロードバランサモジュール132への接続のための全てのバッファされたデータパケットをカプセル化データパケットとして、転送させる。
図10Fを参照すると、接続のためのCPマッピングは、入口サーバに既知であり、その結果、接続のために入口サーバ112によって受け取られる着信TCPパケットは、カプセル化され(例えば、UDPに従って)、サーバノード130のローカルのロードバランサモジュール132にカプセル化データパケットとして直接に転送することができる。ロードバランサモジュール132は、データパケットをデカプセル化し、TCPパケットを、例えばTCPパケットをカーネルのTCPスタックに注入することにより、サーバノード130のサーバ134に送る。サーバ134からのアウトバウンドパケットは、サーバノード130のロードバランサモジュール132によって傍受され、カプセル化され(例えば、UDPに従って)、ロードバランサモジュール132がこの接続のために出口サーバ114として無作為に選択する任意のロードバランサノード110に転送される。出口サーバ114は、パケットをデカプセル化し、デカプセル化パケットをクライアント116に送る。選択されたロードバランサノード110の出口機能は、ステートレスであり、その結果、異なるロードバランサノード110は、出口サーバとして機能するロードバランサノード110の障害が発生すると、接続のための出口サーバ114として選択することができる。しかしながら、概して同じロードバランサノード110は、アウトバウンドパケットの再配列を減少させる、または除去するために、接続の期間にわたって出口サーバ114として使用される。
図10Gを参照すると、少なくともいくつかの実施形態では、1次フロートラッカー116Aによって選択されたサーバノード130Aのロードバランサモジュール132A(図10Cを参照)が、それがオーバーロード状態であることを決定する場合、それは、2次フロートラッカー116Bから受け取る作成されたSYNメッセージを拒否する選択肢を有する(図10Cを参照)。少なくともいくつかの実施形態では、作成されたSYNメッセージは、存続可能時間(TTL)値または拒否の最大数を許容するカウンタを含む。少なくともいくつかの実施形態では、このTTL値がゼロに達すると、ロードバランサモジュール132Aは、接続を受け入れるか、または接続をドロップしてロードを捨てるか、のいずれかを行うことができる。ロードバランサモジュール132Aが、接続を拒否することを決定する場合、それは、TTL値をデクリメントし、拒否メッセージを2次フロートラッカー116Bに送る。2次フロートラッカー116Bは、CPマッピングをリセットし、同じことを行うように解放メッセージを1次フロートラッカー116Aに送る。1次フロートラッカー116Aは、別のサーバノード130Bの新規のロードバランサモジュール132Bを選び、新規の対象となるメッセージを2次フロートラッカー116Bに送り返し、それは、新規の作成されたSYNメッセージを新規に選ばれたロードバランサモジュール132Bに送る。パケットのドロップは、このシーケンスが完了することに失敗する結果になる場合もあるが、クライアント160からの再送信は、ロードバランサモジュール選択プロセスを1次フロートラッカー116Aで再び始動させることができ、それは、必ずではないが、作成されたSYNパケットの以前の拒否について学習していなかった場合、接続のために同じロードバランサモジュール132を選ぶことに留意されたい。
少なくともいくつかの実施形態では、TTLカウンタは、サーバノード130に接続要求を連続して送ることを防ぐために使用することができ、それは、例えば、全てのサーバノード130が使用中になっている場合に、起こることがある。少なくともいくつかの実施形態では、ロードバランサモジュール132がそれぞれのサーバノード130に代わって接続要求を拒否する度に、ロードバランサモジュール132は、TTLカウンタをデクリメントする。フロートラッカーノード116は、TTLカウンタを監視することができ、TTLカウンタがゼロでない(または、ある指定された閾値より上である)限り、別のサーバノード130を選択し、再び試行することができる。TTLカウンタがゼロに達する(または、指定された閾値に達する)場合、接続要求はドロップされ、その接続のためにサーバノード130のうちの選択された1つに接続要求を送る更なる試みは、フロートラッカーノード116によって行われない。少なくともいくつかの実施形態では、エラーメッセージをそれぞれのクライアント160に送ることができる。
少なくともいくつかの実施形態では、分散型ロードバランサシステムは、複数のパブリックIPアドレスをサポートする。このように、クライアント160は、同じクライアントポート番号から2つの異なるパブリックIPアドレスへの2つのTCP接続を開始することができる。これらのTCP接続は、クライアント160の観点からすると異なっているが、内部では分散型ロードバランサは、その接続を同じサーバノード130にマッピングすることがあり、衝突をもたらすことがある。少なくともいくつかの実施形態では、潜在的な衝突を検出して取り扱うために、ロードバランサモジュール132は、図10C及び10Dで示されるように作成されたSYNパケットを2次フロートラッカー116Bから受け取ると、アドレス情報をそのアクティブな接続と比較し、この接続が衝突の原因となっている場合、図10Gで示されるように接続要求を拒否することができる。
ロードバランサノードの障害及び追加の取り扱い
多くの従来のロードバランサでは、ロードバランサの障害が発生すると一部または全部の既存の接続が失われる。少なくともいくつかの実施形態では、単一のロードバランサノード110の障害が発生すると、分散型ロードバランシングシステムは、確立された接続の少なくともいくつかを維持することができ、その結果、クライアント及びサーバは、接続が正常に完了するまで、接続を介してパケットの交換を継続することができる。さらに、分散型ロードバランシングシステムは、障害発生の時点で確立される過程にあったサービス接続を継続することができる。
分散型ロードバランシングシステムの少なくともいくつかの実施形態では、単一のロードバランサノード110の障害が発生すると既存のクライアント接続をリカバリすることができる障害リカバリプロトコルを実装することができる。しかしながら、複数のロードバランサノード110の障害は、クライアント接続が失われる結果となることがある。少なくともいくつかの実施形態では、クライアント160とサーバ134との間のTCP再送信は、ロードバランサノード110の障害に続くリカバリの手段として使用することができる。
潜在的なロードバランサノード110の障害に加えて、新規のロードバランサノード110を分散型ロードバランサシステムに追加することができる。これらの新規のノード110は、ロードバランサ層に、したがってコンシステントハッシュリングに追加することができ、既存のクライアント接続に関するロードバランサノード110の役割は、必要に応じて、変更に従って調整することができる。
フロートラッカーノードの障害及び追加の取り扱い
少なくともいくつかの実施形態では、各々の接続が確立されると(例えば、図10A〜10Gを参照)、接続状態情報は、1次及び2次フロートラッカーと呼ばれる2つのロードバランサノード110を通過し、それらは、例えば、(クライアントIP:ポート、パブリックIP:ポート)タプルをハッシュ関数入力として使用するコンシステントハッシュアルゴリズムを使用して決定することができる。単一のロードバランサノード110の障害が発生すると、生き残っているロードバランサノード110の内の少なくとも1つは、コンシステントハッシュ関数を介して継続してマッピングすることができ、パケットを接続のための選択されたサーバノード130に向ける接続に必要な状態情報を含むことができる。さらに、ロードバランサノード110をコンシステントハッシュリングに追加する場合では、接続のための状態情報は、適切なフロートラッカーに更新することができる。
図11A〜11Dは、少なくともいくつかの実施形態に従う、ロードバランサノードのコンシステントハッシュリングのメンバーシップに影響を与えるイベントの取り扱いを例示する。これらのイベントは、限定されるものではないが、新規の1次フロートラッカーノードを追加すること、新規の2次フロートラッカーノードを追加すること、1次フロートラッカーノードの障害、及び2次フロートラッカーノードの障害を含むことができる。
図11Aは、コンシステントハッシュリングへの新規の1次フロートラッカーノードの追加の取り扱いを例示する。図11Aの上部行は、フロートラッカー116Aを1つ以上のクライアント接続のための1次フロートラッカーとして、及びフロートラッカーノード116Bを同じ接続(複数可)のための2次フロートラッカーとして、示す。図11Aの底部行では、新規のフロートラッカーノード116Cが追加され、クライアント接続(複数可)のための1次フロートラッカーになっている。フロートラッカーノード116Aは、以前は1次フロートラッカーであったが、2次フロートラッカーになり、一方フロートラッカーノード116Bは、以前は2次フロートラッカーであったが、コンシステントハッシュリング内の次のフロートラッカーになっている。フロートラッカー116A及び116Bによって維持されていたクライアント接続(複数可)のための状態情報は、新規の1次フロートラッカー116Cに提供することができる。さらに、フロートラッカー116Bは、2次フロートラッカーの役割でそれの以前に追跡された接続を「忘れる」ことができる。
図11Bは、コンシステントハッシュリングへの新規の2次フロートラッカーノードの追加の取り扱いを例示する。図11Bの上部行は、フロートラッカー116Aを1つ以上のクライアント接続のための1次フロートラッカーとして、及びフロートラッカーノード116Bを同じ接続(複数可)のための2次フロートラッカーとして示す。図11Bの底部行では、新規のフロートラッカーノード116Cが追加され、クライアント接続(複数可)のための2次フロートラッカーになっている。フロートラッカーノード116Aは、接続(複数可)のための1次フロートラッカーとして残り、一方フロートラッカーノード116Bは、以前は2次フロートラッカーであったが、コンシステントハッシュリング内の次のフロートラッカーになっている。フロートラッカー116A及び116Bによって維持されていたクライアント接続(複数可)のための状態情報は、新規の2次フロートラッカー116Cに提供することができる。さらに、フロートラッカー116Bは、2次フロートラッカーの役割でそれの以前に追跡された接続を「忘れる」ことができる。
図11Cは、コンシステントハッシュリング内の1次フロートラッカーノードの障害の取り扱いを例示する。図11Cの上部行は、フロートラッカー116Aを1つ以上のクライアント接続のための1次フロートラッカーとして、フロートラッカーノード116Bを同じ接続(複数可)のための2次フロートラッカーとして、及びフロートラッカーノード116Cをコンシステントハッシュリング内の次のフロートラッカーとして示す。図11Cの底部行では、1次フロートラッカーノード116Aに障害が発生している。フロートラッカーノード116Bは、接続(複数可)のための1次フロートラッカーになり、一方フロートラッカーノード116Cは、接続(複数可)のための2次フロートラッカーになっている。クライアント接続(複数可)のための状態情報は、フロートラッカー116Bによって維持され、新規の2次フロートラッカー116Cに提供することができる。
図11Dは、コンシステントハッシュリング内の2次フロートラッカーノードの障害の取り扱いを例示する。図11Dの上部行は、フロートラッカー116Aを1つ以上のクライアント接続のための1次フロートラッカーとして、フロートラッカーノード116Bを同じ接続(複数可)のための2次フロートラッカーとして、及びフロートラッカーノード116Cをコンシステントハッシュリング内の次のフロートラッカーとして示す。図11Dの底部行では、2次フロートラッカーノード116Bに障害が発生している。フロートラッカーノード116Aは、接続(複数可)のための1次フロートラッカーとして残り、一方フロートラッカーノード116Cは、接続(複数可)のための2次フロートラッカーになっている。クライアント接続(複数可)のための状態情報は、フロートラッカー116Bによって維持され、新規の2次フロートラッカー116Cに提供することができる。
少なくともいくつかの実施形態では、サーバノード130のロードバランサモジュール132は、ロードバランサノード110への接続公開を行う。少なくともいくつかの実施形態では、接続公開は、現在の接続状態情報を、サーバノード130からフロートラッカーノード及び入口ノードとして機能するロードバランサノード110に、周期的(例えば、1秒に1回)または非周期的にプッシュし、それは、接続のための1次及び2次フロートラッカーノードの両方への接続マッピングを更新する、または復元するように動作する。少なくともいくつかの実施形態では、ロードバランサモジュール132は、フロートラッカーのメンバーシップの変更、例えば図11A〜11Dに例示されたようなもの、を検出することができる。それに応じて、ロードバランサモジュール132は、接続公開を行い、メンバーシップが変更したときに接続に関して変更した可能性がある1次及び2次フロートラッカーノードに接続に関する状態情報を取り込むことができる。接続公開は、複数のロードバランサノードの障害が発生したときに、少なくとも一部の確立された接続をリカバリすることが可能であることに留意されたい。
障害関連メッセージフロー
少なくともいくつかの実施形態では、1次と2次フロートラッカーノードとの間のプロトコルは、補正または同期機能を含むことができる。例えば、図11Aを参照すると、新規の1次フロートラッカーノード116Cがコンシステントハッシュリングに加わると、新規のノード116Cは、いくつかの数の接続(約1/N)をコンシステントハッシュ鍵空間に主張し、これらの接続に関連するトラフィックをエッジルータ104から受け取ることを開始することができる。しかしながら、新規の1次フロートラッカーノード116Cは、接続に関して格納された一切の状態を有していないので、それは、クライアント160から受け取った第1のパケットであるかのように各々のパケットに対して動作することができる。1次フロートラッカーは、SYNパケットに応じてサーバTCPシーケンス番号を生成すること(例えば、図10Aを参照)、及びクライアント160からの第1のACKパケットに応じてサーバノード130を選択すること(例えば、図1を参照)を担当し、それらの生成された値は、以前の1次フロートラッカー(図11Aのフロートラッカーノード116A)によって選ばれた値に一致しないことがある。しかしながら、少なくともいくつかの実施形態では、コンシステントハッシュアルゴリズムは、以前の1次フロートラッカー(図11Aのフロートラッカーノード116A)を2次フロートラッカーの役割に割り当て、このフロートラッカーは、接続に関して以前に格納された状態を依然として保持する。したがって、少なくともいくつかの実施形態では、2次フロートラッカー(図11Aのフロートラッカーノード116A)が1次フロートラッカー116Cから受け取った情報の中に不一致を検出すると、それは、更新メッセージを1次フロートラッカー116Cに送り返し、接続のためのフロートラッカーとして機能する2つのロードバランサノード110を同期させることができる。同様な方法を使用し、コンシステントハッシュリングのメンバーシップ内の他の変更の後で、フロートラッカーを同期させることができる。
ロードバランサモジュールの詳細
少なくともいくつかの実施形態では、ロードバランサモジュール132は、サーバノード130の各々に存在する分散型ロードバランサシステムの構成要素である。ロードバランサノード132の役割は、限定されるものではないが、ロードバランサノード110から受け取ったパケットをデカプセル化すること及びデカプセル化パケットをサーバノード130のサーバ134に送ること、並びにサーバ134からの発信パケットをカプセル化すること及びカプセル化パケットをロードバランサノード110に送ること、を含む。
少なくともいくつかの実施形態では、入口サーバ112として機能するロードバランサノード110からサーバノード130のロードバランサモジュール132への着信パケットは、実際のクライアントデータパケットをカプセル化するステートレスのプロトコル(例えば、UDP)パケットである。各々のカプセル化クライアントデータパケットは、それぞれのクライアント160のオリジナルのクライアントIP:ポートを送信元アドレスとして、及びサーバ134のパブリックIP:ポートを送信先アドレスとして、有する。ロードバランサモジュール132は、クライアントデータパケットからカプセル化を取り除き、例えばパケットをローカルホストTCPフローにリダイレクトすることにより、パケットをサーバノード130のそれぞれのサーバ134に送る。
少なくともいくつかの実施形態では、サーバ134から出口サーバ114として機能するロードバランサノード110への発信パケットは、発信IPパケットをカプセル化するステートレスのプロトコル(例えば、UDP)パケットである。ロードバランサモジュール132は、発信IPパケットをカプセル化し、カプセル化パケットを、ファブリック120を介して出口サーバ114に送る。各々のカプセル化発信IPパケットは、サーバ134のパブリックIP:ポートを送信元アドレスとして、及びそれぞれのクライアント160のクライアントIP:ポートを送信先アドレスとして、有する。
ロードバランサモジュールの機能
少なくともいくつかの実施形態では、サーバノード130のロードバランサモジュール132の機能は、限定されるものではないが、以下のうちの1つ以上を含むことができる、
・ロードバランサノード(複数可)110からの、例えばクライアント160への接続を取り扱う入口サーバ112からのUDPトンネルを終端すること。これは、入口サーバ112から受け取った着信クライアントデータパケットからUDPカプセル化を取り除くことを含む。
・接続のための発信トラフィックを受け取る出口サーバ114を選択すること。
・それぞれのサーバ134への接続で発信IPパケットを傍受すること、接続のための発信IPパケットをカプセル化すること、及びカプセル化パケットを出口サーバ114に送ること。
・着信及び発信パケット内のシーケンス番号をマングリングし、その結果、フロートラッカーノード116がSYN/ACKをクライアント160に送ったとき、シーケンス番号が、フロートラッカーノード116によって生成されたシーケンス番号に整合する。
・それぞれのサーバ134のための接続を受け入れるか、拒否するかを、例えばそれぞれのサーバ134の現在のロードを示す1つ以上のメトリックに基づいて、決定を行うこと。
・クライアントIP:ポートアドレスのためのアクティブな接続が存在する場合、同じクライアントIP:ポートアドレスからそれぞれのサーバ134への接続を検出し、拒否して、衝突を回避すること。
・接続の追跡及び接続の公開。
ロードバランサモジュール構成情報
少なくともいくつかの実施形態では、各々のロードバランサモジュール132は、限定されるものではないが、その構成に関する情報の以下のセット、ロードバランサノード110のエンドポイントのセット、それが提供すべき有効なパブリックIPアドレスのセット、及びそれぞれのサーバ134が着信接続を受け入れるポート番号(複数可)、のうちの1つ以上を取得し、ローカルで格納することができる。少なくともいくつかの実施形態では、この情報は、図1に例示されるように、分散型ロードバランサシステムの構成サービス122の構成要素から取得することができる、またはそれにアクセスまたは照会することによって更新することができる。いくつかの実施形態では、情報を取得する他の方法を使用することができる。
ロードバランサモジュールのパケット取り扱い
以下では、少なくともいくつかの実施形態に従うインバウンドトラフィック及びアウトバウンドトラフィックに対するロードバランサモジュール132の動作を説明する。少なくともいくつかの実施形態では、インバウンドデータパケットがロードバランサモジュール132によって受け取られるとき、データパケットは、UDPパケットからデカプセル化され、デカプセル化TCPパケット内の送信先アドレスは、最初に、構成された有効パブリックIPアドレスのセットに対して検証される。一致しない場合、パケットはドロップされるまたは無視される。少なくともいくつかの実施形態では、ロードバランサモジュール132は、一定のデルタによってTCPヘッダ内のシーケンス番号を調整することができ、その結果、シーケンス番号は、SYN/ACKパケットをクライアント160に送ったフロートラッカーノード116によって生成される無作為に選ばれたシーケンス番号に一致する。ロードバランサモジュール132は、[クライアント:パブリック]エンドポイントから[クライアント:サーバ]エンドポイントへのマッピングを内部状態として記録する。
少なくともいくつかの実施形態では、サーバ134からのアウトバウンドTCPパケットの場合、ロードバランサモジュール132は、その内部状態を最初にチェックし、パケットはロードバランサモジュールが管理しているアクティブな接続のためのものであるかを決定する。そうではない場合、ロードバランサモジュール132は、パケットを通過させるだけである。そうである場合、ロードバランサモジュール132は、発信TCPパケットを例えばUDPに従ってカプセル化し、カプセル化パケットをこの接続のための出口サーバ114として選択されたロードバランサノード110に転送する。少なくともいくつかの実施形態では、ロードバランサモジュール134は、一定のデルタによって発信TCPパケット内のTCPシーケンス番号を調整することができ、その結果、それは、SYN/ACKパケットをクライアント160に送ったフロートラッカーノード116によって生成されたシーケンス番号に整合する。
接続の追跡
少なくともいくつかの実施形態では、各々のサーバノード130のロードバランサモジュール132は、それぞれのサーバ134の全てのアクティブなクライアント接続に関する接続の詳細を含むハッシュテーブルを管理する。少なくともいくつかの実施形態では、ハッシュテーブルのための鍵は、(クライアントIP:ポート、パブリックIP:ポート)タプルである。少なくともいくつかの実施形態では、各々のクライアント接続に関する接続状態は、限定されるものではないが、以下のうちの1つ以上を含む、
・クライアントIP:ポート。
・パブリックIP:ポート。
・フロートラッカー116ノードによって提供される初期サーバTCPシーケンス番号。
・サーバTCPシーケンス番号デルタ。
・オリジナルの1次フロートラッカーIPアドレス
・オリジナルの2次フロートラッカーIPアドレス。
・最後に検出された入口サーバ112のIPアドレス。
・このエントリに関する有効期間。
・最小使用頻度(LRU)/衝突指標。
少なくともいくつかの実施形態では、各々のロードバランサモジュール132は、接続公開メッセージを全てのアクティブなクライアント接続のための1次及び2次フロートラッカーノードに周期的に生成する。少なくともいくつかの実施形態では、/proc/net/tcpのコンテンツは、ロードバランサモジュールのハッシュテーブル内のアクティブな接続でスキャンされ、また交差し、その結果それらは、Linuxカーネルが接続の追跡を停止するまで、フロートラッカーノードに継続して公開される。接続公開は、本明細書の後半でより詳細に説明される。
シーケンス番号マングリング
前述のように、少なくともいくつかの実施形態では、ロードバランサノード110は、サーバ134に代わってクライアント160のSYNパケットに応じてSYN/ACKパケットを生成する。クライアント160がACKパケット(TCPスリーウェイハンドシェイク)を送った後にのみ、ロードバランサモジュール110は、任意のデータをサーバノード130のロードバランサモジュール132に送る。ロードバランサモジュール132が最初にクライアント接続を確立するように命令されると、ロードバランサモジュール132は、SYNパケットをローカルで作成してサーバノード130のサーバ134とのTCP接続を開始し、サーバ134の対応するSYN/ACKパケットを傍受する。典型的には、サーバ134(例えば、サーバノード130のLinuxカーネル)は、クライアントがロードバランサノード110からSYN/ACKパケット内で受け取ったものとは全く異なるTCPシーケンス番号を選択する。したがって、少なくともいくつかの実施形態では、ロードバランサモジュール132は、クライアント160とサーバ134との間のTCP接続における全てのパケット内のシーケンス番号を補正することができる。少なくともいくつかの実施形態では、ロードバランサモジュール132は、ロードバランサノード110によって生成されたシーケンス番号とサーバ134によって生成されたシーケンス番号との間の差を計算し、その差をデルタ値としてTCP接続のためのハッシュテーブルエントリ内に格納する。着信データパケットが接続上のクライアント160から到着すると、TCPヘッダは、サーバ134によって使用されるシーケンス番号に整合しない受信確認番号を含み、ロードバランサモジュール132は、デルタ値をTCPヘッダ内のシーケンス番号値から減算する(例えば、2つの補数を使用して)。ロードバランサモジュールはまた、デルタ値をサーバ134から接続上のクライアント130へのアウトバウンドパケット内のシーケンス番号に加算する。
分散型ロードバランサシステムのヘルスチェック
分散型ロードバランサシステムの少なくともいくつかの実施形態では、各々のロードバランサノード110は、少なくとも以下の理由から、ロードバランサ実現形態の健全なメンバーの(すなわち、健全なロードバランサノード110及びサーバノード130の)コンシステントビューを要求する、
・ロードバランシング−ロードバランサノード110は、サーバノード130の障害を検出し、クライアントトラフィックを受け入れることができる健全なサーバノード130のセットを収束する必要がある。
・分散状態管理−ロードバランサは、複数のロードバランサノード110にわたり(例えば、コンシステントハッシング機構に従って)共有された/複製された状態を備える分散型システムである。クライアントトラフィックを適正に取り扱うために、各々のロードバランサノード110は、ロードバランサ実現形態の健全なメンバーノード110の最終的なコンシステントビューを有する必要がある。
これを実現するために、分散型ロードバランサシステムの少なくともいくつかの実施形態は、ロードバランサ実現形態のノードを監視し、可能な限り迅速に不健全なノードを検出するヘルスチェックプロトコルの実施形態を実装する。ヘルスチェックプロトコルは、ヘルス情報をロードバランサ実現形態のノード間に伝搬させることができ、ノードが健全ノードのセットに収束することを可能にする方法を提供することができる。さらに、ヘルスチェックプロトコルは、ロードバランサ実現形態の健全/不健全ノード及び状態変化を報告するための機構を提供することができる。
少なくともいくつかの実施形態では、ヘルスチェックプロトコルは、限定されるものではないが、以下の前提条件のうちの1つ以上に基づくことができる、
・ロードバランサ実現形態の全てのノードが既知である。(すなわち、ヘルスチェックプロトコルは探索を行わなくてもよい)。
・全てのノード障害は、フェイルストップである。
・ノード間の全てのメッセージはステートレスプロトコル(例えば、UDP)メッセージであり、メッセージは、ドロップ、遅延、重複、または破損している可能性がある。メッセージ配信は保証されていない。
少なくともいくつかの実施形態では、ロードバランサ実現形態のノード(例えば、ロードバランサノード110またはサーバノード130)は、以下の条件下で健全とみなすことができる、
・ノードの内部の構成要素の全てが準備完了状態にある(クライアントトラフィックを取り扱う準備が完了している)。
・ノードの着信/発信ネットワークリンクが健全である(少なくともクライアントトラフィックがフローするネットワークインターフェースコントローラ(NIC)に関して)。
図12は、少なくともいくつかの実施形態に従う、ヘルスチェック間隔に従って各々のロードバランサノードによって行うことができるヘルスチェック方法の高レベルのフローチャートである。1000に示されるように、各々のロードバランサ間隔で、例えば100ミリ秒毎で、各々ロードバランサ(LB)ノード110は、少なくとも1つの他のLBノード110及び少なくとも1つのサーバノード130をヘルスチェックすることができる。1002に示されるように、ロードバランサノード110は、そのローカルに格納されたヘルス情報をヘルスチェックに従って更新することができる。1004に示されるように、ロードバランサノード110は、次に、少なくとも1つの他のロードバランサノード110を無作為に選択し、そのヘルス情報を選択されたロードバランサノード(複数可)110に送ることができる。少なくともいくつかの実施形態では、ノード110はまた、健全なロードバランサノード110のリストを1つ以上のサーバノード130、例えばノード110によってヘルスチェックされる同じサーバノード(複数可)130に送ることができる。図12の要素は、以下の考察でより詳細に説明される。
ヘルスチェックプロトコルの少なくともいくつかの実施形態では、ロードバランサノード110は、それ自身のヘルスを他のロードバランサノード110にアサートしない。その代りに、1つ以上の他のロードバランサノード110は、そのノード110をヘルスチェックすることができる。例えば、少なくともいくつかの実施形態では、各々のロードバランサノード110は、ヘルスチェックするための1つ以上の他のノード110を周期的または非周期的に無作為に選択することができる。別の実施例として、少なくともいくつかの実施形態では、1つ以上の他のロードバランサノード110、例えばコンシステントハッシュリングのようなノード110の順序付けリストにある所与のロードバランサノード110の2つの最近傍のものは、各々所与のノード110のヘルスを周期的または非周期的にチェックすることができる。少なくともいくつかの実施形態では、ノード110をヘルスチェックすることは、図23に例示されるように、ノード110のNIC1114に送られたヘルスピンを使用することを含むことができる。少なくともいくつかの実施形態では、第1のノード110がヘルスチェックを介して第2のノード110が健全であることを決定する場合、第1のノード110は、ロードバランサノード110に関するローカルのヘルス情報に格納された第2のノード110のためのハートビートカウンタを更新する(例えば、インクリメントする)ことができる。第1のノード110は、そのローカルのヘルス情報をロードバランサ実現形態の1つ以上の他のロードバランサノード110に周期的または非周期的に送り、それらは、それら自身のヘルス情報をそれに応じて更新し(例えば、第2のノードのためのハートビートカウンタをインクリメントすることにより)、それらの更新されたローカルのヘルス情報を1つ以上の他のノード110に送ることができる。第2のノード110に関するハートビート情報は、そのようにロードバランサ実現形態の他のノード110に伝搬することができる。第2のノード110が健全である限り、第2のノード110から到達可能である他のノード110の全ては、第2のノード110のハートビートカウンタが、このように一貫した基準で例えば1秒に1回または10秒毎に一回インクリメントされていることを確認する必要がある。第2のノード110が、そのヘルスをチェックするノード(複数可)110によって、不健全であることが検出される場合、ノード110のハートビートは、ヘルスチェックするノード110によって送られることがなく、ある時間閾値の後に、ロードバランサ実現形態110の他のノード110は、そのノード110が不健全であるまたはダウンしているとみなす。
少なくともいくつかの実施形態では、ロードバランサノード110は、それ自身の内部状態の1つ以上の態様をチェックすることができ、ノード110が、それがある理由で不健全であることを検出する場合、ノード110は、そのヘルスをチェックする他のノード110からのヘルスピンに応答することを停止することができる。したがって、不健全なノード110のヘルスをチェックするノード110は、ノード110を不健全なものとしてみなすことができ、ノード110に代わってハートビートのインクリメントを伝搬しなくてもよい。
ヘルスチェックプロトコルの詳細
少なくともいくつかの実施形態では、ヘルスチェックプロトコルは、ハートビートカウンタ技術及びゴシッププロトコル技術を活用することができる。ヘルスチェックプロトコルは、2つの主要部分、ヘルスチェック及びゴシップ/障害検出を有するとみなすことができる。
ヘルスチェック−ロードバランサ実現形態の全てのロードバランサノード110は、実現形態の1つ以上の他のノード110を周期的または非周期的にヘルスチェックすることができる。1つ以上の他のノードが決定される方法は後半で説明される。ヘルスチェックのコアとなるアイデアは、ノード110が別のノード110をヘルスチェックし、他のノード110が健全であることを決定する場合、チェックしたノード110は、他のノード110のハートビートカウンタをインクリメントし、伝搬することによって、他のノード110が健全であることアサートする。言い換えれば、ノード110は、それ自身のヘルスを他のノードにアサートせず、その代りに、1つ以上の他のノード110がロードバランサ実現形態の各々のノード110のヘルスをチェックし、アサートする。
ゴシップ/障害検出−少なくともいくつかの実施形態では、ヘルスチェックプロトコルは、ゴシッププロトコルを活用し、ロードバランサノード110のヘルス情報をロードバランサ実現形態のメンバーのロードバランサノード110間に伝搬することができる。ゴシッププロトコルは、急速に収束し、分散型ロードバランシングシステムの目的のために十分である最終的な一貫性の保証を提供する。少なくともいくつかの実施形態では、ゴシッププロトコルを使用し、各々のロードバランサノード110は、ロードバランサ実現形態の各々の他のノード110のためのハートビートカウンタを、例えばハートビートリストに維持する。各々のロードバランサノード110は、上述のように、少なくとも1つの他のロードバランサノード110のヘルスチェックを周期的または非周期的に行い、チェックされたノード110が健全であることを、ヘルスチェックを介して決定すると、ノード110のためのハートビートカウンタをインクリメントする。少なくともいくつかの実施形態では、各々のロードバランサノード110は、それがその現在のハートビートリストを送るロードバランサ実現形態の少なくとも1つの他のノード110を周期的または非周期的に無作為に選択する。ハートビートリストを別のノード110から受け取ると、ロードバランサノード110は、2つのリスト(受け取ったリスト及びそれ自身のリスト)内の各々ノード110のための最大ハートビートカウンタを決定し、それ自身のハートビートリスト内の決定された最大ハートビートカウンタを使用することにより、受け取ったリスト内のハートビート情報をそれ自身のハートビートリストと併合する。今度は、このハートビートリストは別の無作為に選択されたノード110に送られ、それは、それに応じてそれ自身のハートビートリストを更新し、以降も同様である。この技術を使用すると、各々の健全なノード110に関するハートビート情報は、最終的に(例えば、数秒以内に)ロードバランサ実現形態の他のロードバランサノード110の全てに伝搬される。ハートビートカウンタが所与のロードバランサノード110について増え続ける限り、それは、他のノード110によって、健全であるとみなされる。ロードバランサノード110のハートビートカウンタが、ヘルスチェック及びゴシップ方法によって指定された期間にわたってインクリメントされない場合に、他のロードバランサノード110は、不健全であるとみなされているロードバランサノード110に収束することができる。
ロードバランサノードのヘルスチェック
以下で、少なくともいくつかの実施形態に従って、別のロードバランサノード110によって行うことができるロードバランサノード110をヘルスチェックするための方法を説明する。図23を参照すると、少なくともいくつかの実施形態では、ロードバランサノード110は、以下の条件のうちの1つ以上がノード110について決定される場合、健全であるとみなすことができる、
・ノード110のプロセッサスレッド(例えば、コアパケット処理コード1108のスレッド)は、準備完了状態(内部)にある。
・ノード110は、エッジルータ104のIPアドレス及び/またはMACアドレスを既知である(内部)。
・ノード110のスレッド及び/またはプロトコルハンドラの全ては、準備完了状態にある(内部)。
・ノース側(エッジルータ104/ボーダーネットワーク)からの、及びサウス側(サーバ130/実稼働ネットワーク)からの着信及び発信リンクは、アクティブである(外部)。
・ノード110は、ロードバランサ実現形態で使用されるネットワークインターフェース制御装置(NIC)を介してパケットを受け取り、急送することができる。例えば、図23に示されるような例となるロードバランサノード110実施形態では、ノード110は、パケットをノース側NIC1114A及びサウス側NIC1114Bを介して首尾よく受け取り、急送する必要がある。
これらのヘルス条件のうちの1つ以上が所与のノード110について保持されない場合、ノード110は、健全でないとみなすことができる。いくつかの実施形態では、ノード110は、上記の条件の全てがノード110について保持される場合にのみ、健全であるとみなされることに留意されたい。
少なくともいくつかの実施形態では、上記のヘルス条件に加えて、例えば制御プレーン通信のために使用することができる各々のロードバランサノード110の図23でNIC1114Cとして示される第3のNICもまた、パケットをNICへ送ること及びパケットをそこから受け取ることによって、ヘルスチェックするノード110によってチェックすることができ、第3のNICのチェックが不合格になる場合、チェックされているノード110は不健全であるとみなすことができる。
図13は、少なくともいくつかの実施形態に従って、ロードバランサノードを別のロードバランサノードからヘルスチェックするための例となる方法を例示する。この実施例では、ロードバランサノード110Aは、ロードバランサノード110Bをヘルスチェックする。各々のノード110A及び110Bは、ノース側NIC(図23のNIC1114A)及びサウス側NIC(図23のNIC1114B)を有する。1では、ノード110Aは、パケット(例えば、ピンパケット)をそのノース側NICからノード110Bのノース側NICにエッジルータ104を介して送る。ノード110Bは、パケットをそのノース側NICで受け取り、上記のリストに示された条件が満たされれば、2で、応答をそのノース側NICからノード110Aのノース側NICにファブリック120を介して送る。そのノース側NICで応答を受け取り後、3で、ノード110Aは、パケット(例えば、ピンパケット)をそのサウス側NICからノード110Bのサウス側NICにファブリック120を介して送る。ノード110Bは、パケットをそのサウス側NICで受け取り、上記のリストに示された条件が満たされれば、4で、応答をそのサウス側NICからノード110Aのサウス側NICにエッジルータ104を介して送る。応答をそのサウス側NICで受け取ると、ノード110Aは、ノード110Bを健全であるとみなし、ノード110Bのローカルのハートビートカウンタをインクリメントし、それは、次に、前述のようにゴシッププロトコルに従って、他のノード110に伝搬することができる。
上記の代替として、いくつかの実施形態では、ロードバランサノード110Bは、そのサウス側NICを介して、そのノース側NICで受け取った第1のピンメッセージに対して、ノード110Aのサウス側NICに応答し、そのノース側NICを介してそのサウス側NICで受け取った第2のピンメッセージに対して、ノード110Aのノース側NICに応答することができる。
さらに、いくつかの実施形態では、ノード110Aはまた、ピンをそれ自身の第3のNICからノード110Bの第3のNICに送り、ノード110Bが健全である場合に、ピンメッセージに対する応答をその第3のNICでノード110Bの第3のNICから受け取ることにより、制御プレーン通信のために使用されているノード110Bの第3のNIC(図23でNIC1114Cとして示される)をヘルスチェックすることができる。ピンメッセージ及び応答は、1つ以上の制御プレーンデバイス(複数可)170、例えばネットワークスイッチを通過することができる。
上述のヘルスチェック機構は、全ての方向(ノース、サウス、及び制御プレーンを介する)のノード110Bの着信及び発信リンク並びにデータパスの全て、並びにノード110BのNICの全てを用い、更にクライアントパケットと同じように、ピンパケットが内部のキューを通過するときにノード110Bの内部のヘルス及びノード110Bの急送を検証する。
ロードバランサノードへのヘルスチェック担当の割り当て
少なくともいくつかの実施形態では、ロードバランサ実現形態の全てのロードバランサノード110は、例えば図1に示されるような構成機能を介して及び/または構成サービス122の構成要素を介して、ロードバランサ実現形態の他のロードバランサノード110の全てのリスト(例えば、ソート済みリスト)へのアクセスを有する。少なくともいくつかの実施形態では、各々のロードバランサノード110は、各々のヘルスチェック間隔でヘルスチェックし、健全であると決定されるとハートビートカウンタをインクリメントするリスト上の1つ以上の他のノード110を無作為に選択することができる。リストは、ヘルスチェック機構を介して現在健全または不健全とみなされていてもロードバランサ実現形態の全てのロードバランサノード110を含み、現在不健全であるノード110は、健全であるノード110と同様に、リストから無作為に選択され、ヘルスチェックされることに留意されたい。したがって、現在不健全であるノード110は、ノード110をヘルスチェックする1つ以上のノード110によって健全であると決定されることがあり、そのハートビートカウンタは、インクリメントされ、他のノード110に伝搬することができ、不健全であるノード110は、したがって、健全な状態に戻ることができる。
あるいは、いくつかの実施形態では、各々のロードバランサノード110は、リスト内の1つ以上の他のノード110をヘルスチェックし、健全であることが決定される場合、それらのハートビートカウンタをインクリメントすることを担当することができる。例えば、いくつかの実施形態では、各々のノード110は、2つの他のノード、例えばリスト内のその「左の」(または前の)及び「右の」(または次の)最近傍のノード110を担当することができる。リストは、円とみなすことができ、リストの「終わり」にあるノード110は、リストの「始め」にあるノード110をヘルスチェックすることを担当することができ、またその逆も同様である。いくつかの実施形態では、2つの他のノード110は、それ以外の方法では、例えばリスト上で2つの次に最近傍のものとして選択することができる。いくつかの実施形態では、各々のノード110は、リスト上の2つ以上の他のノード110、例えば3つまたは4つの他のノード110をヘルスチェックすることを担当することができる。少なくともいくつかの実施形態では、ノード110によってチェックされている近傍のノード110が不健全であると決定される場合に、ノード110は、不健全である近傍のノード110がチェックを担当していたリスト上の少なくとも1つのノードをヘルスチェックすることを担当することができる。少なくともいくつかの実施形態では、その近傍のノード110(例えば、「左」及び「右」の近傍のノード)をヘルスチェックすることに加えて、各々のロードバランサノード110はまた、リング内のノード110を周期的または非周期的に無作為に選択し、無作為に選択したノード110のヘルスチェックを行い、健全である場合、無作為のノード110のハートビートをインクリメントし、かつ伝搬させることができる。少なくともいくつかの実施形態では、順序付けリスト内の全ての他のノード110は、他のノード110が以前に健全であるとみなされたか否かに関わらずに、無作為の選択及びヘルスチェックの対象とみなされる。
少なくともいくつかの実施形態では、各々のノード110は、1つ以上の無作為に選択されたノード110の、またはあるいは、その近傍のノード110及び無作為に選択されたノードのヘルスチェックを、ヘルスチェック間隔と呼ぶことができる一定の間隔で、行う。例えば、いくつかの実施形態では、ハートビート間隔は100ミリ秒であってもよいが、より短いまたはより長い間隔を使用することもできる。さらに、少なくともいくつかの実施形態では、各々のノード110は、その現在のハートビートリストを少なくとも1つの無作為に選択されたノード110に、ゴシップ間隔と呼ぶことができる一定の間隔で、送るまたは「ゴシップ」する。いくつかの実施形態では、ヘルスチェック間隔及びゴシップ間隔は同じであってもよいが、必ずしも同じではない。
図14は、少なくともいくつかの実施形態に従って、1つ以上の他のロードバランサノードをヘルスチェックするロードバランサノードをグラフィカルに例示する。この実施例では、ロードバランサ実現形態に8つのロードバランサノード110A〜110Hが存在する。点線の円は、実現形態の全てのノード110の順序付けリストを表す。いくつかの実施形態では、各々のノード110は、各々の間隔でヘルスチェックするためにリスト上の1つ以上の他のノード110を無作為に選択することができる。代替として、いくつかの実施形態では、各々のロードバランサノード110は、順序付けリスト上の1つ以上の特定のノード110をチェックすることを担当することができ、例えば、ノード110Aは、図14に示されるように、順序付けリストに従って、その2つの最近傍のノード110B及び110Hをヘルスチェックすることを担当することができる。更に、ロードバランサノードはまた、別のノード110を各々のヘルスチェック間隔で順序付けリストから無作為に選択することができる。この実施例で示されるように、ノード110Aはまた、ヘルスチェックするためにノード110Fを無作為に選択した。ゴシップ間隔で、ノード110Aは、ある他の健全であるノード110、例えばノード110Dを無作為に選択し、その現在のハートビートリストを選択された他のノード110に、例えばUDPメッセージで送る。ノード110は、ハートビートリストを別のノード110から受け取ると、それに応じてそれ自身のハートビートリストを更新し、ハートビートリストを1つ以上の無作為に選択されたノード110に、次のゴシップ間隔で伝搬することができる。
サーバノードのヘルスチェック
上述のようにロードバランサノード110をヘルスチェックすることに加えて、ヘルスチェックプロトコルの実施形態は、ノード130のロードバランサモジュール132及びサーバ134を含むサーバノード130のヘルスチェックを行うことができる。少なくともいくつかの実施形態では、サーバノード130は、以下の条件の1つまたは両方がノード130について決定される場合、健全であるとみなすことができる、
・ロードバランサモジュール132は健全である。
・サーバノード130は、ヘルスピン(例えば、L7ヘルスピン)に首尾よく応答する。
図15は、少なくともいくつかの実施形態に従って、サーバノードをヘルスチェックするロードバランサノードを例示する。少なくともいくつかの実施形態では、ロードバランサ実現形態の全てのロードバランサノード110は、ロードバランサ実現形態の他のロードバランサノード110の全てのリスト、並びにロードバランサ実現形態の全てのサーバノード130のリストにアクセスすることができる。リスト(複数可)は、例えば図1に示されるように構成機能を介して及び/または構成サービス122構成要素を介して、取得し、更新することができる。少なくともいくつかの実施形態では、サーバノード130は、健全なロードバランサノード110に対してコンシステントハッシュ化され、図15に示されるようにコンシステントハッシュリングを形成することができる。少なくともいくつかの実施形態では、リング内の各々のサーバノード130は、リング内の2つの健全なロードバランサノード110によってヘルスチェックされる。例えば、図15では、サーバノード130Aは、ロードバランサノード110A及び110Cによってヘルスチェックされる。これらの2つのノード110は、コンシステントハッシュリング内のサーバノード130のための第1(ノード110A)及び第2(ノード110B)ヘルスチェックノード110と呼ぶことができる。所与の健全なロードバランサノード110は、1つよりも多くのサーバノード130をヘルスチェックすることができることに留意されたい。例えば、図15では、ロードバランサノード110Aはまた、サーバノード130B及び130Cをヘルスチェックする。更に、所与のノードバランサノード110は、1つ以上のサーバノード130のための第1のヘルスチェックノード110であり、かつ1つ以上の他のサーバノード130のための第2のヘルスチェックノード110であることができる。例えば、図15では、ロードバランサノード110Aは、サーバノード130A及び130Bのための第1のヘルスチェッカーノードであり、かつサーバノード130C及び130Dのための第2のヘルスチェッカーノードである。
少なくともいくつかの実施形態では、ロードバランサノード110に障害が発生すると、コンシステントハッシュリングのメンバーシップが変更されて、まだ健全でありしたがってコンシステントハッシュリングにまだ存在するロードバランサノード110の1つ以上の他のものが、障害が発生したノード110によって以前にヘルスチェックされたサーバノード130をヘルスチェックすることを担当することができる。
少なくともいくつかの実施形態では、各々の健全なノード110は、サーバチェック間隔と呼ぶことができる一定の間隔で、その割り付けられたサーバノード130のヘルスチェックを行う。少なくともいくつかの実施形態では、サーバチェック間隔は、前述のゴシップ間隔よりも大きいまたは等しくてよい。
少なくともいくつかの実施形態では、サーバノード130のヘルスチェックを行うために、健全なロードバランサノード110(例えば、図15のノード110A)は、サーバノード130(例えば、図15のサーバノード130A)へのヘルスピンメッセージ(例えば、L7 HTTPヘルスピンメッセージ)を開始する。健全である場合、サーバノード130は、ピン応答をロードバランサノード110に送り返す。少なくともいくつかの実施形態では、ピンメッセージは、サーバノード130のロードバランサモジュール132によって受け取られ、処理され、その結果成功すると、ヘルスチェックピンは、サーバノード130のモジュール132が健全であることを確立する。ピンに対する応答を受け取ると、ロードバランサノード110は、サーバノード130を健全であるとみなし、サーバノード130のためのハートビートカウンタをインクリメントする。
少なくともいくつかの実施形態では、所与に健全なロードバランサノード110によってヘルスチェックされた全てのサーバノード130のためのハートビートカウンタは、例えば各々のノード110がそのハートビートリストを少なくとも1つの他の無作為に選択されたノード110に一定の間隔(ゴシップ間隔)で送るロードバランサノード110のハートビートカウンタについて前述されたゴシップ技術に従って、他のロードバランサノード110に伝搬させることができ、受け取るノード110は、2つのリスト内の最大値に従ってそれ自身のハートビートリストを更新する。
障害検出及びゴシップ
少なくともいくつかの実施形態では、上述のロードバランサノード110のヘルスチェック及びサーバノード130のヘルスチェックを介して取得された情報は、ロードバランサ実現形態の全てのノード110に伝搬されることが必要となることがあり、その結果全てのロードバランサノード110は、ロードバランサ実現形態のコンシステントビューを維持することができる。上述のように、少なくともいくつかの実施形態では、ロードバランサノード110は、ゴシッププロトコルに従って互いに通信し、ヘルス情報を交換し、かつ伝搬し、またロードバランサノード110及びサーバノード130の障害を検出することができる。
少なくともいくつかの実施形態では、一定の間隔(ゴシップ間隔と呼ぶ)で、各々ロードバランサノード110は、別のロードバランサノード110を無作為に選択し、健全なロードバランサノード110及びサーバノード130のそのビューを、ロードバランサノード110及びサーバノード130のためのハートビートカウンタと共に、他のノード110に送る。ロードバランサノードまたはサーバノード130が健全である限り、ノードは、そのヘルスチェックを渡し、そのハートビートカウンタは増加し続ける。ノードのためのハートビートカウンタが指定された間隔(失敗時間間隔と呼ぶことができる)にわたって変わらない場合は、ノードは、ロードバランサノード110によって障害が発生したと疑われる。障害が発生しているとノードが一旦疑われると、ロードバランサノード110は、ノードが不健全であると決定する前に、指定された間隔(不健全時間間隔と呼ぶことができる)にわたって待機することができる。この不健全時間間隔は、全てのロードバランサノード110がノードに障害が発生したことを学習するまで、ロードバランサノード110が待機することを可能にする。
図16は、少なくともいくつかの実施形態に従って、ロードバランサノード110によって維持することができる別のノード(ロードバランサノード110またはサーバノード130のいずれか)のヘルスの状態、またはビューをグラフィカルに例示する。300に示されるように、対象となるノードが健全であるというビューでロードバランサノード110が始まることを想定する。これは、ノードのためのハートビートカウンタがインクリメントしていたことを示す。しかしながら、302に示されるように、ノードのハートビートカウンタが指定された間隔(失敗時間間隔)にわたって増加しない場合は、304に示されるように、ロードバランサノード110は、ノードに障害が発生したことを疑う。306に示されるように、ノードのハートビートカウンタが指定された間隔(不健全時間間隔)にわたって増加しない場合は、ロードバランサノード110は、308に示されるように、ノードを不健全であるとみなす。しかしながら、310に示されるように、ノードのためのハートビートカウンタが、不健全時間間隔が満了となる前に、インクリメントする場合、ロードバランサノード110は、300で、再びノードを健全であるとみなす。同様に、312に示されるように、不健全なノードのためのハートビートのインクリメントを受け取ると、300で、そのノードを健全であるとみなすことができる。
ノードが不健全であること決定することは、本明細書の他の箇所で説明されるが、不健全なノードがロードバランサノード110か、またはサーバノード130かに依存して、更に不健全なノードとのロードバランサノード110の関係に依存して、ロードバランサノード(複数可)110による異なる動作を含むことができる。
ロードバランサノードのデータ
少なくともいくつかの実施形態では、各々のロードバランサノード110は、ロードバランサ実現形態の状態に関するデータを維持することができる。少なくともいくつかの実施形態では、このデータは、限定されるものではないが、健全なロードバランサノードのリスト、疑わしいロードバランサノードのリスト、及びハートビートのリストを含み、各々ロードバランサノード110の1つ以上のデータ構造に維持することができる。図17は、健全なロードバランサノードのリスト320、疑わしいロードバランサノードのリスト322、不健全なロードバランサノードのリスト324、及びロードバランサノードハートビートのリスト326を維持する例となるロードバランサノード110を例示する。
少なくともいくつかの実施形態では、各々のロードバランサノード110は、健全なロードバランサノードのリスト320を維持することができ、それは、例えばどのノード110が健全であるか、したがってゴシッププロトコルに参加しているかを決定するために使用することができる健全なロードバランサノード110のリストである。リスト320にあるノード110のみが、ゴシッププロトコルを介するロードバランサ情報の伝搬に関与し、リスト320にあるノード110のみが、コンシステントハッシュリングに存在するとみなされ、このリストにあるノード110のみが、サーバノード130をヘルスチェックする。ノード110は、そのハートビート情報が送られる別のノード110をこのリスト320から無作為に選択することができる。更に、ハートビートカウンタは、健全なロードバランサノードのリスト320に現在あるノード110のためにのみ、交換される。少なくともいくつかの実施形態では、ロードバランサノードNは、ノードNがロードバランサノード110によるヘルスチェックに合格する場合、またはロードバランサノード110がノードNに関するゴシップメッセージをリスト320にある他のロードバランサノード110から受け取る場合、別のロードバランサノード110の健全なロードバランサノードのリスト320に追加することができる。
少なくともいくつかの実施形態では、各々のロードバランサノード110は、疑わしいロードバランサノードのリスト322を維持することができ、それは、ハートビートカウンタ(ハートビートリスト326を参照)が指定された間隔(失敗時間間隔と呼ばれる)にわたって増加しなかったロードバランサノードのリストである。ロードバランサノードEがロードバランサノード110の疑わしいロードバランサノードのリスト322にある場合は、ロードバランサノード110は、ノードEについてゴシップしない。健全なもののリスト320にある他のロードバランサノード110が、ノード110のハートビートリスト326にあるノードEのためのカウンタより高いハートビートカウンタで、ノードEについてロードバランサノード110にゴシップする場合は、ノードEは、疑わしいもののリスト322から健全なもののリスト320に移される。ノードEが、ロードバランサノード110の疑わしいもののリスト322に指定された間隔(不健全時間間隔と呼ばれる)にわたって留まる場合、ノードEは、ロードバランサノード110によって不健全であるとみなされ、不健全なノードのリスト324に移される。不健全なノードのリスト324にあるノード110(この実施例では、ノードG)は、ノードGがノード110によるヘルスチェックに合格すると、またはノードGのための更新されたハートビートカウンタを別のノード110から受け取ると、ロードバランサノード110の健全なノードのリスト320に移すことができる。
少なくともいくつかの実施形態では、各々のロードバランサノード110は、全ての既知のロードバランサノード110のためのハートビートリスト326を維持することができる。各々のノード、110について、このリスト326は、ハートビートカウンタ及びハートビートカウンタが最後に変更された時を示すタイムスタンプを含むことができる。
少なくともいくつかの実施形態では、各々のロードバランサノード110はまた、図17に示されないが、全ての既知のサーバノードのためのハートビートリストを維持することができる。このリストは、ロードバランサノードのハートビートリスト326と同様であってもよい。いくつかの実施形態では、二つのリストは組み合わせることができる。少なくともいくつかの実施形態では、サーバノード130についてのハートビート情報は、例えばゴシッププロトコルに従って、ロードバランサノード110についてのハートビート情報と共に、またはそれに加えて、ロードバランサノード110間に伝搬することができる。
図17は4つの分離したリストを示しているが、リストの2つ以上は、単一のリストに組み合わせることができることに留意されたい。例えば、いくつかの実施形態では、全てのノード110の単一のリストは、各々のロードバランサノード110に維持することができ、ビットフラグまたは他のデータ構造を使用し、各々のノードが現在健全であるか、疑わしいか、または不健全であるかどうかを示すことができる。
サーバノードのデータ
少なくともいくつかの実施形態では、サーバノード130及びノード130のローカルのロードバランサモジュール132は、ロードバランサノード110とのゴシッププロトコルに参加しない。ロードバランサノード110は、ロードバランサノードのヘルスチェック方法によって取得された他のロードバランサノード110に関するハートビート情報、及びサーバノードのヘルスチェック方法によって取得されたサーバノード130に関するハートビート情報を、それら自身の間のみにゴシップする(具体的には、各々のロードバランサノード110は、その健全なロードバランサノードのリスト320に現在あるノードのみにゴシップする)。
しかしながら、各々のサーバノード130/ロードバランサモジュール132は、ロードバランサ実現形態の健全なロードバランサノード110に関する情報を必要とすることができ、その結果サーバノード130は、サーバノード130が発信クライアントトラフィックを転送することができるロードバランサノード110(具体的には、出口ノード)を決定し、かつどのロードバランサノードに接続公開情報を送るべきかを決定することができる。少なくともいくつかの実施形態では、この情報をサーバノード130に提供するために、ロードバランサノード110は、現在健全であるロードバランサノード110(例えば、図17の健全なロードバランサノードのリスト320)を識別する情報でサーバノード130を周期的または非周期的に更新することができる。少なくともいくつかの実施形態では、所与のサーバノード130(図15を参照)ヘルスチェックすることを担当するロードバランサノード110は、現在健全であるロードバランサノードを識別する情報をサーバ130に提供することを担当する。例えば、図15を参照すると、ロードバランサノード110Aは、その健全なロードバランサノードのリスト320をサーバノード130A、130B、130C、及び130Dに送ることができ、ロードバランサノード110Bは、その健全なロードバランサノードのリスト320をサーバノード130C、130D、及び130Eに送ることができ、以降も同様である。
ロードバランサノードの障害の取り扱い
図18A及び18Bは、少なくともいくつかの実施形態に従って、ロードバランサノードの障害の取り扱いを例示する。図18Aは、例となるロードバランサ実現形態を示す。ロードバランサ実現形態には、現在4つのロードバランサノード110A〜110Dが存在する。エッジルータ104は、クライアント(図示せず)からの着信パケットをロードバランサノード110にルーティングする。少なくともいくつかの実施形態では、エッジルータ104は、層4のフロー毎ハッシュ化マルチパスルーティング技術、例えば等価コストマルチパス(ECMP)ルーティング技術に従って、ルーティング決定を行うことができる。少なくともいくつかの実施形態では、エッジルータ104は、ロードバランサノード110のアドバタイズメント、例えばロードバランサノード110によって開始されたボーダーゲートウェイプロトコル(BGP)技術セッションを介するアドバタイズメント、を介してクライアントトラフィックを受け取るためにロードバランサ実現形態で現在利用可能であるロードバランサノード110に関して学習する。しかしながら、少なくともいくつかの実施形態では、ロードバランサノード110がそれ自身をエッジルータ104にBGPセッションを介して広告する代わりに、ロードバランサ実現形態の少なくとも1つの他のノード110が、ノード110をエッジルータ104にBGPを介して広告することを担当する。例えば、図18Aに示されるようないくつかの実施形態では、所与のノード110の左及び右の近傍のノード110が所与のノード110をエッジルータ104に広告する。例えば、ロードバランサノード110Aは、ノード110B及び110Dを広告し、ロードバランサノード110Bは、ノード110A及び110Cを広告し、ロードバランサノード110Cは、ノード110B及び110Dを広告する。
図18Aの実施例に示されるように、各々のロードバランサノード110はまた、1つ以上の他のロードバランサノード110、例えば1つ以上の無作為に選択されたノード110、ロードバランサノードの順序付けリストによって決定されるような1つ以上の近傍のノード110、または1つ以上の近傍のノード及び1つ以上の無作為に選択されたノード、を周期的にヘルスチェックする。更に、各々のロードバランサノード110は、少なくとも1つのサーバノード130を周期的にヘルスチェックすることができ、更に健全なロードバランサノード110のそのリストを、それがヘルスチェックするサーバノード(複数可)に送ることができる。ロードバランサノード110及びサーバノード130に関するヘルス情報は、例えばゴシッププロトコルに従ってノード110間に伝搬することができる。
図18Bは、図18Aの例となるロードバランサ実現形態の単一のロードバランサノード110の障害の取り扱いを例示する。この例では、ロードバランサノード110Bが、ある理由で障害を発生している。例えば、ノード110A及び110Cは、ノード110Bをヘルスチェックし、その両方が、ノード110Bがそのヘルスチェックに不合格であることを検出することができる。したがって、ノード110A及び110Cは、ノード110Bのためのハートビートカウンタをインクリメントしない。ノード110A及び110Bの両方からのハートビート情報は、ゴシッププロトコルに従って、他の健全なロードバランサノード110(この実施例では、唯一の他のロードバランサノードはノード110Dである)に伝搬される。健全なロードバランサノード110(この実施例では、ノード110A、110C、及び110D)の全てがノード110Bの障害に収束するとすぐに、限定されるものではないが、以下のイベントのうちの1つ以上が起こることがある。これらのイベントは、この順序で必ずしも起こらないことに留意されたい。
・ノード110A及び110Cは、ノード110Bをエッジルータ104に広告することを停止する。少なくともいくつかの実施形態では、これは、ノード110がノード110Bを広告するためにエッジルータ104と確立したBGPセッションを終了させることを含む。各々のノード110は、それが広告する各々の他のノード110ための別々のBGPセッションをエッジルータ104と確立しているので、ノード110BのためのBGPセッションを終了させることは、広告される他のノード110に影響しないことに留意されたい。少なくともいくつかの実施形態では、ノード110は、BGPセッションのためのTCPクローズまたは同様のメッセージをエッジルータ104に送ることにより、エッジルータ104とのBGPセッションを終了する。
・ノード110Bが、もはやノードのいずれによっても広告されていないことの検出に応じて、エッジルータ104は、クライアントデータパケットをノード110Bにルーティングすることを停止する。エッジルータ104はまた、マルチパス(例えば、ECMP)ハッシングを調整し、クライアントからのパケットフローを残りの健全なロードバランサノード110へ、具体的にはノード110の入口サーバ112に再分配する。入口サーバ112がクライアント−>サーバのマッピングを有していない入口サーバ112にルーティングされる任意のパケットフローの場合、マッピングは、クライアント−>サーバの接続のためのフロートラッカーノードから取得することができ、またはあるいは、新規のクライアント−>サーバの接続が、図10A〜10Gに例示されたような技術に従って確立することができる。
・ノード110A及び110Cは、それぞれエッジルータ104へのBGPセッションを開き、互いに広告することができる。ノード110A及び110Cの両方が、ロードバランサノード110D並びにノード110Bによって、エッジルータ104に広告されるので、ノード110Bは、それに障害が発生したときに、ノード110A及び110Bをエッジルータ104に広告することを停止することがあるという事実によって、エッジルータ104がパケットをそれらの2つのノード110にルーティングすることを停止しないことに留意されたい。
・少なくともいくつかの実施形態では、ノード110A及び110Cは、それらが現時点で近傍のノード110になるので、互いをヘルスチェックすることを担当することができる。ノード110Bは、たとえ不健全であるとみなされても、他のノード110のうちの1つ以上によって依然として無作為にヘルスチェックすることができることに留意されたい。
・残りの健全なロードバランサノード110のうちの1つ以上は、以前にノード110Bによってフロー追跡された接続をフロー追跡することを担当することができる。例えば、ノード110C及び/またはノード110Dは、図11C及び11Dに示されるように、ノード110Bが1次または2次フロートラッカーであった1つ以上の接続のための1次または2次フロートラッカーを引き継ぐことができる。
・残りの健全なロードバランサノード110のうちの1つ以上は、以前にノード110Bによってヘルスチェックされたサーバノード130をヘルスチェックすることを担当することができる。サーバノード130は、残りのロードバランサノード110によって、健全なロードバランサノードのリスト(現時点で、ノード110Bを含まない)で更新される。例えば、図18Bでは、ロードバランサノード110Aは、サーバノード130Cのヘルスチェック及び更新を開始し、ロードバランサノード110Cは、サーバノード130Bのヘルスチェック及び更新を開始する。
・エッジルータ104では、障害が発生したノード110BからのBGPセッションが最終的にタイムアウトする。あるいは、エッジルータ104は、ノード110Bに障害が発生したことを認識すると、BGPセッションを終了することができる。
2つのロードバランサノード110に同時にまたはほぼ同時に障害が発生する場合があることも可能である。2つの障害が発生したロードバランサノードが互いに隣接していない場合は、障害は独立しており、図18Bに例示される方法に従って、別々の単一のノード110の障害として取り扱うことができる。しかしながら、2つの障害が発生したノードが互いに隣接する場合に(例えば、図18Aでは、ノード110B及び110C、すべての健全ロードバランサノード110(この実施例では、ノード110A及び110D)が障害を検出してそれに収束するとすぐに、限定されるものではないが、以下のイベントのうちの1つ以上が起こることができる。これらのイベントは、必ずしもこの順序で起こらないことに留意されたい。
・ノード110Aは、ノード110Bのためのエッジルータ104へのBGPセッションを終了する。
・ノード110Dは、ノード110Cのためのエッジルータ104へのBGPセッションを終了する。
・ノード110A及び110Dは、エッジルータ104とのBGPセッションを開始し、互いを広告する。
・ノード110A及び110Dは、互いをヘルスチェックすることを始める。ノード110A及び110Dはまた、障害が発生したノード110を継続してヘルスチェックすることに留意されたい。
・残りの健全なノード110は、健全なロードバランサノードのリストでサーバノード130を更新する。
・トラフィックは、エッジルータ104からノード110B及び/またはノード110Cに、これらの2つのノード110が継続して互いをエッジルータ104に広告することができるので、継続してフローすることができる。しかしながら、これらのBGPセッションは最終的にタイムアウトし、エッジルータ104は、相応にフローを残りの広告されたノード110に再分配する。
・ノード110B及び110Cは、それらがノード110A及び110Dを広告するエッジルータ104とのそれらのBGPセッションを、ノード110B及び110Cがそれらはまだ健全であると思う場合、閉じることができる。
接続公開
図1を再び参照すると、少なくともいくつかの実施形態では、ロードバランサ実現形態のロードバランサノード110は、サーバ130へのクライアントTCP接続のための状態情報を維持する。この状態情報は、ロードバランサノード110がエッジルータ104からの着信クライアントトラフィックを、TCP接続を担当するサーバノード130にルーティングすることを可能にする。サーバノード130のロードバランサモジュール132は、それらのそれぞれのサーバ134へのアクティブなTCP接続のリストを維持する。接続公開は、サーバノード130のロードバランサモジュール132がロードバランサノード110へのアクティブなクライアントTCP接続のそれらのリストを公開することができる機構である。少なくともいくつかの実施形態では、接続公開パケットは、接続公開間隔と呼ぶことができる一定の間隔でロードモジュール132によって、形成され、ロードバランサノード110に公開される。
少なくともいくつかの実施形態では、ロードバランサノード110によって維持される接続状態情報は、キャッシュの形態としてみることができ、特定の接続についての状態情報を維持することは、その接続ためのロードバランサノード110でリース期間を維持することとしてみることができる。キャッシュエントリが更新されない限り、ロードバランサノード110は、データフローを取り扱っているサーバノード130にクライアントデータフローをルーティングすることができないことがある。接続公開の機構は、ロードバランサノード110のキャッシュ、したがってリース期間を、サーバノード130からの現在の接続状態情報で周期的に更新し、それによってクライアント160から適切なサーバノード130へフローするTCPパケットを維持する。クライアント160がサーバ134へのTCP接続を終了すると、その接続に関連するサーバノード130のロードバランサモジュール132は、アクティブな接続のそのリストから接続をドロップし、したがってもはや接続公開機構を介してTCP接続を公開しない。したがって、その接続に関連するロードバランサノード110(具体的に、接続のための入口サーバ112並びに1次及び2次フロートラッカー116)のその接続に関する接続状態情報(1つまたは複数のキャッシュエントリ)は、もはや更新されることがなく、接続はロードバランサノード110によってドロップされる。少なくともいくつかの実施形態では、接続のためのキャッシュエントリまたはエントリ(複数)は、メモリが他のあるアクティブな接続に必要とされるまで、ロードバランサノード110のキャッシュに留まることができる。
したがって、接続公開の機構は、入口サーバ112並びに1次及び2次フロートラッカー116の接続リース期間を周期的または非周期的に延長し、クライアントトラフィックフローを維持する。更に、接続公開の機構は、少なくともいくつかのロードバランサノード110の障害からのリカバリに役立つことができる。クライアント接続に関する状態情報を保持する1つ以上のロードバランサノード110に障害が発生するとき、接続公開によって残りのロードバランサノード110に提供されるアクティブな接続情報は、いくつの場合では、接続をリカバリするために使用することができる。
接続公開の機構を使用すると、サーバノード130は、サーバ134とクライアント160との間の接続の状態のための信頼できるソースとなる。更に、サーバ134への接続を閉じることは、サーバノード130のロードバランサモジュール132及びロードバランサノード110によって受動的に取り扱われる。ハンドシェイクは、サーバノード130とロードバランサノード110との間に必要とされない。言い換えれば、ロードバランサモジュール132は、特定の接続が閉じられたことをノードに能動的に通知するために、メッセージをロードバランサノード110に送る必要がない。サーバ134が接続を閉じるとき、サーバ134は、接続に関するその内部状態をクリアする。ロードバランサモジュール132は、サーバ134の内部状態を使用し、接続公開パケットを取り込む。接続は、もはやサーバ134の内部状態に存在しないので、接続はロードバランサノード110に公開されない。したがって、ロードバランサノード110の接続のためのリース期間が満了し、ロードバランサノード110は、接続を受動的に忘れる。接続のために使用されたロードバランサノード110のキャッシュ内のメモリは、その後必要に応じて他の接続のために使用することができる。
いくつかの実施形態では、ロードバランサノード110によって維持される接続のためのリース期間は、キャッシュ内に接続のためのタイムスタンプのエントリを含むことができる。接続のリース期間が、接続公開パケットによって更新されると、タイムスタンプを更新することができる。接続がもはやサーバノード130のロードバランサモジュール132によって公開されていない理由により接続のリース期間が更新されない場合は、タイムスタンプはもはや更新されない。少なくともいくつかの実施形態では、接続のためのエントリが、メモリが必要となるまでキャッシュ内に留まることができるレイジーガベージコレクション方法を使用することができる。例えば、少なくともいくつかの実施形態では、キャッシュエントリのタイムスタンプは、リース期間更新時間閾値と比較することができ、キャッシュエントリのタイムスタンプが閾値よりも古い場合は、エントリは古くなっており、再利用することができる。しかしながら、いくつかの実施形態では、古くなっているエントリは、能動的にガベージコレクションすることができる。
接続公開受信者
少なくともいくつかの実施形態では、各々のクライアントTCP接続について、接続状態を維持する3つのロードバランサノード110、入口サーバ112として機能するノード110、1次フロートラッカー116として機能するノード110、及び2次フロートラッカー116として機能するノードが存在する。所与のTCPフローのために、1次及び2次フロートラッカー116は、例えばロードバランサノード110によって、コンシステントハッシュ関数をTCPフローに適用して1次フロートラッカー116ノード及びコンシステントハッシュリングのその後継ノードを見つけることにより、決定することができる。TCPフローのための入口サーバ112として機能するロードバランサノード110は、エッジルータ104の内部マルチパス(例えば、ECMP)ハッシュ関数に基づいてエッジルータ104からのそのフローのためのトラフィックを受け取るノード110である。ノード110の障害または追加が存在する場合、入口サーバ112として機能するロードバランサノード110は、アクティブなTCPフローの多くに対して変更されることがあり、少なくともいくつかのアクティブなTCPフローのためのフロートラッカーとして機能するロードバランサノード110は、変更されることがある(例えば、図11A〜11Dを参照)。サーバノード130のサーバ132への全てのTCPフローについて、そのサーバノード130のロードバランサモジュール132は、それがロードバランサノード110からトラフィックを受け取るので、ロードバランサノード110のうちのどれが、そのTCPフローのための入口サーバ112であるかを示す状態情報を維持する。しかしながら、少なくともいくつかの実施形態では、ロードバランサモジュール132は、使用されているコンシステントハッシュ関数を知らないことがあるので、ロードバランサモジュール132は、どのロードバランサノード110がTCPフローのための1次及び2次フロートラッカーとして機能しているかを知らないことがあり、決定できないことがある。言い換えれば、少なくともいくつかの実施形態では、ロードバランサモジュール132は、コンシステントハッシングを行わない。
アクティブな接続情報の公開
図19A及び19Bは、少なくともいくつかの実施形態に従って、接続公開技術をグラフィカルに例示する。図19Aは、アクティブな接続情報をロードバランサノードの公開するロードバランサ(LB)モジュールを例示する。少なくともいくつかの実施形態では、各々のロードバランサモジュール132は、サーバノード130上の各々のアクティブなTCPフローに関する情報を収集し、接続公開パケットを形成する。所与のTCPフローに関する情報は、フローのための入口サーバ112として機能するロードバランサノード110を識別する情報を含む。接続公開パケットの準備が完了すると(例えば、接続公開間隔に達すると)、ロードバランサモジュール132は、ロードバランサノード110を、例えば前述のようにサーバノード130をヘルスチェックするロードバランサノード110からサーバノード130に周期的に送られる健全なロードバランサノード110のリストから無作為に選択する。ロードバランサモジュール132は、次に、接続公開パケットを選択されたノード110に送る。例えば、図19Aでは、ロードバランサモジュール132Aは、1つの接続公開パケットをロードバランサノード110Aに送り、後に別の接続公開パケットをロードバランサノード110Bに送る。
図20は、少なくともいくつかの実施形態に従って、各々ロードバランサモジュール132によって行うことができる接続公開方法の高レベルのフローチャートである。500に示されるように、ロードバランサ(LB)モジュール132は、それぞれのサーバノード130上の全てのアクティブなTCPフローのための接続公開エントリを作成する。少なくともいくつかの実施形態では、ロードバランサモジュール132は、サーバノード130のサーバ134が取り扱うアクティブなTCP接続のセットを、例えばサーバノード130の/proc/net/tcpから取り出す。全てのアクティブなTCP接続について、ロードバランサモジュール132は、TCPフローのための入口サーバ112として機能するロードバランサノード110を検索し(例えば、アクティブな接続のローカルで維持されたテーブル内で)、接続のためのTCPタプル(例えば、クライアントIPアドレス、クライアントポート、サーバ(パブリック)IPアドレス、及びサーバポートからなる4タプル)及び接続のための入口サーバ112を示す接続公開エントリを作成する。各々のロードバランサモジュール132は、接続のためにパケットを受け取った最後のロードバランサノード110を示す各々のアクティブなTCP接続に関する情報を維持し、この情報は、ロードバランサモジュール132によって使用され、各々のアクティブな接続のための入口ノード110を識別することができることに留意されたい。
502に示されるように、ロードバランサモジュール132は、接続公開パケット(各々のアクティブなTCP接続のための1つのエントリとともに、1つ以上の接続公開エントリを含む)が送られるロードバランサノード110を無作為に選択する。少なくともいくつかの実施形態では、ロードバランサモジュール110は、ロードバランサモジュール132が、接続公開パケットが送られる準備が完了していることを決定すると、無作為に選択することができる。少なくともいくつかの実施形態では、この決定は、接続公開間隔に従って行われる。非限定的な実施例として、接続公開間隔は、100ミリ秒(ms)、または1秒であってもよい。少なくともいくつかの実施形態では、ロードバランサモジュール110は、以前にロードバランサノード110のうちの1つから受け取った健全なロードバランサノード110のリストから選択される。504では、ロードバランサモジュールは、次に、接続公開パケットを選択されたロードバランサノード110に公開する。少なくともいくつかの実施形態では、接続公開パケットは、ステートレスパケット、例えばUDPパケットである。いくつかの実施形態では、接続公開パケットは、パケットを対象となるロードバランサノード110に送る前に圧縮することができる。少なくともいくつかの実施形態では、接続公開情報は、2つ以上のパケットで、対象となるロードバランサノード110に送ることができる。
要素504から要素500に戻る矢印で示されるように、ロードバランサモジュール132は、連続して接続公開パケットを構築し、無作為のノード110を選択し、及びパケットを選択されたノードを送ることができる。上述のように、これは、接続公開間隔に従って行うことができ、その結果、ロードバランサノード110は、現在のアクティブな接続情報で比較的定期的に更新され、ロードバランサノード110上に接続リース期間を維持する。
少なくともいくつかの実施形態では、接続公開パケットは、ロードバランサモジュールによって、ロードバランサノード110に無作為に分配されるので、接続公開パケットを受け取るロードバランサノード110は、接続公開パケット内のアクティブな接続情報を接続のための正しい入口/1次/2次ノード110に分配することを担当する。図19B並びに図21及び22は、少なくともいくつかの実施形態で使用することができるアクティブな接続情報を分配するための方法を例示する。
図19Bは、少なくともいくつかの実施形態に従って、アクティブな接続情報をロードバランサノード110間に分配すること例示する。ロードバランサノード110が接続公開パケットをロードバランサモジュール132から受け取ると、ロードバランサノード110は、その中に示される各々のTCPフローのための情報を分析し、そのフローのための入口ノード並びに1次及び2次フロートラッカーノードを決定することができる。ロードバランサノード110は、フローのためのそれらの役割のうちの1つで機能し、ロードバランサノード110は、フローのための情報を消費する(例えば、状態情報のそのキャッシュを更新することにより)。少なくともいくつかの実施形態では、ロードバランサノード110はまた、フローのための情報をパケット(複数可)にいれて、フローのための他の役割で機能している1つ以上の他のノード110に送ることができる。接続公開パケットによって示される残りのフローについて、ロードバランサノード110は、アクティブな接続情報を2つ以上のより小さいパケットに分割し、各々のパケットを1つ以上の他のロードバランサノード110に送る。例えば、少なくともいくつかの実施形態では、1つ以上のフローのためのアクティブな接続情報を含むパケットは、フロー(複数可)のための入口サーバ112、1次フロートラッカー116A、及び2次フロートラッカー116Bとして機能しているロードバランサノード110に送ることができる。
図21は、少なくともいくつかの実施形態に従って、接続公開パケットで受け取ったアクティブな接続情報を対象となるロードバランサノード110に分配するための方法のフローチャートである。520に示されるように、ロードバランサノード110は、接続公開パケットをロードバランサモジュール132から受け取る。ロードバランサモジュール132は、例えば図19A及び20を参照して前述したように、パケットを生成し、パケットを受け取るロードバランサノード110を選択した。接続公開パケットは、パケットを受け取ったサーバノード130を識別する情報(例えば、サーバノード130のロードバランサモジュール132のIPアドレス)、及びアクティブなTCP接続を識別するエントリのリスト(例えば、各々の接続のためのクライアントIPアドレス、クライアントポート、サーバ(パブリック)IPアドレス、及びサーバポートからなる4タプル)を含み得る。
図21の要素522〜530では、ロードバランサモジュール110は、受け取った接続公開パケット内に示されるアクティブなTCP接続情報を反復して処理する。522に示されるように、ロードバランサノード110は、パケット内の次のTCPフローのためのエントリを分析し、それぞれのTCPフローのための入口ノード110並びに1次及び2次フロートラッカーノード110を決定する。少なくともいくつかの実施形態では、ロードバランサノード110は、接続公開エントリから入口ノード110の識別子を取得する。少なくともいくつかの実施形態では、TCPフローのための1次及び2次フロートラッカーノード110は、コンシステントハッシュ関数に従って決定することができる。524で、ロードバランサノード110が検査されるTCPフローのための役割のうちの1つで機能している場合、次に526で、ロードバランサノード110は、例えば状態情報のそのキャッシュを更新することにより、フローに関する情報を消費する。528に示されるように、ロードバランサノード110は、TCPフローのための接続公開エントリを、別のロードバランサノード110に送られる構築されるパケットに追加することができる。530で、接続公開パケットにフローのための更なる接続公開エントリが存在する場合は、方法は522に戻り、次のエントリを処理する。それ以外の場合、532に示されるように、ロードバランサノードは、オリジナルの接続公開パケットから接続公開エントリのサブセットをそれぞれが含む新規に構築されたパケット(複数可)を、パケットのための対象となるロードバランサノード110に送る。少なくともいくつかの実施形態では、対象となるロードバランサノード110に送られるパケットは、ステートレスパケット、例えばUDPパケットである。いくつかの実施形態では、パケットは、パケットを対象となるロードバランサノード110に送る前に圧縮することができる。
したがって、少なくともいくつかの実施形態では、図21の要素522〜528において、フロートラッカーノード110は、受け取った接続公開パケット内の接続公開エントリから522で決定された情報に従って、他のノード110のうちの特定の1つにそれぞれが送られる1つ以上のパケット(例えば、UDPパケット)を構築する。少なくともいくつかの実施形態では、別のノード110に送られるパケットは、対象となるノード110が入口ノード110、1次フロートラッカーノード110、または2次フロートラッカーノード110として機能するTCPフローのためのエントリを含む。いくつかの実施形態では、所与のロードバランサノード110は、TCPフローのための入口及び1次フロートラッカーノードの両方として、またはTCPフローのための入口及び2次フロートラッカーノードの両方として、機能することができることに留意されたい。
図22は、少なくともいくつかの実施形態に従って、接続公開パケットで受け取ったアクティブな接続情報を、対象となるロードバランサノード110に分配するための代替の方法を例示する。550に示されるように、ロードバランサノード110は、接続公開パケットをロードバランサモジュール132から受け取る。この方法では、552に示されるように、ロードバランサモジュール110でのプロセスは、パケット内の接続公開エントリを分析し、受け取ったパケットを1つ以上のより小さいパケットに相応に分割する。ロードバランサモジュール110は、このプロセスの間、フロー情報をローカルで消費しない。接続公開パケットが1つ以上のパケットに一旦分割されると、パケットは、次に、554〜560に示されるように処理される。554で、パケットのための対象となるノード110がこのロードバランサノード110である場合は、556で示されるように、ロードバランサノード110は、パケットをローカルで消費する。それ以外の場合、パケットは、対象となるロードバランサノード110に送られる。560で、処理すべき更なるパケットが存在する場合は、方法は554に戻る。それ以外の場合は、方法を終了する。
したがって、接続公開パケットをロードバランサモジュール132から受け取るロードバランサノード110は、接続公開パケットを、他のロードバランサノード110の内の特定のものに特有である2つ以上の小さいパケットに、分割し、パケットを相応に分配することができ、一方ロードバランサノード110によって現在取り扱われている任意のTCPフローに関するフロー情報を内部で消費する。その間、他のロードバランサノード110もまた、ロードバランサモジュール132から接続公開パケットを受け取り、接続公開エントリを複数のより小さいパケットに分割し、より小さいパケットを対象となるノード110に送り、アクティブな接続情報をノード110間に分配する。
接続公開始動
少なくともいくつかの実施形態では、接続公開は、1つ以上の異なるイベントによって、ロードバランサモジュール132で始動することができる。前述のように、いくつかの実施形態では、接続公開パケットは、接続公開間隔、例えば100msまたは1秒の間隔に従って、生成され、無作為に選択されたロードバランサノード110に送信され、ロードバランサノード110上のTCP接続のためのリース期間を更新することができる。いくつかの実施形態では、ロードバランサノード110のメンバーシップの変更は、即座の接続公開イベントを始動することができる。少なくともいくつかの実施形態では、ロードバランサモジュール132は、それぞれのサーバノード130をヘルスチェックするロードバランサノード110のうちの1つから送られた健全なロードバランサノード110のリストから変更について学習することができる。リストに従って変更(削除または追加のいずれか)を検出すると、ロードバランサモジュール132は、接続公開パケットを生成してロードバランサノード110に送ることができ、その結果、変更に影響されたTCP接続は、ロードバランサノード110によって、より迅速にリカバリすることができる。
パケットループの防止
接続公開パケットを処理している間に、ロードバランサ層のメンバーシップが変更される場合、接続公開パケットのループが起こることがある。第1のノード110は、ロードバランサモジュール132から接続公開パケットを受け取り、より小さいパケットを第2のノード110に送ることができる。しかしながら、メンバーシップが変更された場合、第2のノード110は、パケットは第1のノード110に行くべきであることを決定することができ、したがってパケットを第1のノード110に転送することができる。少なくともいくつかの実施形態では、このループが起こることを防止するために、ロードバランサモジュール132から受け取った接続公開パケット及びロードバランサノード110から受け取ったものに異なるポート番号を使用することができ、ロードバランサノード110は、他のロードバランサノード110から受け取った接続公開パケットを再分配しない。
接続公開パケット分配代替案
上述の接続公開方法では、ロードバランサモジュール132は、接続公開パケットが送られるロードバランサノード110を無作為に選択する。しかしながら、いくつかの実施形態では、他の方法を使用して、ロードバランサノード110を選択することができる。例えば、いくつかの実施形態では、ロードバランサノード132は、アクティブなTCPフローの1つ以上を取り扱う特定の入口ノード110をそれぞれが対象とする1つ以上の接続公開パケットを構築し、パケット(複数可)を対象となる入口ノード(複数可)110に送ることができる。入口ノード(複数可)110は、次に、アクティブな接続情報を接続のための1次及び2次フロートラッカーに再分配することができる。別の実施例として、いくつかの実施形態では、接続公開パケットを単一の無作為に選択されたノード110に送る代わりに、各々の接続公開パケットは、ロードバランサモジュール132によって、健全なノード110のうちの2つ以上に、または健全なノード110の全てに、送ることができる。
ロードバランサノードアーキテクチャ
図23は、少なくともいくつかの実施形態に従うロードバランサノード110のための例となるソフトウェアスタックアーキテクチャを例示し、限定することを意図しない。この例となるソフトウェアスタックアーキテクチャでは、ロードバランサノード110は、ロードバランササーバネイティブコード1106及びコアパケット処理コード1108、例えばIntel(商標)Dataplane Development Kit(DPDK)テクノロジーコード、を含むことができるネイティブコードの層を管理するために、Java Native Interface(JNI(商標))1104テクノロジーを使用する単一のJava(商標)テクノロジープロセス1102で実行される。ネイティブコードは、2つのネットワークインターフェースコントローラ(NIC1114A及び1114B)にインターフェースすることができる。第1のNIC(NIC1114A)は、「ノース」、すなわちエッジルータ104の方向に面することができる。第2のNIC(NIC1114B)は、「サウス」、すなわちサーバノード130の方向に面することができる。少なくともいくつかの実施形態では、NIC1114A及び1114Bは、TCPスタックを維持しなくてもよい。したがって、少なくともいくつかの実施形態は、TCP接続をサポートする第3のNIC1114Cを含むことができ、その結果、ロードバランサノード110は、制御プレーンを介してプロセスと通信することができ、その逆も同様である。あるいは、いくつかの実施形態では、第1のノース側NIC1114A及び第2のサウス側NIC111Bのみが、ロードバランサノード110に実装することができ、第2のサウス側NIC1114Bは、ロードバランサノード110が制御プレーンを介してプロセスと通信することができるTCPスタックを実装することができる。ロードバランサノード110はまた、オペレーティングシステム(OS)テクノロジーソフトウェア1112、例えばLinux(商標)カーネル、OSテクノロジーソフトウェア1112の上部のJava Virtual Machine(JVM(商標))テクノロジーソフトウェア1110層、及びJNI1104テクノロジー0を含む。
少なくともいくつかの実施形態では、分散型ロードバランシングシステムのロードバランサノード110は、それぞれ高いパケットレートの多くのデータフローを同時に処理することが必要となることがある。少なくともいくつかの実施形態では、スループットの必要なレベルを達成するために、ロードバランサノード110は、高性能のパケット処理のために、Intel(商標)Dataplane Development Kit(DPDK)テクノロジーを活用することができる。DPDKテクノロジーは、ユーザー空間プログラムがパケットをネットワークインターフェースコントローラ(NIC)に及びそこから直接に読取/書込みすることを可能にし、またLinuxカーネルネットワーキングスタックの多くの層をバイパスする(Linus ixgbeベースNICドライバを除く)。パケット処理へのDPDKアプローチは、NICハードウェアをビジーループに直接にポーリングする専用CPUコアに有利なように割込みハンドラベース入力を拒否する。このアプローチは、専用CPUコアをビジーループで連続的に実行することによって熱出力を増加させることを犠牲にして、かなり高いパケットレートを可能にすることができる。DPDKテクノロジーはまた、CPUコア管理、ロックフリーキュー、メモリプール、及び同期基本命令を含むパケット処理のためのツールを提供する。図24に示されるように、DPDKテクノロジーでは、専用CPUコア600は、各々の特定のタスクのために使用することができ、ワークは、非ブロッキングキュー602を使用して、1つのCPUコア600Aから別のCPUコア600Bへ送られる。
DPDKキュー602は、高速の2のべき乗リングバッファを使用して実装することができ、単一及び複数のプロデューサ/コンシューマバリアントをサポートすることができる。複数のプロデューサ/コンシューマバリアントは、それらはアクセスを同期するためのコンペアアンドスワップ(CAS)ループを含むので、真にロックフリーではない。全てのパケットバッファメモリは事前にメモリプールに割り当てることができ、その結果バッファへのポインタのみがキュー602に対して読取及び書込みが行われる。メモリプールは、キューとして実装することができ、メモリをメモリチャネル及びランクにわたって分配するように最適化することができ、非均一メモリアクセス(NUMA)最適化割り当てをサポートすることができる。少なくともいくつかの実施形態では、パケットバッファは、各々パケットバッファに十分なヘッドルーム及びテールルームを過剰割当して、バッファコピーを必要とせずに外側ネットワーク層ヘッダを追加/除去することができるカプセル化/デカプセル化操作をサポートするMbufパラダイムのような方法を使用することができる。
ロードバランサノード110の少なくともいくつかの実施形態では、DPDKテクノロジーを活用するコアパケット処理アーキテクチャを実装することができる。各々のロードバランサノード110は、コアパケット処理アーキテクチャに従って実装された少なくとも1つのマルチコアパケットプロセッサを含むことができる。コアパケット処理アーキテクチャは、マルチコアパケットプロセッサのキュー及びコアを通るパケットフローのための単一のプロデューサ/単一のコンシューマパラダイムを使用することができる。このパラダイムでは、各々のキューは唯一のコアに入力し、各々のコアはそれがパケットを供給する互いのコアで唯一のコアに出力する。更に、マルチコアパケットプロセッサのコアによって使用されるメモリは共有されず、各々のコアはそれ自身の別々のメモリ領域を有する。したがって、コア間で共有するメモリまたはキューが存在せず、メモリまたはキューの競合が存在せず、所有権の要求(RFO)またはコンペアアンドスワップ(CAS)のようなメモリまたはキュー共有機構を必要としない。図25及び26は、コアパケット処理アーキテクチャに従って実装された例となるマルチコアパケットプロセッサを例示する。
図25は、少なくともいくつかの実施形態に従い、データフローを処理するためにDPDKテクノロジーを活用するコアパケット処理アーキテクチャに従って実装された例となるマルチコアパケットプロセッサを例示する。コアパケット処理アーキテクチャは、単一のプロデューサ/単一のコンシューマパラダイムに従って、マルチコアパケットプロセッサとして実装することができる。少なくともいくつかの実施形態では、図23に例示されるように、ロードバランサノード110は、各々2つのネットワークインターフェースコントローラ(NIC)、ボーダーネットワーク/エッジルータ104に面するノース側NIC1114A及び実稼働ネットワーク/サーバノード130に面するサウス側NIC1114Bを有する。少なくともいくつかの実施形態では、NIC1114は、10Gpbs NICであってよい。ロードバランサノード110を介してフローするパケットの大部分は、これらの2つのNICのうちの1つ(NIC114Aまたは1114Bのいずれか)で受け取られ、処理され(例えば、カプセル化またはデカプセル化)、及び他のNIC(NIC1114Bまたは1114Aのいずれか)に送信される。
図25を参照すると、少なくともいくつかの実施形態では、ロードバランサノード110は、各々NIC1114の2つのCPUコア、受信(RX)コア610、及び送信(TX)コア630をスピンアップする。ロードバランサノード110はまた、4つのワーカーコア620A〜620Dが使用されるこの実施例において、両方のNIC1114のためのパケットを処理する複数のワーカーコア620を両方向にスピンアップする。受信コア610は、着信パケットのバッチを、それらがNIC1114に到着するときにそれらの入力キューから読み取り、パケットを各々のパケットのためのワークのバルクを行うワーカーコア620に分配し、同時に各々の受信コア610はパケットを各々のワーカーコア620のためのそれぞれのワーカー入力キュー612に供給する。少なくともいくつかの実施形態では、受信コア610は、各々の着信パケットに層4「フローハッシュ」技術(前述のエッジルータ104によって使用することができるフロー毎ハッシュ化マルチパスルーティング技術と同様である)を行い、パケットをワーカーコア620に分配することができ、同時に任意の特定のクライアント接続(そのIPアドレス及びポートで区別される)は同じワーカーコア620によって処理されることを保証する。これは、各々のワーカーコア620は、パケットの同じサブセットを常に見て、ワーカーコア620によって管理される状態データに関する競合を除去することができ、その結果ロックを必要としない。受け取ったパケットへのポインタは、ワーカーコア620が新規の入力について連続して監視するワーカーキュー622にわたって分配することができる。ワーカーコア620は、各々の接続に関する状態(例えば、割り付けられたサーバノード130)を管理することを担当し、パケットをそれらのアウトバウンドキュー632に転送する前に、パケットにUDPカプセル化またはデカプセル化を行うことができる。送信コア630は、ワーカーコア620を通してアウトバウンドキュー632をサイクルし、それらがキュー632に現れるときに出力パケットをそれらの対応するNIC1114に書き込む。
図26は、少なくともいくつかの実施形態に従って、データフローを処理するためにDPDKテクノロジーを活用するコアパケット処理アーキテクチャに従って実装された別の例となるマルチコアパケットプロセッサを例示する。コアパケット処理アーキテクチャは、単一のプロデューサ/単一のコンシューマパラダイムに従って、マルチコアパケットプロセッサとして実装することができる。少なくともいくつかの実施形態では、高スループットのクライアントTCPフローを処理することに加えて、ロードバランサノード110のDPDKコアアーキテクチャはまた、ARP、DHCP、及びBGPのような他のプロトコルのためのノース及びサウス側NIC1114でパケットを送り、受け取るために使用することができる。図26に示される実施形態では、ワーカーコア620Aは、それらの他のプロトコルのためのパケットを取り扱うことに専用される。このワーカーコア620Aは、これらのパケットの処理が概してクライアントTCPフローより遅いレートで起こるので、「低速」ワーカーコアと呼ぶことができ、一方クライアントTCPフローのみを処理する他のワーカーコア620B〜620Dは、高速ワーカーコアと呼ぶことができる。ノース側及びサウス側NIC1114でそれぞれ着信パケットを取り扱う受信コア610A及び610Bは、低速ワーカーコア620Aによって取り扱われるパケットを識別し、パケットを低速ワーカーコア620Aのための入力キュー622に向けることができる。低速ワーカーコア620Aはまた、Java/JNIによって生成されたパケットのための入力キュー622、及びJava/JNIへの出力パケットのための出力キュー634を監視することができる。低速ワーカーコア620Aはまた、高速ワーカーコア620B〜620Dの各々のための入力キュー622へ出力し、その結果低速ワーカーコア620Aは、パケット、例えば接続公開パケットを、高速ワーカーコア620B〜620Dの各々に送ることができる。低速ワーカーコア620Aはまた、送信コア630A及び630Bの各々に供給されるアウトバウンドキュー632を有する。
少なくともいくつかの実施形態では、各々の高速ワーカーコア620B〜620Dの第3の入力キュー622は、低速ワーカーコア620Aからの出力キューである。少なくともいくつかの実施形態では、第3の入力キュー622は、例えば、接続状態情報を各々含む接続公開パケットを、高速ワーカーキュー620B〜620Dによって、受け取り、処理するために使用することができる。これらの接続公開パケットの少なくともいくつかについて、送信コア630への出力が存在しなくてもよい。その代りに、パケット内の接続状態情報は、高速ワーカーコア620によって、例えばそれぞれの高速ワーカーコア620が維持する1つ以上のパケットフローに関する格納された状態を更新することによって、消費することができる。したがって、高速ワーカーコア620B〜620Dに入力される低速ワーカーコア620Aからの出力キューは、高速ワーカーコアの格納された状態を更新するために受信コア610から直接の入力キュー622以外のパスを提供することができる。
少なくともいくつかの実施形態では、図25及び26のマルチコアパケットプロセッサは、着信パケットをフィルター処理し、有効であるパケットのみを処理し、出力することができる。例えば、少なくともいくつかの実施形態では、受信コア610は、ワーカーコア620の何れによってもサポートされていないプロトコルであるパケットを除外し、したがってパケットをワーカーコア620に送らなくてよい。少なくともいくつかの実施形態では、ワーカーコア620は、パケットを処理するとき、各々最初に、それらのそれぞれのワーカー入力キュー622から読み取られたパケットを分析し、パケットを更なる処理のために受け入れて送信コア630に出力すべきかを決定することができ、受け入れられたパケットのみの処理及び送信コア630への出力を完了することができ、受け入れられなかったパケットは廃棄することができる。例えば、ワーカーコア620は、各々のパケットに関するアドレス情報を見て、ロードバランス化される有効なアドレスに向けられたパケットのみを受け入れることができ、一切の他のパケットを廃棄する。
ボーダーゲートウェイプロトコル(BGP)データの取り扱い
少なくともいくつかの実施形態では、コアアーキテクチャに出入するBGPクライアントに関連するパケットフローは、以下のように取り扱うことができる。NIC1114A及び1114Bは、Linuxカーネルに向けられていないので、エッジルータ104へのTCP接続は、図26で例示されるようにコアアーキテクチャによって傍受され、低速ワーカーコア622Aによって処理され、それはBGPパケットを、出力キュー634を介してJava空間内に送り込む。これらのTCPパケットは、BGPクライアントに配信される前に、TCP接続を管理し、パケットをTCPストリームに効果的に変換するためにLinuxカーネルによる処理を含めて、ロードバランサノード110の1つ以上のモジュールによって更に処理される。この設計は、BGPクライアントが標準のJava TCPソケットライブラリを使用して書き込まれるのを可能にする。
図27は、少なくともいくつかの実施形態に従って、ロードバランサ(LB)ノードプロセス650による着信BGP TCPパケットの処理を例示する。エッジルータ104からのパケットは、ノース側NIC640に到着し、受信コア652のための入力キュー640に入る。受信コア652は、キュー640からパケットを読み取り、パケットをBGPパケットとして識別すると、パケットを低速ワーカーコア656のための入力キュー654に置く。低速ワーカーコア656は、パケットを検証し、それをJNI出力キュー658に置く。JNIパケットレシーバ660は、JNIを介してキュー658からパケットを読み取り、送信元/送信先アドレスをマングリングし、パケットを生のソケット644に書き込む。Linuxカーネル646は、生のパケットを受け取り、それをTCPプロトコルに従って取り扱い、ペイロードデータをTCPソケットInputStreamに追加する。パケットからのデータは、次に、BGPクライアント662のJava TCPソケットに配信される。
図28は、少なくともいくつかの実施形態に従って、ロードバランサ(LB)ノードプロセス650による発信BGP TCPパケットの処理を例示する。BGPクライアント662は、データをLinuxカーネル646のJava TCPソケットに書き込む。Linuxカーネル646は、データをTCPプロトコルに従って取り扱い、データをTCPパケット(複数可)に変換する。少なくともいくつかの実施形態では、TCPパケット(複数可)は、127.x.x.x iptaples規則に適合する。TCPパケット(複数可)は、出力キュー648、例えばNetfilter LOCAL_OUTキューに置かれる。JNIを介してキュー648を監視するJNIパケットレシーバ670のJavaスレッドは、TCPパケット(複数可)を受け取り、各々のNF_STOLENにマークしてカーネル646にそれらのことを忘れさせる。Javaスレッドは、送信元/送信先アドレスをマングリングし、パケット(複数可)を、JNIを介して低速ワーカーコア656のためのJNI入力キュー672に追加する。低速ワーカーコア656は、TCPパケット(複数可)をそのJNI入力キュー672から受け取り、パケットをノース側NIC640送信コア666のためのアウトバウンドキュー664に置く。送信コア666は、TCPパケット(複数可)をその入力キュー664から読み取り、それらをノース側NIC640に書き込む。TCPパケットは、NIC640によってエッジルータに送られる。
分散型ロードバランサのシミュレーション及びテスト
本明細書の記載のロードバランサは、多くの独立した構成要素(例えば、ルータ、ロードバランサノード、ロードバランサモジュールなど)の相互作用を必要とする分散型システムである。分散型構成要素、論理、及びプロトコルのテストを行うために、並びにノード障害、メッセージドロップ、及び遅延のようなシナリオをシミュレートするために、複雑なネットワークトポロジ(例えば、実稼働ネットワーク)の複数のホストにコードを展開することを必要とせずに、相互作用をテストすることができる単一のプロセスで分散型ロードバランサを実行させることを可能にするテストシステムの実施形態を説明する。これを達成するために、複数のロードバランサの構成要素が単一のプロセスでまたはそれとして構成され、実行されることを可能にするメッセージバスと呼ばれるソフトウェア機構を説明し、単一のプロセスは単一のホストシステムで実行することができる。メッセージバス機構は、分散型ロードバランサシステムが単一のプロセスとして、例えば単一のホストシステムでテストされることを可能にし、一方ロードバランサの構成要素(ロードバランサノード及びロードバランサモジュール)に対して、それらは実際の実稼働ネットワークで実行されているように見える。
メッセージバスは、分散型ロードバランサが単一のプロセスとして実行されることを可能にするフレームワークを提供する。プロセス内の1つ以上のメッセージバス層の各々は、分散型ロードバランサの構成要素間でネットワーク(例えば、イーサネット(登録商標))セグメントをシミュレートする。分散型ロードバランサシステムのソフトウェア構成要素は、特別の様式で書き込む必要がなく、構成要素がメッセージバス環境内で動作することを可能にする。その代りに、メッセージバスフレームワークは、分散型ロードバランサシステムの構成要素が生成するパケットを傍受し、パケットを、実際の物理的ネットワークの代わりに、メッセージバス層によって提供されるシミュレートされたネットワークに向け、パケットを対象となる構成要素に配信する構成要素(メッセージバスNICまたはパケットアダプタと呼ぶことができる)を提供する。メッセージバス層は、構成要素間の通信のためのTCP/IPスタック(複数可)を実装しない。その代りに、メッセージバス層は、ホストシステムのオペレーティングシステム(OS)とインターフェースし、ホストシステムのTCP/IPスタックを使用する。メッセージバス層は、OSによって提供されるTCP/IPスタックを活用し、クライアント及びサーバが、メッセージバスが傍受し、配信する個別のパケットに対して及びそこから期待するようにTCPストリームを変換する。
少なくともいくつかの実施形態では、メッセージバスとインターフェースするために、ロードバランサの構成要素は、有効なメディアアクセス制御(MAC)アドレスを各々が有する少なくとも1つのメッセージバスネットワークインターフェースコントローラ(NIC)を備え、それは、物理的ネットワークとの送受の代わりにメッセージバスシミュレートされたネットワーク環境へパケットを送り、そこからパケットを受け取る。メッセージバスNICは、物理的ネットワークの代わりにメッセージバスに取り付けられる仮想ネットワークインターフェースコントローラである。メッセージバスを介して通信する必要がある各々のロードバランサの構成要素は、少なくとも1つのメッセージバスNICを必要とする。メッセージバスNICは、メッセージバスへの出パイプライン出口として、及び構成要素へのパイプライン入口として機能する。構成要素は、各々のメッセージバスNICへの複数のメッセージバスネットワークインターフェースをインスタンス化することができる。
メッセージバスネットワークインターフェースは、構成要素を、メッセージバスNICを介してメッセージバスに取り付けるための機構である。メッセージバスネットワークインターフェースは、Linuxテクノロジーのインターフェース構成(ifconfig)インターフェースと同義であることができるが、メッセージバスネットワークインターフェースは、物理的ネットワークの代わりにメッセージバスに取り付けられるという違いがある。メッセージバスネットワークインターフェースは、IPアドレスを有し、メッセージバスNICの上部に位置する。メッセージバスネットワークインターフェースは、メッセージバスからパケット受け取るために構成要素が使用することができるパケットソースインターフェースと、メッセージバスにパケットを送るために構成要素が使用することができるパケットシンクインターフェースと、を公開する。
各々のロードバランサノードは、パケットソース及びパケットシンクインターフェースの実現形態を介して配信され、送られる個別のネットワークパケットを処理する。メッセージバス環境で実行されると、これらのインターフェースは、層2イーサネットヘッダーを追加または除去するメッセージバスネットワークインターフェースによって実装される(これがカーネルネットワークスタックによって行われることを期待するロードバランサノードのために)。図29に示されるような実稼働環境では、パケットソース及びパケットシンクインターフェースの実現形態は、実際のネットワークインターフェース上のパケットを受信し、送信する。図30に示されるようなメッセージバス環境では、パケットソース及びパケットシンクインターフェースの実現形態は、メッセージバス層または層(複数)からパケットを受信し、そこへパケットを送信する。
簡略化のために、メッセージバスNIC及びメッセージバスインターフェースは、集合的にメッセージバスパケットアダプタ、または単にパケットアダプタと呼ぶことができる。例えば、図31及び32を参照。
図29は、少なくともいくつかの実施形態に従って、実稼働環境に分散型ロードバランサ700を含むロードバランシングシステムを例示する。ロードバランサ700は、この説明のための単純化された。ロードバランサ700は、ロードバランサ700を実装するデータセンタのようなネットワーク設備のボーダールータ702を介して外部ネットワーク740上のクライアント742に接続することができる。ロードバランサ700は、複数のタイプの構成要素、少なくとも1つのエッジルータ704、2つ以上のロードバランサ(LB)ノード710、各々が別々のサーバノード(図示なし)に実装された2つ以上のロードバランサ(LB)モジュール732、ルータまたはスイッチのようなファブリック720を形成する1つ以上のネットワーキング構成要素、及び少なくともいくつかの実施形態では、構成サービス722を含む。少なくともいくつかの実施形態では、ロードバランサ700の各々の構成要素は、汎用ラックマウント型コンピューティングデバイスのような分離したコンピューティングデバイスとして、またはその上に実装することができる。
図30は、少なくともいくつかの実施形態に従って、複数の分散型ロードバランシングシステムの構成要素が、単一のプロセスで、またはそれとして構成され、実行されることを可能にするメッセージバス機構を組み込む分散型ロードバランサテストシステム800を例示する。図29に示されるロードバランサ700では、各々のロードバランサソフトウェア構成要素は、別々のコンピューティングデバイスに組み込まれ、実行される(例えば、ロードバランサノード710上のロードバランサソフトウェア及びサーバノード上のロードバランサモジュール732)。これらのロードバランサソフトウェア構成要素が単一のプロセスで実行されることを可能にするために、各々のロードバランサソフトウェア構成要素(図30にロードバランサ「LB」ノード810及びロードバランサ(LB)モジュール832として示される)は、構成要素のネットワーク接続を抽象化するコードを含むことができ、その結果ロードバランサソフトウェア構成要素に出入するパケットはまた、物理的ネットワーク上で送受される代わりに、メッセージバス機構を介して傍受され、ルーティングすることができる。
少なくともいくつかの実施形態では、分散型ロードバランサテストシステム800において、メッセージバス機構は、構成要素間の通信のためのTCPスタック(複数可)を実装しない。その代りに、メッセージバス機構は、ホストシステムのオペレーティングシステム(OS)とインターフェースし、ホストシステムのTCPスタックを使用する。少なくともいくつかの実施形態では、メッセージバス機能は、IPテーブル、カーネルの機能を介して、ユーザー層の下のホストシステムのOSのカーネル(例えば、Linuxカーネル)に結合される。メッセージバス機能は、カーネルレベルでIPテーブルに接続し、パケットを傍受し、パケットをルーティングのためにメッセージバスプロセスに送り込む。
図30のシミュレートされたエッジルータ862及びシミュレートされたファブリック864によって示されるように、物理的ネットワーク構成要素(例えば、図29のエッジルータ704及びファブリック720)の機能は、ソフトウェアでシミュレートすることができ、クライアント860、サーバ834、及び構成サービス866も同様に可能である。しかしながら、少なくともいくつかの実施形態では、シミュレートされたものではない実際のサーバ834を分散型ロードバランサテストシステム800で使用することもできることに留意されたい。図30のメッセージバス層850は、物理的ネットワークインフラストラクチャと交換する。したがって、ロードバランサソフトウェア構成要素(ロードバランサノード810及びロードバランサモジュール832)は、図29に示されるような実稼働ネットワーク環境でそれらが実行されていないことを意識しないまま、ロードバランサテストシステム800で実行することができる。
いくつかの構成要素(例えば、シミュレートされたルータ)は、ネットワークセグメントをシミュレートする異なるメッセージバス層850へパケットを送り、そこからパケットを受け取るために、1つよりも多くのメッセージバス層850に接続することができる。
分散型ロードバランシングテストシステム800のメッセージバス層850に実装されたメッセージバス機構は、ネットワークセグメントの「ワイヤー」をシミュレートする。少なくともいくつかの実施形態では、メッセージバス機構は、構成要素のMACアドレスに基づいて、分散型ロードバランシングテストシステム800の送信先構成要素へパケットを配信する。したがって、各々ロードバランサソフトウェア構成要素(ロードバランサノード810及びロードバランサモジュール832)は、MACアドレスをそれが接続されたメッセージバス層(複数可)850に提供し、その結果ロードバランサソフトウェア構成要素は、分散型ロードバランシングテストシステム800の他の構成要素からそれに送られたパケットを受け取ることができる。
メッセージバスパケットアダプタ
図31及び32は、少なくともいくつかの実施形態に従って、メッセージバスパケットアダプタを例示する。少なくともいくつかの実施形態では、各々のロードバランサ(LB)ソフトウェア構成要素は、パケットソース及びパケットシンクインターフェースの実現形態を介して配信され、送られた個別のネットワークパケットを処理する。図31を参照すると、分散型ロードバランシングテストシステム800で実行されると、それらのインターフェース(パケットソースインターフェース862及びパケットシンクインターフェース864として示される)は、メッセージバス層850とロードバランサソフトウェア構成要素860との間にあって、これがカーネルネットワークスタックによって行われることを期待するロードバランサソフトウェア構成要素870のための層2イーサネットヘッダーを追加または除去するパケットアダプタ870によって実装することができる。図29に例示されるような実稼働環境では、ロードバランサソフトウェア構成要素のためのパケットソース及びパケットシンクの実現形態は、構成要素が実装される物理的デバイスの実際のネットワークインターフェース上でパケットを受け取り、送信する。
図31を参照すると、少なくともいくつかの実施形態では、ロードバランサソフトウェア構成要素870がパケットを送信すると、パケットシンクインターフェース864の送信パケット方法をコールする実行のスレッドは、パケットアダプタ860内及び更にメッセージバス層850内の機能のチェーンを横切り、パケットをその構成要素の入力キューに追加することにより、パケットを最終的に送信先構成要素に配信する。少なくともいくつかの実施形態では、ロードバランサソフトウェア構成要素870がパケットを受け取ると、ロードバランサソフトウェア構成要素870は、パケットソースインターフェース862の受信パケット方法をコールし、その入力キューからパケットを読み取る。少なくともいくつかの実施形態では、メッセージバス機構は、パケットを配信するためにそれ自身の一切の追加のスレッドを必要としない。
メッセージパケットパイプライン
図32を参照すると、少なくともいくつかの実施形態では、パケットソースインターフェース862及びパケットシンクインターフェース864のメッセージバス850側は、パケットパイプライン機能を提供する。ロードバランサソフトウェア構成要素870が、パケットシンクインターフェース864を介してパケットを送ると、パケットデータは、メッセージバス層850に達する前に、一連のステージ(パケットパイプライン880)を横切ることができる。これらのステージは、パケットを変調し、パケットをドロップし、パケットを複製し、パケットを遅延することなどができる。一旦パケットがパケットパイプライン880を横切ると、メッセージバス層850は送信先構成要素870を選択し、送信先構成要素870に関連付けられた第2の一連のパイプラインステージ(パケットパイプライン882)はまた、パケットが送信先構成要素870の入力キューに追加される前に、横切られることができる。
例となるプロバイダネットワーク環境
このセクションは、分散型ロードバランシング方法及び装置の実施形態を実装することができる例となるプロバイダネットワーク環境を説明する。しかしながら、これらの例となるプロバイダネットワーク環境は限定することを意図しない。
図33Aは、少なくともいくつかの実施形態に従って、例となるプロバイダネットワーク環境を例示する。プロバイダネットワーク1900は、限定するものではないが、1つ以上のデータセンタのプロバイダネットワークまたはネットワーク(複数)内のデバイス上に実装される計算及びストレージリソースを含めて、クライアントが仮想化リソースのインスタンス1912にアクセス、購入、賃貸、またはそうでなければ取得することを可能にする1つ以上の仮想化サービス1910を介してクライアントにリソース仮想化を提供することができる。プライベートIPアドレス1916は、リソースインスタンス1912に関連付けることができ、プライベートIPアドレスは、プロバイダネットワーク1900上のリソースインスタンス1912の内部ネットワークアドレスである。いくつかの実施形態では、プロバイダネットワーク1900はまた、クライアントがプロバイダ1900から取得することができるパブリックIPアドレス1914及び/またはパブリックIPアドレス範囲(例えば、インターネットプロトコルバージョン4(IPv4)またはインターネットプロトコルバージョン6(IPv6)アドレス)を提供することができる。
従来、プロバイダネットワーク1900は、仮想化サービス1910を介して、サービスプロバイダのクライアント(例えば、クライアントネットワーク1950Aを操作するクライアント)がクライアントに割り付けられたまたは割り当てられた少なくともいくつかのパブリックIPアドレス1914をクライアントに割り付けられた特定のリソースインスタンス1912に動的に関連付けることを可能にすることができる。プロバイダネットワーク1900はまた、クライアントが以前にクライアントに割り当てられた1つの仮想化コンピューティングリソースインスタンス1912にマッピングされたパブリックIPアドレス1914を、クライアントに別に割り当てられた別の仮想化コンピューティングリソースインスタンス1912に再マッピングすることを可能にする。サービスプロバイダによって提供された仮想化コンピューティングリソースインスタンス1912及びパブリックIPアドレス1914を使用し、クライアントネットワーク1950Aのようなサービスプロバイダのクライアントは、例えば、クライアント固有アプリケーションを実装し、クライアントアプリケーションをインターネットのような中間ネットワーク1940に提示することができる。中間ネットワーク1940上の他のネットワークエンティティ1920は、次に、クライアントネットワーク1950Aによって発行された送信先パブリックIPアドレス1914へのトラフィックを生成することができ、トラフィックは、サービスプロバイダデータセンタにルーティングされ、データセンタでは、ネットワーク基板を介して、送信先パブリックIPアドレス1914に現在マッピングされた仮想化コンピューティングリソースインスタンス1912のプライベートIPアドレス1916に、ルーティングされる。同様に、仮想化コンピューティングリソースインスタンス1912からの応答トラフィックは、ネットワーク基板を介して中間ネットワーク1940へ返されて送信元エンティティ1920にルーティングすることができる。
プライベートIPアドレスは、本明細書で使用される場合、プロバイダネットワークのリソースインスタンスの内部ネットワークアドレスを指す。プライベートIPアドレスは、プロバイダネットワーク内のみでルーティング可能である。プロバイダネットワークの外部から発信されるネットワークトラフィックは、プライベートIPアドレスに直接にルーティングされず、その代りに、トラフィックは、リソースインスタンスにマッピングされたパブリックIPアドレスを使用する。プロバイダネットワークは、パブリックIPアドレスからプライベートIPアドレスに、及びその逆にマッピングを行うために、ネットワークアドレストランスレーション(NAT)または同様の機能を提供するネットワークデバイスまたは装置を含むことができる。
パブリックIPアドレスは、本明細書で使用される場合、サービスプロバイダによってか、またはクライアントによってかのいずれかで、リソースインスタンスに割り付けられたインターネットルーティング可能であるネットワークアドレスである。パブリックIPアドレスにルーティングされるトラフィックは、例えば1:1ネットワークアドレストランスレーション(NAT)を介して変換され、リソースインスタンスのそれぞれのプライベートIPアドレスに転送される。
いくつかのパブリックIPアドレスは、プロバイダネットワークインフラストラクチャによって、特定のリソースインスタンスに割り付けることができ、それらのパブリックIPアドレスは、標準パブリックIPアドレス、または単に標準IPアドレスと呼ぶことができる。少なくともいくつかの実施形態では、リソースインスタンスのプライベートIPアドレスへの標準のIPアドレスのマッピングは、全てのリソースインスタンスタイプに対してデフォルト起動構成である。
少なくともいくつかのパブリックIPアドレスは、プロバイダネットワーク1900のクライアントに割り当てられる、またはそれによって取得することができ、クライアントは、次に、それらの割り当てられたパブリックIPアドレスをクライアントに割り当てられた特定のリソースインスタンスに割り付けることができる。これらのパブリックIPアドレスは、クライアントパブリックIPアドレス、または単にクライアントIPアドレスと呼ぶことができる。標準IPアドレスの場合のようにプロバイダネットワーク1900によってリソースインスタンスに割り付ける代わりに、クライアントIPアドレスは、リソースインスタンスに、クライアントによって、例えばサービスプロバイダによって提供されるAPIを介して割り付けることができる。標準IPアドレスとは異なり、クライアントIPアドレスは、必要または所望に応じて、それぞれのクライアントによって、クライアントアカウントに割り当てられ、また他のリソースインスタンスに再マッピングすることができる。クライアントIPアドレスは、特定のリソースインスタンスではなく、クライアントのアカウントに関連付けられ、クライアントは、クライアントがそれを解放することを選ぶまで、そのIPアドレスを制御する。従来の静的IPアドレスとは異なり、クライアントIPアドレスは、クライアントのパブリックIPアドレスをクライアントのアカウントに関連付けられた全てのリソースインスタンスに再マッピングすることにより、クライアントがリソースインスタンスまたは利用可能ゾーン障害をマスクすることを可能にする。クライアントIPアドレスは、例えば、クライアントIPアドレスを交換用リソースインスタンスに再マッピングすることにより、クライアントがクライアントのリソースインスタンスまたはソフトウェアに伴う問題をエンジニアリングすることを可能にする。
図33Bは、少なくともいくつかの実施形態に従って、図33Aに示されるような例となるプロバイダネットワーク環境における分散型ロードバランサの実現形態を例示する。プロバイダネットワーク1900は、サービス1910、例えば仮想化ストレージサービスを、クライアント1960に提供することができる。クライアント1960は、サービス1910に、例えば1つ以上のAPIを介してサービス1910にアクセスし、プロバイダネットワーク1900の実稼働ネットワーク部分の複数のサーバノード1990に実装されたリソース(例えば、ストレージリソースまたは計算リソース)の使用を取得することができる。サーバノード1990は、それぞれサーバ(図示せず)、例えばウェブサーバまたはアプリケーションサーバ、並びにローカルのロードバランサ(LB)モジュール1992を実装することができる。1つ以上の分散型ロードバランサ1980は、ボーダーネットワークと実稼働ネットワークとの間のロードバランサ層に実装することができる。ボーダールータ(複数可)1970は、インターネットのような中間ネットワーク1940を介してクライアント1960からのパケットフロー内のパケット(例えば、TCPパケット)を受け取り、パケットを、ボーダーネットワークを介して分散型ロードバランサ(複数可)1980のエッジルータ(複数可)に転送することができる。パケットは、分散型ロードバランサ(複数可)1980のエッジルータ(複数可)によって発行されたパブリックIPアドレス(複数可)に向けられる。各々の分散型ロードバランサ1980のエッジルータは、パケットフローをそれぞれの分散型ロードバランサ1980のロードバランサノード間に分配することができる。少なくともいくつかの実施形態では、入口ノードとして機能する各々のロードバランサノードは、同じパブリックIPアドレスをエッジルータに広告し、エッジルータは、フロー毎ハッシュ化マルチパスルーティング技術、例えば等価コストマルチパス(ECMP)ハッシング技術に従って、クライアント1960からのパケットフローを入口サーバ間に分配する。ロードバランサノードは、本明細書に記載の接続プロトコルを使用して、パケットフローのための対象となるサーバノード1990を決定し、サーバとクライアント1960との間の接続を促進することができる。接続が一旦確立されると、入口ノードは、フローのために受け取ったパケットをカプセル化して対象となる実稼働ネットワーク上のサーバノード1990へ送り、その間フロートラッカーノードは、接続のための状態を維持する。サーバノード1990のロードバランサモジュール1992は、サーバノード1960のそれぞれのサーバが接続を受け入れたかどうかについて決定を行うことができる。ロードバランサモジュールは、入口ノードからのパケットを受け取ってデカプセル化し、デカプセル化パケット(例えば、TCPパケット)をサーバノード1990のそれぞれのサーバに送る。ロードバランサモジュール1992はまた、パケットフローのための出口ノードとしてのロードバランサノードを選択し、フローのための発信パケットをカプセル化し、実稼働ネットワークを介して選択された出口ノードに送る。出口ノードは、今度はパケットをデカプセル化し、デカプセル化パケットをそれぞれのクライアント1960への配信のためのボーダーネットワークに送る。
図34Aは、少なくともいくつかの実施形態に従って、分散型ロードバランサ及びサーバノードの例となる物理的ラック実現形態を例示するが、限定することを意図しない。少なくともいくつかの実施形態では、分散型ロードバランサの様々な構成要素は、汎用ラックマウント型コンピューティングデバイス上にまたはそれとして実装することができる。ラック190は、各々がロードバランサノード(LBノード110A〜110F)として機能する複数のコンピューティングデバイス、及び各々がサーバノード(サーバノード130A〜130L)として機能する複数のコンピューティングデバイスを含むことができる。ラック190はまた、少なくとも1つのエッジルータ104、ファブリック120を形成する1つ以上のラックマウント型ネットワーキングデバイス(ルータ、スイッチなど)、及び1つ以上の他の構成要素180(他のネットワーキングデバイス、パッチパネル、電源、冷却システム、バスなど)を含むことができる。データセンタまたは図33A及び33Bのプロバイダネットワーク1900を実装するセンタのようなネットワーク100設備は、1つ以上のラック190を含むことができる。
図34Bは、少なくともいくつかの実施形態に従って、分散型ロードバランサ及びサーバノードの別の例となる物理的ラック実現形態を例示するが、限定することを意図しない。図34Bは、ラック190内にスロットマウント型コンピューティングデバイス、例えばブレードサーバとして実装されたLBノード110及びサーバノード130を示す。
図35は、少なくともいくつかの実施形態に従って、1つ、2つ以上の分散型ロードバランサが、分離して実装されたサーバノードと共に、ネットワークに実装することができる例となるネットワーキング環境を例示する。この実施例では、2つの分散型ロードバランサ1980A及び1980Bが示される。分散型ロードバランサ1980は、各々クライアント1960からのパケットフローを、ボーダーネットワークを介して受け取り、本明細書に記載のロードバランシング方法を行い、パケットフローを複数のサーバノード1990に分配することができる。いくつかの実現形態では、各々の分散型ロードバランサ1980は、図34A及び34Bに示されるラック190と同様なラック型実現形態であることができるが、ロードバランサラックに組み込まれたサーバノードを備えない。サーバノード1990は、データセンタ内の1つ以上の別々のラックに組み込まれたブレードサーバのようなラックマウント型コンピューティングデバイスであってもよい。いくつかの実現形態では、サーバノード1990は、プロバイダネットワークによって提供される2つ以上の様々なサービスを実装することができ、各々のサービスは異なる1つ以上のロードバランサ1980を前段に備える。
例示のシステム
少なくともいくつかの実施形態では、本明細書に記載の分散型ロードバランシング方法及び装置の一部または全部を実装するサーバは、図36に例示されるコンピュータシステム2000のような1つ以上のコンピュータアクセス可能媒体を含む、またはそれにアクセスするように構成される汎用コンピュータシステムを含むことができる。例示の実施形態では、コンピュータシステム2000は、入力/出力(I/O)インターフェース2030を介してシステムメモリ2020の結合された1つ以上のプロセッサ2010を含む。コンピュータシステム2000は、I/Oインターフェース2030に結合されたネットワークインターフェース2040を更に含む。
様々な実施形態では、コンピュータシステム2000は、1つのプロセッサ2010を含むユニプロセッサシステム、またはいくつかのプロセッサ2010(例えば、2つ、4つ、8つ、または別の適切な数)を含むマルチプロセッサシステムであることができる。プロセッサ2010は、命令を実行できる任意の適切なプロセッサであることができる。例えば、様々な実施形態では、プロセッサ2010は、x86、PowrePC、SPARC、またはMIPS ISA若しくは任意の他の適切なISAのような様々な命令セットアーキテクチャ(ISA)のいずれかを実装する汎用または埋め込み型プロセッサであることができる。マルチプロセッサシステムでは、プロセッサ2010の各々は、一般的に、必ずしもではないが、同じISAを実装することができる。
システムメモリ2020は、プロセッサ(複数可)2010によってアクセス可能な命令及びデータを格納するように構成することができる。様々な実施形態では、システムメモリ2020は、スタティックランダムアクセスメモリ(SRAM)、同期ダイナミックRAM(SDRAM)、不揮発性/フラッシュ型メモリ、または任意の他のタイプのメモリのような任意の適切なメモリ技術を使用して実装することができる。例示された実施形態では、分散型ロードバランシング方法及び装置について上述したそれらの方法、技術、及びデータのような1つ以上の所望の機能を実装するプログラム命令及びデータは、システムメモリ2020内にコード2024及びデータ2026として格納されて示される。
一実施形態では、I/Oインターフェース2030は、プロセッサ2010、システムメモリ2020、及びネットワークインターフェース2040または他の周辺インターフェースを含むデバイス内の任意の周辺デバイス間でI/Oトラフィックを調整するように構成することができる。いくつかの実施形態では、I/Oインターフェース2030は、任意の必要なプロトコル、タイミング、または他のデータ変換を行い、1つの構成要素(例えば、システムメモリ2020)からのデータ信号を別の構成要素(例えば、プロセッサ2010)による使用に適するフォーマットに変換することができる。いくつかの実施形態では、I/Oインターフェース2030は、例えば周辺構成要素相互接続(PCI)バス規格、またはユニバーサルシリアルバス「USB」規格の変種のような様々なタイプの周辺バスを介して取り付けられたデバイスのためのサポートを含むことができる。いくつかの実施形態では、I/Oインターフェース2030の機能は、例えばノースブリッジ及びサウスブリッジのような2つ以上の別々の構成要素に分割することができる。更に、いくつかの実施形態では、システムメモリ2020へのインターフェースのようなI/Oインターフェース2030の機能は、プロセッサ2010に直接に組み込むことができる。
ネットワークインターフェース2040は、コンピュータシステム2000と例えば、図1〜35に例示されたような他のコンピュータシステムまたはデバイスのようなネットワークまたはネットワーク(複数)2050に取り付けられた他のデバイス2060との間で、データの交換を可能にするように構成することができる。様々な実施形態では、ネットワークインターフェース2040は、例えばイーサネットネットワークのタイプのような任意の適切な有線または無線汎用データネットワークを介する通信をサポートすることができる。更に、ネットワークインターフェース2040は、アナログ音声ネットワークまたはデジタルファイバ通信ネットワークのような通信/電話ネットワークを介する、ファイバチャネルSANのようなストレージエリアネットワークを介する、または任意の他の適切なタイプのネットワーク及び/若しくはプロトコルを介する、通信をサポートすることができる。
いくつかの実施形態では、システムメモリ2020は、分散型ロードバランシングシステムの実施形態を実装するために図1〜35について上述したプログラム命令及びデータを格納するように構成されたコンピュータアクセス可能媒体の一実施形態であることができる。しかしながら、他の実施形態では、プログラム命令及び/またはデータは、受け取られ、送信され、または異なるタイプのコンピュータアクセス可能媒体に格納することができる。一般的に、コンピュータアクセス可能媒体は、磁気または光学的媒体のような非一時的ストレージ媒体またはメモリ媒体、例えば、I/Oインターフェース2030を介してコンピュータシステム2000に結合されたディスクまたはDVD/CDを含むことができる。非一時的コンピュータアクセス可能ストレージ媒体はまた、RAM(例えば、SDRAM、DDR SDRAM、RDRAM、SRAMなど)、ROMなどのような任意の揮発性または不揮発性媒体を含むことができ、それらは、システムメモリ2020または別のタイプのメモリとしてコンピュータシステム2000のいくつかの実施形態に含めることができる。更に、コンピュータアクセス可能媒体は、ネットワークインターフェース2040を介して実装することができるようなネットワーク及び/または無線リンクのような通信媒体を介して搬送される電気的、電磁気的、またはデジタル信号のような伝送媒体または信号を含むことができる。
開示の実施形態は以下の付記の観点で説明することができる。
1.複数のロードバランサノードと、
各々がロードバランサモジュール及びサーバを実装する複数のサーバノードと、
1つ以上のクライアントからのパケットフローを複数のロードバランサノードに分散するように動作可能なルータと、を備え、
ロードバランサノードが、パケットフローを複数のロードバランサモジュールのうちの選択されたものに分散するように動作可能であり、
各々のロードバランサモジュールが、
1つ以上のパケットフロー内のロードバランサノードから受け取ったパケットを、それぞれのサーバノードのサーバに送ることであって、1つ以上のパケットフローの各々が、パケットフローのためにサーバと送信元クライアントとの間に確立された1つ以上の接続のうちの1つに対応する、送ることと、
1つ以上のアクティブな接続の各々に関する状態情報を、サーバから収集することと、
1つ以上のアクティブな接続に関する収集された状態情報を、接続公開パケットとして、複数のロードバランサノードのうちの少なくとも1つに公開することと、を行うように動作可能である、分散型ロードバランサシステム。
2.収集及び公開が、指定された間隔で行われる、付記1に記載の分散型ロードバランサシステム。
3.各々のロードバランサノードが、
接続公開パケットをロードバランサモジュールから受け取り、
接続公開パケット内の状態情報を有する各々の接続について、
接続に関する状態情報を分析し、状態情報に対応する1つ以上の対象となるロードバランサノードを決定し、かつ
接続に関する状態情報を決定された1つ以上の対象となるロードバランサノードに転送するように、更に動作可能である、付記1に記載の分散型ロードバランサシステム。
4.各々のロードバランサノードが、
少なくとも1つの接続に関する状態情報をキャッシュし、かつ
ロードバランサモジュールによって公開された接続公開パケット内の状態情報に従って、キャッシュされた状態情報を更新する、ように更に動作可能であり、ロードバランサノードの所与の接続に関するキャッシュされた状態情報の更新が、ロードバランサノードの接続のリース期間を更新する、付記1に記載の分散型ロードバランサシステム。
5.各々のロードバランサノードが、接続に関するキャッシュされた状態情報が少なくとも指定された期間にわたって更新されていないことを決定することにより、接続のリース期間の有効期限が切れていることを決定するように更に動作可能である、付記4に記載の分散型ロードバランサシステム。
6.1つ以上のアクティブな接続に関する収集された状態情報を接続公開パケットとして複数のロードバランサノードのうちの少なくとも1つに公開するために、各々ロードバランサモジュールが、少なくとも1つのロードバランサノードを、複数のロードバランサノードのうちから無作為に選択するように動作可能である、付記1に記載の分散型ロードバランサシステム。
7.各々が複数のサーバノードのうちの別個の1つに実装された複数のロードバランサモジュールの各々によって、
それぞれのサーバノードのサーバと複数のクライアントのうちの1つとの間の1つ以上のアクティブな接続の各々に関する状態情報を収集すること、及び
1つ以上のアクティブな接続に関する収集された状態情報を、接続公開パケットとして、複数のロードバランサノードのうちの少なくとも1つに公開すること、を行うことと、
接続公開パケット内の収集された状態情報に従って、複数のロードバランサノードの各々の接続に関するキャッシュされた状態情報を更新することと、を含む、方法。
8.収集及び公開が、指定された間隔で行われる、付記7に記載の方法。
9.複数のロードバランサノードによって、パケットフローをクライアントから複数のロードバランサモジュールのうちの選択されたものに分散することを更に含み、パケットフローの各々が、接続のうちの1つに対応する、付記7に記載の方法。
10.1つ以上のロードバランサモジュールの各々によって、1つ以上のパケットフロー内のロードバランサノードから受け取ったパケットを、それぞれのサーバノードのサーバに送ることを更に含み、1つ以上のパケットフローの各々が、サーバとパケットフローの送信元クライアントとの間に確立された1つ以上の接続のうちの1つに対応する、付記9に記載の方法。
11.接続公開パケット内の収集された状態情報に従う、複数のロードバランサノードの各々の接続に関するキャッシュされた状態情報の前記更新が、
ロードバランサノードによって、接続公開パケットをロードバランサモジュールから受け取ることと、
接続公開パケット内の状態情報に対応する対象となるロードバランサノードを決定することと、
接続公開パケット内の収集された状態情報を、状態情報に対応する決定された対象となるロードバランサノードに従って、2つ以上のパケットに分割することと
2つ以上のパケットを対象となるロードバランサノードに転送することと、を含む、付記7に記載の方法。
12.所与の接続の対象となるロードバランサノードが、それぞれのパケットフローのための入口サーバとして機能するロードバランサノード及びそれぞれのパケットフローのためのフロートラッカーとして機能する少なくとも1つのロードバランサノードを含み、入口サーバが、パケットフロー内のパケットをルータから受け取り、パケットをパケットフローにマッピングされたサーバノードに転送し、かつパケットフローのためのフロートラッカーが、パケットフローに関する状態情報を維持するロードバランサノードである、付記11に記載の方法。
13.ロードバランサノードの所与の接続に関するキャッシュされた状態情報の更新が、ロードバランサノードの接続のリース期間を更新する、付記7に記載の方法。
14.接続に関連するキャッシュされた状態情報が少なくとも指定された期間にわたって更新されていないことを決定することにより、ロードバランサノードが、ロードバランサノードの接続に関するリース期間の有効期限が切れていることを決定することを更に含む、付記7に記載の方法。
15.各々のロードバランシングモジュールが、接続公開パケットを公開すべきである少なくとも1つのロードバランサノードを無作為に決定する、付記7に記載の方法。
16.複数のサーバノードの各々のロードバランサモジュールを実装するようにコンピュータ実行可能なプログラム命令を格納し、サーバノードのロードバランサモジュールが、
それぞれのサーバノードのサーバと複数のクライアントのうちの1つとの間の1つ以上のアクティブな接続の各々に関する状態情報を収集し、かつ
1つ以上のアクティブな接続に関する収集された状態情報を、接続公開パケットとして複数のロードバランサノードのうちの少なくとも1つに公開するように動作可能であり、
公開された状態情報が、複数のロードバランサノードの接続に関するキャッシュされた状態情報を更新し、ロードバランサノード上で所与の接続に関するキャッシュされた状態情報を更新することが、ロードバランサノードの接続のリース期間を更新する、非一時的コンピュータアクセス可能ストレージ媒体。
17.収集及び公開が、指定された間隔で各々のロードバランサモジュールによって行われる、付記16に記載の非一時的コンピュータアクセス可能ストレージ媒体。
18.サーバノードのロードバランサモジュールが、1つ以上のパケットフロー内のロードバランサノードから受け取ったパケットを、それぞれのサーバノードのサーバに送るように更に動作可能であり、1つ以上のパケットフローの各々が、サーバとパケットフローのための送信元クライアントとの間に確立された1つ以上の接続のうちの1つに対応する、付記16に記載の非一時的コンピュータアクセス可能ストレージ媒体。
19.プログラム命令が、複数のロードバランサノードの各々で、
接続公開パケットをロードバランサモジュールから受け取ることと、
接続公開パケット内の状態情報に対応する対象となるロードバランサノードを決定することと、
接続公開パケット内の収集された状態情報を、状態情報に対応する決定された対象となるロードバランサノードに従って、2つ以上のパケットに分割することと、
2つ以上のパケットを対象となるロードバランサノードに転送することと、を実装するように更にコンピュータ実行可能である、付記16に記載の非一時的コンピュータアクセス可能ストレージ媒体。
20.各々のロードバランシングモジュールが、接続公開パケットを公開する少なくとも1つのロードバランサノードを無作為に決定する、付記16に記載の非一時的コンピュータアクセス可能ストレージ媒体。
結論
様々な実施形態は、コンピュータアクセス可能媒体上の前述の記載に従って実装される命令及び/またはデータを、受け取ること、送ること、または格納することを更に含むことができる。一般的に言えば、コンピュータアクセス可能媒体は、磁気若しくは光媒体、例えばディスク若しくはDVD/CD−ROM、RAM(例えば、SDRAM、DDR、RDRAM、SRAMなど)、ROMなどのような揮発性若しくは不揮発性媒体のようなストレージ媒体またはメモリ媒体、並びに伝送媒体、または、ネットワーク及び/若しくは無線リンクのような通信媒体を介して搬送される電気的、電磁気的、またはデジタル信号などの信号、を含むことができる。
図に例示された及び本明細書に記載された様々な方法は、方法の例示の実施形態を表す。方法は、ソフトウェア、ハードウェア、またはそれらの組み合わせで実装することができる。方法の順序は、変更することができ、様々な要素は、追加、並べ替え、組み合わせ、省略、変更などが可能である。
様々な変更及び改変は、本開示に利益を有する当業者には明らかであるように、行うことが可能である。全てのそのような変更及び改変を包含することを意図し、したがって、上記の説明は、限定的ではなく例示的であるとみなされるべきである。