Azure Traffic Manager is a sophisticated, cloud-based service that routes your incoming Web traffic to various instances of your website or application, according to your precise specifications. Moving beyond traditional load balancing, Traffic Manager works purely at the DNS level. As a result, once Traffic Manager has performed its task, the user’s device can access the selected instance directly. To help you get started, we’ll first review the prerequisites for using Azure’s unique, highly efficient approach to traffic routing. Then we’ll take a good look at how to build a Traffic Manager profile that matches your users’ needs while achieving your company’s goals. Finally, we’ll walk through each step of Traffic Manager’s routing process from beginning to end.
Understanding endpoints
One of the key terms used throughout the Traffic Manager service is endpoint. Essentially, an endpoint is an instance of your site or service with a public DNS that Traffic Manager can direct Web traffic to. Before getting started with Traffic Manager, it’s important to take stock of all the instances of your website or service to envision how they will translate into Traffic Manager’s three types of endpoint: Azure, external and nested. Your Azure-hosted instances will naturally serve as Azure endpoints. Your instances hosted outside of Azure, whether on-premises or with another host, will serve as external endpoints. As a third option, you can combine multiple Traffic Manager profiles to create nested endpoints.
Note: in order for Traffic Manager to work properly, all of your endpoints either have to be static pages delivering the same content to the user, or they each need to have access to a shared database. Otherwise, changes that users make using your web service at one endpoint will not be coordinated with changes that users make at another endpoint.
Choosing a DNS name
When creating a Traffic Manager profile, you will need to choose a unique name with the following format:
example.trafficmanager.net
This will become the DNS name used when connecting to your Traffic Manager profile, albeit through an alias of your choice, given that all of the Web traffic routing takes place at the DNS level. Once your user’s local DNS server finds your Azure DNS server, the Azure DNS server will select an endpoint to direct the user to, according to the traffic-routing method you’ve chosen.
Note: once you’re ready to go live with Traffic Manager, don’t forget to update your DNS records to reflect the change above.
Choosing a traffic-routing method
Traffic manager allows you to choose from four traffic-routing methods. You can only choose one traffic method per profile. However, you can create multiple profiles, then combine them for sophisticated traffic routing. This is referred to as nesting your profiles. Note that all traffic-routing methods involve Traffic Manager endpoint health checks and automatic failover.
Priority
The priority traffic-routing method allows you to choose a preferred endpoint to direct all traffic to. If your preferred endpoint is down or otherwise unresponsive, Traffic Manager will direct traffic to the endpoint with the next highest priority, and so on.
Weighted
Like the priority traffic-routing method, the weighted method allows you to create a custom ordering of endpoints that Traffic Manager will follow, subject to endpoint availability, as it distributes traffic. However, unlike the priority method, the weighted method distributes traffic across all available, healthy endpoints. However, the amount of traffic the service allocates to each particular endpoint will reflect the specific weighting you’ve assigned to it. If you assign all endpoints the same weight, then Traffic Manager will evenly distribute your traffic across all your endpoints.
Performance
Under the performance approach, the best match for the user will be the closest available endpoint, which will have the lowest latency, or distance-driven delay, and therefore the best performance. For example, suppose you have endpoints distributed across the globe. If a given user is in Asia, then directing them to one of your endpoints in North America would be a poor choice from a performance vantage, as it would result in relatively high latency, and thus relatively long delays accessing the server.
Geographic
Similar in some respects to the performance traffic-routing method, the geographic method matches the user to an endpoint in their own region, based on the user’s local DNS queries’ location. However, the geographic approach differs from the performance approach in that it’s entirely possible for the nearest endpoint to be in a different geographic region than the user, such as a few miles across a region-defining border. In this case, the endpoint in question would be a good match for performance, but a bad match under the geographic approach.
Directing users to endpoints in their own region can hold several advantages, based on your organization’s goals. For example, if your company needs to comply with different regulatory restrictions in different regions; wants to customize the user experience based on region; or wants to track traffic by region, then the geographic traffic-routing method will make these objectives easier to achieve. However, if you choose the geographic method, Azure strongly recommends coupling it with nested-type endpoints, each of which should have at least two component endpoints within itself.
Choosing a health-check frequency
One of the most important factors to consider when configuring your Traffic Manager settings is the amount of time that the service caches DNS responses it receives from your endpoints. Known as the time-to-live (TTL) for a DNS record, in the context of Traffic Manager this value represents the time that elapses between each of the service’s endpoint health checks. The shorter the TTL, the higher the frequency of checkups and the more effective Traffic Manager will be at routing traffic away from endpoints that have gone down or are otherwise unresponsive. However, it’s not always wise to reduce the TTL to the lowest possible period to approximate real-time health-checks. This is because the more health checks Traffic Manager performs, the higher the cost to your company under Traffic Manager’s pay-as-you-go pricing structure. So as you experiment with Traffic Manager’s benefits, you will want to choose a health-check frequency that strikes a good balance between affordability and optimal traffic routing.
The underlying process
Once you’ve completed your Traffic Manager profile, added your endpoints, and updated your DNS records, Traffic Manager will begin routing your traffic. Here’s how it works:
- The user navigates to (or otherwise tries to access) your URL: example.com
- The user’s local DNS redirects them to an alias for example.trafficmanager.net, your Traffic Manager profile, which resides in the Azure cloud.
- Traffic Manager selects an endpoint to direct the user to, based on your chosen traffic-routing method.
- Traffic Manager relays the IP address for the selected endpoint back to the user’s device.
- The user’s device connects directly to the endpoint.
Leveraging Traffic Manager to achieve optimal traffic flows
As outlined above, Azure Traffic Manager shares some similarities with a traditional load balancer. However, Azure’s sophisticated, cloud-based solution works at the DNS level to allow your users to connect directly to the selected endpoint. Once you’re ready to get started, it’s time to set up a Traffic Manager profile with a unique DNS name; choose a traffic-routing method (priority, weighted, performance, or geographic); add your Azure, external and hybrid endpoints; and choose an affordable and effective health-check frequency. Finally, when you’re ready to go live with this powerful service, simply update your DNS records, then watch Traffic Manager begin routing each of your users to the destination that’s best for them and your business.
To learn more about Azure services that can help your online business grow and thrive, contact us.