gdnsdでかんたんGSLB(その2)

gdnsdでググると本稿がヒットするようになってほくほくしてますｗ

どなたかのお役にたてれば幸いです！

前回、GSLBのオープンソース実装であるgdnsdのインストールから最小構成での動作確認までを解説しました。

→ gdnsdでかんたんGSLB(その1)

今回は重み付け応答を行う設定、各種ヘルスチェック方式に変更する設定を紹介します。

重み付け応答を行う

サイト間で処理能力に差がある場合など、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を使ってます。もし次回頑張れたら、細かいオプションの説明とか、商用で使うにあたって気をつけた方がいい点とかを紹介しようと思います。

→ gdnsdでかんたんGSLB(その3)

皆さま、快適なGSLBライフを！