サーバは仮想化されるべきだが、データベースには気をつけろ

The Server Storage IO Groupのアナリストが書いているブログ「StorageIOblog」に、「Should Everything Be Virtualized?」（すべては仮想化されるべきなのか？）というエントリがポストされました。

すべてのサーバ、I/O、ストレージは仮想化されるべきなのか？ という問いに答えるエントリになっています。

Unfortunately consolidation is commonly misunderstood to be the sole function or value proposition of server virtualization given its first wave focus. I agree that not all applications or servers should be consolidated (note that I did not say virtualized).

残念なことに、サーバ仮想化の最大のメリットはコンソリデーション（サーバ統合）であると誤解されている。私は、すべてのアプリケーションやサーバがコンソリデーションされるべきとは思わない（仮想化されるべきではない、と言っていないことに注意！）。

著者のGreg Schulz氏は、エントリをこのように切り出しています。先回りして彼の結論を書いてしまうと、この文に表れているように、サーバ統合をしない場合でもサーバを仮想化することにはメリットがある、物理サーバ1台に対して仮想マシンを1台しか稼働させない場合でも仮想化にはメリットがある、だからサーバ仮想化は積極的にするべきだ、との主張です。

todays current wave or focus is around maximizing the number of VMs and/or the reduction of physical machines to reduce capital and operating costs for under-utilized applications and servers, thus the move to stuff as many VMs into/onto a PM as possible.

いま注目されているのは、物理サーバ上に多くの仮想マシンを載せることで物理サーバへの投資を減らし、また運用コストを削減するところにある。その結果、1台の物理サーバにどれだけ仮想サーバを集められるか、といった動きになりがちだ。

Shulz氏は、仮想化によるコンソリデーション以外のメリットに注目するよう読者を促しています。

there is still a benefit of having a VM dedicated to a PM. For example, by dedicating a PM (blade, server or perhaps core) allows performance and QoS objectives to be meet while still providing the ability for operational and infrastructure resource management (IRM) flexibility and agility.

仮想サーバが物理サーバに与えるメリットはほかにもある。例えば、性能管理やQoSのためにリソースを柔軟に操作し、またそれが迅速に行えることだ。

（一部略）Meanwhile during busy periods, the application for example a database server could have its own PM, yet during off-hours, some over VM could be moved onto that PM for backup or other IRM activities. Likewise, by having the VM under the database with a dedicated PM, the application could be moved proactively for maintenance or in a clustered HA scenario support BC/DR.

フル稼働時には専用のサーバを占有して動作するデータベースサーバでも、アイドル時には仮想サーバ機能によってバックアップ用の物理サーバへ移動したり、それ以外の操作が可能になる。たとえ専用サーバ上で動作しているデータベースであっても、仮想サーバ上で管理することにより、ハードウェアメンテナンスのために事前に別のサーバへ移動させたり、ディザスタリカバリのために可用性の高いクラスタ構成にするといったことが可能になるのだ。

物理サーバとOSやアプリケーションを仮想サーバによって切り離すことにより、柔軟性というメリットが得られる。コンソリデーションというのは、そのメリットの1つでしかない、というのがSchulz氏の主張と理解しました。

大規模なデータベースは仮想化すべきでない

一方で、仮想化仮想化とうるさいシステム管理者よだまれ！ と一喝するのが、「IT Knowledge Exchange」に投稿された「Hey sysadmins, quit trying to virtualize everything!」（システム管理者よ、全部を仮想化するなんてやめてくれ！）というエントリ。

著者のDenny Cherry氏は、SQL Serverなどデータベースに深い経験を持っているとのこと。

The problem here is that SQL Server (same goes for Oracle, MySQL, DB2, etc) is very different that applications which run on other servers. Databases love memory, they eat it up like its candy. There's a reason for this. Its so that they don't have to hit the disk all the time reading data. We want all the data stored up in the buffer pool (might be called something else on other platforms).

問題は、SQL Serverやその他のデータベースはちょっと特殊だということ。データベースはメモリ食いだ。なぜかといえば、データを読み込むときにいちいちディスクへアクセスしないようにだ。すべてのデータはバッファプール（あるいはほかの呼び方）にあったほうが（アクセスが速くて）よい。

データベースだけは、メモリを大量に必要なため仮想化しないほうがよいと。

さらに、データベースでチェックポイント（定期的にメモリ上のデータとディスク上のデータを同期させるための動作）が発生すると、その間は大量のI/Oが発生します。この大量のI/Oも、仮想化を利用しないほうがよい理由として挙げられています。

my production OLTP database (the database that services our customers via our website) usually has 3-4 IO going to each of the 4 LUNs that the database sits on. However when the database checkpoints there's easily 3-4k IOs going to each of the disks (that's 12-16k IOs at one time being written to the disks). Putting that sort of disk load into a virtual environment would cause a large amount of queuing to happen when the database flushes.

いま実運用中のデータベースでは、通常の状態では4つのロジカルユニットに対して1秒間に3～4回I/Oが発生している。しかしチェックポイントが発生すると、簡単にそれが3000回から4000回のI/Oへとはねあがる（つまり12000回から16000回のディスクへの書き込みI/Oが発生する）。仮想環境ではこうした負荷はキューイングされてしまうだろう。

その間、処理がブロックされ、そのブロックがまた別のブロックを呼び、処理がどんどん遅くなっていくとCherry氏は書いています。

ただし、Cherry氏が対象としているのは大規模なデータベースのみで、中小規模のデータベースはCherry氏自身でも仮想化して運用しているとのこと。

Now don't get me wrong, smaller database servers can be virtualized without much of an issue. I've got a smaller SQL Server running our Shopping Cart, Ticketing system, Microsoft CRM, and BlackBerry Enterprise Server all running in a single VM with 4 Gigs of RAM, and 2 vCPUs and it's cranking along without issue.

誤解しないでほしいが、小規模なデータベースサーバならこうした問題なく仮想化できる。私自身も、ショッピングカート、チケッティングシステム、マイクロソフトCRM、ブラックベリーサーバなどを、4GBメモリで2仮想CPUのうえで問題なく動作させている。

仮想化ソフトウェア自身のオーバーヘッドも多少はあることでしょうし、それ以上に仮想化した場合には、通常は複数の仮想サーバが1台の物理サーバに寄せられますから、メモリが豊富に使えなくなったり、また複数の仮想サーバからのI/Oが集中するためにI/Oの負荷が高まることをCherry氏は指摘しているのだと思われます。

システム管理者としては、すべてのサーバを仮想化してしまったほうが全体を一括して管理しやすい。しかし事情により仮想化しないほうがよいサーバもある。そうしたバランスの落としどころをどうするか。システムの設計は、仮想化1つとっても難しいものですね。