Y:A:D::I::F:A 2.2のマルチマスター機能をお試し

(検証環境イメージ)

YADIFA 2.2がリリースされました(発表)。
その中で、権威スレーブサーバーとしての新機能「マルチマスター対応」が実装されたとのことなので さっそく試してみました。

環境構成

検証環境は上記図の通りです。せっかくなので触ってみたいソフトウェアをいろいろ詰め込んでみました。

• 権威マスター: BIND 9.10.4-P2とPowerDNS 4.0.0-1p
• 権威スレーブ: YADIFA 2.2.1
• 再帰検索DNS: Knot Resolver 1.1.0

権威マスター２台の間は、ひとまず特に同期システム無しで手動入力です。

YADIFAの設定

yadifad.confを作成します。以下抜粋にて

<main>
queries-log-type 3
</main>
<zone>
        domain          yadtest.w4yh.jp
        file            slaves/yadtest.w4yh.jp.zone
        type            slave
        masters         133.18.nn.nn,153.127.nn.nn
        multimaster-retries 2
        true-multimaster false
</zone>

 

mastersの指定部分でカンマ区切りで複数のIPアドレスを列挙することでマルチマスター設定になります。
書いた順番に優先となり、最初に書いたIPアドレスのサーバーが通常のマスターとして参照します。

動作検証

1つめのmaster(133.18.nn.nn, PowerDNS)を落としてみます。(以下、引用部分はyadifaのログを示します)

| server | E | slave: query error for domain yadtest.w4yh.jp. from master at 133.18.nn.nn#53: Connection refused

今回はmultimaster-retries 2で設定しているので、最初の1回 + リトライ2回 = 3回エラーが続くと切り替わります。

| server | W | slave: 133.18.yadtest#53 master failed to answer for domain yadtest.w4yh.jp.: next master is 153.127.nn.nn#53

通常あまりないと思いますが、マスターを切り替えた結果ゾーンが更新されていた場合には、切り替えた２つ目のマスターサーバーからのゾーン転送が行われます。

| I | slave: loaded IXFR for domain yadtest.w4yh.jp. from master at 153.127.nn.nn#53, new serial is 2016081401

true-multimaster

次に、true-multimasterをtrueにします。 これは「マスターの切り替えが発生した場合には、現在のゾーン情報を破棄して切り替わり先の新しいマスターから取得しなおす」という動作を指定する設定です。前の恋人との思い出は全部捨てて新しい恋に生きます、みたいな感じ？
まず優先マスターからゾーン転送を受けておきます。

| I | slave: loaded AXFR for domain yadtest.w4yh.jp. from master at 133.18.nn.nn#53, serial is 2016081401

この後マスターを落とすのは同じくですが、切り替わり先に敢えて古いシリアルのゾーンを入れておきます。 その結果、

| W | slave: 133.18.nn.nn#53 master failed to answer for domain yadtest.w4yh.jp.: next true master is 153.127.nn.nn#53
| D | slave: deleting '/opt/yadifa/var/zones/slaves/yadtest.w4yh.jp.zone'
| D | slave: deleting '/opt/yadifa/var/zones/xfr//98/3e/yadtest.w4yh.jp..axfr'
| D | database: yadtest.w4yh.jp.: will enqueue operation DATABASE_SERVICE_QUERY_AXFR at 2016-MM-DD hh.mm.dd (10分後)
| I | slave: loaded AXFR for domain yadtest.w4yh.jp. from master at 153.127.nn.nn#53, serial is 2016080101
| I | database: yadtest.w4yh.jp.: zone successfully downloaded (AXFR)

シリアル番号は下がりますが、切り替わり先のマスターからゾーンファイルを上書き受信できました。
ちょっと意外だったのは、最初のマスターがダウンしたと判定された時点でゾーンファイルの削除が行われ、約10分間ファイルの無い状態が発生したことです。
ロードはされているのでDNSクエリへの応答はあったのですが(ダンプは見ていないので詳細は要確認)、一時的にファイルを失うというのは監視の仕方によっては厄介かもしれません。

どこで使う？

設定のmastersに並べるだけで冗長化できるという便利な設定を確認できました。この使いどころはどういうケースなのでしょうか。
masterが異なるIPアドレスで冗長されている、ということでVirtual IP addressを持った冗長を組んでいるところでは不要です。
internalセグメントにActive DirectoryのDNSが何台かいて、DMZのyadifaがslaveとして受け取る、というような場合は使えそうです。
また、yadifaの開発元であるEURidはドメイン提供～メール＆ウェブ環境の提供の一括管理をしているので、ドメイン情報は業務システムのデータベースに入っていて、そこから負荷や可用性レベルを切り離した複数のマスターサーバーがhidden(ステルス)で稼動しているのかもしれません。
WHD.glocal 2014での発表資料

余談

今回の検証環境は日割りで初期費用無しで安く利用できる国内事業者さんを探して、Kagoya VPSを利用しました。個人で検証用にいい環境が他にもあれば情報いただきたいです。
せっかく一式の環境を作ったので、DNSおよびその監視についてもうちょっと検証を行う予定です。お題などありましたらツイッターコメントやTXTレコードでお知らせいただければ、余裕あればやってみます。