GDPS Logical Corruption Protection and Testcopy Manager
In this chapter, we provide an overview of the GDPS Logical Corruption Protection (LCP) and Testcopy Manager features, which are separately priced features of GDPS.
LCP is a set of GDPS capabilities that are provided in response to the growing number of requests for a GDPS managed “Continuous Data Protection” capability and is aimed at helping clients to recover from cyberattacks, internal threats, and other forms of logical data corruption.
At a high level, LCP provides the ability to capture multiple, secure point-in-time copies of critical production data (referred to as protection copies) and to restore the data back into production, if necessary. LCP also provides the ability to recover a specific point-in-time copy to another set of devices that can be used to start one or more isolated recovery systems to analyze the scope of a particular logical corruption event.
More security and protection are provided for the LCP protection copies than for copies that are taken with more traditional methods by minimizing host access to these volumes and by providing specific roles and rules for their management.
Testcopy Manager (TCM) is a GDPS feature that allows clients to manage, capture, and refresh a test copy for use within an isolated test environment. This isolated copy is created and maintained by using a Global Copy relationship cascaded from an existing GDPS environment.
This chapter includes the following topics:
10.1 LCP terminology
The following terms are used when describing LCP:
•Copy Sets (CS)
Copy sets are a grouping of volumes that together provide a consistent point-in-time copy of data. Taking a copy to a Copy Set is called capturing a protection copy (also referred to as a backup copy). The protection copy can be captured using the SafeGuarded Copy technology or the FlashCopy technology.
•SafeGuarded Copy (SGC) copy sets
The SafeGuarded Copy copy sets are copy sets that are created with the SGC technology. Protection copies (or backups) taken with SGC require predefined, virtual capacity, which is known as SGC Backup Capacity, to store the consistent backups of the associated source volumes. The SGC Backup Capacity does not use a device number in the storage system; therefore, it cannot be directly addressed by any host system, isolating them and protecting them from conventional host I/O access. Up to 500 SGC backups per production volume are supported by the SGC technology.
GDPS supports up to 10 SGC copy sets. Up to 500 protection copies can be taken for each SGC copy set. This might provide you a way to separately manage the LCP operations for multiple groups of volumes. For example, you might manage LCP operations separately for production volumes and test volumes.
Although up to 500 protection copies can be taken for each SGC copy set, the number of protection copies that can be maintained for a specific production device in an environment is dependent upon the amount of physical space that is assigned to the SGC Backup Capacity that is associated with the production device.
The more updates that occur to the production volume, the more space is required in the SGC Backup Capacity to maintain the copies. For this reason, the SGC Backup Capacity can be dynamically expanded to accommodate changes in update patterns for devices that are protected with SGC.
•FlashCopy (FC) copy sets
The FlashCopy copy sets are copy sets created with the FlashCopy technology. Protection copies (or backups) taken with FlashCopy are isolated and protected from conventional host I/O access by not requiring any UCBs to be defined in any host for them and by not allowing writes to them, which in turn, prevent them from being IPLed from.
GDPS supports up to 10 FC copy sets. However, the total number of FC copy sets and Recovery copy sets combined cannot exceed 11.
•Recovery copy (RC) copy sets
A Recovery Copy copy set is used for corruption analysis or recovery testing. It is created by FlashCopying from a copy set and is not Target Write Inhibited, which allows it to be used to IPL a recovery or test system.
GDPS supports up to 10 RC copy sets. However, the total number of RC copy sets and FC copy sets combined cannot exceed 11.
•Replication Site (RS) volume sets
The RS volume sets are the conventional replication site volume sets that form the basis of the GDPS replication model and can be directly IPLed from when they are in a primary status.
•LCP management profile
An LCP management profile describes the management characteristics of the protection copies including the following:
– the replication site where the captures are to be taken
– the consistency group to be captured
– copy sets assigned to this management profile
– how long a capture must be retained before it expires and becomes eligible for release
– how much time must elapse before a new capture can be taken
The management profile name is unique within the LCP environment and you can define multiple LCP management profiles.
•LCP Restore
The LCP Restore process is the restoration of data in which the target is a production RS volume set.
•LCP Recover
The recover process is the recovery of data in which the target is the RC copy set. The source of the recovery is a specific FC or SGC copy set.
10.2 Introduction to LCP and Testcopy Manager
Two implementations of LCP are provided: internal LCP and external LCP. The following sections introduce to these implementations of LCP and to the Testcopy Manager.
10.2.1 Internal LCP
With internal LCP, the protection copies are within the same storage system as one of the existing production copies in your GDPS environment. This configuration is also referred to as a virtual airgap model or a virtual isolation model. Figure 10-1 shows an internal LCP topology.
Figure 10-1 Internal LCP (virtual airgap)
In Figure 10-1, RSx is one of the RS volume sets in your GDPS production environment. CS1, CS2, and CS3 are the copy sets that contain the protection copies. RC1 and RC2 are RC copy sets. All of these devices are in the same storage server.
With internal LCP, one of the controlling systems in your GDPS environment manages the LCP environment and is referred to as an internal LCP Manager. Therefore, no extra controlling systems are required.
10.2.2 External LCP
External LCP environments differ from internal LCP environments in that the protection copies are isolated from your production environment. An extra copy of data is cascaded from one of the existing production copies in your GDPS environment to a storage system that is external to your production environment.
The protection copies are then captured and maintained within the external storage system. This configuration is also referred to as a physical airgap model or a physical isolation model. Figure 10-2 shows an external LCP topology.
Figure 10-2 External LCP (physical airgap)
In Figure 10-2, RSx is again one of the RS volume sets in your GDPS production environment. Global Copy or Global Mirror (depending on the type of GDPS environment that external LCP is implemented in) is used to replicate the data from the RSx volume set to the volume set labeled RSL in Figure 10-2, which is in a different storage system than RSx.
The copy sets labeled CS1, CS2, and CS3 are the protection copies, which are captured from RSL. The RSL volume set, the CS1, CS2, and CS3 copy sets, and the recovery volume sets (labeled RC1 and RC2 in Figure 10-2) are all in the same storage server.
With external LCP, another external controlling system is required to manage the LCP environment and is referred to as an external LCP Manager.
The RC copy set, in both internal and external LCP environments, enables the IPL of systems for forensic analysis or other purposes.
In most client configurations, the FC copy sets, the SGC Backup Capacity (when SGC is used), and the RC copy set are all thinly provisioned to minimize space requirements.
10.2.3 Testcopy Manager
The Testcopy Manager (TCM) function can be viewed as a subset of the external LCP Manager function. As with the external LCP Manager function, another copy of data is cascaded from one of the existing production copies in your GDPS environment to a storage system external to your production environment.
The main difference between the Testcopy Manager function and the LCP Manager function is that, with the Testcopy Manager function, only one point-in-time copy can be taken and maintained in the external storage system. This copy can then be used in an isolated test environment and can be refreshed with a new copy of production data as required.
Figure 10-3 shows a Testcopy Manager environment.
Figure 10-3 Testcopy Manager
In Figure 10-3, RSx is again one of the RS volume sets in your GDPS production environment. Global Copy is used to replicate the data from the RSx volume set to the volume set that is labeled RST in Figure 10-3, which is in a different storage system than RSx. The test copy (labeled TC1 in Figure 10-3) is then captured from the RST volume set. The RST volume set and the test copy volume set are in the same storage server.
The Testcopy Manager feature is included with the External LCP feature. In this case, an LCP environment and a Testcopy Manager environment can be implemented and maintained from the same production copy of data. The Testcopy Manager can also be licensed separately from the external LCP Manager. In that case, only a Testcopy Manager environment can be implemented.
10.3 LCP operational models
The following sections describe the support that is provided for internal and external LCP, and TCM in the various GDPS solution offerings.
10.3.1 GDPS Metro
For more information about the GDPS Metro offering, see Chapter 3, “GDPS Metro” on page 53.
Internal and external LCP are supported in GDPS Metro environments, as described next.
Internal LCP in GDPS Metro environments
Internal LCP can be implemented from any or all of the RS volume sets in a GDPS Metro environment. Figure 10-4 shows an example of internal LCP in a GDPS Metro single-leg environment.
Figure 10-4 Internal LCP in a GDPS Metro single-leg environment
As shown in Figure 10-4, internal LCP is implemented on the RS1 and the RS2 copies of data. Each of these LCP environments consists of three protection copies or copy sets that are labeled CS1, CS2, and CS3 and one RC copy set that is labeled RC1.
Figure 10-5 shows an example of internal LCP in a GDPS Metro dual-leg environment.
Figure 10-5 Internal LCP in a GDPS Metro dual-leg environment
As shown in Figure 10-5, internal LCP is implemented on two of the three production copies of data (RS2 and RS3). Again, each of these LCP environments consists of three protection copies or copy sets that are labeled CS1, CS2, and CS3 and one RC copy set that is labeled RC1.
Consider the following points when internal LCP is implemented in GDPS Metro single-leg or dual leg environments:
•All internal LCP environments that are implemented in a GDPS Metro configuration are managed by the standard GDPS Metro controlling systems that manage the entire GDPS Metro environment.
•The copy sets in GDPS Metro internal LCP environments (labeled CS1, CS2, and CS3 in Figure 10-4 on page 300 and in Figure 10-5 on page 300) can be FC copy sets or SGC copy sets. A mixture of FC copy sets and SGC copy sets is also supported. For example, the copy sets in the LCP environment that is implemented on the RS1 devices can be FC copy sets while the copy sets that are implemented on the RS2 devices can be SGC copy sets.
•When an internal LCP protection copy is captured in a GDPS Metro environment, updates to the LCP source devices are temporarily held up so that a consistent copy can be captured. LCP source devices also serve as one of the production RS volume sets in your GDPS Metro environment. Therefore, this temporary freezing of the updates might affect your production applications. This is true whether the LCP source volumes are serving as your Metro Mirror primary devices or your Metro Mirror secondary devices.
The amount of time that updates are held up depends on a number of factors including, but not limited to, the number of LSSs and devices in your GDPS Metro configuration. You must evaluate whether your applications can tolerate the effect of capturing an LCP copy in your environment.
External LCP (which is described next) avoids this impact to production applications.
External LCP in GDPS Metro environments
External LCP is supported only for single-leg GDPS Metro environments and can be implemented only from one of the RS volume sets. Figure 10-6 shows an example of external LCP in a GDPS Metro single-leg environment.
Figure 10-6 External LCP in a GDPS Metro single-leg environment
As shown in Figure 10-6, external LCP is implemented on the RS2 volume set, which is the current set of Metro Mirror secondary devices. Global Mirror is used to copy the data from RS2 to the external copy of data (labeled RSL in Figure 10-6). The RSL volume set serves as the source for the LCP protection copy captures. The LCP environment then consists of the RSL devices, along with three protection copy sets (labeled CS1, CS2, and CS3) and one RC copy set (labeled RC1).
The LCP environment in a GDPS Metro external LCP solution is managed by an instance of GDPS Global - GM (GDPS GM) that runs on a separate controlling system from the GDPS Metro controlling system functions.
For more information about the GDPS Global - GM offering, see Chapter 6, “GDPS Global - GM” on page 173. This LCP Manager system is used to maintain Global Mirror to the RSL volume set, in addition to capturing and recovering the LCP protection copies.
The copy sets in GDPS Metro external LCP environments (labeled CS1, CS2, and CS3 in Figure 10-6 on page 301) can be SGC copy sets only.
In most client configurations, the SGC Backup Capacity and the RC copy set are thin provisioned to minimize space requirements.
The following steps are taken when a request is made to capture an external LCP protection copy in a GDPS Metro environment:
1. Global Mirror is paused on a consistent boundary. This process results in the RSL volume set containing a consistency copy of data and the suspension of the Global Mirror session.
2. A protection copy is captured from the RSL volume set to one of the SGC copy sets.
3. Global Mirror is resumed.
This method avoids the potential impact to production applications that is associated with taking an internal LCP copy (for more information, see “Internal LCP in GDPS Metro environments” on page 300).
10.3.2 GDPS Global - GM
For more information about the GDPS Global - GM (GDPS GM) offering, see Chapter 6, “GDPS Global - GM” on page 173.
Internal and external LCP are supported in GDPS GM environments, as described next.
Internal LCP in GDPS GM environments
Internal LCP can be implemented from the Global Mirror secondary device set (B.RS1) in GDPS GM environments. Figure 10-7 shows internal LCP in a GDPS GM environment.
Figure 10-7 Internal LCP in a GDPS Global - GM environment
As shown in Figure 10-7, the RS1 devices in the production region (referred to as Region A) labeled A.RS1, are the Global Mirror primary devices that the production applications use.
Internal LCP is implemented from the RS1 devices in the recovery region (referred to as Region B), labeled B.RS1 in Figure 10-7 on page 302, which are also the Global Mirror secondary devices. The LCP environment consists of three protection copies or copy sets that are labeled CS1, CS2, and CS3 and one RC copy set labeled RC1.
The LCP environment in a GDPS GM solution is managed by the GDPS GM controlling system that runs in the recovery region, referred to as the Kr-system, and the copy sets in a GDPS GM LCP environment must be SGC copy sets.
The following steps are taken when a request is made to capture a protection copy in a GDPS GM environment:
1. Global Mirror is paused on a consistent boundary. This results in the Global Mirror secondary devices (B.RS1) containing a consistent copy of data and the Global Mirror session being suspended.
2. A protection copy is captured from the B.RS1 volume set to one of the SGC copy sets.
3. Global Mirror is resumed.
This method avoids any impact to production applications during the LCP copy capture process at the expense of a typically minor disruption to your Recovery Point Objective (RPO).
External LCP in GDPS GM environments
External LCP can be implemented from the Global Mirror secondary device set (B.RS1) in GDPS GM environments. Figure 10-8 shows external LCP in a GDPS GM environment.
Figure 10-8 External LCP in a GDPS Global - GM environment
As shown in Figure 10-8, a standard GDPS GM 2-site environment exists with Global Mirror running between the A.RS1 devices in the production region (referred to as Region A) and the B.RS1 devices in the recovery region (referred to as Region B). The A.RS1 devices are the devices that the production applications use.
To seed the external LCP environment, a Global Copy relationship is added to the environment to mirror the data from the B.RS2 devices to the external copy of data (labeled RSL in Figure 10-8). The RSL volume set serves as the source for the LCP protection copy captures. The LCP environment then consists of the RSL devices, along with several protection copy sets that are labeled CS1, CS2, and CSn and multiple RC copy sets that are labeled RC1 and RCn.
In this model, the external LCP environment is managed by an instance of GDPS Metro that runs on a separate controlling system from the GDPS GM controlling system functions and that is configured in a single-leg topology.
For more information about the GDPS Metro offering, see Chapter 3, “GDPS Metro” on page 53. This LCP Manager system is used to maintain Global Copy mirroring to the RSL volume set, in addition to capturing and recovering the LCP protection copies.
Consider the following points when external LCP is implemented in GDPS GM 2-site environments:
•The LCP environment can be created and maintained from the B.RS1 devices only.
•The protection copies can be FC copy sets or SGC copy sets.
•Capturing an external LCP protection copy requires task coordination between the LCP Manager controlling system and the controlling systems that make up the GDPS GM 2-site solution. The key coordination task here is creating a consistent data point on the RSL volume set so that it can then be captured to a corresponding copy set. Global Copy is used to maintain the RSL copy and as discussed in 2.4.3, “Global Mirror” on page 32, Global Copy does not provide data consistency.
•The following steps are taken (when a request is made to capture a protection copy) to coordinate consistency across the environment to the RSL volume set and then, to capture the consistency group on the suitable copy set devices:
a. Global Mirror is paused on a consistent boundary. This process results in the suspension of the Global Mirror secondary devices (B.RS1) that contain a consistency copy of data and the Global Mirror session.
b. The consistent copy of data is allowed to drain to the RSL volume set.
c. After the consistent copy of data arrives at RSL, the Global Copy relationship between B.RS1 and RSL is suspended to prevent any more updates to the RSL volume set until after the consistent copy of data is captured to a copy set in a subsequent step.
d. Global Mirror is resumed, which allows updates to again flow from Region A to the B.RS1 volume set.
e. A protection copy is captured from the RSL volume set to one of the associated copy sets.
f. The Global Copy relationship between B.RS1 and RSL is resumed to allow updates to again flow to the RSL volume set until the next protection copy is taken.
This approach minimizes the time that it takes to run the capture process each time by keeping the RSL volume set as current as possible. It also avoids any effect on production applications during the LCP copy capture process at the expense of a typically minor disruption to your Recovery Point Objective (RPO).
10.3.3 GDPS Metro Global - GM
For more information about the GDPS Metro Global - GM (GDPS MGM) offering, see Chapter 9, “Combining local and metro continuous availability with out-of-region disaster recovery” on page 267.
The following sections describe the LCP and TCM features of the GDPS MGM solutions.
GDPS Metro Global - GM 3-site
Internal and external LCP are supported in GDPS MGM 3-site environments, as described next.
Internal LCP in GDPS Metro Global - GM 3-site environments
Figure 10-9 shows an example of internal LCP in a GDPS MGM 3-site environment.
Figure 10-9 Internal LCP on the Metro leg in a GDPS MGM 3-site environment
As shown in Figure 10-9, a standard GDPS MGM 3-site environment exists with Metro Mirror running between the A.RS1 devices and the A.RS2 devices in the production region (referred to as Region A) and Global Mirror running between the A.RS2 devices in Region A and the B.RS1 devices in the recovery region (referred to as Region B).
The A.RS1 devices are the devices that the production applications are using. Internal LCP is implemented on the A.RS2 volume set, which is the current set of Metro Mirror secondary devices. The LCP environment consists of three protection copies or copy sets that are labeled CS1, CS2, and CS3 and one RC copy set that is labeled RC1.
In addition to implementing internal LCP on the Metro Mirror secondary volume set as shown in this example, you also can implement internal LCP on the Metro Mirror primary volume set (A.RS1 in Figure 10-9) or on both the primary and secondary volume sets in Region A at the same time.
Consider the following points when internal LCP is implemented on the Metro leg (on the Metro Mirror primary or secondary volume sets) in a GDPS MGM 3-site environment:
•The LCP environments are managed by the standard GDPS Metro controlling systems that manage the Metro leg of the environment.
•The copy sets can be FC copy sets or SGC copy sets. A mixture of FC copy sets and SGC copy sets also is supported. For example, the copy sets in the LCP environment that is implemented on the A.RS1 devices can be FC copy sets; the copy sets that are implemented on the A.RS2 devices can be SGC copy sets.
•When a protection copy is captured, updates to the LCP source devices are temporarily held up so that a consistent copy can be captured. LCP source devices also serve as one of the production RS volume sets in the GDPS Metro leg of your environment. Therefore, this temporary freezing of the updates might affect your production applications. This result is true whether the LCP source volumes are serving as your Metro Mirror primary devices or your Metro Mirror secondary devices.
The amount of time that updates are held up depends on a number of factors including, but not limited to, the number of LSSs and devices in your GDPS Metro configuration. You must evaluate whether your applications can tolerate the effect of capturing an LCP copy in your environment.
Implementing internal LCP on the Global Mirror secondary devices in the recovery region, which is described next, avoids this effect on production applications. Implementing external LCP on the Global Mirror secondary devices in the recovery region, which is described in “External LCP in GDPS Metro Global - GM 3-site environments” on page 308, also avoids this effect on production applications.
Figure 10-10 shows an example of internal LCP implemented on the Global Mirror secondary devices in the recovery region in a GDPS MGM 3-site environment.
Figure 10-10 Internal LCP on the GM leg in a GDPS MGM 3-site environment
In Figure 10-10, we again have Metro Mirror running between the A.RS1 devices and the A.RS2 devices in Region A and Global Mirror running between the A.RS2 devices in Region A and B.RS1 devices in Region B. Internal LCP is implemented on the B.RS1 volume set, which is the Global Mirror secondary devices. The LCP environment consists of three protection copies or copy sets that are labeled CS1, CS2, and CS3 and one RC copy set that is labeled RC1.
The LCP environment in this configuration is managed by the GDPS GM controlling system that runs in the recovery region, which is referred to as the Kr-system, and the copy sets must be SGC copy sets.
The following steps are taken when a request is made to capture a protection copy in this environment:
1. Global Mirror is paused on a consistent boundary. This process results in the Global Mirror secondary devices (B.RS1) that contain a consistent copy of data and the Global Mirror session being suspended.
2. A protection copy is captured from the B.RS1 volume set to one of the SGC copy sets.
3. Global Mirror is resumed.
This method avoids any effect on production applications during the LCP copy capture process at the expense of a typically minor disruption to your Recovery Point Objective (RPO).
Finally, you might want to maintain LCP protection copies in both regions of your GDPS MGM 3-site environment. This configuration is possible by implementing internal LCP on one of the volume sets in Region A and also implementing internal LCP on the B.RS1 devices in Region B. Figure 10-11 shows an example of such an environment.
Figure 10-11 Internal LCP in both regions in a GDPS MGM 3-site environment
The environment that is shown in Figure 10-11 looks similar to the environment that is shown in Figure 10-10 on page 306. The key difference is that in addition to having an internal LCP environment implemented on the B.RS1 volume set in Region B, we also have an internal LCP environment that is implemented on the A.RS2 volume set in Region A. Each LCP environment contains a distinct set of protection copy sets and a distinct recovery volume set.
The LCP environment in Region A is managed by the standard GDPS Metro controlling systems that manage the Metro leg of the environment and the LCP environment in Region B is managed by the GDPS GM Kr-system. These LCP environments are managed separately and protection copies are captured in each one independently.
Having LCP protection copies in both regions ensures that you can recover from logical corruption events, even if one Region failed or connectivity between regions was interrupted.
External LCP in GDPS Metro Global - GM 3-site environments
Figure 10-12 External LCP in a GDPS MGM 3-site environment
In Figure 10-12, a standard GDPS MGM 3-site environment exists with Metro Mirror running between the A.RS1 devices and the A.RS2 devices in the production region (referred to as Region A) and Global Mirror running between A.RS1 in Region A and B.RS1 in the recovery region (referred to as Region B). The A.RS1 devices are the devices that the production applications are using.
In this model, the external LCP environment is managed by an instance of GDPS Metro that runs on a separate controlling system from the GDPS MGM controlling system functions and that is configured in a single-leg topology. For more information about the GDPS Metro offering, see Chapter 3, “GDPS Metro” on page 53. This LCP Manager system is used to maintain Global Copy mirroring to the RSL volume set, in addition to capturing and recovering the LCP protection copies.
Consider the following points when external LCP is implemented in GDPS MGM 3-site environments:
•The LCP environment can be created and maintained from the B.RS1 devices only.
•The protection copies can be FC copy sets or SGC copy sets.
The following steps are taken (when a request is made to capture a protection copy) to coordinate consistency across the environment to the RSL volume set and then to capture the consistency group on the appropriate copy set devices:
a. Global Mirror is paused on a consistent boundary. This process results in the Global Mirror secondary devices (B.RS1) containing a consistency copy of data and the Global Mirror session being suspended.
b. The consistent copy of data is then allowed to drain to the RSL volume set.
c. After the consistent copy of data arrives at RSL, the Global Copy relationship between B.RS1 and RSL is suspended to prevent any more updates to the RSL volume set until after the consistent copy of data is captured to a copy set in a subsequent step.
d. Global Mirror is resumed, which allows updates to again flow from Region A to the B.RS1 volume set.
e. A protection copy is captured from the RSL volume set to one of the associated copy sets.
f. The Global Copy relationship between B.RS1 and RSL is resumed to allow updates to again flow to the RSL volume set until the next protection copy is taken.
This approach minimizes the time that it takes to run the capture process each time by keeping the RSL volume set as current as possible. It also avoids any effect on production applications during the LCP copy capture process at the expense of a typically minor disruption to your RPO.
GDPS Metro Global - GM 4-site
External LCP and Testcopy Manager (TCM) are supported in GDPS MGM 4-site environments. Internal LCP is not supported in GDPS MGM 4-site environments.
External LCP in GDPS Metro Global - GM 4-site environments
Figure 10-13 shows external LCP in a GDPS MGM 4-site environment.
Figure 10-13 External LCP in a GDPS MGM 4-site environment
In Figure 10-13 on page 309, a standard GDPS MGM 4-site environment exists with Metro Mirror running between the A.RS1 devices and the A.RS2 devices in the production region (referred to as Region A), Global Mirror running between A.RS1 in Region A and B.RS1 in the recovery region (referred to as Region B), and Global Copy running between the B.RS1 devices to a second set of devices in Region B, labeled B.RS2. The A.RS1 devices are the devices that the production applications use.
Considering Figure 10-13 on page 309, to seed the external LCP environment, another Global Copy relationship is used to mirror the data from the B.RS2 devices to the external copy of data, labeled RSL in the figure. The RSL volume set serves as the source for the LCP protection copy captures. The LCP environment then consists of the RSL devices, along with three protection copy sets labeled CS1, CS2, and CS3 and one RC copy set labeled RC1.
The LCP environment in a GDPS MGM 4-site solution is managed by an instance of GDPS Metro that runs on a separate controlling system from the GDPS MGM controlling system functions and that is configured in a single-leg topology.
For more information about the GDPS Metro offering, see Chapter 3, “GDPS Metro” on page 53. This LCP Manager system is used to maintain Global Copy mirroring to the RSL volume set, in addition to capturing and recovering the LCP protection copies.
Consider the following points when external LCP is implemented in GDPS MGM 4-site environments:
•The LCP environment can be created and maintained from the B.RS2 devices only.
•The protection copies can be FC copy sets or SGC copy sets.
•Capturing an external LCP protection copy requires task coordination between the LCP Manager controlling system and the controlling systems that make up the GDPS MGM 4-site solution. The key coordination task here is creating a consistent data point on the B.RS2 volume set so that it can be replicated to the RSL volume set and then captured to a corresponding copy set. Global Copy is used to maintain the B.RS2 copy and as discussed in section 2.4.3, “Global Mirror” on page 32, Global Copy does not provide data consistency.
The following steps are taken when a request is made to capture a protection copy in a GDPS MGM 4-site environment to coordinate consistency across the environment to the RSL volume set and then to capture the consistency group on the appropriate copy set devices:
a. Global Mirror is paused on a consistent boundary. This pause results in the suspension of the Global Mirror secondary devices (B.RS1) that contain a consistency copy of data and the Global Mirror session.
b. The consistent copy of data is then allowed to drain to the B.RS2 volume set and on to the RSL volume set.
c. After the consistent copy of data arrives at RSL, the Global Copy relationship between B.RS2 and RSL is suspended to prevent any more updates to the RSL volume set until after the consistent copy of data is captured to a copy set in a subsequent step.
d. Global Mirror is resumed, which allows updates to again flow from Region A to the B.RS1 and B.RS2 volume sets.
e. A protection copy is captured from the RSL volume set to one of the associated copy sets.
f. The Global Copy relationship between B.RS2 and RSL is resumed to allow updates to again flow to the RSL volume set until the next protection copy is taken. This resumption minimizes the time it takes to run the capture process each time by keeping the RSL volume set as current as possible.
This method avoids any impact to production applications during the LCP copy capture process at the expense of a typically minor disruption to your RPO.
TCM in GDPS Metro Global - GM 4-site environments
As described in 10.2.3, “Testcopy Manager” on page 299, the TCM feature is similar to the External LCP feature. The key difference being that only one copy set exists in a TCM environment.
Figure 10-14 shows an example of TCM in a GDPS MGM 4-site environment.
Figure 10-14 Testcopy Manager in a GDPS MGM4-site environment
Figure 10-14 looks similar to Figure 10-13 on page 309. A standard GDPS MGM 4-site environment is shown with Global Copy being used to seed the external copy. The external volume set in this case is labeled RST to reflect that it is part of a TCM environment and there is only one copy set, which is labeled TC1. There are no other copy sets and there is no recovery copy.
As with External LCP, the TCM environment is managed by an instance of GDPS Metro that runs on a separate controlling system from the GDPS MGM controlling system functions and that is configured in a single-leg topology. This TCM system is used to maintain Global Copy mirroring to the RST volume set and to capture the TC1 copy upon request.
In a TCM environment, the TC1 copy set can be a FlashCopy copy set only. SGC is not supported in a TCM environment.
As with external LCP, the TCM environment can be created and maintained from the B.RS2 devices only. Capturing an external TCM test copy requires task coordination between the TCM controlling system and the controlling systems that make up the GDPS MGM 4-site solution. Similar steps are run to capture a test copy as are run to capture a protection copy in an external LCP environment.
Combining external LCP and TCM
As described in 10.2.3, “Testcopy Manager” on page 299, external LCP, and TCM can be implemented in the same GDPS MGM 4-site environment (see Figure 10-15).
Figure 10-15 External LCP and TCM in a GDPS MGM 4-site environment
Again, Figure 10-15 looks similar to Figure 10-13 on page 309 and Figure 10-14 on page 311 in that a standard GDPS MGM 4-site environment is shown. However, in Figure 10-15, two Global Copy relationships are used to seed two external copies from the B.RS2 volume set: one for the LCP environment and one for the TCM environment.
With this configuration, the external LCP environment and the TCM environment are both managed by a single instance of GDPS Metro that runs on a separate controlling system from the GDPS MGM controlling system functions. However, now this instance of GDPS Metro is configured in a dual-leg topology, which allows it to function as the LCP Manager and the TCM Manager.
A capture process in this configuration applies only to one of the external environments. A capture request can capture an LCP protection copy or it can refresh the test copy, but not both at the same time.
10.3.4 GDPS Metro Global - XRC
For more information about the GDPS Metro Global - XRC (GDPS MzGM) offering, see Chapter 9, “Combining local and metro continuous availability with out-of-region disaster recovery” on page 267.
Internal LCP is supported in GDPS MzGM 4-site environments and can be implemented only from either or both of the RS volume sets in the production region. External LCP is not supported in GDPS MzGM 4-site environments and internal nor external LCP is supported in GDPS MzGM 3-site environments.
Figure 10-16 shows an example of internal LCP in a GDPS MzGM 4-site environment.
Figure 10-16 Internal LCP in a GDPS MzGM 4-site environment
As shown in Figure 10-16, a standard GDPS MzGM 4-site environment exists with Metro Mirror running between the A.RS1 devices and the A.RS2 devices in the production region (referred to as Region A), XRC (also known as z/OS Global Mirror or zGM) running between A.RS1 in Region A and B.RS1 in the recovery region (referred to as Region B), and Metro Mirror running between the B.RS1 devices to a second set of devices in Region B, labeled B.RS2. The A.RS1 devices are the devices that the production applications are using.
Still, referring to Figure 10-16, internal LCP is implemented on the A.RS1 volume set. The LCP environment consists of three protection copies or copy sets that are labeled CS1, CS2, and CS3 and one RC copy set labeled RC1.
The following considerations apply when internal LCP is implemented in a GDPS MzGM 4-site environment:
•All internal LCP environments that are implemented in a GDPS MzGM 4-site configuration are managed by the standard GDPS Metro controlling systems that manage the GDPS Metro portion of the environment. No external LCP Manager controlling system is required.
•The copy sets can be FC copy sets or SGC copy sets. A mixture of FC copy sets and SGC copy sets is also supported. For example, the copy sets in the LCP environment that is implemented on the RS1 devices can be FC copy sets while at the same time, the copy sets that are implemented on the RS2 devices can be SGC copy sets.
•When an internal LCP protection copy is captured, updates to the LCP source devices are temporarily held up so that a consistent copy can be captured. The LCP source devices also serve as one of the production RS volume sets in your GDPS Metro environment. Therefore, this temporary freezing of the updates can affect your production applications. This is true whether the LCP source volumes are serving as your Metro Mirror primary devices or your Metro Mirror secondary devices.
The amount of time that updates are held up depends on a number of factors including, but not limited to, the number of LSSs and devices in your GDPS Metro configuration. You must evaluate whether your applications can tolerate the impact of capturing an LCP copy in your environment.
10.4 Managing the LCP and TCM environments
This section describes the capabilities provided for managing the LCP and TCM environments.
10.4.1 Scripting
Earlier in this book, we described the powerful scripting capability that is provided with most GDPS offerings to enable the automation of complex, multi-step procedures involving multiple GDPS resources. This scripting capability is extended to enable the automation of the LCP and TCM environments as well.
For LCP environments, script statements are provided to perform the following operations:
•Coordinating and securing a consistent copy of data on the RSL volume set (applies to external LCP environments only).
•Capturing protection copies from the RSL volume set to the FC or SGC copy sets (applies to external LCP environments only).
•Capturing protection copies from an RS(n) volume set to the FC or SGC copy sets (applies to internal LCP environments only).
•Releasing expired FC and SGC protection copies.
•Recovering protection copies from the FC or SGC copy sets to an RC copy set.
•Capturing a copy from an RS(n) volume set directly to an RC copy set.
This operation can be useful for taking backups to tape from the RC copy set and for performing validation for early detection of any logical corruption that might occur in the production environment.
•Restoring a copy back to production (see ““Restoring data back to production” on page 315”).
•Ending (removing) a recovery copy.
Scripting is provided to automate the following operations for TCM environments:
•Coordinating and securing a consistent copy of data on the RST volume set
•Capturing a test copy from the RST volume set to the test copy volume set
•Withdrawing a test copy relationship
Restoring data back to production
GDPS provides scripting capabilities for automating the task of restoring data from the LCP environment back to production. These capabilities apply to the catastrophic use case. In the catastrophic use case, large amounts of data are corrupted, which makes surgical recovery of only the corrupted data infeasible. Therefore, production is assumed to be down while large amounts of data (perhaps the entire environment) are restored.
|
Note: At the time of this writing, the automation capabilities to restore data back to the production environment are available only for GDPS Metro environments that use internal LCP.
|
There are two variations of restoring data back to production, as described next.
Restoring a FlashCopy capture
Scripting can be used to restore a capture that is taken to a FC copy set. The target of the LCP restore operation is the RS(n) volume set from which the capture was taken. The operation is shown in Figure 10-17.
Figure 10-17 FlashCopy restore to production
As shown in Figure 10-17, the RS1 devices are the Metro Mirror primary devices that were used by production before the data corruption event occurred. They also are the devices from which the FC captures were taken.
The LCP restore operation uses FlashCopy to copy the data back from the FCn copy set to the RS1 device set. The restore can consist of a full push of all of the data back to the production environment or the restore might be incremental such that only the data that changed since the backup was taken is copied back to production.
Whether the restore is a full push of all of the data or is incremental depends on the options that are used when the backup was taken.
After the restore is complete, the production systems can be IPLed from the RS1 devices.
The LCP restore operation is rejected if mirroring status is OK. Therefore, it might be necessary to stop Metro Mirror before attempting the LCP restore operation.
When the FC captures are taken from the Metro Mirror secondary devices (the RS2 device set in Figure 10-17) and are therefore, housed in the same disk storage system as the secondary devices, GDPS first converts the secondary devices to suspended primary devices before attempting the FlashCopy restore. After the restore process is complete, the production systems can be IPLed from the RS2 devices.
When restoring an FC capture, the source of the restore also cab be an RC copy set, which is possible only if the FC capture was taken directly from the RS(n) volume set. That is, if an FC or SGC capture is recovered to an RC copy set, that capture cannot then be restored back to the RS(n) volume set from the RC copy set.
The ability to capture a copy of production directly to an RC copy set and to restore the copy from the RC copy set back to the RS(n) volume set provides a minimal LCP environment where only one backup copy exists.
Restoring a Safeguarded capture
Scripting can also be used to restore a capture that was taken to a SGC copy set. The target of the LCP restore operation in this case is the device set that is the Metro Mirror peer to the device set from which the SGC captures are taken (see Figure 10-18).
Figure 10-18 Safeguarded Copy restore to production
As shown in Figure 10-18, the RS1 devices are the Metro Mirror primary devices that were used by production before the data corruption event occurred and the RS2 devices are the devices from which the SGC captures were taken. The LCP restore operation consists of first, recovering the wanted SGC capture to the RCn device set, and then, establishing a Global Copy relationship to incrementally copy the data back to the RS1 device set. After the restore is complete, the production systems can be IPLed from the RS1 devices.
The LCP restore operation is rejected if mirroring status is OK. Therefore, it might be necessary to stop Metro Mirror before attempting the LCP restore operation.
When the SGC captures are taken from the Metro Mirror primary devices (the RS1 device set that is shown in Figure 10-18), the target of the restore is the RS2 device set. Again, the target of the restore of a SGC capture is always the device set that is the Metro Mirror peer to the device set from which the SGC captures are taken. In this case, following the restore, GDPS updates its site indicator to point to the RS2 devices, which results in the RS2 devices being used for the subsequent IPL of the production systems.
10.4.2 Panels
In the previous sections, we discussed the scripting capability that is provided to manage the various copies in LCP and TCM environments. Because of the simplicity of TCM environment, little else is required beyond the scripting capability to manage the TCM environment.
However, LCP environments are more complex because they include greater numbers and types of copies and they include management profiles to govern the protection copies. As a result, more tasks are required to manage an LCP environment.
These extra tasks are performed by using the 3270 window interface or the GDPS GUI. This section describes the 3270 window interface. All of the functions and capabilities that are discussed are also available via the GDPS GUI.
Managing LCP management profiles
When the LCP feature is licensed and configured, option L is provided on the GDPS main window. Selecting option L from the GDPS main window displays the management profiles window, as shown in Figure 10-19.
Figure 10-19 VPCPMP00, LCP management profiles window
This window displays all the management profiles that are defined within each consistency group, within each replication site. In Figure 10-19, we see the following components:
•Two consistency groups exist in the same replication site (RS1). One consistency group is named PRODUCTI and one is named TEST.
•PRODUCTI has one user-defined management profile that is named GOLD_SGC_RS1 and it uses the SGC technology to capture the protection copies. PRODUCTI contains 12 volumes from the RS1 volume set, one SGC copy set, and two captures, both of which are expired.
•TEST has one user-defined management profile that is named SILVER_SGC_RS1 and it also uses the SGC technology to capture the protection copies. TEST contains four volumes from the RS1 volume set, one SGC copy set, and three captures, all of which are expired.
•Each consistency group has three unassigned FlashCopy Copy Sets with no active captures and each consistency group also has one recovery copy set (LCP automatically builds internal management profiles for recovery copy sets and unassigned FlashCopy copy sets).
Scrolling to the right on this window by using F11 displays the rest of the window, as shown in Figure 10-20.
Figure 10-20 VPCPMP01, LCP management profiles window continued
This window shows the date and time that the last protection copy was captured for each consistency group and what the retention period is for the protection copies in each of the consistency groups.
Entering S against the consistency group name on the LCP management profiles window requests that a new Safeguarded management profile be created and results in the window that is shown in Figure 10-21 being displayed.
Figure 10-21 VPCPMPAS, adding a Safeguard management profile
In this window, the user enters the following information for creating the Safeguard management profile:
Consistency Group The name of the consistency group with which the profile is associated.
Replication Site The replication site with which the profile is associated.
Management Profile A unique name identifying the profile.
Retention Period This is the minimum amount of time that a capture must be retained. The retention period can be specified in minutes, hours, or days.
Minimum Interval The minimum capture interval is the amount of time that must elapse before a new capture is permitted. The specified value must be equal to or less than the retention period. The minimum capture interval can be specified minutes, hours, or days.
Copy Set The SGC copy set assigned to the management profile.
The remaining three fields on this window (Reservation Time, Check In Time, and CG Pause Time) are related to the capturing of an SGC protection copy within this management profile. The process for capturing an SGC protection copy is made up of multiple steps and these fields allow you to specify the amount of time that LCP is allowed to run each step. This gives you control over how much of an impact the capture process has on your production applications or your disaster recovery RPO, depending on the specific type of LCP configuration that was implemented and the GDPS solution environment in which it was implemented.
In addition to creating a Safeguard management profile, the following options are available from the LCP management profiles window to allow you to manage your management profiles:
Info Displays information about a specific management profile.
Captures Lists all captures that are taken for the management profile.
Modify Modifies a management profile.
Delete Deletes a management profile.
The example that is shown in Figure 10-19 on page 317 and Figure 10-20 on page 318 was taken from a GDPS GM LCP environment, which does not support FC copy sets. For environments that support FC copy sets, the LCP management profiles window also provides an option to create a FlashCopy management profile.
Displaying information about captures
Entering C against the profile name on the LCP management profiles window (as shown in Figure 10-19 on page 317) allows you to list all captures that are assigned to the SafeGuard profile. The Safeguard captures window is shown in Figure 10-22.
Figure 10-22 VPCPLCS0, Safeguard captures window
The window is divided into two sections. The upper half of the window is static and provides summary statistics for the management profile. This information includes the date and time of the latest capture with the number of captures that are taken and number of that expired.
The lower, scrollable section of the window includes the following columns:
•Copy Set : The copy set number.
•Sequence Number : The sequence number that is used by the capture.
•Capture Date & Time : Displays the date and time of the capture in UTC format.
•Volume Count : Indicates the number of volumes that were included in the capture.
•Capture Flags : The following capture flags are available:
– Expiration: Capture expired flag
– Invalid: SafeGuard capture was invalidated
– Tagged: Capture is tagged (for more information about tagging captures, see “Tagging FC and SGC captures for recovery or restore processing” on page 324)
– Recovery: Capture is in use as the source of an LCP recovery
•PCD Count : The number of volumes that are flagged Pending Config Deletion in this copy set.
•S2D Count : The number of volumes that are flagged Safe to Delete in this copy set.
•CID Count : This is the number of volumes that are flagged Capture in Doubt in this copy set.
Regarding the last three fields, Pending Config Deletion, Safe to Delete, and Capture in Doubt are states that copy set volumes can be in during the process of removing the RS volume that is associated with the copy set volumes.
A similar window is available for listing the captures for a user-defined FC management profile.
LCP internally builds and maintains a management profile that is called UNASSIGNED for each replication site. The profile contains all FlashCopy Copy Sets that are not yet assigned to a user-defined FC management profile. Specifying C against the UNASSIGNED profile allows you to list all the unassigned FC Copy Sets in the replication site.
The Unassigned Captures window is shown in Figure 10-23.
Figure 10-23 VPCPLCU1, listing unassigned FlashCopy copy sets
Because these copy sets are not under LCP control, the capture flags nor the Flag-Set counts are reported.
LCP internally builds and maintains a management profile that is called RECOVERY to represent all of the RC copy sets that were defined for each replication site. Specifying C against the RECOVERY profile name lists all recovery copy sets in the replication site.
An example of the Recovery Captures window is shown in Figure 10-24.
Figure 10-24 VPCPLCR1, SafeGuard recovery via the SGC(1) copy set
The window that is shown in Figure 10-24 lists an RC copy set with a Recovery Type of Safeguard, which indicates that it contains an active recovery copy that was captured from a Safeguard copy set.
The recovery type can be one of the following states:
INACTIVE The recovery copy set is not in use.
DIRECT The recovery copy set was captured directly from an RS(n) volume.
SAFEGUARD The recovery copy set was captured by using a Safeguard capture operation.
FLASHCOPY The recovery copy set was captured by using a FlashCopy capture operation.
Because these copy sets are not under LCP control, the capture flags nor the Flag-Set counts are reported.
Displaying information about capture copy set volumes
Entering V against any type of capture lists all volumes that are configured to the associated copy set and their capture status. The Copy Set Volumes window for an SGC capture is shown in Figure 10-25.
Figure 10-25 VPCPLCSS, listing Safeguard capture volumes
The LCP Copy Set Volumes window is divided into two sections. The upper half of the window is static and provides summary statistics for the copy set. This includes the date and time of the capture and whether the capture is expired.
The scrollable section of the window contains the following columns:
•UCB : Indicates the UCB device number.
•Volser : The volume serial number.
•Safeguard Source : The serial number, logical subsystem, and channel connection address for the SafeGuard protected source.
•Sequence Number : The 8-byte sequence number that is used for the LCP capture.
•Safeguard State : The possible values for this field are:
– SafeGuarded: Y/N - the source volume is in a SafeGuarded relationship
– Reservation: In Progress or Complete
– Check In: Is Active - Long Busy
– Captured: Y - SafeGuard protected volume captured
– Invalidated: Y - SafeGuard capture has been invalidated
– Recovery: Y/N - volume is participating in a SafeGuarded recovery
•Backup tracks : The number of tracks that are stored on the SafeGuarded Virtual Backup Capacity.
•LCP Flags : The following flags are available:
– P: Y/N - Pending Config Deletion
– S: Y/N - Safe to Delete
– C: Y/N - Capture in Doubt
Tagging FC and SGC captures for recovery or restore processing
Before running a script to restore or recover a copy set, the copy set that is to be restored or recovered must be tagged. A capture can be tagged for restore or recover by entering a T against it on the Safeguard (or FlashCopy) Captures window. Figure 10-26 shows the same Safeguard Captures window as the window that is shown in Figure 10-22 on page 320; however, this time, one of the SGC captures is tagged for recover as indicated by the T capture flag having a value of Y.
Figure 10-26 VPCPLCS0, Safeguard capture is tagged
A capture can be untagged by entering a U against it on the Safeguard (or FlashCopy) Captures window.
A capture must be tagged, which identifies the source for the recovery operation. A recovery operation for a Safeguarded Management Profile without a tagged capture automatically tags the last closed valid Safeguarded capture.
|
Note: The latest capture is always the open capture and is not eligible for automatic tagging. The use of automatic tagging for Safeguarded captures requires that at least two captures exist. A capture that is flagged as invalid is not eligible for tagging. In this case, automatic tagging evaluates (and where possible) tags the next capture.
|
10.4.3 Securing the GDPS LCP environment
GDPS uses RACF XFACILIT and GXFACILI resource classes to enable you to create a role-based security model for controlling access to the resources in your GDPS LCP environment that is customized to your specific environment.
Simple definitions can be used to control access at the panel option level or more granular definitions can be used to control access to specific types of resources, or even all the way down to the specific resource level.
With the role-based security model, you can create your own roles or you can use the common roles that GDPS recommends that include GDPS Administrator, GDPS Operator, GDPS User, and Non-GDPS User. You define the resources that these roles can access and the type of access they have to those resources by granting them access to the resource profiles that represent the various resources in your environment. Finally, you can grant access to various resources to users by adding them to the suitable roles.
When you use the role-based security model, GDPS ensures that the user has sufficient authority to take a specific action against a specific resource, regardless of whether they are attempting to take the action by using the panels directly or by running a GDPS script.
10.5 Summary
Internal LCP provides a GDPS managed Continuous Data Protection capability and is aimed at helping clients to recover from logical corruption events, whether caused by internal or cyberattacks. It enables GDPS to regularly create one or more logical corruption protection copies of data by using the FlashCopy technology or the Safeguarded Copy technology. These copies can then be used for testing, recovery, or other analysis.
Internal LCP is self-contained within the GDPS Controlling systems; all actions are performed from the GDPS Controlling systems. Internal LCP copies are in the same disk storage systems as the production devices with which they are associated.
External LCP extends the internal LCP functionality by allowing clients to isolate these logical corruption protection volumes from the production environment by the inclusion of a Global Copy or Global Mirror relationship that is cascaded from the GDPS environment (the protection copies for LCP are then taken from these Global Copy target devices). External LCP requires another GDPS controlling system, called the LCP Manager Controlling system, to co-ordinate its activities.
Testcopy Manager is a function of external LCP that allows clients to manage, capture, and refresh a test copy for use within an isolated test environment. This new isolated copy is a FlashCopy that is taken from a Global Copy secondary volume set that is cascaded from a GDPS MGM 4-site environment.
With external LCP (including Testcopy Manager), the LCP copies are in different disk storage systems than the production devices with which they are associated.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.