10GbE NICが次第に導入され始めています。まだサーバのオンボードNICは1GbE NICが主流ですが、おそらく次のモデルチェンジではサーバベンダー各社から10GbE NIC搭載サーバが続々と発表されることになっていくでしょう。特にBladeサーバの場合は仕組み的にBladeシャーシに搭載されるスイッチモジュールへの接続が標準なので、先行して10GbE化が進んでいくことになると思われます*1。HPはオンボードNICとして10GbEを搭載したBladeサーバモデルをすでに提供していますし、DELLは先日発表した新製品でオンボードNICもドーターカード化することで当初搭載の1GbE NICを10GbE NICに交換可能にしたモデルを提供し始めるようです。
10GbE NICでは、1GbEまでの場合と同様にRJ45規格に基づく10GBASE-Tや比較的安価な10GBASE-CX4も規格化されていますが、おそらく光ファイバケーブルを用いた接続構成*2が主流になっていくのではないかと思われます(Wikipedia - 10GbE)。
さて、今回のエントリーではとりあえずFCoEの話はおいておいて、仮想化インフラにおいて10GbE化が与える影響を考えてみたいと思います。
10GbEがNICやスイッチを含めてEnd-to-Endのネットワークで当たり前のように用いられるようになる頃にはおそらく現在の1GbE NICのような使い方にまた戻るのかもしれませんが、当面はこれまで1GbE NICを個別に用いていた通信を束ねる使い方と、10Gbの帯域を活かしたストレージアクセスや帯域を必要とするバックエンド通信用途などの2種類の使い方がされる状況が暫く続くことになるのではないかと思われます。場合によっては、ストレージ通信とその他の通信が10GbE NICを共有する構成となることも十分あり得るパターンとなるでしょう。
これまでも各仮想化インフラHypervisorは仮想スイッチやTag VLAN機能により複数セグメントを同一NICでまかなうことを可能にしていましたが、現実的な設計では重要なネットワークは物理的なNICレベルで分割するなどにより明確な帯域の確保が行われていました。しかし10GbE NICの登場により、本格的に複数セグメントの通信を共有する構成が取られるようになると「物理的な分離」では対応ができないことになり、Hypervisor機能としてより厳密かつ実用的な帯域制御の機能が求められることになります。束ねた複数セグメントのうち、どこかのネットワーク通信がバーストしたために他のセグメントに影響が及ぶことを防止しなければなりません。
仮想化環境における帯域制御の難しさは、単純に上位スイッチ側でのQoS構成では対応しきれないところにあります。仮想マシンはライブマイグレーション機能により実行ホストを移動することもありますし、新規の仮想マシンやセグメントが仮想化サーバに構成された場合に都度上位スイッチ側のQoS定義を更新するような運用はなかなか難しいでしょう。また、単一のHypervisor環境だけを考えればよいのではなく、仮想化環境全体での帯域制御を管理・運用できるようにする必要があります。仮想マシンの配置が移行してもネットワークI/Oは常に確保されるような仕組みが必要です。そのため、やはり仮想スイッチを構成するHypervisorの機能として帯域制御を実装することが最もシンプルかつ確実な対処となるでしょう。ただし仮想化ホストをまたいだ制御となるため、上位スイッチがわとの連携も必要となります。Cisco Nexusで全部まとめればできるよ、とかいう話になるのかもしれませんが(^_^;)、標準化技術かつマルチベンダーで実現できるようになればユーザにとってのメリットも大きいはずです*3。
仮想マシンの増減や移動に対応する柔軟な帯域制御が実現して始めて、10GbE NICによる本格的なセグメント共有ネットワークが実現するのではないかと思います。特にストレージI/Oを他のネットワークI/Oと束ねてしまうような使い方は、確実に帯域が確保されるような帯域制御がとても重要になります。
VMwareは次期vSphereの1機能として、仮想マシンごとのストレージI/Oをより厳密に、実行ホストの枠を超えて管理する"Storage I/O Control (SIOC)"機能を発表していますが、たとえば10GbE NICをシェアする経路でSoftware Initiatorを用いてiSCSIストレージを用いる場合などではこのSIOCだけでは不十分です。iSCSIやFCoEなどによりネットワークI/OとストレージI/Oが次第に統合されつつある現在、帯域制御はネットワークとストレージの両リソースでかかせない重要技術となっていくはずです。
ネットワークとストレージのI/Oが確実に制御できるようになれば、利用者はより仮想化レイヤーを意識せずに仮想マシンを使用することができるようになります。こうした「意識せずとも制御されている」ことが1つ1つ増えていくことで、仮想化はクラウド基盤としての使い勝手がより高まることになっていくでしょう。
