Remote Pair FlashCopy
This chapter covers the following topics:
9.1 FlashCopy in combination with other Copy Services
FlashCopy can be used in various combinations with other Copy Services functions, and the most suitable option depends on the characteristics of the environment and the requirements.
9.1.1 Terminology
The following terms describe the configuration details and terms used in this chapter:
Local A The device at the local site that is the source of the FlashCopy relationship that is being requested.
Local B The device at the local site that is the intended target of the FlashCopy relationship that is being requested. Local A and Local B can be the same device for a data set level operation.
Remote A When Local A is a Metro Mirror primary device, Remote A is the Metro Mirror secondary associated with Local A.
Remote B When Local B is a Metro Mirror primary device, Remote B is the Metro Mirror secondary associated with Local B. Remote A and Remote B can be the same device for a data set level operation.
Mirrored FlashCopy relationship or Mirrored relationship
This is a FlashCopy relationship that is established as a Remote Pair FlashCopy operation.
This is a FlashCopy relationship that is established as a Remote Pair FlashCopy operation.
Preserve Mirror The interface terminology that is used to describe the hardware Remote Pair FlashCopy function.
Local Relationship The FlashCopy relationship that is established between Local A and Local B as part of a Remote Pair FlashCopy operation.
Remote Relationship The FlashCopy relationship that is established between Remote A and Remote B as part of a Remote Pair FlashCopy operation.
|
Terminology: The terms Remote Pair FlashCopy and Preserve Mirror are used interchangeably in this chapter.
|
9.1.2 FlashCopy with Metro Mirror and Global Copy
A FlashCopy target volume can also be a primary volume for a Metro Mirror or Global Copy relationship. This capability creates a Local and a Remote Copy production data. Figure 9-1 on page 61 illustrates the FlashCopy target and the Metro Mirror (or Global Copy) primary are the same volume. They are displayed as two separate volumes for ease of understanding.
Figure 9-1 FlashCopy target is Metro Mirror (or Global Copy) primary
Options are provided on FlashCopy Establish to allow a FlashCopy to a Metro Mirror or Global Copy primary device. The option that you use in your installation depends on the task that you want to accomplish and the type of remote mirroring that you are using.
As illustrated in Figure 9-2, this can be expanded to show not just FlashCopy capability but also Remote Pair FlashCopy (Preserve Mirror) capability and the combinations supported:
•A FlashCopy source volume can become a Metro Mirror primary volume and vice versa. The order of creation is optional.
•A FlashCopy target volume can become a Metro Mirror primary volume and vice versa.
•On the remote site of the Metro Mirror, a FlashCopy source volume can be the Metro Mirror secondary volume and vice versa. There are no restrictions on which relationship should be defined first.
Figure 9-2 Remote Pair FlashCopy and Metro Mirror
FlashCopy to Metro Mirror and Global Copy without Preserve Mirror
Figure 9-3 displays the following sequence of events that occur during a FlashCopy to a Metro Mirror (or Global Copy) primary device:
•Step 1: Note that two Metro Mirror pairs are full duplex and that there is data that resides on Local A and Remote A (because they are identical). You want to FlashCopy that data set from Local A to Local B.
•Step 2: The FlashCopy Establish command is issued to copy the data to Local B, including keywords that allow the target to be a Metro Mirror or Global Copy primary device but without preserve mirror keywords.
•Step 3: The Local B - Remote B pair transitions to duplex pending state, while the data is transmitted over the Peer-to-Peer Remote Copy (PPRC) links to Remote B.
•Step 4: The copy to Remote B completes and Local B - Remote B pair transitions back to Full Duplex state.
Figure 9-3 The system as vulnerable during the COPY PENDING state
The issue with this approach is when the user initiates a FlashCopy onto a Metro Mirror primary volume that is in a FULL DUPLEX mode, the pair transitions to DUPLEX PENDING state while the data is transferred to the target secondary at the remote site. After the FlashCopy data transfer is complete, the Metro Mirror pair will return FULL DUPLEX. However, while any pairs are in the DUPLEX PENDING state, the primary system is vulnerable to disaster (and HyperSwap is no longer enabled, if applicable) because there is no consistent recovery protection until pair returns to the FULL DUPLEX state.
The advantage with this approach is that the source and target status is inconsequential (DUPLEX, SUSPENDED, PENDING, even SIMPLEX), with the exception of Global Mirror and z/OS Global Mirror, which are not compatible with FlashCopy.
|
Note: The movement of the FlashCopy data to the target secondary is independent from the FlashCopy background copy at the local site. Instead, when the FlashCopy Establish occurs, the target bitmap is updated to contain the tracks or block that need to be copied to the remote site. Then, the target pair will ‘read’ the data from the appropriate volume (source or target, depending on if the data has been copied to the target via the FlashCopy background copy or not). That process is autonomous from the FlashCopy background copy. This means that the FlashCopy relationship may still exist at the local site even after the target pair has transitioned back to FULL DUPLEX.
|
For those using Metro Mirror, especially with HyperSwap, the Remote Pair FlashCopy function (9.2, “Remote Pair FlashCopy” on page 64) is a more appropriate solution.
9.1.3 FlashCopy and Global Mirror
FlashCopy in combination with Global Mirror supports only one type of relationship at the primary site (Figure 9-4).
A FlashCopy source volume can become a Global Mirror primary volume and vice versa. The relationships can be established in any sequence. A Global Mirror primary volume cannot become a FlashCopy target volume. However, a FlashCopy target volume can become a Global Mirror primary volume. (In this case, the order in which the establishes are done makes a difference).
Figure 9-4 FlashCopy and Global Mirror
On the Global Mirror secondary site, the Global Mirror secondary volume can be used as a FlashCopy source but not as a target. When used as a source one needs to be aware that steps should be taken to ensure the Global Mirror secondary volumes are consistent before performing Flashcopy (such as using the Global Mirror pause with consistency function). Otherwise, the FlashCopy target volumes might not be consistent.
9.2 Remote Pair FlashCopy
Remote Pair FlashCopy allows a Metro Mirror pair that is a FlashCopy target to remain FULL DUPLEX, and it also reduces the overhead of transferring all of the data to be copied via the PPRC links. With Remote Pair FlashCopy, only the FlashCopy command itself is sent from the local site to the secondary at the remote site, and the FlashCopy is performed, independently but consistently at both the local and remote sites. Preserving the FULL DUPLEX state of the mirror ensures that there is no loss of disaster recovery protection.
The following conditions are required to establish Remote Pair FlashCopy:
•Both the Local A / Remote A and the Local B / Remote B Metro Mirror pairs are in the FULL DUPLEX state.
•Local B / Remote B pair is SIMPLEX, SUSPENDED, or PENDING, Local A / Remote A pair can be in any state (SIMPLEX, PENDING, or SUSPENDED.
•The Remote A and Remote B volumes are in the same DS8000 Storage Facility Image (SFI).
•The required microcode level must be installed on both the local and remote storage systems.
Figure 9-5 on page 65 illustrates the following sequence of events that occur during a FlashCopy with Preserve Mirror Required (Remote Pair FlashCopy) to a Metro Mirror (or Global Copy) primary device:
•Step 1: Notice that two Metro Mirror pairs are full duplex and that there is data that resides on Local A and Remote A (because they are identical). You want to FlashCopy that data from Local A to Local B. This is the same starting point you have for non-Preserve Mirror FlashCopy invocations, but you won’t have the state transitions.
•Step 2: The FlashCopy Establish command is issued to copy the data to Local B, including keywords that allow the target to be a Metro Mirror or Global Copy primary device and with the preserve mirror required keywords.
•Step 3: The FlashCopy command is sent from Local A to Remote A. Independent of each other, the local storage system and the remote storage system then run the FlashCopy operation. The local storage system coordinates the FlashCopy activities and if the FlashCopy does not succeed at the remote site, the local storage system will suspend the target pair.
|
Note: This status is reflected in PPRC query command output as a specific suspend reason (suspended due to FlashCopy failure). Remote Pair FlashCopy supports both full volume and data set FlashCopy.
|
•Step 4: The FlashCopy is applied to Local A / Local B, and it is applied to Remote A / Remote B. The target pair remains full duplex the entire time.
|
Note: Remote Pair FlashCopy will not impact HyperSwap ennoblement status for the configuration because the mirror is not impacted (unless an unforeseen error occurs) and FlashCopy operations can be freely used within the storage system configuration with confidence that your data is protected.
|
Figure 9-5 Remote Pair FlashCopy preserves Metro Mirror FULL DUPLEX state
9.2.1 Features of Remote Pair FlashCopy
Remote Pair FlashCopy provides the following features:
•Remote Pair FlashCopy operations are supported on both count key data (CKD) and fixed block architecture (FB) volumes.
•Remote Pair FlashCopy maintains Metro Mirror Full Duplex to preserve HyperSwap enabled state and for disaster recovery scenarios.
•No additional link bandwidth is needed because only the FlashCopy commands are sent to the remote site, not the data to be copied.
•Remote Pair FlashCopy can be used in combination with the following features:
– Incremental FlashCopy (if the initial established FlashCopy used Remote Pair FlashCopy)
– FlashCopy options: copy, nocopy, or nocopy-to-copy
– FlashCopy consistency groups
– Data set level FlashCopy in z/OS
9.2.2 Considerations
The following options are not supported by Remote Pair FlashCopy:
•Certain FlashCopy options are not supported by Remote Pair FlashCopy:
– Commit is not supported.
– Revert is not supported.
– Fast Reverse Restore is not supported.
•Remote Pair FlashCopy onto a Global Mirror primary is not supported.
•Remote Pair FlashCopy onto a Global Copy primary is not supported.
•Remote Pair FlashCopy with cascading configurations has the following limitations:
– Metro/Global Copy
Remote Pair FlashCopy can be used by this configuration if the configuration requirements for the devices that are involved in the Metro Mirror relationships are met. The FlashCopy command is run from Local A to Local B, and an inband FlashCopy command is run to do the FlashCopy copy from Remote A to Remote B. The tracks or blocks in the relationship are copied from Remote B to its corresponding PPRC secondary device through the Global Copy resync mechanism.
– Metro/Global Mirror
Because the ability to perform a FlashCopy to a primary device that is participating in a Global Mirror session is not allowed, any attempt to perform a Remote Pair FlashCopy (Preserve Mirror) Required operation fails because the inband FlashCopy operation attempts to perform a FlashCopy from Remote A to Remote B, and Remote B is the Global Mirror primary, which is not supported.
In this case, you cannot use Preserve Mirror unless you remove the Global Mirror pairs, that are to become FlashCopy targets, from the Global Mirror session before invoking the FlashCopy Establish commands.
Alternatively, FlashCopy to a PPRC primary without Preserve Mirror can be used at the local site between the Metro Mirror primaries, resulting in the target Metro Mirror pair going duplex pending rather than attempting an in-band FlashCopy Establish to the Global Mirror primary.
Existing Copy Services restrictions still apply. (A remote target cannot be a source, and so forth).
Remote Pair FlashCopy with Multiple Target PPRC
There are additional considerations to account for when using Remote Pair FlashCopy in a Multiple Target PPRC environment.
In a Multiple Target PPRC configuration with two Metro Mirror pairs, the Remote Pair FlashCopy operation may be performed for only one of the Metro Mirror pairs. The chpprc command is used to specify which of the Metro Mirror pairs is used for the Remote Pair FlashCopy command. The other Metro Mirror pair reverts to the duplex pending state and performs a physical copy of the data. For a detailed description of Multiple Target PPRC and the use of Remote Pair FlashCopy, see 9.7, “FlashCopy considerations for Metro/Global Mirror and Multiple Target PPRC” on page 71 or IBM DS8870 Multiple Target Peer-to-Peer Remote Copy, REDP-5151.
9.3 Remote Pair FlashCopy implementation and usage
Before Remote Pair FlashCopy can be established, the Metro Mirror relationship between the Local A and Remote A pair and the Metro Mirror relationship between Local B and Remote B pair must be established and in Full Duplex. For more information about how to create Metro Mirror relationships, see Chapter 13, “Metro Mirror overview” on page 103.
|
Keyword: The FlashCopy to a Metro Mirror or Global Copy Primary OK keyword must be specified when the Remote Pair FlashCopy required options are used. The keyword differs depending on the interface that is used to establish FlashCopy.
|
If the Remote Pair FlashCopy establish command completes successfully at the local site but fails to mirror the command at the remote site, the Metro Mirror pair is no longer considered duplex. This results in the suspension of the Local B / Remote B Metro Mirror pair.
Table 9-1 summarizes the behavior of Remote Pair FlashCopy for different combinations of the Local and Remote Mirror pair states.
Table 9-1 Remote Pair FlashCopy behavior
|
Source
|
Target
|
Situation
|
PM Required
|
No PM
|
|
Duplex
|
Duplex
|
Normal
|
Remote Pair FlashCopy is performed.
|
Target device duplex pending.
|
|
Duplex
|
Duplex
|
Problem with Remote FlashCopy detected early
|
FlashCopy failed.
|
Target device duplex pending.
|
|
Duplex
|
Duplex
|
Problem with remote FlashCopy detected late
|
Target device suspended.
|
Target device duplex pending.
|
|
Suspended
|
Suspended
|
Any
|
Perform a local FlashCopy and set the Metro Mirror OOS bitmap.
|
Set the target device OOS bitmap.
|
|
Pending
|
Pending
|
Any
|
Perform a local FlashCopy and set the Metro Mirror OOS bitmap.
|
Set the target device OOS bitmap.
|
|
Duplex
|
Suspended / Pending
|
Any
|
Perform a local FlashCopy and set the Metro Mirror OOS bitmap
|
Set the target device OOS bitmap.
|
|
Suspended / Pending
|
Duplex
|
Any
|
FlashCopy fails.
|
Target device duplex pending.
|
|
Any
|
Simplex
|
Any
|
FlashCopy issued locally.
|
FlashCopy issued locally.
|
|
Simplex
|
Duplex
|
Any
|
FlashCopy failed.
|
Target device duplex pending.
|
|
Simplex
|
Suspended / Pending
|
Any
|
Perform a local FlashCopy and set the Metro Mirror OOS bitmap.
|
Set the target device OOS bitmap.
|
|
Resynchronizing: If Remote Pair FlashCopy is used in combination with Incremental FlashCopy, the FlashCopy relationship must be created after the Metro Mirror relationship, or subsequent increment restores will fail. This is because if the relationship is established without Remote Pair FlashCopy, there will not be a corresponding relationship at the remote. A restore issued with Remote Pair FlashCopy Required will fail when it attempts to mirror that restore to a relationship that does not exist at the remote location and will suspend the target Metro Mirror pair.
|
9.4 Remote Pair FlashCopy withdrawal
When a Remote Pair FlashCopy operation begins, there is no guarantee that the local and remote DS8000s perform the background copy for their respective relationships at the same pace. Therefore, a withdrawal of the FlashCopy relationship, which might be issued by the host, introduces a situation where Local B and Remote B are not identical, even though the Metro Mirror pair is in the Full Duplex state.
There are two methods to withdraw Remote Pair FlashCopy relationships. The relationships can be withdrawn after a background copy completes that maintains the Metro Mirror Full Duplex state, or the relationships can be forced to withdraw immediately, which also maintains Metro Mirror Full Duplex state, but it sets an indicator in the Metro Mirror target relationship that they are logically identical if not physically identical.
9.4.1 Withdraw with Background Copy
To ensure identical Local B and Remote B data, the local and remote relationships should be terminated only after all source data is copied (destaged) to the target volumes. This task can be achieved by performing a FlashCopy Withdraw with Background Copy operation on both local and remote relationships. After the background copy completes, the Metro Mirror primary and secondary volumes are physically identical.
The following rules apply to Withdraw with Background Copy:
•FlashCopy Withdraw of a mirrored relationship that is established with Remote Pair FlashCopy Required, without the force indicator, issued to either Local A or Local B, results in a background copy being initiated for both the local and the remote relationships. If the relationship is persistent, the relationship is withdrawn after the background copy completes.
•A start background copy that is issued to Local A starts a background copy for both the local and the remote relationships.
•A start background copy that is issued to Remote A starts a background copy for the remote relationship only.
•FlashCopy Withdraw without start Background Copy or Terminate All (also known as the Deleted Data Space Withdraw (DDSW) option - z/OS only) issued to Remote A is rejected if the background copy is not complete.
•FlashCopy Withdraw with Terminate All issued to Remote B is rejected if the background copy is not complete.
•FlashCopy Withdraw with Terminate All, issued to the remote FlashCopy source (Remote A), starts a background copy for the remote relationship only.
|
Mirrored relationships: If FlashCopy relationship is established as a mirrored relationship, and the Local B to Remote B Metro Mirror relationship is deleted before a FlashCopy Withdraw request, then the relationship is no longer treated as a mirrored relation, so normal withdraw processing applies.
|
9.4.2 Forcing FlashCopy Withdraw
Withdraw with Background Copy might not be suitable for all situations. For example, if another FlashCopy Establish is issued before the previously established relationships finish the background copy, the new FlashCopy operation fails. This could happen if you are doing many FlashCopy operations to take a backup before running batch, for instance, but before the job completes, one of the FlashCopy establish commands fails. In order to restart the job, you need to withdraw all relationships that were successful and then re-establish. In this case, there is no purpose in waiting for background copy to complete so that the same copies can be taken again. The delay could impact batch window processing and it is a lot of unnecessary overhead to copy the volumes more than one time to get a consistent copy.
In that scenario, a force option can be used on the FlashCopy Withdraw that causes a mirrored relationship to be withdrawn immediately at both the local and the remote sites without initiating background copy first.
When the force option is used, an indicator is set for the target Metro Mirror pair, stating that there might be tracks that are not physically identical even though the pair is Full Duplex and logically identical. The data on those tracks is not considered valid by the host, so the Metro Mirror pair is still considered Full Duplex.
9.4.3 Withdrawing on the Metro Mirror secondary
Normally, removing the FlashCopy relationship on the Metro Mirror Primary volumes automatically removes the remote FlashCopy relationship on the secondary Metro Mirror volume. If there are communications problems, the remote FlashCopy relationship on the secondary Metro Mirror volumes cannot be removed.
In this case, it will be necessary to withdraw the remote relationship manually to prevent errors when attempting to mirror a new relationship from the local when a relationship already exists on the remote. This can be done via inband (if the PPRC links are in tact and the pair is not suspended), or by issuing the command directly to the remote device, if the host system has access to the remote devices.
9.4.4 FlashCopy Withdraw interface differences
The default handling behavior for FlashCopy Withdraw is different depending on the interface that is used:
•ICKDSF:
– The default initiates Background Copy on withdraw.
– The FORCE keyword exists and is optional.
•TSO / DFSMSdss / ANTRQST:
Force is the default with no other option.
•DS CLI:
– There is no force option.
– The default behavior fails the withdraw.
– It requires the -cprm option to initiate Background Copy.
9.5 Remote Pair FlashCopy impact on Metro Mirror state
Remote Pair FlashCopy operations can impact the state of the Metro Mirror pair:
•If a force withdraw is issued against a Remote Pair FlashCopy pair, the Metro Mirror pair still shows as Full Duplex, but there is also an indication that the pair was the target of a Remote Pair FlashCopy Withdraw.
•If a Remote Pair FlashCopy Establish Required fails at the remote system, the Metro Mirror pair suspends. The Metro Mirror query indicates that the reason for the suspension is Remote Pair FlashCopy.
9.6 Using Remote Pair FlashCopy in a z/OS environment
In a z/OS environment, specifically for SMS managed volumes or data sets, there is a process called volume selection when looking for space to allocate a data set to copy into or to select volumes that are eligible to become Flashcopy targets for full volume operations.
9.6.1 Remote Pair FlashCopy and SMS volume selection
When doing volume selection, it is known, if the copy is going to be logical (FlashCopy) or physical (standard I/O). It is also known, if FlashCopy will be used and which type of FlashCopy operation it will be. These values are taken into consideration so that the correct volume and/or tracks are chosen.
DFSMS takes several things into consideration, two of them are key:
•Is FAST REPLICATION (use of FlashCopy) required or preferred?
•Is Remote Pair FlashCopy required?
The following situations are handled in the following ways:
•If the volume is not FlashCopy eligible or capable and if FAST REPLICATION was REQUIRED, this volume is rejected.
•If the volume is FlashCopy capable:
– PRESERVE MIRROR is either not specified or specified as NO.
• If the potential target is not a PPRC primary, the volume is eligible for volume selection and is ranked higher than a similar non-FR capable volumes.
• If the potential target is a PPRC primary and FlashCopy to PPRC OK is specified, the volume is eligible for volume selection and is ranked higher than a similar non-FR capable volumes.
• If the potential target is a PPRC primary and FlashCopy to PPRC OK is not specified, the volume is rejected.
– PRESERVE MIRROR is specified as REQUIRED. This volume is considered eligible for volume selection if any one of the following conditions is met:
• The volume is PRESERVE MIRROR capable.
• The volume is NOT PRESERVE MIRROR capable because it is not a PPRC volume. But this means there is no mirror to impact.
9.7 FlashCopy considerations for Metro/Global Mirror and Multiple Target PPRC
In a multigrade PPRC environment with Metro Mirror on one leg and Global Mirror on the other leg, FlashCopy target volumes cannot be part of a Global Mirror Session. Many customers want to mirror all data or volumes, even the FlashCopy target volumes. However, FlashCopy cannot be used if a target volume is part of a Global Mirror session.
The FlashCopy target volume can be mirrored with Global Copy, but it cannot be part of a consistency group that a Global Mirror session represents, because consistency group formation would have to wait until the FlashCopy background copy process has finished, which would significantly impact your RPO. Refer to Figure 9-6 on page 72.
Figure 9-6 FlashCopy in a Metro Mirror / Global Mirror multigrade environment
You can identify and isolate a range of volumes that will act as FlashCopy target volumes. You can replicate this range of volumes with Global Copy, but they cannot be part of the Global Mirror session. DFSMS volume selection will honor policies set up to isolate these volumes and select appropriate FlashCopy target volumes accordingly.
9.7.1 Remote Pair FlashCopy with Multiple Target PPRC
With Multiple Target PPRC, the Local source and target volumes can now have two Metro Mirror relationships on them, as shown in Figure 9-7 on page 73. A Remote Pair FlashCopy command can be performed for only one of the Metro Mirror pairs. The other pair will transition back to duplex pending and mirror the copied data to the remote volume.
Figure 9-7 Remote Pair FlashCopy with Multiple Target PPRC
In a configuration with two Metro Mirror pairs, the user must identify which of the pairs to use for the Remote Pair FlashCopy operation. The Set PPRC Characteristics command is used to set or reset Use Remote Pair FlashCopy for a Metro Mirror pair to indicate whether Remote Pair FlashCopy is to be used for that pair. In the case of a failure or suspension of the pair that is enabled for Remote Pair FlashCopy, the Use Remote Pair FlashCopy command can be used to enable the function on the surviving Metro Mirror pairs. The interfaces for the set PPRC Characteristics command are:
•DS CLI chpprc
•TSO PSETCHAR
•ANTRQST PSETCHAR
•ANTTREXX PSETCHAR
•ICKDSF PPRCOPY SETCHARACTERISTICS
When a Remote Pair FlashCopy command is issued to a Multiple Target PPRC primary volume and the conditions allow such an operation, the Metro Mirror pair that is enabled for Remote Pair FlashCopy will mirror the FlashCopy command, and the other pair will transition back to duplex pending and copy the data to the remote site using Metro Mirror.
If neither pair or if both pairs are enabled for Remote Pair FlashCopy and a Remote Pair FlashCopy command is received, the command will be rejected because the storage system cannot determine which of the Metro Mirror pairs to use for the command. (Fails due to ambiguous configuration).
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.