MultipathTCP + 分散型ロードバランサー(2)
May 14, 2021
MultipathTCP + 分散型ロードバランサー(1) の続きです。
手法紹介
そのため、これを正しくルーティングするための何かしらの手法が必要となってくる
今回はこの「何かしらの手法」についてどんな手法があるか紹介をする。
duchene 氏の提案
duchene 氏は RFC のドラフト にて MPTCP に非対応のロードバランサーで MPTCP を利用する方法について述べている。
この手法は分散型ロードバランサーでも問題なく利用できるため、紹介する。
この方式では前提としてバックエンドサーバーはすべて２つのアドレスを持っている。
１つはロードバランサーから、もう１つはクライアントから疎通性があるアドレスである必要がある。
そのため、一般的にはプライベート IP アドレス１つとグローバル IP アドレス１つである。
(卒論で使った図)
コネクションが確立されるまでに必要な流れはざっと以下のとおりである。
- クライアントはロードバランサーの VIP に接続を行い、いずれかのバックエンドサーバーと接続を確立する。
- サーバーは
ADD_ADDRメッセージを使い、クライアントに自サーバーが持っているグローバル IP アドレスを通知する。 - クライアントは通知されたアドレスに対して新規コネクションを作成し、MPTCP のコネクションが確立される。
ここで新たに出てきた ADD_ADDR というものは、接続してきたアドレス以外のアドレスが存在する場合、そのアドレスを通知するために存在するものである。
ADD_ADDR の詳しい話や MPTCP のモード（fullmesh 等）については後ほど別途解説を行うつもりであるため、省略する。
この方式の問題点としては以下のとおりである。
- 慢性的な ipv4 アドレスの枯渇のため、ipv4 でサービスを行うコストが非常に高い
- グローバルアドレスを外部に晒し、接続可能な状態になるため、クライアントが特定のバックエンドサーバーを攻撃可能に
- DDoS の恐れ
- スマートじゃない（個人の感想、要定義）
Beamer
Beamer と呼ばれるステートレスロードバランサーが NSDI で発表された。
そのロードバランサーは MPTCP の対応が目玉ではないが、MPTCP にも対応しているとのことなので、どのように対応しているか紹介する。
読むのがめんどくさい人は上記の方式を LB のポートごとに行うもの、くらいに思っておいてもらえば問題はない。根本的には変わらない。
(卒論で使った図)
コネクションが確立されるまでに必要な流れはざっと以下のとおりである。
- クライアントはロードバランサーの VIP に接続を行い、いずれかのバックエンドサーバーと接続を確立する。
- サーバーは
ADD_ADDRメッセージを使い、VIP にマッピングされた自分のサーバーに疎通性のあるポート番号つきのアドレスをクライアントに通知する - クライアントは通知されたアドレスに対して新規コネクションを作成し、MPTCP のコネクションが確立される。
この方式の問題点としては以下のとおりである。
- 特定のサーバーと対応するポートを外部に晒し、接続可能な状態になるため、クライアントが特定のバックエンドサーバーを攻撃可能に
- DDoS の恐れ
- スマートじゃない（個人の感想、要定義）
自分が卒論で提案した手法
ここから先が自分の提案である。今思い返してみれば思うところは色々あるが、ひとまずは卒論で書いた内容を説明する
MPTCP はサーバー内で key を発行し、そこから求められる Token を利用し、相手とネゴシエーションを行う（*1）
そして、subflow からの通信開始時、Token を付与してパケットが送られてくるため、Token <> Flow の情報をロードバランサーが参照できれば正しいサーバーへルーティングすることが可能になる。
そのため以下のようなアーキテクチャの提案を行った。
(卒論で使った図)
(卒論で使った図)
コネクションが確立されるまでに必要な流れはざっと以下のとおりである。
- クライアントはロードバランサーの VIP に接続を行い、いずれかのバックエンドサーバーと接続を確立する。
- サーバープラグインは途中のパケットをキャプチャし、MPTCP のトークンを横取りし、データストアに自分のサーバー情報とともにアップロードする
- クライアントは通常通り２つ目のインターフェースを利用して VIP に接続を行う。
- クライアントから来た通信を Token を参照し、正しいサーバーへルーティングする。
このとき、フォワーダーとロードバランサーのレイヤーをわざわざ分離したのは理由がある。
ロードバランサーはステートレスに動作し、背後のサーバーに一貫性をもって転送することを目的としている。
それに対し、フォワーダーはステートフルに動作し、問い合わせ先が変わると再度データストアへの問い合わせが発生する。
そのため、ECMP がシャッフルされてもデータストアの再問い合わせが行われないように多層アーキテクチャにした。
ふりかえり
- レイヤーを分離するのは間違いなくロバストではあるが、per flow ecmp が主流になっている今、レイヤーを統合しても小規模な環境ならちゃんと機能するのではないか？
- どのくらい機能するかの比較を取ればよかった
- (記載していないが、評価について) Linux の ip6ip6 トンネルが遅く、そこがボトルネックになっていた気がする
- これはいつか追って検証したい。
- 他のトンネリングプロトコルと比較したい。