サーバ仮想化製品の評価ポイント：サーバ仮想化技術の可能性と限界（3）（1/2 ページ）

一口にサーバ仮想化技術といっても、各製品の採用する技術は多様だ。今回は最終回として、サーバ仮想化を実現する製品を導入する際に留意すべき点について述べる。

　前回はサーバ仮想化技術の可能性の面から活用例を述べた。今回は最終回として、サーバ仮想化製品を導入する際に留意すべき点について述べる。

　仮想的なサーバを作ることに関しては、当然ではあるがどのサーバ仮想化製品でも可能である。しかし、1回作った仮想サーバはいつまでもそのままではない。さまざまな状況下でリソース変更が行われることになる。したがって、サーバ仮想化製品では、単に仮想的なサーバが構築できるだけではなく、いかに滞りなく物理サーバリソースを自由に割り当て、解放できるかにも留意する必要がある。主なポイントは以下のようになる。

1. 物理サーバリソースの配分単位
2. 物理サーバリソースの変更時の影響
3. ホストOSの種類
4. ゲストOSの種類
5. 仮想サーバ間の独立性
6. 制御方法
7. パフォーマンス
8. 信頼性対策
9. 課金単位

　さらにワークロード管理についても考慮すべきである。動的なワークロード管理については、運用をしていく中で刻々と変化する仮想サーバの負荷（ワークロード）をリアルタイムに把握し、適切なリソースの配分を行うための情報や操作ができるかということを考慮する必要がある。この面から留意すべき主なポイントは以下のようになる。

1. 監視可能なリソース
2. 設定可能なトリガ
3. 再配分可能リソース
4. 設定可能アクション

　これらのポイントに注目しながら、要件に最適な製品を選出することが重要である。以下では、それぞれのポイントについて説明する。

開サーバ仮想化技術を評価する際のポイント

1. 物理サーバリソースの配分単位

　単一物理サーバ内に存在する仮想サーバは、それぞれの仮想サーバごとに必要とする物理サーバリソースを分割して利用する。仮想サーバに配分する物理サーバリソースの量の設定も製品によって異なる。

　まず、物理サーバリソースの配分の単位が、物理デバイス単位になっているタイプのものがある。例えば物理サーバがCPUを4つ持っている場合、最高でも4つの仮想サーバしか構成できず、かつそれぞれの仮想サーバが物理CPUを１つしか持つことができないという製品も存在する。

　この場合、CPUの割り当てが物理CPU単位となるため、4CPUの物理サーバ上に3つの仮想サーバを構築した場合、そのうちの1つの仮想サーバが2物理CPUを使うといったことになる。

　つまり、サーバ負荷に応じて割り当てや解放のできるCPUリソースが物理CPU単位となるため、きめ細かなリソース配分は難しく、仮想サーバの数も制限されてしまうことも考えられる。

図1　リソースの配分単位

　全物理リソースを、全体に占める割合で各仮想サーバに割り当てることができるタイプの製品もある。このタイプは物理サーバが持っているすべてのCPUの何パーセントを仮想サーバに割り当てるかという設定ができるため、物理CPUの数以上に仮想サーバを構築できるというメリットがある。加えて割り当てや解放もパーセント単位で行えるため、よりきめ細かなワークロードに対応するリソース配分が可能となる。

2. 物理サーバリソース変更時の影響

　各仮想サーバが稼働している時に、ピーク時間帯にある仮想サーバへのアクセスが集中し、サーバの処理負荷が増大し、現在のリソースでは対処し切れない場合、動的に物理リソースの割り当てを増やして正常に処理を続行しようとする。仮想サーバが実行状態にある状態で、仮想サーバに割り与えられている物理リソースの配分を動的に変更するときの留意点として、リソース配分変更の反映タイミングがある。

　理想的には物理リソース配分の設定直後に変更されることが望ましい。そして、CPUの配分方法はタイムシェアリング方式をとっているものが多いため、この反映は設定直後に実施されるものが多い。ただし、製品によっては仮想サーバに最低限のリソースとして、半固定的にCPUリソースやメモリ、ネットワークインターフェイスなどを割り当てるため、配分変更後はリブートが必要なものもあるので注意が必要である。

3. ホストOSの種類

　仮想サーバを構築する際に、仮想サーバそのものを制御するためのプログラムがOSを必要とするものとそうでないものがある。このときのOSをホストOSと呼び、物理サーバ上にインストールしておく必要がある。

　ホストOSを利用するタイプは、通常このホストOSにWindowsやUNIXを使用する。したがって、物理サーバのハードウェア構成や種類が異なっても、ホストOSが稼働すれば、仮想サーバ製品がその上で動作することが保証される。ただし、実行時のホストOSのオーバヘッドを考慮する必要があり、またホストOSのライセンス料が発生することも考慮する必要がある。

