Azure DNS と Traffic Manager を使用したディザスター リカバリーDisaster recovery using Azure DNS and Traffic Manager

ディザスター リカバリーは、アプリケーションの機能の深刻な損失からの復旧に重点を置きます。Disaster recovery focuses on recovering from a severe loss of application functionality. ディザスター リカバリー ソリューションを選択するには、ビジネスおよびテクノロジの所有者は、災害中に必要な機能レベルを最初に判別する必要があります (例えば、利用不可、機能を制限して一部利用可能、遅延するが利用可能、または完全に利用可能など)。In order to choose a disaster recovery solution, business and technology owners must first determine the level of functionality that is required during a disaster, such as - unavailable, partially available via reduced functionality, or delayed availability, or fully available. ほとんどの企業のお客様は、アプリケーションまたはインフラストラクチャ レベルの フェールオーバーに対する回復性を確保するためにマルチリージョン アーキテクチャを選択します。Most enterprise customers are choosing a multi-region architecture for resiliency against an application or infrastructure level failover. お客様は、冗長なアーキテクチャを使用したフェールオーバーと高可用性の実現を追求して、いくつかのアプローチを選択できます。Customers can choose several approaches in the quest to achieve failover and high availability via redundant architecture. 一般的な手法の一部を次に示します。Here are some of the popular approaches:

  • アクティブ/パッシブ (コールド スタンバイ) : このフェールオーバー ソリューションでは、スタンバイ リージョンで実行中の VM とその他のアプライアンスは、フェールオーバーのニーズが発生しない限りアクティブではありません。Active-passive with cold standby: In this failover solution, the VMs and other appliances that are running in the standby region are not active until there is a need for failover. ただし運用環境は、バックアップ、VM イメージ、または Resource Manager テンプレートの形式で別のリージョンにレプリケートされます。However, the production environment is replicated in the form of backups, VM images, or Resource Manager templates, to a different region. このフェールオーバーのメカニズムはコスト効果は高いですが、完全なフェールオーバーを行うのに長い時間がかかります。This failover mechanism is cost-effective but takes a longer time to undertake a complete failover.

    アクティブ/パッシブ (コールド スタンバイ)

    図 - アクティブ/パッシブ (コールド スタンバイ) のディザスター リカバリー構成Figure - Active/Passive with cold standby disaster recovery configuration

  • アクティブ/パッシブ (パイロット ライト) : このフェールオーバー ソリューションでは、スタンバイ環境が最小構成でセットアップされます。Active/Passive with pilot light: In this failover solution, the standby environment is set up with a minimal configuration. セットアップでは、最小限かつ重要なアプリケーションのセットのみをサポートするために必要なサービスのみが実行されます。The setup has only the necessary services running to support only a minimal and critical set of applications. ネイティブ形式では、このシナリオでは最小限の機能のみ実行されますが、フェールオーバーが発生した場合は実稼働負荷を処理するためにスケール アップして追加のサービスを起動することができます。In its native form, this scenario can only execute minimal functionality but can scale up and spawn additional services to take bulk of the production load if a failover occurs.

    アクティブ/パッシブ (パイロット ライト)

    図 - アクティブ/パッシブ (パイロット ライト) のディザスター リカバリー構成Figure: Active/Passive with pilot light disaster recovery configuration

  • アクティブ/パッシブ (ウォーム スタンバイ) : このフェールオーバー ソリューションでは、スタンバイ リージョンは事前にウォームアップされてベースロードを引き受ける準備ができており、自動スケーリングが有効で、すべてのインスタンスが起動しています。Active/Passive with warm standby: In this failover solution, the standby region is pre-warmed and is ready to take the base load, auto scaling is turned on, and all the instances are up and running. このソリューションは、実稼働負荷全体を引き受けるほどにはスケールアップされていませんが、機能を有しており、すべてのサービスは起動しています。This solution is not scaled to take the full production load but is functional, and all services are up and running. このソリューションは、パイロット ライト アプローチの強化されたバージョンです。This solution is an augmented version of the pilot light approach.

    アクティブ/パッシブ (ウォーム スタンバイ)

    図: アクティブ/パッシブ (ウォーム スタンバイ)のディザスター リカバリー構成Figure: Active/Passive with warm standby disaster recovery configuration

フェールオーバーおよび高可用性について詳しくは、 Azure アプリケーションのディザスター リカバリーに関する記事をご覧ください。To learn more about failover and high availability, see Disaster Recovery for Azure Applications.

