DNS, 小ネタ

仰々しいタイトルですが小ネタです。

options timeout:n

上記でnameserverの切り替わりの秒数を制御できますが

IPの接続性がありDNSのサービス自体が落ちている場合はtimeout値まで待たずに瞬時に切り替わります。

※IPの接続性が失われるとoption timeout:nの値(デフォルト5秒)が適用されその分遅延します。

この特性を覚えておけば、ミッションクリティカルな環境ではDNSキャッシュサーバの再起動は控えるようになりますし、LVSや負荷分散アプライアンスを利用し障害やメンテナンス時の遅延を最小に抑えることも検討できるようになります。

ちなみに、うちではネットワークに問題を抱えるXenServerでDNSキャッシュサーバを構築禁止です。^^;

 

 

クラウド

パブリッククラウドの環境にmemcachedをインストールしmemslapで負荷試験を行ってみました。

下記コマンドでの評価です。

memslap –servers=x.x.x.x –concurrency=32 –flush –test set –execute-number=50000

  memcached
Client
月額費用 memcached
Server
月額費用 処理時間 RTT(avg)
server – client
nifty      2Core 4GB 35,070 1Core 2GB 18,144 24sec 0.249ms
4Core 8GB  66,528 24sec 0.288ms
8Core 32GB  183,435 23sec 0.152ms
1Core 2GB 18,144 8Core 32GB 183,435 27sec
2Core 4GB 35,070 29sec
4Core 8GB 66,528 30sec
localhost 183,435 15sec
idcf  2Core 8GB 13,600 1Core 2GB 5,300 32sec 0.228ms
1Core 2GB 5,300 2Core 8GB 13,600 32sec
locahost 13,600 28sec
ncom        2Core 4GB 7,560 1Core 2GB 3,780 51sec 0.610ms
 4Core 8GB 15,120 50sec 0.579ms
 8Core 16GB 30,240 50sec 0.684ms
 16Core 64GB 87,780 43sec 0.349ms
1Core 2GB 3,780 16Core 64GB 87,780 50sec
2Core 4GB 7,560 46sec
4Core 8GB 15,120 50sec
8Core 16GB 30.240 47sec
localhost 87,780 40sec
sakura      2Core 4GB 5,145 1Core 2GB 2,500 172sec 0.294ms
4Core 8GB 11,445 165sec 0.364ms
12Core 48GB 55,545 162sec 0.349ms
1Core 2GB 2,500 12Core 48GB 55,545 150sec
2Core 4GB 5,145 66sec
4Core 8GB 11,445 46sec
localhost 55,545 19sec

※1Coreサーバでのlocalhostはチェックしていません。1Coreしかないのでmemslap側の処理の負荷により参考になる値が取れないため。

パッと見だと

nifty > idcf > ncom > sakura

各社間の比較というよりは各クラウド環境の中でmemcachedをどのようなスペックで構成すればいいのかの指標にできるような気がします。

これを見れば余剰なスペックを抑制しコスト的なメリットが見えてくるかも。もちろん速度重視の場合はこの限りではないですが。sakura以外は低めのスペックでも十分でコストを抑制できそうです。

それにしても特筆すべきはsakuraの各社と比較しての処理時間の遅さとサーバスペックによる処理時間の差です。

LinuxではRescheduling interruptsにより非常に忙しい状態にあるときアイドル状態にあるCPUへ処理を割り振るようになるようなんですが、sakuraのサーバはこの状態への移行が他社と比べて早いためコア数の変化によりリニアに処理時間が早くなっていたように見える。

逆にスペックを上げればパフォーマンスの改善が見込まれるので望ましい形のような気もしますが基本性能が低いだけになんとも言えないような気もします。

このあたり、いいリファレンスないですかね?

兎にも角にもご参考までに

クラウド

最近ずっと続いているパブリッククラウドの評価ですが次は内部ネットワークのパフォーマンスについてです。

評価するパブリッククラウドは下記の4つです。

idcf cloud: http://www.idcf.jp/cloud/
sakura cloud: http://cloud.sakura.ad.jp/
nifty cloud: http://cloud.nifty.com/
nttcom cloudn: http://www.ntt.com/cloudn/

pingとネットワーク転送帯域について

from to RTT(avg) 帯域(iperf) interface 安定しているかどうか
nifty 1Core 2GB 2Core 4GB 0.249 4.02Gbps 10G stable
4Core 8GG 0.288 4.26Gbps 10G stable
8Core 32GB 0.152 21.8Gbps 10G stable
idcf 1Core 2GB 2Core 4GB 0.236 468Mbps 1G stable
ncom 1Core 2GB 2Core 4GB 0.610 557Mbps 1G unstable
4Core 8GB 0.579 458Mbps 1G unstable
8Core 16GB 0.684 252Mbps 1G unstable
16Core 64GB 0.659 250Mbps 1G unstable
sakura 1Core 2GB 2Core 4GB 0.294 465Mbps 1G stable
4Core 8GB 0.364 468Mbps 1G stable
12Core 48GB 0.349 458Mbps 1G stable

※pingは安定してから100パケットの平均値
※iperfは100MBの転送。3回試して安定して速度が出ているかどうかも確認しています。※unstableとは速度が安定して出ていないということです。プラスマイナスで200Mbps
※ncomについてはプライベートの足がなかったのでグローバル側で計測しています。

ぱっと見だと、
nifty > idcf > sakura > ncom

niftyで10Gのインターフェースで21Gbps出ているものがありますが、同じブレードサーバ内のインスタンスかもしくは同一ホストなんじゃないかと思います。

インスタンスガチャになりますが、もしlatencyなど気にされる方であればniftyで何度も作り直して同じブレードのエンクロージャー内となるまで頑張るのもありかもしれません。ただしエンクロージャーや仮想ホストの障害には対応できなくなるので注意が必要ではありますが。

我々の環境で20kmの専用線で接続している内部のネットワークのRTTは0.25msecほどです。同一のデータセンター内での通信だと0.15msec程度なので、結構びっくりな数値です。遅いという意味で

小ネタ

そういえばUnixBenchですが、CPUのスレッドが16以上だと対応していません。

パッチを当てることでCPUのスレッドが無制限に解除できます。

下記ページが参考になるかと思います。

https://code.google.com/p/byte-unixbench/issues/detail?id=4

もしくは下記の3か所を修正すればいけます。

'system' => { 'name' => "System Benchmarks", 'maxCopies' => 16 },

'system' => { 'name' => "System Benchmarks", 'maxCopies' => 0 },

'misc' => { 'name' => "Non-Index Benchmarks", 'maxCopies' => 16 },

'misc' => { 'name' => "Non-Index Benchmarks", 'maxCopies' => 0 },

next if ($copies > $maxCopies);

next if ($maxCopies > 0 && $copies > $maxCopies);

hardware

本日、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

 

PAGE TOP