CPU対応：サイレントハイパーバイザーキラー

CPU Readyは、なじみのないものです。一見良いことのように聞こえるかもしれませんが、残念ながらそうではありません。 CPU Readyは、私たちが知っていたよりも長い間、仮想環境を悩ませてきました。 VMwareは、これを「仮想マシンの準備ができていたが、物理CPUで実行するようにスケジュールできなかった時間の割合」と定義しています。 CPU準備時間は、ホスト上の仮想マシンの数とそれらのCPU負荷に依存します。」 Hyper-Vはこのカウンター（Hyper-Vハイパーバイザー仮想プロセッサーディスパッチあたりのCPU待機時間）の提供を最近開始したばかりであり、他のハイパーバイザーはまだこのメトリックを提供しない可能性があります。

CPU Readyとは何かを理解するには、ハイパーバイザーが仮想CPU（vCPU）を物理CPU（pCPU）にスケジュールする方法を理解する必要があります。 VMでvCPU時間が必要な場合は、コマンド/プロセス/スレッドがpCPUに対して実行できるように、vCPUをpCPUに対してスケジュールする必要があります。理想的な世界では、これが発生する必要があるときに、リソースの競合やボトルネックはありません。単一のvCPUVMがpCPUに対して時間をスケジュールする必要がある場合、pCPUコアが使用可能であり、この理想的な世界ではCPUReadyはごくわずかです。 CPU Readyは常に存在しますが、理想的な世界では非常に最小限であり、気付かれることはありません。

現実の世界では、仮想化の利点の1つは、VMの多くがすべてのvCPUを同時にスパイクするわけではなく、使用率が非常に低いVMの場合は、どれだけの量を推測できるかを推測できることです。 CPU使用率とRAM使用率に基づいて物理ホストをロードします。これまで、ワークロードに応じて、4vCPUと1pCPU、または10：1の比率にすることを推奨していました。たとえば、単一のクアッドコアプロセッサを使用していても、それぞれにvCPUを備えた4つのVMがあり、16個のvCPUから4個のpCPUまたは4：1を提供できます。しかし、エンジニアが見始めていたのは、環境がひどく遅く、その理由を理解できなかったということです。 RAMの使用率は問題ないようで、物理ホストのCPU使用率は20％未満と非常に低い場合もあります。ストレージの待ち時間は非常に短いものでしたが、VMは非常に低速でした。

このシナリオで起こっていたのはCPUレディでした。スケジュールする準備ができているvCPUのキューが構築されていましたが、スケジュールできるpCPUがありませんでした。ハイパーバイザーはスケジューリングを停止させ、ゲストVMの遅延を引き起こします。近年まで、検出するツールがあまりなかったのはサイレントキラーです。 Windows VMでは、起動するのに永遠に時間がかかり、最後に起動したときにスタートメニューをクリックすると、表示されるまでに永遠に時間がかかります。最初のクリックを受け入れなかったと思ってもう一度クリックすることもできます。最終的に追いつくと、ダブルクリックが発生します。 Linuxでは、VMが読み取り専用モードで起動したり、ファイルシステムを後で読み取り専用モードに切り替えたりする場合があります。

では、CPU Readyとどのように戦うのでしょうか？助けることができるいくつかの方法があります。 1つは、CPUReadyメトリックの監視です。 VMwareでは、10％を超えることはお勧めしませんが、個人的な経験では、ユーザーはVMのタイプと実行しているものに応じて5〜7％を超えることに気付き始めます。

以下では、VMware ESXi 5.5のいくつかの例を使用して、CPU対応を示します。コマンドラインを使用して、「esxtop」を実行します。 CPUビューの「c」を押すと、「」列が表示されます。 ％RDY CPUReadyの場合は「」。大文字を押すことができます V 」はVMのみのビューです。

ここでは、かなり使用されていない環境では％RDYがやや高いことがわかります。この場合、ESXi5.5はVMwareFusion（Macハイパーバイザー）上でテストVMを実行しているため、別のハイパーバイザー上でハイパーバイザー上でVMを実行しているため、少しハイエンドになると予想されます。

vSphereクライアントでは、特定のVMをプルアップして、[パフォーマンス]タブをクリックできます。そこから「チャートオプション」をクリックします

