仮想化HypervisorであるVMware ESXは、同時に実行される複数の仮想マシンに対してリソースを配分するために様々な仕組みを実装しています。中でも、メモリ管理に関する仕様はとても興味深く、また面白い仕組みとなっています。全何回のエントリーが必要なのかまったくわからないのですが、しばらくの間、このESXサーバにおけるメモリ管理の仕組みについて、書いてみたいと思います。なお、このシリーズ？エントリーは以下の資料を参考としています。エントリー中の絵も拝借しています(^_^;)。
- VMware Performance Study "Understanding Memory Resource Management in VMware ESX 4.1" (PDFダウンロード)
- Carl A. Waldspurger (VMware)*1 "Memory Resource Management in VMware ESX Server" (論文PDF／スライドPDF)
ソースコードが公開されていないために、ESXの技術仕様は外からは技術文章などから垣間見ることしかできませんが、仕組みレベルでしか確認できないが故に様々な検証が行われ、動作が評価されているともいえます。ESXを使う上では、ここまで細かくメモリ管理の仕様について理解する必要はありませんが、それでも自分たちが使っているものをより詳細に知ることにより、より適切に利用することができるようになるともいえるのではないでしょうか。
- なぜ、メモリ管理は重要なのか？
仮想化によって仮想マシンに対して割り当てられる"リソース"であるCPU, memory, Disk, Networkの中で、メモリは最も扱いづらいリソースです。
CPUは計算処理のためのリソースであり、必要なときにだけ割り当てれば問題ありません。事前に確保しておく必要はありませんし、突然のリソース要求に対してもHypervisorはすぐに答えることができます。割り当てるべき論理CPUがなかった場合であっても、CPUはタイムスライスで割り当てを行うリソースであるために順次処理が進むことによって割り当てが行われます*2。マルチコアとHyper-Threadingが使われる現在では非常に沢山の論理CPUをリソースとして扱うことができるようになっていますので、そもそも割り当てるべきCPUリソースが確保できないタイミングも少なくなっています。CPUリソースを常に要求するような仮想マシンが多数同時に実行されているような場合はいざしらず、一般的な仮想マシンのCPU使用率は5-10%程度の場合も多いわけで、そのような仮想マシンがたとえ10台同時に稼働していたとしても、CPUリソースの競合によって待たされる状態が発生する可能性はそれほど高くないはずです。
Disk I/OおよびNetwork I/Oについては、逆にESXホスト側としては対応可能な手段が限定されているリソースとなります。ESX4.1から搭載されたStroage I/O Controller (SIOC) およびNetwork I/O Controller (NetIOC) によって、ある程度の相対的なコントロールは可能となりつつありますが、SIOCについては物理サーバも共有ストレージを使っているような構成においてはその間でのI/Oのコントロールはできませんし、NetIOCについても個別仮想マシンの通信に対してQoSを提供するようなことまではできません。だからこそ、仮想化を用いる場合においてストレージとネットワークはハードウェアベンダー側にとっては設計のキモとなるわけですし、ここが差別化のポイントとなるわけです。もちろん、VMware側としてもそこをハードウェアベンダー側にまかせきりにするつもりはないようで、vStorage APIによってストレージオフロード連携の機能を充実させつつありますし、VMWorld2010で発表されると最近噂になっているネットワークのHypervisor?については、ストレージにおけるvStorage APIと同じように、ネットワーク側についても「仮想化を意識した連携」を求める仕組みの提供になるのではないかと予測しています。ストレージもネットワークも仮想化を強く意識した新機能・新技術が続々と産まれつつありますので、このあたりはここ数年で大きく状況が変化していくことになるのではないかと思います。
さて、長くなりましたが、今回は序章ということで、本題には次回から入っていきたいと思います。
