I am quite a new candidate to vSphere Replication and have seen quite a few appliances deployed in our production environment as we are offering Disaster Recovery to Cloud (DR2C) services to our customers in vCloud Air and often have to troubleshoot issues related to replication.

So to understand how disaster recovery works and what should be the area we should be looking for while troubleshooting replication issues, I decided to try my hand on learning and deploying vSphere Replication in my lab.

So let’s begin with understanding what is vSphere Replication and its architecture and what components are involved in setting up disaster recovery environment.

What is vSphere Replication?

Earlier vSphere Replication was a feature of Site Recovery Manager (SRM) that automates the failover of virtual machines to a recovery site. vSphere Replication enables the replication of virtual machines (VMs) at the virtual layer instead of at the storage layer, as was required with earlier versions of vSphere and SRM.

At VMworld 2011 VMware announced the virtual machine (VM) replication feature of Site Recovery Manager (SRM). In the Essentials Plus and higher editions of vSphere 5.1, VMware has included a “lite” version of SRM’s VM replication feature.

As of vSphere 5.1, VMware started including vSphere Replication with the base licenses without needing its own license or a Site Recovery Manager (SRM) license.  What this means is that whether you’re running vSphere Essentials Plus or vSphere Enterprise Plus, you can use vSphere Replication without any additional cost.

Components of vSphere Replication

vSphere Replication requires your vSphere infrastructure ready i.e Esxi hosts, vCenter Server and other components of infrastructure such as DNS, NTP etc.

The vSphere Replication appliance is a small download from VMware and is installed on top of the SUSE flavour of linux. When you download the replication appliance iso from VMware.com and extracts it you will see 2 different ovf files:

1: vSphere_Replication_OVF10.ovf which is the virtual machine descriptor for the vSphere replication (manager) appliance – used for SRM OR single vSphere Replication

2: vSphere_Replication_AddOn_OVF10.ovf which is the virtual machine descriptor for the vSphere replication server – can be used to balance the load and increase the maximum number of replicated VMs.

vSphere Replication Appliance (VRA)

The vSphere replication (manager) appliance is the ‘brain’ in the vSphere replication process and is registered to the vCenter. VRA stores its configuration and data in the embedded Postgres SQL database. We can also use an external SQL database.

The vSphere Replication Appliance also includes 1 vSphere Replication Server . Only 1 vSphere Replication Appliance can registered with a vCenter.

vSphere Replication Server (VRS)

The vSphere Replication Server in general is responsible for the replication job (data gathering from source-ESXi and data transferring to target-ESXi using NFC technology). One vSphere Replication Server (VRS) supports up to 200 replications. We can have a total of 10 VRS/vCenter Server.

How vSphere Replication work?

The approach used by vSphere Replication to achieve DR is to replicate the VMs from the vSphere layer rather than from the storage layer. We need a vCenter Server on the DR side along with hosts to support the VMs. By using vSphere Replication you can replicate only the VM(s) you require, set the schedule of how often to true-up the replica, and how many replicas to keep for how many days!

vSphere Replication uses vSphere Changed Block Tracking (CBT) feature, copying only changed blocks to the recovery site. This lowers bandwidth utilization and makes it easier to achieve lower recovery point objectives (RPOs) than doing a full-system copy of VMs. vSphere Replication supports RPOs from 15 minutes to 24 hours.

vSphere Replication can be paired with Site Recovery Manager (SRM) in order to automate some of the failover process, but that’s not free.

If you have worked with vSphere Replication in past and wondering what new features have been added to vSphere Replication 6.0, I would recommend reading this Blog by Vladan Seget.

Use cases for using vSphere Replication

Case#1 From a single source to a target site

In this approach we replicate a VM from a single source and replicate it to a target site. You can have an environment within your premise, the other one can be down the streets or in a different city or even in a different country. You will be replicating your VM’s from one source site to a target site, much like a one to one mapping.

This is also known as cross-site replication.

As a target site you can choose a company who rents out datacenters/servers. The target site will receive incoming replications from one or more production sites.

Constraints: The success of  cross-site replication depends upon having a good network connectivity between primary and target site. Also, the servers in the disaster recovery environment must be sized large enough to support the recovery of the biggest production site.

Case#2 Within a single site, from one cluster to other

Let’s say you have multiple different cluster created for spreading out workloads or having different sets of hardware in each cluster, and you want to have multiple copies of your VM’s within same datacenter. This is possible using vSphere Replication to replicate your VM’s around different clusters just to have a second copy of your workloads within same location.

Constraints: Dedicated piece of hardware is needed for the recovering VM’s. On top of that we also need dedicated hardware, separated from production, to host the management tools (vCenter Server, vSphere Replication appliance, and other infrastructure components) if we want to protect a complete production cluster.

Case#3 From multiple source site to a shared remote target site

In this case you have one offsite datacenter, to which all your primary datacenters are replicating their virtual machines.

Case#4 Replicating to secondary storage in same cluster

For smaller installations, like lab environments or in a small remote branch, we don’t need to replicate to a remote location. In fact, if you had a single host running a virtual vCenter Server with redundant local storage where all of your VMs run you could simply add another source of storage and replicate to that.

So, really, the end result is that you leverage the vSphere Replication appliance to handle replicating the VM(s) on a schedule to storage other than your default, active storage.

With this introduction to vSphere Replication completes here. In next posts of this series we will have a look into how to setup a lab environment and install/configure Replication appliances.

I hope you enjoyed reading this post. Feel free to share this on social media if it is worth sharing. Be sociable 🙂