忙しくてちょっとエントリーが遅れ気味です。
さて、前回はESX ServerにおけるCPUの同期スケジューリング処理について書きましたが、今回はそれ以外のESXにおけるCPU管理の要点について、ざっと書いてみたいと思います。
(1) - ゲストOSは自分が完全にCPUを管理していると思っている
(2) - CPUスケジューリングは色々
(3) - CPU同期スケジューリング
…の続きです。
■スケジューラセル単位での分散ロック
ESXホストでは、スケジューリング処理を"スケジューラセル"と呼ばれる単位で管理しています。CPUにおけるスケジューラセルとは、ローカルな物理プロセッサ群におけるスケジューリング領域として機能する単位(ドメイン)を意味します。言い換えれば、CPUスケジューリングはセル単位で処理されており、他のセルには影響を与えることはありません。スケジューラセルの仕組みは、多くのCPUが搭載されたシステムにおいて高いCPUスケジューラ性能を発揮させるためにデザインされた仕組みです。
他のOSにおいても、CPUスケジューラの拡張性は重要な要素となっています。拡張性のあるCPUスケジューラは、CPU数やプロセス・ワールドの管理数などが増えたとしてもオーバーヘッドをなるべく発生させない仕組みであることが重要です。ESXホストにおいてpCPUあたりの実行仮想マシン数が多くない場合については、一般的なOSよりも管理しなければならないワールドの数は少ないはずですが、より多くのCPUを持つシステムの場合、これは重要なポイントです。
マルチプロセッサのシステムにおいては、複数のpCPUにおいて同時にそれぞれのCPUスケジューラが実行されるため、同じデータに対して複数のアクセスが同時発生する可能性があります。このような状況において、データの整合性を確保する方法としてはアクセスをロックすることにより排他制御を構成します。最も単純な解決策としては、すべてのCPUスケジューラをロックすることですが、この場合には同時アクセスが発生するたびにCPUスケジューラがロックされるため、処理性能は大きく低下してしまうこととなります。そのため、パフォーマンスインパクトを抑えるためには、より細かな単位でのロックを行う仕組みが必要となります。それが、スケジューラセル単位での分散ロックです。
スケジューラセルの仕組みにより、より細かな単位でのロックを可能とします。すべてのCPUに影響を与えてしまうグローバルロックに換わり、ESXは物理CPUを複数のセルと呼ばれるグループに分けることにより、ロックの範囲をセル内にとどめる仕組みを取ります。これにより、CPUスケジューラはセルにおける競合だけを意識すればよいこととなります。
セルのサイズは、マルチプロセッサ構成の仮想マシンが収まる程度には大きくなければなりません。なぜならば、マルチプロセッサの仮想マシンにおいては、同期されたCPUスケジュールの割り当てが必要となることが想定されるためです。同期スケジュールを必要とするvCPU間では、厳密な同期処理が必要となることが考えられます。常にvCPUのリソース要求が単一セルの範囲だけに留まるのであれば、スケジューラセルをまたいだロック管理は必要ないかもしれません。しかし、仮想マシンを実行する環境においてはそれは限定的な効果しか発揮しない場合が多いといえます。
■CPU間における負荷分散
ESXサーバは通常、マルチプロセッサのシステムにおいて実行されます。マルチプロセッサシステムにおいては、プロセッサ間のCPU使用率もしくは負荷のバランスをとることがパフォーマンスを発揮するためには非常に重要です。忙しいCPUから余裕のあるCPUに対して、ワールドの処理を移動させることによってCPU負荷を分散させることができます。一般的に、ワールドの処理を別のCPUに移行することによって、全体的なCPU使用率に対する応答性は向上します。
2つのCPUだけを持つシステムを考えてみた場合において、複数のワールドに対する処理が一方のCPUに対してだけスケジュールされていたとします。負荷をロードバランスする仕組みがなかった場合、このような不均衡は結果として処理の遅延とCPU使用率の低下につながります。ESXでは、異なるpCPUにワールドの処理を移行することが可能となっています。他のpCPUが担当していたワールドの処理を引き受けるパターンや、他のpCPUに自身の担当しているワールドの処理を依頼するパターンなどがあります。これらの移行の仕組みにより、ESXは高いCPU使用率と低い遅延の両面を達成します。
しかし、pCPU間でワールドの処理を移行することには一定のコストがかかります。たとえば、異なるCPUに処理を移動させる場合、CPU内蔵キャッシュに蓄積されていたデータはメモリに書き戻した上で一度クリアする必要があります。当然ながら、パフォーマンスの観点からは頻繁なワールドの処理CPUの変更は望ましくありません。そのため、CPUスケジューラは処理の移行に一定の制限をかけており、CPU間の負荷バランスが大きく異なっていて処理を移行することによるメリットが一定以上大きいと判断した場合にのみ、ワールドの処理を異なるpCPUへと移行します。また、ESXはCPUリソースをセル単位で区切ってスケジューリングしているため、セル間での移動は極力行わないような仕組みとなっています。
■NUMA対応
NUMAに対応したサーバでは、CPUとメモリから構成されているNUMAノードが複数構成されています。NUMAでは、同一ノード内のメモリアクセスをローカル、異なるノードのメモリアクセスをリモートとして扱います。CPUからローカルメモリに対するアクセスと比較して、リモートメモリに対するアクセスはより多くのホップをたどる必要があり、長いサイクルを必要とします。このようにNUMAはその名の通り非対称なアクセス速度を内包しているため、なるべくメモリアクセスをローカルに保つか、最大限ローカルメモリに収めることにより、パフォーマンスは最適化されます。ただし、CPUの負荷分散という観点から見ると、CPU間での負荷を分散させることもまたパフォーマンスにとっては重要な要素です。
ESXはNUMAを意識して仮想マシンに対してCPUとメモリのリソースを同一のNUMAノードから割り当てるように動作します。これにより、仮想マシンにおけるメモリアクセスはほとんどがローカルアクセスとなります。
もし仮想マシンの配置されているNUMAノードにおけるCPU負荷が他のノードと比較してとても重かった場合、ESXホストはメモリアクセスが一時的にリモートアクセス状態となったとしても実行するCPUを変更することを選択します。実行されるCPUの変更に伴い、可能であればメモリについてもローカルアクセスとなるように移動されます。ただし、メモリのノード間コピーは非常に大きなオーバーヘッドを伴うため、メモリの移動は徐々に実行されます。
■HT対応
ハイパースレッディングは、1つのCPUにおいて同時に複数のコンテキストの実行を可能とする技術です。スレッドレベルにおける並列処理によりパフォーマンスの向上が期待できますが、物理的なCPUとしては単一のため、性能的な向上は大きくは期待することはできません。そのため、ESXホストが管理する論理CPUにおいてアイドル状態であったとしても、HTによって構成されているペアの論理CPUが忙しい場合には、リソースの割り当ては他の論理CPUとした方が性能が発揮できるということとなります。
そのため、ESXにおけるCPUスケジューラは可能な限り、CPUの割り当てにおいてHTによる見せかけの論理CPUを同時に使わないようにリソースのアサインを行います。設定オプションを構成することにより、HTを使用しないようにしたり、一方のスレッドが使用されている場合には他方のスレッドにはリソースアサインを行わないようにすることが可能です。
次回は再びCPUスケジューリングの話に戻り、ESXが4.x世代となってCPUスケジューリングの仕組みがどのように改善されているのかについて書いていきたいと思います。
