Experts Examine: DR as a Service

June 2018

Experts Examine: DR as a Service with VMware vSphere and Azure Site Recovery

Some of you may have heard of Azure Site Recovery (ASR) but haven’t had a chance to gain a deeper understand of it yet. Today, we will help you explore ASR as a DRaaS solution.

Overview

Microsoft Azure offers you the ability to failover your on-premise virtual machines running on VMware over to the Azure cloud with synchronous replication using an Azure Site Recovery (ASR). It also offers you the ability to failover VMware virtual machines from one of your data centers to another one. We will mainly focus on using ASR as a DRaaS solution in this blog!

In order to take advantage of this service, you will need to meet a few prerequisites:

  1. Azure Account with ASR subscription
  2. Azure Storage Account
  3. Azure Network

There are several on-premise components to accomplish replication and failover/failback processes. The Mobility Service agent gets deployed onto your Windows Server (64 bit) or Linux (CentOS, SUSE, OEL) VMs. It captures all written data from your protected virtual machine’s memory, then it will send that data to your Process Server which handles the replication to Azure cloud. By default, a Config Server comes with 2 other roles: Process Server and Master Target Server.

Each of these roles has specific tasks:

  • Config Server: manages replication and communication between Azure and on-premise
  • Process Server: replication gateway that caches, compresses, and encrypts data going outbound; handles push installation of Mobility Service; performs automatic discovery of VMware VMs; this is a scalable role
  • Master Target Server: handles replication of data to failback from Azure; you can deploy a dedicated role if replication traffic gets high

Here is a diagram from Microsoft ASR website to summarize the architecture:


Replication Process

How does replication work? From a high-level, it works based on these steps below:

  1. You setup all of the ASR components and a Recovery Services vault
  2. Machines start to replicate an initial copy of your data
  3. Delta changes are replicated and held in a *.hrl file

NOTE: by default, inbound traffic uses HTTPS 443 and outbound traffic uses HTTPS 9443. Machines within a multi-VM consistency group communicate over port 20004

  1. Replication traffic goes over your internet connection, but you can also use Azure ExpressRoute public peering (sorry, site-site VPN isn’t supported yet).

 

Failover Process

What does the failover process look like? Generally, it’ll look like this:

  1. Unplanned failover are only supported
  2. A single machine can be failed over or a group of them can be failed over through a recovery plan
  3. Replica VMs are created in Azure during the failover then you can commit the failover to being access your workload

 

Failback Process

The failback process is slightly more complex. You will need to meet a few requirements:

  • VMware environment for physical and virtual machine servers
  • Site-site VPN or ExpressRoute connection
  • Snapshots cannot exist on a VM since re-protection will fail
  • Process Server temporarily deployed in Azure
  • Master Target Server must be present on-premise
  • The disk.enableUUID=true setting in Configuration Parameters of the master target VM need to be configured


NOTE: you can failback from an Azure VM back to your on-premise physical server. It has to failback to a VMware virtual machine.

Here’s how the failback goes:

  1. Azure VMs are re-protected to start the replication back to your on-premise site
  2. Perform an unplanned failover VMs back to your on-premise site
  3. On-premise VMs are reprotected

 

Other details


Final Thoughts

As you can imagine, this is a robust yet flexible solution allowing for Azure’s DRaaS and cloud migrations!

Please feel free to contact APEXIS Solution Architects (Rob@APEXIS.com) if you would like to have a further discussion on DRaaS solutions.

Next time, we will discuss ASR’s ability to perform disaster recovery or VM migrations from one VMware vSphere datacenter to a secondary one.