This post is also available in: Italian

Reading Time: 4 minutes

Another interesting feature in vSphere 5.1 is the vSphere Replication (VR) technology. This feature was first introduced on 2011 with Site Recovery Manager 5.0 (on vSphere 5.0) to protect virtual machines natively by copying their disk files to another location where they are ready to be recovered, using a VM replication technology (storage vendor independent) instead of the storage replication (storage vendor depend). It provides simple and cost-efficient replication of applications to a failover site.

The big change is that now it is a component delivered simple with vSphere editions (starting from Essentials Plus), and of course also comes bundled with Site Recovery Manager. This offers protection and simple recoverability to the vast majority of VMware customers without extra cost.

And it’s completly integrated in the new vSphere Web Client!

This feature is probably a clear replay to Microsoft move to include a similar function in their new Hyper-V3 product! But will be also a possible strike to some products in the ecosystem.

From technical point of view, it’s a non-disruptive technology: it does not use vSphere file-system snapshots nor impact the execution of the VM in any abnormal way. Since VR tracks changes at a sub-VM level, but above the file system, it is completely transparent to the VM unless Microsoft Volume Snapshot Service is being used to make the VM quiescent (and this could be handled in the write way).

It works in a similar way as on Site Recovery Manager 5.0, but now is more simple because it does not need SRM (although it could still be used) and also both the “VRMS and VRS” in the SRM 5.0 implementation of VR are included in a single “VR Appliance” now (still one per paired site and it could also support multi-site configuration!).

But note that vSphere Replication is targeted at replicating the virtual disks of powered on virtual machines only because it’s based on a disk filter to track changes that pass through it, therefore static images can not be tracked. For this reason could not be used in those cases:

  • Powered-off or suspended VMs
  • FT, linked clones, VM templates
  • VM snapshots in and of themselves are not replicated but instead are collapsed during replication (Note: Reverting from a snapshot may cause a full sync!)
  • Non-disks attached to a VM (ISOs, floppy images, etc) could not be replicated

Some interesting note:

  • Can replicate to a different format than its primary disk (for example you can replicate a thick provisioned disk to be a thin provisioned replica)
  • VMs can be replicated with a recovery point objective (RPO) of at most 15 minutes and at least 24 hours
  • Virtual Hardware 7 or later is required for VMs to be protected by VR
  • It require vCenter Server version 5.1 with the new Web Client, but can work with ESXi 5.x!
  • Both Storage vMotion and Storage DRS are supported, but with some considerations and exceptions

One important note is the dependency with vCenter Server, because on the other side you need vCenter Server to click “Recover”.If you have a single vCenter Server this could be a problem, but there is an unsopported solution descrived on this post.

Also the VA could be paired only with one vCenter Server, and this will limit the flexibility (for example in multi-site topology).

Andrea MauroAbout Andrea Mauro (2906 Posts)

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-18. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-18. Nutanix NTC 2014-18. PernixPro 2014-16. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.


Share