いまさら聞けないHyper-Vの高可用性機能（2）：システムと運用者の立場を守る「フェールオーバークラスタリングの高度な機能」：今だからこそ学び直すHyper-V再入門（15）

今回は、「Hyper-V」の高可用性機能のキモともいえる「フェールオーバークラスタリング」を支えるネットワークの構成の詳細と、フェールオーバークラスタリングに実装されている高度な機能の概要と利用方法を学び直します。

[後藤諭史，株式会社ネットワールド]

連載目次

フェールオーバークラスタリングを構成するHyper-Vホストのネットワーク構成

　「Hyper-V」の仮想化環境では「フェールオーバークラスタリング」機能を利用することで、仮想マシンの高可用性を保証することは前回解説しました。そのフェールオーバークラスタリングを構成するHyper-Vホストのネットワーク構成は、単体のHyper-Vホスト以上に注意深く構成する必要があります。

　単体のHyper-Vホストであれば、Hyper-Vホストを管理するためのネットワーク（管理ネットワーク）と仮想マシン用のネットワークの2つが必要になります。

　物理的な構成としては、管理用ネットワークと仮想マシン用のネットワークに対して、それぞれ物理ネットワークアダプターを割り当てるとすると、物理ネットワークアダプターは2つ必要になります。概念としては図1の右側のような構成になります。

図1　単体のHyper-Vホストのネットワーク構成

　物理ネットワークアダプターを節約するのであれば、本連載第8回で紹介した「管理オペレーティングシステムにこのネットワークアダプターの共有を許可する」を設定することで、図1の左側のように物理ネットワークアダプター1つでも構成可能です。これらの構成はネットワークアダプターの冗長性を考慮していません。冗長性を考慮する場合は、倍の物理ネットワークアダプターが必要になります。

　対して、フェールオーバークラスタリングを構成するHyper-Vホストでは、クラスタ間通信を行うネットワークの他、仮想マシンの「ライブマイグレーション」実行時にメモリ情報などを移行先のHyper-Vホストに送信するためのネットワーク（ライブマイグレーション用ネットワーク）が必要になります。また、共有ディスクにiSCSI（Internet Small Computer System Interface）を使用している場合は、iSCSI用のネットワーク（ストレージ用ネットワーク）も必要になります。

　それぞれに物理ネットワークアダプターを割り当てた場合、冗長性を考慮しなければ図2のような構成になります。

図2　フェールオーバークラスタリングを構成するHyper-Vホストのネットワーク構成

　全てのネットワークを同一のネットワークで構成する、もしくはVLAN（Virtual Local Area Network：仮想LAN）を使用することで、使用する物理ネットワークアダプターを1つ（冗長性を考慮して2つ）にすることも可能ですが、25Gbpsや40Gbps、100Gbpsといった十分な通信速度を持つ物理ネットワークアダプターが必要です。

　フェールオーバークラスタリングでは、そうした物理的な構成も勘案しながら物理ネットワーク構成を決めていくことが必要ですが、「ネットワークの役割」としては最低限、図2のような構成が必要であることを覚えておいてください。

　なお、これらの「ネットワークの役割」を理解の上で、同一のネットワークに2つの役割を担わせる、例えば「クラスタ間通信用ネットワーク」と「ライブマイグレーション用ネットワーク」を同一のネットワーク（同一のVLAN）に乗せる、といった構成も可能です。

　これらについては、前述の通り、使用する物理ネットワークアダプターの通信速度を勘案して構成してください。

　この「ネットワークの役割」をどのようにして物理ネットワークに割り当てるか、設定方法を見ていきましょう。

　GUI（グラフィカルユーザーインタフェース）管理ツールである「フェールオーバークラスターマネージャー」を開き、クラスタ配下のネットワークを選択すると、クラスタで使用しているネットワークおよびネットワークに接続しているネットワークアダプターの一覧を確認できます（画面1）。

画面1　「フェールオーバークラスターマネージャー」でHyper-Vホストのネットワークの役割が確認できる

　画面1は、いわゆる管理用ネットワークを参照しています。この画面で、当該ネットワークに接続している各ホストのネットワークアダプター、ならびにIPアドレスを確認できます。

　他のネットワークとしては、クラスタ通信用のネットワークやストレージ通信用のネットワークなどが存在していることが分かります。ここに表示されるネットワークは、ホストOSでIPアドレスを設定可能で、通信可能なネットワークのみである点に注意してください。

