BLOG株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。by一緒にラクーンのサービスをつくりませんか?採用情報カジュアル面談2016.3.23インフラネットワークパフォーマンスローカルUnboundによる名前解決の冗長化の検証パフォーマンスUnboundDNSこんにちは!はんだです。今日はDNSサーバの可用性向上についてのエントリです。単純にDNSサーバを複数設置して/etc/resolv.confに記入するという方法がありますが、その方法には、タイムアウトの待ち時間という落とし穴があります。//DNS2のIPアドレスのように設定したとして、1行目のDNS1が落ちた状態の場合、2行目のDNS2に移行するまでに、設定次第ですが問い合わせの度に毎回1~数秒のタイムアウトが発生します。「DNSサーバの冗長化」の項が詳しいです)。この問題への対策として、LVS+Keepalivedなどを利用して冗長性を高める方法がありますが、それに加え複数のDNSサーバをローカルのUnboundの参照先として指定することで冗長性を高めるという方法を検証してみました。検証用の環境として以下を準備しました。node01とnode02でLVS。node03とnode04でLVS。BINDsv-web01にはUnboundをインストールし、/etc/resolv.confには以下のようにnameserverを設定します。//sv-dns-lvs02Unboundの設定Unboundとは、シンプルな設計になっており高速で動作する。BINDより処理性能が良い(2~3倍)設定ファイルは1つのみ(unbound.conf)で内容もシンプルなため、設定が容易キャッシュ汚染に対する耐性を強化した設計&DNSSECをサポートデフォルト設定で高いセキュリティが確保された状態で動くという特徴を持った、新定番となっているDNSキャッシュサーバです。デフォルトの設定でもキャッシュサーバとして問題なく動作しますが、今回は社内の権威DNSサーバへ問い合わせを行いたいため、stub-zoneの設定を行います。stub-zoneは、特定のドメインの名前解決について、指定したDNS権威サーバに問い合わせを行うための設定です。/etc/unbound/unbound.confで、参照先DNSサーバとしてsv-dns-lvs01とsv-dns-lvs02を指定します。stub-addr:192.168.0.12Unboundはデフォルトではプライベートアドレスの問い合わせを行わないので、以下の設定を追加します。transparentまた、特定のドメインについて、指定したDNSキャッシュサーバに再帰問い合わせを行わせるときにはforward-zoneを設定します。指定することで、全ての問い合わせを転送することもできます。自社ドメイン以外は別のDNSサーバ(外部DNSなど)を指定して直接問い合わせを行わせるような場合は、こちらで設定します。203.0.113.111検証したいことstub-zoneに複数DNSサーバを記述した場合、どのような問い合わせ順序になるか。先に書かれているものが優先なのか、ラウンドロビンなのか。stub-zoneに書いたDNSサーバのうち1つが利用不可になった場合に、どのような挙動になるか。利用不可になった理由が、サーバ自体がダウンした場合と、DNSサービスが利用不可になった場合では、挙動に違いはあるか。resolv.confでは、サーバ自体のダウンではなくDNSサービスが落ちていた場合にタイムアウトまでに長くかかることがあるが、Unboundではどうか。検証手順0.事前準備テスト用のスクリプトを作成します。sv-web01から他のサーバにnslookupを行い、最後にunboundのキャッシュを削除するというだけの単純なものです。test.logこのスクリプトを実行しながらサーバやサービスを落として、どのサーバで名前解決が行われているかを確認します。DNSサーバに何の問題も起こっていない時点では以下のようなログになります。127.0.0.1、つまりローカルのUnboundで名前解決が行われているのがわかります。各LVSサーバでDNSサービスへの接続状態を確認しながら検証用スクリプトを実行してみます。271InActConn(一定時間以内の接続数)がほぼおなじ数字で推移しています。結論:stub-zoneに複数のDNSサーバを記入した場合、順番に均等に問い合わせが割り振られる。上記スクリプトを実行した状態で、片方のLVS(sv-dns-lvs01)を落としてみます。127.0.0.1LVSサーバを落としたタイミングで若干処理スピードの低減が発生しましたが、ほぼタイムラグなくsv-dns-lvs01を切り離して引き続きUnboundで名前解決を行ってくれるようです。結論:stub-addrとして指定した複数のDNSのうち一つが落ちた場合でも、Unbound内で切り離しをして名前解決が続行される。sv-dns-lvs0x自体が落ちている場合と、sv-dns-lvs0xにぶらさがっている2つのnodeの両方のDNSサービスが利用不可の場合とで挙動は変わるかLVS用のサーバが落ちた場合、Unboundがうまく切り離してくれることがわかりました。LVSサーバではなく、node側のDNSサービスが両方落ちた場合はどうでしょうか。sv-dns-lvs01で利用している、sv-dns-node01とsv-dns-node02の両方で、namedサービスを停止してみます。127.0.0.1検証2と同様、若干の処理速度低下はありますが、その後は引き続きUnboundでの名前解決が継続されました。結論:LVS自体が落ちている場合とサービスが使用不可の場合で挙動は変わらないまとめ検証により、DNSサーバ障害時のパフォーマンスへの影響をローカルUnboundを導入することによりより減らすことができるだろうという結論が得られました。ここで一度、Unboundを導入することのメリット・デメリットを整理したいと思います。ローカルにUnboundを導入するメリット・サーバ障害時も、キャッシュに保存されている分はTTL内(社内サーバなら1時間)であればローカルで名前解決ができる。・DNSサーバを冗長化しておいた場合に、1台のみの障害であればresolv.confに列記するだけの場合よりもパフォーマンスへの影響を小さくできる。・ローカルのネットワーク流量やDNSサーバの負荷を抑制できる。・ローカルで名前解決ができることによるパフォーマンス向上が期待できる。・サーバ負荷軽減やパフォーマンス向上については、名前解決の問い合わせが少ないサーバや、新しい名前解決が多いサーバの場合には、効果が小さい。・TTL内での名前解決が多く発生し、キャッシュにより問い合わせが大きく減らせる・DNS障害時のタイムラグがサービスのパフォーマンスに影響を与えることが想定できるなど、Unbound導入によるメリットが大きいサーバから順に導入していくことになりました。導入・運用のコストについては、AnsibleやFabricといった自動化ツールを導入することである程度カバーできると考えています。