Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > Testing recovery plans using GNS-enabled groups
Group name services (GNS) provides a common repository to store and maintain Solutions Enabler device group (DG) and composite group (CG) definitions across VMAX/PowerMax arrays that are visible to all locally attached hosts. By default, with GNS disabled, group definitions are stored in the local Solutions Enabler configuration database file on the host that created the group.
Enabling GNS enables group definitions to be stored on the VMAX/PowerMax array in a shared GNS repository. This shared GNS repository is visible to any GNS-enabled locally-attached host, enabling these hosts to perform control operations, regardless of which host initially defined the group. In addition, if one host goes down, you can still perform SYMCLI control operation from another local host in your VMAX/PowerMax environment.
Note: Both the local and global group databases are managed by the GNS daemon.
In the GNS-enabled environment, each host performing management operations must run an instance of the GNS daemon (storgnsd). In this case, the Solutions Enabler and SYMCLI do not directly access the GNS shared repository. Instead, requests are forwarded to the GNS daemon, which processes all GNS operations. This daemon is the only entity that directly accesses the GNS shared repository and is responsible for ensuring that each host has access to the most current GNS definitions
From each host, a GNS daemon listens for GNS requests from local clients (same host) and carries them out on the locally attached VMAX/PowerMax array. In addition, the GNS daemon monitors the GNS repositories on all locally-attached VMAX/PowerMax arrays, at a user-configured polling interval, for changes made to the shared GNS repository by other daemons (on other hosts). When a change is identified, the GNS daemon will update the host to ensure that all GNS-enabled hosts refer to the same group definitions.
In non-GNS enabled environments, the SRA deletes and recreates device group definitions as part of the test failover or failover functionality. The SRM passes a set of devices to SRA then the SRA deletes and recreates the device group definitions if any of those devices already exist in device group definitions. The SRA does this to make sure the devices are not part of multiple groups or if only a subset of devices are part of the existing device groups.
In GNS enabled environments, since the device group definitions are managed by GNS service the SRA does not delete and recreate the group, but instead only adds the target TimeFinder devices to the existing group. The SRA includes the ability to detect whether or not a target device group is managed by GNS or not and will report as such in the SRDF SRA log:
[11/29 14:11:56 10096 0599 SymmUtil::IsGnsGroupDevice] Checking if Symm Dev [013D], Symm [000192603603] is part of any GNS enabled DG
[11/29 14:11:56 10096 0257
SraDevicePairings::GetCopyInfo] [WARNING]: The Symm Dev [013D], Symm [000192603603] is part of a GNS enabled DG
If the respective R2 devices are included in a GNS-enabled group the SRA test failover behavior will change automatically with no additional configuration from the user. All other operations and requirements remain unchanged as the user must still fully configure the options file with correct device pairings and TimeFinder method before executing a test failover operation.
Note: GNS is not supported with the global option AutoTargetDevice. If GNS is being utilized it is necessary to use the EmcSrdfSraTestFailoverConfig.xml file which requires manual creation of target devices.
The option gns_remote_mirror in the GNS daemon’s options file determines whether GNS should attempt to remotely mirror a device group or a composite group RDF definition contained in the shared GNS repository for a given VMAX/PowerMax array.
When enabled, GNS will maintain a remote mirrored group definition with the same name as the local one creating a usable group to hosts (including GNS daemons) directly connected to the remote VMAX/PowerMax array(s). The remote mirrored group has the same name as the local one and has a mirror image of its contents; in other words, the data reflects the perspective of the local array. This done to ensure that the mirrored group is a legal, usable group to hosts directly connected to the remote VMAX/PowerMax arrays. This would mean if a user created a RDF1 group on the protected site Solutions Enabler server a corresponding RDF2 group would be created within GNS automatically (by default no longer than 60 seconds after the RDF1 group creation) and be available for use on the recovery site Solutions Enabler server.
A device group that has been created by this mirroring mechanism is flagged internally by GNS as being a mirror. By default, these mirrored groups are read-only and cannot be modified or renamed by administrators. Only GNS is permitted to continue to update them as the local groups upon which they are based are changed.
Consequently, GNS Remote Mirroring alters how the SRA must handle adding replica devices to target RDF2 groups for test failover. When the remote mirroring option is set and the RDF2 group that contains the devices in the protection group(s) is in fact a remote mirror the SRA cannot add the TimeFinder replica devices to the RDF2 group in the typical fashion. The SRA must instead add them to the RDF1 group as remote target devices. The GNS daemon will recognize this change and will propagate the remote targets to the remote group. In the remote group, the devices that were labeled as remote targets in the RDF1 group will appropriately become local targets in the RDF1 group. This will allow the TimeFinder operations executed by the SRDF SRA to succeed while adhering to GNS remote mirroring rules.
As an example, during test failover, the SRA will ascertain whether or not the target local device/composite group is GNS enabled and, most importantly, a remote mirror. Figure 88 shows a printout of a device group that is remotely mirrored in GNS.
During the test failover operation the SRA will log the following messages (among others) when detecting a GNS Remotely Mirrored group:
SymmUtil::IsGnsGroupDevice] The DG [SRDFS] is being managed by GNS. The DG has flags: 0x18
SymmUtil::IsGnsMirrorGroupDevice] The DG [SRDFS] is mirrored GNS group. The DG has flags: 0x1800
When the device/composite group on the recovery side is determined to be a remote mirror, the SRDF SRA will automatically alter its behavior for this group and add the replica devices as remote targets to the RDF1 group on the protection-side Solutions Enabler server.
It is important to note though that if a mirrored group is directly modified, the connection between it and the local group, on which it was based, is broken. At that point, it is no longer a mirror and changes to its base group (the RDF1 group in this case) may no longer be propagated to it. This may defeat the purpose for originally deciding to use GNS remote mirroring. Consequently, it is not recommended to use mirrored groups with the SRA.
The process to configure Group Name Services is beyond the scope of this book, but for more information please refer to the Solutions Enabler Array Management Product Guide on support.dell.com or Unisphere Online Help for further details.