仮想マシンの集約密度を決めるサイジング：実践！ Xenで実現するサーバ統合（3）（3/3 ページ）
移行先の情報収集
次に、移行先のサーバ機の限界性能を見ていきます。新しいサーバ機は、既存のものと同じスペックであると想定します。
CPUとメモリについては、スペックをそのまま性能と読み替えます。ネットワーク帯域幅についても、最近のネットワークカードとドライバはほぼスペックどおりの性能を出すことができます。つまり、ギガビットのネットワークカードであれば、少なくとも900Mbps以上の性能が期待できます。
最も測定が難しいのは、ディスク帯域幅です。ディスクへのアクセス速度は、シーケンシャルアクセスなのか、それともランダムアクセスなのかといった条件によって大きく異なってくるからです。例えば、シーケンシャルリードのテストで200MByte/sの性能が出ても、データベースアプリケーションのようにランダムリードの環境では、限界性能はそれよりも大きく下回ることが予想されます。
ここでは、ディスク性能を計測するツールとして「tiobench」を使用します。このツールはシーケンシャルアクセスに加えてランダムアクセスの性能も取得することができます。また使用するブロックサイズも調整することができます。tiobenchは以下のサイトからフリーでダウンロードできます。
インストールは簡単です。以下のようにダウンロードしたアーカイブを展開し、makeするだけです。
# tar xvfz tiobench-0.3.3.tar.gz # cd tiobench-0.3.3/ # make
インストールが完了したら、以下のコマンドで実行します。
# ./tiotest -R -d /dev/sdb -L
「/dev/sdb」のところには、仮想マシンを格納する予定のブロックデバイスを指定します。ここでは、ファイルシステム上のディレクトリではなく、あくまでもRawデバイスを指定することに注意してください。ディレクトリを指定してしまうと、ページキャッシュが挟まった性能になってしまいます。
先ほど、sarの-bオプションを用いて取得したディスクの消費帯域幅は、あくまでもディスクデバイスへの読み出し、書き込みの値です。そのため、ここでも純粋にディスクデバイスへの読み出し、書き込み性能を計測する必要があります。結果は以下のように出力されます。
,----------------------------------------------------------------. | Item | Time | Rate | Usr CPU | Sys CPU | +---------------------+--------+-------------+---------+---------+ | Write 40 MBs | 1.9 s | 21.066 MB/s | 0.0 % | 11.8 % | | Random Write 16 MBs| 0.9 s | 16.641 MB/s | 3.4 % | 1.7 % | | Read 40 MBs| 1.8 s | 22.651 MB/s | 0.0 % | 1.4 % | | Random Read 16 MBs| 23.2 s | 0.673 MB/s | 0.0 % | 0.0 % | `----------------------------------------------------------------'
この出力で重要なのは、Rateの列です。この値がディスク帯域幅の限界性能を示しています。
限界性能としてはリード、ライトともにランダムアクセス時の値を採用することにします。これはゲストOS上のアプリケーションの特性が一般的にランダムアクセスとなることが多いためです。
これでサイジングに必要なデータをそろえることができました。収集したデータを以下にまとめてみます。
| リソース | 移行対象サーバ | サーバの限界性能 |
|---|---|---|
| CPU使用率 | 0.97％ | 4GHz（2GHz×2） |
| メモリ使用量 | 256Mbytes | 2Gbytes |
| ネットワーク受信帯域幅 | 11788.12 byte/s | 1Gbps |
| ネットワーク送信帯域幅 | 211079.32 byte/s | 1Gbps |
| ディスク読み出し帯域幅 | 929.57 block/s | 0.673Mbyte/s |
| ディスク書き込み帯域幅 | 9.34 block/s | 16.641Mbyte/s |
| 表1 移行対象サーバのリソース消費と移行先サーバの限界性能 | ||
メモリ使用量については、調査結果では116419kbytesでしたが、ページキャッシュなどの余裕を見て256Mbytesとしています。これらを、単位を合わせてグラフ化してみます。
図2 移行対象サーバのリソース消費と移行先サーバの限界性能ご覧のように、かなりバランスが悪いことが分かります。ほかのリソースについては十二分な余裕があるにもかかわらず、ディスク読み出し帯域幅に関しては70％程度のリソースを消費してしまいます。これでは、ディスクI/Oに引っ張られて、サーバ機のほかのハードウェアリソースが無駄になってしまいます。
ということは、ディスクとして外部ストレージを使う、あるいはディスクの本数を増やしてI/O並列度を上げるなどして性能を稼いであげれば、このサーバ機上でもかなりの仮想マシンが稼働させられると推測できます。
そこで、実際にこのサーバをiSCSIの共有ストレージに接続し、ディスク帯域の限界性能を再度測定してみました。結果は以下のとおりです。
,----------------------------------------------------------------. | Item | Time | Rate | Usr CPU | Sys CPU | +---------------------+--------+-------------+---------+---------+ | Write 40 MBs | 0.6 s | 70.444 MB/s| 1.4 %| 16.2 %| | Random Write 16 MBs | 0.3 s | 58.374 MB/s| 12.0 %| 41.8 %| | Read 40 MBs | 0.7 s | 55.353 MB/s| 3.3 %| 19.4 %| | Random Read 16 MBs | 0.9 s | 17.292 MB/s| 0.0 %| 3.5 %| `----------------------------------------------------------------'
加えて、メモリについても既存サーバの2Gbytesでは若干貧弱なので、4Gbytesに増強するものとします。この新しい限界性能に基づいて、先ほどのグラフを見てみましょう。
図3 iSCSIの共有ストレージを接続し、メモリを増強して測定した結果ずいぶんバランスが良くなりました。
さらに、仮にほかの移行対象のサーバもハードウェアリソースの利用状況が同じだとして、このサーバ機上に何台の仮想マシンが搭載できるかを算出してみます。算出方法は単純で、いずれかのハードウェアリソースが頭打ちになるまで、移行対象サーバが必要とするそれぞれのハードウェアリソースを積み上げていくだけです。
結果は、以下のグラフを参照してください。赤のラインは、移行対象サーバが必要とするハードウェアリソースの14台分に相当します。
図4 ハードウェアリソースを積み上げて、仮想マシンが何台まで搭載できるか計算こうして見ると、ホストOSが使うリソースを差し引いても、14台までは集約させることができそうだと分かりました。ということは、今回の要件である10台の既存サーバ集約は、1台のサーバ機でクリアできる計算になります。
実際には、移行対象のサーバのハードウェアリソース使用状況がすべて同じであることはあまり考えられません。すべての移行対象サーバについて、個別に調査を行う必要があるでしょう。
■ピークタイムへの配慮を忘れずに
最後に、もう1つ注意しなければならない項目があります。ピークタイムです。例えば、企業のポータルサイトやメールサーバでは、朝の出社時にアクセスが集中し、一斉にピークを迎えることが容易に想像できます。
このように、あらかじめピークタイムが想定できるシステムについては、その時間帯が重ならないように分散する仕組みを用意しておかないと、アクセスをさばけなくなる可能性があります。従って調査を行う際には、ピーク時の使用率、そしてその時間帯というデータにも注意しておく必要があります。
今回は、ゲストOSの集約密度についていくつかの方法論を紹介してきました。次回はサイジングが完了したという想定で、その設計に基づいて実際にゲストOSを展開する手順について紹介したいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。