Windows Azure Traffic Manager

Windows Azure Traffic Manager enables you to manage and distribute incoming traffic to your Windows Azure hosted services whether they are deployed in the same data center or in different centers across the world. In this hands-on lab, you will explore different load balancing policies available in Traffic Manager and how you can use them to enhance performance, increase availability, and balance traffic to your hosted services.

Overview

Windows Azure Traffic Manager is a load balancing solution that enables the distribution of incoming traffic among different hosted services in your Windows Azure subscription, regardless of their physical location. Traffic routing occurs as a the result of policies that you define and that are based on one of the following criteria:

• Performance – traffic is forwarded to the closest hosted service in terms of network latency
• Round Robin – traffic is distributed equally across all hosted services
• Failover – traffic is sent to a primary service and, if this service goes offline, to the next available service in a list

You assign each policy a DNS name and associate it with multiple hosted services. The load balancer responds to queries for the policy DNS name with the address of one of the associated hosted services that satisfies the criteria for the policy. Traffic Manager constantly monitors hosted services to ensure they are online and will not route traffic to any service that is unavailable.

In this hands-on lab, you will explore Windows Azure Traffic Manager by publishing a very simple application to multiple hosted services, each one in a different geographic region, and then create several Traffic Manager policies to evaluate how the load balancer routes traffic across these services.

About DNS Caching

The client resolver in Windows caches DNS host entries for the duration of their time-to-live (TTL). Whenever you evaluate Traffic Manager policies, retrieving host entries from the cache bypasses the policy and you could observe unexpected behavior. For example, accessing a service via the endpoint of a round robin policy will continue to yield the same host address for as long as the entry remains in the cache. In general, this is not a problem because the goal for this type of policy is to balance traffic among different clients. However, when you test the policy from a single client, you need to ensure that the DNS name is resolved for each request to observe the round robin behavior.

If the TTL of a DNS host entry in the cache expires, new requests for the same host name should result in the client resolver executing a fresh DNS query. However, browsers typically cache these entries for longer periods, even after their TTL has expired. To reflect the behavior of a Traffic Manager policy accurately when accessing the application through a browser, it is necessary to force the browser to clear its DNS cache before each request.

Throughout the lab, you will be required to access policy endpoints repeatedly to evaluate their behavior. To ensure predictable results, it is essential that you do not use a cached entry. Restarting the browser is one way to guarantee this condition, but requires closing every open browser window before each request, even those that display other sites.

To make this process simpler, the lab provides a registry script to shorten the lifetime of entries in the browser’s DNS cache. After executing the script and restarting the browser, evaluating a policy is simply a matter of waiting for the duration of the TTL and then refreshing the browser window. Note, however, that because this script changes Internet Explorer's configuration, you will only execute it inside a remote desktop session connected to one of the hosted services in the application.

For more information, see Appendix B: Configuring the DNS Cache of the Browser.

About the World Application

The World Application is a sample ASP.NET application included in this hands-on lab to represent a global application that you could scale across multiple data centers by taking advantage of Windows Azure Traffic Manager. Although it does not implement any specific functionality of its own, the application does include some useful features that can assist you in the evaluation of Traffic Manager.

Some of these features are:

1. A customizable background and caption that allows you to determine, at a glance, which of the hosted services responds to a request
2. A timer—restarted with every page refresh—that shows the remaining time on the DNS host entry’s TTL and when it is safe to refresh the page to observe the result of a policy
3. A control panel showing the status of each hosted service deployed including commands to enable or disable traffic to individual services
4. Download links for registry scripts to configure the lifetime of DNS host entries in the browser’s cache
5. A timer—restarted after every change in the status of a service—that shows elapsed time since a change in the state of a service and estimating how long it takes Traffic Manager to become aware of the change

Traffic Manager monitors hosted services by executing periodic HTTP GET requests to an endpoint that you specify when creating a policy. In the simplest case, this endpoint can be the URL to a file served by the application. Traffic Manager considers the service to be available if its monitoring endpoint responds with an HTTP status code of 200 OK within 5 seconds. For the application in this hands-on lab, this monitoring endpoint, located at the URL /AppHealth, has been implemented so that it can be disabled on demand. During the hands-on lab, you will exploit this feature to simulate a service failure.

Objectives

In this hands-on lab, you will learn how to:

• Define Windows Azure Traffic Manager policies
• Route traffic to the hosted service that offers the best performance
• Balance traffic across all hosted services
• Create a active / standby configuration that routes traffic to a primary service and, in the event of failure, to other secondary services
• Temporarily disable traffic to specific hosted services

Prerequisites

The following is required to complete this hands-on lab:

• Microsoft .NET Framework 4.0
• Microsoft Visual Studio 2010
• Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio 1.6
• Windows Azure subscription

Exercises

This hands-on lab includes the following exercises:

1. Routing Traffic for Enhanced Performance
2. Balancing Traffic across Hosted Services
3. Increasing Availability with Failover Policies
4. Managing Traffic Manager Policies

Estimated time to complete this lab: 60 minutes.