Windows Azure Traffic Manager Overview

The Performance load balancing method knows the origin of the traffic and routes it to the closest hosted service. “Closeness” is determined by a network performance table showing the round trip time between various IP addresses and each Windows Azure data center. This table is updated at periodic intervals and is not meant to be a real time reflection of performance across the Internet. This method does not take into account the load on a given hosted service although WATM monitors your hosted services based on the method you choose and does not include them in DNS queries if they are down.

The following graphic shows the general process for the Performance load balancing method.

Figure 4 - Conceptual flow of the Performance load balancing method for Windows Azure Traffic Manager

The following numbered steps correspond to the numbers in the diagram (Figure 4).

1. Performance Times Table built periodically: The traffic manager infrastructure runs tests to determine the round trip times between different points in the world and the Windows Azure data centers which run hosted services. These tests are run at the discretion of the Windows Azure system.
   
   
2. Incoming request: Your Traffic Manager domain receives an incoming request from a client computer.
   
   
3. Performance table lookup: Traffic Manager looks up the round trip time between the location of the incoming request and the hosted services that are part of your policy using the table created in step 1.
   
   
4. Best performing service chosen: Traffic Manager determines the location of the hosted service with the best time. In this example, that is HS-D.
   
   
5. DNS name returned: Traffic manager returns the DNS name of hosted service D to the client machine.
   
   
6. Service call: The client computer resolves the DNS name to the IP address and calls the hosted service.
   
   

Points to note:

• When the performance table is updated, you may notice a difference in traffic patterns and load on your hosted services. These changes should be minimal.
  
  
• The DNS Time-to-Live (TTL) informs the Local DNS resolvers how long to cache DNS entries. Clients will continue to use a given hosted service until its local DNS cache expires.
  
  
• Traffic Manager monitors the state of the hosted services in your policies and will not send traffic to those it sees as down. If all hosted services in the policy are detected to be offline, Traffic Manager acts as if all hosted services in the policy are actually online so it will at least resolve the DNS name to an IP address, even though the client computer will call a hosted service that may not respond. For more information about how hosted services are monitored, see Monitoring hosted services in Windows Azure Traffic Manager.
  
  
• For information about the Service Management API for Traffic Manager, see Operations for Traffic Manager.
  
  

If the primary hosted service is offline, traffic is sent to the next in order. If both the 1st and 2nd hosted services in the list are offline, the traffic goes to the 3rd and so on.

Figure 5 - Conceptual flow for the Failover load balancing method for Windows Azure Traffic Manager

The following numbered steps correspond to the numbers in the diagram (Figure 5).

1. Your Traffic Manager domain receives an incoming request from a client.
   
   
2. Your policy contains an ordered list of hosted services. Traffic Manager checks which hosted service is first in the list. It verifies that the hosted service is online. If the hosted service is unavailable, it proceeds to the next online hosted service. In this case HS-A is unavailable, but HS-B is available.
   
   
3. Traffic Manager returns the DNS entry to the client. The DNS entry points to the IP address of HS-B.
   
   
4. The client calls HS-B.
   
   

Points to note:

• The DNS time-to-live (TTL) informs the Local DNS resolvers how long to cache DNS entries. Clients will continue to use a given hosted service until its local DNS cache expires.
  
  
• Using a failover load balancing method without monitoring is not useful because all traffic will always be sent to the primary hosted service.
  
  
• Traffic Manager monitors the state of your hosted services and will not send traffic to hosted services it thinks are down.
  
  
• If all hosted services in the policy are offline, Traffic Manager returns the DNS name of the primary hosted service.
  
  
• For information about the Service Management API for Traffic Manager, see Operations for Traffic Manager.
  
  

The Round Robin method splits up traffic across various hosted services. It keeps track of the last hosted service that received traffic and sends traffic to the next one in your list of hosted services. If you have set up monitoring, this this method will not send traffic to hosted services that are down.

For more information, see Monitoring hosted services in Windows Azure Traffic Manager.

For information about the Service Management API for Traffic Manager, see Operations for Traffic Manager.

The following graphic shows the general process for the Round Robin routing method.

Figure 6 - Conceptual flow for the Round Robin load balancing method

The following numbered steps correspond to the numbers in Figure 6.

1. Your traffic manager domain receives an incoming request from a client.
   
   
2. Your policy contains an ordered list of hosted services. Traffic Manager knows which service received the last request.
   
   
3. The Traffic Manager sends the DNS entry that points the next hosted service in the list back to the client computer. In this example, this is hosted service C.
   
   
4. The Traffic Manager updates itself so that it knows the last traffic went to hosted service C.
   
   
5. The client computer uses the DNS entry and calls hosted service C.
   
   

Points to note:

