グーグルのクラウドを支えるテクノロジー > 第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の全体像を用いて説明していきます。

この続きは以下をご覧ください
http://www.school.ctc-g.co.jp/columns/nakai2/nakai202.html

よろしければこちらもご覧ください
この記事が役に立ったらシェア!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!
メルマガの登録はこちら Web担当者に役立つ情報をサクッとゲット!

人気記事トップ10(過去7日間)

今日の用語

アドワーズ
グーグルが提供する、検索連動型広告/コンテンツ連動型広告に出稿できる、キーワード ...→用語集へ

連載/特集コーナーから探す

インフォメーション

RSSフィード


Web担を応援して支えてくださっている企業さま [各サービス/製品の紹介はこちらから]