Everything you need to know to implement vSphere replication

We discussed earlier the importance of vSphere replication for affordable and easy-to-implement disaster recovery. Let's examine two common scenarios for using vSphere replication. For simplicity, let's start by deploying it in a single vCenter environment.

This scenario is commonly called Single-Site vSphere replication, as it can be used to replicate a VM to storage in the same site as a form of backup, which will allow quick and easy recovery of the VM if the original gets corrupted.

An even more useful case is to replicate remote branch VMs to the main site or to another site under the control of the same vCenter. vCenter server is very efficient in managing clusters and hosts across low bandwidth high delay WAN links. I have managed a cluster that spans different continents around the world where the main cluster is located in London, while the Dubai, Hong Kong, Johannesburg and Chicago branches have their own vSphere clusters.

Deploying vSphere replication virtual appliance

The VR appliance is a dual-core 64-bit SUSE Linux VM that comes preconfigured with 4GB of RAM and two virtual disks sized at 10GB and 2GB. The VR appliance is deployed as any other OVA file using the “Deploy OVF Template” wizard. It's worth noting that unlike the earlier version, or the VDP appliance (we discussed earlier), the VR appliance is not sensitive to DNS. Actually, I completely forgot to configure a DNS entry for the VM and I was able to deploy it and use vSphere replication without any issues.

You should be able to deploy the appliance on an ESXi 4.x host, but you need to keep in mind that the appliance itself only configures and manages replication. What tracks the changes on the source VMDK is an ESXi 5.x VR agent that sends the data (through the VR appliance) to a network file copy (NFC) component on the receiving host. This means that the VR appliance needs to be able to communicate with the management network of hosts for the replication to succeed.

Once the VM is fully deployed, you need to log off the web interface and log back in to see the new vSphere Replication management icons on the main screen.

You don't need to click on those yet because we don't yet have any VMs replicated. To replicate a VM, you need to right click on a VM and you'll notice that you now have the option to “Configure Replication,” which starts its own wizard.

The first choice we need to make in the wizard is which site to replicate this VM. This is an easy choice in our case since our scenario involves only one vCenter server.

The next important thing to decide is where to store the replica. This choice will determine which hosts you can restore the VM to later as they need to have direct read-write access to the datastore. Notice that the “advanced disk configuration” check box will allow you to choose where to save each disk's replica or the ability to exempt specific disks from the replication.

If similarly named VM files are already staged on the target datastore, you can use those as replication seeds. For that, you need to use the “Browse” button after selecting the datastore. Otherwise, vSphere replication will append (1) to the name of the new folder that will host the replica's files.

The last active wizard screen allows you to specify the Recovery Point Objective and the guest OS quiescing method. As discussed earlier, vSphere replication can be configured with RPOs that range between 15 minutes and 24 hours and support MS Shadow Copy Services.

After reviewing your setting, conclude the wizard by hitting finish on the last screen.

Back to the vSphere replication's home screen

Although you can monitor the state of each VM replication from the Summary tab of the VM, the vSphere Replication Summary tab allows you to monitor the status of all incoming and outgoing replications to the local and target sites.

Recovering a replicated VM

To recover a replicated machine you right click it either on the incoming or the outgoing replication tab (since we are replicating to the same vCenter) and chose “Recover.”

Note: You can't “Recover with recent changes” if the source VM is powered on. This option would be perfect for a planned downtime like a scheduled maintenance or an anticipated disaster like a hurricane in route to hit your location. In such cases, you may have the luxury to shut down the source VMs and synchronize the replicas with the latest data before turning them on.

However, a disaster usually implies that the source VM has suddenly become unavailable or corrupted. For such cases, the best action is to cut your losses and recover the VM with the latest available data which can be performed even if the source VM is on.

Actually, this option is also useful for test recovery since the recovered VM will not automatically be connected to any network so that it doesn't conflict with the running VM.

The next item is to specify a folder for the target virtual machine. You may wish to create a “Recovered VMs” folder. I used a work-in-progress folder I already had in my environment.

The last thing to choose is the cluster, host or resource pool to host the recovered virtual machine. Notice that the host you choose needs to have access to the datastore storing the replica files.

Since my replica files are stored on the local storage esx-p, I can't use any other host as the new home of this VM.

Be careful not to overwrite any VMs on the destination that already has the same name (unless this is what you want to do).

Be aware that, as stated earlier, the virtual will be recovered with the network devices disconnected, and you will need to connect them manually after you make sure that the recovered VM is ready to go.

Is vSphere Replication between two sites more complicated?

Not at all, the concept is very much the same. The main difference is that you need to deploy a VRA at each site, and through vSphere replication, connect to the remote site to be able to replicate VMs to it.

However, you'll need to use the remote vCenter address and credentials to connect to the target site, not the VRA appliance.

Soon after, you will have a remote site connected to replicate a VM to.

It's worth mentioning that connecting Site01 to Site02 does not automatically allow administrators on Site02 to replicated VMs to Site01. For that you need to provide Site02 credentials.

To create the reverse connection, you can “reconnect” the disconnected Site01 from the second site vSphere replication “Manage” tab.

It's also worth mentioning that remote vSphere Replication Sites appear in the disconnected state often after you let your login session time out. After investigating the issue, it turns out there's no need to worry about this misleading behavior because both sites stay connected and the replication continues as scheduled. What disconnects is you connection to the remote site from the vSphere Web Client!

The following VMware diagram displays vSphere replication architecture across sites. It clearly shows that the VR agents on each host track the VM changed blocks and transfer them to VR appliance on the remote site. The remote appliance uses network file copy to commit those deltas to replica's VMDK.

What does SRM add to the mix?

As you have noticed vSphere replication does not automatically connect recovered VMs to the network. In contrast, SRM automatically connects recovered VMs to the target network. Of course, it does so after accounting for any IP address changes that may need to be performed on the recovered VM as it moves across sites. With plain vanilla vSphere replication, you'll need to take care of any IP address changes yourself.

VMware Site Recovery Manager offers much more. We may cover SRM with more details in a future article. However, for most SMBs and many larger organizations vSphere replication is a free, scalable and easy to implement solution for their disaster recovery needs.

Your trial includes access to our course on VMware vSphere 5.1 New Features!