vSphere4、Hyper-V2.0, XenServer5.5とメジャーどころのアップデートが一巡する予定の今年、各製品を横断的にさわっていると、もはや仮想インフラとしてはどの製品を選んでも大差ないと思うようになってきました。すでに現行製品においても「仮想マシンを実行する」基盤レベルであれば大差ない状況となっていましたが、今年各製品のアップデートがリリースされた後は「仮想マシンを管理・運用するために必要な機能」レベルにおいても基本的な差はほとんどないような状況になっていきそうです。
TechEd2009で公開されたHyper-V2.0の仕様ですが、VMkernelが64bit化されたESX4.0を含むvSphere4がリリースされてしまったために機能的な優位性はあまりない状況に(^_^;)。とはいえ、Hyper-V2.0+SCVMM2008R2によってMicrosoftの仮想化は本格的な土俵に乗った感じにはなってきているので、主にMicrosoft製品を中心としたインフラ環境構築向けなどでどれだけ大規模に使われていくことになるのか、注目していきたいと思います。
なんといってもHyper-Vの価値はMicrosoftが提供しているということ自体にあるといえます。DELLによるHyper-VにおけるExchangeサーバの実用性について検証した結果などが一部公開されていますが、Microsoft自身が提供するサーバ製品を使用しているユーザに対してHyper-Vを基盤として採用する動きがどれだけ広がるかがHyper-Vの行く末を左右するといえるでしょう。
Hyper-Vが2.0になって対応してくる主な技術的な側面は以下の通り。
- SLAT (Second Level Address Translation)
もぅいい加減に独自略称の命名をやめてもらいたい今日この頃ではあるのですが、要はIntel EPT / AMD RVIの仮想化支援機能への対応。仮想化によるオーバーヘッドの中でメモリのページテーブル変換処理に関連する部分は意外とインパクトのある部分なので、これはもはや必須ともいえる機能。
- Chimney Offload Support
こちらはNICの持つTCP Offload機能を使って仮想マシンのTCP処理を実行することによってCPU負荷を低減しようという仕組み。対応するNICを使用する必要があるが、Network I/O処理のためのCPU負荷がなくなればその分CPUを別の処理にまわすことができるわけで、環境によっては効果がありそうです。
- VMQ (Virtual Machine Queues)
こちらも対応するNICを使用する必要がありますが、ペアレントパーティション側で各ゲストOSのNIC I/0のQueue制御を行うのではなく、ダイレクトにNIC側でQueue制御を行うことによってCPU負荷を削減しようという仕組み。
VMQの価値はゲストOSのQueue制御だけではなく、ゲストOS間の通信におけるメモリコピーをアドレス情報だけで処理してしまおうという点。Chimney Offload SupportとVMQの両方を使うことによってどれだけメモリに関する仮想化オーバーヘッドが削減できるのか、興味深いところです。
- Live Migration & Cluster Shared Volume
ま、説明不要でしょう(^_^;)。
- Processor Compatibility Mode
EVC同等機能。
- Core Parking
こちらはHyper-Vの機能というよりも、CPUに対するWindows Server 2008 R2の機能。CPU使用率が低ければソケット単位でカットすることによって消費電力の削減を実現する機能です。vSphereで正式サポートされたRVIによるホスト単位の節電よりも柔軟性は高そうですが、だったら最初からCPUソケット数の少ないサーバを仮想化インフラにしたら？というツッコミが入りそうな気も…。
ま、こうした技術的な側面はもはや対応していて当たり前で、あとは管理性能やらサポート体制やらが重要なファクターになるわけなんですけれどもね。各ベンダーとも大変ですね。
