Azure DNS での信頼性

この記事では、Azure DNS でのリージョン間のディザスター リカバリーと事業継続のサポートについて詳しく説明します。

リージョン間のディザスター リカバリーおよび事業継続

ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。

DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、ワークロードに適したディザスター リカバリー計画をお客様が設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。

ディザスター リカバリーのための Azure DNS フェールオーバー ソリューションでは、DNS の標準的なメカニズムを使って、バックアップ サイトにフェールオーバーします。 Azure DNS を使用した手動オプションは、コールド スタンバイまたはパイロット ライトの方法と組み合わせて使用した場合に最適に機能します。

DNS サーバーはフェールオーバーまたはディザスター ゾーンの外部にあるため、あらゆるダウンタイムに対して保護されます。 オペレーターが障害発生時にネットワークに接続して切り替えを実行できる場合に限り、単純なフェールオーバー シナリオを設計できます。 ソリューションをスクリプトにする場合は、スクリプトを実行するサーバーまたはサービスが、運用環境に影響する問題から保護されていることも確認する必要があります。 また、ゾーンの TTL が短いと、リゾルバーで長時間キャッシュされることがなくなり、お客様は RTO 内でサイトにアクセスできます。 コールド スタンバイとパイロット ライトでは、事前ウォームアップや他の管理作業が必要な場合があるため、切り替えを行う前に十分な時間を確保する必要もあります。

Azure portal を使って Azure プライベート DNS ゾーンを作成する方法については、「クイック スタート:Azure portal を使用して Azure プライベート DNS ゾーンを作成する」をご覧ください。

Azure portal を使った Azure DNS Private Resolver の作成については、「クイック スタート: Azure portal を使用して Azure DNS Private Resolver を作成する」をご覧ください。

複数リージョンの地域でのディザスター リカバリー

ディザスター リカバリー アーキテクチャの設定には次の 2 つの技術的な側面があります。

• デプロイ メカニズムを使用して、プライマリおよびスタンバイの環境間でのインスタンス、データ、および構成をレプリケートします。 この種のディザスター リカバリーは、Azure Site Recovery を介してネイティブに実行できます。Veritas や NetApp などの Microsoft Azure パートナー アプライアンス/サービスを介した Azure Site Recovery のドキュメントを参照してください。

• ネットワーク トラフィックまたは Web トラフィックをプライマリ サイトからスタンバイ サイトに迂回させるソリューションを開発します。 この種のディザスター リカバリーは、Azure DNS、Azure Traffic Manager (DNS)、またはサード パーティのグローバル ロード バランサーを使って実現できます。

この記事では、特に Azure DNS ディザスター リカバリーの計画に焦点を当てます。

ディザスター リカバリーと障害検出を設定する

ディザスター リカバリー用の Azure DNS 手動フェールオーバー ソリューションでは、標準的な DNS メカニズムを使用して、バックアップ サイトにフェールオーバーします。 Azure DNS を使用した手動オプションは、コールド スタンバイまたはパイロット ライトの方法を組み合わせて使用した場合に最適に機能します。

図 - Azure DNS を使用した手動フェールオーバー

ソリューションに対して行われた前提条件は次のとおりです。

• プライマリとセカンダリの両方のエンドポイントには、頻繁に変更されない静的 IP があります。 たとえば、プライマリ サイトの IP は 100.168.124.44 で、セカンダリ サイトの IP は 100.168.124.43 です。
• Azure DNS ゾーンはプライマリ サイトおよびセカンダリ サイトの両方に存在します。 たとえば、プライマリ サイトのエンドポイントは prod.contoso.com で、バックアップ サイトのエンドポイントは dr.contoso.com です。 Www.contoso.com と呼ばれるメイン アプリケーション用の DNS レコードも存在します。
• TTL は、組織で設定された RTO SLA 以下です。 たとえば、エンタープライズがアプリケーション ディザスター応答の RTO を 60 分に設定した場合、TTL は 60 分未満である必要があり、少ないほど優れています。 Azure DNS を手動フェールオーバー用に以下のようにセットアップできます。
  • DNS ゾーンの作成
  • DNS ゾーン レコードの作成
  • CNAME レコードの更新

1. 次に示すように、DNS ゾーン (たとえば、www.contoso.com) を作成します。

   

   図 - Azure での DNS ゾーンの作成

2. このゾーン内に、以下に示すように 3 つのレコード (たとえば、www.contoso.com、prod.contoso.com、および dr.contoso.com) を作成します。

   

   図 - Azure での DNS ゾーン レコードの作成

   このシナリオでは、サイト www.contoso.com は TTL が 30 分で、これは明記された RTO を十分に下回っており、さらに実稼働サイト prod.contoso.com を指しています。 この構成は通常の業務操作中の構成です。 prod.contoso.com および dr.contoso.com の TTL は、300 秒つまり 5 分に設定されています。 Azure Monitor や Azure App Insights などの Azure 監視サービスを使用したり、Dynatrace などのパートナー監視ソリューションを使用したりできます。 さらに、アプリケーションや仮想インフラストラクチャ レベルの障害を監視または検出できる自社製のソリューションを使用することもできます。

3. エラーが検出されると、次に示すように dr.contoso.com を指すようにレコード値が変更します。

   

   図 - Azure での CNAME レコードの更新

   ほとんどのリゾルバーが、キャッシュされたゾーン ファイルを更新する 30 分以内に、www.contoso.com への任意のクエリは dr.contoso.com にリダイレクトされます。 また、以下の Azure CLI コマンドを実行して CNAME 値を変更することもできます。

     az network dns record-set cname set-record \
     --resource-group 123 \
     --zone-name contoso.com \
     --record-set-name www \
     --cname dr.contoso.com
   

   この手順は手動またはオートメーションで実行することができます。 手動の場合はコンソールまたは Azure CLI を使用して実行できます。 Azure SDK と API を使用して CNAME の更新を自動化し、手動による介入が不要になるようにすることができます。 オートメーションは、Azure 関数から、サード パーティの監視アプリケーション内で、さらにはオンプレミスからでも、構築できます。

次のステップ

• Azure での信頼性
• Azure Traffic Manager の詳細については、こちらをご覧ください。
• Azure DNS の詳細を学習する。