こんにちは。SB C&Sの湯村です。「基礎から学ぶ！Hyper-V 仮想化入門」シリーズ第4回は、「フェールオーバークラスターの構築」です。仮想マシンの可用性を担保するために重要なフェールオーバークラスターについてご紹介します。

1. フェールオーバークラスターとは？

1.1. フェールオーバークラスターの基本

フェールオーバークラスターは、第6回の記事でご紹介する予定の「ライブマイグレーション」や「フェールオーバー」といった仮想マシンの可用性を保つ機能を使用するために必要になりますので、事前に学習しておきましょう。

Hyper-Vホスト上の仮想マシンには、重要な業務を担うサービスが稼働していることが一般的です。たとえば、企業の社内システムが仮想マシンで稼働している場合、社員が業務時間中は常に   システムへアクセスできるようにする必要があります。これを「可用性（Availability）」と呼びます。

仮想マシンが稼働する基盤には物理ハードウェアが使われていますが、ハードウェアは消耗品であるため、故障の恐れが常につきまといます。そのため、仮想マシンの可用性を担保するためには、ハードウェアが故障した場合を考慮することが大切です。

フェールオーバークラスターとは、「複数台のノードがまとめられ、あたかもひとつのノードとして稼働する」技術であり、Windows Serverの標準機能として提供されている 「フェールオーバークラスタリング」をインストールすることで使えるようになります。 

フェールオーバークラスターの構成によって、あるノードが障害を起こした場合でも他のノード上で仮想マシンが自動的に再起動されることで、サービスの継続が可能になります。この一連の動作を「フェールオーバー」と呼びます。また、サービスが稼働していたサーバーのことを「アクティブノード」、フェールオーバー先のノードを「スタンバイノード」と呼びます。このように、フェールオーバークラスターはサービスの可用性を担保するためにとても重要な技術です。

フェールオーバークラスター上で「ライブマイグレーション」や「フェールオーバー」のような仮想マシンの可用性を保つ機能を使用するには "共有ストレージ" が必要になります。共有ストレージについては「第５回 クラスター共有ボリュームの作成」でご紹介しますので、今回はフェールオーバークラスターのみを先に構築します。

1.2. フェールオーバークラスターに必要不可欠な「クォーラム」とは？

ここで、フェールオーバークラスターを構築するときに重要な要素をご紹介します。それは「クォーラム（Quorum）」という概念です。

先ほどもご紹介した通り、フェールオーバークラスターを構築すればサービスの可用性を担保できるようになりますが、サービスにアクセスできなくなる原因はハードウェアの障害だけではなく、ネットワークの障害が原因となることも考えられます。

たとえば、下図のようにノード間のネットワークに何らかの異常が発生して通信が失われた場合、クラスターが分断されてしまいますが、各ノードおよびサービスは稼働し続けています。 この状態は「スプリットブレイン」と呼ばれます。こうなると、それぞれのノードから同じディスクに書き込みが行われるため、データが破損したりロストしてしまう恐れがあります。

フェールオーバークラスターは「クォーラム」という概念を導入することで、その問題を防ぐように設計されています。クォーラムを一言で説明すると、「クラスターが正常稼働するために必要なノード数を "投票" で決定する仕組み」です。例として、下図のような３ノード構成のクラスターを例にご説明します。

クラスターに属するノード#1,#2,#3のうち、ネットワーク障害によりノード#1とその他のノードが疎通できなくなると、ノードセットとして「ノード#1」と「ノード#2,#3」のように分断されます。この場合、どちらのノードセットをクラスターとして認識するべきか決定するために、クォーラムの概念が使用されます。

クォーラムは、クラスターに属するノードに "投票" が与えられ、過半数の投票を持つノードセットがクラスターの稼働を継続します。

クラスターが3ノードで稼働している場合は既にノード数が奇数であるため、全てのノードに投票が自動で行われます。この状態でクラスターが分断されると、「ノード#1」は投票数が1、「ノード#2,#3」のセットは投票数が2となります。そのため、過半数の投票を持つノードセット「ノード#2,#3」が正常なクラスターであると認識し、サービスを稼働し続けることができます。

では、ノード数が偶数の時はどうなるでしょうか？クラスターが4ノードで構成されている場合は、「ノード#1,#2」と「ノード#3,#4」のように分断されると、投票数がそれぞれ2票ずつになるため、どちらのノードセットをクラスターとして稼働させるか判別できなくなってしまいます。そこで、1台のノードには投票しない（投票数0票）ようにすることで、片方のノードセットが過半数の投票数を持てるように、自動で調整してくれます。

