Azure Site Recovery (ASR) allows Microsoft Azure to be used as a disaster recovery site for your virtual machines. You can read up on the blog from Brad Anderson about announcement of preview of disaster recovery to Azure using Azure Site Recovery to know more about ASR.

When an administrator is thinking about adding disaster recovery capabilities to an application, they need to think through and plan the networking infrastructure so that the application is accessible by users after failover with minimal downtime. This post explains how to setup the required networking infrastructure with the help of an example. We will start with describing the application and then we will look how to setup networking on-premises and on Azure and then concluding with how to do a test failover and a planned failover.

 

1. The application

In this example we will take a two tier IIS based application which is using SQL Server as a backend.

 

In the above diagram, we have an organization called Contoso which has an active directory setup. There is a two tier IIS web application which uses SQL Server as its backend. SQL Server is authenticated using Windows authentication and all virtual machines are joined to domain contoso.com The application is accessed both by the user sitting inside the organization’s premise and by the mobile workforce. Employees that are not in the organization premise use VPN to connect to the organization’s network.

 

2. On-premises Network

The on-premises infrastructure for contoso.com is managed by a VMM 2012 R2 Server. A VLAN based logical network named Application Network has been created on the VMM Server. A VM Network named Application VM Network is created using this logical network. All the virtual machines in the application use Static IP, therefore a static IP pool is also defined for the logical network. Note: If the virtual machines are configured to use DHCP then static IP Pools are not required.

Logical Network

VM Network In all three virtual machines, the domain controller which is the SQL backend and the IIS frontend are added on the VM network described in the step above. Below are the Static IPs that are given to each of the virtual machines

• Active Directory and DNS – 192.168.0.3
• SQL Backend – 192.168.0.21
• IIS Frontend – 192.168.0.22

 

3. Azure Network

Read up on the Azure Virtual Network overview to get the basics about Azure virtual networks. An Azure Virtual Network named AzureNetwork is created in Microsoft Azure. While creating this network, the IP of the on-premises DNS Server is given as the DNS Server IP (192.168.0.3 in this case). Point to site connectivity as well as site to site connectivity are also enabled on this network.

We use address range of 10.0.0.0 – 10.0.0.255 for the AzureNetwork

It’s important to note that we use an address range different from the on-premises address range for two main points:

• We want to establish site to site connectivity with the on-premises network. A S2S gateway can’t have same IP ranges on both sides of the network
• If there are multiple applications running on-premises, we want the capability to failover only some of the applications rather than the complete subnet

 

Note: If the above two requirements are not there, we could have defined an address range exactly similar to the on-premises address range.

 

4. Setting up site to site connectivity and AD replication

Network in Azure should be just an extension of the on-premises network so that applications can move from one site to the other seamlessly. Azure allows you to add site to site connectivity to virtual networks created in Azure. You can add site to site connectivity either at the time you are creating it or at a later point of time. Here is a step by step guide for adding site to site connectivity to an Azure virtual network while creating it. Similar steps can also be followed if you want to add site to site connectivity at a later point.

Once the connectivity between two sites is setup, we can create an Active Directory and DNS Server in Azure. We do this so that the applications running in Azure don’t have to go to on-premises AD and DNS for each name lookup and authentication request. Follow the steps below to create an active directory in Azure:

1. It is recommended that you create a separate site for AzureSite in the on-premises Active Directory using Active Directory Sites and Services
2. Create an IaaS VM on the network created in Step-3
3. Use Server Manager to install Active Directory Domain Services and DNS Server roles
4. While promoting the server to a domain controller, give the name of the on-premises domain contoso.com. The IaaS virtual machine should be able to resolve contoso.com as in Step-3 we gave the IP of on-premises DNS Server as the DNS
5. Add this active directory in the Active Directory site named AzureSite if you have created one

Since now we have a DNS Server running in Azure, it is better to use this for the IaaS virtual machines that are created from now on. To do this, we go to the AzureNetwork and modify the DNS Server IP to provide the IP of the virtual machine created in the step above.

 

AD Replication Frequency: The frequency of DNS records replication can be changed using Active Directory Sites and Services. You can follow this document for scheduling replication between active directory sites

Is it mandatory to replicate Active Directory and DNS to Azure? If you are planning for a complete site disaster then yes it is mandatory to replicate active directory to Azure. But if you for foresee that you will be doing planned failover of only some of the applications at a time and if the applications are not too chatty with respect to communication with active directory and DNS, then you can choose to not to replicate active directory and DNS to Azure. In such a case you can provide the IP of the on-premises DNS Server in the network that you create in Azure.

 

5. Setting up point to site connectivity

