Microsoftのver1.0は基本的な部分は押さえられているけれども使えない、という伝統に則って多くのシステム管理者が強い興味を持ち、中には触ってみたりしている方も多くいらっしゃるものの、突っ込みどころ満載で実運用ベースにはまだなかなか使われていない気がするHyper-V。秋にリリースされるWindows Server 2008 R2に合わせて多くの機能を追加し、2.0として提供が行われます。
可用性の面ではLive Migration。
VMware ESXにおけるVMotion、XenServerにおけるXenMotionに該当する機能ですが、HyperMotionという名前にはなりませんでした(^_^;)。Quick Migrationはダウンタイムがあるから、というよりも1VM1LUN構成を必要とするような使用上の制約が厳しいが故に受け入れられなかった様な気がしますが、Live Migrationは仕様的な制約も解消され、エンタープライズ用途として大規模に採用される切り口にはなりそうです。なんといってもMicrosoft自身がLive Migrationを提供することそのものに価値があるのではないかと。これに伴ってWindowsや各種Microsoftサーバアプリケーション群におけるライセンス規約がより明確なものとなることを望みます。
そして個人的には期待していたもののまだまだ改善の余地がありそうなCSV(Clusterd Shared Volumes)。
この技術が実用レベルに達したためにLive Migrationなどの機能も使えるようになったわけですが、仕組み的にちょっと無理している感じがどうしてもしてしまうのは私だけでしょうか。CSVはいってみればディスクの所有者とファイルの所有者を分離する技術であって真のクラスタファイルシステムではありません。仮想ディスクファイルVHDに対するI/Oは仮想マシンを所有するノードが直接I/Oを行いますが、仮想ディスクファイルの生成などといったディスクレベルの操作はディスクの所有者が一元的に処理する仕組みになっています。この絵にあるとおり、元々のNTFSファイルシステムおよびその下にあるストレージドライバの部分をそのままに、さらにCSV I/O Filer Driverを挟み込むことによってその制御を行っているわけです。そして個人的にCSVの特徴でもあり弱点でもあると思う技術がDynamic I/O Redirection。
この絵にあるとおり、ストレージに対するI/O経路に障害が発生した場合にネットワーク経由で他のHyper-Vノードを経由したストレージアクセスを維持することで耐障害性を確保する、という技術なのですが、SANなど、ストレージI/O用に設計された経路を使っていたI/Oが突然ネットワーク経由、かつ他のHyper-Vノード経由となるわけで、1台のHpyer-VノードにおけるストレージI/O経路の障害が他のHyper-Vノードにまで影響を与えてしまうことがよいことなのかどうか、ちょっと微妙な気がします。クラスタ機能をフェイルオーバークラスタに依存するHyper-Vですが、ネットワークにおける仮想スイッチも既存のネットワークの管理の一部として提供されていたりと管理がどうしてもばらばらになってしまい、せっかく個々の技術はわかりやすくても全体として管理しづらい、ということになってしまっている気もします。
まぁ8/15からMSDN経由などでの提供が始まるようなので、きっとそれ以降は技術的に突っ込んだ記事や情報が色々と出回ることになるでしょう。