ディザスター リカバリー アーキテクチャの計画Planning your disaster recovery architecture

ディザスター リカバリー アーキテクチャの設定には次の 2 つの技術的な側面があります。There are two technical aspects towards setting up your disaster recovery architecture:

  • デプロイ メカニズムを使用して、プライマリおよびスタンバイの環境間でのインスタンス、データ、および構成をレプリケートします。Using a deployment mechanism to replicate instances, data, and configurations between primary and standby environments. この種のディザスター リカバリーは、Veritas や NetApp などの Microsoft Azure パートナー アプライアンス/サービスを介して Azure Site Recovery を使用してネイティブで実行できます。This type of disaster recovery can be done natively via Azure Site-Recovery via Microsoft Azure partner appliances/services like Veritas or NetApp.
  • ネットワーク トラフィックまたは Web トラフィックをプライマリ サイトからスタンバイ サイトに迂回させるソリューションを開発します。Developing a solution to divert network/web traffic from the primary site to the standby site. この種のディザスター リカバリーは、Azure DNS、Azure Traffic Manager (DNS)、またはサード パーティ製のグローバル ロード バランサーを使用して実現できます。This type of disaster recovery can be achieved via Azure DNS, Azure Traffic Manager(DNS), or third-party global load balancers.

この記事では、ネットワーク トラフィックおよび Web トラフィックのリダイレクトを使用した方法のみを扱います。This article is limited to approaches via Network and Web traffic redirection. Azure Site Recovery のセットアップの詳細については、 Azure Site Recovery のドキュメントを参照してください。For instructions to set up Azure Site Recovery, see Azure Site Recovery Documentation. DNS は多くの場合、データ センターの外部で使用できるグローバル サービスであり、リージョンや可用性ゾーン (AZ) レベルのあらゆる障害から隔離されているため、DNS はネットワーク トラフィックを迂回させる最も効率的なメカニズムです。DNS is one of the most efficient mechanisms to divert network traffic because DNS is often global and external to the data center and is insulated from any regional or availability zone (AZ) level failures. ユーザーは DNS ベースのフェールオーバーのメカニズムを使用することができ、Azure では 2 つの DNS サービス、つまり Azure DNS (権限のある DNS) と Azure Traffic Manager (DNS ベースのスマート トラフィック ルーティング) が何らかの方法で同じ効果を実現できます。One can use a DNS-based failover mechanism and in Azure, two DNS services can accomplish the same in some fashion - Azure DNS (authoritative DNS) and Azure Traffic Manager (DNS-based smart traffic routing).

この記事で説明する解決策について説明するために広く使用される DNS に関するいくつかの概念を理解しておく必要があります。It is important to understand few concepts in DNS that are extensively used to discuss the solutions provided in this article:

  • DNS の A レコード - A レコードは、ドメインから IPv4 アドレスへの対応を示すポインターです。DNS A Record – A Records are pointers that point a domain to an IPv4 address.
  • CNAME または正規名 - このレコード タイプは別の DNS レコードを指すために使用します。CNAME or Canonical name - This record type is used to point to another DNS record. CNAME は IP アドレスに応答せず、IP アドレスを含むレコードへのポインターに応答します。CNAME doesn’t respond with an IP address but rather the pointer to the record that contains the IP address.
  • 重み付けルーティング – サービス エンドポイントに重み付けを関連付け、割り当てられた重み付けに基づいてトラフィックを分散させることができます。Weighted Routing – one can choose to associate a weight to service endpoints and then distribute the traffic based on the assigned weights. このルーティング方式は、 Traffic Manager で使用可能な 4 つのトラフィック ルーティング メカニズムのうちの 1 つです。This routing method is one of the four traffic routing mechanisms available within Traffic Manager. 詳細については、「重み付けルーティング方式」を参照してください。For more information, see Weighted routing method.
  • 優先順位によるルーティング – 優先順位によるルーティングはエンドポイントの正常性チェックに基づいています。Priority Routing – Priority routing is based on health checks of endpoints. 既定では、Azure Traffic Manager は優先順位が最高のエンドポイントにすべてのトラフィックを送信し、障害や災害が発生すると、Traffic Manager はセカンダリ エンドポイントにトラフィックをルーティングします。By default, Azure Traffic manager sends all traffic to the highest priority endpoint, and upon a failure or disaster, Traffic Manager routes the traffic to the secondary endpoint. 詳細については、「優先順位によるルーティング方法」を参照してください。For more information, see Priority routing method.

