Hyper-Vのライブマイグレーションもフェールオーバークラスタも、その足元はActive Directoryです。CNOとVCOという2種類のコンピュータオブジェクトの挙動を理解していないと、クラスタ作成やクラスタ役割の追加でつまずきます。Microsoft Learnの一次情報を引きながら、現場でハマる勘所を整理します。

Hyper-Vクラスタやライブマイグレーションの設計というと、ネットワークやストレージ(S2D)に目が行きがちです。しかし実際の構築現場で最初につまずくのは、たいていActive Directory(AD)側です。クラスタ名オブジェクト(CNO)と仮想コンピュータオブジェクト(VCO)という2種類のコンピュータアカウントの挙動、そしてそれらに必要なAD権限を押さえていないと、「クラスタは作れたのにファイルサーバー役割がオンラインにならない」といった事象に必ず出会います。本稿では、EMWが実際にWindows Server 2025 Datacenterでのクラスタ構築とHyper-Vライブマイグレーション移行を手掛けた経験を土台に、Microsoft Learnの一次情報を引きながら勘所を整理します。

01CNOとVCO — クラスタが作る2種類のADオブジェクト

フェールオーバークラスタを作成すると、クラスタ名と同じ名前のコンピュータアカウントがADに自動作成されます。これがクラスタ名オブジェクト(CNO: Cluster Name Object)です。そしてクライアントアクセスポイントを持つクラスタ役割(ファイルサーバーやプリントサーバーなど)を追加すると、その役割名に対応するコンピュータアカウントが作られます。これが仮想コンピュータオブジェクト(VCO: Virtual Computer Object)です。

重要なのは、VCOを作るのがCNOだという点です。Microsoft Learnは「CNOを通じて、クライアントアクセスポイントを使うクラスタ役割を構成すると、VCOが自動的に作成される」と明記しています。つまりCNOは単なるクラスタの名前ではなく、後続のオブジェクトを生み出す「親アカウント」として機能します。

現場のコツ：Hyper-Vの仮想マシン役割だけは例外で、専用のコンピュータアカウント(VCO)を必要としません。ファイルサーバーやSQL FCIでは役割ごとにVCOが増えていくのに、Hyper-VクラスタではCNO以外オブジェクトが増えない、という差はここから来ます。「VMを載せるだけのHyper-Vクラスタ」と「役割が増えるクラスタ」でAD設計の重みが変わることを、最初に見積もっておくと後が楽です。
CNOがVCOを生成する — クラスタのADオブジェクト構造 OU=Clusters CNO: Cluster1 クラスタ名オブジェクト Create Computer objects 権限 VCO: FileServer1 ファイルサーバー役割 VCO: SQLAG1 SQL可用性グループ Hyper-V VM VCO不要(例外) VCOは既定でCNOと同じOU/コンテナに作成される
図：CNOが親アカウントとして、クライアントアクセスポイントを持つ役割のVCOを生成する。Hyper-V VMだけは専用VCOを必要としない。

02クラスタ作成に必要なAD権限 — 誰が何を持つべきか

「クラスタが作成できない」の大半は権限問題です。Microsoft Learnは必要な権限を主体ごとに明確に定義しています。混同しやすいので、アカウントの役割で分けて整理します。

現場のコツ：エンタープライズ環境では、AD運用チームがコンピュータオブジェクトの新規作成を厳しく絞っていることがほとんどです。構築担当に Create Computer objects を渡してもらえないケースは日常茶飯事。そのときの正解は「権限をよこせ」ではなく、次節の事前ステージングを提案することです。AD運用側の統制を崩さずにクラスタを作れるので、話が通りやすくなります。大手SIer/エンタープライズのAD運用ポリシーを尊重した進め方が、結局いちばん早いです。

03CNOの事前ステージング — 権限を渡さずにクラスタを作る

事前ステージング(prestage)とは、ドメイン管理者があらかじめCNOをADに作っておき、構築担当にはそのオブジェクトへのFull Controlだけを渡す手法です。構築担当は Create Computer objects 権限を持たなくてもクラスタを作成できます。Microsoft Learnの手順を要点だけ挙げます。

無効化がなぜ必須か。Microsoft Learnは「クラスタ作成プロセスが、そのアカウントが既存のコンピュータやクラスタで使用中でないことを確認できるように、無効化しておく必要がある」と説明しています。無効化を忘れると、クラスタ作成時に「その名前は使用中」と判断されて失敗します。ステージングしたのに作れない、の典型原因です。

現場のコツ：CNOを既定のComputersコンテナに作った場合は、後述のVCO権限委任(Step 3)が不要で、追加設定なしに最大10個のVCOを作れます。一方、専用OUに置くと統制はきれいになりますが、CNOへのVCO作成権限委任を別途行わないとクラスタ役割がオンラインになりません。「専用OU=きれいだが一手間増える」を承知の上で選ぶことが大事です。

04OU配置とVCOの権限委任 — 役割がオンラインにならない罠

クラスタ役割を作ると、VCOはCNOと同じOUに作られます。これを自動化するには、CNOがそのOU内でコンピュータオブジェクトを作成できる権限を持っている必要があります。専用OUにCNOを置いた場合、Microsoft Learnは2つの選択肢を示しています。

この委任を忘れると、クラスタ自体は動いているのに、ファイルサーバーやSQL FCIのネットワーク名リソースがオンラインにならず、イベントに1194や1207が記録されます。「クラスタは緑なのに役割だけ落ちる」ときは、まずCNOのVCO作成権限を疑うのが定石です。

