- IBM Metro Mirror
- PPRC Commands
- EMC SRDF mirroring
- SRDF Commands
- HDS Universal Replicator
- Global Mirror
- z/OS Global Mirror
TrueCopy mirrors data volumes between two HDS VSP storage subsystems. The mirroring is synchronous, so the two subsystems need to be within Metropilitan distances. TrueCopy ensures that the data stays synchronised as the host will not consider an I/O to be complete until acknowledgement is received from the remote storage system.
To configure TrueCopy you run through the following steps
horcmstart 0 1 This will start two daemons, which you can refer to in commands as IH0 and IH1.
raidcom modify port -port CL1-A -port_attribute MCU -IH0
raidcom modify port -port CL1-C -port_attribute RCU -IH1
raidcom add rcu -cu_free 64539 R800 0 -mcu_port CL1-A -rcu_port CL1-C -IH0Change one pair of port attributes (secondary CL2-C and primary CL2-A) to be Initiator and RCU Target respectively.
raidcom modify port -port CL2-A -port_attribute RCU -IH0
raidcom modify port -port CL2-C -port_attribute MCU -IH1
raidcom add rcu -cu_free 64642 R800 0 -mcu_port CL2-C -rcu_port CL2-A -IH1
raidcom add device_grp -device_grp_name Prod_Cluster ProdStore_02 -ldev_i 64539 -IH0
raidcom add device_grp -device_grp_name Prod_Cluster ProdStore_02 -ldev_id 64642 -IH1
raidcom add copy_grp -copy_grp_name Prod_Cluster_01 Prod_Cluster -IH0
raidcom add copy_grp -copy_grp_name Prod_Cluster_01 Prod_Cluster -IH1
paircreate –ITC# -g Prod_Cluster_01 -f never –vl –c
pairdisplay –ITC# -g Prod_Cluster_01 -fcx –CLI
HDS Universal Replicator is an asynchronous remote mirroring product. Mirroring products require 2 sets of volumes, Primary Volumes in a local site and Secondary Volumes in a remote site. The data on the Secondary Volumes is generally used for disaster recovery purposes and so kept in step with the primary volumes. HDS Universal Replicator (HUR) is intended to be used when the local and remote sites are too far apart for the data to be absolutely identical, as this requires that application update activity at the local site is held until the update reached the remote site. Instead, I/Os are marked complete as soon as they reach the primary disks, then transferred seconds later to the remote site. This is called Asynchronous Mirroring. The trouble is that the I/Os to the remote site must be prresented in the same consistent order as they were at the primary site.
To achieve this, HUR uses a journalling system. Write I/Os to the primary disk subsystem are written to both the primary disk and a Master Journal volume where they are time stamped. These writes are then mirrored over the comms links to the remote site, to a Restore Journal disk, and then copied onto the Secondary Volumes in the correct order. The data on the Secondary Volumes will lag behind the Primaries by a few seconds, the exact RPO will depend on the speed of the links and the distance between sites.
The Secondary Volumes must first be populated by copying all the data over from the Primary Volumes, and the Secondary Volumes cannot be mounted to hosts to preserve the data integrity. Once the data is copied and mirroring commences, the pairs can be split and the Secondary Volumes write enabled so that the DR position can be tested. While a split is in progress, bit maps are maintained at both sites so that mirroring can be resumed again without needing a fresh copy of the data, just those changed blocks need to be copied.
True Copy (TC) can be combined with Universal Replicator (UR), the asynchronous solution, in the following configurations.
HUR would typically be used with TrueCopy in a 3 site configuration, where TrueCopy is used for synchronous mirroring between two quite local sites and HUR is used to mirror data to a third, very remote site.
This can work in a cascade configuration, whith a Truecopy P-VOL in the Primary site, mirrored to an S-Vol in the intermediate mirror site. This S-VOL also acts as a P-VOL for HUR, and is associated with a Master Journal. The Master Journal is replicated to a Restore Journal at a third, remote site, where the data is transferred to an S-VOL.
The other option is a multi-target configuration, where the P-Vol at the Primary Site is synchronously mirrored to an S-VOL at a secondary Site, and is also associated with a Master Journal. The Master Journal is replicated to a Restore Journal at a third, remote site, where the data is transferred to an S-VOL.
When HUR is used with ShadowImage, the Shadow Copy is usually create at the Remote site for testing. You can then suspend the mirroring, create the ShadowImage, then resume mirroring with very little loss in DR postion. You now have a complete and independent copy of the data at the remote site for testing.
The other use of ShadowImage, would be a local copy taken at the Primary site. This would typically be used for local backups. It should not affect the HUR process, unless you decide to copy the ShadowImage back onto the primary disk. This would cause an I/O surge that could overwhelm your journal disks.
The primary volumes are called P-VOLs and secondarys are called S-VOLs. The allowed status for a volume are
You need to know the port, GID and LUN of the volumes that you wish to pair. Once you have that information, select your P-VOL and S-Vol using those numbers. Then select a Master Journal, Restore Journal and Mirror ID to associate with this pair. You then need to specify a consistency group number, and HDS recommends you make this the same as the journal number. Select your copy method, which will probably be ENTIRE if this is the first time. There are other parameters available, but you can take the defaults. Of course, you can run this process for several volumes at once.
You can use the GUI or the pairdisplay command to monitor the mirroring status of volumes, including progress of any volumes being mirrored or resynchronized. The -g group_name option is used to display all disks in a group and the -l option is used if only one of the sites is available
pairdisplay -g GRP
Once mirroring is established and the pairs are in COPY or PAIR ststus, you can split a pair to give you a PIT copy of the P-VOL. If you then write-enable the S-VOL you can bring it online to a host for testing purposes. An effective way to utilise this is to take a ShadowImage copy of the S-VOL, then you can resume mirroring and still have a copy of the data for testing.
When a split command happens, the journalled write data is nolonger sent to the S-Vol and the volume status changes from PAIR to PSUS or SSUS as appropriate. However the pair relationship is maintained and updates from both sides are recorded for future resynchronisation.
If your volume is part of a mirrored group, then you need to split the whole group to get a consistency point between the disks in the group.
When you are ready, you can re-establish the secondary volume as a synchronised copy of the primary volume. This is done by merging the bit-maps that were maintained while the split was in operation, so that updated data on the S-VOL is back levelled from the P-VOL and also any updates made at the P-VOL are copied over too.
Again, if your volume is part of a mirrored group, then you need to resynchronise the whole group.