ここでひとつ問題が生じます。それは2ノードで構成されるクラスターの場合です。

ここまで、3ノード以上の場合を例にしてクォーラムの動作をご紹介しましたが、3ノードの場合は1台のノード障害が発生しても残りの2ノードでクラスターは稼働します。また、4ノードの場合は2台のノード障害が発生しても残りの2ノードでクラスターは稼働し続けます。

しかし、残りの2ノードのうち片方に障害が発生した場合はどうなるでしょうか？下図を参考にしてご紹介します。

2ノードクラスターは偶数ノードになるため、片方のノードには投票され、もう1台のノードには投票されない状態になります。この状態で、投票されなかったノードが予期せず停止してしまった場合は、投票された１台でクラスターは稼働し続けますが、投票されたノードが停止した場合はクラスターが完全に停止してしまいます。

このような状態を防ぐため、偶数ノードでフェールオーバークラスターを構成している場合は、"監視（Witness）" と呼ばれる役割を用意することで、ノードの合計数を奇数にすることが推奨されています。フェールオーバークラスターにおいて、監視の種類は以下の3つで、いずれの方式でも、利用するストレージには、クラスターの全てのノードがアクセスできる必要があります。

• 【ディスク監視】：クラスターの全てのノードがアクセスできる共有ディスク。クラスター共有ボリュームとして使用するiSCSIターゲットなどにボリュームを作成して使用する。
• 【ファイル共有監視】：Windows Serverを実行しているファイルサーバー上に構成したSMBファイル共有フォルダ。クラスター共有ボリュームを構成していない場合はこの構成を選択する。
  ※今回構築する環境では、ファイル共有監視を使用したクォーラムを構成します。
• 【クラウド監視】：Azure上のBlob Storage。

下図は２ノードクラスターの例ですが、監視を追加することで全体のノード数が３台（奇数）となるため、監視を含めた全てのノードに投票がされます。この状態であれば、いずれかのノードが停止したとしてもクラスターは稼働しつづけることができます。

少々長くなりましたが、フェールオーバークラスターにおいて重要な「クォーラム」についてご紹介しました。可用性を保つためには監視の存在は非常に大切で、とりわけ２ノードクラスターでは必須となることがおわかりいただけたと思います。

2. 本記事での構築対象

今回使用した環境については以前の記事と変わりませんので、「第1回 Hyper-Vのインストール」をご覧ください。

本記事では下図の赤枠部分である、「Hyper-Vホスト1」と「Hyper-Vホスト2」によるフェールオーバークラスターを構築します。

3. クラスター用 DNS レコードの登録

フェールオーバークラスター用のホスト名と仮想IPアドレスをDNSサーバーに登録します。

フェールオーバークラスターは、クラスターに所属するノードと同様に、Active Directoryにコンピューターアカウントとして登録されます。そしてクラスターを管理するために、[ホスト名（クラスター名）] と [IPアドレス] のセットが必要になります。

このアドレスは、ユーザーから稼働するサービスにアクセスする際に意識されることはありませんが、クラスターが複数ノードをまとめてリソース管理をするうえで（つまりHyper-Vホストでの仮想マシン管理のために）必要です。Hyper-Vホスト障害時などには、正常稼働しているノードホストへのフローティングIPのように動きます。  

1. サーバーマネージャーからDNSを起動します。

• サーバーマネージャーで [ツール] をクリックします。
• [DNS] をクリックします。

2. フェールオーバークラスターのレコードを登録します。

• 左ツリーから [hv.lab] を右クリックします。
• [新しいホスト（A または AAAA）] をクリックします。

3. フェールオーバークラスターのレコードを登録します。

• 「名前」に [hv-cluster] を入力します。
• 「IP アドレス」に [10.1.5.115] を入力します。
• [ホストの追加] をクリックします。

4. [OK] をクリックします。

5. [完了] をクリックします。

4. フェールオーバークラスターの構築

Windows Serverの標準機能である「フェールオーバークラスタリング」をHyper-Vホストにインストールし、フェールオーバークラスターを構築します。

4.1.「フェールオーバークラスタリング」のインストール

「フェールオーバークラスタリング」はクラスターに属する全てのHyper-Vホストに対してインストールする必要があります。忘れずに行いましょう。

1. サーバーマネージャーからフェールオーバークラスタリングの役割を追加します。

• サーバーマネージャーで [管理] をクリックします。
• [役割と機能の追加] をクリックします。