[グラフオプション]で、[CPU]、[リアルタイム]を選択します（vCenterを使用している場合は、リアルタイム以外のタイミングオプションがある場合があります）。そこからカウンターで「準備完了」を選択します。ビューでは常に2つのデータ型しか許可されないため、別のカウンターの選択を解除する必要がある場合があります。

この値は、準備完了とパーセンテージの要約であることに注意してください。要約されたメトリックをパーセンテージに変換する方法に関するVMwareKBの記事へのリンクは次のとおりです。 – https://kb.vmware.com/kb/2002181

ハードウェアを購入する場合、コアを増やすとCPUReadyの影響を軽減できます。ハイパースレッディングも役立ちます。ハイパースレッディングは、各プライマリコアに完全なセカンドコアを提供しませんが、通常は、vCPUをpCPUにスケジュールして、問題を軽減するのに十分です。ハイパーバイザーはvCPUとpCPUの比率の推奨から離れ始めていますが、通常は4：1の適度に使用されている環境でうまく機能し、そこから移行できます。 VMのロードを開始するときは、CPUレイテンシ、CPUレディ、および全体的な感触とパフォーマンスを確認してください。ヒット数の多いVMがある場合は、それらを他のクラスターに分離し、より低い比率を使用して軽量に保つことをお勧めします。一方、パフォーマンスが重要ではなく、実行速度が遅くても問題がないVMの場合は、サブスクライブをはるかに高くすることができます。

VMの適切なサイズ設定は、CPUReadyと戦うための巨大なツールでもあります。多くのベンダーは、VMが実際に必要とするものよりもはるかに優れた仕様を推奨しています。従来、より多くのCPUとより多くのコア=より多くの電力。仮想環境での問題は、ハイパーバイザーがすべてのvCPUをpCPUにほぼ同時にスケジュールする必要があり、pCPUのロックが問題になる可能性があることです。 8つのvCPUVMがある場合は、8つのpCPUをロックして、同時にスケジュールできるようにする必要があります。 vCPU VMが常に合計vCPUの10％しか使用しない場合は、vCPUカウントを2または4に減らすことをお勧めします。VMを50〜80％CPUで実行し、vCPUを10％より少なくすることをお勧めします。より多くのvCPU。この問題の一部は、オペレーティングシステムのCPUスケジューラができるだけ多くのコアを使用するように設計されているのに対し、コアを最大化するようにトレーニングされていれば、それほど問題にならない可能性があるためです。特大のVMは十分に機能する可能性がありますが、他のVMの「ノイズの多いネイバー」である可能性があるため、パフォーマンスの向上を確認するには、通常、クラスター内のすべてのVMを「適切なサイズ」にする必要があるプロセスです。

多くの場合、CPU Readyに遭遇し、VMの適切なサイズ設定を開始したり、より多くのコアを備えたプロセッサにアップグレードしたりすることは困難です。このような状況にある場合は、クラスターにホストを追加すると、負荷をより多くのホストに分散するのに役立ちます。他のホストよりも多くのコア/プロセッサを備えたホストがある場合は、高vCPUVMをこれらの高コアホストにペグすることも役立ちます。物理ホストがVMを超えない場合でも少なくとも同じ数のコアを持つようにする必要があります。そうしないと、ほぼ同時にロックする必要があるため、vCPUからpCPUへの超過をスケジュールするのが非常に遅く/困難になります。 。

最後に、ハイパーバイザーはVMの予約と制限をサポートする場合があります。時々これらは偶然に設定されます。これらの積極的な設定により、実際に基盤となるリソースが使用可能な場合でも、CPUの準備が整う可能性があります。通常、予約と制限は慎重に、絶対に必要な場合にのみ使用するのが最善です。ほとんどの場合、適切なサイズのクラスターはリソースのバランスを適切に取り、これらは通常必要ありません。

要約すると、CPU Readyに対する最善の防御策は、CPU Readyが存在することと、それをチェックする方法を知っていることです。次に、上記の環境に最適な緩和手順を体系的に決定できます。スクリーンショットとチャートは特にVMwareに適用されますが、ほとんどの場合、この記事の情報はすべてのハイパーバイザーに普遍的に適用されます。