　この画面には「クラスターの使用」という欄があり、そこには「クラスターのみ」や「クラスターとクライアント」といった記述があることが確認できます。

　この「クラスターの使用」は、当該ネットワークでクラスタ間通信を実施可能かどうかの設定箇所となっていて、それぞれ以下の表1ような意味があります。

「クラスターの使用」設定	詳細
クラスターとクライアント	クラスタネットワーク通信とクラスタアプリケーションの通信が許可され、管理通信も含め全ての通信が許可される
クラスターのみ	クラスタネットワーク通信のみを許可し、クラスタアプリケーションの通信は許可されない
なし	クラスタネットワーク通信を許可しないため、クラスタ間通信は使用不可
表1　「クラスターの使用」設定の詳細

　図2のネットワークの役割で考えた場合、iSCSIなどのストレージ用ネットワークはストレージ通信に専念すべきであり、そのネットワークでクラスタ間通信が行われるのは好ましくないともいえます。その場合は「クラスターの使用」を「なし」に設定することで、クラスタ通信が行われないように設定できます。

　設定自体は非常に簡単で、ネットワークの「プロパティ」内で設定できます（画面2）。

画面2　「クラスターの使用」設定は、ネットワークの「プロパティ」で実施可能

　デフォルト（既定）では、ネットワーク名は「クラスターネットワーク1」というような名前が付与されていますが、プロパティの「名前」で自由に変更可能です。ネットワークの役割が明確に分かるような名前を付けることが望ましいです。

　画面2のネットワークは、クラスタ間通信を担うネットワークと定義しているため、「このネットワークでのクラスターネットワーク通信を許可する」を選択の上、「クライアントにこのネットワーク経由の接続を許可する」のチェックボックスをオフにしています。

　この設定にすることで、クラスタ間通信のみを行うネットワークとすることができ、「フェールオーバークラスターマネージャー」上では「クラスターの使用」欄は「クラスターのみ」になります。

　前述したようなストレージ専用のネットワークにしたい場合には、「このネットワークでのクラスターネットワーク通信を許可しない」を選択することで、クラスタ間通信を許可しないネットワークにすることが可能です。この場合、「クラスターの使用」欄は「なし」になります。

　管理通信などを行わせる場合は必ず「クライアントにこのネットワーク経由の接続を許可する」のチェックボックスをオンにすることを忘れないでください。

　クライアント通信が許可されたネットワークがクラスタネットワーク内に存在しないと、画面3のようなエラーが記録され、クラスタリソースであるIPアドレスがオンラインになりません。

画面3　「クライアントにこのネットワーク経由の接続を許可する」が有効なネットワークが存在しないと、クラスタIPアドレスがオンラインにならない

　クラスタ間通信は、いわゆるクラスタノードの死活監視ともいえるハートビート通信（3343/UDP）の他、前回紹介したライブマイグレーション用の通信があります。

　ライブマイグレーション用のネットワークとして使用可能なネットワークも、優先順位を含め設定できます。

　ライブマイグレーション用のネットワークの設定は、Hyper-Vホストとフェールオーバークラスタリングの両方で行う必要があります。

　Hyper-Vホストの設定は「Hyper-Vマネージャー」の「Hyper-Vの設定」から行います（画面4）。

画面4　ライブマイグレーションに関する基本的なHyper-Vホストの設定

　このHyper-Vホストでライブマイグレーションを使用するかどうかの設定が可能で、有効化した際のライブマイグレーションの同時実行数、ライブマイグレーションで使用するネットワークを設定できます。

　複数の仮想マシンを同時にライブマイグレーションする場合は、「同時ライブマイグレーション」欄に適切な値を設定します。この値は、許容するライブマイグレーションの実行速度とライブマイグレーションに利用するネットワークの通信速度によって変わってくるため、運用の中で適切な値を見つける必要があります。

　ライブマイグレーションに使用するネットワークについては、ライブマイグレーション用のネットワークのみを使用するか、それとも到達性のあるネットワーク全てを使用するか、または指定した複数のネットワークを使用するかを設定できます。

　画面4では、クラスタ間通信用のネットワークをライブマイグレーション用のネットワークと兼用する形として、そのネットワークのみを使用する設定としています。

　「高度な設定」画面では、ライブマイグレーションで使用するプロトコルを指定できます（画面5）。

画面5　ライブマイグレーションに関する高度なHyper-Vホストの設定

