White Papers

Additional resources
17 Dell EMC SC Series: Disaster Recovery for Microsoft SQL Server Using VMware Site Recovery Manager | CML1018
SRM version 6.1 support for stretched storage with Live Volume has been added in DSM 2016 R1. Supported
configurations are asynchronous replication or synchronous high availability replication with non-uniform
storage mapping to hosts. For more information on use cases and integrating stretched storage with SRM,
see the SRM Administration documentation available at
VMware Documentation.
Synchronous replication in high consistency mode, uniform storage mapping, managed replication,
consistency groups, Live Volume auto role swap, and Live Volume auto failover are not supported in
conjunction with SRM.
With respect to the Live Volume managed replication feature, disaster recovery at a remote site, independent
of the site or sites containing the Live Volume, is a good use case. However, Live Volume managed
replications are not explicitly supported with VMware SRM. Live Volume managed replication volumes are
activated using DSM.
Replay Manager is not compatible with Live Volume. Since automatic failover is not supported when using
Live Volume with SRM, regular replication is often a better choice when protecting SQL Server virtual
machines using SRM. SRM with replication provides quick recovery times without losing the protection
benefits of application consistent snapshots provided by Replay Manager.
4.2.6 Volume replication considerations
Once a replication methodology is chosen, configuring replication for a single volume is straightforward.
However, there are a few points that need to be raised to be sure they are covered. The first is that all of the
data on a single volume is replicated. In a vSphere consolidated environment, it is likely that many virtual
machines will reside on the datastore being replicated and therefore all of those VMs will be replicated to the
remote system whether that was the original intent or not. In situations where only one or a handful of VMs on
a datastore needs to be protected using replication, those VMs must be separated from the non-essential
VMs using a Storage vMotion or cold migration process. This will ensure only the essential VMs in scope of
the disaster recovery plan are being replicated which results in the best use of the replication bandwidth.
In cases where a SQL Server VM utilizes more than one virtual disk spanning datastores or perhaps uses
RDMs, attention must be given to ensure consistency between the volumes in use. From a snapshot
perspective, all of the volumes in use by SQL Server should be on a consistent snapshot schedule ensuring
all volumes have precisely matching point-in-time snapshots. This can be handled automatically using Replay
Manager or snapshot consistency groups if not using Replay Manager.
From a replication perspective, adequate sizing of the transport must be provided. This will help ensure
snapshots are replicated to the remote system in a timely fashion. In turn, this will also aid in maintaining
replication consistency because there is not currently an SC Series mechanism to guarantee this. For
example, if a SQL Server utilizes six SC volumes with consistent snapshots and the consistent snapshots of
those volumes are asynchronously replicated to a remote system as part of a DR plan, it is likely that some
volumes will complete their replication interval before the others, based on the rate of change of the data
being replicated. If a disaster were to occur after all volumes have completed their replication cycle, this is not
a problem. However, if a disaster were to occur in the middle of a replication cycle, the completed replication
of volume snapshots would be inconsistent at the DR site. The result could be the availability of one-hour
RPO data for three of the volumes and two-hour RPO for the other three volumes. Recovering SQL Server
databases with inconsistent recovery points will almost always be a problem.