A recent #AzureTrivia question on Twitter asked how you would configure Azure Traffic Manager to redirect clients to the closest endpoint (a place hosting a web application). That question made me go hmm – how do you define closest?
Defining Closeness
Do you measure closeness by kilometres as the crow flies or on the road? Or do you measure closeness by how packets travel across the Internet, from the client to the actual Azure data centre? Here’s a story I tell in my Azure training when talking about this topic.
I once worked for a hosting company in Dublin, Ireland. It was the end of a workday in December and we were all excited because it was the night of our Christmas party. We were going to a restaurant in the city and the MD was paying for everything. Fun times! Sales, engineering, support, etc were in the top floor and we piled down the stairs to the NOC to get the folks who were coming off their shift. A few of us walked into the NOC and the staff were in a bit of a tizzy. A customer, not very far away from us, claimed that we were offline. Earlier that year, we did have a catastrophic outage caused by an electrician’s mistake, so we were a bit touchy about things like this. Straight away, us engineers ran back upstairs and started doing tests. The networking guys quickly verified that we were actually online, but the customer was adamant. NOC got the customer (in Ireland, remember) to run a tracert. We quickly found that the customer’s ISP connected to the rest of the Internet in Germany, and that there was a router fault in Germany that was nothing to do with us – there was an infinite loop and packets were timing out.
So this customer, only a few kilometres from us, was connected to the rest of the world through Germany. We were geographically close to the customer, but in terms of latency, the customer could have had a “closer” hosting company in Germany. When you use a phrase such as “closest” in networking, that typically means latency, and is nothing to do with an atlas or map book.
Controlling Traffic Manager
Traffic Manager is a DNS redirection Azure feature for services running across multiple Azure/other locations. The redirection of each Traffic Manager profile works in one of 4 ways:
- Priority: You can think of this as a failover method. Traffic goes to endpoint 1, if that fails it goes to endpoint 2. If endpoint 2 fails, it goes to endpoint 3, and so on.
- Weighted: This is a weight-based distribution method, i.e. load balancing. You might set one endpoint with a weight of 40 (40% in this case) and two other endpoints each with a weight of 30 (30%).
- Performance: I’ll use Microsoft’s definition here … when you have endpoints in different geographic locations and you want end users to use the “closest” endpoint in terms of the lowest network latency.
- Geographic: Using Microsoft’s definition again … users are directed to specific endpoints (Azure, External, or Nested) based on which geographic location their DNS query originates from.
So if you want to configure Traffic Manager to send clients to the closest Azure region, you use the Performance routing method.
In my above Europe example, I might have a web application running in North Europe (Dublin) and West Europe (Netherlands), unified and abstracted at the DNS level by Traffic Manager. If I set Geographic as the routing method, the customer would normally be sent to North Europe. If I set the routing method as Performance, the customer would normally be sent to West Europe because it is closer in terms of latency.
Want to Learn More Azure Stuff Like This?
If you found this information useful, then imagine what 2 days of training might mean to you. I’m delivering a 2-day course in London on July 5-6, teaching newbies and experienced Azure admins about Azure Infrastructure. There’ll be lots of in-depth information, covering the foundations, best practices, troubleshooting, and advanced configurations. You can learn more here.
