いまさら聞けないHyper-Vの高可用性機能（1）：フェールオーバークラスタリングとライブマイグレーション：今だからこそ学び直すHyper-V再入門（14）
今回は、運用環境の仮想化基盤として非常に重要な「高可用性」に関する機能について、その詳細や構成上のポイントなどを学び直します。「Hyper-V」の高可用性機能のキモともいえる「フェールオーバークラスタリング」の概要と、運用環境では欠かせない「ライブマイグレーション」について見ていきます。
Hyper-Vの高可用性機能「フェールオーバークラスタリング」とは
Microsoftの「Hyper-V」はハードウェア仮想化技術（サーバ仮想化技術）であり、1台の物理ホスト上で複数の仮想マシンを動作させることが可能です。そして、Hyper-V上で動作する仮想マシンに対しては、さまざまな機能を提供できることを前回まで見てきました。
仮想化技術は便利な機能ですが、物理ホストに障害が発生して停止してしまうと、その物理ホスト上で稼働する仮想マシンも一斉に停止してしまいます。結果としてシステム障害が引き起こされますが、実際の運用現場目線で見ると、そのような事態は避けなければなりません。
本番環境では複数の仮想化ホストでクラスタを構成し、そのクラスタ上で仮想マシンを動作させることで、クラスタ内のある仮想化ホストが停止しても他の仮想化ホストが仮想マシンを引き継いで動作させる仕組みが求められます。Hyper-Vでは「フェールオーバークラスタリング」機能を利用することで、仮想マシンの高可用性を保証します（画面1）。
フェールオーバークラスタリングは、「Windows NT Server 4.0」で実装された「Microsoft Cluster Server（MSCS） v1.0」を祖としてWindows Serverの歴史とともに進化し続けてきた機能ですが、本稿で扱う仮想化基盤の高可用性機能が実装されたのは「Windows Server 2008」からとなります。つまり、Hyper-Vは初めから運用環境を想定し、高可用性を保証する機能を備えていたということになります。
フェールオーバークラスタリングを用いたHyper-Vの冗長化ですが、簡単に示すと図1のようになります。
複数のホストから接続可能な共有ディスク上に仮想ハードディスクをはじめとする仮想マシン用のファイルを配置し、どのホストからでもアクセス可能にしています。クラスタを構成するHyper-Vホストは、共有ディスク上の仮想マシン用ファイルを使用して仮想マシンを起動します。
このような仕組みにすることで、クラスタ内のHyper-Vホストが停止しても、他の稼働中のHyper-Vホストが共有ディスク上の仮想マシンファイルにアクセスして仮想マシンを起動することで、停止したHyper-Vホスト上で稼働していた仮想マシンを引き継ぐ、という動きが可能になります。この場合、仮想マシンから見ると「一度電源断が発生し、自動的に再起動が行われた」という動きになるので、いわゆる「予期しないシャットダウン」の状態で仮想マシンは起動します。
他のシナリオ、例えば「Windows Update」のようなメンテナンス時に、Hyper-Vホストを再起動する場合を考えてみましょう。
計画的なメンテナンス再起動の場合は、そのHyper-Vホスト上で稼働している仮想マシンを別のHyper-Vホスト上に移動し、動作している仮想マシンがない状態で再起動することが望ましいといえます。この「稼働中の仮想マシンを無停止で他のホストに移動する」機能を「ライブマイグレーション」と呼びます（図2）。
Windows Server 2008のHyper-V 1.0では、ライブマイグレーションが実装されていなかったため「動作状態の仮想マシンを他のホストに無停止で移動できる機能がないから、運用環境では使い物にならない」と言われていました。しかし、「Windows Server 2008 R2」のHyper-V 2.0でライブマイグレーションが実装され、他のハイパーバイザーと同等の高可用性機能を持つに至りました。
Hyper-Vの高可用性を支える「クラスター共有ボリューム」とは
運用環境では必須といえるライブマイグレーションを実現するために、Windows Server 2008 R2で実装されたのが「クラスター共有ボリューム」（Cluster Shared Volume：CSV）と呼ばれる機能です。
【注】CSVは「Windows Server 2012」で再設計され、Windows Server 2008 R2のCSVとユーザーから見た動きはかなり似通っていますが、全く異なるアーキテクチャとなっています。これにより、CSVはHyper-Vの他、ファイルサーバの機能（スケールアウトファイルサーバー）などでも使用可能です。
CSVは「クラスタファイルシステム」ともいうべき仕組みです。CSVを利用することで、共有ディスク上の同一のLUN（Logical Unit Number）に対し、クラスタ内の複数のHyper-Vホストから同時に読み取り／書き込みが可能になります。
【注】LUNなどのストレージの基礎については、＠ITの別記事を参照してください。
CSVを使用しない場合、共有ディスク上のLUNとはいえ、そのLUNに対して読み取り／書き込みできるのは、当該LUNの所有権を持つホスト（所有者ノード）だけになります（画面2）。
この状態で同一クラスタを構成する他のノードである「AzHost11」のディスクの状態を参照すると、共有ディスクは見えるものの「予約」となっており、アクセスできません（画面3）。
これはデータの一貫性を保証するための排他制御の一つです。そのため、ディスクの所有者を移動することで「予約」から通常のディスクとして参照できるようになり、ディスクに対するアクセスが可能になります（画面4）。
これが通常の共有ディスクの所有権とアクセス可否の関係になりますが、このディスクをCSVに追加することで、クラスタ内の複数のホストからのアクセスが可能になります。
CSVへの追加は「フェールオーバークラスターマネージャー」で実施可能です。CSVへ追加したい「Available Storage（使用可能な記憶域）」を選択し、右メニューにある「クラスター共有ボリュームへの追加」をクリックします（画面5）。
この操作で、共有ディスク上のLUNが「Available Storage（使用可能な記憶域）」から「クラスターの共有ボリューム」へと名称が変更されます。ボリュームのパスを見ると、画面5のCSVへの追加前では「Dドライブ」として扱われていたLUNが、「C:\ClusterStorage\Volume1」というフォルダパスに変わっています（画面6）。
LUNをCSVへ追加することで、これまで所有権を持つホストからしかアクセスできなかった共有ディスク上のLUNに対し、クラスタ内の全てのホストからアクセスできるようになります。
具体的には「C:\ClusterStorage」というフォルダ下に「Volume1」というフォルダが作成され、そのフォルダそのものが共有ディスクのLUNになります。また、「C:\ClusterStorage\Volume1」はクラスタを構成する全てのホストから参照可能で、同じLUNを参照することになります（画面7）。
画面7では、ディスクの所有権を持たないホストからCSVとして追加されたLUNを参照していますが、「ディスクの管理」ツール上では当該LUNは「予約」のステータスになっています。
しかし、前出の画面3の「Available Storage（使用可能な記憶域）」の状態とは異なり、ボリューム名やパーティション状態などが参照可能です。また、画面2や画面4ではフォーマットが「NTFS」となっていましたが、画面7では「CSVFS（CSVファイルシステム）」に表記が変わっていることが分かります。つまり、通常のNTFSボリュームではなく、CSVで利用されるボリュームとして認識されています。なお、フォーマットそのものがNTFSからCSVFSに変更されたものではない点には注意してください。
画面7の左下のエクスプローラー画面からも分かる通り、CSVに追加されたLUNはフォルダのように参照可能です。また、この状態で「C:\ClusterStorage\Volume1」直下にファイルやフォルダを作成できますし、他のノードから作成したフォルダを参照することも可能です。
では、フォルダのように振る舞うLUNは、どのようにCドライブ配下のフォルダにマウントされているのでしょうか。
Windows PowerShellでフォルダの状態を確認すると、「C:\ClusterStorage」直下に存在する「Volume1」は、「ジャンクション（Junction）」でリンクされている別のボリュームであることが分かります。さらに、どこの物理ディスクに存在するボリュームかを確認すると、共有ディスクであるiSCSIストレージ上のLUNであることが分かります（画面8）。
ジャンクションについては＠ITの以下の記事を参照してください。
このように、共有ディスクのLUNをCSVに追加すると、ジャンクションでCドライブ上の特定のフォルダでリンクされることになり、どのクラスタのホストからも同じパスでファイルを参照できるようになります。
つまり、仮想マシンの設定ファイルや仮想ハードディスクを格納しているフォルダのファイルパスが、全てのクラスタのホストで共通のパスに設定でき、これによりクラスタを構成するどのHyper-Vホストからでも同じパスで仮想マシンを設定できます（画面9）。
CSVに追加されたLUNであれば、複数のホストから同時にアクセスできることは分かりました。では、どのようにして複数のホストからのアクセスを処理しているのでしょうか。
概要については以下のMicrosoftのドキュメントを参照していただければと思いますが、ポイントは「ダイレクトI/O」と「リダイレクトI/O」という2つのディスクI/O（Input/Output）方式にあります。
- クラスター共有ボリュームの概要（Microsoft Learn）
CSVにも所有権が設定されており、CSVの所有者ノードを「コーディネーターノード」と呼びます。
コーディネーターノードはLUNをローカルマウントし、LUN（ディスク）に対してフルアクセスが可能です。前述の通り、所有権を持たない非コーディネーターノードはLUNに対してアクセスできないはずですが、CSVの場合はコーディネーターノードから情報を受け取り、その情報に基づいて非コーディネーターノードはNTFSのボリュームをマウントせずに読み書きできるようになります。これを「ダイレクトI/O」と呼びます。
ダイレクトI/Oによって、非コーディネーターノードでもパフォーマンスを落とすことなく仮想マシンの仮想ハードディスクにアクセスでき、結果として仮想マシンのディスクI/Oのパフォーマンス劣化を防げます。
ただし、ダイレクトI/Oが可能なディスク操作は限定的で、例えばメタデータ操作、ファイル名の変更やファイル作成、削除といった操作は、ダイレクトI/Oでは実施できません。では、これらの操作を画面7のような非コーディネーターノード上で行った場合はどうなるのでしょうか。
その場合は、非コーディネーターノードからネットワーク経由でコーディネーターノードにリダイレクトされ、コーディネーターノードからのディスク操作として実施されます。これを「リダイレクトI/O」と呼びます。リダイレクトI/Oでは、非コーディネーターノードとコーディネーターノード間でSMB（Server Message Block）による通信が行われます。
つまり、CSV（NTFS）のメタデータ操作が必要な場合はコーディネーターノードへのリダイレクトが発生し、それ以外の操作についてはダイレクトI/Oで直接アクセスする、という挙動になります。
このあたりの細かい挙動については、以下のドキュメントが参考になります。
- Cluster Shared Volume（CSV）Inside Out［英語］（Microsoft Tech Community）
- Understanding the state of your Cluster Shared Volumes［英語］（Microsoft Tech Community）
- Cluster Shared Volume Diagnostics［英語］（Microsoft Tech Community）
なお、ダイレクトI/Oの動きについては、CSVに追加されたLUNがNTFSでフォーマットされている場合に限り行われる動きになります。CSVに追加可能なファイルシステムとしては「Resilient File System」（ReFS）がありますが、ReFSではダイレクトI/Oが使用できない点に注意してください。
- Resilient File System（ReFS）の概要 → ReFSとNTFSで使用できる機能（Microsoft Learn）
クラスタ上で仮想マシンはどう見えるのか？
フェールオーバークラスタリングとクラスター共有ボリュームがHyper-Vの高可用性を実現する機能であることは、理解いただけたと思います。
ここからは、仮想マシンがどのようにクラスタ上から見えるかを確認していきましょう。
フェールオーバークラスタリング上のリソースとしての仮想マシンを作成する場合は、「フェールオーバークラスターマネージャー」から仮想マシンを作成します（画面10）。
仮想マシンを新規作成すると、最初に仮想マシンを作成する「ターゲットクラスターノード」を選択する画面が表示されます（画面11）。
フェールオーバークラスタリングによって高可用性を保証する仮想マシンといっても、実際に仮想マシンが動作するのは“クラスタを構成するHyper-Vホスト上”です。
フェールオーバークラスタリングは、仮想マシンが動作しているHyper-Vホストやステータスを管理し、必要であれば仮想マシンが動作するHyper-Vホストを切り替えるなどのコントローラーの役目を担っています。
したがって、クラスタリソースとして仮想マシンを作成／稼働させた場合でも、Hyper-V視点であればクラスタを構成していない単体のHyper-Vと何ら変わりはありません。画面12のように、仮想マシンリソースの所有者になっているHyper-Vホスト上で、実際の仮想マシンが稼働していることが確認できます。
ただし、仮想マシンの設定を「Hyper-Vマネージャー」から変更しようとすると、仮想マシンがクラスタ化されているために一部の設定変更は許可されず、「フェールオーバークラスターマネージャー」から変更するように警告が表示されます（画面13）。
クラスタ化した仮想マシンは、動作自体は各Hyper-Vホスト上になりますが、設定などは原則として「フェールオーバークラスターマネージャー」から実施する必要があります。
クラスタノード間で仮想マシンを移動するには？
クラスタ化した仮想マシンは、当然のことながらクラスタを構成するクラスタノードのいずれでも稼働できます。
クラスタノードが障害で停止した場合、フェールオーバークラスタリングがノード停止を検知し、停止したノード上で稼働していたリソース（仮想マシン）を稼働中のノード上に移動した上で自動再起動します。これを「フェールオーバー」と呼びます。
フェールオーバーは、物理的なノードダウンやHyper-VホストのOSのハングアップ（BSoD：Blue Screen of Death）、クラスタサービスの停止、ネットワークダウンなど、さまざまな理由によって発生しますが、クラスタノード間での相互監視に応答しなくなることがトリガーになります。
相互監視に応答しなくなったノードが検知されると、稼働しているクラスタノードで「ノードがアクティブなフェールオーバークラスターメンバーから削除された」旨のイベントが重大イベントとして「システムログ」に記録されます（画面14）。
一時的な応答不良の可能性も考慮して一定時間待機しますが、一定時間経過するとノード回復の可能性がないと判断し、当該ノード上で稼働していたクラスタリソース（仮想マシン）が他の稼働中のノード上に移動され、自動再起動が行われます。
この際、稼働中のノードのシステムログにはフェールオーバーが発生した旨のログが記録されます（画面15）。
この一連の動作は、仮想マシン側から見ると「電源断が発生した後に自動起動された」ように見えます。当該仮想マシンを確認すると、予期しないシャットダウンイベントが記録されています（画面16）。
仮想マシンのOSレベルでは整合性がとれた状態でシャットダウンされたわけではないので、フェールオーバーが発生した場合には、アプリケーションレベルでのデータ整合性を確認する必要があります。
前述の通り、フェールオーバーは仮想マシンにとって決して良いイベントではないので、計画されたHyper-Vホストのメンテナンスなどは仮想マシンを安全に他のクラスタノードに移動させる必要があります。
他のクラスタノードにクラスタリソースを移動させる方法は2つあります。1つ目が「クイックマイグレーション」、2つ目が「ライブマイグレーション」で、ともに「フェールオーバークラスターマネージャー」から実行できます（画面17）。
クイックマイグレーションは仮想マシンを保存状態にした上で、メモリ状態も含めてノード間を移動し、移動先のHyper-Vホスト上で再開することで仮想マシンをノード間移動させることができます。
メモリを含めて仮想マシンの状態を維持した状態でノード間を移動するので、仮想マシンには全く変更ありません。例えば、アプリケーションを実行中の環境でクイックマイグレーションを実行しても、その状態を維持したまま移動されます。
クイックマイグレーションは前述の通り、仮想マシンの状態を保存して再開させるため、仮想マシンの動作としては数秒から数十秒の停止を伴います（画面18）。なお、停止時間はHyper-Vホストの負荷状況や移動する仮想マシンの負荷状況、メモリサイズなどに依存します。
クイックマイグレーションは、ライブマイグレーションを実施できないようなシナリオで使用される程度であり、現在の運用環境ではほとんど使われていません。現在の運用環境で頻繁に用いられるのが、ライブマイグレーションになります。
ライブマイグレーションはクイックマイグレーションと同様、仮想マシンの状態を維持したままクラスタノード間を移動できますが、最大の特徴は仮想マシンを「ほぼ無停止」で移動できる点にあります。
ライブマイグレーションを実行すると、「フェールオーバークラスターマネージャー」上では「ライブマイグレーション実行中」というステータスになります（画面19）。
この状態は、仮想マシンの状態を移行先のHyper-Vホストにコピーしている最中を示しており、刻一刻と変化する仮想マシンのメモリの状況を含めた状態を逐次移行先にコピーします。十分に仮想マシンの状態がコピーされたタイミングで仮想マシンを一時停止し（画面20）、移動先のHyper-Vホスト上で再開する、という動きになります。
この挙動により、「ほぼ無停止」といっても過言ではない停止時間でクラスタノード間移動を実施できます。この一時停止時間を「ブラックアウト時間」と呼び、どの程度のブラックアウト時間が発生したかは、移動先のHyper-Vホストのイベントログで確認できます。
イベントログの出力先は「アプリケーションとサービスログ」の下の「Microsoft」→「Windows」→「Hyper-V-Worker」→「Operational」です（画面21）。
画面21の場合は、ブラックアウト時間は「0.936秒」と1秒にも満たない停止であり、利用者からもサービス断などの影響を感じることがない時間といっていいでしょう。
異なるストレージを持つホスト間で仮想マシンを移動するには
クラスタノード内での仮想マシンは、ライブマイグレーションによって「ほぼ無停止」で移動できます。さらに、異なるストレージを持つホスト間でのストレージ移動を伴うライブマイグレーションも、Hyper-Vで実行可能です。この方式のライブマイグレーションを簡単に示すと、図3のようになります。
ストレージ移動を伴うライブマイグレーションは、幾つかの条件を満たす必要があります。以下のドキュメントを確認の上、Hyper-Vホストを設定してください。
- フェールオーバークラスタリングのないライブ マイグレーションのためのホストの設定します。（Microsoft Learn）
本稿のHyper-Vホストは、ドメイン参加の上、「制約付き委任」を設定した環境となっています。
今回の主題であるフェールオーバークラスタリングを構成し、仮想マシンの可用性を保証した環境の場合、Windows Serverの標準管理ツールを使用して異なるクラスタに移行する際は一時的にクラスタリソースとしての仮想マシンを削除し、スタンドアロンのHyper-Vホスト上で稼働する仮想マシンに変更する必要があります（画面22）。この時、CSV上に仮想マシンファイルの各種ファイルがあっても問題ありません。
クラスタリソースから当該仮想マシンが削除されていることが確認できたら、「Hyper-Vマネージャー」で仮想マシンを選択して「移動」を実行します（画面23）。
「移動の種類を選択」画面では「仮想マシンを移動する」を選択します（画面24）。説明としても記載がありますが、この項目を選択することで仮想マシンを別のHyper-Vホストにストレージも含め移動できます。
次の「宛先コンピューターの指定」画面では、移行先としてドメイン内のHyper-Vホストを指定します（画面25）。ここで指定するHyper-Vホストは、移行元である自身が参加するクラスタ（本例では「HVCluster10」）とは異なるクラスタノードや、スタンドアロンのHyper-Vホストでも問題ありません。画面25では、異なるクラスタ（本例では「HVCluster00」）を構成するHyper-Vホスト（HVHost01）を指定しました。
「移動オプションの選択」画面では、ストレージ（仮想マシンを構成するファイル群）の取り扱いを指定します（画面26）。
ストレージ移動を伴うライブマイグレーションなので、仮想マシンのデータを移動するオプションを選択します。ここでは「仮想マシンのデータを1つの場所に移動する」を選択しました。
「仮想マシンの新しい場所を選択」画面では、移行先の仮想マシンのファイル群を格納するフォルダを指定します（画面27）。ここの指定は、移行先がスタンドアロンのHyper-Vホストの場合はローカルディスクになりますが、フェールオーバークラスタリングを構成するHyper-Vホストの場合は、格納先としてCSVを指定できます。ここではCSV上のフォルダを指定しています。
次へ進めることで、仮想マシンのストレージ移動を伴うライブマイグレーションが開始されます。完了後、移行先のHyper-Vホストが属するフェールオーバークラスタリングで仮想マシンのリソースを追加することで、移行先クラスタでも高可用性構成にできます（画面28）。
このように、異なるストレージ、異なるホストであってもライブマイグレーションが可能であり、現在のHyper-Vおよびフェールオーバークラスタリングは運用現場のニーズを満たす高可用性機能を備えていると言えます。
今回はHyper-Vの基本的な高可用性機能やライブマイグレーションを見てきました。次回は応用的な付加機能について、その詳細を見ていきます。
筆者紹介
後藤 諭史（ごとう さとし）
株式会社ネットワールド所属。Microsoft MVP for Cloud and Datacenter Management（2012-2025）。現業の傍ら、コミュニティーイベントでの登壇や著作にてMicrosoftテクノロジーに関する技術情報の発信、共有を続けている。ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。近著は『詳解! Windows Server仮想ネットワーク』（日経BP社）。
Copyright © ITmedia, Inc. All Rights Reserved.