仮想マシンの集約密度を決めるサイジング：実践！ Xenで実現するサーバ統合（3）（1/3 ページ）

仮想化ソフトウェアの「Xen」を用いてサーバ統合を実践していく手順を具体的に紹介します。第3回は現在のリソース利用状況を見極め、サーバ統合時の重要な設計項目である「集約密度」を決める手順を紹介します（編集部）

» 2007年12月25日 00時00分公開

[中嶋一樹, 高橋浩和，住商情報システム株式会社/VA Linux Systems Japan株式会社]

　前回までで仮想マシンの性能がどの程度なのか、またその性能に影響を与える構成要素は何なのかについて見てきました。それらを踏まえたうえで、今回は、本連載の目的である「仮想化でサーバ統合」という環境を構築する際に重要な設計項目となる「集約密度」について考えたいと思います。

【関連記事】

http://www.atmarkit.co.jp/flinux/special/xen01/xen01.html
仮想化技術の大本命「Xen」を使ってみよう～インストール & Debian環境構築編～

http://www.atmarkit.co.jp/flinux/special/xen02/xen01.html
仮想化技術の大本命「Xen」を使ってみよう～Xen対応カスタムカーネル構築編～

ゲストOS、搭載数の限界は？

　「実際のところ、1台のサーバ機上に何台までゲストOSを稼働させることができるのだろう？」という疑問を持たれている方は少なくないと思います。

　まず、誤解を恐れずにざっくりとした結論をいいましょう。数十台程度であれば、物理メモリが許す限り多くのゲストOSを稼働させることはできます。以下のグラフを参照してください。

図1　仮想マシン数によるWebアプリケーション性能の推移

　これはLAMP構成でWebアプリケーションを構築し、そのスループットを計測したものです。横軸が同時稼働ゲストOS数となっています。ゲストOS数が1台のときは600リクエスト/秒のリクエストを処理していますが、ゲストOS数が最大の24台となったときは処理能力が約20リクエスト/秒にまで低下しています。

　限られたハードウェアリソースを複数のゲストOSで共有するために、当然、同時稼働ゲストOS数が増えると仮想マシン1台当たりの処理能力は低下します。とはいえ、大量のゲストOSを同時稼働させたときでも、何ら不具合や特別な性能劣化を起こすことなく、与えられたハードウェアリソースの中で着実に処理をこなしていることが分かります。

　従って、性能要件などの細かい話を抜きにして、まず「普通に動くのかどうか」ということだけに関していえば、先のテストの台数程度であれば、物理メモリが足りる限りはゲストOSを同時稼働させることは可能です。

コラム●物理メモリの制限

　上記では「物理メモリの上限」をたびたび強調しました。理由は、物理メモリは物理容量を上回る割り当て設定を行うことができないハードウェアリソースだからです。例えば、4Gbytesの物理メモリを搭載しているサーバ機上で、1Gbytesの仮想メモリを割り当てたゲストOSを4台以上稼働させることはできません（ホストOSが使用するメモリも考慮して）。

　確かに「1台のサーバ機上の物理メモリ」という意味では、複数のゲストOSが共有していることになります。しかし、各ゲストOSに割り当てたメモリ容量については、完全にそのゲストOSが占有することになります。つまり、各ゲストOSに割り当てた仮想メモリ容量の合計は、サーバ機の物理メモリ容量を超えることはできないのです。

　一方、ほかのハードウェアリソースについてはどうでしょうか。CPUについては、特別な占有設定をしない限り、物理CPUと仮想CPUは1対1の関係にはならないため、ゲストOS数の制限はありません。ディスク容量については、Sparseファイルを用いることでサーバ機に搭載されているHDD容量以上の容量を割り当てることができますし、外部のストレージを利用することも可能です。この意味で、物理メモリはゲストOS数の絶対的な上限を表す唯一の指標といえます。

サイジングの具体的な手順

　先に、ざっくりと集約密度の感覚をつかんでみました。次に、より正確なサイジングの手順を見ていきたいと思います。

　今回はサーバ統合の要件を大きく以下の2パターンに分け、それぞれの状況に応じたサイジングを紹介します。

高密度なVPS（Virtual Private Server）ホスティングサービスのインフラを構築する
現在稼働中の複数のシステムを単一のサーバ機に集約する

■VPSホスティングサービスを構築する

　まず、最も単純な1のパターンについて見ていきます。

　VPSのようなホスティングサービスでは、ユーザーは自由に自身のVPSを設定し、利用することができます。このため、サービス提供側ではどのようなアプリケーションが稼働し、どの程度のハードウェアリソースを必要とするのかを判断するのは不可能です。従って、このような環境では、個々のゲストOSに割り当てるハードウェアリソースをあらかじめ固定・制限しておき、割り当てたリソースをSLAとしてサービスを提供している場合がほとんどです。

　この場合、サイジングを行うことは難しくありません。単純にサーバ機のキャパシティを個々のVPSに割り当てるハードウェアリソースで割ることによって、ゲストOS数を判断することができます。

　例えば、以下のようなスペックのサーバ機を用いるとしましょう。


リソース	スペック
CPU	Xeon 2.6GHz Quadコア×2ソケット
メモリ	16Gbytes
NIC	ギガビットイーサネット×2

　このサーバ機であれば、スペック上、以下のようなリソースを保証した仮想マシンを最大で32台提供することができます。


リソース	スペック
CPU	650MHz
メモリ	500Mbytes
ネットワーク	60Mbps

注1：ディスクについては、一般に共有ストレージを使用することが想定されるため、記載していません

注2：このほかに、ディスクアクセスの帯域幅も重要なハードウェアリソースとなります。しかしディスク帯域幅は一般に、ユーザーにとってはあまり直感的な指標ではなく、かつどのような条件での性能なのかを定義しにくいためか、実際のホスティングサービスでこれについて明記しているケースはあまり見掛けません

　参考までに、海外のものではありますが、Xenを使ったVPSホスティングサービスを1つ紹介しておきましょう。「ProVPS」というこのサービスでも、Plansのページ（http://www.provps.com/plans.php)で、前述のようなSLAが記載されていることが分かります。

■既存のサービスを集約する

　次に2のケースを見ていきます。このケースは、すでに運用中のシステムがあり、それを仮想化環境に移行するようなパターンを想定しています。

　例えば、イントラネットの社内用ブログサイトやナレッジベースサイト、プリンタサーバなど、必要に応じてその都度サーバ機を追加してサービスインしたシステム群の中には、システムごとに1台のサーバが使用されており、稼働率は高くないが、消費電力や占有スペースは一人前……というものがあると思います。このような低稼働率のサーバは、集約するのにうってつけのシステムといえます。

　仮に移行対象となるサーバが10台あったとします。これらのサーバが1台のサーバ機に集約できるのか、あるいは2台必要なのかは、サイジングを行って判断する必要があります。

　サイジングを行う際にキーとなるのは、以下の4つのハードウェアリソース状況です。