一般的な例を挙げてみよう。データベース専用サーバの多くは、ストレージアレイにRAID 1+0（RAID 10としても知られる）を利用する。それらは高価だが、最良の結果を生む。ところが、VMのセットアップはパフォーマンスと冗長性のトレードオフを考え、RAID 5を利用していることが多い。前者のハードウェアに最適化したワークロードは、後者では専用の物理ディスクを割り振り、オリジナルRAID 1+0セットアップにリプレースしないかぎり、うまく処理できないだろう。

　この場合、ディスクはローカルにアタッチされたストレージでなければならないというわけではない。物理ボックスのローカルディスクと同等以上の速度を持つSANでも十分に機能する。問題はIOPSであり、目的達成に最適な技術なのではない。

　VMホストを自前で構築すれば、ある程度コントロールすることが可能だ。しかし、自前ではないVMホスティングを利用するときは、多用途多目的型のセットアップに甘んじなければならない。

VM記憶容量が十分でない場合

　データベースは大量の物理メモリがあれば大きな効果が得られる。それはオペレーションを実行する場所であり、I/Oのキャッシュする場所でもある。Microsoft SQL Serverはそうした理由から、スタンドアロンの専用マシンに置かれているときに最高の性能を発揮する。必要に応じてメモリを解放でき、同一マシン上の他のアプリケーションと直接対立することがないからだ。一般的な経験則として、可能であればデータベース全体――あるいは、少なくともそのうちの最もよく利用される部分――をメモリにキャッシュできるほどのRAMがあればよい。

　データベースサーバのVMバージョンにも物理サーバと同量、あるいはそれ以上のメモリを割り当てる必要がある。多くのVMシステムは、複数のVMでメモリの同一ページをシェアするためのメモリ共有技術を備えている。しかし、そうしたシェアリングは各マシンで実行するOSのようなものには有効だ。VM間で共有可能なものの多くは、データベースのコンテンツそのものではない。

　Microsoft SQL Serverインスタンス用のメモリ消費統計ツールは、ここでも役に立つ。プロダクションデータベースがどれほどのメモリを必要としているか確認でき、VMにどの程度メモリを割り当てればよいかも分かる。

仮想化へ向かう喫緊の理由がない場合

　仮想化が最適だというケースは、もちろんある。それによって生じるメリットが予想以上にある場合だ。より良い結果を得るために仮想化する。

　例えば、社内に古いスタンドアロンのレガシーMicrosoft SQL Serverセットアップがあり、それが今日のハードウェア標準から見てそれほど見劣りしないものであれば、仮想化の優れた候補となるだろう。マシンが古くて遅いほど仮想化のメリットは大きい。多くのマシンを統合すれば、電力消費、空調費、フロアスペースを節約できるはずだ。

　一方で、Microsoft SQL Serverの大規模なクラスタを運用していても、仮想化によってコスト削減やパフォーマンスの改善が見込めないケースも考えられる。クラスタをVMに統合すれば、電気代や空調費である程度の節約ができても、全体的なパフォーマンスを犠牲にすることになるかもしれない。そのような場合は、現状のままにしておくのがベストだ。

　Microsoft SQL Serverの仮想化は、それに最適なビジネスケースがあり、また全体的なIOPSが低下したり、プロセスのメモリアロケーションを失ったりしないときのみ実装すべきだ。仮想化のアドバンテージには目を見張るものがある。だが、それは1つのツールであり、必ず当たる魔法の弾丸ではないということを忘れてはならない。