2.「開始する前に」ページでは [次へ] をクリックします。

3.「インストールの種類の選択」ページでは以下の手順を実行します。

• [役割ベースまたは機能ベースのインストール] を選択します。
• [次へ] をクリックします。

4.「対象サーバーの選択」ページでは以下の手順を実行します。

• [サーバー プールからサーバーを選択] を選択します。
• サーバープールのリストから、[hv-host1.hv.lab] を選択します。
• [次へ] をクリックします。

5.「サーバーの役割の選択」ページでは、そのまま [次へ] をクリックします。

6.「機能の選択」ページでは、[フェールオーバー クラスタリング] にチェックを入れます。
※チェックを入れようとすると次手順のウィザードが開きます。

7. フェールオーバークラスタリングに必要な機能を追加するため、[機能の追加] をクリックします。

8. [次へ] をクリックします。

9.「インストール オプションの確認」ページで、[インストール] をクリックします。

10. インストールが正常に完了したことを確認し、[閉じる] をクリックします。

4.2. フェールオーバークラスターの構築

フェールオーバークラスタリングをインストールすると、フェールオーバークラスターマネージャーがツールに追加されます。フェールオーバークラスターマネージャーでは、クラスターの作成や、クラスター作成後の仮想マシン操作も実行できます。第1回記事でご紹介したHyper-Vマネージャーは、Hyper-Vホスト単体に対して操作するためのツールであり、フェールオーバークラスターを構築した後はフェールオーバークラスターマネージャーからほとんどの操作を行うようになります。VMwareによる仮想化基盤でいうと、ESXiとvCenter Serverの関係性に似ています。

1. サーバーマネージャーからフェールオーバークラスターマネージャーを起動します。

• サーバーマネージャーで [ツール] をクリックします。
• [フェールオーバー クラスター マネージャー] をクリックします。

2.「構成の検証ウィザード」を起動し、適切なクラスター構築環境であるか検証します。

• 左ペインで [フェールオーバー クラスター マネージャー] を右クリックします。
• [構成の検証] をクリックします。

3.「開始する前に」ページでは、[次へ] をクリックします。

4.「サーバーまたはクラスターの選択」ページでは、以下の手順を実行します。

• 「名前の入力」欄に、[hv-host1;hv-host2] を入力します。
  ※クラスターに属する全てのホストを一度に追加するには、セミコロン(;)で区切って入力します。
• [追加] をクリックします。

5.「選択済みサーバー」欄にHyper-Vホストが表示されていることを確認し、[次へ] をクリックします。

6.「テスト オプション」ページでは、以下の手順を実行します。

• [すべてのテストを実行する（推奨）] を選択します。
• [次へ] をクリックします。

7.「確認」ページでは、[次へ] をクリックします。

8. 検証が完了すると「概要」ページに検証結果が表示されます。この画面で [レポートの表示] をクリックすると、検証結果の詳細がブラウザで表示されます。警告がある場合は、何が問題になっているのかも表示されますので、ここで問題を解消してからクラスターを作成しましょう。
※事前に各ノードに対してWindows Updateを適用していないと警告が返されますが、ひとまず検証環境構築を進めたい場合は、クラスター構築後に適用しても問題ありません。  

＜フェールオーバークラスター検証レポート＞

9. 警告が無いことを確認したら [完了] をクリックしてウィザードを閉じます。

10.「クラスターの作成ウィザード」を起動します。

• 左ペインで [フェールオーバー クラスター マネージャー] を右クリックします。
• [クラスターの作成] をクリックします。

11.「開始する前に」ページでは、[次へ] をクリックします。

12.「サーバーの選択」ページでは、以下の手順を実行します。

• 「サーバー名の入力」欄に、[hv-host1;hv-host2] を入力します。
  ※クラスターに属する全てのホストを一度に追加するには、セミコロン(;)で区切って入力します。
• [追加] をクリックします。

13.「選択済みサーバー」欄にHyper-Vホストが表示されていることを確認し、[次へ] をクリックします。

14.「クラスター管理用のアクセス ポイント」ページで、クラスター情報を入力します。

• 「クラスター名」に、[hv-cluster] を入力します。
• [ここをクリックしてアドレスを入力してください] をクリックします。

15. クラスター用のIPアドレスを設定します。

• クラスター用のIPアドレス [10.1.5.115] を入力します。
• [次へ] をクリックします。

16.「確認」ページでは、[次へ] をクリックします。

17. クラスターの作成が完了し、「概要」ページが表示されたのち [完了] をクリックしてウィザードを閉じます。

