GLB: Github’s open source load balancer

結局どんなの

例えば，ファイルのアップロード中に宛先サーバが変わると失敗してしまったりする

そこで，L4でロードバランスする時にL7LBの候補を2つ用意して1つ目にパケットを投げる

そして2つめが通信してるホストだった場合はそのまま通信する

これにより，L4やL7のLBが増えたりした場合でも通信を継続出来る

また，このようにL7のテーブルを持つことで，後ろのサーバの更新を行いたい時にも，新規セッションを一部のサーバに送らないようにすることも出来る

特徴

よく使われているIP in IPだと、サーバのメタデータの情報などを載せれる場所がないので、選択しなかった

セカンダリーサーバのリストをここに載せてるらしい

ルータからみると、ただの2つのサーバ間のUDPパケットになっている

最初の方の訳(動作の説明のところまで)

概要

GLB DirectorはL4のロードバランサで、サーバ変更時の接続の中断を最小限に抑えながら、多数の物理マシンに対して同一のIPアドレスで拡張する

L4のロードバランサはの主な機能は1つのIPアドレスを所得し、そのIPアドレスの接続先を複数のサーバに分散させることである

単一のIPアドレスを増やして、単一のマシンが処理できるよりも多くのトラヒックを処理するには、バックエンドのサーバの分散だけでなく、負荷分散するサーバも増やして処理する必要がある

通常、IPアドレスは1つのマシンを指し示しており、ルータはそのマシンに最も近い次のルータにパケットを転送する

実際には、ほとんどのネットワークはもっと複雑になっている

ECMPは同じコストの接続先が複数ある場合に、ルータがトラヒックからハッシュ値を求めて接続先を分散させる機能

ECMPは、各パケットに対してハッシュ値を求めて、利用可能な経路のなかから、一貫した洗濯を決定する

しかし、これには分散した、サーバのリストが変更する場合に問題がある。

例えば、現在2つのサーバが同じIPアドレスで動いており、そこにECMPにより分散しているとする。

そこに、1台のサーバを追加する。そうすると、ルータはこれまでのコネクションも含めて、均等に分散しようとする。

それにより、あたらに追加されたサーバへ誘導された、これまで2台のサーバで処理されていた通信は失敗することになる。

Split director/proxy balancer design

ECMPのみのソリューションの問題は、特定のパケットの完全なコンテキストを認識してないことと、各パケットの接続データを保存していないことである

1. ECMP経由でルータからパケットを受け取るディレクターサーバを作成する

2. ディレクターサーバから、バックエンドのプロキシサーバを選択する

3. このディレクタサーバでハッシュとストアなどの状態を制御する

これは多くの場合、うまく機能する

しかし、いくつかの欠点が存在する

例えば、ディレクタサーバとバックエンドのプロキシサーバを同時に追加する場合に、まだ、ディレクタはステートを持っていないため、ハッシュ値の計算によってこれまで行われていた通信の一部を新しいサーバに流してしまう可能性がある

Removing all state from the director tier

GLBではこの状態を改善したいと考えた

GLBでは、完全にハッシュ値を用いて経路を決定する

そして、接続が行えるかどうかをプロキシサーバの持っているコネクション情報を用いて決定する