Protecting against downtime associated with cloud outages is something that anyone deploying on ANY cloud service needs to address. While it could be easy to simply deploy your app in “the cloud” and assume that it is someone else’s problem to manage now, the reality is that while cloud providers probably have more resources and expertise to ensure your servers stay up, the ultimate responsibility to ensure that your critical application is available rests squarely on your shoulders.
Believe it or not, simply deploying your SQL Server in Windows Azure does not make it “highly available”. To make it highly available you must use traditional tools and techniques that you might use in your own datacenter. While there is some varying of opinion on this topic, I believe that SQL Server 2012/2014 high availability options are as follows:
- AlwaysOn Failover Cluster Instance
- AlwaysOn Availability Groups
- Multisite Cluster (high availability AND disaster recovery)
Regardless of which option you choose, you are going to want to become familiar with the Windows Azure Fault Domain as described below:
“Nonetheless, in Windows Azure a rack of computers is indeed identified as a fault domain. And the allocation of a fault domain is determined by Windows Azure at deployment time. A service owner cannot control the allocation of a fault domain, however can programmatically find out which fault domain a service is running within. Windows Azure Compute service SLA guarantees the level of connectivity uptime for a deployed service only if two or more instances of each role of a service are deployed”
So before you get started, when you deploy your Windows Azure VMs, you must make sure that each SQL Server and any “witness” servers reside in different Fault Domains. You do this by putting all of the VMs in the same “Availability Set”. This ensures that each server in the same Availability Set resides in a different Fault Domain, hopefully eliminating all single points of failure.
1 – VMs in the same Availability Set will be provisioned in different Fault Domains
By putting all of your VMs in different Fault Domains and configuring a SQL Server Failover Cluster or Availability Group, you are protecting against the usual types of outages that might be localized to a single rack of servers, AKA, Fault Domain. I’ve written a step-by-step article entitled Creating a SQL Server 2014 AlwaysOn Failover Cluster (FCI) Instance in Windows Azure IaaS which should help in your endeavor to build resiliency within the Azure cloud for your SQL Server.
But what happens if Windows Azure has a major outage that takes out a whole region? Natural disaster or human error would likely be the cause of such an outage. Unfortunately, at this point there is no way to stretch an Azure Virtual Private Network between two different Azure Regions, which includes: West US, West Europe, Southeast Asia, South Central US, North Europe, North Central US, East Asia, and East US. However, the Azure Virtual Private Network can support a site-to-site VPN connection with a limited number of VPN devices from Cisco, Juniper and even Microsoft RRAS.
That leads us to thinking about alternate locations outside of Azure, even our own private data center. I recently wrote a step-by-step article that explains how to extend your on premise datacenter to the Azure Cloud. Once you have your datacenter connected to Windows Azure, you can either configure AlwaysOn Availability Groups or AlwaysOn Failover Clustering (multisite) for protection from a catastrophic Azure failure. I’ve written previously about the Advantages of Multisite Clustering vs. Availability Groups, so in my lab I decided to create a 2-node SQL Failover Cluster Instance up in Azure and then add a 3rd node in my primary data center. I’ve written the detailed configuration steps in my blog post entitled Creating a Multisite Cluster in Windows Azure for Disaster Recovery.
If you rather use AlwaysOn Availability Groups, you probably want to visit the tutorials called AlwaysOn Availability Groups in Windows Azure (GUI) and Listener Configuration for AlwaysOn Availability Groups in Windows Azure. If you are using SQL 2008 R2 or earlier I’m sure you could configure database mirroring, but at this point if your are moving to Azure I’m assuming you are probably deploy SQL Server 2012 or 2014. Other technology like Log Shipping and Replication are options for moving data, but I don’t consider them high availability solutions.
If you are deploying highly available SQL Server in Windows Azure IaaS please leave me a comment; I’d love to know what you are doing. If you have any questions please leave a comment as well and I will be sure to get back to you.