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に対応しています。
表にしたものが下記の通りになります。
プロセッサ | x86-64-v1 | x86-64-v2 | x86-64-v2-aes | x86-64-v3 | x86-64-v4 |
---|---|---|---|---|---|
対応命令セット | ベースx86-64命令セット | SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CMPXCHG16B | x86-64-v2 + AES | AVX, AVX2, BMI1, BMI2, FMA, MOVBE | AVX-512ファミリー(AVX-512F, AVX-512CD, AVX-512DQ, AVX-512BW, AVX-512VLなど) |
Intel Xeon | Intel Xeon 3000/5000/7000シリーズ (初代) | Intel Xeon 5500シリーズ (Nehalem) 以降 | Intel Xeon 5600シリーズ (Westmere) 以降 | Intel Xeon E3 v3 (Haswell) 以降, Intel Xeon E5/E7 v3 (Haswell-EP/EX) 以降, Intel Xeon Scalable Processors 1st Gen (Skylake-SP) 以降 | Intel Xeon Scalable Processors 2nd Gen (Cascade Lake-SP) 以降, Intel Xeon Scalable Processors 3rd Gen (Ice Lake-SP) |
AMD Opteron | AMD Opteron 100/200/800シリーズ (SledgeHammer) | AMD Opteron 4200/6200シリーズ (Bulldozer) 以降 | AMD Opteron 4300/6300シリーズ (Piledriver) 以降 | 該当なし | 該当なし |
AMD EPYC | 該当なし | 初代 AMD EPYC (Naples) | 初代 AMD EPYC (Naples) | AMD EPYC 7002シリーズ (Rome) 以降 | AMD EPYC 7003シリーズ (Milan) 以降 |
KVMのメモリ管理とBallooningドライバ
結論からいうと、HRPC基盤においてBallooningドライバは意味を持たないため、アンチェックすることが推奨です。
KVMモデルでは、「最小メモリ量」を「メモリ」と同じ値に設定する事で、設定上は固定的なメモリ設定ができるようにみえます。しかし、実際はLinuxのメモリ管理の特性により確保量と使用量は異なります。メモリ確保では、最小メモリ量と同じ分、起動時に確保されますが、実際に使用されるのは初めてメモリに書き込みを行った時点からです。すなわち、実質的にメモリは動的に使用されていきます。
この状況は、ホストや仮想マシンのサマリの「メモリ使用状況」を見ることで推し量ることができます。実際に、仮想マシンへの割当より、サマリ上の「メモリ使用状況」が少なく表示されます。下記の状態では32GiBの仮想マシンを起動していますが、実際には13.56GiBしか利用していません。
一般的なProxmox VEのシステムでは、メモリが空いている限り仮想マシンを作成する事ができます。このように「メモリ使用状況(RAM Usage)」が少なくみえていると、管理者は仮想マシンに実際の「物理搭載メモリ量」よりも、多くのメモリを割り当ててしまいがちです。具体的に言えば、上の図のハイパバイザ「Type II系のメモリ確保手法」と同じように仮想マシンを立ち上げているとき、実利容量が青の部分しかわからない場合、もう1〜2台の仮想マシンを起動しても問題無いように見え、そして起動してしまいます。これをメモリオーバーコミット状態といいます。この状況下で起動中の仮想マシンが、突然、メモリを使用しはじめると、オーバーコミットではメモリ不足を引き起こし、システムが不安定になります。たとえば、親OSのカーネル層でOut-Of-Memory Killerが動き、ランダムに何かの仮想マシンや、仮想マシン動作のために重要なシステムを勝手に終了させたりします。
HRPC 6Gfでは、用途がエンタープライズ用に特化しているため、隔離性を重視しており、このような状態にはそもそも「ならない」ようにカスタムハイパバイザが作られており、搭載容量よりも多くの仮想マシンは起動できないようになっています。
さて、このように、ホストマシンのメモリが足りなくなってしまったとき、Ballooningデバイスが有効になっていて、かつ仮想マシンにBalloning Driverが組み込まれていると、Ballooning Driverが仮想マシン内でカーネル内でメモリを利用していきます。すると、仮想マシンのゲストOS内は不要と思われるメモリ(ディスクキャッシュやDirty Pageなど)を解放せざるをえなくなります。仮想マシンのBallooning DriverはゲストOSのカーネル層でメモリを確保してロックしたため、これを「ホストOS」に返却することで、ホストOS(KVMのハイパバイザ層)のメモリに余剰が生まれることになります。
この処理は、メモリが枯渇しはじめた比較的短時間に多くの仮想マシンで発生することになり、CPUに負荷が発生します。また、仮想マシン内でもディスクキャッシュが解放された結果、IO数が増え、キャッシュ再充填が起きるなど、結果としてホスト全体の様々な処理が遅延し、Ballooning構造が働いたとしても、不安定さを引き起こします。特にHAシステムはレイテンシの遅れに敏感であり、重さが不安定さを更に招くことになります。
先述したとおり、HRPC6Gfのカスタムハイパバイザでは、仮想マシンが不必要に起動できないように設計されています。したがって、HRPC6Gfにおいて、Ballooningデバイスは実際には、ほぼ意味を持ちません。