ニフクラ ブログ

ニフクラ/FJ Cloud-Vやクラウドの技術について、エンジニアが語るブログです。

ニフクラDNSを利用してリージョンを跨いだDR構築を試してみる

こんにちは、ニフクラテクニカルアカウントチームの新人の水村です。
 東日本大震災以降、災害などからのシステムの復旧および有事に備えるための「Disaster Recovery (DR)」は多くの企業で検討される課題となっております。今回は、ニフクラの東西それぞれのリージョンにおいて一般的なWEB-DBシステムを作成し、DNSを用いたウォームスタンバイのDR構成を構築し、検証を行いました。
最終的には図1のような構成としました。

f:id:TechnicalAccountEngineer:20180912112623p:plain
図1, 構成全体図

はじめに

 地震・津波・火事といった天災が原因でシステムやサーバー・データセンターがダメージを被った場合に備えて、「DR」が注目されております。
 ニフクラでは、お客様のオンプレミス環境からニフクラ上にバックアップを構築する「DRサービス for NetApp」や「バックアップ/DRサービス for VMware vSphere®」などのDRサービスを提供しております。
今回は、ニフクラの別リージョンにDB同期を行ったDR環境を構築し、DNSフェイルフェイルオーバー機能で障害時のリージョン切り替えなどをチェックしてみました。

※今回の検証ではOS以上のレイヤーについても触れていますが、ニフクラではOS以上は利用者の責任で実装する範囲となります。実装を検討される場合は、慎重な検討/検証、入念な設計等をお願いします。
※DR環境を構築する詳細な手順等には今回は触れていません。構成検討の際の参考となるような記事となっています。

前提条件

本ブログは、以下の前提知識がある方を想定しています。

  • ニフクラの基本的なコントロールパネルの操作、サービスを利用する知識
    (サーバー作成、ネットワーク構築など)
  • 基本的なサーバーOSを構築する知識
  • DNSの基礎的な知識

利用リソース

今回の検証を実施するにあたり、利用したニフクラのリソース情報に関して以下に記載します。
※ 各リソースのアクセス制限に関しては、ニフクラのファイアウォール等を用いて適切に設定を行った上で実施しています。

ニフクラ利用リソース

サービス 数量
仮想サーバー 4
DNS(レコード管理) 1
DNS(オプション:フェイルオーバーレコード) 2
拠点間VPNゲートウェイ 2
ファイアウォール 4
プライベートLAN 2

仮想サーバー

名前 OS グローバルNIC プライベートNIC 備考
WEBEast CentOS 7.5.1804 LANEast Web, AP サーバー用途
DBEast CentOS 7.5.1804 LANEast DB サーバー用途
WEBWest CentOS 7.5.1804 LANWest Web, AP サーバー用途
DBWest CentOS 7.5.1804 LANWest DB サーバー用途

プライベートLAN

名前 CIDR 備考
LANEast 192.168.0.0/24 Web->DB通信用およびVPNGW接続用
LANWest 192.168.100.0/24 Web->DB通信用およびVPNGW接続用

拠点間VPNゲートウェイ

 相互に IPsec (IKEv2, AES256, SHA1) で接続しています

名前 所属ネットワーク 対向CIDR
VPNEast LANEast 192.168.100.0/24
VPNWest LANWest 192.168.0.0/24

DNSフェイルオーバー

レコード名 対応サーバー名 フェイルオーバー設定 TTL
test.example.com WebEast プライマリ 60
test.example.com WebWest セカンダリ 60

※test.example.com は実際に取得したレコード名とは異なります

環境構築

手順

  1. ニフクラの左メニューから「DNSゾーン管理」を選択する。レコードを設定するDNSゾーン名を選択するとレコード一覧画面が開くので、左上の「レコード新規作成」をクリックします。f:id:TechnicalAccountEngineer:20180910154356p:plain

  2. 登録したいレコードのタイプを選択します。今回はAレコードを選択します。 f:id:TechnicalAccountEngineer:20180910154427p:plain

  3. レコード登録の基本設定画面が現れます。各欄に情報を入れた後、一番下の「ポリシー」タブを選択して「フェイルオーバー」を選択します。 f:id:TechnicalAccountEngineer:20180910154440p:plain

  4. 「フェイルオーバー」タブにて「プライマリ」or「セカンダリ」を選択します。
    プライマリはゾーン内に1つしか存在できませんが、DNSを介する通信は常にプライマリに対して行われます。セカンダリはゾーン内に複数存在できますが、プライマリがダウンしている時のみ通信が振り分けられます。今回はプライマリでレコードを作成します。
    ※グローバルIPアドレスはXXX.XXX.XXX.XXXとマスクしています。
    f:id:TechnicalAccountEngineer:20180912131705p:plain

  5. この手順を踏むと以下のようにレコードが1つ作成されます。 f:id:TechnicalAccountEngineer:20180912131715p:plain

  6. 同様の手順を踏んで「ポリシー」がフェイルオーバー, 「フェイルオーバー」がセカンダリのレコードを作成します。

検証方法・結果

 今回行った2つの検証の内容と手順、その結果について記載いたします。

