Microsoft Q&A へようこそ!
詳細な導入計画をご説明いただき、ありがとうございます。
Windows Server 2025 をハードウェアへ直接展開するか、Hyper-V 仮想化を利用して展開するかを評価する際には、あらゆる環境に当てはまる単一の「最適な」VM 数やアーキテクチャが存在しないことに留意することが重要です。最も効果的な設計は、アプリケーションが CPU コア全体にどの程度スケールするか、メモリ使用パターン、ストレージおよびネットワーク要件、可用性の目標、および管理上の考慮事項など、ワークロードの特性に大きく依存します。
1. ハードウェアおよびオペレーティング システムのサポートの確認
導入前に、正確なサーバー構成、プロセッサ SKU、ストレージ コントローラー、ネットワーク アダプター、ファームウェア バージョン、および Windows Server 2025 エディションが、HPE の Windows Server サポートおよび認定マトリックスに適合していることを確認することをお勧めします。
HPE の仕様はプラットフォームの最大ハードウェア性能を示していますが、必ずしもすべてのハードウェアとソフトウェアの組み合わせが検証済みであることを意味するわけではありません。そのため、本番環境へ移行する前に、最新のサポート対象 HPE Service Pack for ProLiant (SPP)、ファームウェア更新プログラム、チップセット ドライバー、ストレージ ドライバー、およびネットワーク ドライバーをインストールすることが重要です。
また、インストール後に最終的なプロセッサ トポロジを確認することも有効です。Intel Hyper-Threading などの技術が有効になっている場合、オペレーティング システムは利用可能な 344 個の物理コアよりも多くの論理プロセッサを認識する可能性があります。
2. ベアメタルと Hyper-V の選択
オプション A: Windows Server 2025 をサーバー上で直接実行する
ベアメタル展開が適していることが多いのは、次の場合です。
- 単一のアプリケーションがサーバー リソースの大部分を消費すると想定される場合。
- アプリケーションが NUMA を認識しており、大規模なマルチソケット システム向けにソフトウェア ベンダーから認定されている場合。
- ワークロードが可能な限り低い仮想化オーバーヘッドの恩恵を受ける場合。
- 専用ハードウェアへの直接アクセスが必要な場合。
- VM の移動性やワークロードの分離が重要な優先事項ではない場合。
ただし、ハードウェアへ直接展開したからといって、アプリケーションが自動的に 344 コアすべてを効率的に利用できるわけではありません。多くのワークロードは、オペレーティング システムのプロセッサ制限に達するはるか前に、アプリケーション アーキテクチャ、メモリ アクセス パターン、同期処理、または I/O スループットに関連する内部的な性能限界に直面します。そのため、ベンダーのガイダンスおよびアプリケーション ベンチマークは引き続き非常に重要です。
オプション B: Hyper-V 仮想化を使用する
Hyper-V が一般的に推奨されるのは、次の場合です。
- 複数のワークロードがサーバーを共有する必要がある場合。
- 分離、独立した保守、バックアップ統合、およびリソース制御が重要な場合。
- アプリケーションが単一のオペレーティング システム インスタンス内で効率的にスケールしない場合。
- リソース需要が時間とともに変動し、統合のメリットが求められる場合。
- 将来的な移行、クラスタリング、または高可用性シナリオが検討されている場合。
Windows Server 2025 Hyper-V は、ゲスト オペレーティング システムに仮想 NUMA トポロジを公開できるため、NUMA 対応アプリケーションはプロセッサおよびメモリ リソースをより効率的に利用できます。
この規模のプラットフォームでは、仮想化によって全体的なリソース利用率と運用の柔軟性が向上することがよくあります。ただし、単一アプリケーションが数百コアにわたるスケールを目的として特別に設計されている場合は、ベアメタル展開の方が最良のパフォーマンスを提供する可能性があります。
3. 仮想マシンは何台展開すべきか
これは最もよくある質問の 1 つですが、残念ながら、プロセッサ数だけに基づいて 8、16、32、または 64 VM といった固定的な推奨値は存在しません。
仮想マシンの数は、物理コア数の計算ではなく、ワークロード要件によって決定されるべきです。例えば、
- 8 台の大規模 VM がストレージおよびメモリ リソースを飽和させる可能性があります。
- 64 台を超える軽負荷 VM が問題なく稼働する場合があります。
- 1 台の大規模データベース VM が数十台のインフラ VM を合わせた以上のリソースを消費する場合があります。
評価および概念実証 (PoC) の実施における実践的な出発点として、多くの組織では 16~32 台程度の中規模 VM が、拡張性、管理性、および性能検証のバランスを良好に保つと考えています。
ただし、これは Microsoft または HPE の推奨値ではなく、初期設計のアプローチとしてのみ捉えるべきです。
また、各 VM は必要最小限の CPU およびメモリ リソースから開始し、性能監視によって明確な必要性が確認された場合にのみ割り当てを増やすことをお勧めします。Hyper-V ホスト自体もストレージ、ネットワーク、管理、監視、バックアップ、およびセキュリティ運用のためにリソースを必要とするため、すべての物理コアをゲスト VM に割り当てることは避けてください。
4. NUMA に関する考慮事項
DL580 Gen12 のような 4 ソケット サーバーでは、NUMA 設計が特に重要になります。
通常、ローカル NUMA ノードに接続されたメモリは、リモート ノードに接続されたメモリよりも高速にアクセスできます。その結果、大規模データベース、分析プラットフォーム、および HPC ワークロードでは、CPU 実行とメモリ割り当てが不要に複数の NUMA ノードへまたがる場合、性能低下が発生する可能性があります。
Windows Server 2025 では Hyper-V の NUMA 動作にも変更が導入されています。NUMA スパニングが無効な環境では、単一の物理 NUMA ノード内に存在する仮想プロセッサ数を超える数を必要とする VM は、NUMA スパニングが有効になっていなければ起動できません。
ベスト プラクティスとしては次の事項が含まれます。
- HPE が推奨する NUMA およびメモリ インターリーブ設定に従うこと。
- すべてのプロセッサおよびチャネルに対して均等にメモリを実装すること。
- Get-VMHostNumaNode などの Hyper-V ツールを使用して NUMA トポロジを確認すること。
- 可能な限り、レイテンシに敏感なワークロードを単一 NUMA ノード内に配置すること。
- 必要な場合にのみ NUMA スパニングを有効にすること。
- NUMA スパニング有効時と無効時の両方で大規模ワークロードのベンチマークを実施すること。
- 重要なプロセッサまたはメモリ変更時には仮想 NUMA トポロジを確認すること。
- 大規模データベースおよび HPC ワークロードに対して Dynamic Memory を慎重に評価すること。
サーバーが 4 つの物理 NUMA ノードを提供する場合、一般的な初期アプローチとしては、サーバー全体にまたがる単一 VM を直ちに作成するのではなく、大規模で性能に敏感な VM をそれらの NUMA 境界に合わせることです。
5. CPU サイジングに関する考慮事項
Hyper-V において、仮想 CPU と物理 CPU の比率について普遍的に推奨される値は存在しません。
CPU 集約型ワークロードでは、一般的に保守的な構成から開始し、過度な CPU オーバーコミットを避けることが推奨されます。軽負荷または変動の大きいワークロードでは、性能分析後に一定レベルのオーバーコミットが許容される場合があります。
性能を検証する際は、Hyper-V ホストとゲスト VM の両方について次の項目を監視してください。
- 継続的な CPU 使用率。
- Hyper-V 仮想プロセッサの実行時間。
- CPU 待機時間およびスケジューリング遅延。
- NUMA 関連のメモリ アクセス パターン。
- ストレージ レイテンシおよびスループット。
- ネットワーク利用率およびパケット損失。
- メモリ プレッシャーおよびページング活動。
- バックアップ、更新、および保守作業中の性能。
また、vCPU を増やしたからといって必ずしも VM 性能が向上するわけではない点にも注意が必要です。過度に大きな VM はスケジューラによる効率的な配置が難しくなり、NUMA ノード間のアクセスが増加する可能性があります。
6. メモリ、ストレージ、およびネットワーク
最大 16 TB のメモリ構成が可能であるため、適切なメモリ実装は非常に重要です。HPE のメモリ実装ガイドラインに従うことで、すべてのプロセッサ間でバランスの取れたメモリ帯域幅を維持できます。
ストレージ サイジングでは、容量要件だけでなく次の項目も考慮する必要があります。
- 持続的およびピーク時の IOPS。
- 読み取りおよび書き込みレイテンシ。
- キュー深度。
- コントローラー スループット。
- バックアップ要件。
- フォールト トレランスおよびレジリエンス要件。
Hyper-V ネットワークでは、VM ワークロード、管理トラフィック、バックアップ処理、ストレージ通信、および将来的なライブ マイグレーションやクラスタリング活動に十分な帯域幅が確保されていることを確認してください。
Windows Server 2025 には性能向上および CPU 使用率削減に寄与するストレージ改善機能と NVMe 最適化が含まれていますが、ストレージ設計全体の検証は依然として重要です。
7. 可用性計画
追加で考慮すべき事項として可用性があります。
ワークロードがサーバー上で直接実行される場合でも、仮想マシン内で実行される場合でも、単一の DL580 Gen12 は依然として単一障害点となります。
ワークロードがビジネスクリティカルである場合は、少なくとも 2 台の適切なサイズの Hyper-V ホストを展開し、共有ストレージまたはレプリケーション ストレージを使用したフェールオーバー クラスタリングの実装を検討してください。このアプローチにより、ハードウェア障害および計画メンテナンス時の耐障害性が向上します。
参考情報:
Hyper-V の Windows Server における最大スケール制限 | Microsoft Learn
Hyper-V における NUMA と仮想マシン | Microsoft Learn
Hyper-V メモリを最適化するように NUMA を構成する | Microsoft Learn
Hyper-V プロセッサのパフォーマンス | Microsoft Learn
Hyper-V 仮想マシンの動的メモリ | Microsoft Learn
Hyper-V メモリのパフォーマンス | Microsoft Learn
お役に立ちましたら、Accept Answer をクリックしていただけますと幸いです。
Microsoft Q&A をご利用いただきありがとうございます。
注: この回答は翻訳ツールを使用して翻訳されています。文法上または意味上の誤りが含まれる可能性がありますので、あらかじめご了承ください。