データベースの仮想化に価値はあるか？

作者 Jonathan Allen , 翻訳者 岡田 英久 投稿日 2008年2月29日

セクション

運用/インフラ,

設計/アーキテクチャ,

デベロップメント,

エンタープライズ・アーキテクチャ

トピック

データウェアハウス ,

Architecture ,

仮想化 ,

.NET

タグ

SQL Server 2008 ,

SQL Server 2005

最近、仮想マシンのイメージ中にサーバアプリケーションを配備するのが流行っている。必要に応じて仮想サーバをあるマシンから別のマシンにすばやく移行できるため、IT 部門にとっては非常に便利である。しかし、この手法は SQL Server のような重量級のシステムにも適用できるのだろうか？Conor Cunningham 氏はこれに否定的な見解を述べている。

Conor 氏によると(source)、SQL Server の運用環境には以下に挙げるとおりいくつかの前提条件がある。

1. すべての CPU の能力が同じであること
2. すべての CPU が命令をほぼ同じクロック速度で処理すること 
3. ディスクへの書き込みは限定された時間内に行われるはずであること 

最初の問題は、並列クエリをサポートするハイエンドの製品を使うときに起こる。クエリが実行されるとき、処理はスレッドの間で均等に分けられるが、ハイパースレッディングや仮想化環境の下ではスレッドは一貫した速度で動作しない。

なので、いくつかのスレッドは他のスレッドよりも早く処理を終え、もっとも遅いスレッドが処理を終えるまでブロックしてしまう。さらに困ったことに、すべてのクエリが終わらないかぎり、先に処理を終えたスレッドに別のクエリを割り当てることができないようなのである。これで、少なくとも SQL Server を配備するときにはハイパースレッディングはお勧めできないということがわかっていただけたと思う。.

Conor 氏は続けてメモリと I/O についてこう述べる。

SQL Server （少なくともその主要なサーバ製品）は、マシン上でメモリを大量に使用するアプリケーションは自分だけだと想定している。なんといってもサーバなのだから（SQLExpress は異なる想定をしているが、メモリに対して無頓着というわけではない）。SQL Server はメモリの制約がある環境で稼動されるだろうが、そんな制約は望まれない場合が多い。バッファプール、プランキャッシュ、クエリ実行に用いられるメモリ（hash join への付与など）といった様々なものから制約を取り除こう。油断していると、これらの制約が重なって、深刻な問題になり得る。

仮想化環境における I/O に関して、私の経験はとても少ない。私が SQL Server 製品のことを他の人に尋ねるのは、そのためでもある。その人たちは通常ストレージアレイを使う。それは理にかなったことだ。I/O 帯域幅は大きくなるし、SQL Server による I/O はマシン上の他のオペレーション（OS や、SQL Server の上のレイヤで開発中のアプリケーションなど）からは隔離される。私はもっと時間を費やしてこれについて調べるつもりだが、コアとなるアイデアは妥当だと思う。多くの仮想マシンに I/O 帯域幅を共有させたら、SQL Server のような I/O 帯域幅の使用量が大きいアプリケーションのせいですぐに限界に達してしまう。データベースのトラフィックを別のストレージパスに隔離するのも、それと同じ理屈だ。特にスケーラブルなシステムを構築しているならなおさらである。こうすれば、仮想マシン環境において、全員で同じハードディスクを共有するというデフォルト設定のせいで被る不利益を避けることができる。

SQL Server を仮想イメージ上で稼動させることができないというわけではない。パフォーマンスが重要な場合に仮想化環境を使うのはおそらく割りに合わないと言っているのである。

原文はこちらです：http://www.infoq.com/news/2008/02/VPC-SQL-Server

• 次へ >