Use Azure as Virtual DR Site for VMware and Physical Servers

After acquiring InMage Systems in July 2015, Microsoft quickly started merging the company’s technologies into Microsoft’s cloud solutions. InMage had created a solution that allows VMware virtual machines and physical servers to be migrated to the cloud.

Although Microsoft already had a means to do this for virtual machine through Azure Site Recovery (ASR), this technology is restricted to Hyper-V virtual machines. And although Hyper-V might be growing, there’s still a huge market of VMware customers, where Microsoft isn’t about to turn down the opportunity to sell services to VMware’s customers. But now Azure Site Recovery has embraced InMage technology, where you can now use Azure as a virtual disaster recovery site for Hyper-V virtual machines, VMware virtual machines, and physical servers.

An Overview of the Solution

The solution of replication Hyper-V virtual machines to Azure, without System Center, works something like this:

1. You create an ASR vault
2. A GRS storage account will store the replicated virtual hard disks
3. A VNET will be used to connect failed over virtual machines
4. A protection group is created to define a replication policy
5. A provider is installed on hosts
6. Virtual machines are associated with a protection group and they replicate at the host level using Hyper-V Replica
7. A recovery plan is created to orchestrate failover

In the event of a failover, the recovery plan is executed, and virtual machines are created and connected to the correct VNET.

A few pieces must be deployed to replicate VMware virtual machines and physical machines because they are not using Microsoft virtual hard disks:

• Configuration Server: This is an Azure Standard A3 virtual machine running in the same subscription that is the target for replication. This machine coordinates all replication activities for VMware virtual machines and physical servers.
• Master Target Server: This is either a Windows Server 2012 R2 to replicate Windows or a CentOS 6.6 to replicate Linux Standard A3 (maximum of 8 data disks) or Standard D14 (maximum of 32 data disks) Azure virtual machine in your Azure subscription. This machine receives replicated data from the primary site and writes it to attached data disks in VHD format. These disks are the disks that will be used to failover to Azure.
• Process Server: This Windows Server 2012 R2 physical or virtual machine is deployed on premises, preferably on the same LAN as the machines it will protect. This machine will optimize (caching, compressing, and encrypting) replication traffic before sending it to Azure. It also provides automated discovery of VMware virtual machines.
• Mobility Service: This is an agent that is pushed out by the Process Server to the physical or virtual machines that you want to replicate. Replication is performed by tracking changes within the OS of the replicated machine, and this allows on-the-fly replication/conversion from VMDK or physical disk to VHDs in Azure.

As with Hyper-V replication, you create a one-click failover using one or more recovery plans. This plans allow you to group and order the failover of virtual machines and include scripted or manual actions. In other words, once you have replication in place, your experience of failing over VMware virtual machines or physical machines is identical to that of failing over Hyper-V virtual machines.

Migrating to Azure

Who knows? Maybe you’ll perform a test failover and really like how Azure works. If that is the case, then you can:

1. Perform a planned failover of your machines to Azure, minimizing the amount of down time.
2. Strip away replication, leaving the failed over Azure virtual machines where they are.
3. Remove the failed over infrastructure from your primary site, and maybe install a few extra desks or a nice coffee machine in the reclaimed space.