障害時における本番から予備環境への切り替わり時間の検証

 災害時にユーザーのアクセスを自動的に切り替えるには、DNSのフェイルオーバー機能を使用します。本番環境のサーバーが停止しても、DNSがヘルスチェックを行っているため、その結果に応じて応答するレコードをセカンダリに切り替わります。ヘルスチェックはHTTPS/HTTP/TCPと3種類から選択できます。 本項ではHTTPによるヘルスチェックを用いて、本番環境から予備環境へ切り替わるまでの時間について検証を行いまます。

検証手法

 検証は図2にて示す作業手順をshell scriptにて実装して実行しました。

f:id:TechnicalAccountEngineer:20180913172237p:plain
図2, 検証手法の概要図

  1. WebWestからsshコマンドを用いてWebEastのApache2を停止させます。

  2. その後、WebWestはDNSに対してtest.example.comの名前解決を1秒毎に行います。
    ニフクラ上のサーバはunboundを用いて自身で再起問い合わせを行いますが、本検証ではDNSレコードの切り替わり時刻を正確に計測したいため、unboundのキャッシュを削除した上で名前解決を行います。

  3. 名前解決にセカンダリのレコードが返ってきた場合、scriptは所要時間を表示し動作を終えます。
    プライマリが返ってきた場合は、WebEastへの死活監視がまだ行われていない状態であるため、名前解決を繰り返します。

 上記手順に従い、WebEastのhttpd.serviceが停止してさせてからDNSがセカンダリのレコードを返すようになるまでの時間を秒単位で計測しました。図3に示すものが実際の実行画面となります。

f:id:TechnicalAccountEngineer:20180910173436p:plain
図3, 実行画面

検証結果

 上記方法による検証結果が図4となります。

f:id:TechnicalAccountEngineer:20180910164809p:plain
図4, 予備環境への切り替わり時間の検証結果
 本環境では待ち時間の頻度がおよそ121秒~180秒のパターンが比較的多く現れました。また、最小値は4秒、最大値は296秒となりました。ではなぜこのような結果となったのか、仕様面から考えて見たいと思います。

DNSの仕様について

 本項では、ニフクラDNSのフェイルオーバーの仕様について公開情報をまとめます。ここでの内容は以下のサイトを参照して作成しております。

ヘルスチェックとレコード切り替えのフロー

 図5のようにヘルスチェックは動作します。

f:id:TechnicalAccountEngineer:20180913182149p:plain
図5. ヘルスチェックの動作図解

 ヘルスチェックは5分毎にプライマリサーバーに対して行われます。そのチェックでサーバーが正常に動いていればプライマリのレコードを、サーバーが異常であれば予備環境のセカンダリレコードを返します。
 この仕様に従うと、ニフクラDNSがセカンダリのレコードを返すまでに要する時間は数秒~5分であることが分かります(図6)。 したがって、図5が示すとおりDNSのレコード切り替えは300秒以内に行われることが分かります。

f:id:TechnicalAccountEngineer:20180913191344p:plain
図6, ニフクラDNSのレコードが切り替わりるまでに要する時間

さらに、ユーザーアクセスがセカンダリに変わるまでに要する時間はおよそ60秒~24時間5分であることが分かります(図7)。 ただし、最大値の24時間というはレコードのTTLを意図的に最大値(24時間)に指定した場合であり、デフォルトでは60秒です。したがって、大半のユーザーは最大6分待つことでセカンダリレコードより予備環境へアクセスできるようになります。

f:id:TechnicalAccountEngineer:20180918170500p:plain
図7, ユーザーアクセスが切り替わるまでに要する時間
※ただし、ユーザーが意図的にルートDNSに対して名前解決を行なった場合の最小時間は60秒ではなく数秒で切り替わることを確認できます。

注意点

 ニフクラDNSのヘルスチェックを利用する際の注意点として、DNSから各サーバーに対して行うヘルスチェックを、サーバーに設定されたファイアウォールルールで許可する必要があります。(図8)

f:id:TechnicalAccountEngineer:20180914142213p:plain
図8, ファイアウォールによってDNSヘルスチェックが落ちている図
本ルールを設定していない場合、プライマリに設定したWebEastではなくセカンダリのWebWestに繋がり続けるという、意図しない挙動が発生します。この問題の回避するためには、ヘルスチェックが行われるサーバーすべてのファイアウォールに対して80番ポートへのアクセスをすべて許可すれば解決されます。しかし、ファイアウォールで許可された接続元からのみのアクセスに絞りたいと言った場合に、上記では対応できません。そういった要件が予めわかっている場合は、お手数ですが、弊社窓口へお問い合わせください。

まとめ

 今回の調査によってDNSフェイルオーバーを利用した東西リージョンにおけるDR構築を作成し、本番環境から予備環境への切り替え時間やニフクラDNSの仕様についてご紹介いたしました。ニフクラDNS単体の場合、別リージョンへの切り替えが最大6分要します(TTL60秒設定)。当然、他のアプリケーションや、DB同期方法によりトータル切り替え時間は変動してくるものと思いますが、本記事によりニフクラDNSを利用したDR構築時のご参考になれば幸いです。
※本記事については検証結果の1つであり、実際のシステムの場合には、事前にそれぞれの要件を鑑みて実装するか検討してください。また、実装される際には要件を満たせるか十分に検証を行っていただくようお願いします。