Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > Snap VX and generations
When using SnapVX as the underlying technology for IgnoreActivatedSnapshots, there is an important caveat. This particular parameter was introduced before SnapVX and the concept of generations. As part of the cleanup that the SRA does when configured to reuse the SnapVX target devices, it relinks the snapshot. It does this without providing a generation, assuming of course there is only one (which would be the case if not using this parameter). If there are multiple generations of a snapshot, and the test uses a generation other than 0, when the SRA cleans up it will relink generation 0, and not the generation initially linked. One of two options will avoid this problem:
The SRA creates and activates the TimeFinder sessions only if the state of the SRDF relationship for the devices involved in the recovery plan is “Synchronized”. Without the additional check, it is impossible for the adapter to determine if the source devices for the TimeFinder sessions contain valid data for testing recovery plans. However, there are situations (for example, enterprise consistency configurations that contain data not within a VMware environment) in which users may nevertheless desire to test the recovery plan even though the SRDF link is not in a preferred state. To accommodate this, the SRA provides the option, TestFailoverForce. When this option is changed from the default value of “No” to “Yes,” the SRA ignores the state of the SRDF links and creates a TimeFinder copy of whatever data is on the R2. In this case, the onus is on the user to ensure that the source devices in the TimeFinder sessions contain a consistent and valid copy of the data. This option permits testing when the protection site is down or otherwise unavailable.
Note: The SRA ignores the consistency state of the SRDF pairs when TestFailoverForce is enabled. It does this by using the FORCE flag on the SnapVX establish. Snapshots established with a FORCE flag cannot be guaranteed for data consistency and so should not be used for backups or for restoring production data.
The SRA offers an additional security check during test failover operations called CheckForVirtualDisks. This advanced option will query the input candidate TimeFinder replica target devices for whether or not they are in use as an RDM or a VMFS. If any of the input devices are detected to be in use in the recovery VMware environment, the SRA will fail the test recovery operation before creating a TimeFinder session for that device pair. This will prevent the accidental overwriting of RDMs or VMFS volumes by the copied data. It is important to note that the SRA will only check for the use of the device in the recovery side vCenter associated with the recovery side SRM server. If the device is in use in another environment, VMware or otherwise, the SRA will be unable to detect that.
This option:
Once this option is enabled, a further configuration is required to provide the SRDF SRA access to the information it requires. The SRDF SRA connects to the local vCenter and queries the vCenter inventory to see if any of the input replica devices are in use. It order to enable this behavior; an administrator must grant vCenter access for the Solutions Enabler install local to the recovery SRM server that will execute the test recovery operation. As readers may note, this is the same process required for the advanced discovery option, FilterNonVmwareDevices. If authorizations were created for use with that option, no further configuration is required and the process can be skipped; otherwise please refer to FilterNonVmwareDevices for instructions.
Note: If the credentials are missing or incorrect the SRDF SRA will not fail the test failover process and will continue to create replicas without checking for in-use devices. Therefore, it is important to ensure that valid credentials are added to the Solutions Enabler database prior to test recovery.
By default, the SRA will not terminate snapshot sessions, nor unlink device targets. This allows for quicker re-testing of recovery plans by avoiding the step of recreate and relink. The behavior can be changed to instead terminate all sessions by setting the global option, TerminateCopySessions to “Yes”. If the adapter is set to terminate the copy session, it will also remove the target devices from the device/composite group. If it is not set to terminate the sessions, the target devices will remain in the group.
This option only is relevant to test failovers that use TimeFinder. It has no effect on test failovers executed with the option TestFailoverWithoutLocalSnapshots enabled.
The TimeFinder device pairings for test failover are stored in an XML file (EmcSrdfSraTestFailoverConfig.xml) on the recovery site. This file is only required if the recommended option of AutoTargetDevice is not in use. An example options file is shown in Figure 62.
Figure 62. EmcSrdfSraTestFailoverConfig.xml file example
There are a few different blocks within the XML file:
There are some important points to remember when configuring the options file manually. This does NOT hold true for AutoTargetDevice:
Note: When using AutoTargetDevice, if additional pairs are added to a protection group/recovery plan and snapshots exist from a previous test (i.e., the test failover XML file has entries), the new pairs are added after the current <CopyInfo> block, creating a new block. Therefore it is strongly recommended to set AutoTargetDeviceReuse=no and run a test BEFORE adding more pairs so the XML file is clean.
Note: The test failover XML file must be configured properly prior to the “Test” operation and the “Cleanup” operation. The SRA does not maintain a memory of device pairings used in a “Test” operation for the eventual “Cleanup” operation. The SRA will reference the options file both times for pairing information. If a long time has passed since the “Test” operation was run and before the “Cleanup” is run it is possible that the options file has been reconfigured and may no longer include the valid pairs for Cleanup. Therefore it is important to verify the pairings are correct immediately before a “Test” and a “Cleanup” or those operations may fail.
For automated masking operations for test failover, the advanced option TestReplicaMaskingControl must be enabled on the recovery side SRA. When enabled the following behavior will be added: