仮想化ソフトウエアを導入することで、一つの物理サーバーで複数の仮想マシンを稼働する“サーバー仮想化”の導入件数はだんだんと伸びている。サーバー仮想化環境では、物理的なスイッチだけで構成した場合と比べてネットワークの設計や運用で勝手が違う部分がある。

　例えば、1台の物理サーバー内の仮想マシン同士が通信するケースを考えてみよう。この場合、一般には仮想化ソフトなどに含まれるスイッチ機能（ここでは仮想スイッチと呼ぶ）がフレームの転送を担う。つまり物理サーバー内で、ソフトウエアによる閉じた通信が行われる。このような仮想スイッチによるフレームの処理に関して、スイッチベンダーなどがいくつかの課題を指摘している。

　課題の一つは仮想スイッチがソフトウエアでフレームの転送を担うため、物理スイッチでの処理に比べてオーバーヘッドが大きくなるのではないかという点だ。仮想スイッチの処理が物理サーバーのCPUに負荷をかけると、同じ物理サーバーで稼働している仮想マシンの処理が圧迫されてしまう可能性もある。

　もう一つは物理サーバー内に仮想スイッチが存在することによって、管理が複雑になるのではないかという点である。仮想スイッチは物理サーバー内にあるため、サーバー管理者とネットワーク管理者の責任分界点がわかりにくくなる。

仮想スイッチの処理を物理NICや物理スイッチにオフロード

　そこで、これらの課題を解決するべくIEEEではEVB（Edge Virtual Bridging）と呼ばれる規格を策定中だ。EVBでは物理サーバーに搭載されている物理NICや物理スイッチといったハードウエアで、現在、仮想スイッチがしている処理を代行できる機能を盛り込んでいる。

　EVBにはいくつか方式があるが、ここでは物理スイッチに処理を代行させる方式を例に見てみよう。この場合、仮想マシンから流れてくるトラフィックは物理サーバーのすぐ外側にある物理スイッチ（エッジスイッチ）にいったん送ってしまう。宛先が同じ物理サーバー内の仮想マシンでも、必ずエッジスイッチを経由して通信することになる。

　このように仮想スイッチがしていた処理を物理的な機器などにオフロードすることで、物理サーバーのCPU負荷を軽減することが期待できる。すべてのフレームを物理スイッチに送ると、物理サーバー内に閉じた通信がなくなるため、ネットワーク管理者はこれまでの物理的なネットワーク構成と同じ感覚で、サーバー仮想化環境のネットワークを管理できる点もメリットと言える。

　ただし最近、筆者がシステムインテグレーターなどに取材した範囲では、「一般的なユーザー企業の場合、物理サーバーの性能がボトルネックになって困っているというケースはほとんどない」ということだった。近年では物理サーバーの性能が向上しているためだろう。EVBは「サーバー仮想化がさらに一般化して、ネットワーク側で今よりも複雑な処理が必要になる将来を見越して」（スイッチベンダーの担当者）規格化されていると言えそうだ。そのほか、大規模データセンターのネットワークでの用途が期待されている。

　日経コミュニケーションでは「仮想化の威力をフルに引き出す最先端ネットワーク技術」として、EVBを含めた次世代のネットワーク技術を紹介するセミナーを開催する。この記事では物理スイッチに処理をオフロードするケースを主に説明したが、EVBには他にもいくつかの方式がある。各方式の違いや規格化の動向も含めて解説する予定だ。次世代のネットワーク技術をまとめて俯瞰するセミナーとして企画しているため、ネットワークの制御技術であるOpenFlow、オープンソースのクラウド基盤ソフトのOpenStackなどに関する講演も予定している（申し込みはこちら）。興味をお持ちの方はぜひ参加をご検討いただきたい。