Hyper-V実運用の勘所 — 動的メモリ・NUMA・チェックポイント・VSS

Hyper-Vは「動く」だけなら簡単ですが、本番で安定させるには動的メモリ・NUMA境界・チェックポイントの挙動を正しく理解する必要があります。実際にS2D上でHyper-Vを構築・移行してきた経験から、現場でハマる勘所をMicrosoft Learnの一次情報とともに整理します。

Hyper-Vは仮想マシンを起動するだけなら難しくありません。しかし本番環境で「メモリが足りているはずなのに遅い」「バックアップから戻したADが壊れた」「ライブマイグレーションで性能が落ちた」といったトラブルは、動的メモリ・NUMA・チェックポイント(スナップショット)の内部挙動を理解していないと原因にたどり着けません。この記事では、実際にWindows Server 2025 Datacenter上でS2D+Hyper-Vを構築し、Hyper-Vライブマイグレーションによる移行を手掛けた経験をもとに、本番運用の勘所を整理します。値やバージョン依存の仕様は、必ずMicrosoft Learnで最新を確認してください。

01動的メモリ — 起動・最小・最大・バッファの意味を取り違えない

動的メモリ(Dynamic Memory)は、VMの負荷に応じて割り当てメモリを増減させる機能です。設定値は4つあり、それぞれの意味を正確に押さえることが第一歩です。Microsoft Learnの定義では、起動RAM(Startup RAM)はVMが起動時に確保するメモリ、最小RAM(Minimum RAM)は起動後にHyper-Vが未使用分を回収できる下限、最大RAM(Maximum RAM)はVMが要求できる上限です。割り当てられるメモリの下限は最小RAM、上限は最大RAMです。負荷が低いときは割り当てが起動RAMを下回り、最小RAMまで回収されることがあります(起動RAMはあくまで起動時に確保する量であって、回収の下限ではありません)。

起動RAM：起動時に必要な量。大きすぎると同時起動時にホストが枯渇し、小さすぎるとOS起動が遅い/失敗する。
最小RAM：アイドル時にここまで絞られる。ADやSQLのような常駐ワークロードで小さくしすぎると、回収→再割当のバルーニングが発生し性能が揺れる。
最大RAM：ゲストOSがサポートする上限、あるいはホストの空きが実質の天井。
メモリバッファ：VM内に「余裕」として確保する割合。Microsoft Learnによれば設定可能値は5〜2000(%)。ファイルキャッシュ用の余白と考えると理解しやすい。

現場のコツ：動的メモリが向かないワークロードを最初に切り分けます。SQL Serverのように自前でメモリを掴みにいくアプリや、起動時にNUMAトポロジを固定するアプリは、動的メモリと相性が悪い場面があります。DBやレイテンシ敏感なVMは固定メモリ+適切なNUMA設計、汎用サーバは動的メモリ、という使い分けが実務的です。

PowerShellではSet-VMMemory -DynamicMemoryEnabled $true -MinimumBytes -StartupBytes -MaximumBytes -Bufferで一括設定できます。GUIで一台ずつ触るより、標準化された値をスクリプトで流し込む方が事故が減ります。

02NUMA境界とvNUMA — 「またいだ」瞬間に性能は落ちる

物理サーバが2ソケット以上だと、各CPUは自分に直結したメモリ(ローカルNUMAノード)へのアクセスが速く、別ソケットのメモリ(リモート)へのアクセスは遅くなります。Hyper-VはVM起動時、可能な限り単一の物理NUMAノードからメモリを割り当てようとします。単一ノードで足りない場合のみ、別ノードから割り当てます(=NUMAをまたぐ)。この「またぎ」が起きると、ゲスト内のメモリアクセスの一部がリモートになり、性能が落ちます。

大きなVMにはvNUMA(仮想NUMA)が投影されます。Microsoft Learnによれば、既定でvNUMAトポロジはホストのNUMAトポロジに一致するよう最適化されます。これによりゲストOSやNUMA対応アプリ(SQL Serverなど)は、物理マシンと同様のNUMA最適化を利かせられます。逆に言えば、vNUMAの形が崩れると、アプリのスケジューリングまで狂います。

図：物理NUMAノードとVMへのvNUMA投影。VMメモリが単一ノードに収まればローカルアクセスで高速、超えるとリモートアクセスが混じり性能が落ちる。

現場のコツ：VMのメモリ量を、なるべく1ノードのローカルRAMに収まる設計にします。たとえば1ノード32GBの機で48GBのVMを作れば、確実にまたぎます。「vCPU数もノードあたりの物理コアに合わせる」「動的メモリと巨大vNUMAの併用は挙動を確認してから」が鉄則です。なおNUMAスパニングのオン/オフはホスト全体に効き、Windows Server 2025では小さいVMでも挙動が変わる報告があるため、本番投入前に必ず実機で確認してください。

03統合サービス — 時刻同期とVSSは「意識して」有効化する

統合サービス(Integration Services)は、ゲストとホストの連携を担うコンポーネント群です。Microsoft Learnによれば、Guest Service Interface、Heartbeat、Key-Value Pair Exchange、Shutdown、Time Synchronization、VSS、VM Session(PowerShell Direct)、Remote Desktopの各サービスがあります。ゲスト側のサービス名はvmicvss(VSS Requestor)、vmictimesync(時刻同期)などです。各サービスはホストとゲストの両方で有効でないと機能しません。

Time Synchronization：ホスト時刻をゲストに送る。ズレが5秒以内なら補正、5秒超だと補正しない挙動。
VSS(Volume Shadow Copy Requestor)：本番チェックポイントと整合バックアップの要。後述。

現場のコツ：仮想化されたドメインコントローラーでは、Hyper-Vの時刻同期を扱いに注意します。DCはドメイン階層の時刻源であるべきなので、ホスト由来の時刻に引きずられると権威が二重になり不整合の原因になります。Microsoft Learnのガイダンスに沿って、DCでは時刻同期の扱いを設計し、w32timeの階層を壊さないようにします。ライブマイグレーション用にADを構築した現場でも、ここは最初に固める勘所でした。

04チェックポイント — 標準(スナップショット)と本番(VSS)は別物

Hyper-Vのチェックポイントには2種類あります。Microsoft Learnの定義は明確です。

標準チェックポイント(Standard)：VMの状態とメモリ状態のスナップショットを取る。フルバックアップではなく、ADのようにノード間でデータを複製するシステムではデータ整合性の問題を起こすことがある。
本番チェックポイント(Production)：Volume Shadow Copy Service(Linuxではファイルシステムフリーズ)を使い、データ整合のとれたバックアップを作る。メモリ状態のスナップショットは取らない。

新規VMの既定は本番チェックポイントです。適用時の違いも重要で、標準を適用するとメモリ状態ごと復元されアプリが開いたままの状態に戻りますが、本番を適用するとVMはオフ状態で復元され、起動し直す必要があります。この差は「メモリ状態を含むかどうか」に由来します。

図：標準は「メモリごと止めた瞬間」を復元、本番はVSSで整合をとった状態を復元しオフで戻る。本番ワークロードには本番チェックポイントを使う。

現場のコツ：Set-VM -CheckpointTypeにはProductionとProductionOnlyがあります。前者は本番チェックポイントが失敗すると標準にフォールバックしますが、ProductionOnlyはフォールバックしません。ADやSQLなど整合性が生命線のVMはProductionOnlyを明示し、「知らないうちに標準が作られていた」事故を防ぎます。

05バックアップ整合性 — クラッシュ整合とアプリ整合の差を語れるか

バックアップの「整合性」には段階があります。クラッシュ整合(crash-consistent)は、電源を突然切った瞬間のディスク像に相当します。ファイルシステムは復旧できても、DBのトランザクションが中途半端に残るリスクがあります。アプリケーション整合(application-consistent)は、VSSを介してアプリ(SQL Server、Exchange等)にI/Oを静止(quiesce)させ、ログをフラッシュした状態で取得します。本番チェックポイントおよびVSS対応バックアップが目指すのはこちらです。

