daily dayflower

2010-03-09

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

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

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

おことわり

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

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

NAS 買ったよ!

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

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

QNAP ターボNAS TS-259Pro 黒 TS-259Pro
QNAP
売り上げランキング: 43397

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

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


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

環境

スペックなど

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

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

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)として仮想ディスクを作成
    • シン・プロビジョニング(しか選べない?)

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

仮想 CPU1
仮想メモリ384MB
仮想ディスク16GB
仮想 HDCLSI Logic
ゲスト OSCentOS 5.4 x86_64

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

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

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

localiscsi-rawiscsi-vmfsiscsi-vmfs2nfs
04:2702:2103:0202:5402:38

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

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

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

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

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

# hdparm -tT /dev/sda

結果はこちらです(単位は MB/sec)。

 localiscsi-rawiscsi-vmfsiscsi-vmfs2nfs
cached reads3831.343827.763996.373887.753901.35
buffered disk reads348.7079.90357.63343.23105.84

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

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

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

ということがいえます。

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

epel にも Bonnie++ のパッケージがあるのですが、MinTimeデフォルトのままであり一部計測結果がでないので、Bonnie++ 1.03e を(MinTime0.01 に変えつつ*7)自力でビルドしました。パラメータデフォルトのまま file size = 1G, files = 16 です。

実行は

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

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

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

ただし、

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

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

 nfsiscsi-imageiscsi-image2iscsi-raw
Seq Out Block44.2%48.8%50.0%85.4%
Seq Out Rewrite78.7%81.9%75.7%91.1%
Seq In Block62.4%92.5%78.7%89.8%
Rand Seek193.7%174.6%134.1%194.8%
Seq Cr Create32.2%33.9%36.0%33.4%
Seq Cr Del40.9%39.5%40.4%40.3%
Rand Create39.2%39.4%38.9%34.9%
Rand Del55.1%47.8%47.0%47.4%

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

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

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

実行は

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

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

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

 localiscsi-rawiscsi-vmfsnfs
real55:0959:3357:2157:23
user29:0629:0929:0829:09
sys13:2913:1513:3413:23
(other)12:3417:0914:3914:52

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

総評

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

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

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

資料: くわしい環境

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

local

Sequential OutputSequential InputRandom
Per ChrBlockRewritePer ChrBlockSeeks
K/sec%CPK/sec%CPK/sec%CPK/sec%CPK/sec%CP/sec%CP
54613685732473030727584987734151200.10
Sequential CreateRandom Create
CreateReadDeleteCreateReadDelete
/sec%CP/sec%CP/sec%CP/sec%CP/sec%CP/sec%CP
18020613216101173601852096752510013690

iscsi-raw

Sequential OutputSequential InputRandom
Per ChrBlockRewritePer ChrBlockSeeks
K/sec%CPK/sec%CPK/sec%CPK/sec%CPK/sec%CP/sec%CP
55277684892962761724501753659001389.70
Sequential CreateRandom Create
CreateReadDeleteCreateReadDelete
/sec%CP/sec%CP/sec%CP/sec%CP/sec%CP/sec%CP
602061677797699064609652421006490

iscsi-vmfs

Sequential OutputSequential InputRandom
Per ChrBlockRewritePer ChrBlockSeeks
K/sec%CPK/sec%CPK/sec%CPK/sec%CPK/sec%CP/sec%CP
27878392797532481724270351679341349.40
Sequential CreateRandom Create
CreateReadDeleteCreateReadDelete
/sec%CP/sec%CP/sec%CP/sec%CP/sec%CP/sec%CP
611057612891685073009703941006550

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

Sequential OutputSequential InputRandom
Per ChrBlockRewritePer ChrBlockSeeks
K/sec%CPK/sec%CPK/sec%CPK/sec%CPK/sec%CP/sec%CP
32945402867842295034541754577461268.20
Sequential CreateRandom Create
CreateReadDeleteCreateReadDelete
/sec%CP/sec%CP/sec%CP/sec%CP/sec%CP/sec%CP
649061665597702072109664371006440

nfs

Sequential OutputSequential InputRandom
Per ChrBlockRewritePer ChrBlockSeeks
K/sec%CPK/sec%CPK/sec%CPK/sec%CPK/sec%CP/sec%CP
28197352531132385233536341458201387.60
Sequential CreateRandom Create
CreateReadDeleteCreateReadDelete
/sec%CP/sec%CP/sec%CP/sec%CP/sec%CP/sec%CP
58006043349971007260859734997540

*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:今考えたら MinTime0.5 でも計測可能なように file size と files を多くすればよかった(より正しい計測になった)のかな。

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

*9前回と同じく signmodules を 0 に変えてあります。

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

2009-01-14

ESXi 環境私的考察

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

  • iSCSINFS によってディスクを外在化させれば,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 は一番簡単にマイグレーションを行うことができる
  • ただし NFSiSCSI に比べより上位の実装なので,
    • 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 全体的に壊れうる?

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 しか立ち上げませんでした

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

ハードウェア諸元

ぶっちゃけていうと,それなりの処理能力(およびネットワーク能力)のあるサーバを用意して,それらを 100Mbps スイッチングハブにつないだということになります。