　ここでは認証プロトコルやライブマイグレーションで使用するプロトコルが指定可能です。詳細に関しては、以下のMicrosoftのドキュメントを参照してください。

• フェールオーバー クラスタリングのないライブマイグレーションのためのホストの設定します。（Microsoft Learn）

　認証プロトコルについては、Active Directoryの制限付き委任が必要になりますが、明示的なログイン環境が必要ない「Kerberosを使用する」を選択した方がより安全といえるでしょう。また、パフォーマンスオプションについては、ネットワークアダプターでRDMA（Remote Direct Memory Access）が使用できる場合には「SMB」を選択することで、ハードウェアの力を借りた高速ネットワーク環境下でのライブマイグレーションを実行できます。

　RDMAやハードウェアアクセラレーションについては、別の回で解説します。

　フェールオーバークラスタリング側の設定は、「フェールオーバークラスターマネージャー」の「ネットワーク」→「ライブマイグレーションの設定」から行います（画面6）。

画面6　「フェールオーバークラスターマネージャー」でのライブマイグレーション設定

　ここではライブマイグレーションの通信を許可するネットワークと優先順位を指定できます。許可するネットワークを1つ、あるいは複数チェックし、優先するネットワーク順に上下で入れ替えることで設定が完了します。

　Hyper-Vホスト、およびフェールオーバークラスタリングの両方を設定することで、狙ったネットワークにライブマイグレーションの通信を通すことができます。

　なお、ライブマイグレーションを設定したネットワークが1つの場合、そのネットワークで障害などが発生すると、ライブマイグレーションが実行不可となります。実運用を考えた場合には、クラスタ間通信用ネットワークおよびライブマイグレーション用のネットワークは、冗長化の意味も含めて2つ用意した方がよいでしょう。

Hyper-Vの負荷分散機能

　クラスタ上で多数の仮想マシンが稼働している場合は、Hyper-Vホストごとに異なる負荷状況になる場合があります。例えば、クラスタを構成するあるHyper-Vホストでは仮想マシンの処理によりCPU利用率が80％を超え、他のHyper-VホストのCPU利用率が20％程度だった場合、仮想マシンを再配置して負荷を分散したいと考える管理者がほとんどではないでしょうか。

　他社ハイパーバイザーでも実装されている負荷分散機能ですが、Hyper-Vでもホストの負荷レベルを条件とした負荷分散（自動均衡化）機能が実装されています。

　設定自体は非常に簡単で、「フェールオーバークラスターマネージャー」でクラスタの「プロパティ」を開き、「バランサー」タブで機能の有効化、自動実行するタイミング、強度を設定します（画面7）。

画面7　「フェールオーバークラスターマネージャー」での自動均衡化（自動負荷分散）設定

　「仮想マシンの自動均衡化を有効にする」にチェックが入っている場合、当該クラスタで自動均衡化が有効で、「モード」および「強度」に応じた負荷分散が自動的に実施されます。

　「モード」は負荷分散を行うタイミングを指定するもので、「参加時にノードに負荷を分散する」を選択している場合には、クラスタに新しいHyper-Vホストが追加されたタイミングで負荷分散が自動実行されます。「仮想マシン」ではなく、「Hyper-Vホスト」がクラスタに追加されたタイミングであるという点に注意してください。

　「常に負荷を分散する」を選択している場合には、30分ごとにクラスタ内の負荷が評価され、「強度」で指定された負荷レベルを基準に、必要であれば負荷分散が行われます。

　負荷分散対象となった仮想マシンは、自動的にライブマイグレーションが行われます。ライブマイグレーションなので、仮想マシンの動作には影響を与えません。

　負荷分散の評価基準である「強度」は、画面7の通り3段階（高、中、低）の設定となり、表2のような条件となっています。

強度	詳細
高	クラスタ内のHyper-Vホストの負荷平均値を算出し、平均から5％を超えたHyper-Vホストの仮想マシンを他のHyper-Vホストに移行する
中	Hyper-Vホストの負荷が70％を超えていた場合に、低負荷のHyper-Vホストに仮想マシンを移行する
低	Hyper-Vホストの負荷が80％を超えていた場合に、低負荷のHyper-Vホストに仮想マシンを移行する
表2　負荷分散を評価する「強度」

