帰ってきた VMware ESXi ディスクベンチマーク

以前 VMware ESXi で各種ディスクのベンチマークをとってみた - daily dayflower にてVMware ESXi で各種（ネットワーク）ディスクのベンチマークをとりましたが、残念ながら 100Mbps イーサネット環境での実験でした。

今回、GbE 環境が整ったので改めて各種ネットワークストレージのベンチマークをおこないました。

おことわり

おもに（前回と同じく）下記の命題を検証するために測定をおこないました。

• NFS データストアでも iSCSI データストア・LUN マッピングと比べて遜色ない（といいな）
• ネットワークストレージ環境でもローカルストレージ環境に比べて遜色ない（といいな）

なお前回と比べてネットワークスピード以外に結構環境が違うので*1単純に結果を比較することはできません。

NAS 買ったよ！

じつはとっくにギガビットスイッチと Celeron 440 (Core2 世代) のストレージサーバで VMware ESXi 環境を実運用中なのです。ですが、忙しかったり面倒くさかったりでベンチマークはとっていませんでした。

が、重い腰をあげるきっかけになったのが、下記の NAS。

QNAP ターボNAS TS-259Pro 黒 TS-259Pro

posted with amazlet at 10.03.09

QNAP
売り上げランキング: 43397

Amazon.co.jp で詳細を見る

Linux ベースでストレージサーバを立てるのなら、Core2 じゃなくて Atom でも結構いけるんじゃない？と思って会社に買ってもらいました。そこで、この Atom による NAS が ESXi のストレージサーバとしてどれくらい力を発揮できるのかという興味もあってベンチマークをようやくとることにしたのでした。

なお、だいたいどこで買っても（Amazon 含めて）実売 70,000円弱*2なので、ポイントのたまるお店で買うのがいいかもしんないです。私はさいわい Amazon で 62,910円という破格なときに買うことができました。

QNAP TS-259 Pro 自体の感想ですが、モニタをつなぐと*3わかるとおり、まるっきり Linux ベース*4の NAS です。ウェブ経由のコントロールパネルはそこそこよくできています（日本語にもおかしなところは見当たりません）。ただ同等の Atom の PC に比べるとブートに非常に時間がかかる気がします。また、紙のマニュアルはほとんどありません。DHCP 有効なネットワークだと IP が DHCP で振られるというのがわからずしばらく右往左往していました。また、ネットワークインタフェースのボンディングの設定を変えると IP の設定まわりがリセットされるところにも注意が必要でした。

環境

スペックなど

• ストレージサーバ
  • QNAP TurboNAS TS-259Pro
  • HDD: SATA2 WD 1TB (Caviar Green WD10EADS) x1 (単独ディスクボリューム)
• 仮想マシンサーバ
  • NEC Express 5800/110Ge + Core2 Quad Q9400s @ 2.66GHz + DDR2-6400 4GB
  • Network: Onboard GbE + Intel PRO/1000 PT GbE
  • Local HDD: SATA Seagate 300GB (Barracuda 7200.10 ST3320620AS)
  • VMM: VMware ESXi Version 4.0 Update 1
• ハブ
  • BUFFALO レイヤー2 インテリジェント GbE スイッチ BS-G2016MR

インテリジェントスイッチであり VLAN などもやろうと思えばできるのですが、面倒なのでそのままハブとして使っています。そのかわり、今回は物理 NIC を2つ ESXi サーバに載せたこともあり、仮想スイッチを2つにして、

• 1つをマネージメント＋ストレージアクセス (Management Network)
• 1つを VM の環境が使うネットワーク環境（VM Network）

のように分離しました（ネットワーク自体は同一ネットワークに所属）。

TS-259 Pro も NIC の口が2つあるのでマネージメントとストレージアクセスポートをわけたりボンディング／チーミングしたりできるんですが、やはり面倒だったのと、普通に使う分にはわける必要はないだろうということで1つ分しか使っていません。

VM の設定

以下の4とおりのケースについて計測をおこないました。

• local
  • ローカルにぶら下げた HDD にデータストア（vmfs）を構築
  • シン・プロビジョニングなし（シック・プロビジョニング）
• iscsi-raw
  • NAS 上の iSCSI LUN をそのまま仮想論理ドライブとしてアサイン
• iscsi-vmfs
  • NAS 上の iSCSI ボリュームをデータストア（vmfs）として仮想ディスクを作成
  • シン・プロビジョニングなし（シック・プロビジョニング）
• iscsi-vmfs2
  • NAS 上の iSCSI ボリュームをデータストア（vmfs）として仮想ディスクを作成
  • シン・プロビジョニング
  • 面倒になったので後述するカーネル RPM ビルドベンチはおこなっていない