ストレージについて

DRBD は今回の本筋とは関係ないのですが,今後の環境を考えてインストールしました。ただし片肺運転(つまり Primary のみ)で運用してます。

仮想マシンは以下の4タイプを用意しました。

iscsi-raw
iSCSI で公開されたディスクをそのまま仮想論理ドライブとしてアサイン*4
iscsi-image
iSCSI で公開されたディスクを ESXi のデータストアとして(vmfs で)アサインし,その上にディスクイメージを構築
nfs
NFS で公開されたディスクを ESXi のデータストアとして(vmfs で)アサインし,その上にディスクイメージを構築
local
ローカルにぶら下がっているディスクを ESXi のデータストアとして(vmfs で)アサインし,その上にディスクイメージを構築

となります。

図にすると下記のような感じです。

f:id:dayflower:20090113164818p:image:w400

すべて

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 インストールということでインタラクティブな要素もありますが,諸々の設定を終えたあとから計測を行いました。つまりディスクのフォーマットとパッケージのインストールフェーズのみの時間です。

下記がストップウォッチ*5によるラフな計測です。

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

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

ほんとは IOZone とかでもとるべきなんでしょうけど,面倒なので有名な Bonnie++ だけで。

no title より Bonnie++ 1.03a を取得してビルドを行い,計測を行いました(MinTime0.5 から 0.01 に変えてあります)。あとで気づいたのですが,Bonnie++ now at 1.03e (last version before 2.0)! には Bonnie++ 1.03e があったんですね。

Bonnie++ の出力の読み方は

あたりを参照。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 操作の結果に加味される。
404 - エラー: 404


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

-iscsi-rawiscsi-imagenfslocal
cached reads (MB/sec)6724.966775.606907.936895.84
buffered disk reads (MB/sec)10.6129.1510.81101.98

先に注意点から。

  • 連続3回測定し中間値*6をとった
  • 3回の計測結果からすると結構大まかにブレるのでオーダーのみ参考にし,細かい差は無視するべし
  • cached reads はさきの man からもわかるようにバッファキャッシュとのデータやりとり速度を計測しているので,全 VM で同じような値になっているのはあたりまえ

考察です。

  • iscsi-rawnfs は同じような性能
  • iscsi-image は(なぜか,そして Bonnie++ の一部結果と呼応するように) iscsi-rawnfs の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-rawiscsi-imagenfslocal
real77:5189:1977:5755:38
user29:3232:5829:3430:02
sys15:4318:0815:3716:28
(other)32:3738:1332:469:08
  • nfsiscsi-raw とほぼ同じ結果になっている
  • iscsi-image は iscsi-rawnfs に比べ遅い
    • 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++ は所詮「いわゆるベンチマーク」なので,結果の数値をそのまま過信してはいけない*7
  • iSCSI を data store としてその上に disk image を構築する VM は,
    • ディスクベンチマークでは iSCSI raw disk や NFS data store の VM に比べて(なぜか)勝るものの,
    • 実運用レベルでは逆にパフォーマンスが落ちる
  • NFS data store は iSCSI raw disk と比べ,
    • ディスクベンチマークレベルでは劣る部分もあるものの,
    • 実運用レベルでは遜色ない,というかほぼ同じ
      • (微細な複数のファイルをアクセスする)SMB のようなプロトコルと比較した場合に iSCSI のメリットは生きるかもしれないが,VM disk image のように巨大な単一ファイルを操作する場合にはそれほどアドバンテージはないのかもしれない
  • 100M ネットワークではネットワーク disk の性能はいまいち
    • GbE スマートスイッチ欲しい……

(より広帯域の)GbE 環境で計測したり*8iSCSI target として iSCSI Enterprise Target を利用したり,はたまた iSCSI target 専用機を使った場合にまったく異なる結果となるかもしれません。

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

*2:ジャンボフレーム未対応だそうです。今回は 100Mbps でつないでいるのであまり関係ないと思いますが。

*3:後述する CentOSネットワークインストールで利用した配布元サーバです。あまり大事ではないので既存の環境のものを流用しています。

*4:実際には vmx ファイル等の置き場が必要になりますので iscsi-image の環境を流用しています。ベンチマークの大勢には関係ないと思います。

*5:といってもほんとのストップウォッチを使ったわけではなく,VNC クライアント側で date コマンドを使いました。

*6:平均をとるのが面倒だったので中間値をとりました。他意はないです。

*7:Bonnie++ をおとしめる意図はないです。「いわゆるベンチマーク」というものがあくまで単体性能を計測しているにすぎないこと,Bonnie++ はさまざまなアーキテクチャで動くように書いてあり逆に単体性能を純粋に測定することができないこと,などからこのように書きました。私見ですが,まったく同じアーキテクチャで違う HDD の性能差を測定する場合や,あるいは反対にまったく違うアーキテクチャで Disk I/O の性能バランス・傾向を比較する場合に使うべきものだと思います。

*8:そもそも SAN はファイバーチャネルなど高速なネットワークで運用していたものであり,GbE ならいざしらず 100Mbps 環境では想定外のボトルネックが発生していても不思議ではありません。