Data mobility refers to the periodic creation of a consistent version of the productive data at a second, geographically distant location. It is therefore an appropriate variant for implementing a disaster protection strategy. It is based on a configuration of local and remote replication in a specified configuration and, depending on the application scenario, provides an alternative to synchronous and asynchronous remote replication.
Data mobility defines the hardware and software configuration for redundant data management using mixed replication functions for the ETERNUS DX/AF and Symmetrix/VMAX3 storage systems.
Data mobility uses pubsets as data management units.
Control of the processes required can be automated using SHC-OSD commands in procedures.
Data mobility comprises two scenarios:
Automatic and periodical creation of consistent data at a second, geographically distant location. The synchronization point is defined by the application.
Quick reconstruction of the data from the second, geographically distant location.
In the following information the ETERNUS DX/AF storage systems are taken as an example. The scenarios described also apply for Symmetrix/VMAX3 systems.
Initial configuration
The initial configuration is a combination of local replication using QuickOPC or EC (see also section “Coexistence of QuickOPC and EC” in "Local replication with clones (ETERNUS DX/AF, Symmetrix/VMAX3)") in both the local storage system and in the remote storage system in conjunction with remote replication using REC.
Figure 23: Data mobility: Initial configuration
Creating the consistent data
To create the consistent data on the second, geographically distant location, first of all a synchronization point is defined and created for use in the local storage system. In an initial step local replication using QuickOPC/EC is updated/suspended at this synchronization point, thus ensuring consistent data on the local clone unit. Subsequently the application can continue to execute.
Parallel to this the local clone unit, which is also the source unit for remote replication using REC, is synchronized with the target unit in the remote storage system.
After synchronization has been concluded, in a further step the clone unit for QuickOPC/EC is updated with this status on the remote storage system and then split for EC also. As a result the data created is now available on the clone unit of the remote storage system.
This procedure can be repeated periodically. Further consistent backups of the data will then be created on clone units of the remote storage system.
Reconstruction
The backed-up data is reconstructed from the clone unit of the remote storage system to the original volume.
Various options are available for this:
Reconstruction from the clone unit in the remote storage system directly to the original unit in the local storage system in the following steps (recommended procedure):
Cancel the clone pairs in the local and remote storage systems with
/STOP-CLONE-SESSION
Suspend remote copy mode with
/HOLD-REMOTE-COPY
Temporary replication (using REC) from the clone unit of the remote storage system to the original unit of the local storage system to synchronize the data inventories:
Create remote copy pair with
/START-REMOTE-COPY UNIT=<clone-unit (remote)>, TARGET-UNIT=<original-unit (local)>, WAIT=*UNTIL-SYNCRONIZATION
Figure 24: Data mobility: Reconstruction of clone unit (remote)
Suspend remote copy mode and rename pubset with
/HOLD-REMOTE-COPY UNIT=*BY-PUBSET(PUBSET=..., NEW-PUBSET=...)
Temporary remote copy mode terminated with
/STOP-REMOTE-COPY
Set up the initial configuration for data mobility again
The advantage of this concept is that the original data is reconstructed quickly in one synchronization process with few processing steps.
The disadvantage of this concept is that a complete copy is needed both when restoring the original unit and also after this when reconstructing the original configuration for data mobility.
Reconstructions are rare processes.
Continuation of the application(s) using the remote storage system as the database without reconstruction (reversal of the replication direction in the case of symmetrical configurations)
Terminate remote copy pairs with
/STOP-REMOTE-COPY
Restart the application, use remote storage system
Split the remote and local remote copy pairs
Create remote copy pair with
/START-REMOTE-COPY UNIT=<clone-unit (remote)>, TARGET-UNIT=<original-unit (local)>, WAIT=*UNTIL-SYNCRONIZATION
Figure 25: Data mobility: Symmetrical configuration
The advantage of this concept is the rapid restoration of the configuration for data mobility.
The disadvantage of this concept can be that the application(s) is/are relocated or restarted using the original unit in the remote storage system as the database.
Reconstruction through temporary reversal of the replication direction for all mirror pairs in the following steps (for EC only):
Swap the original and clone properties of the clone pairs in the local and remote storage systems with
/SWAP-CLONE-SESSION
Swap the source and target properties of the remote copy pair with
/SWAP-REMOTE-COPY
Figure 26: Data mobility: Temporary reversal of the replication direction
Start resynchronization for all EC and REC pairs beginning with the clone unit on the remote storage system.
Set up the initial configuration for data mobility again
The advantage of this concept is that only delta copies are required both for reconstruction and also for restoring the initial configuration for data mobility. Consequently only a slight load is placed on the storage systems and the remote links.
The disadvantage of this concept is the large number of processing steps involved in reconstructing the original data.