Geographic Replication in Windows Azure

Windows Azure had some downtime this past February 29th. Let’s get the news out of the way:

Then, the facts from the Windows Azure Blog:

    I did some tinkering on a few late-nights this past week, recognizing that a reliable solution that does not include dedicated hardware (who wants to buy hardware that you might never need?) would be to locate a customer site in a site that is geographically distant from another. While this is not perfect (there are always risks):
  • Some higher-level controller goes out (in the case of Azure, this could be authentication in the Fabric Controller).
  • Risk of CNAME or DNS update delays.
  • Physical connection to a data center or region.
    What to do, what to do?
    Enter the Windows Azure Traffic Manager. Way back when (in fact, I administered a test with this question): load-balancing in Windows Azure was completely automatic. With the Windows Azure Traffic Manager, you have control over how traffic is routed to your virtual machines:
  • Performance
  • Round Robin
  • Failover

The Windows Azure Traffic Manager allows you to manage traffic between multiple instances of Web Roles for scalability and uptime, based on the criteria above. Further, you can create routing policies to manage geo-routing of incoming user requests so they go to an instance closest to the user. You can set these two policies to enable geographical failover in short order.

  • The first thing you need is a deployed hosted service. Please see the deployment lab in the WATK for details on how to set this up. Select as the primary geographical datacenter the one that suits your needs.
  • Then, you need multiple instances of your roles .. note that you need this to ensure you receive the uptime SLAs anyway. You can deploy this in your Service Configuration when you deploy your project, or in the Windows Azure Portal at runtime.
  • With your application deployed in one data center, repeat the steps above by setting up a hosted instance in a different data center and deploying your code to it. Note that these will have different URL prefixes; but don’t let that bug you.

Verify your deployments in the Windows Azure Portal. You should see both deployments in different data centers. Then:

  • Run the Windows Azure Traffic Manager from the Windows Azure Portal.
  • Create a Traffic Manager Policy, selecting your subscription and the ‘Performance’ option under Load Balancing.
    • Select the two internal DNS names for your disparate services.

With this, your solution is complete. The Traffic Manager will talk with the Fabric Controller, and when performance or access is degraded on one set of instances, it will redirect traffic to the other instances. This should increase your stability in the Cloud!

I’ll see you there.

%d bloggers like this: