SVC, Storwize Global Mirror with Change Volume support

Global Mirror with Change Volumes (GMCV) is a new function available for San Volume Controller and the Storwize storage servers.  PowerHA support of Global Mirror with Change Volumes requires PTFs for 7.1 or 7.2 (see table for PTF numbers).  The SVC/Storwize release required is at least 6.4.1.

Prior to the release of GMCV, Global Mirror guaranteed a consistent copy on the target side, but the recovery point objective (RPO) was not tunable, and usually within seconds.  This solution required enough bandwidth to support the peak workload.

Global Mirror with Change Volumes uses FlashCopy internally to guarantee the consistent copy, but offers a tunable RPO, called a cycling period.  Global Mirror with Change Volumes may be appropriate when bandwidth is an issue, although if bandwidth cannot support the replication, the cycling period may need to be adjusted from seconds up to 24 hours.

The original version of Global Mirror sends the changes as they occur, and a sequence number is used to ensure that the changes are applied to the target in the correct order.  With Global Mirror with Change Volumes, a FlashCopy mapping, called a change volume, exists on both the source and target.  When replication begins, all data is sent from the source to the target, and then changes are tracked on the source change volume.  At the end of each cycle period, the changes accumulated in the source change volume are sent to the target change volume, which then stores that set of data as a consistent copy.  If it takes longer than the cycling period to send the changes, then the next cycle period will start as soon as the previous one finishes.  The cycling period default is 300 seconds (5 minutes), but this can be adjusted by the user up to a maximum of 24 hours.

The RPO will be determined by how long it takes for the cycle to complete.  If the cycle completes within the configured cycle time, then the maximum RPO is 2 * cycle time.  If all the changes cannot be written within the cycle period, then the maximum RPO will be the sum of the previous and current cycle times. 

Here are a couple of examples to show RPO in different situations:

Example 1:  5 minute cycle period, 4 minutes to synchronize data

12:00 : consistent target copy, RPO = 0

12:01 : RPO = 1

12:02 : RPO = 2

12:03 : RPO = 3

12:04 : RPO = 4

12:05 : RPO = 5, cycle completes, changes flow to target

12:06 : RPO = 6

12:07 : RPO = 7

12:08 : RPO = 8

12:09 : consistent copy as of 12:05, RPO = 4

12:10 : RPO = 5, cycle completes, changes flow to target

…

Example 2:  5 minute cycle period, 8 minutes to synchronize data

12:00 : consistent target copy, RPO = 0

12:01 : RPO = 1

12:02 : RPO = 2

12:03 : RPO = 3

12:04 : RPO = 4

12:05 : RPO = 5, cycle completes, changes flow to target

12:06 : RPO = 6

12:07 : RPO = 7

12:08 : RPO = 8

12:09 : RPO = 9

12:10 : RPO = 10

12:11 : RPO = 11

12:12 : RPO = 12

12:13 : cycle completes, RPO = 8

12:14 : RPO = 9

…

12:20 : RPO = 15

12:21 : cycle completes, RPO = 8

…

Configuring Global Mirror with Change Volumes is done from the SVC/Storwize user interface.  Once the required PowerHA PTFs are applied, IBM PowerHA SystemMirror for i will recognize that GMCV has been configured and manage the replication environment accordingly.  If GMCV is configured and the PTFs are not applied on both the source and target systems, the periodic health check will fail, and any planned or unplanned switch would also fail. 

 In order to ensure that no data is lost in a planned switch, switchovers in a GMCV relationship have the following restrictions.

• If replication is not active (suspended, detached, or otherwise inconsistent), switchover is not allowed.  Switchover can be retried after mirroring is resumed.
• If replication is active, PowerHA will run checks to ensure that the data on source and target is equivalent.  There could be delay in the switchover process as PowerHA will wait for equivalence before completing the switch.  If at some point in the switchover process the synchronization is suspended, the switchover will fail.

In order to ensure that the target has the latest consistent data in an unplanned switch, failovers in a GMCV relationship have the following restrictions:

• If replication is not active (suspended, detached, or otherwise inconsistent), the failover will fail and storage will not be changed.
• If replication is active, failover will wait for the greater of 10 minutes or the configured cycle time +30 seconds for the data to become synchronized.  If the current cycle has not completed in that time period, then the failover will fail and storage will not be changed. If at some point during the failover process the synchronization goes suspended, the failover will also fail. 

Also note that a FlashCopy of a Global Mirror with Change Volumes target or a detached copy could be up to two cycle periods behind, depending on when the FlashCopy or detach is done in relationship to the cycle time.  The calculation would be the same as that to calculate the maximum RPO.  Even if a vary off is done prior to the detach, to ensure an up to date detached copy, wait two cycle periods after the vary off before completing the detach.

The DSPSVCSSN command can be used to estimate switchover/failover time.  The command will print a DIAG message to the job log giving an approximation of the data out of sync.  Because of the data returned from the storage server, these estimates will tend to be more accurate for environments consisting of many small volumes, rather than a small number of large volumes.