fusionio vs huawei

本日、huaweiのPCIeカード型のnandフラッシュカードをお借りしたので、ベンチかけてみました。

12月下旬までお借りできますので、もし、違うオプション、違うツールで確認してほしいという方がいればコメントやフォームからお声をかけていただければと思います。

今回検証するカードは

huawei ES3000 1.2TB:http://enterprise.huawei.com/en/products/itapp/server/high-performance-pcIe-card/hw-194918.htm

です。

ついでにdmmでも50枚以上導入済みのfusion-io社のiodrive2もベンチかけて比較してみます。
fusionio iodrive2 3.0TB:https://www.fusionio.com/products/iodrive2/

■huawei ES3000の主な特徴

Huawei Tecal ES3000はMLCのNANDフラッシュ製品
800GB,1.2TB,2.4TBのタイプがありPCIe (2.0 x8)のインターフェースを持っています。
1.2TBモデルの読み込み時の最大帯域は3.2GB/s書き込み時の最大帯域は1.8GB/sとなっています。
latencyでみると読み込みは8us、書き込みで49usの能力を持つ。

非常にユニークだなと思ったのがFPGAを3つ搭載しFTL、GC、RAIDやECCなどの処理を担うことでホストサーバのCPUをオフロードしてるところ。また、IOスケジューラーをダブルキューとすることで種類の違う命令を別々のキューで処理できるようになっている。この機能により性能の劣化を低減させ、iodrive2よりも2~3倍高速になっている。

価格も半値で設定されているようです。
日本法人は中国本体の開発部門と直接のパスを持っているようで対応が早くなるようです。

ドライバはカーネルそれぞれで専用のものを利用する必要がありますが結構そろっていました。
rhelやCentOS5/6のほとんどのカーネルには対応していると思われる。それ以外のカーネルで利用する場合はhuawei社でドライバをコンパイルしてもらう必要がある。

とにかく論より証拠ベンチいきます。

コマンドはこちらです。

fio –direct=1 –rw=[randread|randwrite] –bs=[1|4|16|32]k –randrepeat=0 -iodepth=32 –name=test –runtime=60 –ioengine=libaio –filename=/dev/[h|f]ioa1

ES3000

size iops b/w latency(iodepth=1)
randread 1 194757 195MB/s 20us
randread 4 198126 793MB/s, 20us
randread 16 163942 2562MB/s 50us
randread 32 101230 3164MB/s 250us
randwrite 1 55334 55MB/s 20us
randwrite 4 153982 615MB/s 20us
randwrite 16 117080 1829MB/s 20us
randwrite 32 58459 1827MB/s 50us

 

iodrive2

size iops b/w latency(iodepth=32)
randread 1 75305 75MB/s 500u
randread 4 77587 310MB/s 500u
randread 16 61895 990MB/s 750u
randread 32 46182 1443MB/s 750u
randwrite 1 80406 80MB/s 5oou
randwrite 4 79840 319MB/s 500u
randwrite 16 64793 1013MB/s 500u
randwrite 32 32234 1007MB/s 1000u

es3000もiodrive2もカタログスペックのbandwidthは出ています。

あと、確かにiodriveよりも2~3倍ほど高速。すごい製品が出てきましたね。

この性能でさらに半値ならお買い得感があるように思います。何枚か購入して実運用してみたいですね。

次にコメントでnumjobsでベンチを取ってみてほしいとのことでしたので、やってみました。

コマンドは下記です。randread

fio –direct=1 –rw=randread –runtime=60 –group_reporting –filename=/dev/hioa1 –name=test –numjobs=32 –bs=[1|4|16|32]k

size iops b/w latency(avg)
randread 1k 508,679 508MB 60us
randread 4k 482,030 1882MB 64us
randread 16k 206,088 3220MB 153us
randread 32k 103,117 3222MB 308us

今までの数あるベンチの結果からiodepthでのベンチは測れるiopsの最大値が200kであるということが分かってきていますが、いまのところのNANDフラッシュ製品であればnumjobsで限界までiopsが測れます。最初のhuaweiの製品のベンチはiodepth=32で測っていますが200kを超えていないのが分かるかと思います。

 

機器貸出の条件として「フリーハンドでのレポートが必要」とのことでしたのでここに書いておこうかな。

題名:ES3000評価レポート

要旨:
カタログスペック通りの値(iops、latency、bandwidth)が出るのか、
ハードウェアインストールやドライバのインストールについて確認する。

