Recently I was working on a demo for a customer on Azure Site Recovery Plans and I thought I share my setup in here so that it would be beneficial for someone else as well. This post includes an end-to-end demo of Azure Site Recovery Plans along with a real world sample application.
Introduction
In summary, I have an environment that has two virtual networks, one in West US 2 and one in East US. Both of the networks are connected to the on-premises via a central hub network. I have a two tier application that runs in the West US 2 region. The sample application is a Todo Application that has a DotNet core 6 web application and a SQL backend (https://github.com/sameeraman/DotNetCoreSQLDB). So the overall setup looks as below.
Experience
When you access the application in the Primary (West US 2) region, you will see the application as below.
I have enabled ASR replication on the the application server and the SQL Server. Then Create a Recovery plan under the Azure Site recovery. This process is straight forward.
In Production environments, you would normally have SQL HA/DR setup for the database to failover. Eg. You would configure SQL Always-On Replication between the two regions. You can have a asynchronously replicating database on the East US region. Then you will failover the database on the SQL Level rather than the VM level that is used in this sample.
I want to show you how to tune the failover sequence and also to customize the failover with custom script activities.
You can add custom scripts via Azure automation account runbooks to the ASR Recovery plans. This make it possible to literally do anything you want as part of your recovery plan. Some of the common uses of the custom scripts are below:
- Add a VM Behind a load balancer after the failover
- Create a Public IP for the failed over VM.
- Update NSG rules with Failed over VM IP addresses.
- Failover SQL Always on Availability Group to the DR with the Servers.
- Update DNS records post failover
In the above example, I’ll be using a custom script to update the SQL connection string, SQL Server IP address with the new IP address. I use the Invoke-AzVMRunCommand Powershell command to run a script on the server to update the connection string.
Have a look at the Runbook PowerShell script here - UpdateSQLIP.ps1
I also have another script that add a 1 minute delay for the failover between the two servers. It’s actually not required, but I have added it to showcase another use of scripts. That script can be found in the link here - Delay1minute.ps1.
So putting them all together in the Recovery plan, it looks as below.
The Runbooks in the automation Account looks as below:
When you failover using this Recovery Plan, you will see the application comes up successfully on the East US region and the application accessible using the new IP. You will see the Connection string has been updated with the new IP address after the failover.
As you can see the application has been successfully failed over to the secondary region. The orchestration was fully automated end-to-end.
Using the same recovery plan, you can also fail back to the primary region again. But I will not cover that in this blog.
Conclusion
As you can see, Azure Site Recovery Plans let’s you fully automate the application infrastructure failover and reduce the RTO in your application. It allows you to add pre and post actions for each group you failover. Azure Automation Runbook scripts make it possible to execute anything you like as pre and post tasks.
I made full video with an end-to-end demo on the above. Click on the link below to watch the video.