事前ステージングの3ステップ Step 1 CNOを事前作成 専用OUに配置 誤削除防止ON アカウント無効化 Step 2 構築ユーザーに委任 CNOへ Full Control Create権限は不要 Step 3 CNOにOU権限委任 Create Computer objects を Allow → VCO自動作成可 結果 構築担当は Create Computer objects 権限を持たずに クラスタを作成でき、役割追加時のVCOも自動生成される AD運用側の統制を崩さずクラスタを構築できる
図：事前ステージングの流れ。Step 3のOU権限委任を省くと、役割のネットワーク名がオンラインにならない(イベント1194/1207)。

05コンピュータアカウントとDNS — CNO/VCOはDNSに名前を書く

CNOとVCOはADオブジェクトであると同時に、DNSにAレコードを登録する存在でもあります。クラスタのネットワーク名リソースがオンラインになるとき、対応するDNSレコードが更新されます。ここが失敗すると名前解決ができず、リソースはオンラインになりません。

Microsoft Learnのトラブルシューティングでは、ネットワーク名がオンラインにならない原因の一つとして「DNSの問題。CNOまたはVCOのレコードに対する権限も確認する必要がある」と明記されています。よくあるのは、動的更新でCNOが自分のレコードを更新しようとしたが、既存の同名レコードの所有者が別主体で更新権限がない、というパターンです。

現場のコツ：クラスタで使うDNSゾーンはセキュリティで保護された動的更新を前提に設計してください。手作業でAレコードを先に作ってしまうと、レコードの所有者が作成者(=管理者)になり、CNOが自分のレコードを更新できず詰みます。VCO/CNOのDNSレコードは「クラスタに作らせて、クラスタに所有させる」のが原則です。どうしても事前作成が必要なら、対象レコードのACLでCNOコンピュータアカウントに更新権限を委任しておきます。

06クラスタ作成時のAD権限エラー — イベントIDで原因を切り分ける

CNO/VCO関連の障害は、イベントログを見れば原因の見当がつきます。Microsoft Learnが挙げる代表的なイベントIDと意味を、切り分けの順で並べます。

権限を直したあとは、フェールオーバークラスタマネージャーのRepairアクションでCNOのADパスワードを再同期させます。「権限は直したのにまだオンラインにならない」ときは、このRepairを忘れていることが多いです。あわせて、ストレージセクションを除いたクラスタ検証(Test-Cluster)を回して構成ミスを洗い出すのが定石です。

07ドメインコントローラの配置 — 鶏と卵を作らない

ライブマイグレーションやフェールオーバーは、Kerberos認証を通じてAD/DNSに依存します。ここで設計を誤ると、有名な「鶏と卵」問題に陥ります。すべてのDCをそのHyper-Vクラスタ上の仮想マシンとして動かしていると、クラスタが完全停止した状態から復旧しようとしたとき、ノードが認証できずVMを起動できず、DCも上がらない、という膠着に陥ります。

Microsoft Learnは仮想化DCのガイダンスで「クラスタのシステム起動時にDCへアクセスできるよう、このクラスタ配下に依存しない独立したホスティング上に、少なくとも2台のDCを配置する」ことを推奨しています。物理サーバーでも、ADに依存しない別の仮想基盤でも構いません。要は、クラスタの起動がDCに依存し、そのDCの起動がクラスタに依存する、という循環を断つことです。

現場のコツ：2ノードのHyper-Vクラスタで、唯一のDCをそのクラスタ上のVMとして載せる構成は避けてください。EMWの実案件でも、ライブマイグレーション専用にAD/DCをクラスタ外に独立して構築し、認証基盤の可用性を先に確保してからクラスタ設計に入りました。DC配置はネットワークやストレージより先に決めるべき「土台の土台」です。全ノードが同一ADドメインに属していること、DCがクラスタノード自身に同居していないことは、Microsoft Learnも基本要件として明記しています。

08この基盤知識はAWS移行にも効く

ここまでのCNO/VCO・権限委任・DNS連動・DC配置の勘所は、オンプレHyper-V/Windowsの世界に閉じた話に見えて、実はクラウド移行の設計品質を左右します。オンプレADの依存関係を正しく棚卸しできていれば、オンプレADからAWS Managed Microsoft ADへの移行や、Windows Serverの移行で踏みやすい落とし穴を事前に避けられます。EMWは「実際に手を動かして構築している」からこそ、オンプレの現実を踏まえた移行設計ができます。関連する設計判断は、兄弟記事のHyper-Vライブマイグレーション設計やライブマイグレーションのKerberos制約付き委任もあわせてご覧ください。

—まとめ

フェールオーバークラスタとライブマイグレーションのAD設計は、CNOとVCOという2つのオブジェクトの親子関係を理解することから始まります。要点を整理します。

これらは仕様の細部がバージョンで変わり得るため、Windows Server 2025・S2Dの現行仕様やAzure Local(旧Azure Stack HCI)との棲み分けを含め、最新はMicrosoft Learnで確認することをおすすめします。オンプレのクラスタ構築から、その先のAWS移行までの一貫した設計は、導入事例もご参照ください。

—参考(一次情報)

オンプレHyper-V/S2Dの構築から、その先のAWS移行設計まで一気通貫でご相談いただけます。お問い合わせください。

相談する
← ブログ一覧へ戻る