サーバー仮想化と連携するエッジ・スイッチ

データセンター・ネットワークとクラウドの関係

第2回では、純粋にネットワークの観点から、データセンター・ネットワークの高スループット化について解説した。第3回（今回）は、クラウド／サーバー仮想化技術とネットワークの関係について解説する。

前回説明した通り、サーバーを仮想化すると、サービス・インスタンスの密度やトラフィックの密度が高まる。これにより、データセンター・ネットワークに対して広帯域化の要求が高まる。以降では具体的に、トラフィック量に関する課題と、それ以外の課題を考察していく。

クラウドやサーバー仮想化の課題は、大別すると、インスタンスの数量が多くなることによる（1）性能の問題と（2）管理性の問題、と言える。まずは性能面にフォーカスを当てて解説していくが、その前に、現在使われている技術について振り返る。

現在のサーバー仮想化技術では、各物理サーバー上では、最低でも1台のソフトウエア仮想スイッチが動作している。なぜこのようなソフトウエア・スイッチが必要なのかというと、通常のEthernetスイッチではフレームの流入ポートと流出ポートを同じポートにすることができないという事情からである。

もし同じポートを使ってフレームを流入・流出させると、ループが構成されてしまい、ブロードキャスト・ストームなどを発生させてしまう。このため、物理サーバー内にソフトウエア・スイッチを構成することで、このような問題が発生しないように制御している。

ソフトウエア・スイッチの問題は、フレーム転送をソフトウエアで行っていることである。

サーバーを仮想化すると、サービス密度が増大する。現在のサーバーは、6コア構成のプロセッサを2ソケット搭載できるものが多い（合計で12コア）。さらに、米Intelのプロセッサであれば、Hyperthreading機構によって、24コア相当になる。つまり、1コアに1仮想マシンを割り当てるとしても、物理サーバー1台で24個のVMが動作する可能性がある。

一般的なサイジング指標である66%の利用率を想定すると、24個の66％で16個のVMが同時に動作すると考えていいだろう。仮に、これらの仮想マシンが平均300MbpsのLANトラフィックを生み出し、さらにiSCSIもしくはNFSなどのストレージ・プロトコルを300Mbps生み出すとすると、1台あたり600Mbps×16台で、合計では9.6Gbpsになる。つまり、ほぼ10Gbpsの帯域を使い尽くすことになる。

このように、現実的に10Gbpsの帯域が必要になってきている。この時、ソフトウエア・スイッチの負荷によって、トラフィックは10%から40%低下するという報告が米Intelやそのほかのメーカーからなされている。この負荷を軽減する技術が、2010年2月に掲載した連載の第4回で触れた、各種のオフロード技術になる。

以上が、インスタンスの数量が多くなることによる性能の問題である。では、一方の管理性の問題はどうであろうか。

一般に、仮想マシンを使用する時には、ほかのシステムやほかのテナント・システムと分離するためにVLANを使用する。また、QoSを設定することで、サービスに差を付ける。

これらの設定は、ネットワークの設定であるが故に、アクセス・スイッチの役目を持っている上記のソフトウエア・スイッチで設定することになる。サービス・インスタンスが増えてくると、仮想スイッチそのものの台数が増えるが、それ以上にVLAN IDやQoSのマッピング管理リソースも増えることになる。なぜなら、サービスを区別するために仮想マシンのMACアドレスを利用するからである。

ここに、本質的な困難が見て取れる。困難の1つ目は、管理対象の「数量の爆発」である。もう1つは、「新たな管理ワークフロー」を定義する必要性である。