サーバー仮想化において、最新のハードウエアを利用すれば「計算性能」の劣化を気にする必要がないことを前回述べた。今回は、「I/O性能」の観点からサーバー仮想化の性能問題を考えてみたい。特に、最近増えてきたデータベースサーバーを仮想化するケースについてポイントを説明していこう。
宮原 徹
日本仮想化技術
1台の物理サーバーがマルチコアCPU、大容量メモリー、さらに10Gbpsのネットワークが使えるのであれば、その上に構築する仮想化環境は、かなり潤沢なリソースを利用できるといえる。
だが、性能面で悩みどころがあるとすれば、それはストレージだろう。昨年ぐらいから、OracleやSQL Server、MySQL、PostgreSQLといったデータベースを仮想化環境で動かす事例が増えてきた。特にそのようなケースで、ストレージのI/Oがボトルネックになる傾向がある。
従来のデータベースサーバーは1台のマシンを専有し、計算性能とI/O性能を確保した状態で運用していたはず。だが、それらのデータベースサーバーを仮想化して、単純に集約しようとすると、仮想化した新しい環境での計算性能やI/O性能とかみ合わない。計算性能は十分なのに、ストレージのI/O性能が追いつかないことが多いのだ。
仮想化環境でのストレージ選び
こうした仮想化の課題に対して、ストレージを選定する際の基本的なポイントはいくつかある。単純化すると、まず当然ながら必要な容量を確保しなければならない。そして、容量を確保しながら、仮想化環境でどれぐらいのパフォーマンスを出せるかがポイントになる。そのうえで、データが飛んでしまったときの耐障害性をどう高めるか、という点を考慮する（図1）。たいてい、この3点は相容れない。
もう1つ、コストの観点も当然必要である。コストをどんどん掛けてもいいのであれば、すべてを満たせる。しかし、実際にはコストの制限があるので、上記3点のうち、1つか2つしか満たすことができない。どこに重点を置くかが、ストレージ選定のポイントになる。
さて、ストレージの容量に関しては、今後の増加率をある程度予測する必要がある。予測が難しい場合は、ストレージ容量を仮想化する「シンプロビジョニング」を検討するか、ノードの追加により容量を増やしていけるスケールアウト型のストレージ製品を選ぶとよいだろう。
速度については、使っているアプリケーションによって、意外に帯域を使わないことがある点に注目してもらいたい。例えばファイバーチャネルやiSCSI、FC over Ethernet（FCoE）といったストレージネットワークの利用状況を調べてみると、流れているデータ量が実は少なかったりする。ネットワークの速度に問題があるというよりは、書き込み処理のときに「物理的に正しく書き込んだ」という状態になるのを待つ、いわゆる「ディスクI/Oウエイト（wait）」が影響している。ストレージI/O性能ではこの部分が重要なので、特に書き込み処理でどれぐらい待たされるのかをいろいろ検討しなければならない。
耐障害性に関しては、ストレージノードを冗長化して、リアルタイムにレプリケーション（複製）を取るネットワークRAID型ストレージに注目している。仮想化環境におけるバックアップ/リカバリーをどうするかという点も含めて、ストレージ分野では改めて検討すべきことが多い。容量、速度は比較的分かりやすいが、耐障害性をどう高めるかは、コストとの兼ね合いもあり、なかなか悩ましい。
最近はSSD（Solid State Drive）を搭載した企業向けストレージがだいぶ増え、ネットワークRAID型ストレージもより本格に導入されるフェーズに入ってきた。サーバー仮想化に伴うストレージの不安を解消するには、これまでの常識にとらわれず、ストレージ製品を幅広く検討するとよい。
ストレージ専有型のほうがよいケースも
仮想化環境におけるストレージの接続方法として、「仮想化＝ストレージ共有型」というイメージがかなり定着している。これは間違いなく、ライブマイグレーションを利用したりフェイルオーバー・クラスターを組んだりする場合を想定した考え方である。仮想マシンがサーバーをまたがって移動してもデータにアクセス可能となる。
だが、この構成にとらわれすぎてはいけない。性能をある程度追求していこうとすると、やはり専有型にせざるを得ない場合がある。特にデータベースサーバーを仮想化する場合なら、高価な共有型ストレージよりも、専有型の、そのデータベースだけで使うストレージをピンポイントで導入するほうが効果的なことがある。専有型ストレージをサーバーに内蔵すれば、さらにアクセス速度を高められる。
