KB ID 0001740
Why Azure Traffic Manager? I had to price up a hardware load balancer (ADC) a couple of weeks ago for a client. I wont mention the vendor, (though I’m sure you can guess). Over 3 years it was going to cost (for a pair) about £100k, (so about 33k a year). That included the global DNS failover, this was so they, (the client) could fail over their services between multiple data centres.
OK there are other ADC vendors, and there’s even some budget vendors, I could use ARR, or even deploy NGINX. (Though supporting those deployments is another matter!) Whilst discussing this with my colleagues, the consensus was “We would be better deploying Azure Traffic Manager”. So I though I’d take a look to see just how difficult that was to deploy.
What is Azure Traffic Manager? Essentially a cloud based ADC that can provide availability and DNS failover, between Azure regions, and (more importantly in my case) ‘External‘ endpoints, (so on premises, multiple data centres, other public clouds, etc.)
What Does Azure Traffic Manager Cost? Therein lies most people’s ‘bug-bear‘ with public cloud, that’s hard to quantify. So per million DNS lookups it’s £0.403p a month (up to a billion DNS queries,) THEN £0.28p per million DNS queries (over a billion) per month. I’m not sure how you would begin to calculate that? I can tell you how many people are on this website while you are reading this text, and how many hits we get a month, but DNS queries?
I no longer host my own DNS, I used to, but it was getting hammered by script kiddies 24/7 and my servers were just using processor cycles to do nothing productive. So I pay someone else to host my records now. I asked them..
Additionally you pay: £0.403p a month per (basic) monitored external endpoint or £1.41 a month per (rapid) monitored external endpoint.
I’m being a little disingenuous to Microsoft, in their defence this is a traffic management solution NOT a web load balancing/HA solution. If you look at it from that perspective then DNS queries is a better measurement than ‘web-hits‘ or ‘page-impressions’. But you will be billed on multiples of something that you have no control over and you have to just ‘Trust’ that when Microsoft tells you you’ve had 36 million DNS lookups then that’s correct.
Deploy Azure Traffic Manager
From the Azure portal > Create a Resource.
You will need to search for ‘Traffic Manager Profile” > Create.
Give it a sensible name > Set the routing meshing to Priority > Pick a Resource group (or create a new one) > Select your resource group location > Create.
Locate your traffic manager profile (look under all resources if you can’t find it) > Configuration.
Drop the DNS TTL to 30 seconds > I’m monitoring HTTPS on Port 80> Leave the probing interval on 30 seconds > Save.
Note: this will take 3 lots of 30 seconds before it will fail over (90 seconds). If you drop the poll interval to 10 seconds then you get billed the additional ‘fast interval charges‘ I mentioned above). You can set it to 0 lots of 10 seconds to make it fail over quicker, but that’s more expensive.
Endpoints > Add.
Add your primary site in with a priority of ‘1’, the repeat for your standby site(s), with lower priorities.
Before testing, make sure all the endpoints are ‘Online‘.
Overview > Copy the DNS name.
In your own DNS config, simply create a CNAME DNS record to point to the Azure one you copied above.
Testing Azure Traffic Manager
First let’s test Azure > Ping the domain name you coped from the Azure portal, you will notice it resolves to my primary site IP (that wont respond to pings, but that’s not important for testing. Power off the primary endpoint (or disconnect its NIC). And wait 90 seconds. Then ping it again, this time the IP address it responds to has changed to my secondary endpoint. That proves the Azure Traffic Manager works.
To illustrate I’ve got a slightly different web page on my primary and secondary external node, just to prove its working.
Related Articles, References, Credits, or External Links