　「強度」で評価される負荷ですが、これはCPU負荷およびメモリ負荷となっており、CPU利用率が低負荷でもメモリの利用率が80％を超えていた場合は、自動負荷分散の対象となって仮想マシンがクラスタ内の他のHyper-Vホストに移行されます。

　30分間隔の負荷分散ではなく、もっと短い間隔で負荷分散を積極的に行いたい場合には、Microsoftが提供する管理製品「Microsoft System Center Virtual Machine Manager」（SCVMM）を導入して、「コンピューティング動的最適化」（Dynamic Optimization：DO）を設定することでより短い間隔での負荷分散が可能になります。SCVMMのDOであれば最小10分間隔での負荷分散が実施可能です。必要であればSCVMMの導入も検討してみてください。

Hyper-Vのクラスターアフィニティ

　フェールオーバークラスタリングは複数のHyper-Vホストから構成されますが、同じ役割を持った仮想マシンであったり、2台の高負荷仮想マシンであったり、特定の組み合わせの仮想マシンを同一のHyper-Vホスト上で稼働させたくない、といった配置上のルールを設定したい場合があるでしょう。

　逆に特定の仮想マシン群を、システムの都合で必ず同じHyper-Vホスト上で稼働させたいというニーズもあるかと思います。

　これらの配置上の制御もフェールオーバークラスタリングの「クラスターアフィニティ」の機能を利用することで実現できます。グループに属する仮想マシンを異なるHyper-Vホスト上で稼働させる（アンチアフィニティ）こともできますし、同じHyper-Vホスト上で稼働させる（アフィニティ）こともできます。

　これらの「クラスターアフィニティ」の設定はGUIツールからではなくPowerShellで行いますが、2つのステップを踏む必要があります。

　最初のステップは「アフィニティルールの設定」で、「New-ClusterAffinityRule」コマンドレットを使用します。

　必要なオプションは、「ルール名」（Nameオプション）と「ルールタイプ」（RuleTypeオプション）の2つです。ルールタイプはアフィニティの場合は「SameNode」、アンチアフィニティの場合は「DifferentNode」を指定します（画面8）。

画面8　アフィニティル−ルの設定

　2番目のステップとしてアフィニティグループの作成とグループに所属する仮想マシンの定義を行います。使用するコマンドレットは「Add-ClusterGroupToAffinityRule」コマンドレットです。

　必要なオプションは、1番目のステップで作成した「アフィニティルール名」（Nameオプション）と「クラスタグループ名」（Groupオプション）です。クラスタグループ名には仮想マシン名を指定します。なお、クラスタグループ名は「Get-ClusterGroup」コマンドレットで確認可能です（画面9）。

画面9　アフィニティグループル−ルの設定

　Add-ClusterGroupToAffinityRuleコマンドレットを実行すると、設定したアフィニティルールに沿って仮想マシンの移行が行われます。万が一、アフィニティルールに沿った配置になっていなかった場合は、当該アフィニティルールが有効であるかどうかを確認してください。デフォルトで有効なはずですが、無効化されていた場合は「Set-ClusterAffinityRule」コマンドレットで有効化する必要があります（画面10）。

画面10　アフィニティグループル−ルの有効化

　アフィニティルールを設定後は、例えばアンチアフィニティを設定したTest-VM02をTest-VM03と同じHyper-Vホストに移行しようとしても、エラーが発生して移行できません（画面11）。

画面11　アンチアフィニティが設定された仮想マシンを同じHyper-Vホスト上へ移行しようとしても、移行作業がエラーで失敗する

　また、アフィニティを設定した仮想マシンを移行すると、残されたアフィニティが設定された仮想マシンも同じHyper-Vホストに自動的に移行されます。

Hyper-Vの「プロセッサ互換モード」とは

　「プロセッサ互換モード」はフェールオーバークラスタリングの機能というよりは、Hyper-Vの機能になります。しかし、仮想マシンの移行を考えた際には、非常に重要な機能となるため、高度な機能の一つとして紹介します。

　よくあるシナリオで考えてみましょう。クラスタを構成するHyper-Vホストのリソースが足りなくなり、Hyper-Vホストを増設する必要が出てきました。このクラスタは数年前に導入されたもので、同じCPUは既に生産終了となっています。そこで新しいCPUを搭載したHyper-Vホストをクラスタに参加させました。

　こうしたシナリオはよくある話かと思いますが、世代の異なるCPUのHyper-Vホスト間で仮想マシンを移行しようとした場合、画面12のようなエラーが表示されて移行が失敗することがあります。

