Azure Traffic Manager is a global DNS service hosted in Azure. It extends the functionality of DNS beyond simple name to IP resolution, adding load balancing and advanced resolution features such as geo-fencing, weighted priority, performance, and source IP based name resolution.
Just as important to what it is, is what it is not. It is not an IP based Global Load Balancer. Traffic Manager does not handle IP session data, BGP or any other routing protocols. It is only an External DNS solution, it won’t work as an internal DNS solution.
Video Version can be found here
At a high-level, Traffic Manager works as illustrated below. The client looks up the resource with a custom FQDN. That FQDN has a CNAME entry in DNS for the Traffic Manager Profile. The Client is redirected to the Traffic Manager Profile. Traffic Manager monitors the state of each endpoint. The endpoint IP is returned based on the Routing Method and endpoint availability. In this case, Routing Method describes the way Traffic Manager directs DNS requests. Not to be confused with IP routing protocols.
Unlike other Azure services, Traffic Manager is global and not bound to a region. This makes it a useful part of any high availability solution for externally hosted services. The services can be in multiple Azure regions, on-premises or even at other cloud service providers. Traffic Manager will direct clients to the best endpoint based on availability and the routing method specified.
Traffic Manager uses Routing Methods to determine response to client requests. Routing Methods can be any one of the following.
Priority – Traffic Manager sends all requests to the highest priority endpoint available.
Weighted – Distributes client traffic based on a weighted priority.
Performance – Clients are directed to the endpoint with the lowest latency.
Geographic – Directs endpoints based on the geographic location.
Multi-value – Returns the IP address of all healthy endpoints.
Subnet – Maps client to a specific endpoint based on source IP.
Configure Traffic Manager
In this example, an Azure Traffic Manager Profile is created for two Azure App Services endpoints. One is located in the Azure Central US region and one in the Azure West US Region. I have two clients for testing, one in Central and One in West.
Start by logging into Azure and creating a new Traffic Manager Profile. Give the profile a globally unique name. The routing method is set to Performance in this example. Finish by selecting the subscription, Resource Group, and region.
Next, go into the newly created Traffic Manager Profile and select Endpoints. Add an endpoint.
The Example below demonstrates how to set up an Azure Endpoint. Give the Endpoint a name and select the resource type. This example shows an App Service Endpoint, but other Azure resource types are available. Select the External Endpoint option if the resource is not in Azure.
Once finished, the second endpoint for the Central Region is added. The example below shows that both endpoints added and the Monitor Status shows Online.
A custom domain name is used instead of the trafficmananger.net domain name to direct clients. This can be set up for external and/or internal DNS. Add a CNAME pointing your cosmetic FQDN to the Traffic Manager Profile FQDN. Below is an example from godaddy.com that directs traffic going to webtest.ciraltos.com to cirtest.trafficmananger.net.
To test, the web page title was modified from the default to indicate the Central or West App Service. The image below indicates a client located in Central US connects to the Central US App Service.
The image below indicates a client located in West US connects to the West App Service.
Configuration Settings
The default configuration works fine for simple websites. Some websites don’t respond to the default web page and path or require a specific hostname for SSL. In this case, the monitoring settings are modified from their default value. These settings are available in the Configuration page of the Traffic Manager Profile.
The Routing Method changed to Priority in the example below. If the site was SSL enabled, the protocol settings is also modified here.
The App Services have a test directory with a test web page added for this example. The path “/test/test.html” is added to the Path settings. Adding a separate monitoring page may be beneficial in some environments. This way, Traffic Manager probing can be removed from site statistics.
A custom header has also been added. This is helpful for sites using SSL or with strict URL host and path restrictions, such as AD FS Web Proxy. Other settings such as expected status code and failover settings are left as default.
Notice that the Endpoints are still showing online, but now have a priority value.
Browsing to webtest.ciraltos.com from a client in Central US shows it’s connected to the West App Service. This is expected as the West App Service has the highest priority.
If an error occurred with the primary endpoint, the monitor status changes from Online to Degraded and new sessions are directed to the secondary endpoint.
That is how to setup Azure Traffic Manager and configure it for both Performance and Priority connections as well as add custom hosts names and paths to endpoint monitoring.
The importance of internal DNS configuration
Active Directory makes DNS an easy, set-it and forget-it service. There is, however, one important gotcha with how DNS is configured in some environments that affects Traffic Manager performance.
First, let’s look at the right way to set up name resolution. In the example below,
1 – Clients connect to local DNS server for name resolution.
2 – The DNS server does a recursive query to resolve the address.
3 – Traffic Manager, set for performance routing, returns the closest web endpoint, West web.
4 – The local DNS server returns the West Web IP.
5 – the client connects to the local web endpoint.
Now let’s look at the incorrect way.
1 – West client connects to local DNS server for name resolution.
2 – DNS is set to forward, send a request to the Central DNS server.
3 – Central DNS does the recursive query.
4 – Traffic Manager, set for performance routing, returns the closest web endpoint for the Central DNS Server.
5 – Central DNS returns Central Web IP to West clients local DNS server.
6 – West DNS catches and returns Central Web IP
7 – West Client connects to Central Web.
Forwarding DNS queries used to be common when bandwidth was limited or to force DNS traffic from one secured location. Bandwidth is cheap and DNS queries secure relatively easily. There is little reason to forward queries to a central DNS server.
The above example is not limited to Azure Traffic Manager. Most websites such as YouTube, Netflix or Office 365 use content delivery networks (CDN) to connect the client to the closest content endpoint and decrease latency. Centralized DNS forwarders will impact those services as well.