Azure DNS を使用した手動フェールオーバーManual failover using Azure DNS

ディザスター リカバリー用の Azure DNS 手動フェールオーバー ソリューションでは、標準的な DNS メカニズムを使用して、バックアップ サイトにフェールオーバーします。The Azure DNS manual failover solution for disaster recovery uses the standard DNS mechanism to failover to the backup site. Azure DNS を使用した手動オプションは、コールド スタンバイまたはパイロット ライトの方法を組み合わせて使用した場合に最適に機能します。The manual option via Azure DNS works best when used in conjunction with the cold standby or the pilot light approach.

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

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

ソリューションに対して行われた前提条件は次のとおりです。The assumptions made for the solution are:

  • プライマリとセカンダリの両方のエンドポイントには、頻繁に変更されない静的 IP があります。Both primary and secondary endpoints have static IPs that don’t change often. たとえば、プライマリ サイトの IP は 100.168.124.44 で、セカンダリ サイトの IP は 100.168.124.43 です。Say for the primary site the IP is 100.168.124.44 and the IP for the secondary site is 100.168.124.43.
  • Azure DNS ゾーンはプライマリ サイトおよびセカンダリ サイトの両方に存在します。An Azure DNS zone exists for both the primary and secondary site. たとえば、プライマリ サイトのエンドポイントは prod.contoso.com で、バックアップ サイトのエンドポイントは dr.contoso.com です。Say for the primary site the endpoint is prod.contoso.com and for the backup site is dr.contoso.com. www.contoso.com と呼ばれるメイン アプリケーション用の DNS レコードも存在します。A DNS record for the main application known as www.contoso.com also exists.
  • TTL は、組織で設定された RTO SLA 以下です。The TTL is at or below the RTO SLA set in the organization. たとえば、エンタープライズがアプリケーション ディザスター応答の RTO を 60 分に設定した場合、TTL は 60 分未満である必要があり、少ないほど優れています。For example, if an enterprise sets the RTO of the application disaster response to be 60 mins, then the TTL should be less than 60 mins, preferably the lower the better. Azure DNS を手動フェールオーバー用に以下のようにセットアップできます。You can set up Azure DNS for manual failover as follows:
  • DNS ゾーンの作成Create a DNS zone
  • DNS ゾーン レコードの作成Create DNS zone records
  • CNAME レコードの更新Update CNAME record

手順 1: DNS の作成Step 1: Create a DNS

以下に示すように、DNS ゾーン (たとえば、www.contoso.com) を作成します。Create a DNS zone (for example, www.contoso.com) as shown below:

Azure での DNS ゾーンの作成

図 - Azure での DNS ゾーンの作成Figure - Create a DNS zone in Azure

手順 2: DNS ゾーン レコードの作成Step 2: Create DNS zone records

このゾーン内に、以下に示すように 3 つのレコード (たとえば、www.contoso.com、prod.contoso.com、および dr.consoto.com) を作成します。Within this zone create three records (for example - www.contoso.com, prod.contoso.com and dr.consoto.com) as show below.

DNS ゾーン レコードの作成

図 - Azure での DNS ゾーン レコードの作成Figure - Create DNS zone records in Azure

このシナリオでは、サイト www.contoso.com は TTL が 30 分で、これは明記された RTO を十分に下回っており、さらに実稼働サイト prod.contoso.com を指しています。In this scenario, site, www.contoso.com has a TTL of 30 mins, which is well below the stated RTO, and is pointing to the production site prod.contoso.com. この構成は通常の業務操作中の構成です。This configuration is during normal business operations. prod.contoso.com および dr.contoso.com の TTL は、300 秒つまり 5 分に設定されています。The TTL of prod.contoso.com and dr.contoso.com has been set to 300 seconds or 5 mins. Azure Monitor や Azure App Insights などの Azure 監視サービスを使用したり、Dynatrace などのパートナー監視ソリューションを使用したりできます。さらに、アプリケーションや仮想インフラストラクチャ レベルの障害を監視または検出できる自家製のソリューションを使用することもできます。You can use an Azure monitoring service such as Azure Monitor or Azure App Insights, or, any partner monitoring solutions such as Dynatrace, You can even use home grown solutions that can monitor or detect application or virtual infrastructure level failures.

手順 3: CNAME レコードの更新Step 3: Update the CNAME record

