Cascading FlashCopy
This chapter covers the concepts related to the IBM DS8000 Cascading FlashCopy.
This chapter includes the following topics:
9.1 Introduction
In today’s modern, complex application environments, the need to have multiple copies of data for the purpose of backup, testing, development, data mining, and disaster recovery is essential. From that standpoint, The DS8000 series offers an extensive and comprehensive set of Copy Services that helps fulfill those business needs.
9.1.1 Flashcopy
Before diving into the specifics of the Cascading FlashCopy function, we review the basics of the FlashCopy function and its different options. Understanding those options is critical for a proper usage of the Cascading FlashCopy capability. As one of the basic DS8000 Copy Services, FlashCopy enables the creation of a point in time copy of a volume, or a data set (a subset of a volume in a z/OS environment).
When describing FlashCopy, the following terms are used:
•Source refers to the original data that is to be copied.
•Target refers to the destination where the data is to be copied.
•FlashCopy relationship refers to the relationship being created between the specified source volume or tracks and the specified target volume or tracks.
•Point-in-time copy describes the result of a FlashCopy establish operation. The target of the establish contains a copy of the source as of the point in time that the establish was performed.
•Time-zero (T0) copy refers to the first point in time that a copy is taken. A subsequent version would be T1, then T2, and so on.
•Background copy refers to the physical copy operation that is performed by the DS8000 in the background, asynchronously after a FlashCopy has been established.
With FlashCopy, when the FlashCopy command completes, both the source and target copies are immediately available for read and write operations. FlashCopy is also known as a point-in-time copy, fast replication, or time-zero copy (T0 copy).
9.1.2 FlashCopy prior to the cascading capability
Before the Cascading FlashCopy capability, you were allowed to have one FlashCopy source and up to 12 FlashCopy target volume or dataset relationships. This allowed you to have multiple PiT(T0) relationships and therefore multiple copies of the source volume or dataset, created at different times against the same source., T1, T2...T11.
However, to restore one of the targets back to the source, you had to withdraw the other relationships that shared the same source.
Users could make multiple copies and then restore only one of these copies. However, they had to remove any existing relationships from the original source prior to reversing one relationship. If the wrong PiT is chosen, and the background copy has not completed, other PiT backups are no longer available.
Any volume can be the source of up to 12 FlashCopy relationships.
9.2 Cascading FlashCopy concept and design
Before DS8880 Release 8.3, a volume could not be both the source and a target in a FlashCopy relationship at the same time. The same restriction applied to data sets in the case of data set-level FlashCopy.
Release 8.3 lifts this restriction and allows a volume or track to be both a source in one FlashCopy relationship and target in a second FlashCopy relationship. This is referred to as a Cascading FlashCopy relationship, as illustrated in Figure 9-1.
There is no architectural limit to the number of FlashCopy cascades other than the total number of volumes within a DS8880. However, the maximum number of FlashCopy relationships is still limited to 12.
A volume or dataset can perform one of the following functions:
•Source in up to 12 FlashCopy relationships
OR
•Target in 1 FlashCopy relationship AND a source in up to 11 FlashCopy relationships.
Figure 9-1 Cascading Flashcopy concept
9.2.1 Typical use cases
Typical use cases and applications for cascading FlashCopy include:
•Reversing one of several FlashCopy relationships from a source device to restore this copy without first removing the other relationships.
•Recovering a Global Mirrored environment without needing to withdraw an existing FlashCopy used for Disaster Recovery testing.
•Using a dataset FlashCopy between devices that are both the sources of other FlashCopy relationships including in Remote Pair FlashCopy environments.
•Performing an object-level restore using FlashCopy from an IBM DB2 System Backup that still has an active FlashCopy relationship.
•Increasing the flexibility of dataset FlashCopy where an existing source data set can become a target of a new FlashCopy and an existing track can become a source of a new FlashCopy.
•Recovering from Ransomware or other malicious event.
9.2.2 Terminology
Several new terms are being introduced to distinguish between different types of Cascading FlashCopy topologies.
Forward cascade
A forward cascading relationship is created when the target volume in an existing FlashCopy relationship becomes the source volume in a new FlashCopy relationship.
In Figure 9-2, a FlashCopy relationship was established at Time 0 from Volume A to Volume B. A forward cascading FlashCopy relationship is then created at Time 1, when a FlashCopy is established from Volume B to Volume C.
Figure 9-2 Forward cascading FlashCopy relationship
Backward cascade
A backward cascading relationship is created when the source volume in an existing FlashCopy relationship becomes the target volume in a new FlashCopy relationship.
In Figure 9-3, a FlashCopy relationship was established at Time 0 from Volume B to Volume C. A backward cascading FlashCopy relationship is then created at Time 1 when FlashCopy is established from Volume A to Volume B.
Figure 9-3 Backward cascading FlashCopy relationship
Source relation and Target relation
In a Cascading FlashCopy relationship with FlashCopy established between volume A and volume B, and a second FlashCopy relationship between volume B and volume C (see Figure 9-4), the following terms are used to distinguish between the two FlashCopy relationships:
•Source Relation: the FlashCopy relationship between volume A and volume B.
•Target Relation: the FlashCopy relationship between volume B and volume C.
Figure 9-4 Source and Target FlashCopy relations
9.3 Cascading FlashCopy and Fast Reverse Restore
Because Cascading FlashCopy allows a volume to be simultaneously the source of one relation and the target of another relation, it is now possible to reverse one of the relationships without first withdrawing the other relationship. As illustrated in Figure 9-5, the A → B FlashCopy relationship can now be reversed while the A → C FlashCopy relationship is preserved.
Figure 9-5 Cascading FlashCopy and Fast Reverse Restore
9.4 Thin provisioning considerations
It is important to consider the implications of Cascading FlashCopy relationships when using extent space efficient (ESE) volumes on the DS8880. Withdrawing the source relation in a cascading relationship created with the NOCOPY option results in a background copy being started to the target volume in the source relation. This situation will cause the allocated capacity to increase for the target volume.
The behavior of withdrawing Flashcopy relationships established with COPY can also be affected by Cascading Flashcopy. When a Flashcopy target volume is in a cascading relationship, the Flashcopy is not withdrawn until the background copy completes.
Using the DSCLI, the allocated capacity for a volume can be displayed under the realcap output value of the showckdvol or showfbvol command.
Using the DS8880 Storage Management GUI, the allocated capacity can be viewed by hovering over the Volumes icon and clicking Volumes, as shown in Figure 9-6.
Figure 9-6 DS8900F Storage Management GUI: Volumes
Make sure to specify the Allocated Capacity field by clicking the icon at the top-right corner and selecting Allocated Capacity, as shown in Figure 9-7.
Figure 9-7 DS8900F Storage Management GUI: Volumes->Allocated Capacity
9.4.1 Space release
For full volume FlashCopy relationships, space release will occur on an ESE target volume as long as the following conditions are met:
•The target volume is not cascading in a cascading FlashCopy relationship.
•The target volume is not in any other copy services relationships.
Note that establishing data set level FlashCopy onto an ESE volume will not cause space to be released on the target volume.
9.4.2 Withdrawing Cascading FlashCopy relationships
In a non-cascading FlashCopy relationship, withdrawing FlashCopy does not affect the allocated capacity of a target volume.
In a cascading FlashCopy relationship A → B → C, withdrawing the A → B FlashCopy relationship while the B → C FlashCopy relationship still exists will result in all the allocated capacity on volume A being physically copied to volume B.
If volume A is a fully allocated volume, this will cause volume B to allocate its full capacity.
Example
In Example 9-1 on page 66, a cascading FlashCopy relationship is created from volume 0111 to volume 0110 to volume 0112. All three volumes are 1 GiB ESE volumes and volume 0111 has 176 MiB of real capacity allocated.
Before the Flashcopies are established, volume 0110 has 0 MiB of real capacity allocated.
When the FlashCopy relationship between volume 0111 and volume 0110 is removed, message CMUN81131I is issued to alert the user that a physical copy will be completed before the FlashCopy relationship is withdrawn.
Example 9-1 Withdrawing a Cascading FlashCopy relationship
dscli> showfbvol 0111
Name ITSO_SLES12_
ID 0111
cap (MiB) 1024
realcap (MiB) 176
dscli> showfbvol 0110
Name ITSO_SLES12_
ID 0110
cap (MiB) 1024
realcap (MiB) 0
dscli> mkflash -nocp -tgtse -persist 0111:0110
CMUC00137I mkflash: FlashCopy pair 0111:0110 successfully created.
dscli> mkflash -nocp -tgtse -persist 0110:0112
CMUC00137I mkflash: FlashCopy pair 0110:0112 successfully created.
dscli> rmflash 111:110
CMUC00144W rmflash: Are you sure you want to remove the FlashCopy pair 111:110:? [y/n]:
y
CMUN81131I rmflash: 0111:0110: The Withdraw command was accepted and the FLC relationship will be removed after the physical copy is completed.
A subsequent showfbvol command against volume 0110 shows that now the allocated capacity for volume 0110 matches that of volume 0111 after the FlashCopy is removed and the physical copy has completed. See Example 9-2.
Example 9-2 Capacity allocated on Target
dscli> showfbvol 0110
Date/Time: August 28, 2017 9:56:06 AM CEST IBM DSCLI Version: 7.8.30.459 DS: IBM.2107-75HGX91
Name ITSO_SLES12_
ID 0110
cap (MiB) 1024
realcap (MiB) 176
9.4.3 Out of Space conditions
When using Extent Space Efficient (ESE) FlashCopy target volumes, it is possible for the target extent pool to run out of space. This will cause the FlashCopy relationship to fail. The writes to the FlashCopy source volume will be allowed if there is no Cascading FlashCopy relationship. If there is a forward cascading FlashCopy relationship from the target volume that ran out of space, this FlashCopy relationship (target relation) will also fail. Note that Global Mirror FlashCopy targets that run out of space cause the source volume to inhibit writes.
9.5 Design limitations
Note that the following restrictions apply to cascading FlashCopy relationships:
•A volume can only be a target volume in one FlashCopy relationship.
•A volume or dataset can be involved in a maximum of 12 relationships:
– 12 source relationships.
or
– 11 source relationships and 1 target relationship.
•Cannot cascade from an incremental FlashCopy relationship until the background copy has completed.
•Cannot create cyclic FlashCopy relationships between two volumes where there is a relationship from Volume A → Volume B and Volume B → Volume A.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.