Overview of ASR for multi-tier applications using SQL AlwaysOn

Lately I have been working Azure Site Recovery. It provides some useful tools for orchestrating the failover of your on premise physical servers or virtual machines to Azure or another secondary location and then failback their original location. ASR can also simplify your Disaster Recovery plan by using Azure as a secondary site instead of requiring a secondary datacenter.  One thing that is not totally clear when first looking into ASR is how to handle multi-tier applications that use databases.  A lot of the examples I looked at showed a whole application being added to an ASR recovery plan and failed over together. While this could work if you have an extremely simple application or you are just doing some testing, this usually isn't the recommended way to to do it. I am going to give a overview of how you would use ASR for disaster recovery for an application that leverages SQL server AlwaysOn with a secondary site in Azure. A typical large, multi-tier application has a number of web and app tier servers and data being stored in a database. This approach involves running services on dedicated servers, grouping these servers into together into web, app and database tiers and then scaling out these groups of servers as needed. Typically an application leveraging Microsoft technologies will also be using Active Directory for identity. To make this all work will take a bit more planning than just setting up a recovery plan in Azure Site Recovery.

Identity:

The first thing to consider is do you need Active Directory for your secondary site and if so how do you set it up? Most likely you are using Active Directory to manage users, computers, service accounts etc.. and you will need these to keep working once the application has failed over. If this is a dev environment or you only have one domain controller that could failover with your application then you can use ASR to failover the domain controller along with your application. This would work but it could cause disruptions or outages to your primary site if anything else relies on this domain controller. If this environment has a number of applications and is running an Active Directory forest it is recommended to setup an additional domain controller for the secondary site in Azure.

Azure Requirements:

For any Azure Site Recovery installation you will need to setup a Recovery Services vault along with a storage account and an azure virtual network. The storage account and vnet must be in the same region as the Recovery Services vault.

Setup DR for SQL:

The next thing would be to setup DR for your SQL server instance. Site recovery natively supports SQL AlwaysOn through the classic portal but is not yet available through the new azure portal. This allows you to be able to select an availability group in Azure as source and a new separate virtual machine running SQL Server in Azure as a target.

First, you will need to setup a SQL AlwaysOn availability group in Azure. Then, you will also need to setup another virtual machine in Azure that is running the same version of SQL server in Azure. ASR will use this separate SQL vm as the replication target. You can then add your availability group to your recovery plan and select the SQL virtual machine and that machine will be used as a target for replication for your availability group. When failover happens the availability group would become primary on the virtual machine you setup as the target.

DNS:

For applications that are internet facing it is recommended to use Traffic manager to point to your public IP once you failover as below.

Location	Source	Target
Public DNS	Public DNS Ex. mysite.mycompany.com	Traffic Manager Mysite.trafficmanager.net
On premise DNS	mysiteonprem. mycompany.com	Public IP of on premise site

For internal applications you can just change your DNS entries for failover to the secondary site as below.

Location	Source	Target
On premise DNS	Internal URL Ex. https://mysite.mycompany.com	Site Name https://webtiervmname

Create Recovery Plan:

Finally, you would finish setting up your recovery plan by adding your web and app tiers to your plan. When adding these machines to your recovery plan be sure to add them to the correct vnet. This vnet needs to be routable to your SQL tier. ASR has the concept of groups in the recovery plan. Each group in the recovery plan will failover seperately. Each tier of your application should be setup into separate groups in the order that you would like them to come back up after failing over. Ex. Group 1 would include SQL so that it comes up first. Group 2 would include your application tier and Group 3 would come up last with your web tier.

This has been a quick overview of things you need to consider for a SQL AlwaysOn application to use Azure Site Recovery for Disaster Recovery. For more details on how to setup Azure Site Recovery you can go to the following links.

Azure Site Recovery documentation

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-overview

Azure Site Recovery and SQL Server

https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-sql