エラーが検出されると、次に示すように dr.contoso.com を指すようにレコード値が変更します。Once failure is detected, change the record value to point to dr.contoso.com as shown below:

CNAME レコードの更新

図 - Azure での CNAME レコードの更新Figure - Update the CNAME record in Azure

ほとんどのリゾルバーが、キャッシュされたゾーン ファイルを更新する 30 分以内に、www.contoso.com への任意のクエリは dr.contoso.com にリダイレクトされます。Within 30 minutes, during which most resolvers will refresh the cached zone file, any query to www.contoso.com will be redirected to dr.contoso.com. また、以下の Azure CLI コマンドを実行して CNAME 値を変更することもできます。You can also run the following Azure CLI command to change the CNAME value:

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

この手順は手動またはオートメーションで実行することができます。This step can be executed manually or via automation. 手動の場合はコンソールまたは Azure CLI を使用して実行できます。It can be done manually via the console or by the Azure CLI. Azure SDK と API を使用して CNAME の更新を自動化し、手動による介入が不要になるようにすることができます。The Azure SDK and API can be used to automate the CNAME update so that no manual intervention is required. オートメーションは、Azure 関数を使用して構築するか、サードパーティー製の監視アプリケーション内で構築するか、オンプレミスから構築することもできます。Automation can be built via Azure functions or within a third-party monitoring application or even from on- premises.

Azure DNS を使用した手動フェールオーバーの動作のしくみHow manual failover works using Azure DNS

DNS サーバーはフェールオーバー ゾーンまたはディザスター ゾーンの外部にあるため、あらゆるダウンタイムに対して保護されます。Since the DNS server is outside the failover or disaster zone, it is insulated against any downtime. これによりユーザーは、コスト効果の高い単純なフェールオーバー シナリオを構築し、オペレーターは障害発生時にネットワーク接続が可能で対策を実行できるという仮定の下で、常に作業することができます。This enables user to architect a simple failover scenario that is cost effective and will work all the time assuming that the operator has network connectivity during disaster and can make the flip. ソリューションをスクリプトに含める場合、スクリプトを実行するサーバーまたはサービスが、実稼働環境に影響する問題から隔離されているようにする必要があります。If the solution is scripted, then one must ensure that the server or service running the script should be insulated against the problem affecting the production environment. また、低い TTL をゾーンに対して設定することで、世界中のリゾルバーがエンドポイントを長期間キャッシュ し続けないようにして、顧客が RTO 時間内にサイトにアクセスできるようにすることに留意してください。Also, keep in mind the low TTL that was set against the zone so that no resolver around the world keeps the endpoint cached for long and customers can access the site within the RTO. コールド スタンバイおよびパイロット ライトの場合は、事前ウォームアップやその他の管理作業が必要な場合があるため、対策を実行する前に十分な時間を確保する必要もあります。For a cold standby and pilot light, since some prewarming and other administrative activity may be required – one should also give enough time before making the flip.

Azure Traffic Manager を使用した自動フェールオーバーAutomatic failover using Azure Traffic Manager

アーキテクチャが複雑で、同じ機能を実行できる複数のリソースのセットがある場合、Azure Traffic Manager を (DNS に基づいて) 構成して、リソースの正常性を確認し、正常でないリソースから正常なリソースにトラフィックをルーティングすることができます。When you have complex architectures and multiple sets of resources capable of performing the same function, you can configure Azure Traffic Manager (based on DNS) to check the health of your resources and route the traffic from the non-healthy resource to the healthy resource. 次の例では、プライマリ リージョンとセカンダリ リージョンの両方が完全にデプロイされています。In the following example, both the primary region and the secondary region have a full deployment. このデプロイには、クラウド サービスと同期化されたデータベースが含まれます。This deployment includes the cloud services and a synchronized database.

Azure Traffic Manager を使用した自動フェールオーバー

図 - Azure Traffic Manager を使用した自動フェールオーバーFigure - Automatic failover using Azure Traffic Manager

ただし、プライマリ リージョンのみが、ユーザーからのネットワーク要求をアクティブに処理しています。However, only the primary region is actively handling network requests from the users. セカンダリ リージョンは、プライマリ リージョンでサービスの中断が発生した場合にのみアクティブになります。The secondary region becomes active only when the primary region experiences a service disruption. その場合、新しいネットワーク要求はすべて、セカンダリ リージョンにルーティングされます。In that case, all new network requests route to the secondary region. データベースのバックアップはほぼ瞬時で行われ、両方のロード バランサーには正常性のチェックが可能な IP が存在し、インスタンスは常に動作しているため、このトポロジでは、低い RTO での実行と、手動による介入が不要なフェールオーバーのオプションが提供されます。Since the backup of the database is near instantaneous, both the load balancers have IPs that can be health checked, and the instances are always up and running, this topology provides an option for going in for a low RTO and failover without any manual intervention. セカンダリ フェールオーバー リージョンは、プライマリ リージョンで障害が発生した直後に動作可能な状態になる必要があります。The secondary failover region must be ready to go-live immediately after failure of the primary region. このシナリオは、http、https、TCP などのさまざまな種類の正常性のチェックのための組み込みのプローブを持つ Azure Traffic Manager の使用するために最適です。This scenario is ideal for the use of Azure Traffic Manager that has inbuilt probes for various types of health checks including http / https and TCP. Azure Traffic Manager には、以下に示すように障害が発生したときにフェールオーバーを構成できるルール エンジンもあります。Azure Traffic manager also has a rule engine that can be configured to failover when a failure occurs as described below. Traffic Manager を使用した次のソリューションについて検討してみましょう。Let’s consider the following solution using Traffic Manager:

  • お客様は、静的 IP が 100.168.124.44 であるprod.contoso.com というリージョン 1 のエンドポイントと、静的 IP が 100.168.124.43 である dr.contoso.com というリージョン 2 のエンドポイントを持っています。Customer has the Region #1 endpoint known as prod.contoso.com with a static IP as 100.168.124.44 and a Region #2 endpoint known as dr.contoso.com with a static IP as 100.168.124.43.
  • 各環境は、ロード バランサーのようにパブリックに公開されたプロパティを使用してアクセスされます。Each of these environments is fronted via a public facing property like a load balancer. ロード バランサーは、上記のように、DNS ベース エンドポイントまたは完全修飾ドメイン名 (FQDN) の設定を構成できます。The load balancer can be configured to have a DNS-based endpoint or a fully qualified domain name (FQDN) as shown above.
  • リージョン 2 のすべてのインスタンスは、リージョン 1 とほぼリアルタイムでレプリケーションされます。All the instances in Region 2 are in near real-time replication with Region 1. さらに、マシンのイメージは最新状態で、すべてのソフトウェアおよび構成データはパッチが適用され、リージョン 1 に合致しています。Furthermore, the machine images are up-to-date, and all software/configuration data is patched and are in line with Region 1.
  • 自動スケーリングが事前に構成済みです。Autoscaling is preconfigured in advance.

Azure Traffic Manager によるフェールオーバーを構成するための手順については次のとおりです。The steps taken to configure the failover with Azure Traffic Manager are as follows:

  1. 新しい Azure Traffic Manager プロファイルの作成Create a new Azure Traffic Manager profile
  2. Traffic Manager プロファイル内のエンドポイントの作成Create endpoints within the Traffic Manager profile
  3. 正常性チェックとフェールオーバー構成の設定Set up health check and failover configuration

手順 1: 新しい Azure Traffic Manager プロファイルの作成Step 1: Create a new Azure Traffic Manager profile

contoso123 という名前で新しい Azure Traffic Manager プロファイルを作成し、ルーティング方法については優先順位を選択します。Create a new Azure Traffic manager profile with the name contoso123 and select the Routing method as Priority. 関連付けを行う既存のリソース グループがある場合は既存のリソース グループを選択でき、それ以外の場合は新しいリソース グループを作成します。If you have a pre-existing resource group that you want to associate with, then you can select an existing resource group, otherwise, create a new resource group.

Traffic Manager プロファイルを作成する

図 - Traffic Manager プロファイルの作成Figure - Create a Traffic Manager profile

手順 2: Traffic Manager プロファイル内のエンドポイントの作成Step 2: Create endpoints within the Traffic Manager profile

この手順では、実稼働サイトとディザスター リカバリー サイトを指すエンドポイントを作成します。In this step, you create endpoints that point to the production and disaster recovery sites. ここでは、 [Type](タイプ) を外部エンドポイントとして選択しますが、リソースが Azure でホストされている場合は、 [Azure エンドポイント] も選択できます。Here, choose the Type as an external endpoint, but if the resource is hosted in Azure, then you can choose Azure endpoint as well. [Azure エンドポイント] を選択した場合、Azure によって割り当てられた [App Service] または [パブリック IP] のいずれかである [ターゲット リソース] を選択します。If you choose Azure endpoint, then select a Target resource that is either an App Service or a Public IP that is allocated by Azure. これはリージョン 1 のプライマリ サービスであるため、優先順位は 1 に設定されます。The priority is set as 1 since it is the primary service for Region 1. 同様に、Traffic Manager 内でディザスター リカバリーエンド ポイントを作成します。Similarly, create the disaster recovery endpoint within Traffic Manager as well.

