Tweet

第3回　仮想マシンの集約密度を決めるサイジング

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　これらそれぞれについて、移行先のサーバ機にはおのずと限界性能があります。サーバ集約におけるサイジングとは、つまるところ、全仮想サーバの各ハードウェアリソース消費量の合計が、サーバ機の限界性能を超えないようにバランスよくアレンジすることです。

　そのためには、以下の2つの情報を手に入れる必要があります。

　まず、前者の既存サーバのハードウェアリソース利用状況を確認していきます。この場合、すでに動いているサーバがあるので、その上でリソース利用状況を採取するツールを動作させれば、実運用に必要なハードウェアリソースのデータを簡単に取得できます。ちなみに既存のサーバ機は、以下のスペックであると想定します。

第2回へ

1/3

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

Page 1 ゲストOS搭載数の限界は？ 　コラム　物理メモリの制限 サイジングの具体的な手順 　VPSホスティングサービスを構築する 　既存のサービスを集約する 　 Page 2 既存サーバの情報収集 　CPU使用率 　メモリ使用量 　ネットワーク帯域幅 　ディスク帯域幅   Page 3 移行先の情報収集 　ピークタイムへの配慮を忘れずに

Linux Square全記事インデックス

	連載：実践！ Xenで実現するサーバ統合 有力な仮想化技術として注目を集めるようになった「Xen」。このXenを活用してサーバ統合を実践していく手順を具体的に紹介します
	特集：サーバの仮想化技術とビジネス展開の可能性 jailからUML／VMwareまで 1台のマシンで複数のサーバを動かす「仮想化技術」。VMwareやUMLの登場により、WebサイトだけでなくOS自体を仮想化できるようになった
	特集：仮想化技術のアプローチと実装 VMwareから要注目技術Xenまで 1台のサーバで複数の仮想マシンを実行する仮想化技術は、空間コストを引き下げる可能性を持つ。最新の仮想化技術を概観してみよう
	特集：仮想OS「User Mode Linux」活用法 技術解説からカーネルカスタマイズまで Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説
	特集：仮想化技術の大本命「Xen」を使ってみよう インストール & Debian環境構築編 高いパフォーマンスで本命の1つとなった仮想マシンモニタ「Xen」。日本語による情報が少ないXenを、実際に動かしてみよう
	特集：仮想化技術の大本命「Xen」を使ってみよう Xen対応カスタムカーネル構築編 Xen環境およびその上で動作する仮想マシン用カーネルを自分で構築しよう。これにより、自由にカスタマイズしたカーネルを利用できる
	特集：IPv6、UML、セキュリティ機能の統合 全貌を現したLinuxカーネル2.6［第4章］ 今回は、これまでに紹介し切れなかった機能を一気に紹介する。これを読めば、カーネル2.6の正式リリースが楽しみになるだろう
	Linux Squareプロダクトレビュー　VMware Workstation 4 PC/AT互換機エミュレータとして不動の地位を築いたVMware。その新バージョンがリリースされた。新機能を早速試してみよう
	古くて新しい「サーバ仮想化技術」の行方 サーバ仮想化を実現するための技術がソフトウェア、ハードウェアの両面で出そろってきた。ハイパーバイザーのさらなる高速化に向けた動きを紹介する
	Linux Squareフォーラム全記事インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード