CPUとメモリについて

CPUの種別について

CPUの種別設定では、CPUの世代や機能ごとに選ぶことができ、プライベートクラウド基盤が異なるCPUになったとしても同じように利用する事ができるように、一定の機能制限ラインを引くことができるようになっています。なお、Intel/AMD間でのライブマイグレーションの保証はありません。

プルダウン最下段の「host」を選ぶと物理ホストと同じCPUを利用し、もっとも効率良くCPUを活用する事ができますが、世代が異なるホスト間でライブマイグレーションができなくなるため、将来、仮想データセンターに新しいHRPCを増設する際、問題となる可能性があります。

現在のほとんどのOSは、x86-64-v2であれば動きます。 SSE3、SSSE3、SSE4.1、SSE4.2、POPCNT、CMPXCHG16Bなどの命令セットがサポートされています。x86-64-v2-aesは、AES暗号化命令がサポートされているため、暗号化するソフトウェアが高速に動作します。

x86-64-v3を選ぶことで、AVX/AVX2命令の利用ができるようになります。またx86-64-v4を選ぶことで、加えて、AVX512命令セットを利用することができます。

当社のプライベートクラウド6Gt以降モデルで、すべてx86-64-v4に対応しています。

表にしたものが下記の通りになります。

KVMのメモリ管理とBallooningドライバ

結論からいうと、HRPC基盤においてBallooningドライバは意味を持たないため、アンチェックすることが推奨です。

KVMにて「最小メモリ量」を「メモリ」と同じ値に設定する事で、設定上は固定的なメモリ設定ができるように感じます。しかし実際は、Linuxのメモリ管理の特性により確保量と使用量は異なります。メモリ確保では、最小メモリ量と同じ分、起動時に確保されますが、実際に使用されるのは初めてメモリに書き込みを行った時点からです。すなわち、実質的にメモリは動的に使用されていきます。これが「Type II系ハイパーバイザー」のメモリ確保の典型的な特徴です。

この状況は、ホストや仮想マシンのサマリの「メモリ使用状況」を見ることで推し量ることができます。実際に、仮想マシンへの割当より、サマリ上の「メモリ使用状況」が少なく表示されます。下記の状態では32GiBの仮想マシンを起動していますが、実際には13.56GiBしか利用していません。

一般的なProxmox VEのシステムでは、メモリが空いている限り仮想マシンを作成する事ができます。これは、収容率を重視しているためです。しかし、このように「メモリ使用状況(RAM Usage)」が少なくみえていると、管理者は仮想マシンに実際の「物理搭載メモリ量」よりも、多くのメモリを割り当てて仮想マシンを起動してしまいがちです。

具体的に言えば、Proxmox VEの管理パネルでは、上図において、実行容量が青の部分の合計しかわからないため、システム管理者は、もう1〜2台の仮想マシンを起動しても問題無いように見えます。メモリを「確保」していたはずなのに、そのメモリが他の用途に使われている状態になり、これをメモリオーバーコミット状態といいます。この状態であっても、メモリが実際に使い切られることがなければ、何の問題も無くシステムは動きます。

しかし、この状況下で、起動中の「仮想マシンVM#1」が、突然、メモリを確保分のすべてを使用しはじめると、オーバーコミットではメモリ不足を引き起こし、システムが不安定になりはじめます。たとえば、親OSのカーネル層でOut-Of-Memory Killerが動き、ランダムに何かの仮想マシンや、ハイパーバイザー管理のための重要なプロセスを、勝手に終了させたりします。リソース共有技術によって沢山の仮想マシンを「収容率」する仕組みが裏目にでるわけです。

これでは、エンタープライズ用途としては使いにくいので、HRPC 6Gvに搭載されているInfiniCloud HVの場合、互いに影響を与えにくい「隔離性」を重視し、このような状態にはそもそも「ならない」ようにカスタムハイパバイザが作られています。具体的には、そもそも搭載容量よりも多くの仮想マシンは起動できないようになります。繰り返しますが、Proxmox VEのダッシュボードではInfiniCloud HVを利用していても、青の部分の合計しか見えないので、「メモリが余っているように見えるのに、新しい仮想マシンを起動しようとしたらエラーがでて起動できなかった」という動きをします。

バルーンデバイスについて

最後にもう一歩、メモリ周りについて知識を付けたい人のために、誤解の多いバルーンデバイスについて記載します。

仮想マシンのBallooning Deviceを有効にし、仮想マシンでBalloning Driverが組み込まれているケースを考えてみましょう。

上記のようなシチュエーションで、ホストマシンのメモリが足りなくなってしまったとき、Ballooning Driverは、仮想マシン内のカーネル空間でバルーンのようにメモリを利用しはじめます。すると、仮想マシンのゲストOSの中でメモリが逼迫し、メモリ上に保持する優先順位の低いメモリ、たとえばディスクキャッシュや、Dirty Pageなどを解放せざるをえなくなります。仮想マシン内の仮想OSのBallooning Driverは、ゲストOSのカーネル層ではメモリ確保してロックしています。したがってKVMはこの空間を「ホストOSに返却」することで、ホストOS(KVMのハイパバイザ層)のメモリに余剰が生まれることになります。

この処理は、メモリが枯渇しはじめると、多くの仮想マシンで発生します。もちろん「メモリが足りない」というトリガーで発生するため、ゲストOS内のメモリ解放のためCPUに負荷を発生させます。また、仮想マシン内でもディスクキャッシュが解放されるため、IO数が増え、キャッシュ再充填が起きるなど、結果としてホスト全体の様々な処理が遅延しはじめます。Ballooning構造はホストOSを保護するために動作しますが、結果的には不安定さも引き起こしたり、システム全体の一瞬の停止(プチフリーズ)なども発生します。システムでHAが組まれていると、レイテンシの遅れに敏感であるため、こういったプチフリや、重さがが不安定さを更に招くことになります。

そこで、HRPCに搭載されたInfiniCloud HVでは、そもそも、このようなことが起きないように、メモリの利用を厳格にしています。ユーザーであるシステム管理者が、オーバーコミットして仮想マシンを起動できないように、リソース共有率よりも隔離性を高め、安全側に倒した設計をしています。Ballooning Deviceは、メモリが足りなくなって初めて動くため、InfiniCloud HV搭載のProxmox VEにおいては、Ballooning Deviceはほぼ動作しないことがわかるかと思います。