仮想化によるサーバー集約でよく問題になるのが,現実的には「仮想化できないサーバー」の存在だ。特に,処理性能面での制約が大きい。アプリケーションの特性や仮想化ソフトのオーバーヘッド,環境設定などを十分に吟味しないと,思わぬトラブルに遭遇する。

 仮想化により実際にサーバーを集約する場合、集約先のサーバーにはブレードなど小型機を使うことが多い。ネットワークの配線や保守が容易、設置面積が小さいなどサーバー統合に適しているからだ。パイオニアやアパマンショップ、宇部興産など、ほとんどの企業がブレードを採用している。

 ブレードの処理性能はそれほど高くないため、負荷の高い大型サーバーは仮想化による集約の対象になりにくい。仮想化ソフトを使えば、4CPU搭載の実マシンの上で4CPU搭載の仮想マシン2台を動かせることは事実だが、これは実マシンが搭載するCPUやメモリーを分割して仮想マシンに割り当てているだけの話。当たり前だが、仮想化ソフトを使ったからといって実マシンが搭載するCPU数以上の処理能力を生み出せるわけではない。

 こうしたことから宇部興産は独SAPのERP(統合基幹業務システム)用のサーバーは仮想化ソフトによる集約の対象から外した。引き続き富士通の大型IAサーバー「PRIMEQUEST」で動かす。同社は3年後をメドにサーバー500台の集約を進めているが、集約先はデュアルコアCPUを2個搭載したブレードなので、ERPを動かすサーバーには力不足と判断した。

 それでは実マシンの処理能力以下のサーバーなら何でも集約できるのかというと、それも違う。各仮想マシンに割り当てるCPU数の設定を誤ると、仮想化ソフトのオーバーヘッドが大きくなり、実マシンのCPUをかえって無駄遣いすることになる。導入時には十分な検証と設計作業が欠かせない。

 一般には仮想化ソフトを使うと実マシンのCPUの使用率を向上できる。例えばCPU使用率20%のサーバー4台を1台に統合すれば、仮想化ソフトのオーバーヘッドを除いた単純計算では使用率が80%に高まり資源を有効活用できるはずだ。

 ところが仮想マシンの設定を間違えると、これは“机上の空論”になる。VMwareを例にとると「仮想CPU」という単位で実マシンのCPUリソースを各仮想マシンに割り当てるのだが、各仮想マシンは実マシンのCPUを割り当てた分だけ同時に使おうとする。

 つまり、ある仮想マシンに仮想CPUを4個割り当ててしまうと、実マシンのCPUが4個同時に空かない限り処理の順番が回ってこないのだ。これではスケジューリングの効率が極端に劣化し、仮想マシンの処理性能が低下する(図1)。

図1●仮想化ソフト「VMware」で仮想マシンにCPUを割り当てる仕組み
図1●仮想化ソフト「VMware」で仮想マシンにCPUを割り当てる仕組み

 先述の石垣はこの問題であわてた。PDMシステムのサーバー4台をデュアルコアCPU2個(計4コア)搭載のブレードに集約したところ、システムの応答が明らかに遅くなった。

 仮想マシンに割り当てる仮想CPU数の合計を5個と、実マシンのCPU数(コア数)を超えて設定したのが原因だった。業務終了後、仮想CPU2個を割り当てていたデータベース・サーバー用仮想マシンを1個に減らしたところ、問題はすぐに解決したという。

 同様の問題はXenやHyper-Vでも起こる。性能を重視する際は、仮想マシンに割り当てる仮想CPU数の合計は実マシンのCPU数(コア数)以下にとどめるのが賢明だろう。