Cloud migration and disaster recovery of load balanced multi-tier applications

Support for Microsoft Azure virtual machines availability sets has been a highly anticipated capability by many Azure Site Recovery customers who are using the product for either cloud migration or disaster recovery of applications. Today, I am excited to announce that Azure Site Recovery now supports creating failed over virtual machines in an availability set. This in turn allows that you can configure an internal or external load balancer to distribute traffic between multiple virtual machines of the same tier of an application. With the Azure Site Recovery promise of cloud migration and  disaster recovery of applications, this first-class integration with availability sets and load balancers makes it simpler for you to run your failed over applications on Microsoft Azure with the same guarantees that you had while running them on the primary site.

In an earlier blog of this series, you learned about the importance and complexity involved in recovering applications – Cloud migration and disaster recovery for applications, not just virtual machines. The next blog was a deep-dive on recovery plans describing how you can do a One-click cloud migration and disaster recovery of applications. In this blog, we look at how to failover or migrate a load balanced multi-tier application using Azure Site Recovery.

To demonstrate real-world usage of availability sets and load balancers in a recovery plan, a three-tier SharePoint farm with a SQL Always On backend is being used.  A single recovery plan is used to orchestrate failover of this entire SharePoint farm.

Here are the steps to set up availability sets and load balancers for this SharePoint farm when it needs to run on Microsoft Azure:

1. Under the Recovery Services vault, go to Compute and Network settings of each of the application tier virtual machines, and configure an availability set for them.
2. Configure another availability set for each of web tier virtual machines.
3. Add the two application tier virtual machines and the two web tier virtual machines in Group 1 and Group 2 of a recovery plan respectively.
4. If you have not already done so, click the following button to import the most popular Azure Site Recovery automation runbooks into your Azure Automation account.
   

    

5. Add script ASR-SQL-FailoverAG as a pre-step to Group 1.  
6. Add script ASR-AddMultipleLoadBalancers as a post-step to both Group 1 and Group 2.
7. Create an Azure Automation variable using the instructions outlined in the scripts. For this example, these are the exact commands used.

 $InputObject = @{"TestSQLVMRG" = "SQLRG" ;
                 "TestSQLVMName" = "SharePointSQLServer-test" ;
                 "ProdSQLVMRG" = "SQLRG" ;
                 "ProdSQLVMName" = "SharePointSQLServer";
                 "Paths" = @{
                     "1"="SQLSERVER:SQLSharePointSQLDEFAULTAvailabilityGroupsConfig_AG"; 
                     "2"="SQLSERVER:SQLSharePointSQLDEFAULTAvailabilityGroupsContent_AG"}; 
                 "406d039a-eeae-11e6-b0b8-0050568f7993"=@{                             
                     "LBName"="ApptierInternalLB";
                     "ResourceGroupName"="ContosoRG"};             
                 "c21c5050-fcd5-11e6-a53d-0050568f7993"=@{
                     "LBName"="ApptierInternalLB"; 
                     "ResourceGroupName"="ContosoRG"};
                 "45a4c1fb-fcd3-11e6-a53d-0050568f7993"=@{
                     "LBName"="WebTierExternalLB";
                     "ResourceGroupName"="ContosoRG"};
                 "7cfa6ff6-eeab-11e6-b0b8-0050568f7993"=@{
                     "LBName"="WebTierExternalLB";
                     "ResourceGroupName"="ContosoRG"}}

$RPDetails = New-Object -TypeName PSObject -Property $InputObject  | ConvertTo-Json

New-AzureRmAutomationVariable -Name "SharePointRecoveryPlan" -ResourceGroupName "AutomationRG" -AutomationAccountName "ASRAutomation" -Value $RPDetails -Encrypted $false

You have now completed customizing your recovery plan and it is ready to be failed over.

Once the failover (or test failover) is complete and the SharePoint farm runs in Microsoft Azure, it looks like this:

Watch this demo video to see all this in action – how using in-built constructs that Azure Site Recovery provides we can failover a three-tier application using a single-click recovery plan. The recovery plan automates the following tasks:

1. Failing over SQL Always On Availability Group to the virtual machine running in Microsoft Azure
2. Failing over the web and app tier virtual machines that were part of the SharePoint farm
3. Attaching an internal load balancer on the application tier virtual machines of the SharePoint farm that are in an availability set
4. Attaching an external load balancer on the web tier virtual machines of the SharePoint farm that are in an availability set

With relentless focus on ensuring that you succeed with full application recovery, Azure Site Recovery is the one-stop shop for all your disaster recovery and migration needs. Our mission is to democratize disaster recovery with the power of Microsoft Azure, to enable not just the elite tier-1 applications to have a business continuity plan, but offer a compelling solution that empowers you to set up a working end to end disaster recovery plan for 100% of your organization's IT applications.

You can check out additional product information and start protecting and migrating your workloads to Microsoft Azure using Azure Site Recovery today. You can use the powerful replication capabilities of Azure Site Recovery for 31 days at no charge for every new physical server or virtual machine that you replicate, whether it is running on VMware or Hyper-V. To learn more about Azure Site Recovery, check out our How-To Videos. Visit the Azure Site Recovery forum on MSDN for additional information and to engage with other customers, or use the Azure Site Recovery User Voice to let us know what features you want us to enable next.