ゲスト内のvmicvssが有効で、アプリのVSS Writerが正常でないと、アプリ整合バックアップは成立しない。
チェックポイントの実体は.avhdx差分ディスク。削除するとHyper-Vが.vhdxとマージする。.avhdxを手で消してはいけない。
バックアップ製品側でチェックポイントが残留すると、差分ディスクが肥大化しストレージを圧迫する。定期的に残留チェックポイントを監視する。

06世代1と世代2 — 移行の可否を左右する分岐点

Microsoft Learnは、Secure Boot等の恩恵を受けられるため原則世代2(Generation 2)を推奨しています。世代2はBIOSではなくUEFIファームウェア、SCSIコントローラからのブート、IPv4/IPv6でのネットワークブートに対応し、VHDX限定です。世代1はPCAT BIOSでIDEコントローラを持ちます。重要なのは、作成後に世代を変更できない点です。

現場のコツ：既存のVHD(UEFI非互換)を流用する移行では世代1を選ばざるを得ないことがあります。逆に新規構築なら世代2一択で、Secure Bootでrootkit/bootkitの攻撃面を減らせます。この「世代の固定性」は、後述のAWS移行でも効いてきます。移行前に世代とファームウェア形式を棚卸ししておくと、変換工程の見積もりが正確になります。

07リソース制御 — CPU予約・重み・上限の使い分け

Hyper-VはvCPUに対して3つの制御を持ちます。予約(Reserve)はそのVMに最低保証する物理CPUの割合、上限(Limit)は使える最大割合、重み(Weight)は競合時の優先度です。オーバーコミット(物理コア数を超えてvCPUを割り当てる)環境では、この3つで「誰を優先するか」を設計します。

レイテンシ敏感なVM(DB、通信基盤)には予約を与え、飢餓を防ぐ。
暴走しうるバッチ系には上限をかけ、他VMへの巻き添えを断つ。
平時の優先順位は重みで相対制御する。

あわせて、ハイパーバイザースケジューラの種類(Core/Classic/Root等)も性能・セキュリティに影響します。Windows Server 2025での既定と選択は、Microsoft Learnで最新を確認してください。

08オーバーコミットの現実 — 「詰め込める」と「安定して回る」は違う

メモリもCPUもオーバーコミットは可能ですが、それは「起動できる」の話であって「本番SLAを満たす」の話ではありません。動的メモリで論理的に詰め込んでも、全VMが同時にピークを迎えれば物理メモリは有限です。過度なオーバーコミットは、バルーニングやページングを誘発し、レイテンシの尻尾(テールレイテンシ)を悪化させます。

現場のコツ：本番設計では「平均使用率」ではなく「相関するピークが重なった時」を基準に容量を引きます。特にS2D上でHyper-Vを回す場合、ストレージ層(ReFS/CSVキャッシュ)とメモリを奪い合うため、ホストメモリには十分な余白を残します。クラスタ全体では、1〜2ノード障害時にもワークロードが収まるだけの空きを常に確保しておくのが、可用性設計の基本です。この容量計画の考え方は、ReFS/CSVボリューム設計やS2D設計と地続きです。

—まとめ

Hyper-Vの本番運用は、動的メモリの4値、NUMA境界とvNUMA、統合サービス、本番チェックポイント(VSS)と整合バックアップ、世代、リソース制御——この一つひとつを「なぜそうなるか」まで理解して初めて安定します。詰め込むこと自体は簡単で、安定して回すことが難しいのです。

そして、この知識はオンプレに閉じません。世代・ファームウェア形式・NUMA前提・整合バックアップの理解は、そのままAWSへの移行判断——たとえば導入事例で扱うようなリフト＆シフトや、オンプレサーバのEC2サイジング、オンプレADからManaged Microsoft ADへの移行——の精度を上げます。手が動かせる会社は、オンプレの内部挙動を語れる会社でもあります。

—参考(一次情報)

オンプレHyper-Vの設計・運用、あるいはそこからAWSへの移行まで、手を動かせるコンサルとしてご支援します。お問い合わせください。

相談する

← ブログ一覧へ戻る