TimeFinder/Snap sessions can be created on SRDF source and target units, i.e. snap units can be assigned to both the source and the target unit of a remote copy pair. The snap unit and the source/target unit then form a snap pair in the context of a snap session. The source/target unit is then also the original unit of the snap pair.
When a snap pair consists of a target unit and a snap unit, access to the snap pair via the VSN or pubset ID is not possible because the target unit is generally not readable. If the source unit is attached, the pubset ID of the source unit can also be specified in the snap session commands using the UNIT=*BY-PUBSET(...) operand in conjunction with SELECT=*TARGET-UNIT.
Prerequisites for addressing a snap pair with target unit via the pubset ID or VSN:
SRDF mirroring takes place between two Symmetrix systems, not between Symmetrix and VMAX3).
The source unit is attached.
Synchronous processing mode must be set for
/ACTIVATE-SNAP.In addition, remote copy mode must be suspended (
/SHOW-REMOTE-COPY-STATUSshows the remote copy statusIN-HOLDorERROR) in the event of/ACTIVATE-SNAP, or if remote copy mode is active, the remote copy pair must be synchronized.
SF pubsets can also be renamed using /ACTIVATE-SNAP NEW-PUBSET=<new cat id>. The I/Os to the source unit can be suspended in ongoing operation using the HOLD-IO=*UNTIL-ACTIVATED operand to ensure consistent splitting.
Scenarios for TimeFinder/Snap in SRDF configurations
No renaming of the snap units
The source unit and target unit form a remote copy pair (see figure 33).
At the same time the two also each form a snap pair:
The source unit with the snap unit of the local storage system
The target unit with the snap unit of the remote storage system
Figure 33: TimeFinder/Snap with SRDF, no renaming of the snap units
The server has no connections to the remote storage system, which cannot therefore be accessed directly from the server. The target unit cannot be addressed via the VSN or pubset ID. The source unit has pubset ID A.
The snap pair in the remote storage system is activated using /ACTIVATE-SNAP UNIT=*BY-PUBSET(PUBSET=A),SELECT=*TARGET-UNIT. In the case of concurrent target units, the required target unit is selected by specifying the RA group.
With renaming of the snap units
The source unit and target unit form a remote copy pair (see figure 34).
At the same time each of the two units forms a snap pair:
The source unit with the snap unit of the local storage system
The target unit with the snap unit of the remote storage system
Figure 34: TimeFinder/Snap with SRDF with renaming of the snap unit in the remote storage system
The server has connections to the remote storage system, which means that the latter can be accessed directly by the server. The target unit cannot be addressed via the VSN or pubset ID. The source unit has pubset ID A.
/ACTIVATE-SNAP UNIT=*BY-PUBSET(PUBSET=A,NEW-PUBSET=B) causes the snap pair in the local storage system to be split and the snap unit’s pubset ID to be changed to B.
/ACTIVATE-SNAP UNIT=*BY-PUBSET(PUBSET=A,NEW-PUBSET=C),SELECT=*TARGET-UNIT is used to split the snap unit in the remote storage system, and the pubset ID of the snap unit is changed to C. In the case of concurrent target units, the required target unit is selected by specifying the RA group.
This permits the units to be used as follows, for example:
the source unit (with pubset ID A) for the main application
the snap unit of the local storage system (with pubset ID B) for the backup
the target unit as a copy in case a disaster occurs
the snap unit of the remote storage system (with pubset ID C) for evaluations
/RESTORE-FROM-SNAP for an SRDF target unit can be used only if the target unit is in the READY status, i.e. the remote copy status is IN-HOLD or ERROR and TARGET-ACCESS has the value DIRECT. As a result of this, the last consistent status can, for example, be copied from the snap unit to the target unit in the event of a disaster.