Home > Storage > PowerMax and VMAX > Storage Admin > Implementing Dell SRDF SRA with VMware SRM > Target Gold Copy considerations and requirements
Target gold copies, intrinsically, are no different than the replicas used for test failover when <AutoTargetDevice> is not in use. They have, for the most part, the same requirements and are created in a similar way. The main differences revolve around when they are created and how they are used. For this reason, the same devices can be used for test failover and then re-purposed for gold copy replicas during a recovery plan. Different devices can, of course, also be dedicated for gold copies if desired.
Whether using the legacy functionality of gold copies (target), or targetless, the timing of the creation of the copies is the same. The protection site gold copies are created at the start of the recovery plan, assuming the protection site is available. The recovery site gold copies, on the other hand, are created immediately prior to failover.
Similar to test failover pairings, the gold copy pairings are saved in XML files. There are two separate files for gold copy pairings for the recovery and protected site and they are respectively:
Note: The creation of gold copies is OPTIONAL and the lack of configuration, by default, will not prevent recovery. Configuring and using gold copies though is recommended and is part of standard recovery best practices, whether with or without a target.
An example of a gold copy XML file is shown in Figure 96. It can be seen by this figure that the XML file is designed almost identical to the test failover pairings configuration file.
The XML file requires the following information:
There are some important points to remember when configuring the options file(s):
Furthermore, most requirements for valid gold copy replicas are identical to test failover:
It should be noted that there are a few important differences between gold copy requirements and test failover replica requirements:
By default, the SRA allows the continuation of the failover process even if the attempt to create a gold copy of the replicated data fails. If the creation of a gold copy of the replicated data is a critical requirement, the value of the option, FailoverIfGoldCopyFails, should be changed to “No” before the execution of the recovery plan. This option is located in the EmcSrdfSraGlobalOptions.xml file and can be edited using any text editor. This option should be edited on the recovery site SRM server to control the recovery side gold copies and on the protected site SRM server to control the protected site gold copies. The parameter applies to both target and targetless.
The SRDF SRA has an additional security check (disabled by default) during test failover and gold copy operations. The CheckForVirtualDisks advanced option will query the input candidate TimeFinder replica devices for whether or not they are currently in use as an RDM or VMFS. If any of the input devices are detected to be one of the two, the SRDF SRA will fail the gold copy operation and no gold copies will be activated. This will prevent an accidental overwrite of RDMs or VMFS volumes by the TimeFinder gold copy operation.
Note: The SRDF 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 a separate environment, VMware or otherwise, the SRA will be unable to detect that and that data will be overwritten.
This option:
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. If this check is desired for both protected and recovery side gold copies for a given recovery operation, the CheckForVirtualDisks advanced option must be enabled for both the recovery and protected site SRDF SRAs.
It order to enable this behavior for recovery site gold copy creation, an administrator must grant recovery site vCenter access for the Solutions Enabler install local to the recovery SRM server. Similarly, in order to enable this behavior for protected site gold copy creation, an administrator must grant protected site vCenter access for the Solutions Enabler install local to the protected site SRM server. Please refer to FilterNonVmwareDevices for instructions on configuring access.
Note: If the credentials are missing or incorrect, the SRDF SRA will not fail the gold copy process and will continue to create gold copies without checking for in-use devices. Therefore, it is important to ensure that valid credentials are added to the Solutions Enabler database prior to recovery.
As previously mentioned, even one device that is deemed to be in-use will prevent the activation of any of the target gold copy devices for a given protection group as this occurrence will fail the gold copy operation immediately[1]. While the gold copy TimeFinder sessions are created one at a time for Clone or VP Snap (SnapVX is a single session), the sessions are not activated until all of the gold copy replica devices are validated and their sessions created (essentially the activate is an all-or-nothing operation). This is because the SRDF SRA requires that there be copies of all the R1 or R2 devices to allow for a scenario that might require a full recovery to the original data. To properly achieve this, there needs to be a copy of all of the devices and they need to be consistent point-in-time copies with each other. Consequently the sessions do not need to be created simultaneously, but they do need to be activated simultaneously.
Therefore, if one device is invalid, the activate operation will not be attempted as the SRDF SRA will be unable to create gold copies for all of the devices. If gold copy protection is an important requirement, it is recommended to disable the advanced option FailoverIfGoldCopyFails (enabled by default) on both the recovery and protected site when CheckForVirtualDisks is enabled.
Disabling FailoverIfGoldCopyFails will then cause the recovery operation to fail if one of the gold copies replicas is found to be invalid. As a result, the source/replica pairing can be reconfigured and the recovery can be attempted again. This will ensure that fully consistent copies of all of the R1 or R2 devices are created and activated during failover.
If the credentials were input incorrectly or missing, further troubleshooting information on can be found in the viclient log created by the SRDF SRA. This log is located on the SRM server in the below locations, Windows and the Appliance respectively.
C:\Program Files\EMC\Solutions Enabler\log
/usr/emc/API/symapi/viclient
The logs are entitled viclient-YYYYMMDD.log. So if the log was created by the SRDF SRA on September 10th, 2012, the log would be entitled viclient-20120910.log.
Common scenarios for errors can be seen in Table 19.
Table 19. Troubleshooting vCenter authorizations
Message logged in viclient.log | Common reason |
SymPwdDbEntryList2() Failed: No objects of the selected type were found | The -vmware option was missed in the command |
RetrieveCredentials Failed: No records were found in the authorization database. | The -namespace option is missing or incorrect |
ViClient::Connect: SOAP 1.1 fault: "":ServerFaultCode [no subcode] "Cannot complete login due to an incorrect user name or password." | Incorrect user name or password |
ViClient::Connect: SOAP 1.1 fault: SOAP-ENV:Client [no subcode] "Host not found" Detail: get host by name failed in tcp_connect() | Incorrect host name or the host name is not configured in DNS or the local hosts file |
ViClient::Connect: SOAP 1.1 fault: "":ServerFaultCode [no subcode] "Permission to perform this operation was denied." | The account supplied is valid but does not have permissions to access the vCenter server |
This option could be beneficial to larger VMware environments where the control of each and every device is tougher due to the higher number of simultaneous users and/or devices.
Note: If there is more than one authorization present on a Windows server, the SRA will use the first in the list. Therefore be sure to check the authorizations using the command symcfg list authorization -vmware to ensure the correct one is listed first (or only).
Although the SRA can create gold copies as part of its behavior, it has no capability to remove or clean them up. For the legacy functionality, after a failover is complete, if the user wishes to have the target devices available for the same or another purpose, the copies must be terminated and any link with the previous source device, removed. If not, future attempts at gold copy creation using the same XML file(s) and device pairing(s) will fail.
For targetless snapshots, as there is no target device, there is no requirement to terminate the SnapVX snapshots the SRA creates; however, remember that all snapshots use metadata so if the targetless gold copy snapshots are not required, best practice is to remove them.
[1] Note that if both recovery side and protected side gold copies are configured for creation, a failure on the protected side gold copy creation will only cause the other protected side gold copies to not be created. The recovery side gold copies will be unaffected and vice versa.