ネットワークの仮想化について考えてみた結果がこれだよ! | やむにやまれず

ネットワークの仮想化を手がけている会社は少ないとおっしゃる方もいらっしゃいますが、IaaS型クラウド基盤のコード読んだらおわかりの通り、今やどのコードにも大なり小なりもう組み込まれています。「ネットワークの仮想化って一体なんだ?」に答えられる記事にできたらな、と思って、久しぶりに書きました。

ネットワークの制御を集中的なトポロジでやるとスケールしない

IaaS型クラウド基盤としては先駆者であるEucalyptusにもすでにネットワークを制御する試みはあります。Cluster Controllerと言う名前で、Node Controllerに対するパケットフローの掌握に挑んでいます。スケールアウトしなかったのとSPOFになった点を除けば、設計が悪かっただけで、 自由なネットワークを作るアプローチの一つであり、まさにネットワークの仮想化を目論んだ仕組みなんだと思います。

VLANは数に限りがあってスケールしない

僕達はWakame-VDCを作るにあたって悩んでいたことがひとつありました。それはもちろんネットワークです。
ユーザーが望むネットワークをどうやって自由自在に構築するのか、これに全く良いアイディアが無かったのです。逃げ道として考えたのが、貸し出す仮想サーバーのNICをいくつか用意し、VLANで区切られた目的別のネットワークに流すと言うものでした。しかし、VLANは12bitの上限があり、4000+α個作るともうそれ以上スケールしません

スケールアウトさせるため分散を前提に制御せよ

悩んで悩んで、無い知恵を絞って考えていたら、ある時こうすれば良いと言う結論に至ったのです。それが、2010/11にリリースしたWakame-VDC v10.11に反映された分散ファイアウォールの考え方でした。そしてその発想は、2011/06にリリースしたv11.06の分散NATにも反映されています。

これらはどこに分散しているのかと言うと、「すべてのエッジノード(末端部分)に分散している」のです。エッジノードに分散してしまうと制御が大変ですから、ここにソフトウェアの力が必要になります。Wakame-VDCのネットワーク制御はすべてエッジノードで実現しています。

分散ファイアウォールの仕組み

分散ファイアウォールは、AWSで言うところのSecurity Groupsです。Wakame-VDCのインスタンス(ゲストOS)は、すべてホストOS側にファイアウォールを1つずつ持つ、と言う概念の設計がなされています。このファイアウォールで、パケットの送信元を調べallow/denyの制御をし、インスタンスを安全に保ちます。

実はAWSのSecurity Groupsの概念で一番面白い点は、「End to Endでルールを設定するだけで論理ネットワークが組める」と言う点にあります。

security_groups_physics物理ネットワークでは、左図のように仮にフラットなスイッチ構成であったとしても、個々に持つファイアウォールで通信の制御を行えば…

security_groups_logics右図のように論理的には直列のネットワークと似た動きを再現することができます。

エッジノードでの制御でも十分ネットワークのパケットフローをコントロールできます。しかもVLANを一切使わずに済ませることができました。
ここまで実装して、この辺りにネットワークの仮想化の未来像がありそうだと社内で議論していました。エッジノードでネットワークを制御すると言う方針はここで決まりました。

分散NATの仕組み

すっかりSecurity Groupsに気を良くした僕達は、IPアドレスの付与にNATが必要で、このコントロールもユーザーに与えようと言う話しになった時も結局分散して実装するアイディアを継続しました。Firewallができるなら、NATもできる、と言う単純な動機です。

WANに出ていくパケットに対し、指定のグローバルIPを付与しなおすと言うだけの仕掛けなのですが、これもインスタンス(ゲストOS)に分散させて配置しました。ここで使ったのは伝統的なNATの技術ですから、VMが送出したパケットを作法を守って変換すれば正しく通信ができるのです。

この実装が終わった時には、Default Gatewayもエッジノードに持って来たら便利だとか議論をしていました。ここまで来たので、エッジノードで全力を出してネットワークのあらゆるものを制御したらどうなるかや、OpenFlowの動向も踏まえて立ち返って整理しなおしました。

今後はOpenFlow対応してネットワークの仮想化を完了させる

僕達はこれらの経験から、次の結論を導きました。

  1. VMを使うユーザが意識しているネットワーク体系を使える(=これが仮想ネットワーク)
  2. しかしこのパケットはエッジノードで変換され、物理ネットワークを通過する
  3. 変換のルールを作るために物理ネットワークはデーターベース化されている
  4. 制御範囲である物理ネットワーク の境界がエッジノードであるから、インターネットから出入りするパケットも変換の対象である
そしてこれらエッジノードを制御するソフトウェアがIaaS型クラウド基盤の役目ではないかと考えています。もうVLANも何も必要ありません。L2だけで仮想化できるかも知れません。エッジノードがひたすら賢くなり、ユーザの望むネットワークを受け入れるのです

こうしたパケットの制御は、OpenFlowの技術が適しています。これまでは同じ目的のためにLinuxに備わっているNetfilterを利用してきましたが、実装に縛られないため標準技術に対応する方が良いでしょう。僕達はNetfilterをOpenFlowに置き換える作業を行います。

今はハードウェアSwitchがOpenFlow対応してきている流れですが、僕達はできるだけエッジノードに処理を持って行きたいので、Switchの動向に現時点ではあまり魅力を感じていません。それよりも、エッジノード上で動くNICがOpenFlow対応するのを心待ちにしています。今はネットワークが1Gb, 10Gbと高速化しており、転送量だけを処理するのでCPUの負担は増え続ける一方だからです。

例えば、ここをサポートしてくれるNIC(クラウド対応NIC?)が出たら僕達は小躍りすることでしょう。
喜ぶのは僕達だけかも知れませんけど、SR/IO-V対応していてその先にOpenFlowで制御できるCPU(GPUっぽいもの?)が備わっているNICとかあと何年かしたら出そうな気がします。

*言いたいことのまとめ

  1. ネットワークの仮想化で
    ユーザ視点のネットワークを自由に用意できる
  2. ネットワークの仮想化は
    エッジノードで物理ネットワークに相互翻訳される
  3. ネットワークの仮想化のために
    クラウド対応NICの登場を期待してます!

引き続き、もうちょっと丁寧にまとめて行こうと思います。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中