イントロダクション:
フラッシュ型のドライブの重要性が増していく中にあっても、このジャンルの製品はfusionio社の1社独走状態。
ちょうど性能的にも価格的にもライバルの存在は必要だと感じていたのですが、
fusionio社の技術はパテントでガチガチに守られていて同じような製品が出たとしてもパフォーマンスに難があるはずだと、根拠もなく考えている節があり他社の検討は行っておりませんでした。
今回、たまたま販社様よりご紹介いただいたES3000は性能でfusionioを超えていますというお話しでしたので、これはと思い評価させていただく機会をいただいた次第です。

パフォーマンス取得方法:
fio –direct=1 –rw=randwrite –bs=16k –randrepeat=0 -iodepth=32 –name=test –runtime=10 –ioengine=libaio –filename=/dev/hioa1

fio結果:このページの上部に記載

まとめ:
ハードウェアインストールの取扱いについては通常のpciカードと同様の扱いやすさだが、キャパシタに手が触れると折れてしまいそうだったのでちょっと怖いかなと感じた。
ドライバインストールについてはドライバがカーネルに依存していてカーネルごとにメーカーにドライバの作成をお願いする必要があるのが難点。20個くらいのカーネルでドライバがすでに用意されているのでその点は良いのだが、
必要なカーネルバージョンのドライバを探すのが面倒でした。カーネルのバージョンを自動で認識して最適なドライバを選択してインストールさせる方式になればいいと思う。
マニュアルについては読みやすく理解しやすいが順序があってない箇所もあったように思う。パフォーマンスについてですが一部カタログスペックに届かない数値もあったが、相対的に見ればライバル機よりも相対的にパフォーマンスが高いことがわかった。
価格的にも半額ということなのでサポート体制次第では弊社としてもラインナップの一つとして加えていければと考えている。

継続調査

下記コマンドにて確認できる項目について
特に「Max bad block rate: 0.112%」この部分がすでに数値が上がっているがなぜなのか確認する。またこのブロックレートがどこまでいくとreadモードになるのかも確認する必要がある。

# hio_info -d /dev/hioa1
hioa Size(GB): 1204
Max size(GB): 1204
Serial number: 030PXS10D4000029
Driver version: 2.0.0.39
Bridge firmware version: 320
Controller firmware version: 320
Battery firmware version: 111
Battery status: OK
Run time (sec.): 1816611
Total IO read: 259518244
Total IO write: 298356159
Total read(MB): 1729073
Total write(MB): 1828273
IO timeout: 0
R/W error: 0
Max bit flip: 5
Average EC: 1
Max bad block rate: 0.112%
Event log: OK
Health: OK

 

【AWSのプロビジョンドIOPS追記】パブリッククラウドIOPS比較【ボニプラ編】

 

fioに続きbonnie++での調査を行ってみました。

キャッシュが利いていて平等ではないとの指摘もあったので別のツールでも試します。

実態にそった現実的な数字が出てきたと思います。

コマンドの例はこちらです。

bonnie++ -d /mnt -c 32 -n 256:1024:1024:16 -u root -s 16000

※1Core/2GBメモリ/増設100GB
※価格性能比は1000円あたりのiops値

パブリッククラウド RandomSeeks
(iops)
type 月額 価格性能比 awsのプロビジョンドIOPSの価格で換算すると
idcf 1068 6,048 177 14,316
sakura 6392 ssd 3,675 1739 78,204
607 標準 2,100 289 8,784
nifty 1486 40 4,200 354 19,332
1493 200A 5,250 284 19,416
8177 ssd 25,200 324 99,624
ncom 120 1,050 114 2,940
aws
672(実測) iops
500
7,500 90
3684(実測) iops
2000
25,500 144

fioのベンチとはまったく違った結果ですよね。

これだとsakuraのssdタイプがコスパ的に圧倒的でパフォーマンスも申し分ないです。

iopsは保証されているわけではないようなので一概には比較できないんだなあと思っていますがSSDならある程度は維持できると予想しています。なのでsakuraとniftyのssdはめちゃくちゃお得かもしれません。

sakuraのssdタイプは300GBまでの選択しかできないようですがお願いすればそれ以上の割り当ても可能かもしれません。ダメだったとしてもいくつかをmdで束ねることでコスパを維持したまま大容量で高パフォーマンスを享受できるのではないかと思います。ちなみにniftyのssdタイプも300GBまでの容量です。

それにしても各社さん同じような機材を使っているように思うのですが、どこで差がつくのでしょうかね?

qos?混雑具合?

awsのようにプロビジョンドIOPSのように品質保証が可能となってくれば高くても選択肢の一つとして検討できるように思います。

各社さんの見解を聞いてみたいですね。

ちにみにawsのiops保証は16KBでの書き込みで設定されています。
プロビジョンドIOPSで2000IOPSでボリュームを作成したなら、1秒間に16KBの書き込みが2000回可能。32KBなら1000回/秒。64KBなら500回/秒とのことです。

