|
| 1 | +--- |
| 2 | +title: Reliability in Azure Traffic Manager |
| 3 | +description: Learn about reliability in Azure Traffic Manager. |
| 4 | +author: anaharris-ms |
| 5 | +ms.author: anaharris |
| 6 | +ms.topic: overview |
| 7 | +ms.custom: subject-reliability, references.regions |
| 8 | +ms.service: traffic-manager |
| 9 | +ms.date: 02/02/2024 |
| 10 | +--- |
| 11 | + |
| 12 | + |
| 13 | +# Reliability in Azure Traffic Manager |
| 14 | + |
| 15 | +This article contains detailed information on [cross-region disaster recovery and business continuity](#cross-region-disaster-recovery-and-business-continuity) support for Azure Traffic Manager. |
| 16 | + |
| 17 | +## Cross-region disaster recovery and business continuity |
| 18 | + |
| 19 | +[!INCLUDE [introduction to disaster recovery](includes/reliability-disaster-recovery-description-include.md)] |
| 20 | + |
| 21 | +Azure Traffic Manager is a DNS-based traffic load balancer that lets you distribute traffic to your public facing applications across global Azure regions. Traffic Manager also provides your public endpoints with high availability and quick responsiveness. |
| 22 | + |
| 23 | +Traffic Manager uses DNS to direct client requests to the appropriate service endpoint based on a traffic-routing method. Traffic manager also provides health monitoring for every endpoint. The endpoint can be any Internet-facing service hosted inside or outside of Azure. Traffic Manager provides a range of traffic-routing methods and endpoint monitoring options to suit different application needs and automatic failover models. Traffic Manager is resilient to failure, including the failure of an entire Azure region. |
| 24 | + |
| 25 | +### Disaster recovery in multi-region geography |
| 26 | + |
| 27 | +DNS is one of the most efficient mechanisms to divert network traffic. DNS is efficient because DNS is often global and external to the data center. DNS is also insulated from any regional or availability zone (AZ) level failures. |
| 28 | + |
| 29 | +There are two technical aspects towards setting up your disaster recovery architecture: |
| 30 | + |
| 31 | +- Using a deployment mechanism to replicate instances, data, and configurations between primary and standby environments. This type of disaster recovery can be done natively viaAzure Site Recovery, see [Azure Site Recovery Documentation](../site-recovery/index.yml) via Microsoft Azure partner appliances/services like Veritas or NetApp. |
| 32 | + |
| 33 | +- Developing a solution to divert network/web traffic from the primary site to the standby site. This type of disaster recovery can be achieved via [Azure DNS](reliability-dns.md), Azure Traffic Manager(DNS), or third-party global load balancers. |
| 34 | + |
| 35 | +This article focuses specifically on Azure Traffic Manager disaster recovery planning. |
| 36 | + |
| 37 | +#### Outage detection, notification, and management |
| 38 | + |
| 39 | +During a disaster, the primary endpoint gets probed and the status changes to **degraded** and the disaster recovery site remains **Online**. By default, Traffic Manager sends all traffic to the primary (highest-priority) endpoint. If the primary endpoint appears degraded, Traffic Manager routes the traffic to the second endpoint as long as it remains healthy. One can configure more endpoints within Traffic Manager that can serve as extra failover endpoints, or, as load balancers sharing the load between endpoints. |
| 40 | + |
| 41 | + |
| 42 | +#### Set up disaster recovery and outage detection |
| 43 | + |
| 44 | +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. |
| 45 | + |
| 46 | +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. |
| 47 | + |
| 48 | + |
| 49 | + |
| 50 | +*Figure - Automatic failover using Azure Traffic Manager* |
| 51 | + |
| 52 | +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. 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. |
| 53 | + |
| 54 | +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 also has a rule engine that can be configured to fail over when a failure occurs as described below. Let’s consider the following solution using Traffic Manager: |
| 55 | + |
| 56 | +- 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. |
| 57 | +- Each of these environments is fronted via a public facing property like a load balancer. The load balancer can be configured to have a DNS-based endpoint or a fully qualified domain name (FQDN) as shown above. |
| 58 | +- All the instances in Region 2 are in near real-time replication with Region 1. Furthermore, the machine images are up to date, and all software/configuration data is patched and are in line with Region 1. |
| 59 | +- Autoscaling is preconfigured in advance. |
| 60 | + |
| 61 | + |
| 62 | +**To configure the failover with Azure Traffic Manager:** |
| 63 | + |
| 64 | +1. Create a new Azure Traffic Manager profile |
| 65 | +Create a new Azure Traffic manager profile with the name contoso123 and select the Routing method as Priority. |
| 66 | +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. |
| 67 | + |
| 68 | +  |
| 69 | + |
| 70 | + *Figure - Create a Traffic Manager profile* |
| 71 | + |
| 72 | +1. Create endpoints within the Traffic Manager profile |
| 73 | + |
| 74 | + In this step, you create endpoints that point to the production and disaster recovery sites. Here, choose the **Type** as an external endpoint, but if the resource is hosted in Azure, then you can choose **Azure endpoint** as well. 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. The priority is set as **1** since it's the primary service for Region 1. |
| 75 | + Similarly, create the disaster recovery endpoint within Traffic Manager as well. |
| 76 | + |
| 77 | +  |
| 78 | + |
| 79 | + *Figure - Create disaster recovery endpoints* |
| 80 | + |
| 81 | +1. Set up health check and failover configuration |
| 82 | + |
| 83 | + In this step, you set the DNS TTL to 10 seconds, which is honored by most internet-facing recursive resolvers. This configuration means that no DNS resolver will cache the information for more than 10 seconds. 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. The example below shows the **https** as the probing protocol. However, you can choose **http** or **tcp** as well. The choice of protocol depends upon the end application. The probing interval is set to 10 seconds, which enables fast probing, and the retry is set to 3. As a result, Traffic Manager will fail over to the second endpoint if three consecutive intervals register a failure. The following formula defines the total time for an automated failover: |
| 84 | + Time for failover = TTL + Retry * Probing interval |
| 85 | + And in this case, the value is 10 + 3 * 10 = 40 seconds (Max). |
| 86 | + If the Retry is set to 1 and TTL is set to 10 secs, then the time for failover 10 + 1 * 10 = 20 seconds. Set the Retry to a value greater than **1** to eliminate chances of failovers due to false positives or any minor network blips. |
| 87 | + |
| 88 | + |
| 89 | +  |
| 90 | + |
| 91 | + *Figure - Set up health check and failover configuration* |
| 92 | + |
| 93 | +## Next steps |
| 94 | + |
| 95 | +- [Reliability in Azure](/azure/reliability/availability-zones-overview) |
| 96 | + |
| 97 | +- Learn more about [Azure Traffic Manager](../traffic-manager/traffic-manager-overview.md). |
| 98 | +- Learn more about [Azure DNS](../dns/dns-overview.md). |
0 commit comments