ネットワーク仮想化の「オーバーレイ方式」はスケーラブルなのか?

2013年9月4日

ネットワーク仮想化の方式の1つであるオーバーレイ方式は、ネットワークのエッジ部分、物理サーバ上のハイパーバイザでOpen vSwitchのような仮想スイッチを利用し、ハイパーバイザ間にトンネルを張ることで仮想的なネットワークを物理ネットワーク上に作り出す技術です。

しかしこのトンネル通信を用いたオーバーレイ方式は、大量の物理サーバが存在するデータセンターでも使えるほどスケーラブルなものなのか? という疑念が一部で持ち上がっています。

Are Overlay Networking Tunnels a Scalability Nightmare? « ipSpace.net by @ioshints

その疑念に真っ向から反論するのが、米国でネットワーク構築のコンサルタントや教育を行っているIvan Pepelnjak氏。同氏のブログ「ipSpace.net」にポストされた「ARE OVERLAY NETWORKING TUNNELS A SCALABILITY NIGHTMARE?」では、オーバーレイ方式への疑念は単なる風評だと一周しています。

オーバーレイ方式は本当にスケーラブルな技術なのか。Pepelnjak氏の許可を得たので、翻訳で内容を紹介します。

ARE OVERLAY NETWORKING TUNNELS A SCALABILITY NIGHTMARE?

(2013/8/28 Ivan Pepelnjak)

オーバーレイ型の仮想ネットワーキングのトンネルについて話すたびに、この手法に関するスケーラビリティの心配をする人が出てくる。「何百ものホストが稼働するデータセンターで、そんなに多くのフルメッシュのGREトンネルを張ることなどできないのでは? その手法にはスケールの上限があるのではないか?」と。

意外なこととも思えないがトップオブラック(ToR)スイッチのベンダーたちはこうしたくだらない点についての(それこそ彼らの特権として)不安をまき散らしている。この記事では、こうした誤解を正していこう。

トンネルとは何か?

上記で指摘したトンネルとは、Linuxベースのハイパーバイザ―の間のpoint-to-point GRE(あるいはSTTやVXLANの)トンネルインターフェイスのことだ。ただしCisco Nexus 1000VVMware vCNS、あるいは(たしか)VMware NSX for vSphereではトンネルインターフェイスは使っていない(あるいは少なくとも外部からそのようには見えない)。

なぜトンネルインターフェイスが必要なのか?

P2Pオーバーレイのトンネルは、Open vSwitchでのOpenFlowベースのフォワーディング実装によるものだ。OpenFlowのフォワーディングモデルは、point-to-pointインターフェイス(switch-to-switchもしくはswitch-to-host links)であり、マルチポイントインターフェイスを扱うことはできない。

つまりOpenFlowコントローラ(Nicira NVP)は、フォワーディングルールにおいてマルチアクセストンネルインターフェイスでトランスポートネットワークの次ホップ(VXLANでいうVTEP)を指定することはできない。

これに対する現実的な回避策は、多数のP2Pトンネルインターフェイスを作成し、目的地(VTEP)となりそうなあらゆる場所に対してそれらを接続することだ。

そうしたことを管理者は気にする必要がある?

そんなことはない。Open vSwitchのデーモンの1つが自動的にプロビジョニングしてくれる。それは、Linuxホストでのみ稼働し、トランスポートネットワークには何の影響も与えない(ハイパーバイザーのホストにおけるMACアドレスとARPエントリーを除いては。いずれにせよトランスポートネットワークはそれを扱わなければならないわけだが)。

で、トンネルはスケールするのか?

手短な答えはイエスだ。スケーラビリティでボトルネックとなる本当の場所はコントローラであり、コントローラが管理可能なハイパーバイザーの数による。

各ハイパーバイザは必要なだけトンネルを張る。もしもあるハイパーバイザが仮想マシンを50個走らせていて、それぞれの仮想マシンが別々のサブネットに属していて、そのサブネットごとに別の50個もの仮想マシンが属していたら(つまり別に50ものホスト上のハイパーバイザがあちこちにある、ということだ)、そのホストは2500ある目的地VTEPSにつながるための、2500のトンネルインターフェイスが必要となる。

大規模な仮想化率ではLinuxのスケーラビリティの限界に達することは明らかだろうし、大規模な仮想サブネットの限界(それがどれくらいかは私には分からない。コメント求む)、そして分散されたL3フォワーディングは加速度的に性能悪化していくだろう(これについては、いずれブログで書くつもりだ)。

しかしそれぞれのホスト上のハイパーバイザーとしては、トランスポート上の目的地に対してトンネルを1つ張っており、単一のホストがクラウド内の物理サーバ数を超えるトンネルを張ることは決してない。だからこそ、単一のNVPコントローラクラスタは現時点で5000以上のハイパーバイザー以上にはスケールせず、これが単一のLinuxホストのトンネル数の上限を示している。

ということは空騒ぎしているだけ?

最初に書いたように、これはハードウェアベンダによる純然たる風評(FUD)だ。あなたはもうこんなことには惑わされず、誰かが不安をまき散らしたとしても悠然と構えていればよい(そして、いくつか彼らの痛いポイントを突いてもいいだろう)。

あわせて読みたい

コンテナ型仮想化 仮想化 OpenFlow Software-Defined Network ネットワーク




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本