|
![](
/cda/static/image/spacer.gif) |
![](
/cda/static/image/spacer.gif) |
![](
/cda/static/image/spacer.gif) |
![](
/cda/static/image/spacer.gif) |
![](
/cda/static/image/spacer.gif) |
![](
/cda/static/image/2008lab.gif) |
![](
/cda/static/image/spacer.gif) |
![](
/cda/static/image/spacer.gif) |
![](
/cda/static/image/spacer.gif) |
|
Hyper-Vはどの程度使えるか【最終回】
|
![](
/cda/static/image/spacer.gif) |
ベンチマークでみるHyper-Vの実力
|
|
最終回の今回は、Hyper-Vでいくつかのベンチマークを試してみた。
■ 仮想HDDのパフォーマンスは?
Hyper-Vには、仮想HDDのフォーマットがいくつかあるため、どのフォーマットがどのくらいのパフォーマンスを持っているのかをテストしてみた。ベンチマークソフトには、クライアントPCなどのベンチマークで利用されているCrystalDiskMark 2.1を使用した。仮想マシン(1CPU、1GBメモリ)にWindows Server 2008 32ビット版をインストールした仮想環境でチェックした。この環境で、容量可変、容量固定、差分、さらに物理ディスクの4つのパターンでテストをしてみた。
|
物理ディスク |
容量固定 |
容量可変 |
差分 |
Sequential Read |
60.39 |
56.72 |
57.11 |
46.94 |
Sequential Write |
54.82 |
50.79 |
19.76 |
18.46 |
Random Read 512KB |
40.49 |
37.35 |
35.01 |
27.00 |
Random Write 512KB |
35.69 |
33.98 |
16.94 |
15.00 |
Random Read 4KB |
0.784 |
0.789 |
0.714 |
0.407 |
Random Write 4KB |
1.763 |
1.788 |
0.383 |
0.378 |
詳細に関しては、表を参照してほしいが、やはりもっともパフォーマンスが高いのは物理ディスクだった。物理ディスクを使用する場合は、仮想マシンからのディスクへのリクエストをペアレントOSのHDDドライバが直接処理をしている形になっているため、リアルなHDDアクセスのパフォーマンスに近いといえる。
ペアレントOSのHDDにファイルとして構築される仮想HDDでは、容量固定が物理ディスクに匹敵するパフォーマンスを出している。仮想HDDということで、ファイル化されていることを考えれば、高いパフォーマンスを示しているといえるだろう。これなら、物理ディスクがなくても、ディスクアクセスが頻繁に行われるデータベースなどのアプリケーションでもある程度のパフォーマンスで動作するのではないか。また、容量固定の仮想HDDでも、容量拡張は可能なので、使い勝手の点でもそれほど悪くはないといえる。
3番目が容量可変の仮想HDD、最後が差分となった。この2つの仮想HDDは、シーケンシャル、ランダムともにWriteの結果が悪かった。このあたりは、どのようなアーキテクチャになっているかはわからないが、ディスクのパフォーマンスにデメリットがあることはきちんと知っておく必要があるだろう。このような仮想HDDをディスクアクセスが頻繁にあるアプリケーションで使用すると、どれだけ高性能なCPUを用意しても、仮想HDDが足を引っ張ることになるからだ。ただし、容量可変や差分の使い勝手の良さというのは、ディスクパフォーマンスをそれほど必要としないアプリケーションにとっては、メリットになるだろう。
このベンチマークからは、ディスクアクセスの頻繁に起こるアプリケーションは、容量固定を利用した方がいい。容量可変や差分は、仮想ディスクの使い勝手の良さを生かして利用すればいい。物理ディスクに関しては、このベンチマークからは、容量固定仮想ディスクとずば抜けてパフォーマンスが異なるわけではないので、システムの使い勝手からは容量固定仮想ディスクで十分かもしれない。
なお、8月に開催されたTech・Ed 2008のセッションでは、仮想HDDの配置に関してのTipsがいくつか紹介された。
まず、ペアレントOSのシステムドライブと仮想マシンを配置するドライブは、異なるドライブにすべきとのこと。仮想環境では、ディスクアクセスの善し悪しが、パフォーマンスを左右するからだ。このため、仮想マシンが配置されるドライブは、RAID 1+0などを使用した高速なディスクを使うべきだろう。また、RAID 5は、読み込みは速いものの、書き込みが遅いため、仮想ディスクを保存するドライブとしては勧めないとしている。ただし、RAID 5で作成したドライブを別パーティションにして、2台のRAID 5ドライブをRAID 0として組み合わせる技もある。
もし、コスト的に許されるのなら、フラッシュメモリを利用したSSDを利用すれば、劇的にパフォーマンスがアップするだろう。
また、ファイルのクラスタサイズを大きく設定した方が、パフォーマンスがアップするとしている。NTFSは標準では4KBだが、仮想環境で利用する場合は16KBや64KBといったクラスタサイズでもいい。
そのほか、ゲストOSのブートHDDにはIDEしか使えないが、データドライブにはSCSIを使用した方がいいという。パフォーマンスとしては、IDEもSCSIも変わらないが、管理性がSCSIの方がいいからだ。システムはIDE、データはSCSIというようにするのがいいだろう。
■ 仮想マシン全体のパフォーマンスは?
次にテストしたのは、仮想マシンを複数動かしたときのベンチマークの変化だ。このテストでは、CrystalMark 2004R3を利用した。環境としては、仮想マシン(1CPU、1GBメモリ)にWindows Server 2008 32ビット版をインストールした。また、CPUには、CPUコアが4つのIntel Core 2 Quad Q6600(2.4GHz)を利用した。
同じ仮想マシンを最大6つ起動し、同時にベンチマークソフトを動かしてみた。これにより、同時に複数の仮想マシンが動いたときのCPUパフォーマンスの変化、メモリやHDDアクセスの変化を見てみた。
ちなみに、CrystalMark 2004R3には、画面のベンチマークもあるが、仮想環境ではVMBusの標準ディスプレイドライバを利用しているため、ほとんど意味のないベンチマークになるため表には表記していない。また、複数の仮想化マシンにおかれたベンチマークソフトは、手動で動かしているため、若干のタイムラグもある。このため、厳密なベンチマークというよりも、一つの指針としてほしい。
仮想マシン数=1台
|
WS08-001 |
WS08-002 |
WS08-003 |
WS08-004 |
WS08-005 |
WS08-006 |
ALU |
10,740 |
- |
- |
- |
- |
- |
FPU |
11,192 |
- |
- |
- |
- |
- |
MEM |
18,486 |
- |
- |
- |
- |
- |
HDD |
10,817 |
- |
- |
- |
- |
- |
仮想マシン数=2台
|
WS08-001 |
WS08-002 |
WS08-003 |
WS08-004 |
WS08-005 |
WS08-006 |
ALU |
10,731 |
10,751 |
- |
- |
- |
- |
FPU |
11,235 |
11,209 |
- |
- |
- |
- |
MEM |
18,013 |
18,000 |
- |
- |
- |
- |
HDD |
1,535 |
2,065 |
- |
- |
- |
- |
仮想マシン数=3台
|
WS08-001 |
WS08-002 |
WS08-003 |
WS08-004 |
WS08-005 |
WS08-006 |
ALU |
10,735 |
10,716 |
10,725 |
- |
- |
- |
FPU |
11,186 |
11,242 |
11,160 |
- |
- |
- |
MEM |
12,560 |
11,696 |
11,825 |
- |
- |
- |
HDD |
1,040 |
1,420 |
1,475 |
- |
- |
- |
仮想マシン数=4台
|
WS08-001 |
WS08-002 |
WS08-003 |
WS08-004 |
WS08-005 |
WS08-006 |
ALU |
10,724 |
10,692 |
10,659 |
10,686 |
- |
- |
FPU |
11,230 |
11,317 |
11,293 |
11,102 |
- |
- |
MEM |
8,254 |
7,587 |
8,675 |
8,249 |
- |
- |
HDD |
749 |
780 |
1,134 |
1,074 |
- |
- |
仮想マシン数=5台
|
WS08-001 |
WS08-002 |
WS08-003 |
WS08-004 |
WS08-005 |
WS08-006 |
ALU |
9,762 |
10,215 |
10,291 |
9,905 |
9,682 |
- |
FPU |
10,524 |
10,856 |
9,754 |
9,524 |
10,100 |
- |
MEM |
8,061 |
7,908 |
5,160 |
6,107 |
7,779 |
- |
HDD |
596 |
646 |
728 |
738 |
909 |
- |
仮想マシン数=6台
|
WS08-001 |
WS08-002 |
WS08-003 |
WS08-004 |
WS08-005 |
WS08-006 |
ALU |
8,793 |
8,762 |
8,923 |
9,376 |
8,697 |
9,102 |
FPU |
8,554 |
9,099 |
9,727 |
8,122 |
8,810 |
7,878 |
MEM |
5,987 |
5,866 |
6,063 |
4,620 |
5,999 |
6,502 |
HDD |
463 |
472 |
547 |
604 |
592 |
634 |
ALU(論理演算)に関しては、4つの仮想マシンまでは、各CPUコアにうまく処理が割り振られているようで、それほど性能にばらつきはなかった。ただ、仮想マシンを5台にしてからは、徐々にALUの性能も落ち始めているようだ。このあたりは、CPUコア数以上に、仮想マシンを作り同時に動かしているためだろう。
FPU(浮動小数点演算)に関しても、ALUと同じような傾向にある。
MEMやHDDアクセスに関しては、仮想マシンが増えるほどパフォーマンスが低下している。ただ気になるのが、HDDアクセスが、仮想マシン1台から、2台以上になったときに、劇的に低下している点。これがどういった原因でおきているのか類推するしかないが、やはりNTFSディスク上にファイルとして仮想HDDを利用している上では、ディスクパフォーマンスは低下するのだろう。
今回のベンチマークでは、容量可変の仮想HDDを使用したため、容量固定の仮想HDDなどを使用した場合は、もう少しパフォーマンスがよくなるのかもしれない。
なお、このベンチマークを見ると、CPUに関しては、仮想マシンが使用するCPU数と物理マシンのCPUコア数が一致していれば、それほどのパフォーマンス低下を招かないようだ。物理マシンのCPUコア数以上に仮想マシンを起動した場合は、徐々にパフォーマンスが低下するようだ。
メモリアクセスに関しては、起動した仮想マシン数に応じて、パフォーマンスが低下しているようだ。HDDアクセスに関しては、複数の仮想マシンを起動した時点で、大きくパフォーマンスが低下している。
このことからも、Hyper-Vを実運用する場合は、物理マシンのCPU数とメモリのパフォーマンス、HDDのパフォーマンスに注意を払うべきだろう。そうしないと、古いサーバーを仮想環境に移行しても、パフォーマンスが低下するということになる。やはり、このあたりは、設計や運用が大きくかかわる部分なのだろう。
■ Hyper-Vは使えるか?
いろいろテストをしてみるとHyper-Vは、ある程度実用になるようだ。クアッドコアCPUなどで4つぐらいの仮想マシンを動かす上では、ベンチマーク結果のように、それほどパフォーマンスの低下はなかった。このくらいなら、十分実用になる。
パフォーマンスに関しては、きちんとVMwareと比較をしているわけではないが、VMwareは1台の仮想サーバーで数多くの仮想マシンを現実動かしている例が多数ある。しかし、Hyper-Vでは、それほどの多数の仮想マシンが高いパフォーマンスで動作するかどうかは未知数だ。Hyper-Vを大規模に導入するためには、きちんと事前テストを繰り返す必要があるだろう。ただし、ハイブリッド型のハイパーバイザのおかげで、ペアレントOSのドライバが利用できる点は、VMwareと比べて大きなメリットだ。
なお、実環境で導入するには、ペアレントOSにはServer Coreを利用するべきだろう。フルインストールのWindowsでは、いろいろなアプリケーションを入れたり、ドライバを入れたりすることになる。リモートPCから管理したり、System Center Virtual Machine Manager 2008(以下、SCVMM 2008)から管理するなら、Server Coreで十分だ。Server Coreなら、ペアレントOSにリソースはあまり割かれないから、より仮想環境にリソースを回すことができる。
ただ残念なのは、Hyper-Vには、P2VやV2Vといったツールがついていないことだろう。できれば、数台の仮想サーバーを管理するためのP2VやV2Vツールが提供されると便利だ。
また、仮想サーバーがある程度の台数があったり、複数の仮想環境(Hyper-V、VMware ESX Server、XenServerなど)がある環境では、SCVMM 2008は必須となるだろう。価格は今後正式アナウンスされるだろうが、Hyper-Vを導入予定の企業はSCVMM 2008の導入も検討した方がいい。Hyper-Vをもっとも生かすためには、SCVMM 2008は必要だ。
■ 仮想環境の問題はライセンス
Hyper-Vは、仮想環境としては強力な環境が用意されている。しかし、大きな問題としては、仮想環境で動かすOSのライセンスだ。
Windows Server 2008では、仮想化を念頭に「仮想インスタンス実行権」というライセンスが用意されている。たとえば、Windows Server 2008 Enterprise Editionでは、4つの仮想インスタンス実行権がバンドルされているため、ペアレントOSに1つ、ゲストOSに4つで、合計5つのWindows Server 2008を動かすことができる。
また、Windows Server 2008 Enterprise Editionの仮想インスタンス実行権は、Windows Server 2003などを動かすことを念頭にしているため、旧バージョンのOSを動かしても問題ない。旧バージョンに関しては、Windows Server 2008 Enterprise Editionを持っていれば、ダウングレード権を使うことで、4つのWindows Server 2003を動かすことができる。
これらのことを見ていると、仮想化をめいっぱい利用するユーザーにとっては、仮想インスタンス実行権が無制限のWindows Server 2008 Datacenter Editionのライセンスを購入しておくのが現実的だろう。
なおライセンスの問題は、OSだけでなく、SQL ServerやExchange Serverなどのサーバーアプリケーションにも及ぶ。マイクロソフトでは、8月19日にサーバー・アプリケーションの仮想化に関するライセンス体系の変更を発表している。この発表では、SQL Server、Exchange Server、Dynamics CRM、SharePoint Serverなど41種類にも及ぶサーバー・アプリケーションのライセンスを仮想環境で利用しやすいように変更している。
以前のライセンスでは、物理サーバーを変更する場合は、90日以上間をおく必要があった。このため、ライセンス的に、一度Quick Migrationを行うと、次に物理サーバーを移行するには、90日以上間をおく必要があった。これは、仮想化の使い勝手からいっても、非現実的なものだった。
新しいライセンスでは、物理サーバーではなく、サーバーファーム内と変更している。これにより、サーバーファーム内部では、必要に応じて何度アプリケーションを移動してもライセンス違反とはならなくなった。
このようにマイクロソフトのライセンス体系は変更されたが、アンチウイルスソフトなど、他社のアプリケーションに関しては、仮想環境におけるライセンスはまちまちだ。ユーザーとしては、最悪仮想環境ごとにライセンスが必要になるということも考えられる。これでは、仮想環境を構築して、ハードウェアコストを下げたとしても、OSやサーバーアプリケーションのコストがかさんでしまうことになる。
このあたりに関しては、業界全体できちんとしたコンセンサスを作り、ユーザーにも、メーカーにもベネフィットのあるライセンス形態を構築する必要があるだろう。そうでなければ、仮想化というメリットの大きなテクノロジーも、ソフトウェアライセンスという問題により普及しなくなるかもしれない。
■ 関連記事
・ Hyper-Vはどの程度使えるか【第一回】(2008/09/19)
・ Hyper-Vはどの程度使えるか【第二回】(2008/09/26)
・ Hyper-Vはどの程度使えるか【第三回】(2008/10/03)
( 山本 雅史 )
2008/10/09 00:00
|
|
|
![](/epw/cda/static/image/spacer.gif)
|
![](/epw/cda/static/image/spacer.gif) |