Azure DNS プライベート リゾルバーは、仮想マシン ベースの DNS サーバーを必要とせずに、オンプレミス環境とAzure DNSプライベート ゾーン間の DNS 解決を可能にするマネージド サービスです。 オンプレミス、マルチクラウド、パブリック DNS サーバーへの条件付き転送を構成できます。
Azureを使用する場合、信頼性は共有責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの障害、リージョン全体の障害など、潜在的な停止や中断に対する DNS プライベート リゾルバーの回復性を確保する方法について説明します。 また、バックアップと復元に関する考慮事項とサービスメンテナンスの動作についても説明します。
信頼性アーキテクチャの概要
DNS プライベート リゾルバーを使用する場合は、プライベート リゾルバーをAzure仮想ネットワークにデプロイします。 次に、オンプレミスとの間で DNS クエリを送受信する エンドポイントと、 転送動作を定義する転送規則を構成します。 詳細については、「 DNS プライベート リゾルバーエンドポイントとルールセット」を参照してください。
Microsoftは、マネージド リゾルバー サービスとそのプラットフォーム操作の可用性と正常性を担当します。 エンドポイントとルールセットトポロジの設計、DNS 転送ロジックの構成、ネットワーク接続パスで信頼性要件がサポートされていることを確認する責任があります。
エンド ツー エンドの信頼性は、依存するサービスとネットワーク アーキテクチャの決定にも依存します。 たとえば、プライベート DNS ゾーン、仮想ネットワーク構成、ファイアウォール規則、オンプレミス インフラストラクチャ、ハイブリッド接続のセットアップは、失敗時の名前解決の結果に直接影響します。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
DNS 解決中に一時的な障害が発生した場合、DNS クライアントまたは中間リゾルバーは DNS クエリを再試行する必要があります。 タイムアウト値を適切に構成します。通常、DNS クライアントでは 2 秒から 5 秒の間で十分なタイムアウトになります。
各 DNS レコードの Time to Live (TTL) は、ソリューションが障害を処理する方法にも影響します。 TTL が非常に低い場合、クライアントはより多くの DNS 解決要求を行う必要があり、一時的な障害が発生する可能性が高くなります。 TTL が非常に高い場合、バックエンド サーバーで別の IP アドレスにリダイレクトする必要がある真の障害が発生した場合、TTL の有効期限が切れるまで、クライアントのフェールオーバーの遅延が発生する可能性があります。 可用性、待機時間、応答性のバランスを取るために、TTL を慎重に構成します。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
DNS プライベート リゾルバーは、可用性ゾーンをサポートするリージョンでは自動的にゾーン冗長になります。 Microsoftは、これらのリージョン内のすべてのゾーンにサービスをプロビジョニングします。
必要条件
リージョンのサポート: DNS プライベート リゾルバーは、可用性ゾーンを サポートするリージョンで自動ゾーン冗長性を提供します。
Cost
DNS プライベート リゾルバーのゾーン冗長を有効にするための追加コストは発生しません。 価格の詳細については、「Azure DNS価格」を参照してください。
可用性ゾーンのサポートを設定する
DNS プライベート リゾルバーは、サポートされているリージョンでは自動的にゾーン冗長になります。 ゾーンの冗長性を有効にするために必要な構成はなく、無効にすることはできません。 デプロイ手順については、「クイック スタート: Azure ポータルを使用して DNS プライベート リゾルバーを作成する」を参照してください。
すべてのゾーンが正常な場合の動作
このセクションでは、可用性ゾーンを持つリージョンに DNS プライベート リゾルバーをデプロイし、すべてのゾーンが運用可能な場合に想定される内容について説明します。
ゾーン間操作: DNS プライベート リゾルバーは、複数のゾーンにわたってインフラストラクチャを実行し、ゾーン間で要求を自動的にルーティングします。
ゾーン間データ レプリケーション: DNS プライベート リゾルバーは、サービスがステートレスであり、顧客データを維持しないため、ゾーン間で顧客データをレプリケートしません。
ゾーン障害時の動作
このセクションでは、可用性ゾーンがあるリージョンに DNS プライベート リゾルバーをデプロイし、1 つのゾーンで障害が発生した場合に想定される内容について説明します。
- 検出と応答: Microsoftは可用性ゾーンの障害を検出し、すべての応答アクションを管理します。 ゾーンのフェールオーバーを開始するためのアクションを実行する必要はありません。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Resource Health を 使用して個々のリソースの正常性を監視したり、 Resource Health アラート を設定して問題を通知したりすることはできます。 また、Azure Service Health を使用して、ゾーンエラーを含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することもできます。
アクティブな要求: 影響を受けるインフラストラクチャを使用する実行中の DNS クエリは、失敗またはタイムアウトする可能性があり、再試行する必要があります。 クライアントが 一時的な障害を 適切に処理する場合、通常は重大な影響を回避します。
予想されるデータ損失: サービスはステートレスであり、顧客データを格納しないため、データ損失は予想されません。
予想されるダウンタイム: サービスが要求を正常なゾーン インフラストラクチャに移行する間、少量のダウンタイムが発生する可能性があります。 通常、このダウンタイムは数秒です。
再配布: Microsoftは、正常なゾーンを介して DNS 解決要求を自動的に再ルーティングします。
ゾーンの回復
障害が発生した可用性ゾーンが復旧すると、DNS プライベート リゾルバーは、顧客の介入なしに通常の操作を自動的に復元します。
ゾーンエラーのテスト
DNS プライベート リゾルバーは、完全にMicrosoft管理されたゾーン冗長サービスです。 Microsoftはゾーンの冗長性を管理するため、可用性ゾーンのフェールオーバー シナリオをテストする必要はありません。
リージョン全体の障害に対する回復性
DNS プライベート リゾルバーは、単一リージョン のサービスです。 リージョンが使用できなくなった場合、プライベート リゾルバーも使用できなくなります。
回復性のためのカスタム マルチリージョン ソリューション
リージョン全体の障害に対する回復性を向上させるために、複数のプライベート リゾルバーを別々のリージョンにデプロイできます。 次に、リージョン間のフェールオーバーをサポートするように転送パターンとトラフィック パターンを構成します。 詳細な手順については、「 プライベート リゾルバーを使用して DNS フェールオーバーを設定する」を参照してください。
バックアップと復元
DNS プライベート リゾルバーは顧客データを格納せず、バックアップや復元は必要ありません。 構成を再作成するには、ネットワーク リソース用のコードとしてのインフラストラクチャ (IaC) テンプレートを維持することを検討してください。 プライベート リゾルバーは構成専用であり、顧客データを格納しないため、リゾルバー、エンドポイント設定、DNS 転送ルールセット、およびその他のリソースを迅速に再デプロイするために、IaC テンプレートにバックアップ作業を集中します。
サービス メンテナンスに対する回復性
Microsoft は定期的にサービス更新プログラムを適用し、その他のメンテナンスを実行します。 Azure プラットフォームは、これらのアクティビティを自動的に処理し、メンテナンスがシームレスで透過的であることを保証します。 Azure Service Health の計画メンテナンスを通じて通知されていない限り、メンテナンス イベント中にダウンタイムは想定されていません。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。
DNS プライベート リゾルバーは、クライアントが失敗した要求を繰り返し再試行する限り、DNS クエリ応答の可用性 SLA を提供します。