• nfs
  • NAS 上の NFS ボリュームをデータストア（vmfs）として仮想ディスクを作成
  • シン・プロビジョニング（しか選べない？）

ほか共通の設定は下記のとおりです。

仮想 CPU 数	1
仮想メモリ	384MB
仮想ディスク	16GB
仮想 HDC	LSI Logic
ゲスト OS	CentOS 5.4 x86_64

ややこしいのは、各環境でシン・プロビジョニング（簡単にいうとストレージ容量を動的割り当てすること）のありなしが異なるところです。ですがもっとややこしいことに、QNAP TS-259 Pro の iSCSI ボリューム自身もシン・プロビジョニングできる*5んです。で、静的に確保するのが面倒だったので iSCSI ターゲット側のボリュームもシン・プロビジョニングしています。

CentOS 5 のインストールにかかった時間

ローカルネットワークに CentOS のディストリビューションサーバをしたてて、ネットワーク経由で kickstart インストールしました（パッケージは base, core のみ、SELinux なし）。ラフなストップウォッチ計測です。

local	iscsi-raw	iscsi-vmfs	iscsi-vmfs2	nfs
04:27	02:21	03:02	02:54	02:38

まさかの「local が一番遅い」という結果になりました。たしかに使用しているハードディスクは local のものは network に比べてやや劣るものなので「ネットワークのボトルネックよりハードディスクのボトルネックのほうが大きい」といえなくもないのですが、後述する別のベンチマーク群の結果をみればこれは何らかの別の理由（不明）によるものなのでしょう。

とはいえ、ネットワークストレージのものがまるでローカルストレージに比べて遜色ないということはいえるでしょう。GbE おそるべし。

あと、前回いまいち安定しなかった iscsi-vmfs ですが、きちんと安定して高速な環境になってます。QNAP の iSCSI target ってどの実装を使っているんだろう。

hdparm による Disk I/O ベンチマーク

hdparm コマンドを使うと下位レベルでのディスク読み取り性能を測定することができます。下記のコマンドラインで計測をおこないました。

# hdparm -tT /dev/sda

結果はこちらです（単位は MB/sec）。

	local	iscsi-raw	iscsi-vmfs	iscsi-vmfs2	nfs
cached reads	3831.34	3827.76	3996.37	3887.75	3901.35
buffered disk reads	348.70	79.90	357.63	343.23	105.84

結果のブレが大きいので*65回試行の中央値を採用しました。

前回説明したとおり、cached reads はバッファキャッシュとのデータやりとり速度なのですべての条件で同じような数値になっています。そしておそるべきは iscsi-vmfs の結果です。なんと local と同じ速度になっています。シン・プロビジョニングするかどうかはそれほど関係はなさそうです。一方同じ iSCSI なのに iscsi-raw は nfs にすら負ける結果となっています。

おおざっぱな傾向としては

• ネットワークストレージはローカルストレージに比べ3.5〜4倍ほど遅い
• （なぜか）iSCSI 上にデータストアを構築するとローカルストレージと同等の速度となる

ということがいえます。

Bonnie++ による Disk I/O ベンチマーク

epel にも Bonnie++ のパッケージがあるのですが、MinTime がデフォルトのままであり一部計測結果がでないので、Bonnie++ 1.03e を（MinTime を 0.01 に変えつつ((今考えたら MinTime が 0.5 でも計測可能なように file size と files を多くすればよかった（より正しい計測になった）のかな。))）自力でビルドしました。パラメータはデフォルトのまま file size = 1G, files = 16 です。

実行は

# bonnie++ -d / -u root -b

のようにしておこないました。

前回のようにだらだらと結果をつらねてもわかりにくいので、local の結果に対するスループットの百分率をまとめました（詳細な結果は末尾の資料に記載）。

ただし、

• CPU 利用率が環境によって安定しない Sequential I/O の Per Chr
• CPU bounds になる Sequential Create / Random Create の Read

については結果からはぶいてあります*7。

	nfs	iscsi-image	iscsi-image2	iscsi-raw
Seq Out Block	44.2%	48.8%	50.0%	85.4%
Seq Out Rewrite	78.7%	81.9%	75.7%	91.1%
Seq In Block	62.4%	92.5%	78.7%	89.8%
Rand Seek	193.7%	174.6%	134.1%	194.8%
Seq Cr Create	32.2%	33.9%	36.0%	33.4%
Seq Cr Del	40.9%	39.5%	40.4%	40.3%
Rand Create	39.2%	39.4%	38.9%	34.9%
Rand Del	55.1%	47.8%	47.0%	47.4%

