DNSの評価と計測の話

Size: px

Start display at page:

Download "DNSの評価と計測の話"

さみあんさい
5 years ago
Views:

1 DNS の評価と計測の話 Internet Week 2013 SCSK 株式会社服部成浩 1

2 内容 DNSストレスツール Nominum dnsperf/resperfの紹介 dnsperf と resperf の違い負荷の生成方法エラーメッセージ対処同じ DNS サーバ (unbound) に対して dnsperf, resperf でかけた場合同じ結果になる? ケーススタディ dnsperf, resperf オプション指定例結果ファイル 2

3 Nominum dnsperf/resperf dnsperf 権威サーバや LAN 環境でのキャッシュサーバのテストでは O.K. キャッシュのテストで WAN 回線を使用した場合は結果が不十分になる可能性ありレスポンス状況で dnsperf の出す負荷 (qps) が変化するため resperf レスポンス状態にかかわらず負荷を上げていくことができるしたがってテスト時に WAN 環境の影響を受けにくい 3

4 dnsperf の負荷 self-pacing approach # dnsperf -q 20 の場合名前解決中のクエリが 20 たまるように QPS を調整するサーバの処理量 ( 出て行く量 ) に応じ QPS( 注入する水の量 ) がかわる遅延のある環境だと名前解決中のクエリがたまりやすい QPS は少ない QPS -q 20 たまるように dnsperf が QPS を調整風呂桶 -q 20( ユーザが指定 ) 出て行く量 ( 少 ) = サーバのクエリ処理量 QPS 風呂桶 -q 20 出て行く量 ( 多 ) = サーバのクエリ処理量 4

5 resperf の負荷 controlled rate approach 60 秒かけて 100,000 QPS( デフォルト値 ) -r 60 -m 毎秒約 1,666 クエリ負荷を上げていく 1 秒 1,666 クエリ 100,000 QPS -m QPS 0 秒 -r 秒 5

6 dnsperf オプション指定例 # dnsperf -s S 1 -d query_random_list.txt q 20 c 1 b s : ターゲットの IP -S 1 : 毎秒 dnsperf が送信した qps を表示 -d : クエリファイル -q 20 : 名前解決中のクエリが 20 になるように QPS を調整する ( デフォルト q 100 ) -c 1 : クライアント数 ( デフォルト c 1 ) -b : UDP バッファ ( デフォルト 32 kilo bytes) 6

7 dnsperf q オプション遅延による QPS 影響遅延なし遅延 100msec の環境で同じ負荷を発生させた場合 dnsperf のオプションは同じ # dnsperf -s S 1 -d query_random_list.txt q 20 遅延なし ( 4,600 QPS) dnsperf 上の送信 QPS : エポック時間 : QPS : 遅延 100msec ( 100 QPS ) dnsperf 上の送信 QPS ( 100QPS ) : 遅延があると名前解決中のクエリ (-q 20) を 100QPS 程度で維持できるため, 負荷 (QPS) が小さい遅延のある環境では期待した QPS とならない場合がある 7

8 dnsperf -q オプション -q オプションの値を大きくすればQPS 多量に送信できる? 例えば q 5000? -q の値を大きくしてもあまりQPSが出ない» QPSが安定しない» UDPバッファあふれ q のデフォルト値は 100 -q 100 ( デフォルト値 ) でテスト対象のリソースの限界が確認できた場合は -q 50, 20, 10, 5 と小さくしていく -q 100 でまだリテスト対象のソースがあまっていれば -q 200, -q 300 と大きくする 8

9 dnsperf -b オプション UDP バッファエラー UDP バッファエラー dnsperf マシンの限界 # dnsperf -s S 1 -d query_same_list.txt -l 30 -q 5000 Warning: failed to send packet: Resource temporarily unavailable UDP バッファのエラーをチェック ( dnsperf マシン上で netstat su ) # netstat su Udp: <snip> packets sent SndbufErrors: b オプションでバッファサイズを増やすことでエラーがなくなる場合もある # dnsperf b s S 1 -d query_same_list.txt デフォルト : OS のデフォルト値 (wmem_default, rmem_default) 送信バッファ : /proc/sys/net/core/wmem_default (wmem_max ではない ) 受信バッファ : /proc/sys/net/core/rmem_default (rmem_max ではない ) 9

10 OSのUDPバッファのチューニング (Ubuntu 12.04) 送信バッファ # sysctl -w net.core.wmem_default= # sysctl -w net.core.wmem_max= 受信バッファ # sysctl -w net.core.rmem_default= # sysctl -w net.core.rmem_max=

