FJcloud実践
FJcloud-V DNSフェイルオーバー機能を用いたDR構築検証
この記事は、ニフクラブログで2018-09-19に公開された記事を移転したものです。
こんにちは、ニフクラテクニカルアカウントチームの新人の水村です。
東日本大震災以降、災害などからのシステムの復旧および有事に備えるための「Disaster Recovery (DR)」は多くの企業で検討される課題となっております。今回は、ニフクラの東西それぞれのリージョンにおいて一般的なWEB-DBシステムを作成し、DNSを用いたウォームスタンバイのDR構成を構築し、検証を行いました。
最終的には図1のような構成としました。
はじめに
地震・津波・火事といった天災が原因でシステムやサーバー・データセンターがダメージを被った場合に備えて、「DR」が注目されております。
今回は、ニフクラの別リージョンにDB同期を行ったDR環境を構築し、DNSフェイルフェイルオーバー機能で障害時のリージョン切り替えなどをチェックしてみました。
※今回の検証ではOS以上のレイヤーについても触れていますが、ニフクラではOS以上は利用者の責任で実装する範囲となります。実装を検討される場合は、慎重な検討/検証、入念な設計等をお願いします。
※DR環境を構築する詳細な手順等には今回は触れていません。構成検討の際の参考となるような記事となっています。
前提条件
本ブログは、以下の前提知識がある方を想定しています。
- ニフクラの基本的なコントロールパネルの操作、サービスを利用する知識
(サーバー作成、ネットワーク構築など) - 基本的なサーバーOSを構築する知識
- DNSの基礎的な知識
利用リソース
今回の検証を実施するにあたり、利用したニフクラのリソース情報に関して以下に記載します。
※ 各リソースのアクセス制限に関しては、ニフクラのファイアウォール等を用いて適切に設定を行った上で実施しています。
ニフクラ利用リソース
仮想サーバー
| 名前 | 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 は実際に取得したレコード名とは異なります
環境構築
- WEBサーバー
Apache と Tomcat を用いて構築しました。ECサイトを模した作りとなっております。 - DBサーバー
PostgreSQL を用いて構築しました。本DBでは100MB相当のデータを保持しています。 - 拠点間VPNゲートウェイ
以下のサイトを参照して作成しました。
加えて、各ホストに対向NWへのstatic routeを設定する必要があります。
IPsec VPN（L3VPN）で東西リージョンのプライベートLANを接続する方法 - DBレプリケーション
East-West間で一定時間毎に同期を行う仕組みを構築しています。 - ドメイン取得
以下のサイトを参照して作成しました。
https://pfs.nifcloud.com/guide/dns/domain_new.htm
FJcloud-Vでドメイン名の取得とDNSを設定する方法 - DNSフェイルオーバーの設定
DNSレコードの作成については以下のリンクを参考にしました。
https://pfs.nifcloud.com/guide/dns/zone_record.htm
リンク先ではDNSフェイルオーバーの設定については触れられていないため以下の手順にて補足させて頂きます。
手順
- 1. ニフクラの左メニューから「DNSゾーン管理」を選択する。レコードを設定するDNSゾーン名を選択するとレコード一覧画面が開くので、左上の「レコード新規作成」をクリックします。
- 2. 登録したいレコードのタイプを選択します。今回はAレコードを選択します。
- 3. レコード登録の基本設定画面が現れます。各欄に情報を入れた後、一番下の「ポリシー」タブを選択して「フェイルオーバー」を選択します。
- 4. 「フェイルオーバー」タブにて「プライマリ」or「セカンダリ」を選択します。
プライマリはゾーン内に1つしか存在できませんが、DNSを介する通信は常にプライマリに対して行われます。セカンダリはゾーン内に複数存在できますが、プライマリがダウンしている時のみ通信が振り分けられます。今回はプライマリでレコードを作成します。
※グローバルIPアドレスはXXX.XXX.XXX.XXXとマスクしています。 - 5. この手順を踏むと以下のようにレコードが1つ作成されます。
- 6. 同様の手順を踏んで「ポリシー」がフェイルオーバー, 「フェイルオーバー」がセカンダリのレコードを作成します。
検証方法・結果
今回行った2つの検証の内容と手順、その結果について記載いたします。
障害時における本番から予備環境への切り替わり時間の検証
災害時にユーザーのアクセスを自動的に切り替えるには、DNSのフェイルオーバー機能を使用します。本番環境のサーバーが停止しても、DNSがヘルスチェックを行っているため、その結果に応じて応答するレコードをセカンダリに切り替わります。ヘルスチェックはHTTPS/HTTP/TCPと3種類から選択できます。 本項ではHTTPによるヘルスチェックを用いて、本番環境から予備環境へ切り替わるまでの時間について検証を行いまます。
検証手法
検証は図2にて示す作業手順をshell scriptにて実装して実行しました。
- 1. WebWestからsshコマンドを用いてWebEastのApache2を停止させます。
- 2. その後、WebWestはDNSに対してtest.example.comの名前解決を1秒毎に行います。
ニフクラ上のサーバはunboundを用いて自身で再起問い合わせを行いますが、本検証ではDNSレコードの切り替わり時刻を正確に計測したいため、unboundのキャッシュを削除した上で名前解決を行います。 - 3. 名前解決にセカンダリのレコードが返ってきた場合、scriptは所要時間を表示し動作を終えます。
プライマリが返ってきた場合は、WebEastへの死活監視がまだ行われていない状態であるため、名前解決を繰り返します。
上記手順に従い、WebEastのhttpd.serviceが停止してさせてからDNSがセカンダリのレコードを返すようになるまでの時間を秒単位で計測しました。図3に示すものが実際の実行画面となります。
検証結果
上記方法による検証結果が図4となります。
本環境では待ち時間の頻度がおよそ121秒\~180秒のパターンが比較的多く現れました。また、最小値は4秒、最大値は296秒となりました。ではなぜこのような結果となったのか、仕様面から考えて見たいと思います。
DNSの仕様について
本項では、ニフクラDNSのフェイルオーバーの仕様について公開情報をまとめます。ここでの内容は以下のサイトを参照して作成しております。
ヘルスチェックとレコード切り替えのフロー
図5のようにヘルスチェックは動作します。
ヘルスチェックは5分毎にプライマリサーバーに対して行われます。そのチェックでサーバーが正常に動いていればプライマリのレコードを、サーバーが異常であれば予備環境のセカンダリレコードを返します。
この仕様に従うと、ニフクラDNSがセカンダリのレコードを返すまでに要する時間は数秒\~5分であることが分かります(図6)。 したがって、図5が示すとおりDNSのレコード切り替えは300秒以内に行われることが分かります。
さらに、ユーザーアクセスがセカンダリに変わるまでに要する時間はおよそ60秒\~24時間5分であることが分かります(図7)。 ただし、最大値の24時間というはレコードのTTLを意図的に最大値（24時間）に指定した場合であり、デフォルトでは60秒です。したがって、大半のユーザーは最大6分待つことでセカンダリレコードより予備環境へアクセスできるようになります。
※ただし、ユーザーが意図的にルートDNSに対して名前解決を行なった場合の最小時間は60秒ではなく数秒で切り替わることを確認できます。
注意点
ニフクラDNSのヘルスチェックを利用する際の注意点として、DNSから各サーバーに対して行うヘルスチェックを、サーバーに設定されたファイアウォールルールで許可する必要があります。(図8)
本ルールを設定していない場合、プライマリに設定したWebEastではなくセカンダリのWebWestに繋がり続けるという、意図しない挙動が発生します。この問題の回避するためには、ヘルスチェックが行われるサーバーすべてのファイアウォールに対して80番ポートへのアクセスをすべて許可すれば解決されます。しかし、ファイアウォールで許可された接続元からのみのアクセスに絞りたいと言った場合に、上記では対応できません。そういった要件が予めわかっている場合は、お手数ですが、弊社窓口へお問い合わせください。
まとめ
今回の調査によってDNSフェイルオーバーを利用した東西リージョンにおけるDR構築を作成し、本番環境から予備環境への切り替え時間やニフクラDNSの仕様についてご紹介いたしました。ニフクラDNS単体の場合、別リージョンへの切り替えが最大6分要します（TTL60秒設定）。当然、他のアプリケーションや、DB同期方法によりトータル切り替え時間は変動してくるものと思いますが、本記事によりニフクラDNSを利用したDR構築時のご参考になれば幸いです。
※本記事については検証結果の１つであり、実際のシステムの場合には、事前にそれぞれの要件を鑑みて実装するか検討してください。また、実装される際には要件を満たせるか十分に検証を行っていただくようお願いします。
本記事は過去に公開した記事を移行したものであり、公開時点の情報に準拠しております。リンク切れの際はご容赦ください。
