GSLBアプライアンス製品って買うとめっちゃ高くないですか？

そんなに高かったら、月額数百円から運用出来てしまうAmazon Route 53やさくらのクラウドGSLB(税抜500円/月)、GMO ConoHA GeoDNS(税抜500円/月)を使っちゃいますよね！！

でも、自前で安価にGSLBを運用したいという方もいらっしゃると思います。

そんなあなたに、gdnsdというオープンソースのGSLBがありますよ！

そもそもGSLBとは？

GSLBはGlobal Server Load Balancingの略で、広域負荷分散と日本語訳されることがあります。地理的に離れた複数のサイトに負荷を分散したり、障害時にサイト単位のフェイルオーバを行ったりする場合に利用されます。

地理的に離れている(＝エンドポイントIPアドレスをサイト間で引き継げない)ような状況で使用されるため、DNSの仕組みを用いたアクセス誘導が行われます。具体的にはGSLB自身がDNS権威サーバとして動作し、DNSクエリに対するレスポンスIPアドレスを変化させることでこれを実現しています。

※ 逆に、エンドポイントIPアドレスが変化しない負荷分散・フェイルオーバを実現するのが通常のロードバランサです(GSLBに対比してローカルロードバランサと呼んだりします)。

GSLBの中枢機能は以下のたった2つです！

誘導先サーバのヘルスチェック(もしくはメトリック取得)
DNSサーバとして、DNSクエリに対するダイナミックなレスポンス
ヘルスチェックの結果や、クエリ元の地理的な場所(Geolocation)をメトリックとして考慮します

ぶっちゃけ、これくらいだったら自前で実装できそうな気もしますよね？

実際にGMOさんは、ZabbixとOpenStack Designate(PowerDNS)を使って自前実装されているそうです。

gdnsdとは？

自前でGSLB作っちゃってもいいですが、gdnsdを使うと上記2つの機能を単一のデーモンで実現できます。構成上非常にすっきりして運用上も楽です。

gdnsdのWebサイトは以下にあります。
http://gdnsd.org/

各種方式のヘルスチェック、単純なフェイルオーバや重み付けDNS応答といった基本的なGSLBの機能はもちろんのこと、Geolocation情報を元にしたDNS応答にも対応しており、非常に高機能なソフトウェアです。

今回のテスト環境

今回は以下のように、さくらのクラウドとGMO ConoHa上に、gdnsdとWebサーバを用意しました。

設定パラメータをまとめると以下のとおりです。

パラメータ	値	備考
権威を持つゾーン名	gslb.src.sakura.ad.jp	上位ゾーン名は src.sakura.ad.jp
GSLB対象FQDN	www.gslb.src.sakura.ad.jp
GSLBサーバ(gdnsd) #1	ns1.gslb.src.sakura.ad.jp 133.242.aaa.aaa	さくらのクラウド石狩
GSLBサーバ(gdnsd) #2	ns2.gslb.src.sakura.ad.jp 163.44.bbb.bbb	GMO ConoHaシンガポール
Webサーバ #1	153.120.ccc.ccc	さくらのクラウド石狩
Webサーバ #2	163.44.ddd.ddd	GMO ConoHaシンガポール

Step1. gdnsdのインストール

gdnsdはソースをコンパイルしてインストールします。CentOS6系ではうまくコンパイルできず、CentOS7.2を使用しました。

まず、コンパイルに必要なパッケージをインストールします。

$ yum install libev-devel libtool
$ yum localinstall http://netix.dl.sourceforge.net/project/kenzy/special/C7/x86_64/ragel-6.8-3.el7.centos.x86_64.rpm

gdnsdのソースコードを取得し、展開します。

$ wget https://github.com/gdnsd/gdnsd/archive/v2.1.3.tar.gz
$ tar xvfz v2.1.3.tar.gz

コンパイルしてインストールします。

$ cd gdnsd-2.1.3
$ libtoolize
$ aclocal
$ autoheader
$ automake -a -c
$ autoconf
$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
$ make
$ make install
$ useradd -s /sbin/nologin -r -d /usr/var/run/gdnsd gdnsd

Step2. 設定ファイルを作成

以下の2つのファイルを作成します。

/etc/gdnsd/config

plugins = {
  multifo = {
      www = {
        up_thresh = 0.00000001
        service_types = http_mon
        www1 = 153.120.ccc.ccc
        www2 = 163.44.ddd.ddd
      }
  }
}

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
  }
}

/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    multifo!www

/etc/gdnsd/configには応答方式(multifo)とヘルスチェック方式を定義しています。

ゾーンファイル(gslb.src.sakura.ad.jp)は、BINDなどと同じなのでAAAAやCNAMEなど他のレコードも普通に書けます。DYNAを指定したレコードは特殊で、configファイルの定義に従いダイナミックなレスポンスを行います。DNSの変更がなるべく早く反映されるよう、TTLは短めの10秒に設定しています。

Step3. gdnsdを起動し動作確認

gdnsdを起動します。

$ /usr/sbin/gdnsd start

これで、ヘルスチェックとDNSサーバとしてのレスポンスが開始されます。ヘルスチェックの状態は、gdnsdの動作しているサーバの3506番ポートにブラウザで接続することで確認可能です。

以下のような画面が表示されると思います。

DNSレスポンスの動作確認をしてみます。上位ゾーンから正しく委譲されていれば世界中からDNS引けるはずです。

両方の実サーバが正常稼働している場合：

$ dig +short www.gslb.src.sakura.ad.jp
163.44.ddd.ddd
153.120.ccc.ccc

片方(153.120.ccc.ccc)がダウンした場合：

$ dig +short www.gslb.src.sakura.ad.jp
163.44.ddd.ddd

うまく外れてますね。ステータス画面でもダウンを検出していることが確認できます。

GSLB化したFQDNでのWebアクセスも、切り替わっていることを確認できるかと思います。
http://www.gslb.src.sakura.ad.jp/

次回に続く

今回は基本的な設定のみを紹介しました。次回は各種ヘルスチェック方式や重み付け応答の設定を紹介したいと思います。

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

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