VMware ESXi で各種ディスクのベンチマークをとってみた
ESXi でネットワーク Disk 上に VM を構築するにはいくつかの手段があるのですが,それらの速度を測定してみました。
おことわり
おもに下記の命題を検証するために測定を行いました。
性能比較としては統制のとれていない劣悪な環境で行いました。
- ネットワーク環境は 100Mbps(!)
- しかも isolated な環境ではない……つまり他のパソコンやルータ等がつながったハブにもつながっている(!)
- ストレージサーバは単一のディスクを LVM で分割して利用している
- なので外周内周による速度の違いはありうる
- といっても 1TB HDD に 32GB の LV をいくつか切っただけなのでそこまでの差はないと思う
- なので外周内周による速度の違いはありうる
- VMware ESXi はCPU 周波数やメモリ割り当てをダイナミックに変更しうる
- 一応同時に 1 VM しか立ち上げませんでした
ですので結果の数値はあくまで参考程度でとらえてください。面倒なので細かい施行条件も省いています。追試不能ですいません。
ハードウェア諸元
- ストレージサーバ
- 仮想マシンサーバ
- ディストリビューションサーバ*2
- Pentium III 1.0 GHz
- Intel 82557 Ethernet PRO/100+
- CentOS 5.2 (2.6.18-92.1.22) i386
ぶっちゃけていうと,それなりの処理能力(およびネットワーク能力)のあるサーバを用意して,それらを 100Mbps スイッチングハブにつないだということになります。
ストレージについて
- DRBD: DRBD 8.2.6 (
drbd82-8.2.6-1.el5
) - NFS: システム付属
- iSCSI target: Linux SCSI target framework (
scsi-target-utils-0.0-0.20070620snap.el5
)
DRBD は今回の本筋とは関係ないのですが,今後の環境を考えてインストールしました。ただし片肺運転(つまり Primary のみ)で運用してます。
仮想マシンは以下の4タイプを用意しました。
- iscsi-raw
- iSCSI で公開されたディスクをそのまま仮想論理ドライブとしてアサイン*3
- iscsi-image
- iSCSI で公開されたディスクを ESXi のデータストアとして(vmfs で)アサインし,その上にディスクイメージを構築
- nfs
- NFS で公開されたディスクを ESXi のデータストアとして(vmfs で)アサインし,その上にディスクイメージを構築
- local
- ローカルにぶら下がっているディスクを ESXi のデータストアとして(vmfs で)アサインし,その上にディスクイメージを構築
となります。
すべて
- 仮想CPU: 1
- 仮想メモリ: 384MB
- 仮想ディスク: 16GB
- 仮想 HDC: LSI Logic
- ゲストOS: CentOS 5.2 (2.6.18-92) x86_64
- VMware Tools 非インストール
で VM を構築しました。また,disk image を利用する VM では Independent / Persistent な disk image にしています。
予想としては,
の順でパフォーマンスがよいのではないか。
CentOS 5.2 (x86_64) のインストールにかかった時間
CentOS 5.2 x86_64 を SELinux disabled な環境でネットワークインストールしました。VNC でリモートから GUI インストールを行いました。
linux noselinux selinux=0 vnc vncpassword=********
インストールするパッケージ群はミニマム(base, core)なものにしました。GUI インストールということでインタラクティブな要素もありますが,諸々の設定を終えたあとから計測を行いました。つまりディスクのフォーマットとパッケージのインストールフェーズのみの時間です。
下記がストップウォッチ*4によるラフな計測です。
iscsi-raw | iscsi-image | nfs | local |
---|---|---|---|
06:07 | 18:26 | 07:09 | 03:55 |
Bonnie++ 1.03a による Disk I/O ベンチマーク
ほんとは IOZone とかでもとるべきなんでしょうけど,面倒なので有名な Bonnie++ だけで。
Bonnie++ download | SourceForge.net より Bonnie++ 1.03a を取得してビルドを行い,計測を行いました(MinTime
は 0.5
から 0.01
に変えてあります)。あとで気づいたのですが,Bonnie++ now at 1.03e (last version before 2.0)! には Bonnie++ 1.03e があったんですね。
Bonnie++ の出力の読み方は
- bonnie++を使ったベンチマーク結果の見方 - yoshifumi1975's diary
- 某エンジニアの日記 - bonnie++ の見かた
- 原典たる Bonnie++ Documentation
あたりを参照。CPU 使用率も表示してくれるんだけど,これが高い場合はアテにならないのでは?という意見もあります(→年越しそばと初詣は絶対に欠かせない: ディスクIO性能(2) - BonnieとIOZoneの比較)。そのへんも考慮にいれつつ結果を見ていきましょう。
まずはベースとなる iscsi-raw の結果から。整形してるので省略していますが,以降すべて file size = 1G, files = 16 となっております。
===== iscsi raw ===== ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 12753 17 10610 1 5660 0 11251 14 11121 1 300 0 ------Sequential Create------- --------Random Create--------- -Create-- ---Read--- -Delete-- -Create-- ---Read--- -Delete-- /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 92 0 299530 56 82 0 99 0 839301 102 83 0
ベース指標なのであまりコメントすることもないのですが,Sequential Create と Random Create の Read で CPU の使用率が高い(また結果数値も高い)のがちと気になります。私見ですが Sequential / Random Create は Disk I/O というより file system の効率をみるものであり,read に関してはノードエントリがバッファキャッシュにおさまっちゃってるんじゃないかなぁ。
次にシステムインストールではふるわなかった iscsi-image の結果です。
===== iscsi image ===== ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 18249 90 81404 47 4262 0 11111 14 11065 1 304.5 1 ------Sequential Create------- --------Random Create--------- -Create-- ---Read--- -Delete-- -Create-- ---Read--- -Delete-- /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 87 0 298542 56 80 0 95 0 829654 101 80 0
だいたい iscsi-raw と同じですが,Sequential Output の Per Chr と Block がいずれも iscsi-raw を(なぜか)凌駕しちゃってます。んが,両者とも CPU 使用率が(なぜか)あがってしまっているので当てにならないかもしれません。実際 file system ベースの項目(Sequential / Random Create) では,微妙に iscsi-raw より劣っています。
次に nfs の結果です。
===== nfs image ===== ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 9125 12 8572 1 5122 0 10950 14 10802 1 212.9 1 ------Sequential Create------- --------Random Create--------- -Create-- ---Read--- -Delete-- -Create-- ---Read--- -Delete-- /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 32 0 322038 60 32 0 33 0 835444 101 32 0
iscsi-raw と比較すると(あやしい Sequential / Random Create の Read 以外)全般的に劣った結果となっています。Sequential Output では1割減くらい,Input はさほどかわらず,Sequential / Random Create 系ではなんと3分の1にまで落ち込んでいます。ちょっぴりがっかりです。
最後にローカルディスクの結果を載せておきます。
===== local ===== ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP 33870 89 96000 58 22581 4 73449 94 75418 6 200.4 0 ------Sequential Create------- --------Random Create--------- -Create-- ---Read--- -Delete-- -Create-- ---Read--- -Delete-- /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 1848 1 285814 55 1678 0 1583 0 823944 100 1818 0
圧倒的に次元が違う結果となりました :)。Sequential I/O では数倍,Sequential / Random Create では20倍程度違います。GbE にするとそこそこ近づけるのかもしれません。
hdparm
による Disk I/O ベンチマーク
hdparm -tT
を使って下位レベルでのディスク読み取り性能を測定しました。オプションの説明を引用します。
http://www.linux.or.jp/JM/html/hdparm/man8/hdparm.8.html
-T
- ベンチマーク及び比較目的で、キャッシュ読み込みを測定する。有意な結果を得るためには、少なくとも数メガバイトの空きメモリがあり、他にアクティブなプロセスがない状態で、この操作を 2, 3 回繰り返すべきである。これは、ディスクアクセスなしに、Linux のバッファキャッシュから直接読み出す速度を表示する。これは、テスト環境下でのプロセッサ・キャッシュ・メモリの基本的な処理能力を測定するものである。
-t
フラグが同時に指定された場合には、-T
の出力を元にした補正係数が-t
操作の結果に加味される。-t
- ベンチマーク及び比較目的で、デバイス読み込みを測定する。有意な結果を得るためには、少なくとも数メガバイトの空きメモリがあり、他にアクティブなプロセスがない状態で、この操作を 2, 3 回繰り返すべきである。これはデータのキャッシュがない状態から、バッファキャッシュを通してディスクを読み出す速度を表示する。これは、ファイルシステムのオーバーヘッドなしに、そのドライブが Linux でどれだけ連続データ読み込み速度を維持できるかを測定するものである。測定の正確さを上げたいのであれば、
-t
の実行の間にBLKFLSBUF
ioctl を使ってバッファキャッシュをクリアする。-T
フラグが同時に指定された場合には、-T
の出力を元にした補正係数が-t
操作の結果に加味される。
結果は下記のとおりです。
- | iscsi-raw | iscsi-image | nfs | local |
---|---|---|---|---|
cached reads (MB/sec) | 6724.96 | 6775.60 | 6907.93 | 6895.84 |
buffered disk reads (MB/sec) | 10.61 | 29.15 | 10.81 | 101.98 |
先に注意点から。
- 連続3回測定し中間値*5をとった
- 3回の計測結果からすると結構大まかにブレるのでオーダーのみ参考にし,細かい差は無視するべし
- cached reads はさきの man からもわかるようにバッファキャッシュとのデータやりとり速度を計測しているので,全 VM で同じような値になっているのはあたりまえ
考察です。
CentOS 5.2 (x86_64) の kernel-2.6.18-92 の RPM ビルドにかかった時間
ここまでのベンチマークでは「会議室の結果」ぽいので,わりと実地に近いことをやってみることにします。理想をいうと,そこそこの規模の DB サーバを立ち上げてベンチマーク,とかやれるとおもしろいのですが,セットアップが面倒なのでカーネルパッケージのリビルドを行うことにしました。
素人考えですが
- CPU を結構使うので実地テストに近い
- かなり多くの File I/O が発生する
- ファイル数もサイズもそこそこ多いので,すべてが cache に乗るということは考えにくい
などの点から選択肢として悪くないのではないでしょうか。
実行は,
# time rpmbuild -ba --target=x86_64 --with baseonly SPECS/kernel-2.6.spec
のようにして行いました。
なお,package signing が絡むとちと問題があったので spec ファイルの
%define signmodules 1
の部分をすべて 0 に書き換えて実行しました。
実行結果は下記のとおりです。それなりの時間がかかったので秒未満は四捨五入してあります。
- | iscsi-raw | iscsi-image | nfs | local |
---|---|---|---|---|
real | 77:51 | 89:19 | 77:57 | 55:38 |
user | 29:32 | 32:58 | 29:34 | 30:02 |
sys | 15:43 | 18:08 | 15:37 | 16:28 |
(other) | 32:37 | 38:13 | 32:46 | 9:08 |
- nfs は iscsi-raw とほぼ同じ結果になっている
- iscsi-image は iscsi-raw や nfs に比べ遅い
- user や sys もかなり増加していることからすると何かしらの原因で CPU をフルパワーで使いきれない可能性がある
- このデータの前に取得したとき real 111:48, user 44:18, sys 22:07, (other) 45:24 という非常に遅い結果を得ている
- そのときの Performance チャートをみると 2.4GHz まで到達せず 1.8〜2.0GHz 程度の頭打ちになっていた
- local は(Disk I/O を反映していると考えられる)other の結果からするとネットワーク経由より3倍強速い
- GbE でどの程度迫れるか興味深い
まとめ
- Bonnie++ は所詮「いわゆるベンチマーク」なので,結果の数値をそのまま過信してはいけない*6
- iSCSI を data store としてその上に disk image を構築する VM は,
- ディスクベンチマークでは iSCSI raw disk や NFS data store の VM に比べて(なぜか)勝るものの,
- 実運用レベルでは逆にパフォーマンスが落ちる
- シーケンシャルアクセスにのみ強い?
- Linux SCSI target framework と ESXi vmfs の相性が悪い?
- NFS data store は iSCSI raw disk と比べ,
- 100M ネットワークではネットワーク disk の性能はいまいち
- GbE スマートスイッチ欲しい……
(より広帯域の)GbE 環境で計測したり*7,iSCSI target として iSCSI Enterprise Target を利用したり,はたまた iSCSI target 専用機を使った場合にまったく異なる結果となるかもしれません。
*1:ジャンボフレーム未対応だそうです。今回は 100Mbps でつないでいるのであまり関係ないと思いますが。
*2:後述する CentOS のネットワークインストールで利用した配布元サーバです。あまり大事ではないので既存の環境のものを流用しています。
*3:実際には vmx ファイル等の置き場が必要になりますので iscsi-image の環境を流用しています。ベンチマークの大勢には関係ないと思います。
*4:といってもほんとのストップウォッチを使ったわけではなく,VNC クライアント側で date コマンドを使いました。
*5:平均をとるのが面倒だったので中間値をとりました。他意はないです。
*6:Bonnie++ をおとしめる意図はないです。「いわゆるベンチマーク」というものがあくまで単体性能を計測しているにすぎないこと,Bonnie++ はさまざまなアーキテクチャで動くように書いてあり逆に単体性能を純粋に測定することができないこと,などからこのように書きました。私見ですが,まったく同じアーキテクチャで違う HDD の性能差を測定する場合や,あるいは反対にまったく違うアーキテクチャで Disk I/O の性能バランス・傾向を比較する場合に使うべきものだと思います。
*7:そもそも SAN はファイバーチャネルなど高速なネットワークで運用していたものであり,GbE ならいざしらず 100Mbps 環境では想定外のボトルネックが発生していても不思議ではありません。