ブログニフクラやクラウドの技術について、エンジニアが語るブログです。ブログニフクラやクラウドの技術について、エンジニアが語るブログです。(DR)」は多くの企業で検討される課題となっております。今回は、ニフクラの東西それぞれのリージョンにおいて一般的なWEB-DBシステムを作成し、DNSを用いたウォームスタンバイのDR構成を構築し、検証を行いました。最終的には図1のような構成としました。注意点まとめはじめに地震・津波・火事といった天災が原因でシステムやサーバー・データセンターがダメージを被った場合に備えて、「DR」が注目されております。vSphere®」などのDRサービスを提供しております。今回は、ニフクラの別リージョンにDB同期を行ったDR環境を構築し、DNSフェイルフェイルオーバー機能で障害時のリージョン切り替えなどをチェックしてみました。※今回の検証ではOS以上のレイヤーについても触れていますが、ニフクラではOS以上は利用者の責任で実装する範囲となります。実装を検討される場合は、慎重な検討/検証、入念な設計等をお願いします。※DR環境を構築する詳細な手順等には今回は触れていません。構成検討の際の参考となるような記事となっています。本ブログは、以下の前提知識がある方を想定しています。利用リソース今回の検証を実施するにあたり、利用したニフクラのリソース情報に関して以下に記載します。各リソースのアクセス制限に関しては、ニフクラのファイアウォール等を用いて適切に設定を行った上で実施しています。ECサイトを模した作りとなっております。本DBでは100MB相当のデータを保持しています。拠点間VPNゲートウェイ以下のサイトを参照して作成しました。routeを設定する必要があります。ブログDBレプリケーションEast-West間で一定時間毎に同期を行う仕組みを構築しています。以下のサイトを参照して作成しました。ブログDNSフェイルオーバーの設定DNSレコードの作成については以下のリンクを参考にしました。ニフクラリンク先ではDNSフェイルオーバーの設定については触れられていないため以下の手順にて補足させて頂きます。手順ニフクラの左メニューから「DNSゾーン管理」を選択する。レコードを設定するDNSゾーン名を選択するとレコード一覧画面が開くので、左上の「レコード新規作成」をクリックします。登録したいレコードのタイプを選択します。今回はAレコードを選択します。レコード登録の基本設定画面が現れます。各欄に情報を入れた後、一番下の「ポリシー」タブを選択して「フェイルオーバー」を選択します。「フェイルオーバー」タブにて「プライマリ」or「セカンダリ」を選択します。プライマリはゾーン内に1つしか存在できませんが、DNSを介する通信は常にプライマリに対して行われます。セカンダリはゾーン内に複数存在できますが、プライマリがダウンしている時のみ通信が振り分けられます。今回はプライマリでレコードを作成します。※グローバルIPアドレスはXXX.XXX.XXX.XXXとマスクしています。この手順を踏むと以下のようにレコードが1つ作成されます。った2つの検証の内容と手順、その結果について記載いたします。災害時にユーザーのアクセスを自動的に切り替えるには、DNSのフェイルオーバー機能を使用します。本番環境のサーバーが停止しても、DNSがヘルスチェックを行っているため、その結果に応じて応答するレコードをセカンダリに切り替わります。ヘルスチェックはHTTPS/HTTP/TCPと3種類から選択できます。本項ではHTTPによるヘルスチェックを用いて、本番環境から予備環境へ切り替わるまでの時間について検証を行いまます。scriptにて実装して実行しました。検証手法の概要図WebWestからsshコマンドを用いてWebEastのApache2を停止させます。その後、WebWestはDNSに対してtest.example.comの名前解決を1秒毎に行います。ニフクラ上のサーバはunboundを用いて自身で再起問い合わせを行いますが、本検証ではDNSレコードの切り替わり時刻を正確に計測したいため、unboundのキャッシュを削除した上で名前解決を行います。名前解決にセカンダリのレコードが返ってきた場合、scriptは所要時間を表示し動作を終えます。プライマリが返ってきた場合は、WebEastへの死活監視がまだ行われていない状態であるため、名前解決を繰り返します。上記手順に従い、WebEastのhttpd.serviceが停止してさせてからDNSがセカンダリのレコードを返すようになるまでの時間を秒単位で計測しました。図3に示すものが実際の実行画面となります。よる検証結果が図4となります。本環境では待ち時間の頻度がおよそ121秒~180秒のパターンが比較的多く現れました。最小値は4秒、最大値は296秒となりました。このような結果となったのか、仕様面から考えて見たいと思います。DNSの仕様について本項では、ニフクラDNSのフェイルオーバーの仕様について公開情報をまとめます。ここでの内容は以下のサイトを参照して作成しております。図5のようにヘルスチェックは動作します。ヘルスチェックの動作図解ヘルスチェックは5分毎にプライマリサーバーに対して行われます。そのチェックでサーバーが正常に動いていればプライマリのレコードを、サーバーが異常であれば予備環境のセカンダリレコードを返します。この仕様に従うと、ニフクラDNSがセカンダリのレコードを返すまでに要する時間は数秒~5分であることが分かります(図6)。したがって、図5が示すとおりDNSのレコード切り替えは300秒以内に行われることが分かります。ニフクラDNSのレコードが切り替わりるまでに要する時間さらに、ユーザーアクセスがセカンダリに変わるまでに要する時間はおよそ60秒~24時間5分であることが分かります(図7)。最大値の24時間というはレコードのTTLを意図的に最大値(24時間)に指定した場合であり、デフォルトでは60秒です。したがって、大半のユーザーは最大6分待つことでセカンダリレコードより予備環境へアクセスできるようになります。※ただし、ユーザーが意図的にルートDNSに対して名前解決を行なった場合の最小時間は60秒ではなく数秒で切り替わることを確認できます。注意点ニフクラDNSのヘルスチェックを利用する際の注意点として、DNSから各サーバーに対して行うヘルスチェックを、サーバーに設定されたファイアウォールルールで許可する必要があります。本ルールを設定していない場合、プライマリに設定したWebEastではなくセカンダリのWebWestに繋がり続けるという、意図しない挙動が発生します。この問題の回避するためには、ヘルスチェックが行われるサーバーすべてのファイアウォールに対して80番ポートへのアクセスをすべて許可すれば解決されます。ファイアウォールで許可された接続元からのみのアクセスに絞りたいと言った場合に、上記では対応できません。いった要件が予めわかっている場合は、お手数ですが、弊社窓口へお問い合わせください。まとめ今回の調査によってDNSフェイルオーバーを利用した東西リージョンにおけるDR構築を作成し、本番環境から予備環境への切り替え時間やニフクラDNSの仕様についてご紹介いたしました。ニフクラDNS単体の場合、別リージョンへの切り替えが最大6分要します(TTL60秒設定)。他のアプリケーションや、DB同期方法によりトータル切り替え時間は変動してくるものと思いますが、本記事によりニフクラDNSを利用したDR構築時のご参考になれば幸いです。※本記事については検証結果の1つであり、実際のシステムの場合には、事前にそれぞれの要件を鑑みて実装するか検討してください。実装される際には要件を満たせるか十分に検証を行っていただくようお願いします。Gatewayを使用したWindowsサーバーへのリモートデスクトップ接続の手順こんにちは、ニフクラテクニカルアカウントチームです。Window...2019-07-10ニフクラのインターネットVPN機能に関するまとめ(前編:拠点間VPNゲートウェイ)こんにちは、富士通クラウドテクノロジーズの鮫島です。ミートアップ「クラウドのネットワークやルーターでハマりがち...こんにちは。公開しました!(リモートアクセスVP...こんにちは!富士通クラウドテクノロジーズの蓮沼です。本日(...2019-04-03リージョンをまたいだWSUSの階層化(チェーン化)構成を検証してみたこんにちは、ニフクラテクニカルアカウントチームです。»プロフィールニフクラとは、VMwareを基盤とした国産のパブリック型クラウドサービスです。LIMITEDスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。