MultiTarget PPRC with cascaded Metro/Global Mirror
This chapter describes how Multiple Target Peer-to-Peer Remote Copy (PPRC) simplifies the use of a cascaded Metro/Global Mirror environment and provides added flexibility. It includes the following topics:
44.1 Cascaded Metro/Global Mirror topology
Multiple Target PPRC provides several benefits and simplifications in a cascaded Metro/Global Mirror topology. Figure 44-1 shows a cascaded Metro/Global Mirror topology where there is Metro Mirror H1:H2 and Global Mirror H2:H3.
Figure 44-1 Cascaded Metro/Global Mirror configuration
Similar to Multiple Target PPRC with Metro Mirror and Global Mirror, this topology provides both a local high availability capability and a long-distance disaster recovery capability at the same time. Data is synchronously mirrored from H1 to H2 and asynchronously mirrored from H2:H3. Because H2:H3 is an asynchronous copy, H3 can be located in a different region at a long distance from the local primary site. In the event of a widespread disaster that affects both H1 and H2, production can be restarted at the H3 remote location.
The scenarios in this chapter describe outages at one of the sites. These can be either a failure condition or a planned event for testing or maintenance purposes.
To simplify the descriptions, these sites are often referred to as though they were a single volume, but it must be understood that the terms refer to the entire set of volumes being mirrored by PPRC. For example, “Failover H2:H1” means to fail over all of the H2 volumes to their corresponding H1 volumes.
44.2 Outage at H3
A failure or outage at the Global Mirror remote site H3 can cause the Global Copy pairs to suspend and the Global Mirror session to stop forming consistency groups. The Metro Mirror pairs H1 continue to run and provide protection in case of a failure at H1. When site H3 is recovered, Global Mirror H2:H3 can be resumed to restore the Global Mirror protection.
44.3 Outage at H2
A failure or outage at the secondary site H2 can cause the Metro Mirror pairs H1:H2 to suspend.
Global Mirror with Incremental Resynchronization from H1 to H3 can be used to start Global Mirror H1:H3 and continue to provide disaster recovery protection. See Chapter 36, “Metro/Global Mirror incremental resynchronization” on page 403 for the use of Metro/Global Mirror Incremental Resynchronization.
44.4 Outage at H1
Multiple Target PPRC can be used to simplify the recovery procedures in the case of a failure or outage at site H1 in a cascaded Metro/Global Mirror configuration.
After a failure at the local site H1, production can be moved to the H2 Metro Mirror secondary site. The following sections describe the steps that are taken in the case of a failure or planned outage at the local production H1 site, including the use of the Multiple Target PPRC capabilities.
44.4.1 Terms used in this example
For the examples in this section, the following terms are used:
•H1 is the current primary site where the production applications are running.
•H2 is the intermediate site which is a Metro Mirror secondary site from H1 and a Global Mirror primary to H3.
•H3 is the remote Global Mirror secondary site.
Table 44-1 identifies the DS8000 storage controllers used in the examples.
|
Note: The volume range on each DS8000 is different in these examples only to help clarify the different sites used. It is not a requirement that they be different.
|
Table 44-1 Identifications used in DS CLI examples
|
Site
|
Role
|
Dev
|
WWNN
|
Volume range
|
|
H1
|
Local primary
|
IBM.2107-75CZM21
|
5005076305FFD75A
|
5000-500F
|
|
H2
|
Intermediated cascaded site
|
IBM.2107-75CYM31
|
5005076305FFD71E
|
6000-600F
|
|
H3
|
Remote Global Mirror site
|
IBM.2107-75CYK71
|
5005076305FFD71A
|
7000-700F
|
44.4.2 Recover at H2
The first step in the process is to move production to H2 so that the host application I/O can continue. Either HyperSwap or a traditional restart can be used. After performing the freeze and unfreeze operations for H1:H2, a failover H2:H1 is performed to prepare the H2 site for receiving application host I/O.
Freeze H1:H2
Freeze commands for H1:H2 remove the PPRC paths and suspend all PPRC pairs for H1:H2. A separate freeze command is required for each LSS-to-LSS PPRC relationship. With the use of consistency groups, the freeze command creates consistent data at the H2 site by using extended long busy or queue full to temporarily queue dependent writes.
Depending on the type of failure at H1, the freeze commands might not complete successfully and some or all H1 pairs can remain full duplex. If the H1 site has completely failed, these commands might not have even been issued or executed.
Failover H2:H1 without Multiple Target PPRC
Without Multiple Target PPRC in a cascaded configuration, a failover H2:H1 cannot cause H2 to become a suspended primary to H1 because it is already a primary to H3, and a PPRC primary volume can be a source to only one secondary. In this case, H2 detects that it is a cascaded volume, and the processing is different than for a conventional failover in a noncascaded configuration. In a cascaded failover, the H2 volumes remain as secondaries of H1 and their secondary pair state is changed to target suspended. The H2 volumes remain as active primary volumes to H3. The states of the H2 volumes are changed to allow host I/O to be received.
Example 44-1 shows a failover H2:H1 without the -multtgt option. This prevents the failover command from creating a Multiple Target PPRC configuration. As this example shows, H2 is left as a target of H1.
Example 44-1 Failover H2:H2 without -multtgt
dscli> failoverpprc -dev IBM.2107-75CYM31 -remotedev IBM.2107-75CZM21 -type mmir 6000-600f:5000-500f
CMUC00196I failoverpprc: Remote Mirror and Copy pair IBM.2107-75CYM31/6000:IBM.2107-75CZM21/5000 successfully reversed.
...
dscli> lspprc -dev IBM.2107-75CYM31 6000-600f
ID State Reason Type SourceLSS
=========================================================================================================
IBM.2107-75CYM31/6000:IBM.2107-75CYK71/7000 Copy Pending - Global Copy IBM.2107-75CYM31/60 ...
...
IBM.2107-75CYM31/600F:IBM.2107-75CYK71/700F Copy Pending - Global Copy IBM.2107-75CYM31/60 ...
IBM.2107-75CZM21/5000:IBM.2107-75CYM31/6000 Target Suspended Host Target Metro Mirror IBM.2107-75CZM21/50 ...
...
IBM.2107-75CZM21/500F:IBM.2107-75CYM31/600F Target Suspended Host Target Metro Mirror IBM.2107-75CZM21/50 ...
Figure 44-2 shows the configuration state after a failover H2:H1.
Figure 44-2 Failover H2:H1 without Multiple Target PPRC
It is not possible to fail back H2:H1 without first suspending the H2:H3 pairs.
Failover H2:H1 using Multiple Target PPRC
Multiple Target PPRC target allows for a simpler handing of a PPRC failover in a cascaded configuration. With Multiple Target PPRC, a PPRC failover H2:H1 behaves in a similar manner to a failover in a noncascaded configuration and causes H2 to become a suspended primary to the H1 volumes.
In some circumstances, it is necessary for a failover in a cascaded configuration to behave in the same manner as without Multiple Target PPRC support. These are among the reasons for requiring this previous behavior:
•Not all of the DS8000 storage systems have Multiple Target PPRC support yet, so a Multiple Target PPRC configuration is not allowed.
•Not all host systems have been updated to have Multiple Target PPRC support.
•User processes and procedures are not yet updated and still expect the previous behavior.
A keyword on the PPRC failover command instructs the DS8000 storage system that creating a Multiple Target PPRC configuration is allowed. If this keyword is not specified, the previous cascaded failover behavior is used. If the keyword is included on the PPRC failover command, a Multiple Target PPRC configuration is created.
Example 44-2 on page 510 shows a sample DS CLI command to fail over to the intermediate H2 site by using the -multtgt option to allow the creation of a Multiple Target PPRC configuration.
Example 44-2 Failover H2:H1 with -multtgt
dscli> failoverpprc -dev IBM.2107-75CYM31 -remotedev IBM.2107-75CZM21 -type mmir -multtgt 6000-600f:5000-500f
CMUC00196I failoverpprc: Remote Mirror and Copy pair IBM.2107-75CYM31/6000:IBM.2107-75CZM21/5000 successfully reversed.
...
CMUC00196I failoverpprc: Remote Mirror and Copy pair IBM.2107-75CYM31/600F:IBM.2107-75CZM21/500F successfully reversed.
As Example 44-3 shows, the failover H2:H1 caused H2 to become a Multiple Target PPRC primary to both H1 and H3. Compare this to the results shown in Example 44-1 on page 508 when the -multtgt option was not used.
Example 44-3 Query after failover H2:H1 with -multtgt
dscli> lspprc -dev IBM.2107-75CYM31 6000-600f
ID State Reason Type SourceLSS
=====================================================================================================
IBM.2107-75CYM31/6000:IBM.2107-75CYK71/7000 Copy Pending - Global Copy IBM.2107-75CYM31/60 ...
IBM.2107-75CYM31/6000:IBM.2107-75CZM21/5000 Suspended Host Source Metro Mirror IBM.2107-75CYM31/60 ...
...
IBM.2107-75CYM31/600F:IBM.2107-75CYK71/700F Copy Pending - Global Copy IBM.2107-75CYM31/60 ...
IBM.2107-75CYM31/600F:IBM.2107-75CZM21/500F Suspended Host Source Metro Mirror IBM.2107-75CYM31/60 ...
The host applications can then run at the H2 site by using either HyperSwap or a traditional restart method.
The configuration at this point in the process is shown in Figure 44-3.
Figure 44-3 Multiple Target PPRC failover H2:H1
44.4.3 H1 recovered
This scenario is for the case where Multiple Target PPRC was used for the failover H2:H1 after the outage at H1.
When site H1 is recovered, mirroring can be resumed to H2 to create a Multiple Target PPRC Metro/Global Mirror configuration.
Establish paths H1:H2
The paths for H1:H2 were removed by the freeze commands. After H1 is recovered, these paths can be reestablished so that they are available when needed. The paths are not required until the time when mirroring is later resumed for H1:H2, but establishing them as soon as H1 is recovered helps to ensure that they are available when needed. The paths are reestablished using the same command that was used to originally create the paths.
Failback H2:H1
When the local H1 site is recovered, a failback H2:H1 resumes Metro Mirror from H2:H1 and copies all the data that was updated since the time of the failover to H2. Example 44-4 shows an example DS CLI command to fail back H2:H1.
Example 44-4 Failback H2:H1
dscli> failbackpprc -dev IBM.2107-75CYM31 -remotedev IBM.2107-75CZM21 -type mmir 6000-600f:5000-500f
CMUC00197I failbackpprc: Remote Mirror and Copy pair IBM.2107-75CYM31/6000:IBM.2107-75CZM21/5000 successfully failed back.
...
CMUC00197I failbackpprc: Remote Mirror and Copy pair IBM.2107-75CYM31/600F:IBM.2107-75CZM21/500F successfully failed back.
The cascaded Metro/Global Mirror configuration is now a Multiple Target PPRC Metro/Global Mirror configuration with Metro Mirror H2:H1 and Global Mirror H2:H3. Because H2 is now a Multiple Target PPRC primary, MTIR pairs are created between the secondary H1 and H3 sites. The resulting configuration is shown in Figure 44-4.
Figure 44-4 Failback H2:H1 creating Multiple Target PPRC Metro/Global Mirror configuration
44.4.4 Return production to H1
After the H1 site has been recovered, the original cascaded configuration of Metro Mirror H1:H2 and Global Mirror H2:H3 can be restored easily. The first step in the process is to move production back to H1. The process and commands are similar to those described for the two Metro Mirror case in 40.5, “Return production to H1” on page 463, which contains examples of the DS CLI commands.
As with the move to H2, either HyperSwap or a traditional restart can be used. The steps involved in this process is described in the sections that follow.
Freeze H2:H1
A freeze command for H2:H1 removes the PPRC paths for H2:H1 and suspends the PPRC H2:H1 pairs. A separate freeze command is required for each LSS-to-LSS PPRC relationship. With the use of consistency groups, this creates consistent data at the H1 site.
Unfreeze and run H2:H1
When all freeze commands have completed, the secondary H1 site contains a consistent copy of data. The unfreeze or run command (also known as a consistency group created command) removes the extended long busy or queue full condition at the primary H2 site. A separate unfreeze command is required for each LSS-to-LSS PPRC relationship.
Failover H1:H2
The failover command for H1:H2 coverts the H1 volumes to suspended Metro Mirror primary volumes whose secondary volumes are H2.
Resume host systems at H1
The host systems can now be restarted at H1. If HyperSwap is used, the host systems are switched to H1.
44.4.5 Start replication H1:H2
Because this is a planned swap, there is no need to wait for a secondary system to be recovered. The replication of H1:H2 can be immediately resumed.
Failback H1:H2
A failback command for H1:H2 resumes replication for the H1:H2 pairs.
Establish paths H2:H1
The paths from H2:H1 were removed by the freeze commands that were performed before the failover H2:H1. Reestablishing these paths as soon as possible helps to ensure that they are available when needed.
The configuration is now restored to the original configuration, as shown in Figure 44-1 on page 506.
44.5 Cascaded Metro/Global Mirror and Multiple Target PPRC Metro/Global Mirror
This scenario described in 44.1, “Cascaded Metro/Global Mirror topology” on page 506 started with a cascaded Metro/Global Mirror configuration, converted it to a Multiple Target PPRC Metro/Global Mirror configuration and then went back to the original cascaded configuration again. This demonstrates how cascaded and Multiple Target PPRC Metro/Global Mirror configurations complement each other.
In the course of operations, a configuration can change from a cascaded configuration to Multiple Target PPRC and back again. The ability to move between cascaded and Multiple Target Metro/Global Mirror configurations as needed gives additional flexibility and options to manage different requirements and circumstances.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.