In failure scenarios it is first necessary to determine whether data is mirrored using SRDF or whether a concurrent SRDF configuration is in use. This section deals with the most important failure scenarios (but not those for concurrent SRDF). The failure scenarios and actions to be taken are similar in concurrent SRDF configurations; however, the following constraints must be taken into account on a case-to-case basis:
In the event of local failures, a decision must be made as to which of the two remote sites is to continue operation.
Failure during failback is required because the SWAP-REMOTE-COPY function is not available in concurrent SRDF configurations.
In the event of failback, concurrent SRDF replication should also be resumed at both remote sites.
The following failure scenarios (without concurrent SRDF) and measures for maintaining operation will be examined:
"Failure of the local storage system and of the local system" (Data Center failure)
"Failure as a result of failback to the local storage system"
If a unit fails, it is necessary to establish whether or not the unit was protected by RAID1, RAID5, RAID6 or by a spare unit. If the remote link fails, it is necessary to establish whether one link or the last remote link failed.
After a storage system failure or another failure in the local Data Center, a check should be carried out to establish whether local troubleshooting can recover the application faster than remote recovery. In most cases, local troubleshooting is quicker and remote recovery is not recommended.
If remote recovery is performed, you must consider the application downtime involved in switching to the remote Data Center, starting the application there, and then switching back to the local Data Center once the problem has been resolved.