ディザスター リカバリー エンドポイントの作成

図 - ディザスター リカバリー エンドポイントの作成Figure - Create disaster recovery endpoints

手順 3: 正常性チェックとフェールオーバー構成の設定Step 3: Set up health check and failover configuration

この手順では、DNS の TTL を 10 秒に設定します。この時間はインターネットに接続されたほとんどの再帰的なリゾルバーで受け入れられる設定です。In this step, you set the DNS TTL to 10 seconds, which is honored by most internet-facing recursive resolvers. この構成は、DNS リゾルバーが情報を 10 秒以上キャッシュしないことを意味します。This configuration means that no DNS resolver will cache the information for more than 10 seconds. エンドポイント監視設定については、パスは現在 / すなわちルートに設定されていますが、たとえば prod.contoso.com/index などのパスを評価するためにエンドポイントの設定をカスタマイズできます。For the endpoint monitor settings, the path is current set at / or root, but you can customize the endpoint settings to evaluate a path, for example, prod.contoso.com/index. 以下の例ではプローブ プロトコルとして https が示されています。The example below shows the https as the probing protocol. ただし、http または tcp を選択することもできます。However, you can choose http or tcp as well. プロトコルの選択は、目的のアプリケーションによって異なります。The choice of protocol depends upon the end application. プローブの間隔は、高速な調査を可能にする 10 秒に設定され、再試行回数は 3 に設定されます。The probing interval is set to 10 seconds, which enables fast probing, and the retry is set to 3. その結果、連続する 3 回の間隔でエラーが登録された場合、Traffic Manager は 2 番目のエンドポイントにフェールオーバーします。As a result, Traffic Manager will failover to the second endpoint if three consecutive intervals register a failure. 自動フェールオーバーの合計時間は次の数式で定義されます。フェールオーバーの時間 = TTL + 再試行回数 * プローブ間隔。この場合、値は 10 + 3 * 10 = 40 秒 (最大) です。The following formula defines the total time for an automated failover: Time for failover = TTL + Retry * Probing interval And in this case, the value is 10 + 3 * 10 = 40 seconds (Max). 再試行回数が 1 に設定され、TTL が 10 秒に設定された場合、フェールオーバーの時間は 10 + 1 * 10 = 20 秒になります。If the Retry is set to 1 and TTL is set to 10 secs, then the time for failover 10 + 1 * 10 = 20 seconds. 偽陽性または ネットワークの軽微な一時的悪化によるフェールオーバーの可能性を排除するために、再試行回数を 1 より大きい値に設定してください。Set the Retry to a value greater than 1 to eliminate chances of failovers due to false positives or any minor network blips.

正常性チェックの設定

図 - 正常性チェックとフェールオーバー構成の設定Figure - Set up health check and failover configuration

Traffic Manager をた使用し自動フェールオーバーが動作するしくみHow automatic failover works using Traffic Manager

障害発生時に、プライマリ エンドポイントがプローブされ、状態が [低下] に変わり、ディザスター リカバリー サイトが [オンライン] のままになります。During a disaster, the primary endpoint gets probed and the status changes to degraded and the disaster recovery site remains Online. Traffic Manager では、既定では、すべてのトラフィックがプライマリ (優先順位が一番高い) エンドポイントに送信されます。By default, Traffic Manager sends all traffic to the primary (highest-priority) endpoint. プライマリ エンドポイントが低下したとき、Traffic Manager は、2 番目のエンドポイントが正常である限り、トラフィックを 2 番目のエンドポイントにルーティングします。If the primary endpoint appears degraded, Traffic Manager routes the traffic to the second endpoint as long as it remains healthy. Traffic Manager 内に追加のエンドポイントを 構成して、追加のフェイル オーバーのエンドポイントとして使用したり、エンドポイント間の負荷を分散するロード バランサーとして使用したりするオプションもあります。One has the option to configure more endpoints within Traffic Manager that can serve as additional failover endpoints, or, as load balancers sharing the load between endpoints.

次のステップNext steps