Administrator Guide

Live Volume with Linux/UNIX
97 Dell EMC SC Series: Synchronous Replication and Live Volume | CML1064
reconstruct or import the storage domain into the alternate data center object, and from which object,
reconstruct the virtual machine workgroup.
The following technical and performance considerations should be taken when exploring these use cases.
/etc/multipath.conf: This keeps the contents of /etc/multipath.conf file consistent across all hosts sharing
these Live Volumes; this file contains the definitions of volume WWIDs and their respective aliases and will
ensure that volumes are identified across the different hosts as the same device, and contain the same data
to maintain application integrity.
/etc/fstab: Use the /etc/fstab file in conjunction with /etc/multipath.conf to ensure that volumes are accurately
mounted to their respective and proper mount points in the filesystem. Use the multipath device aliases (if
defined) or default multipath device naming (mpathX) in /etc/fstab to maintain this consistency.
/etc/ntp.conf: Always use the /etc/ntp.conf file to maintain a certain degree of time-based integrity across all
infrastructure. The use of /etc/ntp.conf file becomes even more critical when attempting to maintain data
integrity across multiple cluster nodes/sites dispersed across larger geographic deployments (MAN, WAN).
Cluster configurations: In addition to the considerations mentioned above, take into account cluster-specific
configuration files as well and the best practices of their respective vendors. The discussion of cluster-specific
configuration remains outside the scope of this paper. The list of enterprise-class clustering technologies
include but is not limited to Red Hat Cluster Suite, IBM
®
PowerHA
®
, Oracle
®
Solaris Cluster, Oracle RAC, HP-
UX ServiceGuard, and Symantec™ Veritas™ Cluster Server to name a few.
Performance considerations: It should be noted that the dual commit nature of synchronous replication (I/O
writes must be committed to the secondary SC Series volume before it is committed to the primary volume)
may introduce latency to the applications generating these write requests. The use of synchronous replication
guarantees the consistency and integrity of the data at both SC Series sites when the acknowledgment is
received by the requesting application. The use of synchronous replication should be made upon the detailed
and thorough analysis and understanding of the applications and its I/O needs.
The following demonstration has a small dataset (40 MB) that is written to a primary Live Volume and is
synchronously replicated to an alternate array. The filesystem is formatted as ext4 and mounted (@ /vol_00)
with the discard and sync (the sync option disables filesystem buffer caching) flags.
[tssrv216:/root]# cd /etc; time tar cvf - . | (cd /vol_00; tar xvf -)
[snip]
real 0m24.147s
user 0m0.122s
sys 0m1.421s
In this next demonstration, the synchronously replicated Live Volume at the alternate site is mounted to the
secondary Linux host and writes are applied to the secondary Linux host. This demonstrates additional
latency as all write I/O requests are proxied through the secondary SC Series array to the primary array for
processing.
[tssrv217:/root]# cd /etc; time tar cvf - . | (cd /vol_00; tar xvf -)
[snip]
real 0m30.864s
user 0m0.111s
sys 0m1.422s