Once the application is failed over to Azure, we want it to be remain accessible to the mobile workforce. To accomplish that, we need to create point to site connectivity to the AzureNetwork. This document provides a step by step guide to setup a point to site vpn to an Azure virtual network. Once we have this setup, the picture would look like the diagram below:

 

6.    Creating a test network

Azure Site Recovery provides you the capability to do a test failover without impacting the production workload. For this step, a separate Azure virtual network is required. Create another network and use the same IP ranges as used in the network created in Step-3. Let us call this network AzureTestNetwork. Don’t add site to site connectivity and point to site connectivity in the network just yet.

 

7.    Setting up Azure Site Recovery

Now that we have the infrastructure setup, we will have to complete the following steps in ASR:

1. Configure Cloud
2. Map ‘Application VM Network’ to AzureNetwork
3. Enable protection on
   1. Active Directory – Although we use AD replication for replicating AD to Azure, we require an instance of AD during the test failover. This is why we are enabling protection on AD using ASR as well. How an AD would be used in a test failover is covered later in this blog in Section-9
   2. IIS Frontend
   3. SQL Backend

This post does not go into details of these steps as they are covered very well in the ASR getting started guide and ASR deployment guide. Once we have this setup, the picture would look like the following diagram:

 

8. Creating a Recovery Plan

We create a recovery plan by adding two VMs, IIS Frontend and SQL Backend, in it. We then customize the recovery plan by adding one more group and moving the virtual machine IIS Frontend to Group2. We want to failover SQL Backend VM first before the IIS Frontend VM is started up so that the IIS application is able to successfully come up. The recovery plan should look like this:

9. Performing a test failover or a DR drill

Organizations are required to perform test failovers or DR drills at a regular frequency to check the readiness of the disaster recovery setup and for compliance needs. ASR provides the capability to do a test failover without impacting your production workload. For doing a test failover or a DR drill we will use the test network in Step-6. We will follow the steps below to execute the DR drill:

1. Go to AD virtual machine in ASR and do a test failover of it in AzureTestNetwork
2. Once the IaaS virtual machine is created for AD in AzureTestNetwork, check the IP that has been provided to this virtual machine
3. If the IP is not same as what was given to DNS of AzureTestNetwork, modify the DNS IP to the IP that AD VM has got. Azure starts giving IP from the 4^th IP of the IP range defined in virtual network. If the IP range added in the network is 10.0.0.0 – 10.0.0.255, the first VM that is created in this network would get IP 10.0.0.4 . As AD would be the first machine to be failed over in a DR drill, you can predict the IP that this VM is going to get and accordingly add that as the DNS IP in AzureTestNetwork
4. Go to the recovery plan created in Step-8 and do a test failover in AzureTestNetwork. When the virtual machines failover and start up in Azure, they go and register themselves in DNS that was failed over in AzureTestNetwork. After this the AD-DNS VM running in AzureTestNetwork would have the updated IP for the two virtual machines in the recovery plan. Note that this IP could be different from the on-premise ip of the virtual machine even if the virtual machine was using a static ip.
5. Create an IaaS virtual machine in AzureTestNetwork
6. IIS application should now be accessible from this IaaS VM using https://iisfrontend/
7. Once the testing is complete, you can mark the test failover complete from the Jobs view in ASR. This will delete the virtual machines that were created on AzureTestNetwork

 

 

10. Performing a planned failover

In order to perform a planned failover of the application, we will need to go to the recovery plan created in Step-8 and then execute planned failover. Once the planned failover is complete and the virtual machines start in Azure, they go and update their IP in DNS running Azure. The new IP gets propagated to the DNS running on-premises based on the replication frequency you might have set in Step-4. You can also choose to do an on-demand replication of DNS records by going to Active Directory Sites and Services and expanding one of the sites, domain controller till NTDS settings. Right clicking on NTDS settings would give you an option to replicate to or from the selected domain controller:

Once the DNS records are replicated and the Time-To-Live (TTL) of the DNS record has expired, the application should be accessible from the on-premises client or from a client connected to AzureNetwork using P2S VPN:

 

 

 

In this post, we reviewed how we can setup disaster recovery for a two tier IIS based web application which uses SQL Server as its backend. We covered how a domain controller and dns can be setup to enable doing a DR drill or a planned failover. Additionally, we looked at how site to site and point to site connectivity can be setup with the azure virtual network allowing end users to seamlessly access the application even after a failover.

If you have further questions, please visit the Azure Site Recovery forum on MSDN for additional information and to engage with other customers.

You can also check out additional product information, and sign-up for a free Azure trial to start trying out Microsoft Azure using Azure Site Recovery.