logo

グーグルのクラウドを支えるテクノロジー > 第2回 分散型ロードバランサーを実現するMaglev(パート2)

CTC教育サービスはコラム「グーグルのクラウドを支えるテクノロジー > 第2回 分散型ロードバランサーを実現するMaglev(パート2) 」を公開しました。

###
はじめに
 前回のコラムでは、分散型ロードバランサー「Maglev」を理解する準備として、一般的なロードバランサーの動作を解説した上で、「分散処理を実現する上での課題」を説明しました。Maglevは、これらの課題をどのように解決しているのでしょうか? 公開論文「Maglev: A Fast and Reliable Software Network Load Balancer」に基づいて、その仕組みをひも解いていきましょう。

分散型ロードバランサーを実現するポイント
 前回あげた課題は、コネクショントラッキングとDSR(Direct Server Return)に関連するものでした。まず、DSRの課題から説明すると、DSRの構成でロードバランサーから転送先のWebサーバーにパケットを送信する際は、L2レイヤーでの転送が必要になります。小規模な環境では、すべてのWebサーバーを同一のサブネットに配置すれば、L2レイヤーでの転送が可能ですが、複数のデータセンターにまたがって負荷分散するような際は、これは現実的な構成ではありません。

 Maglevにおけるこの問題の解決方法は、実は意外とシンプルです。先ほどの論文によると、GREトンネルによるオーバーレイネットワークを用いて、L3ネットワーク上でL2接続を実現しているそうです。ちなみに、この論文では、Googleが実サービス環境でMaglevの使用を開始したのは、2008年からと説明しています。最近では、SDN、あるいは、ネットワーク仮想化の考え方が広まるにつれて、オーバーレイネットワークもそれほどめずらしいものではなくなりました。その一方で、Googleでは、2008年の段階でオーバーレイネットワークを実活用していたというのは、興味深い事実ではないでしょうか。

Maglevハッシングアルゴリズム
 次は、コネクショントラッキングの説明です。コネクショントラッキングでは、5tuple、すなわち、IPパケットのヘッダーに含まれる「プロトコル番号(TCP/UDP/ICMPなど)、送信元IP、送信元ポート番号、宛先IP、宛先ポート番号」の組から、転送先のWebサーバーを一意に決定する必要がありました。この際、5tupleと転送先Webサーバーの対応は、すべてのMaglevサーバーで同一に保つ必要があります。これが必要な理由を図1の全体像を用いて説明していきます。

この続きは以下をご覧ください
リンク

本プレスリリースは発表元企業よりご投稿いただいた情報を掲載しております。
お問い合わせにつきましては発表元企業までお願いいたします。