価格設定は下記の通りです。

IOPS 月額 EBSボリューム(100GB) トータル月額(円)
100 1,200 1,500 2,700
500 6,000 1,500 7,500
1000 12,000 1,500 13,500
2000 24,000 1,500 25,500

※1ドル100円換算

プロビジョンドIOPS設定をしなければ100GBで1500円/月
100iops相当のパフォーマンスとのことです。

最後に誤解がなきよう付け加えます。

いろんな指標でawsが悪い結果となっていますが、
プロビジョンドIOPSやその他機能も多く揃っており今でも増え続けています。
自分にとって必要な機能を見極めた上で価格などの比較を行っていくべきかなと思います。

特に、グローバルに展開する企業やサービスにとっては唯一無二の存在で、
その他グローバルに展開する事業者があるのは確かですが、リージョンの多さとその情報量の違いは他を圧倒しているのではないでしょうか。

うちも海外向けサービスならAWS使っちゃうかなあ。

パブリッククラウド回線速度ランキング

小ネタです。

先ほど各パブリッククラウド環境で600MBのファイルをダウンロードしてみました。

dmmのバックボーンに直結したサーバで1Gbps回線を持つサーバからのダウンロードです。

コマンドは下記です。
wget ftp://mirror.dmmlabs.jp/linux/centos/5.10/isos/x86_64/CentOS-5.10-x86_64-bin-2of9.iso

パブリッククラウド 回線種別 速度 時間
nifty 1G共有 102 MB/s 2013-11-28 00:34:28
ncom 1G共有 11.7 MB/s 2013-11-28 00:39:59
idcf 1G共有 88.8 MB/s 2013-11-28 00:29:12
sakura 100M共有 15.3 MB/s 2013-11-28 00:29:55

nifty(102) > idcf(88.8) > sakura(15.3) > ncom(11.7)

sakuraは100M共有なのでncom以外は問題ないです。安定しています。

ncomはこの時間混雑しているようです。かなり影響がありyumのupdateなども動かない状態でした。

 

パブリッククラウドIOPS比較

各社のクラウド環境でディスク周りのベンチマークを取ってみましたので共有します。

/rootボリュームと増設ボリュームでのベンチとなります。

まずは/rootボリュームから

randreadでコマンドは下記です。
fio –direct=1 –rw=randread –bs=4k –size=5G –numjobs=64 –runtime=10 –group_reporting –filename=iofile –name=file1

※1Core/2GBサーバ

ゾーン iops latency 月額 iops価格性能比
nifty
east-11
2804 50msec
36%
10msec
27%
20msec
26% 
18,144 155
nifty
east-12
2339 50msec
35%
20msec
27%
10msec
25%
18,144 129
nifty
east-13
1972 10msec
41%
50msec
31%
20msec
20%
18.144 109
ncom-1a 678 100msec
80%
250msec
14%
50msec
2%
3,780 179
ncom-2a 1946 50msec
84%
20msec
9%
100msec
4%
3,780 515
sakura
第二
5769 10msec
56%
20msec
37%
50msec
6%
2,500 2307
sakura
第一
6030 10msec
88%
100msec
11%
4msec
1%
2,500 2412
idcf 653 100msec
58%
250msec
31%
10msec
2%
12,240 53
参考
iodrive
109061 0.5msec
47%
0.75sec
32%
1msec
13%

iops価格性能比順を示します。

sakura1(2412) > sakura2(2307) > ncom2a(515) > ncom1a(179) > nifty11(155) > nifty12(129) > nifty13(109) > idcf(53)

ここで特筆すべきはncomのクラウドはゾーンの違いによりパフォーマンスに大きな差が出ている。その他のクラウドはゾーンに違いによる変化はないのですが、ncomでは使っている機材がまったく異なっているのでしょうか。それとも混雑しているのでしょうか。

次に増設したストレージの比較

コマンドは下記としました。

fio –direct=1 –rw=randread –bs=4k –size=1G –numjobs=32 –runtime=10 –group_reporting –filename=iofile –name=file1

 

ディスクタイプ 容量 iops Latency 月額 iops価格性能比
nifty40 100GB 28882 0.5msec
31%
0.75msec
25%
2msec
17%
4,200 6876
nifty200a 100GB 29804 0.5msec
41%
0.75msec
21%
2msec
13%
5,250 5676
niftyssd 100GB 29303 2msec
54%
1msec
28%
0.75msec
15%
25,200 1162
ncom100 100GB 15233 2msec
52%
4msec
40%
1msec
7%
1,050 14507
sakurassd 100GB 8755 4msec
97%
10msec
3%
3,675 2382
sakura標準 100GB 2001 10msec
44%
4msec
51%
1msec
10%
2,100 952
idcf 100GB 38256 1msec
49%
0.75msec
28%
2msec
16%
6,048 6325

