VMware ESXi で各種ディスクのベンチマークをとってみた

ESXi でネットワーク Disk 上に VM を構築するにはいくつかの手段があるのですが，それらの速度を測定してみました。

おことわり

おもに下記の命題を検証するために測定を行いました。

• NFS data store でも iSCSI data store / raw disk と比べて遜色ない（といいな）

性能比較としては統制のとれていない劣悪な環境で行いました。

• ネットワーク環境は 100Mbps（！）
• しかも isolated な環境ではない……つまり他のパソコンやルータ等がつながったハブにもつながっている（！）
• ストレージサーバは単一のディスクを LVM で分割して利用している
  • なので外周内周による速度の違いはありうる
    • といっても 1TB HDD に 32GB の LV をいくつか切っただけなのでそこまでの差はないと思う
• VMware ESXi はCPU 周波数やメモリ割り当てをダイナミックに変更しうる
  • 一応同時に 1 VM しか立ち上げませんでした

ですので結果の数値はあくまで参考程度でとらえてください。面倒なので細かい施行条件も省いています。追試不能ですいません。

ハードウェア諸元

• ストレージサーバ
  • Base: NEC Express 5800/110Gd (Chipset: Intel 3000)
  • CPU: Celeron 440 @ 2.00 GHz
  • Memory: 1GB
  • Network: Onboard Intel 82573L*1 Gigabit Controller (e1000e)
  • HDD: SATA2 SAMSUNG 1TB (HD103UI)
  • OS: CentOS 5.2 (2.6.18-92.1.22) x86_64
• 仮想マシンサーバ
  • Base: NEC Express 5800/110Gd (Chipset: Intel 3000)
  • CPU: Core2 Quad Q6600 @ 2.40 GHz (G-0 step)
  • Memory: 4GB
  • Network: Onboard Intel 82573L Gigabit Controller (e1000e)
  • HDD: SATA2 SEAGATE 300GB (型番失念)
  • VMM: VMware ESXi Version 3.5 Update 3 (123629)
    • USB メモリキーにて起動
• ディストリビューションサーバ*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
  • sda1: 1GB (ext3) /boot
  • sda2: 1GB (swap)
  • sda3: 14GB (ext3) /
• 仮想 HDC: LSI Logic
• ゲストOS: CentOS 5.2 (2.6.18-92) x86_64
  • VMware Tools 非インストール

で VM を構築しました。また，disk image を利用する VM では Independent / Persistent な disk image にしています。

予想としては，

• local >>> (越えられない壁) >>> iscsi-raw >> iscsi-image > nfs

の順でパフォーマンスがよいのではないか。

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

• ネットワークインストールを行っているので iscsi-* や nfs は，Disk I/O を阻害されうる
• nfs は iscsi-raw に比べて約 17% のパフォーマンスゲイン
  • トータルの時間が Disk I/O を反映しているわけではないが，おもったほど悪くない結果
• iscsi-image はなぜかとても時間がかかっている
  • 気になったので後日再計測を行ってみたが，やはり同じように遅い結果となった
  • まずもって最初のディスクフォーマットフェーズが遅い
  • パッケージインストールフェーズも（iscsi-raw や nfs に比べ）やや遅め
• local はさすがに速い
  • が，やはりトータルの時間でみると 1.5 倍程度。100M であることを考えると悪くない

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 を使って下位レベルでのディスク読み取り性能を測定しました。オプションの説明を引用します。

-T

ベンチマーク及び比較目的で、キャッシュ読み込みを測定する。有意な結果を得るためには、少なくとも数メガバイトの空きメモリがあり、他にアクティブなプロセスがない状態で、この操作を 2, 3 回繰り返すべきである。これは、ディスクアクセスなしに、Linux のバッファキャッシュから直接読み出す速度を表示する。これは、テスト環境下でのプロセッサ・キャッシュ・メモリの基本的な処理能力を測定するものである。-t フラグが同時に指定された場合には、-T の出力を元にした補正係数が -t 操作の結果に加味される。

-t

ベンチマーク及び比較目的で、デバイス読み込みを測定する。有意な結果を得るためには、少なくとも数メガバイトの空きメモリがあり、他にアクティブなプロセスがない状態で、この操作を 2, 3 回繰り返すべきである。これはデータのキャッシュがない状態から、バッファキャッシュを通してディスクを読み出す速度を表示する。これは、ファイルシステムのオーバーヘッドなしに、そのドライブが Linux でどれだけ連続データ読み込み速度を維持できるかを測定するものである。測定の正確さを上げたいのであれば、-t の実行の間に BLKFLSBUF ioctl を使ってバッファキャッシュをクリアする。-T フラグが同時に指定された場合には、-T の出力を元にした補正係数が -t 操作の結果に加味される。

http://www.linux.or.jp/JM/html/hdparm/man8/hdparm.8.html

結果は下記のとおりです。

-	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 で同じような値になっているのはあたりまえ

考察です。

• iscsi-raw と nfs は同じような性能
• iscsi-image は（なぜか，そして Bonnie++ の一部結果と呼応するように） iscsi-raw や nfs の3倍程度高速
• local はネットワーク経由に比べると10倍程度速い

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 と比べ，
  • ディスクベンチマークレベルでは劣る部分もあるものの，
  • 実運用レベルでは遜色ない，というかほぼ同じ
    • （微細な複数のファイルをアクセスする）SMB のようなプロトコルと比較した場合に iSCSI のメリットは生きるかもしれないが，VM disk image のように巨大な単一ファイルを操作する場合にはそれほどアドバンテージはないのかもしれない
• 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 環境では想定外のボトルネックが発生していても不思議ではありません。