画面12　世代の異なるCPUを搭載したHyper-Vホスト間でライブマイグレーションを行った場合、ライブマイグレーションに失敗することがある

　世代の異なるCPUでは搭載されている機能が異なる場合が多く、機能差異によってCPUの互換性が確保できずにライブマイグレーションが失敗する、という事象になります。

　世代の異なるCPUを搭載したHyper-Vホスト間であってもクラスタを構築できますが、ライブマイグレーションができないという運用上致命的な問題を抱えてしまいます。

　これに対応するために、Hyper-Vではプロセッサ互換モードと呼ばれる機能を搭載しています。これは互換性の確保を目的とし、あえてCPUの機能を制限する（マスクする）機能になります。

　プロセッサ互換モードは仮想マシン単位で設定します。仮想マシンの「設定」→「プロセッサ」配下の「互換性」の項目で設定できます（画面13）。

画面13　プロセッサ互換性モードの設定画面

　「プロセッサバージョンが異なる物理コンピュータへ移行する」のチェックをオンにすることで、その仮想マシンはプロセッサ互換モードで動作するようになります。なお、プロセッサ互換モードは、仮想マシンが電源オフの状態でしか設定できません。

　プロセッサ互換モードを有効化すると、異なるバージョンのCPU間でのライブマイグレーションが可能になる半面、CPUの機能を限定してしまうため、パフォーマンスに影響が及ぶ可能性があります。特にハードウェア最適化に大きく依存した機能を使用するワークロードでは、顕著なパフォーマンス劣化が発生する可能性があります。プロセッサ互換モードを使用する際は、ベンチマークテストなどを通じたパフォーマンス評価が必須といえるでしょう。

　このパフォーマンスへの影響を抑えるため、「Windows Server 2025」のHyper-Vでは、構成バージョンが「10」以降の仮想マシンに限り、「動的プロセッサ互換モード」を使用できます。

　Windows Server 2025のHyper-Vでは動的プロセッサ互換モードと「標準プロセッサ互換モード」を選択して使用することができます。

　標準プロセッサ互換モードの場合は、Hyper-Vホストやクラスタの機能に関係なく、固定のプロセッサ機能セットを使用して最大の互換性を確保します。動的プロセッサ互換モードの場合は、クラスタを構成するHyper-Vホストのプロセッサ機能を動的に計算し、クラスタ内で共通で使用できる機能は使用するように制限機能を動的に変更します。

　この動的プロセッサ互換モードを利用することで、クラスタ全体で使用できる最大機能を利用し、パフォーマンスへの影響を最小限に抑えることができます。

　プロセッサ互換モードの切り替えは、GUIではなくPowerShellの「Set-VMProcessor」コマンドレットで行います（画面14）。

画面14　PowerShellによるプロセッサ互換性モードの切り替え

　動的プロセッサ互換モードを使用する場合は「-CompatibilityForMigrationMode」オプションで「CommonClusterFeatureSet」を指定します。標準プロセッサ互換モードの場合は「MinimumFeatureSet」を指定します。

　Set-VMProcessorコマンドレットを実行する際は、仮想マシンは電源オフ状態である必要がありますので注意してください。

　なお、プロセッサ互換モードはあくまでCPUの機能を制限することで互換性を確保する機能であり、メーカーの差異までを吸収するものではありません。従って、Intel CPU搭載Hyper-VホストからAMD CPU搭載Hyper-Vホストへのライブマイグレーション、もしくはその逆を行うことはできないので注意してください。

　また、プロセッサ互換モードはあくまでもライブマイグレーションを行う際に必要な機能であり、仮想マシンの停止と再起動を伴うことに問題がなければ、プロセッサ互換モードを利用する必要はありません。仮想マシンの電源投入時に使用可能なCPUの機能を確認し、利用できるためです。

　今回はフェールオーバークラスタリングの高度な機能について見てきました。次回はHyper-Vの高度な機能の一つでもある「ハードウェアオフロード」機能について、その概要を紹介します。

筆者紹介

後藤 諭史（ごとう さとし）

株式会社ネットワールド所属。Microsoft MVP for Cloud and Datacenter Management（2012-2025）。現業の傍ら、コミュニティーイベントでの登壇や著作にてMicrosoftテクノロジーに関する技術情報の発信、共有を続けている。ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。近著は『詳解! Windows Server仮想ネットワーク』（日経BP社）。