ncom(14507) > nifty40(6876) > idcf(6325) > nifty200a(5676) > sakurassd(2382) > niftyssd(1162) > sakura標準(952)

相対的に見ればsakuraとniftyのssd以外はどれでも良いように思います。

latencyとiopsの高性能モデルで選ぶならidcfとnifty。コスパならncomですかね。

驚くべきところとしてはniftyのパフォーマンス。
どのタイプのボリュームを選択しても変わらないパフォーマンス
IOPS値の保証がない事をリスクとして承知の上で利用するのであれば有りかも。

国産でもAWSのようにプロビジョンドIOPSで性能保証するサービスを期待しています。

3PARの今後のファームでqosが使えるようになるそうでiopsが保証される時代がやってきそうではありますがまだ先ですかね。

 

パブリッククラウドのゾーンによるCPU型番の違い

各社のクラウド内のゾーンでCPUの違いを調べてみました。

まずはCPUの型番のおさらいから
※私の知っているクラウド環境でインテル以外のCPUがいなかったのでインテルでの比較のみです。

とりあえず、サーバ製品はXeonの下記の型番だけ覚えておけば良いです。左のほうが最新のCPUです。右側へいくにつれて古い型番のCPUです。
ivyは10月くらいからの製品に搭載されるようになってきました。なので、まだクラウド環境ではお目にする機会はないかもです。遭遇するとラッキーかもしれません。

ivy bridge(E5系v2) > sandy bridge(E5系) >>> westmare(*5600番台) > nehalem(*5500番台) > Harpertown(*5400番台)

また、sandy bridgeからはかなり性能が上がっています。出来ればsandy以降のCPUを選択したいところです。

では、各社を見ていきましょう。

まずはNIFTYクラウドから

NIFTYクラウドはゾーンが3つ存在しています。

1Core 1GBモデル

ゾーン CPU型番 スコア
east-11 X5680 3.33GHz 1544
east-12 X5690 3.47GHz 1564
east-13 E5-2690 2.90GHz 1643

east-13がスコア的にもCPUの型番的にもいいですね。同じコストならeast-13が良い選択かも
※世代が変わってもスコアが合うように設定されているのがわかりますね。

次にさくらのクラウドです。2つのゾーンが存在しています。

1Core 1GBモデル

ゾーン CPU型番 スコア
石狩第一 X5675 3.07GHz 1391
石狩第二 E5-2640 2.50GHz 1407

さくらのクラウドはE5のsandy bridgeが使える石狩第二が良さそうです。

ただ、上記2社は、どのゾーンであってもスコアが合うように設定されていて、どちらのゾーンを選択しても平等になるようになっているようです。※私的にはスコアが同じでもsandyを選ぶかな。

次々と進化していくCPUですが、どこまで同じスコアで合わせいけるのか。
CPUが劇的な進化を遂げたときどのような変化が起こってくるのか非常に楽しみです。
性能に合わせた価格設定になるのかな?

さて、次の会社へいきましょう。

ncomとidcfはゾーンが2つあるのですが、いずれも同じ型番のCPUとなっていました。

最後にAWSです。

有名なインスタンスガチャです。
※awsは同じゾーンで違う型番のCPUが混在しています。

m1.smallとm1.midiumを各20個作ってみました。

出現回数 インスタンスタイプ CPU型番 スコア
18 m1.small E5645 2.40GHz 142
2 m1.small E5507 2.27GHz 137
8 m1.midium E5645 2.40GHz 337
12 m1.midium E5-2650 2.00GHz 309

ここでも他のクラウド事業者同様。スコアがばっちり合うように設定されてますね。どのような型番であっても同じようなスコアになっています。

AWSは少し違うアプローチでCPUの仕事量を調整しているようですね。
同じ型番、同じコア数でもインスタンスのタイプでスコアに違いが出るようになっています。こうすることで各インスタンス間で明確な差別化が行われています。
最新のCPUに足かせをつけることによって3つも4つも世代が古いCPUでも売れる。すごく効率的でAmazon社的には良いのだろうと思います。ただし、現状、価格に反映してなさそうなのでどうなんだろうなあとも思う。。

一方、国産クラウドばCPUのコア数でインスタンスタイプ間で差別化するようになっていてパフォーマンス重視を打ち出しているように見えます。価格性能比もいいですし。国産頑張っていると思います。