概要
Consul の v0.3.0 から、DNS インターフェースの問い合わせに対して TTL ( Time To Live ) の指定が出来るようになりました。
以下、TTL 設定方法および検証方法です。
Consul で TTL 設定を行う目的
Consul ノードやサービスの問い合わせ時に、DNS キャッシュを持たせることができるようになりました。従来、Consul の DNS インターフェースに対する問い合わせには、TTL がありませんでした。そのため、問い合わせ毎に、都度 Consul に対するアクセスが発生し、システムに対する負荷や、トラフィックが増えるという課題がありました。
そこで、Consul は DNS インターフェースに対する問い合わせがあった場合に、TTL 値を返すことができます。DNS クライアントは TTL が切れるまで問い合わせを行わないため、余分なトラフィックが発生しません。デフォルト値は、これまでどおりの TTL=0 であり、キャッシュしません。
一方、TTL が有効になることで、DNS を通した障害検出・サービス検知が遅れる懸念もあります。その場合でも、BIND 等の DNS サーバを通さず、直接 Consul の DNS ポート（標準は 8600）を参照すると、随時最新の情報を確認できます。一般的なクライアントは通常通り DNS を通して、クリティカルな運用が必要な場合は、直接 Consul に問い合わせるという使い分けが出来ます。
なお、Consul 自信に対する DNS 問い合わせのトラフィックや負荷を分散するための方法として、v.0.3.0 からは Consul ノードもクエリの応答ができる Stale 読み込みが実装されていますが、本稿では割愛します。
設定および検証方法
httpd サービスの検出に TTL を用いてみます。httpd (Apache) が停止しても、即座に反映して Consul のサービスから消えるのではなく、TTL の期間は、情報が DNS 上で保持されることを確認します。
なお、事前準備として、BIND の設定も行います。これは、DNS の問い合わせは Consul のポートに対して直接行えないので（TTLを指定しても無効になるため；バグ？仕様？）、BIND の IP Forwarding を使った設定を有効にしておきます。
- 関連 ... Consul の TTL 反映を確認するためには、BIND が楽
Cosul 側では、JSON ファイルで指定を行います。Consul 起動時、-config-dir=/etc/consul.d/ のように指定し、中で dns_config.json を作成します。以下の例は、Consul のサイトのサンプルに手を加えたものです。
{
"dns_config": {
"service_ttl": {
"*": "5s",
"web": "30s"
}
"allow_stale": false ,
"max_stale": "5s",
}
}
ここでは、webという名前の Consul 上のサービスに対して 30s(秒)の TTL を設定し、それ以外のサービスは 5s を指定します。ファイル設置後は、Consul を再起動して、設定を有効化します。
次に dig で問い合わせます。
$ dig web.service.sakura.consul
(略)
;; QUESTION SECTION:
;web.service.sakura.consul. IN A
;; ANSWER SECTION:
web.service.sakura.consul. 30 IN A 192.168.39.13
web.service.sakura.consul. 30 IN A 192.168.39.11
初回はこのように、TTL 値は 30 秒と分かります。
少し時間をおいて再度問い合わせると
;; ANSWER SECTION:
web.service.sakura.consul. 21 IN A 192.168.39.11
web.service.sakura.consul. 21 IN A 192.168.39.13
TTL が 21 秒まで減少しています。
この状態で、片方の Apache を停止します。Consul 上では、10 秒間隔でサービス監視しているので、Fail を検出していますが、DNS 上は TTL が 0 秒にカウントするまで、両方のサーバが見え続けます。
30秒経過すると、
;; ANSWER SECTION:
web.service.sakura.consul. 30 IN A 192.168.39.11
このように一台しか見えなくなります。
その後、Apache を起動しなおすと、ただちに Consul 上ではノードが検出され、再び dig を行うと、両方のサーバの存在が確認できるようになります。
参考
- DNS Caching - Consul