Leveraging Azure Site Recovery with SQL Always On Availability Groups for Disaster Recovery to Azure

Azure Site Recovery provides a single, workload-aware disaster recovery solution for  heterogeneous IT environments.  Critical applications and workloads, whether running on Hyper-V or VMware virtual machines or physical servers can be replicated to and recovered in Azure. With ASR Recovery Plans, customers can create workload-aware recovery workflows for their applications and achieve orchestrated “single click” application recovery in Azure.

Microsoft SQL Server is the foundation for many enterprise-grade first party, third party and custom line of business applications that run inside a customer’s on-premises datacenter. SQL Server 2012 and 2014 provide enterprise-class high availability and disaster recovery technologies such as SQL AlwaysOn Availability Groups to help protect SQL databases to a remote site, such as Azure, and quickly failover during an event. SQL Availability Groups is recommended for configuring high availability for the database tier for key applications such as SharePoint, Dynamics and SAP.

Typical enterprise applications are multi-tiered: they consist of a web tier/presentation tier, a middle tier or an application tier and a SQL Server based database tier. When planning disaster recovery for such applications, it is important to plan for protection and recovery of each tier and orchestrate the inter-dependencies between the tiers during recovery.

Azure Site Recovery and SQL AlwaysON Availability Groups are complimentary and can be used in conjunction for end-to-end protection and recovery of a multi-tiered application.  Best in class DR capabilities of SQL AlwaysOn Availability Groups can be used to protect the SQL databases, while Azure Site Recovery replication can be used to replicate the web and app tiers. Finally, ASR Recovery Plans can be used to sequence the end-to-end recovery of the entire application including failover of SQL AlwaysOn Availability Groups via scripted actions as part of the ASR Recovery Plan. In the next few sections we show how these technologies come together to deliver a singleclick, workload-aware recovery plan for enterprise applications.

Typical 3 Tier App

The following diagram illustrates a sample 3-tier enterprise application. The app consists of 1) one or more Web tiers (typically scaled out and behind a load balancer) 2) one or more app servers serving application logic and 3) a high available SQL Server backend. With SQL Server 2012 and above, the recommended way to setup high availability is to configure two availability group replicas in synchronous replication mode.

Configure Protection for all Tiers

Leverage the following steps to replicate the above application to Azure using Azure Site Recovery and SQL AlwaysOn Availability Groups.

Configuring SQL Replica in Azure

1. Create an Azure Virtual Network and configure site-to-site VPN or Express Route between the on-premises site and this network.
2. Create a new SQL IaaS Virtual Machine in this network and configure it as an asynchronous availability group replica. (Note: If you require high availability for the SQL tier post failover to Azure, then configure two asynchronous replica copies in Azure)
3. A replica of a Domain controller should be setup in this virtual network.
4. Ensure VM extensions are enabled on this VM. (Note: This will be used to push SQL specific scripted actions during recovery)
5. Configure a SQL listener for the availability group using Azure’s internal load balancer (Note: Since only one ILB is supported per cloud service, configure all databases of your app to a single availability group to leverage the listener)
6. Configure the app tier to use the listener to access the database tier.

Check out the following resources to help you with above steps:

• Scripts to setup SQL AG in Hybrid IT setup
• Configuring Listener with ILB
• IaaS VM extensions

Configure Web and App tier protection

1. Complete pre-requisites for setting up Azure Site Recovery based on your on-premises environment.
2. Use ASR replication to replicate the front end and app tier VMs to Azure.
3. Configure network settings in ASR such that the app tiers and front end VMs failover to the same Azure network hosting the ILB and the SQL replica copy. (Note: The web and app tiers must failover into a different cloud service from the one in which SQL replica is deployed. ASR will automatically create a new cloud service when failing over)

Some resources to help you with the above steps:

• Configure ASR with VMM/Hyper-V
• Configure network mapping

The following diagram illustrates the end-to-end topology after the application protection has been configured

Create a Recovery Plan for full App failover

Configure SQL failover scripts

We will leverage customer script extensions and Azure Automation to configure scripted failover of SQL Availability groups:

1. Create a local file for the script to failover SQL Availability Group. The following sample script takes the path to the Availability Group on the Azure replica and fails it over to that replica instance. This script will be passed to the SQL replica VM for execution via the Custom Script Extension.

Param(
[string]$SQLAvailabilityGroupPath
)

import-module sqlps
Switch-SqlAvailabilityGroup -Path $SQLAvailabilityGroupPath -AllowDataLoss -force

2. Upload the script to a blob in an Azure storage account (In this example the blob is named “AGFailover.ps1″).

$context = New-AzureStorageContext -StorageAccountName "Account" -StorageAccountKey "Key"
Set-AzureStorageBlobContent -Blob "AGFailover.ps1" -Container "script-container" -File "ScriptLocalFilePath" -context $context

3. Create an Azure Automation Runbook to invoke the above script on the SQL Replica VM in Azure. You can use the following sample script for the purpose. You can also look at Add Azure automation runbooks to recovery plans to understand how to create Azure automation runbooks to be used in ASR recovery plans

workflow SQLAvailabilityGroupFailover
{
    param (
        [Object]$RecoveryPlanContext
    )

    $Cred = Get-AutomationPSCredential -name 'AzureCredential'
	
    #Connect to Azure
    $AzureAccount = Add-AzureAccount -Credential $Cred
    $AzureSubscriptionName = Get-AutomationVariable –Name ‘AzureSubscriptionName’
    Select-AzureSubscription -SubscriptionName $AzureSubscriptionName
    
    InLineScript
    {
     #Update the script with name of your storage account, key and blob name
     $context = New-AzureStorageContext -StorageAccountName "Account" 
         -StorageAccountKey "Key";
     $sasuri = New-AzureStorageBlobSASToken -Container "script-container" 
         -Blob "AGFailover.ps1" -Permission r -FullUri -Context $context;
     
     Write-output "failovertype " + $Using:RecoveryPlanContext.FailoverType;
               
     if ($Using:RecoveryPlanContext.FailoverType -eq "Test")
       {
           #Skipping TFO in this version.
           #We will update the script in a follow-up post with TFO support
           Write-output "tfo: Skipping SQL Failover";
       }
     else
       {
           Write-output "pfo/ufo";
           #Get the SQL Azure Replica VM.
           #Update the script to use the name of your VM and Cloud Service
           $VM = Get-AzureVM -Name "SQLAzureVM" -ServiceName "SQLAzureReplica";     
       
           Write-Output "Installing custom script extension"
           #Install the Custom Script Extension on teh SQL Replica VM
           Set-AzureVMExtension -ExtensionName CustomScriptExtension -VM $VM -Publisher Microsoft.Compute -Version 1.3| Update-AzureVM; 
                    
           Write-output "Starting AG Failover";
           #Execute the SQL Failover script
           #Pass the SQL AG path as the argument.
       
           $AGArgs="-SQLAvailabilityGroupPath sqlserver:\sql\sqlazureVM\default\availabilitygroups\testag";
       
           Set-AzureVMCustomScriptExtension -VM $VM -FileUri $sasuri -Run "AGFailover.ps1" -Argument $AGArgs | Update-AzureVM;
       
           Write-output "Completed AG Failover";

       }
        
    }
}

Create a new ASR Recovery Plan

1. In the Azure Site Recovery portal, create a new Recovery Plan and add the app and web tier VMs into the recovery plan.
2. Add a “pre group 1 boot” scripted step that will invoke the above Azure Automation in the Recovery Plan.
3. Customize the Recovery Plan by selecting “Group1” as the Start group for app tier and “Group2” as the Start group for web tier (E.g. app tier will Start up before the web tier).
4. If you have more than one VM in the web tier then you would have to add a script to create a load balancer as a post-script to Group-2
5. Save the Recovery Plan.

Failover the Recovery Plan to Azure

Once the Recovery Plan has been configured, you can use it to perform planned or unplanned failover to Azure.  ASR will failover the app and web tiers into Azure and create IaaS VMs. ASR will invoke the Azure Automation Runbook above and failover the SQL AlwaysOn Availability Group. It will then boot up the app tier followed by the web tier. The SQL listener will be updated to point to the SQL Azure Replica Instance once all the tiers are up.

Following diagram illustrates the state after a failover.

Failback from Azure back to on-premises

Once the on-premises servers return back to healthy state, you can configure replication from SQL Azure replica back to the on-premises replica copy. After that you can use a similar ASR Recovery Plan to failover the application back to on-premises.

That’s it. We now have a “single click” Recovery Plan that combines best in class technologies like Azure Site Recovery and SQL AlwaysOn Availability Groups to failover an entire application. If your application is a public facing site, then check out how you can use Azure Traffic Manager to further optimize the RTO when recovering the application.