White Papers

Replication and remote recovery
61 Dell EMC SC Series: Best Practices with VMware vSphere | 2060-M-BP-V
Asynchronous replications usually have more flexible bandwidth requirements, making it the most common
replication method. Another benefit of asynchronous replication is that snapshots are transferred to the
destination volume, allowing for checkpoints at the source system and destination system.
15.3 Replication considerations with standard replications
One key consideration about SC Series replication is that when a volume is replicated either synchronously or
asynchronously, the replication only flows in one direction. Changes made to the destination volume are not
replicated back to the source. Do not to map the replication destination volume directly to a host, but instead
to create a read-writable view volume.
Block changes are not replicated bidirectionally with standard replication. The ability to vMotion virtual
machines between source controllers (main site), and destination controllers (DR site), is not possible with a
standard replication, but is possible with Live Volume.
There are some best practices for replication and remote recovery to consider. ESXi host hardware is needed
at the DR site in which to map replicated volumes in the event the source ESXi cluster becomes inoperable.
Also, preparations should be made to replicate all management resources to the DR site, including vCenter,
DSM, and other management software hosts.
15.4 Replication considerations with Live Volumes
Live Volume is a feature that allows a volume to be accessed from two disparate SC Series systems, allowing
for the migration of data, increased uptime, and planned maintenance. Although this technology enables new
functionality such as long-distance vMotion, there are some caveats described in the following sections.
Administrators need to be aware of these caveats when choosing to use asynchronous or synchronous Live
Volume.
Caution: LUN conflicts should be considered when designing Live Volumes into the environment’s
architecture. When a Live Volume is created, it attempts to keep LUN assignments identical between sites.
For example, if a VMFS volume is mapped as LUN 10 at the primary site, it attempts to map the destination
Live Volume as LUN 10. In some instances, the secondary site may already have existing LUNs that conflict
and cause the Live Volume to not operate as expected. For example, having a Live Volume presented using
LUN 10 from the first array, and presented as LUN 11 from a second array will likely cause problems. In
addition, this is unsupported with certain configurations such as with vMSC clusters.
15.4.1 Asynchronous Live Volume
When a Live Volume replication is created, the volume becomes read-writable from both the main system and
secondary system, allowing vMotion of virtual machines over distance. However, the VMware long-distance
vMotion best practices need to be followed. The vMotion network between ESXi hosts must be gigabit or
greater, round-trip latency must be 10 milliseconds or less (dependent on vSphere support agreement level),
and the virtual machine IP networks Layer 2 must be stretched between data centers. In addition, the storage
replication must also be high bandwidth and low latency to ensure Live Volumes can be kept synchronized.
The amount of bandwidth required to keep Live Volumes synchronized highly depends on the environment,
so testing is recommended to determine the bandwidth requirements for the implementation.
Due to the asynchronous nature of the replication and how it proxies data, it is recommended that
asynchronous (async) Live Volumes only are used for disaster avoidance or planned migration. Live Volume
is most practically used for planned maintenance operations such as migrating workloads between racks or