What’s New With vSphere Replication and Site Recovery Manager 5.5

At VMworld we announced the newest release of both vSphere Replication and Site Recovery Manager.
Version 5.5 introduces a few new features for each of these that I will be diving into more detail on over the next few weeks, but I wanted to give a quick introduction to the new features so that when the products become available you’ll know what to go take a look at.

vSphere Replication 5.5 includes the following enhancements:

• After failover you can choose to revert to a previous ‘known good point’.  For example, if you’ve done a failover either manually or via SRM and find out that the copy you’ve failed over to has something wrong, it’s as simple as browsing through the snapshot manager of a VM to choose a historical point to revert to.  Retain up to 24 historical “MPITs” with this new feature available in the configuration menu.

• vSphere Replication up version 5.1 would be configured by deploying a single vSphere Replication Appliance per vCenter Server.  This appliance acts as both the management interface and the recipient of changed blocks – the target for replication.  In this dual function it will allow for ease of deployment and simple configuration.
• With 5.5 we now allow for the additional deployment of further vSphere Replication Servers that only function as the target for replication.  The first appliance that is deployed will still maintain the dual role of management and target, but now you can deploy up to 9 further appliances to act as the target for replication.
• Deploy up to 10 appliances under a single vCenter to spread the replication between different appliances, or even deploy the appliances at remote offices, giving the option of expanded supported topologies for replication including intra- and inter-Remote office replication!

• Despite incorrect information I’ve seen on the web, we’ve always supported HA, vMotion and DRS with vSphere Replication.  The one thing we didn’t support was Storage vMotion.  With 5.5 that has changed, and you can now freely migrate the replicated VMs around between disks with Storage vMotion and now use Storage DRS!  Note that Storage vMotion is only supported for the replicated VM, not the target replica vmdk.  Even then, storage vmotion support for protected VMs greatly simplifies management – you can now enable Storage DRS and use storage pools for these VMs without concern.

• The location for vSphere Replication has been surfaced in the web client interface in a few new locations.  Previously it was accessible only as a top-level object in the UI, but now it is also found under each vCenter to which the client is connected.  Since replication can be both to or from any vCenter instance, the corresponding tabs for “monitor” and “manage” now both show VR information, as well as the “summary” tab giving you overall health info about the state of all replications.

• The datastore of the virtual SAN are presented like any other storage service class, meaning vSphere Replication can utilize it.  VR can both protect VMs that sit on a vSAN  *and* protect *to* a vSAN as a target with absolutely no problems or configuration hoops.  The beauty of the vSAN is that from a VM perspective it looks just like any other datastore that is presented with a storage profile.
• There is nothing to configure when protecting a VM sitting on a vSAN, simply configure the replication like you would any other VM.  To protect to a vSAN is just as easy, simply select the datastore presented by the vSAN.
• To further simplify this, you could simply select the storage service class drop down for the target of replication (and choose the vSAN service class (or any other service class that has been defined) and the VR interface will populate a list of targets that are compliant with that filter.

• New optimizations deliver significant speed improvement in replication.  There are a number of areas wherein our engineering team made some changes to a handful of things.  I’ll talk in more detail about some of these changes in a post to come, but while the RPO does not change (15m-24h) within a given replication expect to see a lot more traffic get shipped!

 

Site Recovery Manager 5.5 includes the following enhancements:

• This is something we’ve been asked for for some time, so it’s quite pleasing to outline our (growing) support for Storage vMotion with SRM.  Again the details of the how and why will follow, but the support model looks as follows:
• With Array Based Replication SRM can support storage migration of virtual machines *only* if the datastores are backed by disks/LUNs/Disk Groups/etc. residing in a consistency group on the array.  SRM does not check for this consistency group backing yet, so my best practice is to create a datastore cluster that contains all the datastores for a given consistency group and then place VMs that you need to migrate in that datastore cluster.  Then let ’em fly!
• With vSphere Replication SRM can support storage migrations anywhere and to anywhere; As VR operates at the host level, not the disk level, it doesn’t matter to SRM where the primary VM resides.
• Again – this is support for storage vMotion of the *protected* objects only, not the target objects just yet…

• SRM does not directly interact with the multiple points in time vSphere Replication creates, but is aware of them.
• SRM will always failover to the most current point in time, and then an administrator may choose to revert to an earlier point via the snapshot manager.
• This may be over-ridden; for example all customizations for failover are applied to the current point in time.  If an inadvertent user reverted to a previous point in time, these customizations would be lost.  Therefore, if desired, retention of MPIT when using SRM can be turned off and have all snapshots collapsed at time of failover.

• SRM can failover VMs that reside on a vSAN, as they are only going to be protected by vSphere Replication, and SRM is quite happy about vSphere Replication protected VMs.
• SRM is unaware of the disk subsystem used by VR protected VMs, so you can failover VMs from a vSAN one-by-one if you want!  It’s simply a matter of how you craft the protection groups by choosing which VMs you want to fail over together.

Again, I’ll be diving into the bulk of these features in individual blog postings over the next few weeks, so stay tuned for the details!

-K