Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > Consistency protection with the SRDF/SRA
A typical SRDF configuration contains applications writing data on multiple VMAX/PowerMax LUNs at the protected (R1) site which are replicated to a remote (R2) sites over SRDF/A or SRDF/S links. Data replication is a complex process that very often requires preserving the order of writes on these LUNs. A typical example is a database application writing data and transaction logs across multiple LUNs. It is very critical to preserve the order of writes in such cases. In SRDF environments, this can be achieved by using a feature known as consistency groups.
Similarly, in a VMware environment, virtual machines are running applications that are writing data to one or more VMAX/PowerMax LUNs and it is important that these virtual machines are able to correctly restart on the recovery site in case of protected site failure. To achieve this, Dell strongly recommends having consistency protection across all of the related VMAX/PowerMax LUNs being used.
Note: In addition to Dell’s requirement to always use consistency groups, VMware requires the use of consistency groups to support Storage DRS or Storage vMotion moves. VMware allows for the manual or automated migration of virtual machines or virtual disks for SRM-controlled devices as long as the moves are within the confines of devices included in the same consistency group. If Storage DRS is enabled on SRM-controlled devices it is best practice to configure VMware Datastore Clusters to only include devices that are in the same consistency group.
A consistency group is a device or composite group comprised of VMAX/PowerMax RDF devices, which has been enabled for remote consistency. The devices in the consistency group are specially configured to act in unison to maintain the integrity of data when distributed across multiple devices within an array. RDF consistency protection software preserves the dependent-write consistency of devices within the group by monitoring data propagation from source devices to their corresponding target devices. If a source R1 device in the consistency group cannot propagate data to its corresponding R2 device, RDF consistency software suspends data propagation from all the R1 devices in the group. This allows one to quickly recover from certain types of failures or physical disasters by retaining a consistent environment.
RDF consistency group protection is available for synchronous mode (SRDF/S), asynchronous mode (SRDF/A), and active mode (SRDF/Metro). RDF consistency protection for SRDF/S and SRDF/Metro devices are provided through RDF Enginuity Consistency Assist (RDF-ECA). RDF consistency protection for SRDF/A devices is provided through Multi Session Consistency (MSC)[1]. Consistency is managed and maintained by the RDF Daemon running on the Solutions Enabler servers.
Depending on the configuration and combination of the devices to be grouped, either a device group or a composite group must be created. A consistency group can refer to either a device group or a composite group.
The creation of consistency groups is a manual process. The storage admin needs to identify the virtual machines being protected, identify the datastores that are holding the virtual machines and determine the list of VMAX/PowerMax devices that are being used by these datastores (or RDMs if applicable). Once the devices are determined, a composite or device group is created into which the devices identified are added, followed by enabling RDF consistency on the group.
The differences between device and composite groups are described below:
Device group: A device group is a user-defined group comprised of devices that can belong to a locally-attached VMAX/PowerMax. A control operation can be performed on the group as a whole, or on the individual device pairs that comprise it. RDF devices contained in a device group are limited to one RA group.
Device groups containing SRDF/S devices that do not span multiple RA groups do not need consistency to be enabled. Device groups containing SRDF/A devices that do not span multiple RA groups should have consistency enabled. SRDF/A device groups can have consistency enabled through the command symrdf enable and this operation does not require the use of the RDF daemon.
Composite group: A composite group[2] (CG) is a user-defined group whose members can be individual devices or device groups spanning RA groups.
Composite groups, and especially composite groups that have SRDF devices that span multiple RA groups must have consistency enabled and this is achieved via the command symcg enable with the consistency provided through MSC or ECA via the RDF daemon. An example of enabling consistency on a composite group that spans RA groups on an array is seen in Figure 41.
Note: The SRDF SRA does not support the use of storage groups. Consistency groups (composite/device) are required for all configurations except MetroDR.
Figure 41. Enabling consistency across SRDF groups
Consistency group creation for Non-Star Concurrent or Cascaded SRDF is discussed in the section Creating consistency groups for Concurrent and Cascaded SRDF.
Dell strongly recommends running redundant SRDF daemons on at least two control hosts at each site. This ensures at least one SRDF daemon is available to perform time-critical, consistency monitoring operations.
For redundant consistency protection of composite groups, environments must simultaneously run two instances of the SRDF daemon on separate control hosts. Each control host must have a common view of the composite group being monitored, which can be accomplished by doing one of the following:
SRDF daemons running simultaneously on two different hosts perform independent monitoring and switching operations. If one fails, the other SRDF daemon takes it place[4], completing all pending tasks, such as committing the last cycle of data to the target site. By running redundant SRDF daemons, one avoids service interruptions caused by performance bottlenecks local to a control host, and link failures of the redundant SRDF daemons and the control hosts.
The storrdfd daemon runs on each host for which SRDF consistency is required. If the GNS daemon (storgnsd) is enabled, storrdfd relies on GNS to propagate updated CG definitions to all hosts locally attached to the same set of VMAX/PowerMax arrays. If GNS is not enabled, one must manually recreate the updated CG definition on each one of these hosts. Administrators can enable GNS on each host by installing and starting the daemon with the following commands:
stordaemon install storgnsd -autostart
stordaemon start storgnsd
And by using the following Solutions Enabler options file setting:
SYMAPI_USE_GNS=ENABLE
As shown in Figure 42, Host-1 and Host-2 contain sets of the base daemon, the SRDF daemon, and the GNS daemon to ensure data consistency protection.
Figure 42. Running redundant hosts with GNS to ensure consistency protection
The following sections outline the steps that should be observed when creating consistency groups and activating consistency for Concurrent or Cascaded SRDF respectively.
If the Concurrent SRDF topology has each leg off the R1 devices operating in different RDF modes, SRDF consistency protection cannot be enabled at the composite group level as with other configurations. Instead, consistency must be individually enabled for each RDF group representing the device mirrors by its group name. Enabling SRDF consistency at the group name causes the RDF daemon to monitor the SRDF groups separately so that if a concurrent R1 device is unable to propagate its data to one of its remote R2 partners, the daemon suspends the SRDF links for only the group representing that R2 mirror.
The RDF group of the leg operating in asynchronous mode is enabled with MSC consistency protection and the RDF group of the leg operating in synchronous mode is enabled with RDF-ECA protection.
RDF group-level consistency can only be enabled with Solutions Enabler CLI. The following syntax should be used to enable consistency:
Use the symcg command to define a name to represent an SRDF group:
symcg -cg <CG name> set -name <name> -rdfg <VMAX/PowerMax SN>:<RDF Group #>
Then use the symcg command to enable consistency protection for that SRDF group:
symcg -cg <CG name> enable -rdfg name:<name>
This must be executed twice, once for each leg of the Concurrent SRDF setup. An example of doing so with Solutions Enabler CLI is displayed in Figure 44. The Synchronous target is enabled first followed by the Asynchronous target. The VMAX serial number in the example is 1253 and the Synchronous RDF Group number is 16 and the Asynchronous RDF Group number is 16.
Figure 44. Enabling consistency for a Concurrent SRDF setup with Solutions Enabler
The RDF group of the leg operating in asynchronous mode is enabled with MSC consistency protection and the RDF group of the leg operating in synchronous mode is enabled with RDF-ECA protection. Also, unlike Concurrent SRDF, users can enable SRDF consistency protection for cascaded devices using a composite group or an SRDF group name. It should also be noted that one method or the other should be chosen but not both. For example, users cannot enable the first hop using a composite group and then enable the second hop using its SRDF group name.
Composite group-level consistency can be enabled with Solutions Enabler CLI or Unisphere for PowerMax. The following Solutions Enabler CLI syntax is to be used to enable consistency:
Use the symcg command to enable consistency protection for a composite group Synchronous leg:
symcg -cg <CG name> enable
Use the symcg command to enable consistency protection for a composite group Asynchronous leg:
symcg -cg <CG name> enable -hop2
Examples of enabling consistency with Solutions Enabler CLI are displayed in Figure 46
Figure 46. Enabling consistency for a Cascaded SRDF setup with SE
If the user fails to create consistency groups on the protected and recovery sites’ Solution Enabler servers and then initiates a failover, the SRA will create the groups before conducting the failover. When the SRA names the groups, it is in the format of “DG_<time and date and process id>”.
Note: Test failover will not function without group creation.
[1] For consistency groups using MSC/ECA to provide consistency, the RDF Daemon on both the protected and recovery Solutions Enabler server must be running. It is highly suggested that the RDF Daemon be set to autostart on both sides in case the Solutions Enabler server is rebooted.
[2] Composite groups must ALWAYS be created with the -rdf_consistency flag regardless of device configuration. It also must either be of type RDF1 or RDF2.
[3] GNS is not supported with the parameter <AutoTargetDevice>, thus the second manual method should be used if that SRA parameter is in use.
[4] If the primary Solutions Enabler server fails and cannot be recovered, the array managers in SRM will need to be reconfigured with the backup Solutions Enabler server. SRM does not provide for inherent HA in the array manager.