What is new in VMware Site Recovery Manager 5.5

This post is part of a series of posting on the VMworld 2013 announcements. See this post for an overview of what has been announced at VMworld 2013.

AT VMworld 2013 VMware announced Site Recovery Manager 5.5
Part of SRM is the ability to replicate on a per VM basis. Information on What is New on vSphere Replication can be found here.

VMware vCenter Site Recovery Manager (SRM) is a business continuity and disaster recovery solution that helps you to plan, test, and run the recovery of virtual machines between a protected vCenter Server site and a recovery vCenter Server site.

You can configure SRM to work with several third-party disk replication mechanisms by configuring arraybased replication. Array-based replication surfaces replicated datastores to protect virtual machine workloads. You can also use host-based replication by configuring SRM to use VMware vSphere Replication to protect virtual machine workloads.

You can use SRM to implement different types of recovery from the protected site to the recovery site.

What is new:

this information is based on VMware vCenter Site Recovery Manager 5.5 Release Candidate| 19 JUL 2013 | Build 1228390

  • Ability to test your DR non-disruptively from any site, and view both sites
  • SRM 5.5 allows you to protect virtual machines with disks that are larger than 2TB
  • support for Windows Server 2012 for installation of SRM
  • New configuration option to support vSphere Replication
  • Storage DRS and Storage vMotion  supported when moving virtual machines within a consistency group.
  • Protect virtual machines in Virtual SAN environments by using vSphere Replication. You can use Virtual SAN datastores on both the protected site and on the recovery site.
  • Preserve multiple point-in-time (MPIT) images of virtual machines that are protected with vSphere Replication. Advanced settings include an option to recover all vSphere Replication PIT snapshots.
  • Protect virtual machines that reside on vSphere Flash Read Cache storage. Flash Read Cache is disabled on virtual machines after recovery.
  • SRM 5.5 no longer supports IBM DB2 as the SRM database, in line with the removal of support for  DB2 as a supported database for  vCenter Server 5.5.

SRM 5.5 still needs the C# (full vSphere client) for management. So no support for the vSphere web client.
The operational limits for using SRM 5.5 with vSphere Replication 5.5 are the same as for using SRM 5.1 with vSphere Replication 5.1.

•MPIT retention is turned off by default, but can be enabled in advanced settings within SRM.  This is the default behaviour as only the recent point in time will have any SRM failover customizations such as scripts, network changes, etc. applied to it during failover.  If the administrator reverts to an earlier snapshot these changes will be lost.  Enable this setting in advanced features in SRM if retention of MPIT is desired.
•Compatibility with Storage vMotion of primary objects with vSphere Replication is retained when using SRM, completely transparently.  There is no real restriction on where or when users may migrate VMs.
•SRM has always supported multiple vSphere Replication servers, but be aware that topologies are more restrictive when using SRM vs. using stand alone vSphere Replication. I.e. VR supports many topologies depending on where VR appliances and VR servers are deployed.  SRM still supports only 1-to-1 pairing or Many-to-1 shared recovery.
•VSAN support is also maintained in SRM if using vSphere Replication
•Migrating VR based VMs with SDRS or sVmotion is fully supported within SRM as well.

Secondly, the support for Storage vMotion has been expanded to include migration of VMs within a consistency group on an array when using array based replication and vCenter 5.5 with vSphere 5.1 and above *only*:

•If VMs are moved out of a disk consistency group the replicated VMX file may not be created in the right location rapidly enough, causing the VM to be unrecoverable
•Therefore Datastore Clusters *must* be made and *must* contain only the datastores provided by the consistency group on the array, i.e. each datastore cluster may contain only datastores from the same consistency group on the array.
•Each datastore in the consistency group will have the same availability characteristics (RPO, speed, etc.) and therefore each datastore in the datastore cluster/pod will have the same characteristics.
•When that is the case, storage vMotion and storage DRS are supported within the datastore cluster/pod.  This will ensure a valid VMX and VMDK file is always present and available for recovery.
•SRM will scan all datastores in a protection group for a valid VMX file for any given VM.  If a VM is migrated on the primary site, the VMX will be created on the new datastore and deleted on the old.  This means the replication of that VMX will happen and the deletion of the old one in parallel with the action on the primary site.
•This means the migration may not have completed when failover occurs, in which case we can still use the old VMX, or it will have completed in which case we can use the new one.  In any case the VM remains recoverable as long as consistency groups are used.

