宮原 徹
日本仮想化技術

 仮想化環境の設計や省電力化には、リソース量の現状把握と移行後の見積もりが欠かせない。前回に引き続き、仮想化環境におけるリソース量(ネットワークI/OとストレージI/O)の基本的な考え方や見積もり方法を説明することに加え、仮想化に伴う性能の劣化や移行先環境のサイジングについて紹介する。CPUやメモリーに起因する性能劣化はさほど気にならないが、ストレージ関連で書き込み性能が2~3割程度落ち込むことがある。詳しく見ていこう。

ネットワークI/Oの事前調査

 物理環境のネットワークI/Oに関するリソース量は、実際の使用量をもとに確認する。NICでの計測はもちろん、できればスイッチやルーターなどの機器でもトラフィック量を計測して、ネットワークの使用量を把握するのが望ましい。

 移行する仮想化環境でのネットワークI/O についても物理環境と同じリソース量が必要になる。やはりHAクラスタによる冗長構成を取るのであれば、前回述べた「60%ルール」に従って、障害対応時に必要なリソース量の確保を検討する。

 アプリケーションによって、ネットワークの使用量は大きく変動する。ネットワークI/Oがどの程度システムの性能を左右するかはケース・バイ・ケースになるので、必要に応じてキャパシティ・プランニングを行う。

ストレージI/Oの事前調査

 仮想化環境でボトルネックになりやすいのはストレージI/Oである。もともとストレージはCPUやメモリーなどに比べてデータ転送速度が桁違いに遅く、仮想化しないときも性能の足を引っ張りやすい。さらに仮想化統合では、複数のOS環境からのI/Oが集中するため、ボトルネックになりやすい。

 ストレージに比較的負荷がかかるシステムとしては、データベースやメールサーバー、ファイルサーバーなどが挙げられる。これらを仮想化統合の対象に含んでいる場合は、特に注意が必要である。

 物理環境におけるストレージI/Oのリソース量については、データ転送量のほか、読み書きの回数、読み書きを待つ度合いなどを調べる。まずは仮想化統合後のキャパシティ・プランニングを行う前に、物理環境でストレージにボトルネックが発生していないかを確認する。既にボトルネックが発生し、性能的に許容できないときは、可能な限りチューニングなどで事前に解消する。事前に解消できないときは、仮想化統合の際にストレージを増強して解消する。

 仮想化環境で使用するストレージの性能は、I/O接続方式やコントローラの性能、ハードディスクの台数などで大きく変わる。このため、物理環境のリソース量と単純に同じにならない上に、数式で表すのが難しい。性能が要求される場合は、ベンチマークテストの実施や、擬似的な環境を作って性能をテストする必要がある。

仮想化による性能劣化を見積もる

 次に、仮想化に伴う性能の劣化分を見積もる。仮想化環境では、ハードウエア・リソースを複数のOS環境が共有するため、どうしても性能が劣化しがちである。

 リソースを使い切っていないうちは性能劣化が目立たないが、限界性能を引き出す際は、性能の上限値が物理環境より下がるといった性能の劣化が現れる。

 CPUはその性質上、仮想化による性能劣化が目立たなく、あっても数%である。メモリーも若干の劣化はあるが、実際に使用しているときも気がつかない程度だ。

 劣化の度合いがやや大きいのがストレージである。定量化はできないが、感覚的には書き込み性能が2~3割程度落ち込む。

 ただし、ストレージの性能劣化はキャッシュを有効活用すると改善できることがある。データの読み取りであれば、読み取りキャッシュによって速度は大幅に向上する。書き込みキャッシュにはサーバーの電源が落ちるとデータが失われるリスクがあるものの、リスクを減らす対策がある。具体的には、電源の冗長化やUPSの利用、コントローラ上のキャッシュ・メモリーをバッテリ・バックアップするなどである。

 「ストレージ性能が落ちるから仮想化はダメ」と考えるのではなく、仮想化のメリットを享受しながら、弱い部分を補強するべきである。