HDS True Copy

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.

Configuring TrueCopy

To configure TrueCopy you run through the following steps

• Plan out and configure your local and remote storage systems, so that the secondary copy volumes are the same size as the equivalent primaries.
• Connect the local and remote storage systems with a Fibre Channel channel data path.
• Hitachi Open Remote Copy Manager (HORCM) controls remote mirroring for open systems. It runs as a daemon process on the CCI server. It needs two configuration definition files that describe the storage systems, pair volumes, and data paths. One file describes the P-VOLs and the other the S-VOLs. Define these two files, then start two HORCM instances with command

  horcmstart 0 1 This will start two daemons, which you can refer to in commands as IH0 and IH1.

• The Fibre Channel ports need to be pairs of Initiator ports to send data, and RCU target ports, which receive data. You need to configure ports and paths in both directions. The commands below show how to set up one pair of paths, but you will need several pairs for performance and resilience. The primary serial number is shown as 64539 and the secondary as 64642, the Raid Type is R800 and the pid is 0. You will need to substitute your own values, and your values for the ports.
  
  Change one pair of port attributes (primary CL1-A and secondary CL1-C) to be Initiator and RCU Target respectively.

  raidcom modify port -port CL1-A -port_attribute MCU -IH0
  raidcom modify port -port CL1-C -port_attribute RCU -IH1

  Add a remote connection with path group ID 0 from primary storage system port (CL1-A) to secondary storage system port (CL1-C).

  raidcom add rcu -cu_free 64539 R800 0 -mcu_port CL1-A -rcu_port CL1-C -IH0

  Change 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

  Add the reverse remote connection with path group ID 0 from secondary storage system port (CL2-C) to primary storage system port (CL2-A).

  raidcom add rcu -cu_free 64642 R800 0 -mcu_port CL2-C -rcu_port CL2-A -IH1

• Create Device Groups on the source and destination VSPs

  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

  Create Copy Groups on the source and destination VSPs

  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

• Update the HORCM configuration files with the Copy Groups:
• Restart both of the configured HORCM files

  horcmshutdown
  horcmstart.

• Create the replication pair

  paircreate –ITC# -g Prod_Cluster_01 -f never –vl –c

• Monitor the replication pair

  pairdisplay –ITC# -g Prod_Cluster_01 -fcx –CLI

HDS Universal Replicator

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.

HUR with TrueCopy and ShadowImage

True Copy (TC) can be combined with Universal Replicator (UR), the asynchronous solution, in the following configurations.

• In a 3-data-center cascade configuration (3DC cascade), three data centers are used — the TC production site, the TC/UR intermediate site, and the distant UR remote site. With this configuration, you can locate the TC synchronous site near the local site to lower I/O response time, while the UR backup provides a disaster recovery solution at a remote site.
• In a 3-data-center multi-target configuration (3DC multi-target), the production volume is shared by the TC and UR. This volume is the primary volume (P-VOL) for both at the local site. The targets of each system are located at different remote sites. They provide the TC solution and the UR asynchronous disaster recovery solution. The TC secondary site is at an intermediate location, the UR secondary site is at a distant location. This is illustrated in 3DC multi-target configuration on page C-4.
• Another use of the 3DC multi-target is the UR Delta Resync pair, which provides a quick way to regain a long distance copy after disaster in the event that the TC/UR P-VOL becomes unusable. In this case, the host continues I/O operations at the intermediate TC S-VOL site. With a second UR pair previously set up between the TC S-VOL and the UR SVOL, only differential data needs to be copied to the UR S-VOL. Delta resync is illustrated in Delta resync configuration on page C-6.
• In a 2-data-center configuration (2DC), data is copied from the TC PVOL to an intermediate site, though not to the TC S-VOL. Instead, the data is copied to the UR master journal volume. This results in an asynchronous copy that side-steps the TC S-VOL, and thus enhances overall transfer speed to the UR S-VOL.

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.

HUR Volume States

The primary volumes are called P-VOLs and secondarys are called S-VOLs. The allowed status for a volume are

SMPL

indicates unpaired volumes. Both primary and secondary are R/W enabled

PAIR

means volumes are paired and the initial copy is complete. The pimary disk is R/W enabled while the secondary is read only (but S-VOL read is always disabled if the paircreate command was run with the -m noread option)

COPY

means volumes are paired but the operation, which can be copy, pairsplit, or resync, is not complete. The primary disk is R/W enabled while the secondary is read only

PSUS and SSUS

indicates that the volumes are in a paired state, but updates to the S-VOL data are suspended due to a user-requested pairsplit. The hardware keeps track of updates to the P-VOL so they can be applied to the S-VOL if the pair is re-established. If the pairsplit command used the write-enable option to enable writes to the S-VOL, then these updates are also tracked while the pair is split. The pimary disk is R/W enabled and the Secondary is either read only or read/write depending on the split parameter.

PSUE

means that an error has happened and mirroring is suspended. When the error is corrected and mirroring re-snychronised, the entire P-VOL is copied over to the S-VOL. If there were no errors on the P-VOL, then it will be in R/W status.

HUR Functions

Creating a Mirrored Pair

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

Splitting Pairs

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.

back to top

---