仮想化でプリセールスしてるSEの一日

VMware から Azure まで、インフラや仮想化の最新情報をベンダー色をできるだけ抑えて綴っていきます

ESX 4.1 の vCPU オーバーコミットと CPU スケジューリング

f:id:ogawad:20190203195705p:plain:right

前回、vCPU オーバーコミット*1 の際のハイパーバイザーの動きをハードウェアの視点からご紹介したのですが、私の師匠から「一般的には確かにフリーズは起きるが、現行の VMware ESX については独自の技術で緩和を試みている」とご連絡をいただきました。


VMware ESX 4.1 ですが、下記の資料に詳しく解説されています。
VMware vSphere 5 については、まとまったホワイトペーパーがまだ無いようです)

The CPU Scheduler in VMware ESX 4.1
http://www.vmware.com/resources/techresources/10131


要約していくと、、、


The ESX CPU scheduler meets this challenge by implementing relaxed co-scheduling of the multiple vCPUs of a multiprocessor virtual machine. This implementation allows for some flexibility while maintaining the illusion of synchronous progress.


ESX の CPU Scheduler は、同期プロセス内の "illusion"(幻覚)を利用して vSMP 環境での柔軟性に挑戦している。


It is worth noting that there is no co-scheduling overhead for an idle vCPU, because the skew does not grow when a vCPU halts.
For example, when a single-threaded application runs in a 4-vCPU virtual machine, resulting in three idle vCPUs, there is no co-scheduling overhead and it does not require four pCPUs to be available.
If the skew becomes greater than a threshold, typically a few milliseconds, the entire virtual machine would be stopped (co-stop) and will only be scheduled again (co-start) when there are enough pCPUs available to schedule all vCPUs simultaneously.


他の仮想マシンによって vCPU を確保できなかったとしても Guest OS はすぐには障害検知しない。
Guest OS が確保して処理を行わせている vCPU と、確保できず処理を行えなかった vCPU との "skew"(処理遅れ)が数ミリ秒のしきい値を超えると障害となる。
逆に言えば、この猶予時間内であれば、確保できた一部の vCPU だけ処理を進められる。我々はこの猶予時間に着目した。


Previously, the entire virtual machine was stopped (co-stop) when the accumulated skew exceeded the threshold.
The virtual machine was restarted (co-start) only when enough pCPUs were available to accommodate the vCPUs that lagged behind.
In ESX 4, the progress of each vCPU in a virtual machine is tracked individually and the skew is measured as the difference in progress between the slowest vCPU and each of the other vCPUs.
In ESX 4, instead of stopping or starting a set of vCPUs, only the vCPUs that advanced too much are individually stopped.
Once the lagging vCPUs catch up, the stopped vCPUs can start individually.
Co-scheduling all vCPUs is still attempted to maximize the performance benefit of co-scheduling.


従来バージョンでは、やはり猶予時間を超えてしまうと 前回の解説 のように仮想マシン全体のフリーズ・再開 (co-stop/co-start) が発生していたが、ESX 4 では Guest OS の各 vCPU 間の処理遅れを個々に追跡するようにした。
これにより、仮想マシン全体をフリーズ・再開するのではなく、猶予時間を超えるほど処理が進んだ vCPU だけを個々にフリーズ・解除するように改善した。我々はできる限り性能を伸ばせるよう努力している。


... ということだそうです。
vCPU を確保できなくても、"illution" と表現された CPU 障害を検知するまでの猶予時間に着目し、少しでも処理を進めるとのこと。
vCPU をずっと確保できず猶予時間を超えてしまった場合、ESX 4 では猶予を超える原因となる最も処理が進んだ vCPU のみを個々にフリーズし、仮想マシン全体のフリーズ・再開を極力避けるそうです。
もちろん、vSMP 環境で大幅にオーバーコミットさせるなど、どの vCPU も猶予時間を超えてしまうと全体フリーズに入りますが、確かに緩和されると思います。


実際の動きを細かく検証してみたかったのですが、いまはちょっと co-stop/co-start や vCPU 単位の停止/再開を見る余裕も環境も無く、とりあえずこのホワイトペーパーの内容で締めたいと思います。(誰か検証したら教えてください)

*1:実際のコア搭載数より vCPU アサイン総数が多い状態