Azure Traffic Manager

Azure Traffic ManagerAzure 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.

Traffic Manager Overview
Traffic Manager Overview

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.

Environment Overview
Environment Overview

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.

Create Traffic Manager Profile
Create Traffic Manager Profile

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.

Create Traffic Manager Endpoint
Create Traffic Manager Endpoint

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.

Traffic Manager Endpoints
Traffic Manager Endpoints

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.

External DNS CNAME
External DNS CNAME

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.

Central Client Connect
Central Client Connect

The image below indicates a client located in West US connects to the West App Service.

West Client Connect
West Client Connect

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.

Traffic Manager Configuration
Traffic Manager Configuration

Notice that the Endpoints are still showing online, but now have a priority value.

Endpoint Priority
Endpoint Priority

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.

Traffic Manager Redirect
Traffic Manager Redirect

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.

Traffic Manager Degraded
Traffic Manager Degraded
Secondary Endpoint
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.

Correct Internal DNS Configuration
Correct Internal DNS Configuration

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.

Incorrect Internal DNS Configuration
Incorrect Internal DNS Configuration

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.

 

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.