第1回 Hyper-V 2.0のライブ・マイグレーションの基礎知識：Hyper-V 2.0実践ライブ・マイグレーション術（4/5 ページ）

[小川大地，日本ヒューレット・パッカード株式会社]

　ここまでで解説したとおり、Windowsはクラスタ・ファイル・システムに対応した設計ではないという問題があり、Hyper-V 1.0ではクイック・マイグレーションという、ダウンを要する“準”ライブ・マイグレーション機能にとどまった。

　従って、完全なライブ・マイグレーション機能が追加されたHyper-V 2.0には、クラスタ・ファイル・システムが新しく実装されたと思われるだろう。しかし、Hyper-V 2.0はクラスタ・ファイル・システムを実装していない。利用しているファイル・システムも従来のNTFSのままである。では、複数ホストによる同時アクセスの問題はどのように解決したのだろうか。

クラスタ共有ボリューム（CSV）の実装

　Hyper-V 2.0は、「クラスタ共有ボリューム（Cluster Shared Volume: CSV）」という特殊なボリューム・マネージャ機構をWSFCに実装した。これにより、ファイル・システムは通常のNTFSのままに、複数ホストからの同時アクセスを可能にしたのである。

クラスタ共有ボリューム（CSV）
Hyper-V 2.0では、クラスタ共有ボリュームという特殊なボリューム・マネージャ機構を実装し、複数ホストによる同時アクセスの問題を解決した。

クラスタ共有ボリューム（CSV）の動作

　それでは、新しく実装されたCSVの動作を解説していこう。CSVの動作を理解するためには、共有ディスクの「所有権」がキーとなる。CSVを導入しても、通常のWSFCと同じでディスクには所有権があるところに注目してほしい。

■通常のI/O
　まず、仮想マシンからの通常のI/Oを説明しよう。

　ディスクの所有権を持つホスト上に存在する仮想マシンの場合、自分のVHDファイルへの書き込みは通常どおりNTFSドライバ（ntfs.sys）を介して行われる。これに対し、所有権のないホスト上にある仮想マシンの場合はNTFSドライバを介さず、CSVフィルタ・ドライバからダイレクトに書き込みが行われる。

CSVのアーキテクチャと動作イメージ（通常のI/O）
所有権のないホスト上にあるVM2からのI/Oは、NTFSドライバを介さない。

■ファイル操作が発生するI/O
　次は、ファイル操作が発生する場合だ。ここでのファイル操作とは、CSV配下のボリュームに対して、ファイルの作成や削除、名称変更やサイズ変更といった処理を示している。技術的にいえば、ファイル・システムのメタデータ（ファイル管理用のデータ領域のこと。ファイルやフォルダのインデックス・データや使用済み／空き領域のマップ、不良セクタ・マップなど、重要なデータが含まれる）に対して何らかの更新が行われる場合だ。

　具体例としては、次のようなケースが挙げられる。

• 仮想マシンの作成／削除／クローン（各種構成ファイルが作成／削除されるため）
• 仮想マシンの電源オン／オフ（メモリ情報ファイルなどが作成・削除されるため）
• VHDファイルのメンテナンス
• スナップショット機能の利用 *
• 容量可変VHD／差分VHD *
  * 未確認情報であるが、ファイル・サイズが変更される仕組みから該当すると思われる

　メタデータの更新が発生する場合、所有権を持つホストでは通常どおりのI/Oであるが、所有権のないホストの場合はアクセス経路が大きく異なる。CSVのフィルタ・ドライバから内部ネットワークを通じて、所有権を持つホストが代理で書き込みを行うのだ。つまり、所有権のないホストで仮想マシンを作成しようという場合、実際のI/Oは内部ネットワーク経由で行われるということになる。

CSVのアーキテクチャと動作イメージ（メタデータI/O）

　ネットワーク経由でI/Oが行われていると聞くと衝撃を受けるかもしれないが、これは具体例を挙げたメタデータの更新が発生するケースだけである。仮想マシンをリブートしたり、クローンを作成したりといった作業はメンテナンス時くらいであり、実際にはメタデータ更新はほとんど行われない。なお、仮想マシンの通常のI/Oについては、前述のとおり、所有権の有無にかかわらずダイレクトに行われるので安心してほしい。

　では、なぜメタデータ更新の場合だけ、所有権を持つホストが代理で書き込むのか。これは複数から同時にメタデータが更新されると整合性が失われ、ファイル・システムの破損につながるためである。メタデータの整合性を保つためには、1台のホストが責任を持ってメタデータを管理する必要があるのだ。

　この考え方は、Windowsの共有フォルダなども同じである。ネットワーク上のマシンが共有フォルダ内で書き込みを行ったとしても、実際にファイルを書き込んでいるのは共有フォルダをホストしているマシンである。上図を見ると、ディスクへのネットワーク通信にはSMBプロトコルが利用されていることが分かるだろう。つまり、CSVは従来からの共有フォルダの技術を応用して設計されているのだ。

■クラスタ・ファイル・システムとの違い
　メタデータI/Oの説明のついでに、CSV と、VMwareのvStorage VMFSのようなクラスタ・ファイル・システムとの違いを解説しておこう。

　クラスタ・ファイル・システムは、メタデータI/Oであってもすべてのホストがダイレクトに書き込むところがCSVとの違いである。しかし、メタデータの整合性は保護しなければならないため、メタデータを更新する場合はSCSI Reservationという命令を発行し、ほかのホストからメタデータ更新をロックしている。これにより、CSVのようなネットワーク経由の代理書き込みを必要としない。しかし、SCSI Reservationのロックや解除処理にはそれなりのレイテンシ（遅延）が発生するうえ、ロックされている間、ほかのホストはI/O待ち状態となるため、性能低下の要因となる。一長一短といえるだろう。

■経路障害時のリダイレクトI/O
　CSVにはもう一つ面白い機能が搭載されているので最後に説明しておこう。

　サーバと共有ストレージをつなぐ経路がケーブル断線などで通信不能となった場合、自動的に内部ネットワークを経由した代理アクセスに切り替わる「リダイレクトI/O」という機能もCSVには備わっている。

　ただし、実際の現場ではサーバとストレージの経路は多重化してWindows Server標準のマルチパスI/O（MPIO）機能で障害対策・負荷分散を取ることが一般的であるため、本機能はあまり使われる機会がないかもしれない。

経路障害時のリダイレクトI/O
CSVでは、ストレージとの経路に障害が発生して通信不能となっても、自動的に内部ネットワークを経由した代理アクセスに切り替わる機能も搭載されている。