gdnsdでググると本稿がヒットするようになってほくほくしてますｗ
どなたかのお役にたてれば幸いです！
前回、GSLBのオープンソース実装であるgdnsdのインストールから最小構成での動作確認までを解説しました。
今回は重み付け応答を行う設定、各種ヘルスチェック方式に変更する設定を紹介します。
重み付け応答を行う
サイト間で処理能力に差がある場合など、GSLBのアクセス誘導比率を調整したくなります。そんな時は重み付け応答の設定で実現できます。
設定例は以下のとおり、weightedプラグインを使用するように記載します。
/etc/gdnsd/config
plugins = {
weighted = {
www = {
up_thresh = 0.00000001
service_types = http_mon
www1 = [ 153.120.ccc.ccc, 1 ]
www2 = [ 163.44.ddd.ddd, 3 ]
}
}
}
service_types = {
http_mon = {
plugin = http_status
port = 80
url_path = "/"
ok_codes = [ 200 ]
interval = 10
timeout = 5
up_thresh = 5
ok_thresh = 3
down_thresh = 2
}
}
ゾーンファイルは以下のとおり、multifoと記載していた部分をweightedに変更するのみです。
/etc/gdnsd/zones/gslb.src.sakura.ad.jp
$TTL 86400
@ SOA ns1 hostmaster (
2016030300 ; serial
7200 ; refresh
30M ; retry
3D ; expire
10 ; ncache
)
@ NS ns1
@ NS ns2
ns1 A 133.242.aaa.aaa
ns2 A 163.44.bbb.bbb
www 10 DYNA weighted!www
設定変更が終わったら、gdnsdを再起動します。
(configファイルを変更した場合は、デーモン自体の再起動が必要となります)
$ gdnsd restart
この場合、153.120.ccc.cccと163.44.ddd.dddを1:3の割合で応答することになります。
ただし、ISPサイドに設置されているDNSキャッシュサーバの状態や、そこに収容されているユーザ数によって、エンドユーザからのアクセス数が必ずしも指定した割合になるわけではありませんので、ご留意ください。
DNSレスポンスの違い
重み付け応答に変更すると、以下のように、DNSレスポンスがラウンドロビンではなく、単一レコードのみの応答となります。
multifoの場合(DNSラウンドロビン)
$ dig +short www.gslb.src.sakura.ad.jp
163.44.ddd.ddd
153.120.ccc.ccc
weightedの場合(単一のレコードのみ応答)
$ dig +short www.gslb.src.sakura.ad.jp
163.44.ddd.ddd
↑このIPアドレスが変化する
どちらかのIPアドレスが、指定した重み値の比率で返るはずです。digコマンドの参照先がDNSキャッシュサーバ経由の場合、キャッシュが消えるまで同じレコードが返りますのでご注意ください。
ヘルスチェックをTCP接続にする
先の設定では、HTTPによるヘルスチェックを行っていました。単純なTCP接続によるヘルスチェックに変更する場合、以下のようにservice_typesのpluginとしてtcp_connectを使用します。
/etc/gdnsd/config
plugins = {
weighted = {
www = {
up_thresh = 0.00000001
service_types = tcp_mon
www1 = [ 153.120.ccc.ccc, 1 ]
www2 = [ 163.44.ddd.ddd, 3 ]
}
}
}
service_types = {
tcp_mon = {
plugin = tcp_connect
port = 80
interval = 10
timeout = 5
up_thresh = 5
ok_thresh = 3
down_thresh = 2
}
}
ヘルスチェックをpingにする
gdnsdにはpingを行うプラグインが用意されていません。そのため、extmonという外部コマンドを実行するプラグインを使用し、pingコマンドの結果(exit status)により監視を行います。設定例は以下のとおりです。
/etc/gdnsd/config
plugins = {
weighted = {
www = {
up_thresh = 0.00000001
service_types = ping_mon
www1 = [ 153.120.ccc.ccc, 1 ]
www2 = [ 163.44.ddd.ddd, 3 ]
}
}
}
service_types = {
ping_mon = {
plugin = extmon
cmd = ["/usr/bin/ping", "-c", "3", "-W", "1", "%%ITEM%%"]
interval = 10
timeout = 5
up_thresh = 5
ok_thresh = 3
down_thresh = 2
}
}
%%ITEM%% の部分に、監視対象のIPアドレスが差し込まれます。
ヘルスチェックをhttpsにする
ping同様に、httpsを直接的に叩くプラグインもないため、curlコマンドを実行して監視を行います。設定例は以下のとおりです。
/etc/gdnsd/config
service_types = {
https_mon = {
plugin = extmon
cmd = ["/bin/sh", "-c", "/usr/bin/curl -I -o /dev/null -w '%{http_code}' -s -k -m 4 https://%%ITEM%%/ | /bin/grep ^200$"]
interval = 10
timeout = 5
up_thresh = 5
ok_thresh = 3
down_thresh = 2
}
}
curlコマンドの -w '%{http_code}' オプションにてStatus Codeを表示するようにし、grepコマンドでマッチさせることで判定しています。
※ もっと良い方法があったら教えて下さい！
余談：重み付け応答を使用しないほうがいい場合
ところで、DNSラウンドロビン応答の場合、生きているサイトのIPアドレスが全て返されます。そのため、GSLBが障害を検知して切り替わるまでの間でも、クライアント側で障害が発生したサイトへの接続が失敗することにより、正常なサイトに高速にフォールバックすることができます(Webブラウザ等アプリケーションの挙動にもよりますが)。
重み付け応答に変更した場合、1つのレコードしか応答しなくなるため、そのサイトに障害が発生した直後は、クライアント側アプリケーションでの高速なフォールバックができなくなります。
GSLBをバランシング目的でななく、主に冗長化目的で使用している場合は、重み付け応答を使用せずにDNSラウンドロビン(multifo)を使用したほうが良いでしょう。
次回に続く・・かも？
ここだけの話、某クラウドのGSLBサービスはgdnsdを使ってます。もし次回頑張れたら、細かいオプションの説明とか、商用で使うにあたって気をつけた方がいい点とかを紹介しようと思います。
皆さま、快適なGSLBライフを！