VMware vSphereでVMへ過剰vCPUの割り当て

　VMware vSphereによる仮想化基盤を構築する案件が色々ある。ここで業務チームが以来してくる計算機資源の設定が何時も問題になっている。

　筆者の所属する企業の案件は東証1部のかなりの部分を占める中堅規模の企業が多く、TOPIX coreになるような大規模な案件は少ない。案件は生産、販売、会計の業務が多い。

　結論から書けばサーバのCPUに投資するより、ストレージに投資する方がコストパフォーマンスが良い。また仮想化基盤ではVMに割当するvCPUは最小限に抑えるべきである。

　業務チームの方々から「DBは8vCPUで！」と元気よく依頼される事が多々ある。
　本当にこれだけ必要なのか？というと大概は不要である。大概のDBサーバを観察するとCPU使用率が100%になる事は滅多にない。しかしながら、経験豊富な業務チーム程要求CPUが多くなるのだ。
　これは古い案件では「性能が心配なので、物理DBサーバでは4コアCPUを2ソケット」と言った構成が多かったのでは推測している。この手のシステムを一度経験してしまうと、以前よりCPU数を減らすのは抵抗感があるのだろう。また、業務システムを構築後、基盤負荷を定期的に確認するという文化が根付いていないので、適切なサイジングだったか？というフィードバックがなされていないのもあると思われる。

 　さて、この過剰な要求をそのまま現代の仮想化基盤で設定してしまうとどうなるのか？
　現代の仮想化基盤ではCPUはある程度オーバーコミット設定するのが定石である。オーバーコミット状態で多数のvCPUをVMへ割り当てしてしまうと、VMが動作開始するには設定したvCPUが全て利用可能になるまでVMは起動を待つことになる。この起動待ちはVMwareではReadyとして表示される。 このReadyが増加していることは折角の仮想化ホストのCPUが有効に利用されていないという事である。また、vCPUを過剰にするとVMが起動するまでの待ち時間が増え、結果的に遅くなってしまう。

　アプリケーションがマルチスレッドに対応しておらずCPUを有効に使えないのであればvCPUを増やしても過剰なvCPU設定は性能劣化の原因となってしまう。

　加えて前述のような中堅向けのシステムではOracleもStandard Editionが殆どである。Enterprise Editionであれば、パラレルクエリでCPUが多い効果が得られる（LINK先PDF）。Standard Editionではアプリケーションで相当意識しないと、CPUを増やしても効果は少ない。
　また、前出のOracle社の資料にある通り、DB性能ボトルネックはCPUが全体の9%であり、大半はI/OとSQLに問題があるとなっている。IBM社の調査ではI/Oの待ちでCPUが効率的に利用できないとある。
　VMware Essential Plusで構築可能な仮想化ホスト3台の構成でもSSDによるDBのボトルネック解消とCPU削減、この結果のコストの削減は十分に可能である。