Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > Testing recovery plans using TimeFinder/SnapVX
TimeFinder/SnapVX provides space-efficient snaps, while offering efficient usage of metadata and flash memory and simplified pool management. It is the preferred technology for use with the SRDF SRA.
SnapVX creates snapshots by storing changed tracks (deltas) directly in the Storage Resource Pool (SRP) of the source device. With SnapVX, you do not need to specify a target device and source/target pairs when you create a snapshot. These snapshots are “targetless”. To access a point-in time-copy, however, one must create a link from the snapshot data to a host mapped target device. The links may be created in Copy mode for a permanent copy on the target device, or in NoCopy mode for temporary use. Copy mode links create
full-volume, full-copy clones of the data by copying it to the target device’s Storage Resource Pool. NoCopy mode links are space-saving snapshots that only consume space for the changed data that is stored in the source device’s Storage Resource Pool. NoCopy is the default mode when using SnapVX with the SRA and is recommended.
If there is ever a need for the application to use the point-in-time data, you can create links from the snapshot to one or more target devices. If there are multiple snapshots and the application needs to find a particular point-in-time copy for host access, you can link and relink until the correct snapshot is located. Snapshots can be set to expire or manually terminated.
SnapVX operations are performed using the symsnapvx command to create point-in-time copies (snapshots) of critical data. SnapVX supports up to 256 snapshots per source device (including any emulation mode snapshots) and 1024 linked targets. For a more detailed overview of TimeFinder SnapVX functionality including I/O flow, refer to the array product guides.
The process for using TimeFinder/SnapVX replicas of R2 devices is explained in this section using the EmcSrdfTestFailoverConfig.xml file. This example uses synchronous SRDF, but asynchronous would follow a similar process. This process is only used when the option AutoTargetDevice in the global options file is set to NO. The following steps should be adhered to when testing recovery plans with TimeFinder/SnapVX technology:
In addition to selecting the device pair, the user should select whether to use COPY or NOCOPY (default) mode. For most SRM tests, NOCOPY is the most appropriate mode as the intent is not for the replicas to be of a permanent or long-lasting nature.
Figure 63 shows the options file containing the pairings required to test a recovery plan. The figure demonstrates the organization of the options file and the tag, ArrayID, which enables the adapter to support multiple storage arrays in a single recovery plan. Thus, when a recovery plan involves multiple VMAX/PowerMax arrays at the target, a CopyInfo stanza with appropriate TimeFinder technology, VMAX/PowerMax serial number, and device pair definitions should be created for each VMAX/PowerMax array.
The state of the SnapVX pairs when the test environment is running can be verified by utilizing the Solutions Enabler command, symsnapvx. An example screenshot is shown in Figure 65.
The termination of the recovery plan test is accomplished by clicking the Cleanup link as discussed previously in this chapter. The SRA automatically re-creates the TimeFinder/SnapVX link during the next failover test as seen in Figure 66. Note the change in the “Last Snapshot Timestamp”. If the user prefers, the SRA can terminate all sessions (unlink and terminate) by setting the global option, TerminateCopySessions to YES.
The process for using TimeFinder/SnapVX replicas of R2 devices is explained in this section using the global option AutoTargetDevice. This example uses synchronous SRDF, but asynchronous would follow a similar process. This process is only followed when the option AutoTargetDevice in the global options file is enabled. Note that AutoTargetDevice is only available with TimeFinder/SnapVX technology. TimeFinder/Clone will always require manual creation of the target devices. The following steps should be adhered to when testing recovery plans:
In addition, by default the NOCOPY option is used for SnapVX. If the user desires COPY, the <CopyMode> should be adjusted in the EmcSrdfSraTestFailoverConfig.xml file along with the <ArrayId> and the <Source> devices. For most SRM tests, NOCOPY is the most appropriate mode as the intent is not for the replicas to be of a permanent or long-lasting nature.
Figure 67 shows the options file containing no actual pairings because AutoTargetDevice is in use; however notice that the R2 devices are present, the targets are empty, and that the <CopyMode> is set to COPY indicating that SnapVX will copy all the data from the sources to the targets. Note that doing so will mean that if the devices are not reused with AutoTargetDeviceReuse, the cleanup operation will take longer since the devices may require more time to drain.
As the EmcSrdfSraTestFailoverConfig was modified to copy the data from the target, the log file will show this Figure 69.
Figure 70 shows the final state with the linked targets.
The termination of the recovery plan test is accomplished by clicking the Cleanup link as discussed previously in this chapter. In this example, AutoTargetDeviceReuse is disabled which means that TerminateCopySessions must be enabled in the global options file.
The snapshot therefore will be unlinked and terminated and the devices deleted as seen in Figure 71 and Figure 72.
A known issue can arise when running the Cleanup after utilizing TimeFinder SnapVX in test failover. The following paragraph explains how to address it.
When a SnapVX target is first linked, all of the tracks are known as “undefined”. At this point the target does not know where in the SRP the track is located, and host access to the target must be derived from the SnapVX metadata. A background process is run to define the tracks and updates the thin device to point directly to the track location in the source device's SRP. This process is completed fairly quickly, however the larger the device, the longer the process. There can arise situations where the SRM Cleanup operation is run before the define is complete. In such cases, the SRA cannot unlink the target as that would cause the target to become undefined. An error message will appear in the SRA logs similar to the following:
[11/29 18:12:56 15592 13653 SraSnapVxDg::DoSraAction] Performing SymSnapvxControl() for the SNAPVX action [UNLINK] on Snapshot [SRA-SVX-30088_161129175135402] for
[1] devices
[11/29 18:12:58 15592 3716 SraSnapVxDg::DoSraAction] [ERROR]: Failed to perform SNAPVX operation [UNLINK] on DG [VEGRP12], Symm [000197000115].
[ERROR]: [SYMAPI_C_SNAP_UNLINK_WOSF: The unlink cannot be completed in this state unless the Symmetrix force flag is used]
[11/29 18:12:58 15592 14334
SraSnapVxGroup::DeactivateSnapshot] [ERROR]: Could not perform SNAPVX [UNLINK] on device pairs within the DG [VEGRP12].
[11/29 18:12:58 15592 10516
TestFailoverStopCommand::RunOnGroup] [ERROR]: Failed to restore deactivate snapshots for the group [VEGRP12].
Exiting with failure
If this error is received, the state of the SnapVX target can be checked with the following command and demonstrated in Figure 73.
snapvx list -sid xxx -dev xxx-linked
While the Defined state is in progress, a Cleanup will fail. Once the ‘X’ bit is set, it will be safe to re-run the Cleanup operation.