サーバー仮想化でI/Oの問題が顕在化

サーバー仮想化を始める: 物理I/O編

サーバー仮想化によって、物理サーバー機の導入モデルとシステム・アーキテクチャが、全面的に変わりました。仮想化では、複数の仮想サーバーが、物理リソースを共有するからです。

仮想化の目的は、システム・リソースをプール化しておき、必要に応じてリソースを割り当てることにより、物理サーバー機のリソース利用効率を向上させることです。これを実現するために必要なシステム要件は、以下の通りです。

サーバー仮想化のシステム要件

柔軟なアプリケーション実装

ほとんどのアプリケーションを、任意のサーバー上で実行できる必要があります。

1台のサーバーに複数のアプリケーション

リソースの使用効率を高めるため、リソースが十分に活用されていないサーバーにアプリケーションを追加できる必要があります。

アプリケーションの可動性

高可用性（HA）とロード・バランシング（負荷分散）を実現するため、アプリケーションはすべてのサーバー間で移動できる必要があります。

上記のシステム要件を満たすためには、サーバーのI/Oが非常に重要です。I/Oに関して考慮すべきポイントを、下記に示します。

I/O接続要件の増大

個々の物理サーバーは、すべてのネットワークに対する接続性を備えている必要があります。なぜなら、ある仮想サーバーをSANとDMZ（非武装地帯）に接続する、といったように、ユーザーの要件に応じて、任意の仮想サーバーを任意のネットワークに接続する可能性があるからです。この場合、ユーザーの多くは、個々のサービスが使うネットワークを分離独立させるために、サービスごとに個別の物理I/Oをサーバー機に追加して対処しているのが現状です。これが、各サーバー機に多数の物理I/Oが存在する原因となっています。

ストレージ要件の多様化

仮想サーバー・イメージを格納するために、共有ストレージが必要となります。この結果、ユーザー要件によっては、イーサネットに加えてFC（Fibre Channel）接続が必要になることもあります。こうして、サーバー側のI/O拡張スロットの数が足りなくなるケースが生じています。

独立した管理用ネットワーク

仮想化環境を管理するために、専用のI/O接続が必要になります。例えば、各種の仮想化ソフトウエアでは、仮想サーバーのマイグレーション（移動）やFT（無停止）用に、独立した専用のネットワーク接続を使います。この接続にI/Oを消費してしまいます。

帯域幅要件の増大

仮想化により、サーバーI/Oが消費する帯域が増えます。従来、サーバーのCPU使用率は平均で10%程度でしたが、仮想化環境では50%を超えることもあります。同様に、I/O使用率も、仮想サーバー台数に比例して増加します。こうして、I/Oパスの帯域幅がITシステムの新たなボトルネックとなります。

もちろん、従来のI/Oを使ったままでも、サーバー仮想化に求められるシステム要件を満たすことは可能です。1台のサーバー機に数枚のNIC（Network Interface Card）と、場合によっては数枚のHBA（Host Bus Adapter）を搭載しておき、仮想サーバー間で共有すればよいのです。しかし、この方法は、最適な解とは言えません。

従来のI/Oが最適とは言えない1つ目の理由は、仮想サーバーをバックアップしている最中などのように高い負荷がかかっている時に、アプリケーションの輻そうが発生してしまうことです。ネットワークや共有ストレージの構成によっては、このようなパフォーマンスの問題を解決することは難しいでしょう。また、仮に管理者がボトルネックの原因を特定できたとしても、問題を改善するためには、多くのNICを新たに購入したり、仮想サーバーごとのアプリケーション処理負荷を再度調整する必要があります。

従来のI/Oが最適とは言えない2つ目の理由は、仮想サーバー環境が物理サーバー環境よりも多くのI/O接続を必要とすることです。データ用ネットワークに対する接続が多数になるだけでなく、運用管理や仮想サーバーの移行のための専用接続が必要になります。SANを使っていれば、各サーバーにFC（Fibre Channel）接続用のHBAも必要です。コストや消費電力が増えるほか、ラック・スペースが無駄になるなど、さまざまな課題が発生します。