18. フェールオーバークラスターマネージャーにクラスター名 [hv-cluster.hv.lab] が表示されていることを確認します。

5. クォーラムの設定

冒頭でご紹介した通り、今回構築する環境は2ノードクラスター構成ですので、監視を追加してクォーラムによる可用性を高めます。今回は「ファイル共有監視」の構築手順をご紹介します。

1. クォーラムを設定する前の各ノードの投票状況を確認します。

• [hv-cluster.hv.lab] 内にある [ノード] をクリックします。
• 各ノードの「現在の投票」欄が [0][1] になっていることを確認します。
  ※[1] のノードが投票されているノード、[0] のノードが投票されなかったノードです。

2. クラスタークォーラム構成ウィザードを起動します。

• [hv-cluster.hv.lab] を右クリックします。
• [他のアクション] をクリックします。
• [クラスター クォーラム設定の構成] をクリックします。

3.「開始する前に」ページでは [次へ] をクリックします。

4.「クォーラム構成オプションの選択」ページでは以下の手順を実行します。

• [クォーラム監視を選択する] を選択します。
• [次へ] をクリックします。

5.「クォーラム監視の選択」ページでは以下の手順を実行します。

• [ファイル共有監視を構成する] を選択します。
  ※ディスク監視を選択する場合は、ディスク監視用のiSCSIターゲットを事前に用意しておく必要があります。iSCSIターゲットの作成方法は「第5回 クラスター共有ボリュームの作成」に記載していますので、参考にしてみてください。
• [次へ] をクリックします。

6.「ファイル共有監視の構成」ページで [参照] をクリックします。

7.「共有フォルダーの参照」でファイル共有監視先の情報を指定します。
※今回の環境では、AD兼DNSサーバー（hv-ad）のCドライブ直下にファイル共有のフォルダ [FileShareQuorum] を事前に用意しています。

• 「サーバー」欄にファイル共有フォルダのIPアドレス [10.1.5.113] を入力します。
• [共有フォルダーの表示] をクリックします。
• [FileShareQuorum] を選択します。
• [OK] をクリックします。

8. [次へ] をクリックします。

9.「確認」ページでは [次へ] をクリックします。

10. クォーラムの設定が正常に終了したら [完了] をクリックします。

11. 監視欄に [ファイル共有監視] が表示されていることを確認します。

12. クォーラムを設定した後の各ノードの投票状況を確認します。

• [hv-cluster.hv.lab] 内にある [ノード] をクリックします。
• 各ノードの「現在の投票」欄が [1][1] になっていることを確認します。
  ※監視を追加したことで、どちらのノードにも投票されています。

6. TIPS ~ Active Directory に依存しないクラスター ~

フェールオーバークラスターについてご紹介しましたが、構築するには "基本的に" Active Directoryドメインが必要で、クラスターに参加する全てのサーバーは、同じADドメインに参加している必要があります。

しかしWidows Server 2016からは、ADドメインで構成されるクラスターに加えて、ADドメインに依存しないクラスター「ワークグループクラスター」を構成できるようになりました。
※ワークグループクラスターでもDNSは必要です。

たとえば、ADに依存せず、ユーザー管理でIDaaS（Identity as a Service）を利用していたり、デバイス管理でUEM（Unified Endpoint Management）を利用している企業もあります。そのような環境でも、Hyper-V管理のためだけに新規のADを用意することなくフェールオーバークラスターを導入できます。

ここまで聞くとメリットしかないように思うかもしれませんが、制約もちゃんとあります。ワークグループクラスターの制約は、「ライブマイグレーションがサポートされていない」ことです。ライブマイグレーションは仮想マシンの電源をオンにしたまま別のホストに移動させることができる機能です。仮想化基盤を運用する上ではとても大切な機能ですが、それができません。

仮想マシンの電源をオフにした状態であれば別のホストに移動させることはできますが（クイックマイグレーション）、わざわざ電源をオフにするのは面倒ですよね。そのため、仮想マシンが乱立しているような中規模から大規模の環境にワークグループクラスターを導入する際は注意しましょう。

なお、本記事の執筆時点ではWindows Server 2025（プレビュー版）が公開されており、このバージョンからワークグループクラスター構成でもライブマイグレーションができるようになっています。製品版が公開されるのが楽しみですね！

今回は、Hyper-V仮想化基盤において重要な要素であるフェールオーバークラスターについてご紹介しました。次回の記事では、クラスターの共有ストレージとして使用する「クラスター共有ボリューム」をご紹介します。