Exercise 1: Routing Traffic for Enhanced Performance

Traffic Manager maintains a network performance table that it updates periodically and contains the round trip time between various IP addresses around the world and each Windows Azure data center. For the performance load balancing method, Traffic Manager forwards requests to the closest hosted service in terms of its network latency.

Fully evaluating the results of this policy requires accessing the application from different geographic locations. Fortunately, this does not require you to travel around the world to complete this exercise. Instead, because you are deploying the application to multiple hosted services in various regions, you can take advantage of remote desktop to log into a hosted service in each of these regions and then access the application from within the remote session. In this case, the role instance acts as both the client and the server.

Task 1 – Creating a Traffic Manager Performance Policy

In this task, you define a Traffic Manager policy that maximizes performance by forwarding traffic to the hosted service that offers the best performance for any given client. The load balancer bases its decision on performance tables that measure the round trip time of different IP addresses around the globe to each Windows Azure data center.

1. In the Windows Azure Management Portal, select the Virtual Network tab. Then, choose the Policies option under Traffic Manager and click Create on the ribbon.

   

   Figure 21

   Creating a Windows Azure Traffic Manager policy

2. In the Create Traffic Manager Policy dialog, pick the subscription where you created the hosted services for this hands-on lab.
3. Specify the load balancing method as Performance.
4. Assign the Hosted services to include in the policy from the list of Available DNS names. Add all hosted services created for this hands-on lab. To add a service to the policy, select it and then click the arrow button in the middle.
   Note:

   For subscriptions that contain a large number of hosted services, you can filter the list by typing the [appname] portion of the URL prefix in the text box shown above the list of DNS names.

5. Set the Relative path and filename of the monitoring endpoint to /AppHealth.
   Note:

   Traffic Manager performs an HTTP (GET) request against the monitoring endpoint every 30 seconds to determine the service’s health. The service must respond with a 200 OK HTTP status code within 5 seconds; otherwise, Traffic Manager considers the service unhealthy and removes it from the load balancer rotation.

   /AppHealth is the URL of the monitoring endpoint for the lab’s application that can be disabled on demand to simulate a failure.

6. Next, choose a name for the Traffic Manager DNS prefix, for example, performance.[appname], where [appname] is the name chosen for your service.
   Note:

   Traffic Manager uses the DNS prefix to build the URL for the service. Client requests to this URL are subject to the policy defined in Traffic Manager.

7. To complete the policy definition, set the DNS time-to-live (TTL) to 30 seconds.
   Note:

   The TTL determines for how long clients and secondary DNS servers cache a DNS host entry. Clients will continue to use a given hosted service until its entry in the cache expires. For this hands-on lab, the TTL is set to the lowest possible value to allow policy results and changes in the status of services to be seen as early as possible. Note, however, that lowering this value increases DNS traffic and that you should consider keeping its default value for your production services.

   

   Figure 22

   Creating a Traffic Manager policy for load balancing based on network performance

8. Click Create to save the policy definition.

Task 2 – Testing the Performance Policy

In this task, you test the performance policy defined previously. First, you test the policy from your own computer. Next, to observe the behavior of the policy when accessing the application from different geographic regions, you establish remote desktop sessions to every region where you deployed a hosted service. Inside each remote session, you browse the application to initiate a request originating from the same region as the hosted service.

1. Open a browser window and navigate to http://performance.[appname].ctp.trafficmgr.com/, where performance.[appname] is the DNS prefix name that you configured for the performance policy created in the previous task. Notice the distinctive background color and the label in the first paragraph indicating the location of the hosted service that replies to the request. Verify that the response originated from the service closest to your current location.

   

   Figure 23

   Testing the Traffic Manager performance policy in your own machine

   Note:

   For a performance policy, the load balancer determines which hosted service responds to a client request based on tables that record the round trip time between various IP addresses around the globe and each Windows Azure data center. Note, however, that while there is a strong correlation between distance and network latency and you would normally receive a response from the hosted service closest to your current location, other factors such as network topology and congestion could determine that you receive a response from a service that is further away.

2. Now, in the navigation pane of the Windows Azure Management Portal, select the Hosted Services, Storage Accounts & CDN tab and then the Hosted Services option.
3. Locate one of the hosted services created for this hands-on lab and expand its node to show its instances. Select one of the instances and then click Connect on the ribbon to open a remote desktop session to that instance.
4. Inside the remote desktop session, open a browser window and navigate to http://performance.[appname].ctp.trafficmgr.com/, where performance.[appname] is the DNS prefix name that you configured for the performance policy. Verify that the response originates from the hosted service in the same region as the remote desktop session.
   Note:

   Ensure that you connect to one of the role instances where you previously configured the DNS cache for the browser. Otherwise, click the link to download and run the registry configuration script and then restart the browser. After that, repeat the current step.

5. Open a command prompt window and type the following command:

   Command Prompt

   nslookup performance.[appname].ctp.trafficmgr.com

   where performance .[appname] is the DNS prefix name that you configured for the performance policy.

   Notice the Name and Address returned by the DNS query, which should match that of the hosted service nearest to your current location.

   

   Figure 24

   Using nslookup to determine the address returned by the performance policy

6. Next, open a remote desktop session to each of the other regions and repeat the previous steps to access the application from that region. Verify that in all cases, the response originates from the service hosted in the region where the remote desktop session is established.

   

   Figure 25

   Testing the performance policy from different geographic regions

7. Do not close the remote desktop sessions. You will need them for the following exercises.

Task 3 – Simulating a Service Failure

In this task, you place the hosted service that is currently servicing your requests in an offline state to simulate a failure.

1. In the remote desktop session, navigate to http://performance.[appname].ctp.trafficmgr.com/ and determine the region of the hosted service that responds to the request.
2. Now, locate this region in the Hosted Service Status table and click Disable to set its state to Offline. Notice that the Health Monitor Timeout column starts a timer that shows the elapsed time since the state of the service changed.

   

   Figure 26

   Simulating the failure of a hosted service

   Note:

   The Health Monitor Timeout provides an estimate of how long it takes Traffic Manager to become aware of the change.

   When a hosted service is disabled, its monitoring endpoint stops sending responses to simulate a failure. Traffic Manager performs a check of this endpoint at 30-second intervals and if it fails to receive a response to three consecutive polls, it considers the service as unavailable. Thus, it could take as much as 120 seconds for the service to failover.

   After you disable a service, a timer on the page starts showing the elapsed time since the status of the service changed, providing an estimate of how long it takes the Traffic Manager to become aware of the failure.

3. Wait until the TTL expires and the Health Monitor Timeout shows a Ready status.
4. Now, refresh the page and verify that the response now originates from a service located in a different region, presumably, the second closest region in terms of network latency.
5. Re-enable traffic to the previously disabled region and wait until the Health Monitor Timeout indicates that the change should be effective.
   Note:

   When a service comes back online, Traffic Manager detects the change in its status within the next polling interval. Thus, the interval shown by the Health Monitor Timeout when switching from offline to online is only 30 seconds.

6. Refresh the page and confirm that the response is once again from the original hosted service.