2025年のSIer界隈（というか当社内）で非常にホットなお話として、Broadcom社によるVMware社買収に伴うESXi/vSphereライセンス提供の大規模変更があります。新聞・ネットニュースでも出ていますがライセンス料金、販売パートナー契約もほぼ変更になります。そんなこんなで脱VMWareを進めているユーザも多く出ています。今回の記事はESXi構成で冗長化された仮想環境からの置き換えを「WindowsServer Hyper-Vフェールオーバークラスター構成」でやろうとするとどんな感じになるのかをまとめたものです。情報量が多くなるので、概要編と構築編で分割して記事にします。

ESXi(置き換え元)の構成イメ―ジ

vSphereクラスターで複数のESXiがクラスター化されており、データストレージは各サーバの内蔵ディスクをvSANで仮想化、統合された環境を想定しています。

WindowsServerでの構成イメージ

今回のお試し環境ですが物理構成図はこんな感じです。

システム概念図はこんな感じです。

今回のゴール

WindowsServerOSでHyper-Vフェールオーバークラスタ構成を構築する。
具体的な機能要件としては

仮想サーバを複数台運用できること
物理サーバを複数台で構成し、1台の物理サーバで障害(OS停止やNW断)が発生しても別物理サーバ上で仮想サーバが継続して動作（フェールオーバー）すること
障害発生の際に手動ではなく、自動的にフェールオーバーすること
外部ストレージとiSCSIで接続し、外部ストレージをクラスター共有ボリュームにする

フェールオーバーとは？
稼働中のシステムやサーバーに障害が発生して停止してしまった際に、自動的に予備（待機）システムに切り替えて、システムの稼働を継続させるための機能。

クラスター構成とは？
複数のコンピューター（サーバー）を連携させて、あたかも1台のコンピューターであるかのように機能させるシステム構成のこと

前提条件(免責事項)

クラスターノード用物理サーバ(WindowsServerOS入り)が２台必要
物理サーバにはNICが2枚以上搭載されていること
データストレージとしてiSCSI接続可能なNASが必要
Witness(何ものかは後述)用に物理もしくは仮想WindowsServerが１台必要
AD環境が必要(今回はWitnessがADサーバを兼任)
当方はマイクロソフト社とは関係ありませんので、設定は自己責任でお願いします

AD環境は厳密には必須ではありませんがWorkgroup環境では一部実現できない機能が出てきます。

構築・導入する設定

①フェールオーバークラスタリング

システムの可用性を高めるための構成で、レプリカ構成もありますがクラスター構成とは下記差異があります。

クラスター構成とレプリカ構成の差異
Hyper-V レプリカ機能のフェールオーバーは、主に災害対策などの目的で利用される機能のためホストOSの障害時に自動でフェールオーバーを実行する機能ではありません。Hyper-V レプリカ機能でのフェールオーバーの実行は、クラスター構成とは異なり、手動実行する必要があります。

＜Microsoft Japan Windows Technology Support Blog＞
https://jpwinsup.github.io/blog/2017/02/24/Hyper-V/UnplannedfailoverinHyper-VReplica/

今回は自動的にフェールオーバーする構成にするので、クラスター構成にします。

②クラスター監視(Witness)

クラスター構成では、それぞれ独立したサーバが複数台存在しますが１つのデータストレージを共有することで、どのサーバを使っても同じ状態にすることができます。ただ複数サーバあるが故に「スプリットブレイン」と呼ばれる状態（ネットワーク分断などにより、同時にデータ書き込みでデータの一貫性が失われたり、処理の競合が発生する危険な状態）が発生する恐れがあります。スプリットブレインを防ぎ、クラスター全体のデータ整合性と高可用性を維持するためにクラスター監視(Witness)は必要となります。

図にするとこんな感じです。

クラスター監視(Witness)なしの場合

クラスター監視(Witness)ありの場合

監視方法は下記３つの方式があります。　※本記事ではファイル共有監視を設定してます

ディスク監視（Disk Witness）: 共有ストレージ上にごく小さなファイルを作成し、それを監視役とします。
ファイル共有監視（File Share Witness: FSW）: クラスター外のファイルサーバー上の共有フォルダを監視役とします。
クラウド監視（Cloud Witness）: Azureなどのクラウドストレージを監視役とします。

Hyper-Vクラスター構成では、どのサーバがプライマリー（アクティブ状態）になるかはノード間の多数決で決まる仕組みになっています。そのため厳密にいえば奇数台のクラスター構成の場合はクラスター監視(Witness)はなくても問題ありませんが、偶数台の場合は必須となります。

Witnessノードとは？

クラスター内のノードが、自分たちの間で「誰がクラスターの正当なリーダーであるか」「クラスターが正常に稼働しているか」を判断する際に、第三者的な投票権を持つ存在です。そのためWitnessノードはクラスターには含めないのが一般的です。

③クラスター共有ボリューム(CSV)

複数のクラスターノードが同時に同じ論理ディスク（ボリューム）にアクセスできるようにするための機能です。フェールオーバーに対応したHyper-Vで作成する仮想マシンのデータ格納先として利用します。

クラスターに属する複数のHyper-Vホストが、同じディスクにアクセスできるようになります。これにより、仮想マシンを電源オンにしたまま別のホストに移動する、ライブマイグレーションが実行可能になります。

参照 https://licensecounter.jp/engineer-voice/blog/articles/20240902_kiso_hyper-v_5_csv.html

今回の環境では外部ストレージNASのデータ領域をiSCSIでサーバにマウントして、そのデータ領域をクラスター共有ボリューム(CSV)として利用します。

記憶域スペースダイレクト(S2D)を利用しない理由

クラスター共有ボリューム(CSV)用のデータストレージとして、記憶域スペースダイレクト(S2D)を使う構成も可能ですが下記要件、理由により今回は利用しません。

S2Dの要件としては、以下のいずれかのコントローラーを使用する必要があります。

HBA (Host Bus Adapter): RAID機能を持たないシンプルなディスクコントローラー。これがS2Dで最も推奨される構成です。
パススルーモード（HBAモード）に設定されたRAIDコントローラー: ハードウェアRAIDコントローラーであっても、RAID機能を無効にして、接続されているディスクを個々のドライブとしてOSに直接提示する「パススルーモード」や「HBAモード」に設定できるものであれば使用可能です。

実質ハードウェアRAIDをしないディスク構成になるため、クラスター化によりシステム全体の可用性は上がるとは言え単体の物理サーバOSの可用性は下がります。物理サーバ2台のクラスター構成の場合、それぞれ物理サーバのディスクが1本ずつ故障すると2台ともダウンしてアウトなため、本当に耐障害性が高いのかは怪しいと感じます。一方で外部ストレージをクラスター共有ボリュームにする場合、それぞれの物理サーバのディスクをRAID5にしておけば1本ずつ故障してもシステムは止まりません。

次回記事について

どのような仕組みを使うのか、どういう仕様なのを本記事で記載しました。次回「構築編」で実際の設定画面を元に参考手順を記事にします。お楽しみに。