Site recovery manager and vsphere replication features

Overview of New Features in SRM and vSphere Replication

vCenter Site Recovery Manager 5.5 and vSphere Replication 5.5 include a number of significant improvements and exciting new features

New features in vCenter Site Recovery Manager 5.5 include:
• New support for StorageDRS and Storage vMotion
• Full integration with vSphere 5.5  - Support for Multiple Recovery Points
New features in vSphere Replication include:
• New User Interface
• Flexible Replication Topologies
• Support for Multiple Point-in-Time Recovery Points
• Support for vSphere Distributed Storage

• Major Performance Improvements

What's New in vSphere Replication: Support for New Replication Topologies

vSphere Replication is a feature of the vSphere platform. It copies a virtual machine to another location, within or between clusters, and makes that copy available for restoration through the VMware® vCenter Server™ Web-based user interface.

vSphere Replication continues to protect the virtual machine on an ongoing basis. It replicates to the copy the changes that are made to the virtual machine. This ensures that the virtual machine remains protected and is available for recovery without requiring restore from backup.

One of the exciting new features of vSphere Replication v5.5 is the ability to support flexible replication topologies.  In previous versions of vSphere Replication, you were limited to a single vSphere Replication Management Server instance per vCenter Server.   This generally limited you to replicating between two distinct datacenter sites and required that each site had it's own vCenter Server instance.

Topologies with vSphere Replication can now be broadened to encompass inter-datacenter replication, intra-datacenter replication, and can include many different models of deployment dependent on where the vSphere Replication Server appliances are deployed.

Each vCenter Server needs to have a single, master vSphere Replication Appliance deployed and paired with it, but up to 9 further vSphere Replication Servers can be deployed to locations managed by that vCenter Server to act as the target for replication.

we are going to configure replication between two datacenters:PROD and DR. The DR datacenter is a small regional site that does not have it's own vCenter Server.  We will be configuring replication for a VM running in PROD, to ensure that we have a valid replica available in DR as part of our overall BCDR strategy

Examine master vsphere replication appliance for prod vcenter server

As stated earlier, each vCenter Server instance is configured and paired with a master vSphere Replication appliance.  

Using the vSphere web client, navigate to the About information pane for thePRODvCenter Server master appliance.

1. Select the vCenter icon to access the inventory

2. Select vCenter Servers and click onvc-01b

3. Click on the Manage tab

4. Select the vSphere Replication sub-tab

5. Select About

Examine target site information

Click on the Target Sites button.  

You are able to pair this instance with one or more remote vCenter instances.   In our example, this site has been paired with the vCenter Server for the DR datacenter (vc-01a).  This pairing is required only if you with to replicate to site managed by a different vCenter Server.

we will be configuring replication from our primary PROD datacenter to our smaller regional DR datacenter.  Both datacenters are managed by the same vCenter Server.  This inter-vCenter replication is a new feature of vSphere Replication 5.5.

Examine replication servers for this vcenter instance

Click on the Replication servers button.  

You will see that we have two vSphere Replication appliances configured.  One appliance is responsible for the primaryPRODdatacenter.  The second appliance manages replication for the remote regional DR datacenter

Complete the following steps to open the vSphere Replication configuration wizard.

1. Right-click on the Extranet ServerVM

2. Select All vSphere Replication Actions

3. Click on Configure Replication

Select the vcenter site

We will be replicating a full LAMP stack from DR to PROD.

1. Select the DR vCenter instance (vra-01a)

2. Click Next to continue

Select the dr vsphere replication server

We will be replicating the Extranet Server VM to DR

1. Click on Select vSphere Replication Server

2. Select the DR (ds-site-a-nfs01) Replication server

3. Click Next to continue

Select the desired datastore located at the DR remote regional site.

1. Select the ds-site-a-nfs01 datastore

2. Click Next to continue

Finish

Monitoring vsphere replication and point-in-time recovery points

What's New in vSphere Replication: Multiple Point-in-Time Recovery Points

Another new and powerful feature of vSphere Replication 5.5 is the ability to support multiple recovery points.   Prior to this release, only a single recovery point (most current) was supported.   Starting with version 5.5, the administrator has the ability to specify how many point-in-time copies of the VM should be created per day, and for how many days they should be retained.  

