resolverの特性から見るDNSキャッシュサーバ運用の勘所

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

options timeout:n

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

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

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

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

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

 

 

パブリッククラウドmemcachedパフォーマンス比較

パブリッククラウドの環境に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スレッド数制限解除

そういえば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);