z/OS Basic HyperSwap
Basic HyperSwap is a z/OS high availability feature that is available with the DS8000 storage system. It provides the capability to switch host I/O operations transparently without application outage, between Metro Mirror primary and secondary volumes. The switch can be either planned (for maintenance) or unplanned (as a result of a primary storage system failure, for example).
This chapter describes the z/OS Basic HyperSwap functions. It provides a short overview and describes some of the sequences of HyperSwap operations.
This chapter includes the following topics:
29.1 z/OS Basic HyperSwap overview
Basic HyperSwap is a high availability function that cooperates with DS8000 Metro Mirror and IBM Copy Services Manager for z Systems former known as Tivoli Productivity Center for Replication (TPC-R) for z Systems. For this purpose, a limited version that is designated as the Copy Services Manager Basic Edition for z Systems is available for the z/OS operating system at no additional cost, apart from a small maintenance fee.
This section provides an overview of Basic HyperSwap, explains how it works, what its benefits and requirements are, and where you can find more information about it.
|
HyperSwap support: Copy Services Manager Basic Edition supports only the session types Basic HyperSwap and FlashCopy. You need the fully licensed version of Copy Services Manager for z Systems to use its disaster recovery capabilities. The following Copy Services Manager session types support Basic HyperSwap:
•Basic HyperSwap
•Metro Mirror with Failover/Failback
•Metro-Mirror Metro-Mirror
•Metro/Global Mirror
•Metro/Global Mirror with Practice
|
Basic HyperSwap relies on Copy Services Manager for its configuration and management. Support for Basic HyperSwap is now available with Copy Services Manager running on any of the supported platforms.
|
TPC-R, Copy Services Manager, and high availability: You can run Copy Services Manager in a high availability configuration, with the active Copy Services Manager server running on z/OS and the standby server on another platform, as with Linux, AIX, or Windows. If there is an outage of the active instance, the standby server can take over. In this situation, you cannot change the HyperSwap configuration because Copy Services Manager for example on Linux cannot communicate the changes to z/OS. The HyperSwap capability itself does not depend on Copy Services Manager; it is a pure z/OS function and is not affected.
The minimum version for non z/OS platform support is Tivoli Storage Productivity Center for Replication V5.2 plus APAR OA40866 with R13 and later. Both instances of Tivoli Storage Productivity Center for Replication or Copy Services Manager must be at the same service level.
|
29.1.1 Benefits and positioning
Basic HyperSwap for z/OS is enabled by Copy Services Manager for z Systems and can provide a low-cost, high availability disk solution that allows the configuration of disk replication services by using an intuitive GUI from z/OS. It extends Parallel Sysplex availability to the disk systems.
Unplanned Basic HyperSwap masks primary disk storage system failures by transparently switching to the secondary disks. Planned Basic HyperSwap can be performed to complete disk maintenance without quiescing applications.
The Basic HyperSwap session type is not a disaster recovery solution. Copy Services Manager Basic Edition for z Systems does not include the capability to maintain recovery data consistency and is a single site solution only. It is not designed to handle Metro Mirror link failures that can occur in cross site configurations.
However, Metro Mirror with Failover/Failback and HyperSwap session, which is managed by Copy Services Manager or Copy Services Manager for z Systems platforms, provides both high availability and disaster recovery automation.
There is some overlap between z/OS Basic HyperSwap and GDPS/PPRC HyperSwap Manager. The following list contains the most significant advantages of the GDPS solution:
•Support for other vendors’ storage systems
•Support for z/VM and Linux on z Systems
•Support for open—fixed-block architecture (FB)—and mainframe—count key data (CKD)—disks in the same consistency group
•Seamless upgrade path to full-featured GDPS/PPRC and beyond
For more information about the available GDPS offerings, see Chapter 27, “IBM Geographically Dispersed Parallel Sysplex” on page 319.
29.1.2 Sources of information
You find more information about z/OS Basic HyperSwap in the following publications:
•IBM DS8000 and z/OS Basic HyperSwap, REDP-4441
•IBM Tivoli Storage Productivity Center for Replication for System z, SG24-7563
•Securing IBM HyperSwap and IBM Tivoli Storage Productivity Center for Replication Communication Using AT-TLS, REDP-5061
Complete documentation of Basic HyperSwap related commands and messages are available in the MVS section of z/OS IBM Knowledge Center:
29.1.3 Setup
Basic HyperSwap consists of a set of functions that interact with the z/OS I/O Supervisor (IOS) to perform swaps of devices on a mass scale. HyperSwap functions are performed in parallel for each logical subsystem (LSS) in the Metro Mirror configuration.
z/OS provides two address spaces, the Basic HyperSwap Management address space (HSIB) and the HyperSwap API Services address space (HSIBAPI), which perform all HyperSwap related activities, such as:
•Monitoring the device and Metro Mirror states
•Enabling or disabling HyperSwap based on these states
•Listening for HyperSwap triggers
•Performing the swap itself, including the necessary Metro Mirror operations
These address spaces are started as started tasks, for more information about the address spaces, see IBM Copy Services Manager Installation and Configuration Guide, SC27-8543.
You define and enable a Metro Mirror session with HyperSwap support through Copy Services Manager. When all Metro Mirror volume pairs reach the FULL DUPLEX state, Copy Services Manager passes the Copy Services configuration over to HyperSwap management address space, which then distributes the configuration to all participating z/OS images within the same Parallel Sysplex.
After the configuration load process finishes successfully, IOS with the HyperSwap address spaces is responsible for HyperSwap events. Copy Services Manager or TPC-R is not required any longer for HyperSwap operations, but can be used to initiate a planned HyperSwap. The HyperSwap address spaces issue all the required Metro Mirror commands to handle and manage a HyperSwap if there is an unplanned disk systems outage.
A HyperSwap configuration always involves the whole Parallel Sysplex. Therefore, the HyperSwap address spaces must be running in all images. They communicate with each other through the cross-system coupling facility (XCF).
Figure 29-1 illustrates the system structure of a Basic HyperSwap configuration.
Figure 29-1 Copy Services Manager on z/OS system overview
A HyperSwap can be performed only on a Metro Mirror configuration that is in the DUPLEX state. The primary volumes and Metro Mirror are continuously monitored for events that might trigger a HyperSwap, such as:
•A permanent I/O error on a primary volume triggers a HyperSwap for all devices in the configuration file.
•A planned HyperSwap, started through a Copy Services Manager or a z/OS system command for maintenance.
•A Metro Mirror status change causes Basic HyperSwap to be disabled. Basic HyperSwap is re-enabled when the Peer-to-Peer Remote Copy (PPRC) devices are back in the FULL DUPLEX state.
29.2 z/OS Basic HyperSwap sequence
This section explains how HyperSwap works by describing the sequence of events that comprise a HyperSwap event.
A HyperSwap is a staged process that happens in phases. When a z/OS image detects a HyperSwap trigger, it propagates a HyperSwap start request to all participating z/OS images within the Parallel Sysplex. Each z/OS image then performs the HyperSwap operation. One of the z/OS images in the Sysplex has the role of a master system, which verifies that all participating systems successfully finish the swap process.
A planned HyperSwap is triggered by Copy Services Manager or a z/OS system command. Copy Services Manager does not play an active role after you issue the trigger event to IOS. IOS handles and manages all further activities:
1. Validates I/O connectivity (can the secondary devices be accessed?).
2. Freezes and quiesces the DASD I/O.
3. Fails over Metro Mirror.
4. Swaps Unit Control Blocks (UCBs).
5. Resumes DASD I/O.
6. Soft Fences the former primary devices to prevent accidental online activation if the z/OS system has an IPL or unexpected accesses by systems outside of the current sysplex.
7. Unfreezes.
|
Note: The Soft Fence function requires DS8000 Microcode Rel. 7.1 and later plus APAR OA41388. The TPC-R or Copy Services Manager version is not relevant.
|
The freeze (step 2) ensures an I/O quiesce to all the involved primary devices. Then, IOS performs the actual swap operation and exchanges the primary with the secondary device addresses in the UCBs.
If there is an unplanned HyperSwap, Copy Services Manager is not involved. z/OS, or more precisely IOS with the help of the HSIB address spaces, handles the unplanned HyperSwap. When IOS detects a permanent I/O error on a primary volume, it stops all application I/Os and performs the swap.
After the swap is complete, IOS reissues any failed operation and resumes normal I/O. Transparent to the application, I/O is now performed against the former Metro Mirror secondary volumes. Their new Metro Mirror state is Primary Suspended.
Figure 29-2 on page 348 shows the status after a successful HyperSwap operation. The volumes in Site 2 are in the Primary Suspended state and are now the active or host volumes. HyperSwap is disabled because Metro Mirror is suspended.
Figure 29-2 After a successful HyperSwap
You can re-enable Metro Mirror in the reverse direction (Metro Mirror failback) by using Copy Services Manager or TPC-R (Start_H2_H1 operation). HyperSwap is automatically enabled after the resynchronization is complete and all Metro Mirror relationships are in the Full Duplex state. In this phase, the volumes in Site 2 are in the Primary Duplex state, and the volumes in Site 1 are in the Secondary Duplex state.
If you want to return to the original replication configuration, you can perform another planned HyperSwap.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.