With the release of VMware vSphere 5.1, a number of other VMware products got updated to the release 5.1. One of them is VMware's replication product VMware Site Recovery Manger 5.1.
One of the major (and great) news for SMB customers is that SRM now supports vSphere Essentials Plus editions as well. Stays the requirement of vCenter server (which can be now the vCenter Foundation) on both sites – the main and the DR site.
SRM is 64 bit process now and so you'll need to recreate a 64 bit ODBC connections. The software installs in new directory as well, but the installer can upgrade a 32 bit SRM to a 64 bit 5.1 version too. You'll need to upgrade your Storage Replication Adapters (SRA) as well.
The vSphere Replication (VR) introduced in vSphere 5.0 has been enhanced as well and can be fully managed through the new vSphere Web client only. Since as I already wrote in deep in my article about the new vSphere Web client, the shift to full web interface has began with the v 5.0 and the 5.1 is the last version where the windows vSphere “classic” client has been updated.
VMware SRM 5.1 – What's new from the technical point of view?
Application Quiescence – The new vSphere Replication (VR) has been improved over since the 1st VR with SRM. The VR's main improvements is the VSS integration (through VMware Tools) and doesn’t merely request OS quiescence, but flushes app/db writers if present. Can create application consistent copies of entire VMs.
The application quiescence works out of the box, just need to select the quiescing method and VR will handle it. If VR is asked to use VSS, it will synchronize its creation of the lightweight delta with the request to flush writers and quiesce the application and operating system. This ensures full app consistency for backups.
vSphere Replication is presented the quiescent and consistent volume produced by the OSS flushing the VSS writers, and that consistent volume is used to create the LWD for replication.
If for some reason the VSS can not quiesce correctly or flush the writers, VR will continue irrespective of the failure and create an OS consistent LWD bundle at the VM level, and generate a warning that VSS consistency was not able to be created
All paths down (APD) state improved – The way vSphere 5 handles hosts with devices in an “All Paths Down” state has been improved in VMware SRM 5.1. In fact, in vSphere 5.0 the host could get into an infinitive loop with tries to I/O on unavailable devices.
SRM now checks for a datastore’s accessibility flag before deciding whether or not to attempt to use that datastore. A datastore may become inaccessible because of various reasons. APD is one of them.
The changes in how vSphere handles these devices enables SRM to differentiate APD from other types of inaccessible states such as and Permanent Device Loss (PDL).
If SRM sees a datastore in an APD condition, it will stop immediately and try again later, since APD conditions are supposed to be transient, rather than time out trying to access a missing device.
SRM also has been improved to use a new unmount command to gracefully remove datastores from the primary protected site during the execution of a recovery plan. Since SRM needs to break replication and unmount the datastore from the protected environment the new method allows for a graceful dismount and generation of an APD situation rather than an abrupt removal of the datastore.
During a disaster recovery, however, in some cases hosts are inaccessible via network to gracefully unmount datastores, and in the past the isolated hosts could panic if their storage was removed abruptly by SRM.
With vSphere 5.1 there are new improvements to the hosts and storage stacks that allow them to remain operative even through an unplanned APD state.
Forced Failover – new function introduced in VMware SRM 5.0.1. This function has been made fully supported for all protection group types. When the primary site is in incostistent state (SAN problem). The SAN can be down on the main site, and SRM can wait for messages from the device, which has entered APD or PDL state.
SRM can execute forced failover (from the DR site) . Forced failover worked alreday in SRM 5.0.1 for array based replication. Now the feature is fully supported to work with vSphere Replication too.
vSphere automate Reprotects – You can now easily return environments to the primary production site.
After running a “planned failover only”, the SRM user can now reprotect back to the primary environment. Planned failover shuts down production VMs at the protected site cleanly, and disables their use via GUI. This ensures the VM is a static object and not powered on or running, which is why we have the requirement for planned migration to fully automate the process.
The “Reprotect” button when used with VR will now issue a request to the VR Appliance (VRMS in SRM 5.0 terminology) to configure replication in opposite direction. VR will reuse the same settings that were configured for initial replication from the primary site (RPO, which directory, quiescence values, etc.) and will use the old production VMDK as seed target automatically.
If things have gone wrong at the primary site and an automatic reprotect is not possible due to missing or bad data at the original site, VR can be manually configured, and when the “Reprotect” is issued SRM will automatically use the manually configured VR settings to update the protection group.
Once the reprotect is complete a failback is simply the process of running the recovery plan that was used to failover initially. Go to the page 2 to read the rest of the entry
Hi Vladan i am having some issues setting up the vSphere Replication 5.1. i successfully deployed the ovf, my issues are with the configuration page. I am trying to setup a mant-to-one scenario. can you kindly run me through a configuration setup manual?
If things have gone wrong at the primary site and an automatic reprotect is not possible due to missing or bad data at the original site, VR can be manually configured, and when the “Reprotect” is issued SRM will automatically use the manually configured VR settings to update the protection group.
Can you be more specific about “VR can be manually configured”? Sounds like I couldn’t just click the “Reprotect” button because the original Primary site is gone. When it’s rebuilt, I’m trying to understand what manual configuration needs to happen in order for “Reprotect” to now work
I can’t currently test this. Perhaps you shall contact VMware if you’re on SnS.