• The DNS time-to-live (TTL) informs the Local DNS resolvers how long to cache DNS entries. Clients will continue to use a given hosted service until its local DNS cache expires. 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.
  
  
• Traffic Manager monitors the state of hosted services and will not send traffic to hosted services it thinks are unavailable. If all hosted services in the policy are unavailable, Traffic Manager acts as if all hosted services in the policy are actually available so it will at least resolve the DNS name to an IP address, even though the client machine will call a hosted service that may not respond.
  
  
• For information about the Service Management API for Traffic Manager, see Operations for Traffic Manager.
  
  

• Services should be in a single subscription – All hosted services must be in the same subscription where you are creating the policy. You cannot add hosted services in different subscriptions to a single policy.
  
  
• Production services only – Only hosted services in a production environment are available for routing. You cannot route to services running in a staging environment. Note that if you perform a VIP swap while a policy is routing traffic, the traffic will now use the hosted service just swapped into the production environment.
  
  
• Name your hosted services so they can be easily found and clustered into policies –The Traffic Manager Create Policy and Edit Policy dialog boxes allow you to perform a "contains" search on the DNS name of the hosted service. Note the DNS name is different than the hosted service name. The DNS name is used because it is guaranteed to be unique in a subscription, while the name of the hosted service may not be. In order to avoid confusion, give a hosted service a name and DNS prefix that are the same or similar. If you have over 20 hosted services, bad naming can make finding the correct hosted service difficult. Badly named hosted services will make policies difficult to maintain and prone to errors.
  
  
• All services in a policy should service the same operations and ports – If you mix your hosted services, it becomes more likely that a client will call a hosted service that cannot service its request.
  
  
• All services in a policy must use the same monitoring method – You can only chose a single path and file to monitor all hosted services in a given policy. If you move services from one policy to another and you have different methods of monitoring those services, some hosted services in the policy will appear to be consistently offline. As a result, these "offline" services will never have their IP addresses handed out to clients and thus never receive traffic. You can enter "/" in the Relative path and filename text box so that monitoring will try to access the default path and filename.
  
  
• Keep monitor charges low – Keep in mind that although there is no charge for Traffic Manager, its monitoring transactions are included in monthly data transfer costs.
  
  

• Use the disable policy and disable hosted services methods rather than changing a policy – In many cases, you may wish to take a hosted service or an entire policy offline. Rather than modify the policy, simply disable individual hosted services or alternately the whole policy. For more information, see Temporarily Disable Policies and Hosted Services in Windows Azure Traffic Manager.
  
  

• Storage – How you design the location and distribution of your storage is an important consideration when using Traffic Manager. Think of the end-to-end transaction and how your data will flow when you design and deploy your applications for Traffic Manager.
  
  
• SQL Azure – Similar to storage design and analyze your application state and data requirements when you extend your hosted service to multiple geographic regions.
  
  

• Make your prefixes unique and easy to understand – Traffic Manager domains must be unique. You can control the first part of the domain only. The Traffic Manager domain is used for identification and routing purposes only. Client machines will never use the domain name so it does not necessarily need to be easily readable. However, policies are identified by this domain so it is important that you be able to quickly identify it from other domains listed in the Management Portal interface.
  
  
• Use dots to add uniqueness or make domains readable – You can use periods to separate parts of your domain name prefix as well.  If you are planning to create multiple policies in Traffic Manager, use a consistent hierarchy to differentiate one service from the other. For example, Contoso has global services for web, billing, and utility management. The three policies would be web.contoso.trafficmanager.net, bill.contoso.trafficmanager.net, and util.contoso.trafficmanager.net. When setting up hosted services use names that include location, for example, web-us-contoso.cloudapp.net and web-asia-contoso.cloudapp.net.  Your limitations are those imposed by DNS and the size of the edit box in the Create Traffic Manager policy dialog box. Assume a domain name is a sequence of labels separated by dots ( label.label.label.label.etc.). At the time of this documentation, the limits for domain names in Traffic Manager are as follows:
  
  
  • Each label can be a maximum of 63 characters.
    
    
  • You cannot have more than 40 labels total. Since two labels are taken up by trafficmanager.net, that leaves 38 for your prefix.
    
    
  • The entire domain can be a maximum of 253 characters. Keep in mind that trafficmanager.net takes up 19 of those characters.
    
    
• DNS TTL (time-to-live) - The DNS time-to-live (TTL) value controls how often the client’s local caching name server will query the Windows Azure Traffic Manager DNS system for updated DNS entries. Any change that occurs within Traffic Manager, such as policy changes or changes in hosted service availability, will take this period of time to be refreshed throughout the global system of DNS servers. We recommend you leave the setting at the default value of 300 seconds (5 minutes).