VMware SRM 5.1 and vSphere Replication – New release – 64bit process, Application Quiescence

vSphere Replication

The vSphere Replication (VR) is bundled with SRM. It's a in my opinion step in the right direction concerning the costs for SMBs, since Array Based replication was clearly outside of the budgets for small shops and those SMBs usually used other software solutions (Veeam for example), to create and manage their DR plans. The vSphere replication started to be part of vSphere 5.0 and in the 5.1 release it's been further improved and enhanced. The VR agent is a component of vSphere 5.x hypervizor, so vSphere 5.0 and vSphere 5.1 will both works for VR.

vSphere replication is hypervizor based replication which works at the host level. Not at the array level (like SRM) .You don't have to have identical SANs on boths sides, or even you can leverage of use of local disks (local datastores) on the DR site, to lower the costs even further. The VR can use local disk, SAN, NFS, and VSA to replicate VMs from one host to another on local site, from local to remote or from remote to local.

How it works?

Within the RPO defined by the admin, VR tracks which blocks are being dirtied and will create a “lightweight delta” (LWD) bundle of data to be transferred to the remote site.

Pointers to changed blocks are kept in both a memory bitmap as well as a “persistent state file” (psf) located in the directory of a VM.  Memory contents are always current, the PSF file represents the current shipping LWD.  After an LWD is shipped and completely acknowledgd, the memory bitmap is copied to the PSF file and the memory bitmap is restarted for the next LWD.

 VR will use the defined RPO to determine how often to create a LWD.  Time must be allowed to create the block bundle, transfer it, and successfully complete writing the entire bundle to ensure that the RPO is not violated.  In order to do this, VR will track the length of the previous 15 transfers to create an estimate of how long it will take to complete the transaction of the subsequent LWD.

Fully integrated with SRM, The vSphere Replication (VR) Replicate between VMs between VMFS and NFS, from iSCSI to local disk.  Because VR works above the storage layer (per VM) it can replicated independently of the file systems.  (It will not, however, work with physical RDMs.)

VR creates a “shadow VM” at the recovery side, then populates the VM’s data through replication of changed data.

The VR can be deployed through the “Thick client” the management of the VR is possibly only through the new vSphere Web Client 5.1 web interface.  The VR Agent is part of the hypervisor (5.0 and 5.1) so only vSphere 5.0 and 5.1 works with VR.

vSphere Replication can not co-exist with the vSphere Replication pieces originally shipped with SRM 5.0.  If an existing SRM 5.0 vSphere Replication environment is in place it will need to be uninstalled and replaced with the standalone vSphere Replication from vSphere 5.1.

Storage DRS and sVMotion are supported (only for SRM replication, not for VR replication), but you'll have to deal with certain scenarios.

The VR Appliance is deployed via OVF (previously you had VRMS and VRS in the SRM 5.0).  Like this there is a single appliance which has the 2 roles (at different locations). You have to have vCenter instance running at DR site in order to deploy the VR appliance there.

One to One scenario – this is classical case, where you have 1 main site and one recovery site (DR). In this case the main site (Protected site) has vCenter and also the remote site (Recovery site) has a vCenter server running. See the example below.

The management of vSphere Replication is done only through the New vSphere web client, the admin will enter the vSphere Replication component and register the remote VR Appliance as a target for the local vCenter Server.

Once pairing with the remote appliance is complete, the administrator can choose a local VM to protect, provide the paired remote VR Appliance as the target, select the appropriate target datastore as well as cluster/resources in which the VM should run in case of recovery, and also the recovery point objective for that VM.

The local VR Agent on the host running that VM will then start tracking the changes to the VMDK as they are being written, and as defined by the RPO will create a lightweight delta bundle of blocks to ship via the VMKNIC of that host directly to the VR Appliance at the recovery site.

The VR Appliance at the recovery site will then write the blocks via NFC to the remote cluster to be committed to the replica of the VMDK. Note that the traffic from the VR Agent passes directly to the appliance at the remote site via the management network of the local vSphere host, so the host management networks must be able to correctly resolve and route to the target appliance at the recovery site!

One to many scenarios – In case you're having 1 primary site which you want to replicate to multiple remote DR sites, each of those remote sites has to have vCenter installed together with VR appliance deployed.

Many to one scenarios – In case that you want to protest several remote sites and replicate those to a main DR location and all this infrastructure is managed by single vCenter server located at the main site, in this case only one VR Appliance needs to be deployed. Sometimes you'll want to separate the traffic per protection site, so you can deploy one VR per protected site.

You can find the “Replicating IN” scenario on the screenshot below.

vSphere Replication can recover a VM only if that VM isn't powered somewhere else (or isn't reachable by the recovery vCenter server). It's for avoiding to have duplicate VM running at the same time.

If the recovery of that particular VM succeed, you have to first re-start the protection again. Only after you can reconnect and re-enable replication for this VM.

A protected VM can be recovered if at least the initial replica has completed.

The operation is simple to execute:

– From the replication location you need to select the VM which has been replicated
– Right Click > Recover
– Choose target folder and resource (host, cluster or ressource pool) create and register the VMX, attach the VMDK and power-on the VM.
– Click Finish (checkbox “Power On the VM after recovery” can be selected as well).

Here is the image from the new vSphere Web Client 5.1 web interface.  Only the new vSphere web client can handle the configuration and management of the vSphere replication now. The legacy Windows client can be used only to deploy the VR Appliance.

Click to enlarge.

VR Limits – one of the limitations is that the VR tracks only powered On VMs. The VMs which are powered Off or Suspended are not replicated. Isos, floppy images etc aren't replicated.

Another “limitation” might be that VM with snapshots may be configured for protection by VR (and you can take and revert snapshots), but the remote state for such VMs will be copied without any snapshots. Snapshots are aggregated into a single VMDK at the recovery location. So reverting from a snapshot may cause a full sync!

15 min at most for RPO only – VMs can be replicated with a recovery point objective (RPO) of at most 15 minutes and at least 24 hours. So you can possibly loose 15 min of work.

vSphere 5.1:

• VMware vSphere 5.1 – Virtual Hardware Version 9
• vSphere Data Protection – a new backup product included with vSphere 5.1
• vSphere Storage Appliance (VSA) 5.1 new features and enhancements
• vCloud Director 5.1 released – what's new
• vSphere Web Client – New in VMware vSphere 5.1
• VMware Enhanced vMotion – New in vSphere 5.1
• vSphere 5.1 Networking – New features
• VMware SRM 5.1 and vSphere Replication – New release – 64bit process, Application Quiescence – This Post
• Top VMware vSphere 5.1 Features
• vSphere 5.1 licensing – vRAM is gone – rather good news, any more?
• Coolest VMworld Videos
• Licensing VMware – Further Reading
• ESXi 5.1 Free with no vRAM limit but physical RAM limit of 32Gb