　ホストOSが不要なタイプでは、仮想サーバ制御用にカスタマイズされた非常に軽量な独自のOSを利用することで、オーバヘッドを削減し高速に動作させることが可能である。またホストOS自体のセキュリティ対策としてセキュリティパッチを当てたりするなどの管理負荷を大きく削減できる。

　ただし、留意すべき点は、ハードウェアの相性がある点である。前述のホストOSの場合は広く利用されている一般的なOSを使用するため、対応するハードウェアは数多いが、専用のOSを利用するホストOS不要タイプでは、ベンダ側で稼働確認をして動作保証ができるハードウェアの数が限られている場合が多い。

4. ゲストOSの種類

　対応するゲストOSの種類は、製品によって大きく異なる。パーティション技術を採用している製品では、ホストOSとゲストOSが同じOSである場合が多い。仮想サーバがx86系マシンをエミュレートする仮想マシン（Virtual Machine）である場合には、ゲストOSはx86で稼働するOS（たとえば、Windows、Linux、FreeBSD、NetWare、DOSなど）に対応しているものがほとんどである。同一の物理サーバ内に、WindowsやLinuxなどの複数のOSを仮想サーバとして稼働させたい場合には、後者のような仮想マシン系の製品の利用が適している。

5. 仮想サーバ間の独立性

　同一の物理サーバ内に存在する仮想サーバ同士は、独立したサーバとして動作することを前提としている。データセンターなどで、複数の異なったシステムが、同一の物理サーバ内に仮想サーバとして存在することも当然考えられる。その場合、あるシステムの仮想サーバが、故意にあるいは偶然にでも他の仮想サーバのファイルを容易に破壊できることは許されない。したがって、仮想サーバ同士のリソースは、物理サーバ同士と同様、ネットワークを介したアクセス以外には不可能であることが望ましい。

6. 制御方法

　仮想サーバの設定状況の監視やリソース稼働状況、および設定変更やリブートなど運用時を考慮した、外部から操作可能なAPI（Application Program Interface）が用意されているかどうかもポイントとして挙げられる。動的ワークロード管理を行うときに専用の管理ツールを使用して行うだけでなく、他のシステムで使用している既存の運用管理ツールと連携し、統一した管理を行うことで管理の手間を軽減することも重要である。

7. パフォーマンス

　仮想化をすることにより、物理リソースから仮想的なリソースへ変換するために大きく2つのオーバヘッドがかかることになる。

　1つは仮想サーバを制御するソフトウェアのオーバヘッドである。仮想サーバは物理サーバ上で論理的に動作するサーバである。つまりソフトウェア的にハードウェアをエミュレートしているため、仮想サーバ動作の制御・管理のためのオーバヘッドが起こるというわけである。すでに述べたが、このソフトウェアがホストOSを必要とするものとそうでないものがあり、ホストOSを必要としないもののほうがオーバヘッドは少ない。サーバ仮想化製品の実機評価を行った結果からいえば、ホストOSを必要としない製品ではサーバ仮想化におけるオーバヘッドが10％以下に抑えられているものも存在する。

　次に、仮想化されているリソースを動的に再配分したときのオーバヘッドがある。CPU、ネットワーク、ディスクのように時分割でアクセスを行っているデバイスではオーバヘッドは発生しないが、メモリのように時分割アクセスを行っていないものはオーバヘッドが大きい場合がある。

　また、COMポート、LPTポート、CDやテープドライブなど仮想化されていない複数のデバイスに、仮想サーバが同時にアクセスすると、大幅な性能劣化を引き起こしたり、デバイスがフリーズしたりする可能性もあるため、同時アクセスを抑制する運用を考える必要がある。

8. 信頼性対策

　単一筐（きょう）体型サーバ仮想化では、仮想サーバを制御するソフトやホストOSがフリーズした場合、その上で動作している仮想サーバもフリーズ、もしくは制御不能になってしまう。万が一の場合を考慮し、仮想サーバに対応するクラスタリングソフトの有無などを確認することも重要である。最近では稼働中の仮想サーバを他の物理マシン上へ高速で移動するなどの技術も出てきており、新たな信頼性向上の手段としても検討する価値があるだろう。

9. 課金単位

　サーバ仮想化製品のライセンス体系には、稼働する物理マシンのCPU数に依存するもの、同時に構築可能な仮想サーバ数に依存するもの、上記を混合したものなど、製品によって差異がある。最初に構築する仮想サーバ数や、使用していくうちに仮想サーバ数を増減する場合などの運用の仕方によっても費用が大きく変わることがあるので注意を要する。