Last time I walked through a basic traffic manager setup. As with most walkthroughs this should help get you up and running but it doesn’t cover some of the things you need to consider to make this a real world solution. So, this time I’m going to delve into some of this. I’ll cover the Azure part of setting up a custom domain to give your site a realistic presence to your customers. To better understand this I’ll look at what Traffic Manager Profiles are actually doing under the covers with requests coming from clients.
After setting up a traffic manager profile if you look at the custom domains for your site you’ll see something like this.
You’ll see that Azure has added a custom domain for azurewebsites.net so you have a means of accessing the site even if you do nothing else. It is greyed out as you cannot remove it. In the screen grab I have also added a custom domain in order to give the site a friendly name. To get this to work you need to setup the relevant DNS A or CNAME records whether that is in Azure itself or via a 3rd party. Azure will only allow you to add this after verifying that the domain records are correctly registered.
If you set up a traffic manager profile and add your web site as an endpoint, when you look at the custom domains again you notice a change. An entry for the traffic manager profile has been added, but why? To understand that you need to look at what the traffic manager profile is really doing.
When a client makes a request for
tmpprofile1233.trafficmanager.net, a DNS lookup is required to resolve the address. Normally this would result in the same IP address (in the case of an A Record) or a domain name (in the case of an CNAME record) for every lookup. If the result is a domain name, the process is repeated until an IP address is returned. The client then uses this IP address to talk to the web application directly. Traffic is not being routed through the DNS infrastructure for each request nor is a lookup done each time. The client holds on to the IP address for a set period of time, called the Time To Live, TTL, and only looks up the address up again when this time has expired.
Traffic manager profiles provide a set of rules so different domain names are returned based on the routing method and the endpoint configuration e.g., the number of endpoints, their weight and priority. You also define a TTL which is lower than normal to ensure that address lookups occur more regularly. This ensures that clients are not disrupted for too long in the case of a failure.
Based on its rules, traffic manager will provide the domain for one of your endpoints, such as
uksouth-dev.hamersmith.space. The client will then resolve that to an IP address and talk to it directly. This explains why
trafficmanager.net addresses show up in each of your app services custom domains list. It is also why you configure a shared domain name such as
dev.hamersmith.space at each site and not in the traffic manager profile itself.
In the screen grab above I have a local, pretty domain,
xxx-dev1.hamersmith.space, that routes the clients directly to this web site. This is useful for testing purposes to bypass any traffic manager policies. You’ll also see the shared domain name
xxx-dev.hamersmith.space which is needed to ensure that the site works correctly when it is picked by the traffic manager policy.
It took a while to get my head around this when I first used traffic manager, but once you walk through what it is doing it starts to make more sense.