11 dnsperf c オプションクライアント数 -c 1 : 1 クライアント数 1クライアントの定義送信元 UDPポート番号が異なる注意 : 送信元 IPアドレスは同じ 1 クライアントで 2 スレッド使用送信で 1 スレッド受信で 1 スレッド 2 クライアントだと 4 スレッド指定方法 : -c クライアント数クライアント数 2./dnsperf -c 2 -d query.txt -s IP クライアント数 10./dnsperf -c 10 -d query.txt -s IP デフォルト (-c を指定しない場合 ) はクライアント数は 1 -c の値を増やすと使用するスレッド数が増えるので QPS が増える場合がある resperf はシングルスレッド 1 クライアント ( 送信元 IP*1, 送信元 UDP ポート *1) 11

12 dnsperf チューニング -b, -c, -q オプションを調整し負荷 (QPS) を上げる # dnsperf -s d query.txt -S 1 -l 60 -q 200 -c 4 -b : : # dnsperf -s d query.txt -S 1 -l 60 -q 300 -c 6 -b : :

13 resperf オプション # resperf -s d query.txt -r m b s : テスト対処の IP -d : クエリファイル -r 120 m 秒かけて 50,000QPS まで負荷をあげるデフォルトは 60 秒かけて 10 万 QPS(-r 60 m ) -b UDP バッファサイズデフォルトは 32 kilo bytes 13

14 resperf エラーバッファあふれやリソースの問題でクエリを送信できないときのエラー Warning: failed to send packet: Resource temporarily unavailable Fell behind by 1000 queries, ending test at qps -b でバッファサイズを増やす # resperf b デフォルト : 32kilo bytes ( -b ) netstat su でエラーチェック (SndbufErrors) バッファサイズを増やしてもエラーが解消しない場合は OS の UDP バッファのチューニング負荷発生マシンを複数台にわける負荷を小さくするスペックの良いマシンを使用するなど 14

15 dnsperf, resperf で同じ結果になる? 3 台マシンを準備負荷発生マシン Nominum dnsperf/resperf 2.0 負荷生成 dnsperf resperf キャッシュサーバ (unbound) 権威サーバ (BIND) キャッシュサーバ ( unbound ) 権威サーバ ( BIND ) L2SW LAN 環境 ( 回線遅延なし ) unbound(single thread) に負荷をかけるキャッシュヒット率 0% OS は全て Ubutnu12.04 LTS 64bit 低スペックな環境で動作させているのでパフォーマンス (QPS) 自体は問題としない resperf dnsperf で同じ結果になるかが目的 15

16 dnsperf -q の値を変化させる 100,20,10,5 -q 100 のときの unbound のリソースが 100% だったので -q を小さい値にする QPS がだいたい落ち着くところをさがす限界値 4,500QPS ~ 4,900QPS あたり dnsperf -q 100 ( デフォルト値 ) # dnsperf -s S 1 c 1 -d query_same_list.txt -l # dnsperf -s S 1 c 1 -d query_same_list.txt -l 30 -q # dnsperf -s S 1 c 1 -d query_same_list.txt -l 30 -q 10 5 # dnsperf -s S 1 c 1 -d query_same_list.txt -l 30 -q 5 QPS (dnsperf, unbound 上で観測 ) 4,500QPS~ 7,500QPS でふらつく 100% 4,500QPS 4,900QPS % 4,500 4,600 QPS 96 98% unbound の CPU 使用率 (single thread) キャッシュヒット率 0% 3,800QPS 4,000QPS 88% - 92% 16

17 resperf resperf でテスト ( 60 秒かけて 100,000QPS ) # resperf -s d query_random_list.txt resperf 結果 [Status] Reached outstanding queries Transaction ID を全て消費したため終了 Statistics: Queries sent: Queries completed: Queries lost: 0 Run time (s): Maximum throughput: qps dnsperf の結果と大きく差がある Lost at that point: 0.00% Maximum throughput とは? テスト中に得られた最大 responses_per_sec Maximum throughput が 9,582 qps のときは遅延が発生しているかもしれない 17

18 resperf どこらへんが限界値 (QPS) か判断が難しい実際に DNS サーバが処理できる値に対して resperf の負荷 ( 60 秒かけて 10 万 QPS) が高すぎた unbound-controal stats 結果 ( QPS ) # while :; do unbound-control stats grep 'total.num.queries'; sleep 1 ;done total.num.queries=4301 total.num.queries=6358 total.num.queries=6621 total.num.queries=9400 CPU 100% PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 760 unbound m 27m 2256 R :21.43 unbound 18