This capability allows you to easily revert to the last known good state of a virtual machine to recover from data corruption, virus infections, etc.  

we are going to configure multiple point-in-time recovery options for a VM that is currently being replicated betweenPRODand DR.   We have been given a directive to ensure we have four daily recovery points for this VM and that they should be retained for 2 days.

Best Practice Note: While we can support up to 24 recovery points per VM, we do not recommend as a general practice that you implement multiple recovery points for all of your replicated VMs.  This feature should only be used when there is a specific known need, and then only retain what is necessary.  

Examine existing replications

Using the vSphere web client, navigate back to the DR vCenter Server instance and examine the currently configured replications.

1. Navigate to the DR vCenter Server (vc-01a) in the inventory view

2. Select the Monitor tab

3. Click on vSphere Replication

4. Select the Incoming Replicationsbutton

We are replicating a full LAMP stack ofVMs from DR to PROD.  You can examine or modify the current replication configuration here.

Let's implement the multiple point-in-time recovery options as required by our new BCDR policy (four daily recovery points retained for two days).

Reconfigure replication settings

Make sure the DB Server VM is selected and click on the ReconfigureReplication icon to launch the configuration wizard.

Click Yes to dismiss the Security Alert if needed.

Click Next four times to keep currently configured settings and advance to the Recovery settingspage.

Remember, we want to configure four daily point-in-time recovery points and retain them for two days.  Execute the following steps to implement the desired recovery capabilities.  

1. Make sure Point in time instances is Enabled by clicking the checkbox

2. Enter 4 as the number of instances per day

3. Enter 2 as the number of days to retain

4. Click Next to continue

Review your changes and click Finish to continue.

Confirm new policy

Confirm your new settings took effect.

1. Click the Refresh button

2. Examine the Point in time recovery settings and existing Instance Sync Point(s)

Congratulations.  You have just configured custom multiple point-in-time recovery settings for vSphere Replication

What's New in SRM:  Storage vMotion and Storage DRS Interoperability

Prior to the release of vCenter Site Recovery Manager 5.5, VMware explicitly stated that StorageDRS and Storage vMotion were NOT supported with SRM.   The following example (taken from Cormac Hogan's excellentblog on this topic) explains the core issue preventing interoperability.

Example:  If a customer enables Storage DRS in fully automated mode on the protected site, and at 3am in the morning, Storage DRS decides that it needs to balance the datastores (either for space or for I/O load), and it Storage vMotions a VM to a different datastore, that VM is no longer protected by SRM. Let's say that at 4am, there is a disaster at the protected site. SRM does its thing and fails over to the recovery site. Unfortunately, not all the VMs are recovered because some of them were migrated to different datastores at the protected site, and were left in an unprotected state. This is not a nice situation to be in during a disaster.

Starting with vCenter Site Recovery Manager 5.5, VMware now provides support for protected-site StorageDRS and Storage vMotion with vSphere Replication.  

Historically we could not support Storage vMotion  and Storage DRS with vSphere Replication.  In earlier releases, vSphere Replication persistent state files that track changed blocks for current replication were deleted during a Storage vMotion operation.  This caused a vSphere Replication full sync operation to occur which is a very expensive operation.   This behavior has been changed in vSphere 5.5 so that the persistent state files are now migrated along with the VMDK file during a Storage vMotion operation.  

Protected site storage vmotion and storage drs now supported:  array-based replication

vCenter Site Recovery Manager 5.5, VMware now provides support for protected-site StorageDRS and Storage vMotion with array-based replication as well.  

Support relies on the use of a StorageDRS cluster that contains only datastores that are part of the same array consistency group.  The disks in this consistency group are all replicated with the same schedule and write order fidelity is maintained.   This allows them to be moved 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).

What's New in SRM:  Multiple Point-in-Time Recovery Capability

SRM is fully compatible with the new Multiple Point-in-Time recovery point feature in vSphere Replication 5.5.   Using these technologies together, you can easily revert to a previous point-in-time copy of your virtual machine following the execution of an SRM recovery operation.   This can be extremely useful to revert a VM to a known good state prior to data corruption, virus infection, or other issues.