Different Global Mirror topologies can be considered when planning for Global Mirror implementation.This chapter describes a number of scenarios that can be used for setting up a Global Mirror configuration based on disaster recovery requirements.

The examples in this chapter use the following symbols:

This chapter includes the following sections:

With an asymmetrical configuration, Global Mirror can only be used from the primary site to the disaster recovery (DR) site. This type of configuration would be typical for a disaster recovery configuration where the production systems would run in the secondary location only during an unplanned outage of the primary location. As shown in Figure 6-1, each primary H1 volume is in a replication relationship with its associated H2 host volume and a corresponding J2 journal volume for creating consistency groups.

Because Global Mirror uses two copies of data in the secondary (DR) location, there are twice as many physical drives in this location as in the production location if the same size drives are used.

After production workloads are moved to the recovery site, Global Copy must be used to return back to the primary site (see Figure 6-2). No disaster recovery capability is provided in the reverse direction. Therefore, it is unlikely that this type of configuration production would run for extended periods of time at the secondary location, unless forced to by unavailability of the primary site.

Monitor the Global Copy status by using Copy Services Manager (CSM) or any command interface to determine how many tracks are out of sync between H2 and H1 volumes. After these out-of-sync numbers are static, you can stop I/O at the secondary DR site (shut down all systems) and wait until the out of sync is zero. You can then fail back to the H1 volumes at the primary site, start your systems off H1 volumes, and resume the Global Mirror session again from H1 to H2 volumes.

With a symmetrical configuration, additional disk capacity is also required for journal FlashCopy volumes at the primary site. Therefore, both primary and secondary disk systems have identical configurations, as shown in Figure 6-3 on page 60. The additional capacity at the primary site can also be used for regular FlashCopy operations. For example, the capacity can be used for backing up the data to disk and then dump to tape without extended outages for the production systems.

With FlashCopy capacity at both sites, it is possible to provide a disaster recovery solution using Global Mirror in both directions between the two sites. This type of configuration would typically be used where production workloads might run for extended periods of time in either location. In Figure 6-4, the Global Mirror session direction is from H2 to H1 volumes and the consistency groups are formed on journal J1 volume set.

Different multi-site DS8000 copy services topology options are available when it comes to three or four site configurations. Multiple Target Peer-to-Peer Remote Copy (MT PPRC) is one of them. It allows you to have a single primary volume in a continuous copy services relationship with two target volumes. MT PPRC enhances capability and flexibility for disaster recovery and migration solutions by using synchronous, asynchronous, or a combination of both synchronous and asynchronous replications.

This section provides only a high-level description for Global Mirror option in combination with Metro Mirror. More details about MT PPRC can be found in IBM DS8870 Multiple Target Peer-to-Peer Remote Copy, REDP-5151.

The existing customers with two data centers within metropolitan distance (usually up to 100 km) might consider enhancing their DR topology with a remote third site. This site is usually located out of the region and beyond the supported distance for synchronous replication.

With MT PPRC configuration, data is synchronously mirrored to one secondary site and is asynchronously mirrored to a separate remote disaster recovery site (see Figure 6-5). When the primary DS8000 with H1 volumes detects that an MT PPRC configuration exists, it creates Multiple Target Incremental Resynchronization (MTIR) pairs between H2 and H3. The MTIR pairs serve two main purposes:

During any planned or unplanned outage for H2 site, Global Mirror from H1 to H3 site still provides disaster recovery protection.

When H3 site encounters an unplanned or planned outage, the Global Copy relationship between H1 and H3 is suspended and Global Mirror stops forming consistency groups. The Metro Mirror replication continues to run and provides protection during H1 site failure.

During an H1 site outage, the production workload can fail over to the H2 site and continue replication between H2 and H3 site, thus maintaining DR capability.

Metro Global Mirror provides a 3-site or 3-copy solution using both synchronous and asynchronous replication. This topology can provide a local synchronous copy of data either to another site within synchronous distance or within the same campus or data center.

Additionally, Global Mirror is used to continually mirror data from the Metro Mirror secondary devices, providing an out-of-region copy. As shown in Figure 6-6, H2 volumes are defined as secondary Metro Mirror volumes. These volumes are in a cascaded Global Mirror relationship with primary Global Mirror volumes that asynchronously replicate data to H3 volumes at the remote site. In this example, the Global Mirror session between H2 and H3 site volumes is asymmetrical. However, based on client’s requirements, both symmetrical and asymmetrical Global Mirror configurations are supported.