19 resperf resperf の結果ファイル resperf.gnuplot( テキストファイル ) を確認テスト終了後に resperf を実行したディレクトリに生成される time: 0.5 秒毎にプロット target_qps: 目標 qps actual_qps : 実際の qps responses_per_sec: 戻ってきたレスポンス failures_per_sec: failure レート ( NXDOMAIN, NO ERROR を除くレスポンス ) avg_latency: 平均レイテンシ resperf.gnuplot 結果ファイル # time target_qps actual_qps responses_per_sec failures_per_sec avg_latency

20 resperf actual_qps と responses_per_sec に差がでたところ avg_latency ( 例えば 0.1 以上, 1 秒以上になったところ ) # time target_qps actual_qps responses_per_sec failures_per_sec avg_latency レイテンシ 0.1 秒以上レイテンシ 1 秒以上 Maximum throughput の値 actual_qps とresponses_per _secに差 ,000-10,000QPS のどこか? 20

21 resperf 負荷をなだらかにしてテスト -m r 秒かけて 10,000QPS 結果ファイルを resperf-report でグラフ化オプションは resperf も resperf-report 同じ gnuplot をインストールする必要がある # resperf-report -s d query_random_list.txt -r 60 -m Done, report is in html 21

22 resperf 結果グラフ右上のグラフ : QPS 赤 : 送信クエリ緑 : 受信青 : Failure 右下のグラフ : レイテンシレイテンシが上昇し始めたところの QPS 5,000QPS 5300QPS 前後が低遅延で処理できる限界 unbound 上 QPS ( 増え方がなだらかになった ) total.num.queries=4709 total.num.queries=4900 total.num.queries=5316 CPU 90 96% 22

23 dnsperf, resperf dnsperf, respserf でもだいたい同じ結果になった無理やり 5,000QPS あたりでまとめた (?) 挙動の違いを知っているとだいたい同じ結果を導けそう dnsperf -q, -c, -b の調整 resperf ランプアップの調整 -r 60 m , -r 60 m 10000, -r 60 m b の調整結果ファイル (resperf.gnuplot ) を確認 actual_qps, reosponses_per_sec, avg_latency maximum throughput の QPS だけで判断しない 23

24 参考 : 遅延エミュレート Linux Traffic Control Ubuntu LTS 64bit 100msec 遅延追加 # tc qdisc add dev eth0 root netem delay 100ms 変更 ( 100msec 10msec ) # tc qdisc change dev eth0 root netem delay 10ms 変更するときは最初に add している必要がある削除 # tc qdisc delete dev eth0 root netem delay 10ms 設定確認 # tc qdisc show dev eth0 24

25 参考 :dnsperf, resperf コンパイル Nominum dnsperf / resperf dnsperf-src tar.gz または nominu.com へブラウザでアクセス dnsperf で検索コンパイル (Ubuntu bit LTS) # apt-get install libbind-dev build-essential dnsutils bind9 libpcap-dev tshark libxml2-dev libssl-dev libcap-dev gnuplot tshark # ln -s /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2.2 /usr/lib/x86_64-linuxgnu/libgssapi_krb5.so # tar xzvf bind tar.gz # cp bind-9.9.4/lib/isc/include/isc/hmacsha.h /usr/include/isc # tar xzvf dnsperf-src tar.gz # cd dnsperf-src / # sh configure # make # make install 25

26 参考 dnsperf,resperfクエリファイルの書式 queryperf と同じ書式ドメインクエリタイプ # cat query_list_sample.txt A AAAA foo.com MX 26

27 unbound 参考 Unbound unbound # apt-get install unbound unbound.conf statistics-interval: 0 statistics-cumulative: no num-threads: 1 27

自己紹介 l Nominum 社の商用 DNS,DHCPソフトウェアの技術を担当しています Nominumの回し者ではありません l l プライベート DNS(Nominum 除く) unbound, PowerDNS, BIND10とたわむれています DNS 以

自己紹介 l Nominum 社の商用 DNS,DHCPソフトウェアの技術を担当しています Nominumの回し者ではありません l l プライベート DNS(Nominum 除く) unbound, PowerDNS, BIND10とたわむれています DNS 以フリーのDNS ストレスツールの紹介 dnsperf ( 開発元 Nominum), dnstcpbench( 開発元 Nether Labs) 2013/7/18 SCSK 株式会社服部成浩 ( s.hattori@scsk.jp ) 自己紹介 l Nominum 社の商用 DNS,DHCPソフトウェアの技術を担当しています Nominumの回