Hyper-V2.0の目玉機能"Live Migration"のために用意された"Cluster Shared Volumes (CSV)"ですが、だいぶ情報は公開されてきているもののまだまだ謎が多いと思いませんか？ユーザとしては別に問題なく使えればいいかもしれませんが、技術者魂？としては「どうやって動いているの？」という面はけっこう気になるところ。そのあたりがスッキリしないとなんとなく気持ち悪いモノです(^_^;)。
…で、最大の謎ポイントは仮想マシンを配置するボリュームのディスクフォーマットはNTFSのままでありながら、CSVという共有ファイルシステムを用意することによって"Live Migration"時における最大の課題であった仮想マシン構成ファイルへの透過的なアクセス切り替えを実現してきている点。先日公開された"Windows Server 2008 R2機能評価ガイド"の"Hyper-V 2.0 Live Migration"編にもCSVについての説明が載っているのですが、いまいち表面的なことしか書いていないのです。
クラスター シェアード ボリューム (CSV：Cluster Shared Volumes) は、Hyper-V 2.0 の仮想マシンを格納するためのストレージとして設計され、Windows Server 2008 R2 のフェールオーバー クラスタリング機能に標準搭載される、新しいタイプの共有ストレージです。
CSVはVMFSのようなネイティブな？ディスクフォーマットレベルのファイルシステムではなく、あくまでもLive Migrationを実現するために構成された共有ストレージAPIのようなものの様です。GPTでもOKかな？
CSV は、Windows Server 2008 R2 のフェールオーバー クラスターに参加するノードに対して、共有ストレージ上のボリュームへの同一パスによるアクセスを提供します。CSV は ドライブ レターを使用せず、フェールオーバー クラスターのすべてのノードから［C:\ClusterStorage\Volume1］［C:\ClusterStorage\Volume2］のような簡潔なパスを使用して読み書きすることができます。指定が面倒なボリューム GUID を使用する必要もありません。
フェールオーバー クラスターが管理する共有ストレージ上の記憶域リソースは、通常、リソースを所有するノードのみがアクセスできます。これに対して、CSV のボリュームは、リソースの所有者とは関係なく、すべてのノードから同時にアクセスすることが可能です。この同時アクセスの機能により、同じボリューム内に、複数の仮想マシンを、その仮想マシンの実行ノードに関係なく配置することができます。
CSVを通じて仮想マシンを配置することにより、実際のブロックレベルファイルシステムはNTFSでありながら擬似的に(透過的に)共有ファイルシステムを実現する仕組みにすることによってLive Migration機能を実現したHyper-Vですが、気になるのはあまりにもLive Migrationを実現するためだけに設計されているCSVを組みこんで来ている点。1LUN/1VMというような本末転倒な制約条件を無くすなど、CSVによって得られるメリットは多く、その仕組みにおいて無理しているとは思いませんが、NTFSを改築するのではなく、NTFSに増築するようなかたちで用意されてきたCSVはどれだけ使い物になり、今後の機能拡張に制約をもたらさずに済むものなのか、色々と気になるところではあります。
…そんな時にちょうどよく？、Microsoftのエバンジェリストである高添さんがBlog"高添はここにいます"にてCSVについての技術的解説をしていました。
CSV には面白い特徴があります。それは、
2段階の所有者(オーナー)制
です。
2段階とは、
1. CSV という論理ボリュームに対する所有者
2. CSV の中に登録されている各仮想マシンに対する所有者です。
図にするとこんな感じです。
ふむ、ボリューム自体に対する所有者とファイル(群)で構成される仮想マシンに対する所有者との2段階構造なわけですね。なるほど、仮想マシンに対する所有者というレイヤーを入れ、ボリューム自体の所有者が別のノードであってもアクセスできる仕組み？を設けている、と。しかし、問題はここから。
緑色の枠はCSVで、CSV の所有者は HVR01です。
よって、新しく仮想マシンを作る時のような、CSV に何かを書き込む際には HVR01が実施します。
じゃあ、CSV に対するすべての処理を HVR01 がやるかというと違うんです。
それが2つ目の所有者でして、CSV の中に登録されている仮想マシンは、CSVとは別に所有者の割り当てが行われています。
例えば上図では、仮想マシンB に対して HVR02 が所有者になっているわけで、仮想マシンB に対する書き込みは HVR02が担うことになります。
ボリュームに対する処理はボリュームの所有者が。それはいいんですが、ではボリュームの所有者になっているノードに障害が発生したら？そこはMSFCで担保ってことになるんでしょうか？んー…、その間、一時的にボリュームに対するアクセスは停止する？
CSVにおける処理プロセスをもう少し分かりやすくしたスライドも載っていました。
こちらはCSVに対して仮想マシンを作成している処理の流れ。
CSVの所有者ではないノード側で仮想マシンの作成処理を開始した場合、その命令は"CSV I/O Filter Driver"から"Redirector FSD", "NetFT"を通じてCSV所有ノードへ、CSV所有ノード側の"NetFT"から"File Server Service"に入り、そこから改めて"CSV I/O Filer Driver"-"NTFS"-"Storage Driver"と辿ってやっとLUNに対する処理が。ノード間のNetFT同士の通信ってどのパスを使ってやるのかな？まさかネットワークってことはないですよね？
つづいて作成された仮想マシンに対する処理の流れ。
CSVの所有者は対向のノード側でしたが、仮想マシンの所有者は自ノード側なので、そのI/O処理は直接実行されています。しかも、この絵のポイントはNTFSファイルシステムレイヤーを通過せずに"CSV I/O Filter Driver"が直接"Storage Driver"へデータを受け渡している点。ふむ、この辺はいわゆるPara-Virtualization的な動きですね。
Hyper-Vもやっと技術的に深みが出てきて面白くなってきました(^_^;)。
