Using Asynchronous PPRC (Global Mirror) for Failover on zSeries

Using Asynchronous PPRC (Global Mirror) for Failover on zSeries

Content
For the following steps we assume that you have an established Asynchronous PPRC session continuously creating Consistency Groups at the local site and sending them to the remote site, as shown in the picture below.



If you have a disaster at the primary site and therefore have to start the production at the remote site, you will need to ensure that you use the data from the most valid Consistency Group at the secondary site.

You will later want to return production to the local site. If you have a running system at the remote site that is independent of the local site, you can use the ICKDSF commands to perform the failover. You should have jobs and/or automation procedures prepared to do the steps below. Otherwise, you have to use the Web User Interface with prepared tasks to perform the following steps for a disaster at the primary site where all or a part of the local site is lost.

Failover to the remote site
1. If the Master of the Asynchronous PPRC session is still active, issue the TERMINATE SESSION command to the Master, otherwise go to step two. This will stop the Master trying to create Consistency Groups if this process is still running. Address this command to the same LSS you used to start the session.

2. Failover to the PPRC secondary volumes using the ESTABLISH PAIR command with the FAILOVER option at the remote site to the PPRC secondary volumes. These volumes become primary suspended.

3. Usually the most recent and consistent data resides on the FlashCopy target volumes and you have to copy this data back to the FlashCopy source volumes in step 4. But it is required to check the consistency status of the FlashCopy pairs, even if it is unlikely to have inconsistent data at the FlashCopy target volumes. This can be done by issuing the FLASHCPY QUERY RELATIONS command to each of the FlashCopy primary volumes. The queries provide a FlashCopy sequence number for each volume and whether or not the volume is revertible to the previous FlashCopy relationship. In most of the cases the volumes are consistent and you can continue with step 6. Use this table to decide on the correct action.



If the indication directs you to revert the FlashCopy pairs back to the previous FlashCopy relationship, submit the FLASHCPY WITHDRAW command with the REVERT option. If you are directed to commit all of the FlashCopy pairs to the new FlashCopy relationship, submit the FLASHCPY WITHDRAW command with the COMMIT option.
Note: These commands do not withdraw the relationships.

4. Issue a FLASHCPY ESTABLISH PAIR command with FASTREVERSERESTORE and TGTOKASPPRCPRIM(YES) parameter to the PPRC secondary volumes. This will reverse the direction of the FlashCopy relationship and copy the consistent data to the suspended PPRC secondary volumes at the remote site.
Note: The FlashCopy relationship will end after the background process has finished. The former FlashCopy target volumes, the C volumes, are no longer usable.

5. Before you continue, the background copy process should be finished. This should be very fast as only small data differences have to be copied. Before you start the applications at the PPRC secondary volumes (now suspended primary) you should establish a FlashCopy to the original FlashCopy target volumes with the specific options as the previous inband command for establishing the original FlashCopy. (MODE(NOCOPY), INHIBITTARGETWRITE, CHANGERECORDING(YES)), then set the former PPRC secondary volumes online to the remote systems, test the data and start the applications.

Now your production workload is running at the remote site.

Moving the workload back to the local site
1. If your applications at the remote site are running and the local site has recovered from the disaster, you may want to revert the production workload to the local site again. For this reason you should establish PPRC paths to the local site ESS to enable the PPRC mirror to the local site. As Fibre Channel PPRC links are bidirectional links, these paths can be established prior to this procedure.

2. Issue the PPRCOPY ESTPAIR command with the mode XD and FAILBACK option to the remote site PPRC volumes. Now the local site volumes change from primary suspended to PPRC pending copy state. The changed data from the remote site will be drained now to the local site.

3. Wait until the first pass of the PPRC-XD copy process of all volumes has finished, then shutdown the applications. Use the PPRCOPY QUERY command to check the volumes for out-of-sync cylinders. Alternatively you can catch-up the volumes to the duplex state with the PPRC ESTABLISH PAIR command with synchronous mode. When the number of out-of-sync cylinders is zero, proceed to the next step.

4. Submit the PPRCOPY ESTPAIR command with the FAILOVER option to the local volumes that will become primary suspended.

5. Reestablish the paths from the local to the recovery site again. Now you can start the applications at the local site, check the data and if the systems are running, issue the PPRCOPY ESTPAIR command with FAILBACK and mode XD to the local volumes.

6 .Finally, Asynchronous PPRC has to be restarted again by submitting the PPRCOPY STARTASYNCOPY command to the local volumes.

Note: If the disaster destroys the primary devices and you need to replace them, previously defined jobs or tasks can not be used because the serial numbers of the new ESSs are different.