Implementing High Availability with Azure Traffic Manager
In this blog, I will implement a scenario to achieve high availability for an application deployed on Azure. The application will be deployed in 2 distinct geographic regions of Azure — West US and East Asia region. We will simulate a scenario where the application in one region will go down and still the application will be reachable and served to the end user from another region. We will achieve this using Azure Traffic Manager and the application will be deployed on Azure VMs. Before we start with the implementation, let us understand the Azure Traffic Manager service in brief.
What is Azure Traffic Manager?
Azure Traffic Manager is a global DNS-based traffic load balancing solution. It enables you to distribute incoming traffic across multiple endpoints, such as Azure VMs, cloud services, or web apps, apps deployed on AKS, based on various traffic routing methods. One of the key benefits of using Azure Traffic Manager is that it provides a way to improve application performance and provides a better user experience by routing traffic to endpoints in different geographic locations or regions. This can help reduce latency, improve response times, and ensure that users are always directed to the closest available endpoint in case of disaster to a failover region ensuring no downtime. Azure Traffic Manager is also designed to be highly scalable and resilient, with automatic failover and monitoring capabilities it ensures that the traffic is always directed to the healthiest available endpoint.
What are Azure Traffic Manager endpoints?
An endpoint is the destination location that’s returned to the client. We configure each application deployment as an ‘endpoint’ in Traffic Manager. When Traffic Manager receives a DNS request, it chooses an available endpoint to return in the DNS response. There are three types of endpoint Traffic Manager supports:
- Azure endpoints are used for services hosted in Azure. These can be services like Azure App Service, public IP resources that are associated with load balancers, or virtual machines.
- External endpoints are used for IPv4/IPv6 addresses, FQDNs, or services hosted outside Azure that can either be on-premises or with a different hosting provider.
- Nested endpoints are used to combine Traffic Manager profiles to create more flexible traffic-routing schemes to support the needs of larger, more complex deployments.
How Azure Traffic Manager does routing?
Azure Traffic Manager supports different methods for choosing how traffic is routed to multiple endpoints. You can choose from six traffic routing methods. This includes — geographic routing, performance routing, weighted round-robin, priority-based, subnet, and multivalue-based routing. For the implementation in this blog, we will focus on priority-based routing to achieve high availability in case of disaster.
Now, let us understand the architecture and implement the scenario. Assume West US is the primary region and East Asia is the secondary region for our application.
Architecture:
Step 1: Create an Azure Traffic Manager profile
Go to the Azure Traffic Manager service in the Azure portal. Create a traffic manager profile.
Give a name to the traffic manager profile. This name will also be prefixed with the traffic manager’s DNS name. Select the routing method as priority-based routing. Then, click on Create.
Step 2: Create the VMs in the regions
The profile will be visible on the dashboard. Click on the created profile and we a multiple configuration options and details of the created profile. Note the DNS name and check the configuration of the profile.
Now we will deploy our web application to the West US and the East Asia region. Run the following command using Azure CLI, to deploy an Azure Resource Manager (ARM) template. The template creates two VMs each in one region. We are using a ready-made ARM template for the demo purpose.
az deployment group create \
--resource-group learn-9afee9bb-41eb-4412-a23d-21726c4a96a1 \
--template-uri https://raw.githubusercontent.com/MicrosoftDocs/mslearn-distribute-load-with-traffic-manager/master/azuredeploy.json \
--parameters password="$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 32)"Once, the deployment is done, you can see the 2 VMs running in both regions with public IPs.
Step 3: Add endpoints for both the regions
For this demo, as discussed we are assuming West US as the primary region and the East Asia region as the secondary or the failover region. Back to Traffic Manager, we will configure the endpoints. Click on Endpoints of the left pane and click on Add.
Create a West US endpoint, and select the type Azure endpoint with public IP. From the drop-down select the public IP NIC associated with the VM. Set the priority as 1 as it acts as the primary region. Click on Add.
Similarly, create an East Asia endpoint, and select the type as Azure endpoint with public IP. From the drop-down select the public IP NIC associated with the VM. Set the priority as 2 as it acts as the secondary region. Click on Add.
Once both endpoints are added, we can see them on the endpoints console.
Step 4: Testing the primary region
We will now test the traffic manager DNS endpoint URL. From my browser, on hitting the Traffic Manager endpoint, the response is received from the West US serving application. This is because the West US endpoint has been given priority as 1 — primary region.
On doing an “nslookup” ( DNS to IP resolver tool) on the CLI, we get the public address of the West US VM.
nslookup anm-test.trafficmanager.net
Server: 172.21.16.1
Address: 172.21.16.1#53
Non-authoritative answer:
anm-test.trafficmanager.net canonical name = westus2-vm-6ximnu5pcgbbg.westus2.cloudapp.azure.com.
Name: westus2-vm-6ximnu5pcgbbg.westus2.cloudapp.azure.com
Address: 20.3.160.35Step 5: Simulating a disaster
We will now simulate a disaster scenario, where in the West US VM goes down, or is deleted. In this scenario, the Traffic Manager will redirect the traffic to the secondary/failover region VM in East Asia. We have set the East Asia endpoint as priority 2. To do so, let us delete the West US VM.
Step 6: Testing the failover region after disaster
We will retest the Azure Traffic Manager endpoint. This time, without any downtime, the traffic will be served by the East Asia VM — by the failover region.
Now, on doing an “nslookup” on the CLI, we get the public address of the East Asia VM.
nslookup anm-test.trafficmanager.net
Server: 172.21.16.1
Address: 172.21.16.1#53
Non-authoritative answer:
anm-test.trafficmanager.net canonical name = eastasia-vm-6ximnu5pcgbbg.eastasia.cloudapp.azure.com.
Name: eastasia-vm-6ximnu5pcgbbg.eastasia.cloudapp.azure.com
Address: 20.187.94.240Thus, the Azure Traffic Manager based on the priority profile has seamlessly directed the traffic from the primary region to the secondary region ensuring the high availability of the application without hammering the end-user experience in case of disaster.
Conclusion:
In this blog, we covered a HA scenario using Azure Traffic Manager with priority-based routing. Similarly, using other routing mechanisms several techniques can be archived. Having a Traffic manager is always a best practice when deploying solutions to the production environment. It can also be used to reduce latency for end users using geographic and performance-based routing, ensuring the best-performing endpoints receive the traffic. It can be also coupled with Azure Load Balancer and Azure CDN to improve content delivery and reduce latency and achieve scalability of the backend instances. This helps to improve user experience and reduce the load on your application. That's it from this article of mine. Suggestions are most welcomed.
