次の方法で共有


Hyper-V ホスト CPU リソース管理

Windows Server 2016 以降で導入された Hyper-V ホスト CPU リソース コントロールを使用すると、Hyper-V 管理者は、"ルート"、または管理パーティション、およびゲスト VM の間で、ホスト サーバーの CPU リソースの管理や割り当てをより適正に行うことができます。 管理者は、これらのコントロールを使用して、ホスト システムのプロセッサのサブセットをルート パーティション専用にすることができます。 これにより、ゲスト仮想マシンで実行されるワークロードをシステム プロセッサの個別のサブセットで実行することで、それらと Hyper-V ホストで実行される作業とを分離できます。

Hyper-V ホストのハードウェアの詳細については、「Windows 10 Hyper-V システム要件」を参照してください。

背景

Hyper-V ホスト CPU リソースの制御を設定する前に、Hyper-V アーキテクチャの基本を確認することは役に立ちます。 一般的な概要については、「Hyper-V アーキテクチャ」のセクションを参照してください。 この記事で説明される重要な概念は次のとおりです。

  • Hyper-V は、ハイパーバイザーの制御下で、コンピューティング リソースが割り当てられ、共有される、仮想マシンのパーティションを作成し、管理します。 パーティションにより、すべてのゲスト仮想マシン間、およびゲスト仮想マシンとルート パーティションの間に強力な分離境界が提供されます。

  • ルート パーティション自体は仮想マシン パーティションですが、独自の特性があり、ゲスト仮想マシンと比べて非常に多くの権限があります。 ルート パーティションは、すべてのゲスト仮想マシンを制御し、ゲストに仮想デバイスのサポートを提供し、ゲスト仮想マシンのすべてのデバイス I/O を管理する管理サービスを提供します。 ホスト パーティションでは、アプリケーションのワークロードを実行しないことを強くお勧めします。

  • ルート パーティションの各仮想プロセッサ (VP) は、基になる論理プロセッサ (LP) に 1:1 でマップされます。 ホストの VP は、常に同じ基盤の LP で実行されます。ルート パーティションの VP の移行は必要ありません。

  • 既定では、ホスト VP を実行する LP は、ゲスト VP も実行できます。

  • ゲスト VP を使用可能な任意の論理プロセッサ上で実行するようにハイパーバイザーがスケジュールする場合があります。 ゲスト VP をスケジュールする際、ハイパーバイザー スケジューラは、一時的キャッシュの局所性、NUMA トポロジ、およびその他のさまざまな要因を考慮する必要があります。最終的には、VP はいずれのホスト LP でもスケジュールされる可能性があります。

最小ルート、または "Minroot" 構成

Hyper-V の初期バージョンでは、パーティションあたり 64 VP というアーキテクチャの上限が設定されていました。 これは、ルート パーティションとゲスト パーティションの両方に適用されました。 64 を超える論理プロセッサを搭載したシステムがハイエンド サーバーとして登場したときに、Hyper-V も、これらの大規模なシステムをサポートするためにホスト スケールの制限を進化させ、一時は最大 320 の LP を持つホストをサポートしました。 ただし、その時にパーティションあたり 64 VP という制限を破ることでいくつかの課題が生じ、複雑さが増してしまい、やがてパーティションあたり 64 を超える VP のサポートは禁止されるようになりました。 対処策として、Hyper-V は、基になるマシンに使用可能なさらに多くの論理プロセッサが搭載されている場合でも、ルート パーティションに付与する VP の数を 64 に制限しました。 ハイパーバイザーは引き続きゲスト VP を実行するために使用可能なすべての LP を利用しますが、ルート パーティションでの上限は人為的に 64 に設定しました。 この構成は、"最小ルート"、または "minroot" 構成と呼ばれるようになりました。 パフォーマンス テストでは、64 を超える LP を持つ大規模なシステムでも、多数のゲスト VM とゲスト VP に十分なサポートを提供するために、ルートでは 64 を超えるルート VP を必要としなかったことが確認されました。実際、もちろんゲスト VM の数やサイズ、実行する特定のワークロードなどに応じて異なりますが、64 ルート VP よりはるかに少ない数でたいていの場合は十分でした。

この "minroot" の概念は、現在も引き続き利用されています。 実際、Windows Server 2016 Hyper-V がホスト LP のアーキテクチャ サポートの上限を 512 LP に引き上げた場合でも、ルート パーティションは最大 320 LP に引き続き制限されます。

minroot を使用したホスト コンピューティング リソースの制約と分離

Windows Server 2016 Hyper-V の 320 LP という高い既定しきい値では、minroot 構成は非常に大規模なサーバー システムでのみ使用されます。 ただし、Hyper-V ホスト管理者はこの機能をはるかに低いしきい値に構成できます。そのため、これを利用して、ルート パーティションで使用できるホスト CPU リソースの量を大幅に制限できます。 ホストに割り当てられた VM とワークロードの最大要求をサポートするには、使用するルート LP の特定の数を、当然ながら慎重に選択する必要があります。 ただし、ホスト LP の数の妥当な値は、実稼働ワークロードの慎重な評価と監視によって決定し、広範な展開の前に非実稼働環境で検証できます。

Minroot の有効化と構成

minroot 構成は、ハイパーバイザー BCD エントリを介して制御されます。 minroot を有効にするには、コマンド プロンプトから管理者権限で次のコマンドを実行します。

     bcdedit /set hypervisorrootproc n

ここで、数はルート VP の数です。

システムを再起動する必要があります。新しい数のルート プロセッサは OS ブートの有効期間中は保持されます。 minroot 構成は、実行時に動的に変更することはできません。

複数の NUMA ノードがある場合、各ノードは n/NumaNodeCount 個のプロセッサを取得します。

複数の NUMA ノードでは、VM のトポロジは、対応する VM の NUMA ノードの VP を実行するために各 NUMA ノードに十分な空き LP (つまり、ルート VP のない LP) を持つようなものにする必要があります。

Minroot 構成の検証

次に示すように、タスク マネージャーを使用してホストの minroot 構成を確認できます。

Host's minroot configuration shown in Task Manager

Minroot がアクティブな場合、タスク マネージャーには、システム内の論理プロセッサの総数に加えて、ホストに現在割り当てられた論理プロセッサの数が表示されます。