A closer look at MS Azure Site Recovery for VMware environments

Earlier this year Microsoft announced some improvements for Azure Site Recovery for VMware environments. Azure Site Recovery, or just simple ASR, is Microsoft’s Disaster Recovery as a Service (DRaaS) solution and provides both orchestration/runbook automation options and allows customers to use Azure as a failover site. The updated ASR for VMware solution is now called “enhanced migration and disaster recovery for VMware using ASR”.

Azure Site Recovery supports different scenarios:

• Protect Hyper-V virtual machines – replicate VM’s to a second datacenter or to Azure. ASR used to configure replication and runbook automation;
• Protect VMware virtual machines – replicate VM’s to a second datacenter or to Azure. ASR used to configure replication and runbook automation;
• Protect physical machine in the same way VMware virtual machines are protected.

For Hyper-V virtual machines, Hyper-V replica technology (Microsoft’s hypervisor based replication technology) is used for replication in both a dual datacenter and datacenter to Azure scenario. With Hyper-V you can also choose for SAN replication in a datacenter to datacenter scenario, ASR is used for the orchestration/automation part.

For VMware virtual machines and physical machines guest OS replication technology is used, Microsoft acquired Scout vContinuum and uses their technology for this setup. Installation of the Mobility service agent in the guest OS is required and can be automated using standard software deployment tool such as SCCM.

With the launch of the updated ASR for VMware solution, Microsoft improved the initial configuration procedure. You don’t need to install the IaaS components on Azure anymore (which was the case with the previous of the offering), the on-premises installation is still required but simplified using an MSI installer. The following figure details the ASR for VMware architecture:

The on-premises management server (virtual machine) runs the required process-, configuration- and master target service. Extra process servers can be added, depending on the number of protected virtual machines. When Azure is a replication target, standard Azure storage offerings are used to save the data. In case of a failover ASR automatically spins up the different virtual machines, following the startup order configured in the runbook. Take a note of the SLA Azure offers for virtual machines and decide if they suit your needs.

A new option for “migration and disaster recovery for VMware using ASR enhanced” is  to do a test failover to Azure. This option wasn’t available with the old ASR for VMware, but now you can do testing as well. Selecting a test network is part of the solution. Another nice addition is the integrated failback option. In the previous verison of ASR for VMware this involved a lot of manual actions, now failback is integrated and more of an automated procedure (although there are still some manual steps involved).

What surprised me is that ASR for VMware can cope with multi-virtual machine applications through consistency groups. You can create a recovery plan that groups together application workloads that are tiered across multiple machines. You can fail over those plans, and Site Recovery provides multi-VM consistency so that machines running the same workloads can be recovered together to a consistent data point. This is not something this is offered by all other guest OS- and/or hypervisor based replication technologies. By the way, ASR replication is continuous, but has an RPO threshold: if the RPO threshold is exceeded an alarm is triggered. So you can set a specific RPO (only a threshold), replication is always continuous.

As you can see, the enhanced version of ASR for VMware includes some nice improvements. To conclude this article I’ve summarised the pros en cons of this DRaaS solution.

Pros

• ASR is a DRaaS service, not requiring any initial investment. You just pay for the subscription (as any other DRaaS offering). With Azure you pay for the protected instances (per instance) and the consumed storage. You pay for compute resources if you spin up virtual machines (test failover and/or failover).
• For existing Azure customers, or planning to move to Azure, ASR is specifically an interesting option. ASR will be part of the Azure platform you are already familiar with. Notice that ASR is also offered as part of the Operations Management Suite.
• Application consistency is available for supported operating systems.
• Multi-vm consistency (consistency groups) is a new option which is very interesting.
• ASR supports near synchronous replication.
• vSphere 5.5 and 6.0 are both supported, however Microsoft recommends to use the latest vSphere version.

Cons

• Guest OS agent is required and must be installed in each virtual machine to be replicated. Most (but not all) popular 64 bits operating systems (Windows and Linux) are supported. No hypervisor based replication option available.
• Stretched layer 2 configurations are not supported by Azure, and also not by Azure Site Recovery. You can choose to move an entire L2 subnet (this involves manual configuration steps), or you are stuck to IP renumbering.
• Do some research on the Azure SLA for recovered virtual machines and determine if the SLA suits your needs.
• You cannot configure the RPO, the replication is continuous. However, you can configure an RPO threshold, which triggers an alarm if the required RPO isn’t met.

Talking about DR and DRaaS at NLVMUG Usercon 2016

If you want to know more about DR and DRaaS solutions for VMware environments, join me at the NLVMUG UserCon on Thursday March 17 in Den Bosch. I will discuss DR and DRaaS solutions in my session “Opties voor disaster recovery binnen virtuele infrastructuren – alles over DR en DRaaS” (session will be in Dutch). In this session we will have a close look at solutions like SRM, Zerto Virtual Replication, vSphere Replication, vCloud Air DR and Azure Site Recovery. Go here to register for the NLVMUG UserCon 2016!