(cache) Software-Defind xx と対応ハードウェア - ネットワーク編 (1)

ネットワーク編　(1)

最近、「software-defined something.. (SDx)」というお題で、講演の機会をよくいただくのですが、SDx の正確な定義をよく分かっていません。

もう 9 年くらい経つ「サーバー仮想化」も software-defined Compute のような気がしますし、ストレージについてはユニファイド系の多くが Xeon プロセッサを積んだ x86 サーバーで動いているわけで、言ってしまえばそれも software-defined Storage なのではないかな、と思ったり。。。

さすがに最近は「software-defined になるとハードウェアは何でも良い」と言う人は減っていますが、ネタに困っていることもあり、SDx を意識したハードウェアや設計ネタについて数回紹介していきたいと思います（なるべくニュートラルに）。

物理スイッチと仮想スイッチ

最近のネットワークスイッチは、Broadcom Trident などのスイッチプロセッサと Linux/BSD ベースの OS（ファームウェア）で作られています。

しかも、x86 プロセッサにおける Intel Xeon のように、スイッチ用プロセッサは Broadcom Trident が寡占的です。このため、下図のようなスイッチのハードウェア部分は基本的に共通であり、各社は OS で独自性を出しています*1。

つまり、Hyper-V や VMware といったハイパーバイザーに含まれる「仮想スイッチ」はもちろん、「物理スイッチ」も一種の "software-defined" なわけですが、同じ SDx である物理スイッチと仮想スイッチだと、効率が良いのは前者です。

理由は単純。先ほどの Broadcom Trident はスイッチ専用プロセッサなだけあって、専用の命令セットで多くのスイッチングをハードウェア処理できます。

ソフトウェアプログラムの場合であれば数十～数百コードになるスイッチ処理が、特殊な命令セットを持つ専用プロセッサによって一瞬で処理できてしまうのです
（できるだけソフトウェア処理させないよう、ASIC を更に搭載するケースもあります）。

仮想スイッチの処理によって CPU が振り切る

これに対し、仮想スイッチはスイッチ処理のほぼすべてを CPU で処理します。
CPU には仮想スイッチの処理を高速化する命令セットはありませんし、特別な ASIC も搭載されていません。

ここで、昨今流行りの 10Gbps NIC*2 を考えてみましょう。10G や 20G のトラフィックを仮想スイッチに流した場合、CPU がどれくらい奪われてしまうか想像できますでしょうか？

次のスライドは若干古いですが、ネットから入手できる資料の抜粋です。

注意）仮想スイッチのコードは各社独自ですので負荷に差異はあります。また、後者のグラフは元々は VMQ の効果測定の結果です。VMQ を有効にして処理コアを増やした途端、そのコアの使用率が 0 → 80% に跳ね上がったところに目を向けていただければと思います。
こちらのベンチマークもおすすめです。http://it.anandtech.com/show/2956/10gbit-ethernet-killing-another-bottleneck-

帯域やスピードばかり気にしがちになりますが、同じ 1 秒間において、
10Gbps は 1Gbps の 10 倍の量をこなしていることを思い出してください。