Further explanation on storage vmotion:

“Fundamentally what we’re doing is now scanning all the directories in the replica datastores of a datastore group in a PG on the recovery site.  We look for the vmx everywhere now instead of just looking for the vmx in the last place it was put when the vmx was protected.
So the caveat is the VM must be placed in the primary site on a storage cluster that contains only datastores that contain only disks/luns/disk groups that are part of the same consistency group on the backend.

It is a manual process to set this up and there is no error checking, so the administrator must know the storage layout well.

If all the replicated files reside in a SRM protection group backed by a storage cluster backed by datastores backed by only disk groups/LUNs/etc. in a consistency group, then you can manually migrate or turn on storage DRS for those VMs.

This is because we now look for the files for that VM in all directories associated with that protection group.
Since those disks in the consistency group are all replicated with the same schedule and write order fidelity is maintained, we can therefore allow them to move because there will always be a recoverable set of files either at the source location (if a crash/recovery occurs during migration) or at the target location (if it completes successfully before the crash/recovery).

This is the scenario we’ve had to avoid in the past, an incomplete migration leading to the deletion of the primary VMX before the replication engine has placed the new VMX in the appropriate directory at the recovery site, or before SRM has been notified about the new location at the recovery site.

Not there are no checks to ensure it doesn’t move out to somewhere incorrect, so there is still the risk of moving it into an unprotected area or outside of the consistency group if they are not careful, and that can still lead to a non-recoverable VM.  We do send alerts if vmotion has moved it out of protection, but do not stop the migration.

Caveats and Limitations

  • SRM 5.5 RC does not support upgrading from a previous release. Only a fresh installation of SRM 5.5 RC is supported.
  • No storage replication adapters (SRA) are  provided for SRM 5.5 RC. Existing SRM 5.1 SRAs should work, but SRM 5.5 RC  does not officially support array-based. Protecting virtual machines by using  vSphere Replication is supported.
  • Using vSphere Replication with VMware Virtual SAN environments is supported but is subject to certain limitations in this release.

    Using SRM and vSphere Replication to replicate and recover virtual machines on VMware Virtual SAN datastores can results in incomplete replications when the virtual machines are performing heavy I/O. ESXi Server can stop  unexpectedly.

    SRM and vSphere Replication do not  support replicating  or recovering virtual machines to the root folders with user-friendly names on Virtual SAN datastores. These  names can change, which causes  replication errors.  vCenter Server does not register virtual machines from such paths. When selecting Virtual SAN datastores, always select  folders with UUID names, which do not change.

  •  SRM 5.5 RC offers limited  support for vCloud Director environments.  Using SRM  to protect virtual machines  within  vCloud resource pools (virtual machines deployed to an Organization) is not supported. Using SRM to protect the  management structure of vCD is supported. For information about how to use SRM to protect the vCD Server instances, vCenter Server instances, and databases  that provide the management infrastructure for vCloud Director, see VMware vCloud Director Infrastructure Resiliency Case Study.
  • SRM does not accept certificates signed using MD5RSA signature algorithm.
  • Windows Server 2003 is not a supported platform for  SRM Server but the SRM installer  allows  you to install SRM on Windows Server 2003.

In the future SRM will be deployed as a virtual appliance.

This post is part of a series of posting on the VMworld 2013 announcements. See this post for an overview of what has been announced at VMworld 2013.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current day month ye@r *