仮想化の遅延とハイパーバイザーのオーバーコミットメント
目次
免責事項
この記事は、あらゆる読者にとって理解しやすいように、専門的なことを避けた非常に一般的な内容となっています。 したがって、技術的な意味では正確とは言えない内容が含まれている可能性がありますが、比喩的な意味では正しい表現となっています。
また、この記事の情報は、x86 アーキテクチャーおよび kvm ハイパーバイザーに焦点を当てています。 一般的な情報の提供を目指していますが、他のアーキテクチャーまたはハイパーバイザーには該当しない場合があります。
カーネルから見た仮想マシン
ホストのカーネルから見ると、実行中の仮想マシン [VM] は プロセスがたくさんある に過ぎません。 仮想化のコンテキストのほとんどは、ハイパーバイザーソフトウェアによって処理されます。
すべての作業は最終的にプロセッサーによって行われるため、VM のすべての作業を処理するのは、最終的には VM の CPU (仮想CPU [vCPUs]) の仕事となります。
仮想 CPU の仕組み
通常、各 vCPU はホストマシン上のプロセス (またはスレッド) で表されます。 したがって、vCPU は、それぞれの vCPU プロセスがホストの CPU (物理CPU [pCPU]) 上で動作しているときにのみ、作業を処理 (実行) しています。
vCPU プロセスの実行が予定されている場合、pCPU は実際にはそのレジスターの内容を置き換え、コンテキストを vCPU の最後の実行ポイント (保存された状態) に切り替えます。 続いて、ホストマシン上で他のプロセスを実行できるように vCPU を再スケジュールする必要がある場合は、vCPU の実行が中断され、その状態、コンテキスト、レジスターが保存されて、元の pCPU のレジスターとコンテキストが復元されます。
これは、(カーネルがユーザー空間のタスク間で切り替えるときのコンテキストスイッチと比較して) より複雑なコンテキストスイッチ であると想像できます。
このようにして、プロセッサーハードウェアは、仮想 CPU と物理 CPU を区別することなく、単純に同じ動作を続けます (簡単に言うと、数値が変更されただけで、実行は同じまま継続されます)。
仮想 CPU の遅延について
vCPU はプロセスであり、プロセスは他のプロセスを実行できるように再スケジュールすることができるため、vCPU の実行にダウンタイムが発生します。 そのため、vCPU が行っていることはすべて、事実上一時停止されます。 ただし、VM から見ると、vCPU は一時停止せずに実行されています。つまり、一時停止 (再スケジュール) したことを認識していない点に注意してください。
(VM から見て) vCPU が実行中だと思っていても、実際には一時停止している場合、vCPU プロセスの再スケジュールは時間枠を作成します。 この時間枠の間、その特定の仮想 CPU に固有のすべての作業 (タイムキーピングを含むが、これに限定されない) も一時停止され、遅延 が始まります。 そのため、vCPU プロセスの実行が再びスケジュールされると、仮想 CPU では タイムジャンプ が発生し、追いつく必要があります。つまり、現在有効期限が切れているすべてのタイマーを起動させることになります。
vCPU のこのイベントが、しばらくの間再スケジュールされ、その後再び実行するようにスケジュールされた後に追いつくことは、仮想化の遅延の典型的な例です。
vCPU の遅延による影響
一般に、再スケジュールによる タイムジャンプ 後の vCPU に問題はありません。通常、vCPU は動作を続け、ワークロードは (現在期限切れのタイマーや他の潜在的な キャッチアップイベント ofc をすべて処理した後に) 先に進みます。 しかし、このような遅延は統計上顕著に現れることがあります。たとえば、ある読み取り操作は、明らかな理由もなく、他の読み取り操作よりもはるかに長い時間がかかりました (これは、vCPU プロセスが実行されていない時間があったため、かかった時間が長くなりました)。
通常、誰も小さな遅延には気づきません (ただし、仮想化環境で実行することのトレードオフとして覚えておくとよいでしょう)。 ただし、遅延が長くなると、顕著な中断が 発生し、パフォーマンスが低下する可能性があります。
さらなる影響は、VM 内で実行されている実際のアプリケーション (カーネル自体を含む) がそのような タイムジャンプ に敏感であるかどうか、または処理できるかどうかに依存します。
vCPU の遅延が発生する原因
vCPU の遅延は、vCPU のプロセスが再スケジュールされることが原因で発生します。そうでない場合は、中断により発生します。つまり、特定の pCPU でアクティブに実行されるプロセスが原因で発生するのではありません。 したがって、プロセスの実行を停止する要因となる すべてのこと が、vCPU の遅延を引き起こす可能性があります。
vCPU の遅延の一般的な原因としては、ハイパーバイザーオーバーコミットメント と通常呼ばれるさまざまな理由が挙げられます。 これらは、ハイパーバイザー上で実行されるアクティブな VM のリソース要求 (メモリーと CPU 時間) を満たす際に、ハイパーバイザーに問題が生じ始めた場合に発生する状況です。
これは一般に、作業のオーバーロードと考えられます。つまり、ホストマシン (特にその CPU) が効率的に処理可能な量よりも多くの作業を行う必要がある場合です。 サーバーマシンの場合、たまに負荷が急増しても、問題なく処理できることが多いですが、仮想化環境の場合は、このようなオーバーロードが大きな影響を及ぼす可能性があります。
vCPU の遅延を回避するためのグッドプラクティス
ハイパーバイザーのソフトウェアは、このようなオーバーコミット状況を軽減し、解決しようとするアルゴリズム (メモリーバルーニング など) を備えている傾向にありますが、これらを完全に阻止することはできません。 また、ハイパーバイザー (KVM / VMWare ESXi / Hyper-V / ...) によっては、このような軽減策や他のアルゴリズムを別の方法で実装する可能性がある点に注意してください。
オーバーコミット状態を回避する最善の方法は、仮想環境を 慎重に設計およびプロビジョニング することです。以下に示すように、特に CPU と メモリー のリソースに注意します。
- 実行中のすべての VM の CPU 数 (合計) は、ホストマシン上で利用可能な CPU 数を超えることはできません。 付録: ハイパースレッディング も確認してください (*)。
- vCPU を専用の pCPU (ピニング など) で実行するように設定すると、遅延 (*) が発生する可能性が大幅に減少します。
- 実行中のすべての VM に設定されたメモリーの量を検討し、その合計がホスト上で利用可能なメモリーの合計を超えている場合は、オーバーコミット状態になる危険性があります (**)。
- NUMA ノードの数が多い場合は、VM の設定に注意してください。
- VM が 1 つの NUMA ノード に 適合 する(1 つのノードより多くのメモリーを持たない) か、
- または、VM のカーネルがトポロジーを認識してメモリーを適切に管理できるように、VM にも適切な NUMA セットアップ (可能であれば 1:1) を設定します。
- また、VM に関連しないプロセスを処理するために、ホストにいくつかの CPU (例: NUMA ノードあたり 1 個) を残しておくことも、グッドプラクティスと言えます。
(*) pCPU の合計を上回る vCPU を許可すると、1 つの pCPU の時間を 2 つ以上の vCPU で共有しなければならない状況が実質的に発生します。 これは仮想化の特徴ではありますが、vCPU がその事実を認識していないため、単に vCPU の遅延タイムジャンプが発生していることになり、VM 内のスケジューリングや時間管理の効率が悪くなるという点で少々不便と言えます。 したがって、CPU リソースのオーバーコミットメントが望ましいかどうかは、環境のニーズによって異なります。
(**) いくつかのオプション (メモリーオーバーコミットおよび vCPU ピンニング) は、仮想化の特定の属性を取り除くものであるため、トレードオフとして考慮する必要がある点に注意してください。つまり、メモリーのオーバーコミットは有用な機能であり、vCPU プロセスが pCPU 間で移行できることは、環境のスループットと柔軟性を高める可能性があります。
最終的にすべては、仮想環境を使用/構築する実際のユースケースやワークロードによって異なります。
付録: ハイパースレッディング
物理プロセッサーコアのハイパースレッドである論理 CPU は、ゲスト VM の vCPU プロセスの実行には (パフォーマンスの点で) あまり適していません。 これは、ハイパースレッディングの仕組みによるものです。つまり、ハイパースレッドは、同じプロセッサーコアの計算能力を共有します。 そのため、1 つのプロセッサーのコアが、各ハイパースレッドで vCPU プロセスを実行するような状況では、それらの仮想 CPU のパフォーマンスが著しく低下する可能性があります。
これは vCPU の遅延とは特に関係ありませんが、仮想環境を設計する際に考慮すべき注目に値する点と言えます。
Comments