おもしろい傾向がでています。

• 生 I/O に近いベンチマーク（Sequential Out / In / Random Seek）では
  • Sequential Access ではローカルとネットワークにそれほど差はない
    • iscsi-raw にいたってはほぼローカル並の速度
  • Sequential Access では NFS は iSCSI よりパフォーマンスが劣る
  • Random Access ではなぜかネットワークのほうがローカルに勝る
• 実地の I/O に近いベンチマーク（Create / Delete 系）では
  • 全般的にネットワークはローカルのスループットの 33% 〜 40% 程度
  • NFS と iSCSI の差はない

カーネル RPM パッケージビルドにかかった時間

より実地に近いベンチマークとして前回と同じく、カーネルパッケージのビルドをおこなってみました。

実行は

$ time rpmbuild -bb --target x86_64 \
                --with baseonly --without headers SPECS/kernel-2.6.spec

のようにしておこないました((前回と同じく signmodules を 0 に変えてあります。))。

結果は下記のとおりです。秒未満は四捨五入しています。

	local	iscsi-raw	iscsi-vmfs	nfs
real	55:09	59:33	57:21	57:23
user	29:06	29:09	29:08	29:09
sys	13:29	13:15	13:34	13:23
(other)	12:34	17:09	14:39	14:52

驚くべきことに、すべての環境でほぼ同じ数値となっています。I/O を反映していると考えられる other 項だけみるとたしかに local が速いのですが、それでも 100MbE 時代と比べてほとんど差はありません。またなぜか iscsi-raw が今回は遅くなっています。

総評

まとめると以下のようなことがいえます。

• GbE の環境では、raw level に近いスループットとしてはネットワークはローカルの3割〜4割程度の性能となる
  • ただし iSCSI では項目によってはローカルに迫るスループットをだせることもある
  • I/O ベンチマークレベルでは NFS は iSCSI にやや劣る
• だが、実地環境ではネットワークストレージはローカルストレージより遅いと感じることはない
• 上記の結果で満足できるのならストレージサーバは Atom 世代で十分性能を発揮できる

iSCSI target 専用機を使ったり Solaris + ZFS + iSCSI を使ったりすると、よりローカルストレージに肉薄させることも可能かもしれません。あと NIC をチーミングしたりとか*8。ですが、Linux でストレージサーバを構築するなら、メンテナンスの手間を考えると Atom (NAS) + NFS でいいや、と思える結果が出て個人的には満足しました。

ただ上記のベンチマークはすべて 1 VM で計測してるんですよね。ほんとは複数 VM を同時に立ち上げたときにローカルストレージとネットワークストレージでどれくらい差がでるかを計測するべきかもしれません。でももう力尽きました。

資料: くわしい環境

• ストレージサーバ
  • Base: QNAP TurboNAS TS-259Pro
  • CPU: Atom D510 1.66GHz (Dual Core / HT)
  • Memory: 1GB
  • Network: Onboard Intel GbE Controller x2 (e1000e; 82574L ぽい？)
  • HDD: SATA2 WD 1TB (Caviar Green WD10EADS) x1 (単独ディスクボリューム)
  • OS: カスタム Linux
• 仮想マシンサーバ
  • Base: NEC Express 5800/110Ge (Chipset: Intel 3200)
  • CPU: Core2 Quad Q9400s @ 2.66GHz / L2 6MB
  • Memory: DDR2-800 4GB
  • Network1: Onboard (Intel 82573L) GbE
  • Network2: Intel PRO/1000 PT (Intel 82571GB) GbE
  • Local HDD: SATA Seagate 300GB (Barracuda 7200.10 ST3320620AS)
  • VMM: VMware ESXi Version 4.0 Update 1
• ディストリビューションサーバ
  • Board: Intel D945GCLF2
  • CPU: Atom 330 @ 1.6GHz (Dual Core / HT)
  • Network: Reaktek RTL8111 GbE
  • OS: CentOS 5.4 (2.6.18-164) i386
• ハブ
  • BUFFALO レイヤー2 インテリジェント GbE スイッチ BS-G2016MR
  • ただのハブとして仕様（VLAN は切ってない）

資料: Bonnie++ の詳細な結果

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
54613	68	57324	7	30307	2	75849	87	73415	1	200.1	0
Sequential Create						Random Create
Create		Read		Delete		Create		Read		Delete
/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP
1802	0	613216	101	1736	0	1852	0	967525	100	1369	0

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
55277	68	48929	6	27617	2	45017	53	65900	1	389.7	0
Sequential Create						Random Create
Create		Read		Delete		Create		Read		Delete
/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP
602	0	616777	97	699	0	646	0	965242	100	649	0

