Geo-Distributed Services and Other Examples with the Windows Azure Traffic Manager

In April, Microsoft introduced a new component to the Windows Azure platform called Windows Azure Traffic Manager.  Traffic Manager, falling under the Windows Azure Virtual Network, allows for the ability to control how traffic is distributed to multiple hosted services in Windows Azure.  These services (i.e. web site, web application, or web services) can be in the same data center or in different data centers across the globe.

You may be wondering how this is different from the load-balancing provided by Windows Azure for your hosted service.  Windows Azure provides load-balancing across all of the instances you have running in a single Windows Azure service.  The big difference here is that Traffic Manager is not custom load-balancing for a single service but for multiple services.  This means that I can deploy my service several times (even to different regions), have my end-users hitting a single address, and control how those end-users are routed to those difference services.  Really cool.

How Traffic Manager Works

One of the great things about Traffic Manager is that it adds very little overhead.  This is because of the way it uses DNS.  A custom domain name is registered to a Traffic Manager address.  The first time a user requests the domain name, Traffic Manager resolves the DNS entry for the domain name to the IP address of the hosted service based on the defined traffic policy.  After that, the user talks directly to the hosted service until their DNS cache expires, at which point they would repeat the process.

Traffic Manager provides three different policies for routing traffic:

• Performance:  Routes requests to the nearest service based on the incoming request’s location.
• Failover: Routes requests based on health of the services.
• Round Robin: Distributes requests equally across the hosted services.

Traffic Manager also provides monitoring of the hosted services regardless of the policy being used to ensure they are online.  You have the ability to configure protocol, port and path for monitoring.  The monitoring system will perform a GET on the file and expects to receive a 200 OK response within 5 seconds.  This occurs every 30 seconds. A service is deemed unhealthy and marked offline if it fails 3 times in a row.

Traffic Policy Examples

So what are some examples of when you would use one of these policies?  Here are a few:

• Performance Policy Example:  Building a Geo-Distributed service.  If you have users using your service around the globe, deploy your hosted service into multiple regions (i.e. US, Europe, Asia) and have your users routed to the nearest location.
• Failover Policy Example:  Having a “hot” standby service.  If the primary service is offline, requests will be routed to the next in order, and so on.
• Round Robin Example:  Increased scalability and availability within a region.  Spread the load across multiple services with multiple instances.  Note that Traffic Manager still monitors health and will not route a request to a service that is down.

I tend to align the Failover and Round Robin polices in an “availability” category.  Both are ways to further improve the availability of services.  I would be really curious to see the impacts of availability in terms of Windows Azure’s SLA of 99.95%.  I wonder if using either of these policies can reliably extend the actual availability beyond these numbers, for applications with the need for more “nines”.

Using Traffic Manager for Monitoring

One of the things I have been asked before is if there is any monitoring capability included for your Windows Azure services.  Traffic Manager now provides some capabilities in this space.  Instead of adding third-party URL based monitoring to a web site hosted in Windows Azure, you can now leverage the monitoring capabilities provided by Traffic Manager to do the same thing.  In addition, a developer can even create transactional test endpoints or smoke test endpoints that exercise key behaviors of the system, and have Traffic Manager hit these endpoints every 30 seconds as well.

Using Traffic Manager for Geo-Distributed Applications

One of the largest scenarios that Traffic Manager addresses is the ability to build geo-distributed applications.  What does it mean to have a geo-distributed application?  This refers to the service being deployed into multiple data centers around the world.   Delivering high-performance, low-latency experiences for applications that have a geographically distributed user base is a real challenge.  This will be even more important in the mobile and social application industries.  The expectation of end-users is that the applications they use will be available and perform to the same level that they are accustomed to everywhere.  With the growth of mobile apps and smart phones, the need for geo-distributed architectures will grow as well.

With Windows Azure, it is easy to deploy your hosted service package into multiple regions.  But there are challenges in terms of data and storage that come with distributing your front and middle tier.  Mainly, you should not simply deploy your hosted service into multiple regions without considering where your hosted service will store its data.  You would not want a web application in Europe talking to a database in the United States for performance considerations.  There are a couple of options that I will point out for addressing your data and storage:

• Leverage SQL Azure Data Sync:  This technology can keep multiple SQL Azure databases in sync with each other, even across regions.
• Leverage Worker Roles for Custom Sync:  Build a worker role to move necessary data into appropriate regions.  This may be useful if you are leveraging Table Storage and BLOB Storage.
• Leverage CDN wherever possible:  Store data in BLOB Storage and enable the CDN to act as a distributor of content to all other regions.

Let’s dive into a mobility scenario. This diagram depicts a mobile application being used from 2 different parts of the globe.  You can see the clients connected to Traffic Manager initially, and then talking directly to the local hosted service layer in Windows Azure.  The service layer talks to SQL Azure as a relational database in the same local region.  SQL Azure Data Sync is used to keep data synced across all of the SQL Azure databases in all the regions.

In this scenario, we showed users on different continents.  But this use could be just as effective for users on the same continent, especially if the number of Windows Azure regions grows in the future.

Get Started

Windows Azure Traffic Manager is currently available as a CTP (Community Technology Preview).  You can sign up for the preview from the Windows Azure Management Portal and try it out today.

Resources

• Windows Azure Virtual Network
• Getting Started with Windows Azure Traffic Manager
• Cloud Cover on Channel9: Windows Azure Traffic Manager

More about Slalom Consulting’s Seattle office.	More about Slalom Consulting’s Cloud focus.

Subscribe to be emailed about new Cloud posts.

Subscribe to be emailed about new Mobility posts.