Search
StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

[Azure] Azure Site Recovery with ARM – Part 2

  • November 29, 2017
  • 8 min read
Cloud and Virtualization Architect. Florent is specializing in public, hybrid, and private cloud technologies. He is a Microsoft MVP in Cloud and Datacenter Management and an MCSE in Private Cloud.
Cloud and Virtualization Architect. Florent is specializing in public, hybrid, and private cloud technologies. He is a Microsoft MVP in Cloud and Datacenter Management and an MCSE in Private Cloud.

azure site recovery logo

Here is the second article of 2 for the Azure Site Recovery implementation with ARM:

  1. Preparation of the environment (Part 1)
  2. Start the replication and Failover/Failback

Replicate your first VMs

Now that the Azure infrastructure is ready, we will go to step 2 to replicate VMs/Applications. Choose from where you want to replicate VMs (On-Prem for me) and to which the Hyper-V site that you created in the first article:

replicate VMs and Applications in ARM

Select the storage account that you created previously to store replications and the network and subnet associated:

Target Configuration in Azure Console

Select VMs where you want to activate the replication:

Enable Replication in Azure Resource Manager

Choose the OS type and OS Disk. Choose data disks that you want to replicate to Azure:

Choose data disks to replicate to Azure

Apply the policy created previously:

Apply the policy in Azure Resource Manager

Replication is starting:

Replication status in Azure Resource Manager

From the Hyper-V console, you can see that the replication started:

Virtual machines replication status in Hyper-V manager

VM modification before the Failover

Before testing the failover, you need to choose the size of the VM that will be deployed and, choose the right network. In fact, you can choose to run the virtual machine in a smaller size, in degraded mode. Because my application was coded with static IP in the code, I’ll attribute the same IP address that on my local network. If you don’t provide anything, the DHCP will take the first available IP in the pool:

Compute and Network properties in Azure Resource Manager

Failover test

We can now test the failover. I turned off my infrastructure, and so, nobody can work anymore. In the Azure console, on the replication of your server (application), click on Unplanned Failover to say that your application must be deployed on Azure.

Choose the recovery point that you want to restore. I don’t synchronize last changes because my infrastructure is not available anymore and so, I’ll lose 15 minutes maximum of data in my case:

Unplanned Failover in Azure Console

The deployment of my VM on Azure is in progress:

VM deployment on Azure progress status

10 minutes later, my VM has been deployed on Azure:

Site Recovery Job - Failover

Virtual Machine Replica Overview

VNet Peering

I created a VNet Peering between the network that contains my DC and my ASR network. You can find how to do it here: https://www.starwindsoftware.com/blog/azure-virtual-network-peering

You can automate this part:

create a VNet Peering

Application testing

By connecting on my DC on Azure, I can see that I ping directly the new server (thanks to the VNet Peering) and that I can access the website:

IIS Windows Server

And by adding an NLB and creating a NAT rule, on the application port to the VM that just be deployed, my users can continue to work, just by modifying your DNS to the new public IP address:

Azure Console - Inbound NAT rules

IIS Windows Server view

Now that your application is working, you need to do a Commit of the failover:

Commit of the failover in Azure console

Failback

Your datacenter is back online, it is necessary to take back the data with the changes that have occurred. To do this, click Planned Failover:

Planned Failover in Azure Console

You want to do the failover from Azure to your Datacenter. If you lost your data, you can choose to create a new VM in your datacenter, on a specific host:

failover Azure to Datacenter in Azure console

When the failback is over, you should see this:

Microsoft Azure Planned Failover

Click on Commit to validate the change to your datacenter:

commit failover from Azure to Datacenter

The last delta is sent:

Virtual Machines replicating changes in Hyper-V Manager

Finally, the failback is done:

Failback status in Azure console

To finish, you need to activate again the replication of the VM to Azure. Click on Reverse replicate:

activate the replication of the VM to Azure

Reverse replication status

If I do the test again, from the VM who is on Azure, to the same IP who is on my datacenter, you can see that now, I’m going through my S2S VPN and that the website didn’t change anymore:

IIS Windows Server tracing route

For further

If you want to go further, here we have done the failover for only one VM. You can create a group of VM, in the Recovery Plan part to do the failover on multiple VM, at one time:

failover on multiple VM - Recovery Plan window

You can manage directly parameters of ASR infrastructure in the Azure console, without going through the Step-By-Step 🙂

manage Azure Site Recovery Infrastructure

Conclusion

This functionality is very interesting for the company who have business critical to run the business of the company. Even in degraded mode, employees can continue to work and so, lost a minimum of money to the company. So, go to ASR 🙂

Found Florent’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!