iscsi-vmfs

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
27878	39	27975	3	24817	2	42703	51	67934	1	349.4	0
Sequential Create						Random Create
Create		Read		Delete		Create		Read		Delete
/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP
611	0	576128	91	685	0	730	0	970394	100	655	0

iscsi-vmfs2 (シン・プロビジョニングあり)

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
32945	40	28678	4	22950	3	45417	54	57746	1	268.2	0
Sequential Create						Random Create
Create		Read		Delete		Create		Read		Delete
/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP
649	0	616655	97	702	0	721	0	966437	100	644	0

nfs

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
28197	35	25311	3	23852	3	35363	41	45820	1	387.6	0
Sequential Create						Random Create
Create		Read		Delete		Create		Read		Delete
/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP	/sec	%CP
580	0	604334	99	710	0	726	0	859734	99	754	0

*1:ESXi ホスト環境（CPU, ESXi のバージョン）が違うこと、ストレージサーバが違うこと（Core2 ベースから Atom ベースへ）、CentOS が 5.2 から 5.4 になっていること、ストレージネットワークとVMネットワークのNICを分離していること、カーネル RPM ビルドのオプションが異なること、などが前回と違います。

*2:ReadyNAS などと比べて高い気もしますが、こちらは Atom なので無理をいって買ってもらいました。実質 PC と同じアーキテクチャであると考えると、ややお高めなのも仕方ないかな。普通の PC と違ってホットスワップができますし。

*3:もちろんこの NAS はモニタをつながずに運用するのが普通です。

*4:モニタをつないでみてると結構荒い仕上げだなと思うところもあります。もちろん表にはみえませんが。

*5:買ってから気づいたんですが、これは嬉しい機能です。

*6:実は前回と異なりブレはあまりありませんでした。ですが、実行回数を重ねるほどパフォーマンスが上がっていくという謎の現象がおきました。

*7:CPU bounds になると当たり前ですが、local だろうとネットワークストレージだろうと同じような数値になります。

*8:個人的にはもうネットワーク帯域自体がネックになっていないと思います。

ESXi 環境私的考察

VMware ESXi で各種ディスクのベンチマークをとってみた - daily dayflower の動機とか思索とかメモメモ。

• iSCSI や NFS によってディスクを外在化させれば，DRBD や LVM を活用して堅牢な VM image store とすることができる
  • local disk だとサポートされているハードウェア RAID でなくては保護ができないし，どれかがこけると全 VM が止まってしまう
• VM の手動マイグレーションを行うには，事実上 VM を構築するディスクを外在化させる必要がある
• iSCSI data store では local disk と大差ない，つまり（似非）オンラインマイグレーションできない*1
• iSCSI raw LUN mapping にすれば一応マイグレーション可能
  • ただしどこかに Configuration File や Working Location を配置する必要がある
  • という点を含め，実際にマイグレーションを行うのは面倒
• NFS data store は一番簡単にマイグレーションを行うことができる
  • バックアップ等もストレージサーバでカジュアルに行うことができる
• ただし NFS は iSCSI に比べより上位の実装なので，
  • VMM と ストレージサーバ双方にやや負荷がかかる
  • パフォーマンスも落ちる，ことが考えられる
• しかもいまどき NFS はいまいち流行らない気もする（というかなぜかネガティブな印象をもっている）
• NFS data store が iSCSI raw LUN mapping に比べて遜色ない性能だといいな ←命題
• 実運用上は NFS data store は iSCSI raw LUN mapping と同等 ←結果
• あとは安定性について要検証
  • vmfs はそこそこ安定していると考える；以下差分のみ各論
  • local raw LUN mapping
    • そんな潤沢なリソースありません; 無視
  • local data store
    • ESXi のディスクドライバ（安定していると考えられる）
  • iSCSI raw LUN mapping / iSCSI data store
    • iSCSI initiator on ESXi（安定性不明）
    • iSCSI target on storage server（tgt は未知数; vmfs と絡めると不安定？）
  • NFS
    • NFS client on ESXi（安定性不明）
    • NFS server on storage server（不明だが歴史もあるので tgt よりはマシ？）
    • NFS protocol と vmfs の相性は？（不明）
  • 壊れる場合 iSCSI raw LUN mapping と local は局所的だが，iSCSI / NFS data store は disk image 全体的に壊れうる？
    • 怖いのでバックアップをとるべき
      • LVM の snapshot？

*1:安価にバックアップ可能という意味では利用価値はありますけど。

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 環境では想定外のボトルネックが発生していても不思議ではありません。