NOTE: I implemented the below example using the Azure Government cloud, however this technique will work exactly the same using the public Azure cloud.
Before we get started take a look at my other article on how I set up my 3 VMs in a cloud service and wrote a little client app to showcase the load balancing and failover behavior of load balanced sets. http://blogs.msdn.com/b/azuregov/archive/2015/06/15/configuring-high-availability-for-iaas-virtual-machines.aspx
One huge advantage of Azure is the fact that we operate many regions around the world. At the time of writing this article there are 19 public regions, and even for our Azure Government customers we offer 2 Azure regions, Iowa and Virginia. Before we get too far let’s define a few things. An Azure region is made up of one or more data centers. While the data centers in a single region are near each other, regions are separated by hundreds of miles protecting your workloads against a natural disaster. As far as I know Azure Government is the ONLY hyper scale cloud platform offering US Government customers this type of resiliency today.
Additionally, having multiple regions allows you to move workloads closer to the end customer. While the cloud is super powerful there is nothing we can do to increase the speed of light and therefor the less trips your customers need to make across the country the faster your application will perform.
Previously we have talked about Load Balanced Sets. These allow you to distribute work across multiple virtual machines in a single cloud service in a single region. The goal of this load balancer is high availability and load leveling in a single region. However, as your workload grows you might want to run your application in multiple regions. To do that we will layer on top of the Load Balanced Sets the Azure Traffic Manger. Azure Traffic Manager is a global DNS load balancer that can route your users to a Azure region depending on the rules you configure. You can read more about it here: https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-overview/
We are going to build something that looks like this:
So let’s get started. The first step is to have a workload running in two different regions. To do that I am going to deploy the cloud service I created in my last article in Iowa to Virginia.
First let’s copy the template VHD we created in Iowa to Virginia. You can do this with AzCopy (https://aka.ms/AzCopy), however I used CloudBerry Explorer as it allows you to drag and drop move things and it work with Azure Government (http://www.cloudberrylab.com/blog/cloudberry-explorer-extends-support-for-microsoft-azure/) and they have a freeware version. Make sure you keep it as a “Page” blob.
Next let’s create an Image out of the VHD we just copied over. In the management portal go to virtual machines then images then press the create button. Give it a name and description, find the vhd we just copied over, select that it has been sysprep-ed and press next.
Now we can create our VMs and load balanced set in Virginia exactly the same way we did in Iowa. I will not rehash that procedure here, please refer to my last blog post for those details. After you are done you should have 2 cloud services and 6 VMs.
Now we have 2 URLs, one for each cloud service. So our next step is to create the Traffic Manager Load Balancer to route requests to one of the two endpoints.
The first step is to give it a name and select the method. I am going to select performance so that my requests get routed to the “closest” region.
Now let’s add the endpoints to the load balancer. Drill into the Traffic Manager entry we just created and select the endpoints tab, and then the add button at the bottom of the screen. Now you should be able to select the two cloud service endpoints that we created.
Next let’s update our little test console application to point at the traffic manager endpoint (http://something.usgovtrafficmanager.net).
When I run the console application from my office in Texas, traffic manager routes me to the Cloud Service in Virginia. However, when running it from a client on the west coast I get routed to the Cloud Service in Iowa. Note my server naming convention “V” at the end for Virginia, and nothing at the end for the Iowa ones, you will probably want to have an “I” on yours.
That is, it now you have a single URL that will route users to the “closest” region, and then a load balanced set in each region to handle the load.