Hyper-Vホストをセキュリティ要件でワークグループ運用にしつつ、ゲストVMはAD参加してSQL Server FCIを組みたい──この要件は実現できます。鍵は「ホストの可用性」と「ゲスト内WSFC/FCI」を分け、共有ストレージの渡し方を正しく選ぶことです。
結論：ホストがワークグループでも、ゲストVM（AD参加）でSQL Server FCIは構成できる
結論から言うと、Hyper-Vホストがワークグループでも、ゲストVMをActive Directory（AD）に参加させてSQL Server Failover Cluster Instance（FCI）を構成すること自体は可能です。ホストがADに参加していないことは、ゲストOSのドメイン参加や、ゲストOS内で動くWindows Server Failover Clustering（WSFC）の成立条件にはなりません。
不安になりやすいのは「共有ストレージをどうやってゲストに渡すか」です。ここを押さえると、設計の迷いが一気に減ります。
まず整理：今回の「クラスタ」は2階層で別物
今回の構成は、実は“ホスト側の可用性”と“ゲスト側のアプリ可用性（SQL FCI）”の2つを同時に考える必要があります。混ぜて考えると「ホストがワークグループだからダメなのでは？」となりがちなので、役割で切り分けます。
| 層 | 何を守るか | 技術要素 | AD参加の必須性 | 今回の要件との関係 |
|---|---|---|---|---|
| ホスト層 | VMそのもの（移動・再起動・再配置） | Hyper-V / （必要なら）ホスト側Failover Cluster / CSV | 構成次第（後述） | セキュリティ要件でワークグループ運用にしたい |
| ゲスト層 | SQL Serverインスタンス（FCI） | ゲストOS内WSFC + 共有ストレージ + SQL Server FCI | 一般に必須（FCIの名前解決・認証） | ゲストVMはAD参加できる前提 |
ポイントは、ゲスト層のWSFC/FCIが必要とするのは「ゲスト同士でのAD認証」と「両ノードから見える共有ストレージ」であり、ホストがAD参加かどうかは本質ではありません。
「共有ボリュームをVMに渡せるか？」は、渡し方を選べば解決する
HP MSAのようなFibre Channel（FC）共有ストレージがある場合、共有ディスクをゲストVMに渡す方法は複数あります。大きく分けると次の3パターンです。
| 方法 | 共有ディスクの見え方 | ホスト側クラスタの要否 | 向いているケース | 注意点 |
|---|---|---|---|---|
| Virtual Fibre Channel（vFC） | VMがFC-SANに直接接続（LUNがVMに見える） | 不要（VM可用性まで狙うなら別途検討） | FC-SANがあり、NPIVが使える。構成を素直にしたい | HBA/SAN/ゾーニング設計、ゲスト内MPIOが重要 |
| ゲストOS内iSCSI | VMがiSCSIターゲットへ接続（LUNがVMに見える） | 不要 | ストレージがiSCSI提供できる/ネットワーク分離できる | ネットワーク設計がシビア（MTU/帯域/冗長） |
| ホスト側CSV上のVHD Set（.vhds）を共有 | VMが“共有仮想ディスク”を共有（ゲストからは共有ディスク） | 通常は必要 | 物理LUNをVMへ直接渡せない/運用をHyper-V側で完結したい | ホストクラスタの設計・サポート範囲に注意 |
このうち、FC接続のHP MSAを使ってSQL FCIを組むなら、まず検討したいのはVirtual Fibre Channel（vFC）です。Hyper-Vの仮想FCは、VMからSANへ直接接続でき、ゲストOS内で共有ストレージを使ったクラスタリングが可能になります。
推奨パターン：Virtual Fibre Channelで「VMにLUNを直接提示」してSQL FCIを組む
ワークグループ運用のホストでも実現しやすく、構造も分かりやすいのがこのパターンです。ホスト側はあくまでHyper-VとしてVMを動かし、共有ディスクはゲストがSANから直接受け取ります。結果として、「ホストのAD参加有無」と「SQL FCIの共有ストレージ」が切り離され、セキュリティ要件とも両立しやすくなります。
Virtual Fibre Channelの前提条件（ここが満たせれば強い）
- Hyper-VホストにFC HBAが搭載され、仮想FCに対応したドライバであること
- SAN側がNPIV（N_Port ID Virtualization）に対応していること
- VMのゲストOSがWindows Server 2012以降で、仮想FCアダプターをサポートすること
Microsoftのドキュメントでも、仮想FCにはNPIV対応SANや対応HBAなどの前提が示されています。
構成イメージ
（物理）Hyper-V Host A（WG） （物理）Hyper-V Host B（WG）
| \\ // |
| \\ FC Fabric 1/2 // |
| \\ // |
+------ HP MSA（FC-SAN：共有LUN）------+
| |
（VM）SQL01（AD参加） （VM）SQL02（AD参加）
| vFC×2 | vFC×2
+---- 共有LUN（Data/Log/TempDB/Quorum 等） ----+
（ゲスト内WSFC） → （SQL Server FCI）手順の全体像（ホスト側→SAN→ゲスト側）
- ホスト側で仮想SAN（Virtual SAN）を定義し、VMに仮想FCアダプターを付与する
- 可能なら各SQL VMに仮想FCアダプターを2本（冗長）
- WWNは自動生成でもよいが、運用を考えると固定（静的WWN）で管理した方がトラブルシュートしやすい
- SAN側でゾーニング/マスキングを行い、VMのWWNに対してLUNを割り当てる
- 「ホストの物理WWN」ではなく「VMの仮想WWN」に対して割り当てる点が重要
- SQL用LUN（Data/Log/TempDB/Quorumなど）を用途別に分けると、I/Oの性質が違うものを分離できる
- ゲストOSでMPIOを構成し、共有LUNを認識させる
- FC-SANの冗長パス前提なら、MPIOを入れないと「片系断」でストレージが落ちたように見える
- クラスタ用途では、ストレージスタック（HBA/ドライバ/MPIO等）をノード間で揃えるのが基本
- ゲストVM同士でWSFC（Windows Server Failover Cluster）を作成し、共有ディスクをクラスタディスクとして追加
- クラスタ検証（Validate Configuration）は必ず実施し、ストレージ/ネットワークの警告を潰す
- 2ノード構成ではクォーラム（ウィットネス）設計が安定性に直結する
- SQL Server FCIをインストール（1台目で新規、2台目でノード追加）
- FCIはWSFCのリソースグループとして動作し、ネットワーク名・IP・共有ディスクなどを束ねてフェールオーバーします
- 共有ストレージは、iSCSI/FCなどのクラスタディスクやSMBファイル共有など幅広い方式がサポートされます
ゲスト側WSFC/FCIで「ここだけは外さない」設計ポイント
| 項目 | 推奨 | 理由 |
|---|---|---|
| IPアドレス | 静的IP | FCIはDNS登録と接続継続性が重要。DHCPは運用上の不確実性が増える |
| 共有ディスクの分割 | Data/Log/TempDB/Quorumを分ける | I/O特性が違うため、性能・障害切り分け・拡張が楽になる |
| ウィットネス | 安定した第三地点（ファイル共有/クラウド/ディスク） | 2ノードは分断時に“どちらが正か”の判断が難しいため |
| 名前解決 | クラスタ名/FCI名がDNSで確実に引ける | クライアントは“名前”で接続するため、DNSが不安定だと障害に直結 |
SQL Server側の推奨としても、本番環境ではFCIの仮想IPに静的IPを使い、DHCPは避けるべきことが示されています。
運用上の小ワザ：ホストがクラスタ化できなくても、SQLの可用性は担保できる
ホストがワークグループで、かつホスト側Failover Clusterを採用しない場合でも、SQL FCIの2ノードを「別ホストに常時1台ずつ」配置しておけば、片方のホスト障害でももう片方のVM上でFCIが稼働し続けられます（アクティブノードが落ちたらパッシブへフェールオーバー）。
このやり方は「VMの自動再配置（ホストHA）」は弱くなりますが、“DBサービスの継続”という目的に対しては、最小構成で強いのがメリットです。セキュリティ要件が厳しく、ホストをドメイン参加させられない環境では現実解になりやすいです。
別パターン：ホスト側CSV上の「VHD Set（.vhds）」を共有してゲストクラスタの共有ディスクにする
どうしても「物理LUNをVMに直接見せられない」「SAN運用をVMのWWN単位でやりたくない」という場合は、ホスト側で共有ストレージをいったん受けて、CSV上に“共有仮想ディスク”を作ってゲストへ渡す方法があります。
このとき、現行の選択肢として押さえておきたいのがVHD Set（.vhds）です。VHD Setは、ゲストクラスタ向けの共有仮想ディスクモデルとしてWindows Server 2016で導入され、オンラインリサイズやHyper-V Replica、アプリ整合性チェックポイントへの対応などが整理されています。
VHD Set方式のざっくり手順
- （ホスト側）Failover Clusteringを構成し、共有ストレージをクラスタへ追加
- 追加したLUNをCSV（Cluster Shared Volumes）に変換し、CSV上にVMやVHD Setを配置
- CSV上にVHD Set（.vhds）を作成し、SQL用VM 2台へ同一のVHD Setを接続
- （ゲスト側）共有ディスクとして認識されたVHD Setを使ってWSFC→SQL FCIを構成
CSVは、Failover Cluster内の複数ノードが同一LUNへ同時に読み書きできる仕組みとして説明されています。
ただし重要：Windows Server 2022の「ホストをワークグループでクラスタ化」にはサポート観点の注意がある
「ホスト側もワークグループクラスタ（ADなし）にしてCSVを使いたい」という発想は自然ですが、MicrosoftのドキュメントではワークグループクラスタはADを使わない一方でDNSが必須であること、また対応ワークロードに制約があることが明記されています。
- ワークグループクラスタはWindows Server 2016で導入され、ADに参加せずに構成できます（ただしDNSは必要）。
- 準備として、各ノードに同一の管理者アカウントを用意し、WinRMのTrustedHosts設定や共通のPrimary DNS Suffixを揃える手順が示されています。
- 同じページ内で、SQL Server FCIはワークグループクラスタのサポート対象外であることが明記されています。
- またHyper-V VM（クラスタ上でVMを高可用にする用途）はWindows Server 2025からサポート対象と記載されています。
ここで誤解しないでほしいのは、上記は「ワークグループクラスタ上で何の役割を動かすか（どのワークロードがサポートされるか）」の話です。今回の主題である“ゲストVM（AD参加）内でSQL FCIを組む”こととは別問題です。
ただし、ホスト側もクラスタ化してVMの自動フェールオーバーやライブマイグレーションまで求める場合、Windows Server 2022で「ホストをワークグループのまま」実現しようとすると、サポート範囲や設計の難易度が一気に上がります。現場では次のどれかに落ち着くことが多いです。
| 落としどころ | 概要 | メリット | デメリット |
|---|---|---|---|
| ホストはクラスタ化しない（単体2台） | SQL VMを各ホストに1台ずつ固定配置し、可用性はゲストFCIで担保 | ワークグループ運用と両立しやすい。構成が単純 | ホスト障害時のVM再配置は手動対応 |
| ホストはAD参加（管理用ドメインなど） | ホストクラスタでVM高可用、ゲストでもFCIでアプリ高可用 | 運用が王道でトラブルが少ない | セキュリティ要件の調整が必要 |
| 将来的にWindows Server 2025/Azure Localを検討 | ワークグループでもHyper-Vワークロードが整理された世代で設計 | ワークグループ運用の制約が軽くなる可能性 | OS更新や検証コストがかかる |
つまずきポイント集：設計で潰せる“ハマりどころ”
ホストがワークグループの場合に増える「名前解決」の作業
ワークグループ環境では、ADによる名前解決・自動登録が期待できません。ワークグループクラスタもDNSを必要とし、クラスタ名とIPがDNSに関連付けられる前提で説明されています。
- DNSの動的更新を許可できない環境では、クラスタ名や管理用の名前（必要な場合）を手動でAレコード登録する
- ノード間の解決がブレないよう、Primary DNS Suffixを揃える（Microsoftの手順にも出てきます）
- 最悪、閉域の検証環境ならhostsで固定も可能だが、本番運用ではDNSで管理した方が後々安全
FC-SAN利用時のストレージ設計（MPIOと“同一構成”が効く）
FCやSASなどの共有ストレージをクラスタで使う場合、ノード間でHBAやドライバ、MPIOなどを揃えるべきだというガイドがあります。
- ホスト側：HBAファーム/ドライバ、MPIO関連はできる限り揃える
- ゲスト側：仮想FCを2本にして、ゲストOSのMPIOで冗長パスを束ねる
- MSA側：コントローラ冗長・パス冗長・ALUA設定など、ベンダ推奨に合わせる
SQL FCIは“クォーラムが落ちると全部落ちる”
FCIはWSFCの健全性（クォーラム）に依存し、クォーラムを失うとFCIが停止しうることがSQL Serverドキュメントでも説明されています。
- 2ノード構成では、ウィットネス（クラウド/ファイル共有/ディスク）を必ず検討する
- 「ネットワーク分断」時に想定外の停止をしないよう、投票設定（Vote）も含めて設計する
バックアップとスナップショットの扱い
SQL FCIは共有ディスクを含むため、バックアップはまずSQLの論理バックアップ（FULL/DIFF/LOG）を基本にして設計するのが安全です。仮想基盤側のチェックポイントは便利ですが、共有ディスクを含むVMでは運用ルールを決めずに乱用すると復旧の難易度が跳ね上がります。
設計チェックリスト（そのままレビューに使える）
| カテゴリ | チェック項目 | OKの目安 |
|---|---|---|
| ホスト（Hyper-V） | ホストはワークグループ運用か／管理方法は決まっているか | ローカル管理者の統制、パッチ運用、監査ログの収集方法が決まっている |
| ストレージ | 共有LUNの分割（Data/Log/TempDB/Quorum） | 用途別に分け、I/Oが競合しないよう設計 |
| パス冗長 | 仮想FC/MPIOで冗長経路が取れているか | 片系断でもディスクI/Oが継続する |
| ネットワーク | クライアント用／クラスタ通信用の分離 | 最低限、帯域とMTUを考慮し、分断時の挙動を検証 |
| AD/DNS | ゲストWSFC/FCIの名前がDNSで解決できるか | クラスタ名・FCI名が確実に名前解決でき、IPも静的 |
| クォーラム | ウィットネスの種類と置き場所 | 2ノードで安定し、分断時の停止条件が説明できる |
| 運用 | パッチ適用手順（ホスト/ゲスト/SQL） | 計画フェールオーバー→作業→戻し、まで手順化 |
よくある質問
ホストがワークグループだと、ゲストVMはドメイン参加できない？
できます。ゲストOSのドメイン参加は、ゲストOSがADに到達できるネットワーク/名前解決/時刻同期が成立していれば問題ありません。ホストがワークグループかどうかとは別です。
「ホスト側もワークグループクラスタ＋CSV」で固めたいが、結局どう判断すべき？
技術的には成立するケースがありますが、OSバージョンと“何をサポート対象として動かすか”で判断が変わります。ワークグループクラスタはDNS必須で、準備手順やサポートワークロードが明記されています。
設計としては、まず「SQLサービスを止めない」ことが最優先なら、ゲストFCIを成立させる（共有ストレージはvFC等で直結）を軸にし、次に「VMも自動で逃がしたい（ホストHA）」が必要なら、ホスト側のクラスタ/AD参加/将来のOS選定まで含めて再検討するのが安全です。
まとめ
Hyper-Vホストがワークグループでも、ゲストVMをAD参加させてSQL Server FCIを構築することは可能です。設計の肝は、共有ストレージをどうゲストへ提示するかと、ホスト可用性（VMのHA）まで求めるかの切り分けです。
FC-SAN（HP MSA）があるなら、まずはVirtual Fibre ChannelでVMにLUNを直接提示する構成が分かりやすく、要件にも合わせやすいです。ホスト側のクラスタ化やCSV/VHD Setは便利な選択肢ですが、OS世代とサポート範囲、運用設計まで含めて慎重に選びましょう。
コメント