During a H1 site outage, production workload is failed over to the intermediate H2 site and the Global Mirror session between H2 and H3 continues to provide disaster recovery protection.

Although the links between H1 and H3 are optional, the preferred practice is to always configure them. The advantage of having these links is beneficial when the intermediate H2 site fails. The MGM Incremental Resync function offers the capability to establish the Global Mirror relationship between the local H1 and remote H3 sites without needing to replicate all the data again. The MGM topology with Incremental Resync provides a more flexible and efficient disaster recovery protection.

When H3 site is not available, the H1 to H2 Metro Mirror configuration is not affected.

Customers with three or four data centers within and out of the region might consider a combination of Metro Global Mirror with Multiple Target PPRC (MT PPRC) as shown in Figure 6-7. Metro Global Mirror configuration between H1, H2, and H3 systems can be extended by adding a Metro Mirror session between H1 and H3 with MT PPRC. This MT PPRC configuration provides high availability and disaster recovery protection within metropolitan distances, while MGM extends data protection during metropolitan and regional disasters.

During a failure at site H1, the production applications can be moved to run at H3, and the Incremental Resynchronization capabilities of Multiple Target PPRC (MTIR) can be used to establish an active Metro Mirror relationship (H3 to H2). This situation results in an MGM configuration where there is Metro Mirror H3 to H2 and Global Mirror H2 to H4.

Even after a failure of the primary production site, there is still the full protection of an MGM environment where Metro Mirror H3:H2 provides a high availability capability and the Global Mirror H2 to H4 provides for long-distance disaster recovery.

In case the H2 site is not operational, there is an option to cascade H3 to H4 by forming a new MGM configuration.

This section describes the migration topology and process that is involved when replacing the old DS8870 systems in a Global Mirror session with the newer DS8880 disk models, as illustrated in Figure 6-8.

For the examples in this section, the following terms are used:

The proposed migration example to migrate data from a primary or secondary DS8870 storage system in Global Mirror session is MT PPRC. The use of MT PPRC allows for migration procedures with either few or no periods of time when the system is not protected by mirroring.

For more information about DS8870 migration, see DS8870 Data Migration Techniques, SG24-8257.

The general method of this migration is to use the MT PPRC capability to start Global Copy from the existing H1 primary site to the new H2’ secondary site (Figure 6-9). Global Copy is asynchronous data replication, which does not use journal volumes to create consistency groups. Therefore, it is mainly used for data migration. However, the new DS8880 at the secondary site requires provisioned space for journal volumes that are used in the final migration step.

After all of the volume pairs H1 to H2’ have passed the first round of copy (they never reach full sync/duplex state, but the out of sync data amount is minimal), the migration can start as follows (see Figure 6-10):

The RPO increases during the conversion of H1 to H2’ Global Copy into Global Mirror. The new consistency group will be created after the new Global Mirror session between H1 and H2’ is started.

Similarly to replacing secondary DS8870 in a Global Mirror session, MT PPRC can be used to replace the primary Global Mirror DS8870 system. Because the new target DS8880 H1’ volumes are in the local, primary site, the H1’ volumes can be defined in a synchronous Metro Mirror session between H1 and H1’. As you can see in Figure 6-11 on page 67, the secondary DS8880 is already replaced (as described in “Replacement of Global Mirror secondary DS8870 system” on page 65) and the Global Mirror session is active between old H1 and new H2’ volumes.

With z/OS and AIX, you can start the H1 to H1’ Metro Mirror session with IBM HyperSwap® enabled. HyperSwap can transparently swap the production workload from H1 to H1’ volumes, thus avoiding the applications and systems outage.

After the H1 and H1’ volumes are fully synchronized and in Duplex state, you can invoke HyperSwap if it is enabled, or alternatively perform a failover to the H1’ volumes, by shutting down the workload to H1 volumes and starting it from H1’ volumes. Thanks to the Multiple Target Incremental Resynchronization capability between the new H1’ and H2’ volumes, the new Global Mirror relationship is quickly started and the new consistency group created.

At this stage, you can terminate all relationships on H1 volumes and remove the old DS8870. The migration to H1’ is now complete, as shown in Figure 6-12.