z/os Multi-Site Business Continuity August, 2013

Transcription

1 Page 1 7/30/2013 z/os Multi-Site Business Continuity August, 2013 Robert F. Kern BOBKERN@US.IBM.COM,

2 Page 2 7/30/2013 Notices Copyright 2013 by International Business Machines Corporation. No part of this document may be reproduced or transmitted in any form without written permission from IBM Corporation. The information provided in this document is distributed AS IS without any warranty, either express or implied. IBM EXPRESSLY DISCLAIMS any warranties of merchantability, fitness for a particular purpose OR INFRINGEMENT. IBM shall have no responsibility to update this information. IBM products are warranted according to the terms and conditions of the agreements (e.g., IBM Customer Agreement, Statement of Limited Warranty, International Program License Agreement, etc.) under which they are provided. IBM is not responsible for the performance or interoperability of any non-ibm products discussed herein. The provision of the information contained herein is not intended to, and does not; grant any right or license under any IBM patents or copyrights. Inquiries regarding patent or copyright licenses should be made, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY USA Trademarks The following trademarks may appear in this Paper. AIX, AS/400, DS8000, Enterprise Storage Server, Enterprise Storage Server Specialist, ESCON, FICON, FlashCopy, Geographically Dispersed Parallel Sysplex, HyperSwap, IBM, iseries, OS/390, RMF, System/390, S/390, Tivoli, TotalStorage, z/os, and zseries are trademarks of International Business Machines Corporation or Tivoli Systems Inc. Other company, product, and service names may be trademarks or registered trademarks of their respective companies.

3 Page 3 7/30/2013 Abstract Clients look for ways to reduce their TCO, simplify operations, and provide better service to their customers. A trend in the area of Business Continuity today is that more and more clients are looking to develop multi-site Continuous Operations and D/R strategies, with the idea of switching which site production runs at on a regular basis. The concept of toggling between sites or doing site flip/flops is gaining more scrutiny. Most clients today who exploit toggling between sites do so with the full GDPS/PPRC HyperSwap functionality deployed with a Multi-Site Workload. This configuration provides the ability to perform switch sites in real time, with minimal interruption to the business. Another emerging trend is for clients with out of region data centers to start examining how they might also best accomplish the same business objective of switching sites or regions, while minimizing the impact to their business during the site switch operation.

4 Page 4 7/30/2013 Introduction This paper explores the various GDPS configuration deployments that clients have implemented to provide high availability/continuous operations locally and/or out of region disaster recovery protection. It also explores the trend towards trying to reduce D/R testing costs by moving toward a regular site switch or site toggle model. To do this, the paper will examine each of these aspects: 2 sites within metro/sysplex distance active/active (multi-site workload) with HyperSwap and parallel sysplex exploitation - non-disruptive flip/flop active/standby (single site workload) with HyperSwap and parallel sysplex exploitation - non-disruptive flip/flop possible with appropriate configuration and temporary performance impact. Applications that do not exploit sysplex incur an outage during the site move. Disruptive site switches are typically automated to minimize the outage duration. 2 sites beyond metro/sysplex distance or using asynchronous data replication. Disruptive switch but automated to minimize outage duration Active/Standby DB2 & IMS Application Disaster/Recovery at distance. Two separate Sysplexes at distance with application level Active/Standby across the two Sysplexes utilizing application specific software based data replication technology. 3 Site Configurations & benefits. 4 Site Configurations & benefits. The traditional two site model provides for Site 1 as the primary production site and Site 2 as the backup or remote recovery site. The regular site toggle model is a peer to peer relationship model where production can run at either site and switching sites for business reasons on a regular basis becomes the business norm. An active/active model, that enables a site switch with minimal performance impacts, can be realized by clients through the following: sysplex enabled applications deployment of a multi-site workload under GDPS/PPRC with HyperSwap. Duplication of all site resources across the two sites. As distances between sites increase, data replication must switch from synchronous to asynchronous techniques to avoid application performance impacts. In addition, parallel sysplex distances are typically determined by the acceptable CF Link performance for the various applications as well as the maximum STP Timer distances (200km maximum). With these types of configurations a site switch is possible, but

5 Page 5 7/30/2013 an automated sysplex wide IPL is required. End to end automation like GDPS can minimize the outage time to perform the site switch. This paper will discuss trends and directions in this arena for z/os. High Availability/Continuous Operations & Out of Region Disaster Protection IT Infrastructure Availability can be broken down into three pieces; High Availability, Continuous Operations and Disaster/Recovery. Each brings unique client requirements to clients when addressing Business Continuity. Through an understanding of the client business requirements in this arena, IBM can help tailor the right solution at the right cost point for any IT infrastructure. Business Continuity - Aspects of Availability High Availability Fault-tolerant, failureresistant infrastructure supporting continuous application processing Protection of critical business data Continuous Operations Non-disruptive backups and system maintenance coupled with continuous availability of applications Operations continue after a disaster Disaster Recovery Protection against unplanned outages such as disasters through reliable, predictable recovery Recovery is predictable and reliable Costs are predictable and manageable IBM Corporation Copyright IBM 2009

6 Page 6 7/30/2013 GDPS Solutions Overview GDPS (Geographically Disperses Parallel Sysplex) shipped originally in 1998 and introduced the concept of multi-site IT Infrastructure resource management, for the Sysplex. GDPS automation enhances the z/os base sysplex and parallel sysplex management to an end to end server, workload, and data, with a coordinated network switch solution of resource management within the same or across multiple sites providing continuous operations for clients. To accomplish this, GDPS automation interfaces with many different System z hardware & software interfaces to reduce the necessity of skilled personnel to perform various operations during a site switch. Some of these interfaces include: System z Hardware Management Console (HMC) to manage the System z hardware reconfigurations dynamically. (ex. CBU, Expend Lpars, System IPLs, etc.) Sysplex & STD Timer interfaces, CF Duplexing Interfaces DS8000 Data Replication Functions FlashCopy, z/os Global Mirror(XRC), Metro Mirror (PPRC), and Global Mirror Various z/os System Interfaces z/os integrated with various DS8000 Synergy items. GDPS is storage vendor independent as all major storage vendors on the System z platform can participate in solutions using their implementation of the IBM DS8000 Disk Storage Subsystem data replication architecture of Metro Mirror, FlashCopy and zgm (XRC). New features and functions are developed with the IBM Systems Storage team on the DS8000. IBM sells the Host to Storage Subsystem architecture to the other storage vendors. Those vendors then implement the feature/function on their disk subsystems based on the Host to Disk Storage Subsystem architected interfaces. So, the disk storage subsystem internal processing for a feature or function may be different from one vendor to another. Depending on the specific feature/function there generally is some time where the feature/function is only available on the DS8000. One should consult with each storage vendor to understand specific feature/function support for any DS8000 storage subsystem enhancement. In addition, the GDPS automation inter-operates with all major system automation packages available for System z. Relative to Business Resiliency/Business Continuity, IBM s Flagship product is GDPS. GDPS comes in a variety of different flavors/solutions. The following two charts illustrate the various solutions.

7 Page 7 7/30/2013 GDPS provides an entry level solution called GDPS HyperSwap Manager, focused on providing the HyperSwap availability solution for z/os on the same data center floor or across two local area data centers up to 200km with Parallel Sysplex. GDPS/PPRC HyperSwap is the Full Function version of HyperSwap Manager, which can be easily upgrade to. The full function GDPS/PPRC HyperSwap supports zvm and zlinux data along with z/os data. In addition to masking disk subsystem failures the full function version, exploits parallel SYSPLEX to mask CEC failures, persistent sessions to coordinate a network switch, CF Duplexing to manage CF structure failures and VTS PtP to mask tape subsystem failures. Finally, if the failures evolve into a disaster scenario, GDPS provides a complete end to end site failover/fallback capability for both planned and unplanned site switches. One mouse click and the server, data, workload and a coordinated network site switch are performed via automation. All data is recovered, the SYSPLEX IPL ed, data bases restarted followed by the applications. Skilled personnel are no longer required to get the Sysplex up and running in the event of a disaster. GDPS/GM (System z & Open Systems data) & GDPS/XRC (z/os & zlinux only) provide site failover/failback (FO/FB), typically out of region exploiting IBM s Global Mirror and zgm (XRC) data replication technologies. GDPS/MzGM and GDPS/MGM provide a combination of high availability/continuous operations locally coupled with out of region D/R protection. All GDPS solutions are fully automated, proven, auditable, and in the case of PPRC and zgm (XRC) storage vendor independent!

8 Page 8 7/30/2013 The various GDPS solutions also support zvm and zlinux data through a feature call x/dr. The GDPS System z umbrella also includes the ability for GDPS automation to interoperate with System p, x, i (Linux), Windows, HP and Sun through the GDPS/DCM (Distributed Cluster Manager) automation inter-operability code feature that works in conjunction with Tivoli System Automation Application Manager (SA Appman) and/or the Symantec Vertias Cluster Server Solutions. With GDPS and the x/dr and/or DCM features, a single mouse click can yield a coordinated site failover/fall back of all of the customers systems. (ex. System z (z/os, zlinux, zvm) coordinated with say System p AIX systems). The disk replication functions can be managed separately with the GDPS and DCM automation or together, depending on the clients requirements for cross platform data consistency. GDPS is build upon the IBM DS8000 Storage based data replication architecture for FlashCopy, Metro Mirror, z/os Global Mirror and Global Mirror. As new features and functions are implemented in the DS8000, GDPS automation is modified to exploit those features and functions. In addition, GDPS supports various DS8000 base box features used in conjunction with the various advanced functions. IBM DS8000 Metro Mirror and Global Mirror support a function known as Open Lun Support, such that through an ECKD device address, GDPS automation is able to manage the Metro Mirror and/or Global Mirror functions for a distributed system Lun(s). This is also true for Metro Global Mirror configurations. With the Open Lun support, GDPS can provide a single restart point across the platforms. More systems and data replication alternatives will continue to be provided in the future based on client requirements. This is especially important for clients that have Multi-Platform Applications where transactions are for example initially received by a Windows system, then routed to say an AIX system and then to the backend z/os System. Each system may save data and as a result to recover the application, multiple platforms must be recovered to the same point in time. GDPS inter-operability with IBM PowerHA solutions, Tivoli Application Manager (AppMan) cluster solutions and/or Symantec Veritas Cluster Server (clustered solutions) can provide such a solution for clients.

9 Page 9 7/30/2013 Open Lun Support is also important for clients with applications like SAP where the user interfaces are typically on non System z platforms and the backend data base runs on z/os. In some cases clients have moved the application s parts that were running on non- System z platforms to zlinux, but many clients resist introducing the risk of any change to critical production applications that have been running for some time. Open Lun Support can provide a data consistency solution for multi-platform application(s). All data is recovered to a single point in time enabling each platform s data base to perform a data base Restart operation instead of a data base Recover operation when a site switch occurs. The data base restart process manages all in flight and in doubt transactions, which in turn permits the application(s) parts spread across the different platforms to resume processing from the restarted point in time forward. GDPS automation when combined with the Distributed Cluster Manager (DCM) automation feature can interoperate across the enterprise to provide a complete business solution for clients in the area of IT business continuity. This critical business function is made possible by the DS8000 open Lun support.

10 Page 10 7/30/2013 Two Local Data Centers - 2 sites within metro/sysplex distance The full GDPS/PPRC HyperSwap implementation can be configured as an active/active multi-site workload or active/standby single-site workload providing real time planned and unplanned site switches mode through the deployment the following features/functions: - Parallel Sysplex permits the movement of a workload from one processor at site 1 to an alternate CEC in site 2. - Sysplex enabled Applications. (required for multi-site workloads) - HyperSwap permits the ability for disk access to switch from a Metro Mirror Primary volume(s) to the target volume(s) and reverse the mirror without an IPL of the parallel Sysplex. - VTS Peer to Peer Tape configuration permits real time tape mirroring across multiple physical Tape libraries without interrupting operations. - Multiple Sysplex Timers permit timer switches in real time. - CF Duplexing permits the switching of data structure access in real time. - The concept of persistent sessions enables real time network switches. Some customer applications have affinities. (e.g., all transactions for a given type must be routed to a specific system, one transaction passes information onto the next transaction, etc.). A sysplex enabled application requires that all affinities be removed so a transaction can be routed to & execute on any clone of the application on any system in the sysplex. When this is done, the application can then be run in an active/active, multi-site workload configuration. Transactions can be distributed to run on any system within the Sysplex, independent of their physical location. Through the GDPS automation, more and more clients perform both Planned and Unplanned site switches on a regular basis. Planned site switches are used to minimize the production risks associated with site or equipment maintenance. Once a lights out data center opens its doors for maintenance operations, the possibility exists for production impacts. These can be minimized by switching production to the alternate site in real time with a multi-site workload configuration. Providing the ability for a client to exploit this type of operational functionality has spurred clients to think of new approaches and new business exploitations of the technology.

11 Page 11 7/30/2013 GDPS/PPRC: a Continuous Availabilty and/or Disaster Recovery Solution NETWORK - Metropolitan Distance NETWORK SITE 1 SITE 2 Manages Multi-Site Parallel Sysplex, Processors, CBU, CF, Couple Data Sets Manages Disk RC (System z & open LUN) Manages Tape Remote Copy (PtPVTS) Exploits Hyperswap & FlashCopy Function Automated planned and unplanned actions (z/os, CF, disk, tape, site) Improves availability of heterogeneous System z business operations Planned and unplanned exception conditions 38 IBM Systems 2008 IBM Corporation The above diagram shows a high-level view of the GDPS/PPRC topology. The physical topology of a GDPS/PPRC consists of a base or Parallel Sysplex cluster spread across two sites (known as site 1 and site 2) with one or more z/os systems at each site, separated by up to 200 kilometers (km). The multi-site sysplex must be configured with redundant hardware (e.g., a Coupling Facility and a Sysplex Timer in each site) and the cross site connections (typically dedicated or dark fibre) must be redundant. All critical data is mirrored from the primary site (site 1 in this diagram) to the secondary site (site 2). All Shared CF structures are located on the primary site coupling facilities. Therefore, when transactions are executed on the processors at the remote site, disk I/O and Shared CF structure access is through links from the secondary site to the primary site and the disk I/O and CF structure updates are then mirrored in a synchronous manner back to the remote site. This adds additional overheads to the applications disk I/O as well as any access to shared CF structures. Before a customer elects to deploy a multi-site configuration, he must first insure that his applications are sysplex enabled after which careful consideration must be given to the system & application performance impacts of these two accesses when a transaction is executed at the remote site. In many cases the application performance impact will limit the effective distance that an active/active configuration can actually sustain. For disk I/O the performance impact of Metro Mirror rule of thumb: 1. Disk Subsystem overhead of MM at zero distance + (plus)

12 Page 12 7/30/ speed of light through dedicated dark fibre for a single protocol exchange (linear function of 1ms/100km or.1ms/10km) x (times) 3. the # of protocol exchanges implemented in the specific MM disk to disk implementation (for IBM DS8000 MM, a single protocol exchange is accomplished through a feature called predeposit write) + (plus) 4. other device overheads that may be on the fibre path. (ex. Switches, DWDMs, compression and/or encryption devices, channel extenders, etc.) For CF single latency rule of thumb: Signal latency impact (round trip) = 10 US/KM * fiber distance KM * # of protocol exchanges Example: assume two sites separated by 10 KM and a processor in site 1 is accessing disk in site 2, signal latency impact = 10 US/KM * 10 KM * 1 (FICON has one protocol exchange) or 100 US impact Terminology: Kilometer (KM) one KM equals 5/8 mile Millisecond (MS) 10**-3 Microsecond (US) 10**-6 For most clients, the impact of CF single latency beyond km (25-30 miles) yields too great of application impact. Because of this, GDPS/PPRC multi-site implementations typically tend to be campus or metro distances. If customer applications are not sysplex enabled and/or the application performance impact of a multi-site configuration to too great, then the choice for these clients becomes GDPS/PPRC w/hyperswap in a Single-site (active/standby) configuration. In this configuration, all hardware can be duplicated across the two sites. The secondary site processor typically will run the GDPS control system typically referred to as the k- sys. Both a planned and unplanned site switch will involve the re-ipl of all systems in the Sysplex at the recovered site having had automation recover and switch all dependent resources. GDPS/PPRC prerequisites include NetView and System Automation for z/os. GDPS automation also interacts with any existing automation products. With a multi-site Parallel Sysplex, this provides a Continuous Availability/Continuous Operations and a Disaster Recovery solution. In addition, GDPS provides set of panels for standard actions as well as the ability to customize scripts for an installation. GDPS/PPRC Multi-site sysplex. At least one system in Site 2 is in the site 1 production Sysplex. All production can run in site 1, the GDPS K-sys runs in site 2 or production can run in either or both site 1 & 2. Sysplex timers and CFs are in both sites. Two (for availability) fiber trunks are recommended to connect both sites, For unplanned reconfigs, system failures, processor failures, systems can be restarted in place or on the other site depending upon how they are defined.

13 Page 13 7/30/2013 GDPS/PPRC Single-site sysplex. All production images run at the primary site. The GDPS K-sys typically runs at site 2 and all resources are typically available at both sites. Sysplex timers and CFs are in both sites. Two (for availability) fiber trunks are recommended to connect both sites The following outlines the typical resources available at each site for GDPS/PPRC w/hyperswap. Base Sysplex or Parallel Sysplex environment Manages unplanned reconfigurations z/os, CF, disk, tape, & coordinates network connections Designed to maintain data consistency and integrity across all volumes Fast, automated site failover No or limited data loss Single point of control for Standard actions Stop, Remove, IPL system(s) Parallel Sysplex Configuration management Couple data set (CDS), Coupling Facility (CF) management User defined script (e.g. Planned Site Switch) PPRC Configuration management 2 Sites Beyond Metro/Sysplex Distance GDPS solutions beyond metro/sysplex distance include GDPS/XRC and GDPS/GM). Clients select either the XRC or GM data replication technique based on their specific requirements. XRC provides for the lowest possible RPO and only supports z/os, and zlinux data. Global Mirror provides for a tunable RPO (3-5 seconds to 18 hours) and supports all System z and distributed systems data. With asynchronous data replication solutions a site switch will require an automated Sysplex wide IPL. Asynchronous data replication can support a Planned Site Switch with no loss of data, but to do this the applications must be shut down. Storage based data replication technology today supports planned site Failover/Failback scenarios such that only changed data need be copied back to resync the sites. This capability is available today with the various flavors of GDPS 2-site and 3-site solutions. But, in

14 Page 14 7/30/2013 each case a Sysplex wide IPL, data replication disk/tape switch, and a client end user network switch must be done in a coordinated manner. In this way the Sysplex is restarted as well as all data bases and application(s) workloads at the remote site. When the various data bases are restarted, In Flight and In Doubt transactions are resolved as well as a rebuild of any and all coupling facility structures. If a planned outage can be tolerated by the client, then switching sites on a regular base can help to minimize costs involved with D/R testing. Planned site switches can verify that all the resources required to run the application are available in both sites. This can then be fully tested to insure that enough capacity (Processor, storage, network, etc) is available at both sites for any and all combinations of the workload. In addition, a client is testing the complete production application(s) end to end. Often, traditional D/R tests only verify that the system platform can be ipl ed and based on time available some minimal subset of the production workload is executed. The best D/R test can be executed by a site switch that in fact leaves production to run in each site for a reasonably long period of time. (ex. 3-6 months) During this time, the application typically has gone through various periods of the business cycle including end of day, end of week, and end of quarter processing. Through careful planning, one can eventually verify that all application processing can be executed independent of site. This approach fits into some business models better than others. In some countries a physical site utility check is required once a year. This requires a full electrical shutdown. Therefore a site switch to the other production site may be easier in this environment as the outage is minimized to the time to perform the site switch and have the application(s) back up and running rather than also including the time to verify all utilities at the original production site. The simple approach to insure that a client can easily switch sites and run all applications with similar performance, scalability and capacity growth is to duplicate all hardware and software resources across both sites. If a client currently has deployed a 3-site GDPS configuration with GDPS/PPRC HyperSwap locally at the production site, one would also want to deploy the same configuration at the target sister production site. This is called a 4-site configuration and is pictured below. The emerging thoughts are that money currently spent on Disaster Recovery Testing could be decreased, if one could provide on a regular basis, the ability to switch back and forth across sites in an automated fashion. When implemented, planned site switches provide this function. That means that D/R testing need only verify that the unique automation required to perform a site switch for an unplanned scenario also works. Customers minimize the differences between planned and unplanned site switch scenarios today by deploying the Test the Way we Recover and Recover the way we test model. Typically today, several clients D/R testing is done at the remote site while maintaining full D/R protection. This is done by making a PiT FlashCopy of the data and performing all D/R testing against that copy of the data. When a disaster occurs, as part of the recovery process, a FlashCopy of the data is created and used for the D/R recovery process. This minimizes unique actions between a planned and unplanned site failover scenario.

15 Page 15 7/30/2013 In both the planned and unplanned site switch scenarios, GDPS automation can minimize the time of the outage or the RTO. GDPS automation can also help to minimize the risk of performing a site switch as the automation is proven, repeatable and minimizes human errors. The Recovery Time objective is a measure of the time it takes from the time that a planned or unplanned site switch is identified until all applications are up and running at the remote site. A key benefit of GDPS automation is that, once implemented, the RTO is a known proven, repeatable quantity. GDPS/Active/Standby - Application by Application Availability: If all of a client s application data is within a single data base (DB2 and/or IMS), clients can implement high availability across two sites on an application by application basis rather than managing high availability/disaster protection on a platform(s) basis. GDPS/Active/Standby automation enables automated application level site switches that typically provides an RTO on the order of seconds to minutes. Clients use DB2 to DB2 software data replication with IBM Tivoli Infosphere Replication Server for z/os and/or IMS to IMS software data replication with IBM Tivoli Clasic Infosphere Replication for z/os.. In this case the DB2/IMS log entries are replicated between sites by DB2/IMS. An active z/os image with a copy of the DB2/IMS data base is running at the remote site and all DB2/IMS updates are applied when received. In the event of a disaster or a planned site switch for this application, the end user network is switched to route active transactions to the remote site for processing with minimal data loss. The routing of transactions managed by the IBM Workload Distributor software. This approach typically also requires the client to implement a strict change control process across all systems to insure that the various system components are always updated in step to keep the z/os images in sync. The following picture outlines the GDPS/Active/Standby solution.

16 Page 16 7/30/ Site Configurations Several clients with an out of region D/R implementation or with high availability locally have moved to a 3-site configuration by implementing either GDPS/MzGM w/hyperswap or a GDPS/MGM w/hyperswap. These configurations provided local high availability/continuous operations environments providing local real time planned site switch scenarios as well as site failover/failback functionality for a local site disaster with an RPO of zero. Some clients, implement their 2 nd local site on the same data center floor, or across a fire wall on the same data center floor. A few customers have just implemented HyperSwap locally to avoid a disk subsystem failure from causing a Sysplex wide outage. In all cases, the implementation focus was on increasing availability of IT to the business locally or adding out of region D/R protection. One key cost component on developing a multi-site solution is the duplication of the client s end user network. Depending on the complexity and cost associated with replicating the end user network, several clients prefer to implement a 3-site solution across only two physical sites. At this time, IBM has deployed some 86+ GDPS/MzGM w/hyperswap or GDPS/MGM with HyperSwap multi-site configurations. The following figures outline these implementations.

17 Page 17 7/30/2013 GDPS/MzGM w/hyperswap & Incremental Resync Site1 CF1 K1 K1 P1 P2 bkup Unix Data Replication A->B & A -> C Incremental resynch B C if Site1 or A-disk fails Maintains disaster recovery position A Improved RTO ETR or STP Metro Mirror KgB z/os Global Mirror Incremental Resync A C SDM Kx A F CF2 Site2 K2 K2 P1 bkup P2 Optional: CFs / Prod systems in Site2 Recovery Site 57 IBM Systems 2008 IBM Corporation SDM Kx P1 Bkup P2 Bkup CF1 F Recommended for FlashCopy The standard GDPS/MzGM HyperSwap with Incremental Resync configuration enables data replication from A -> B with HyperSwap and z/os Global Mirror data replication from A -> C. On an A->B HyperSwap event, the Incremental Resynchronization for GDPS MzGM enables the reestablishment of the z/os Global Mirror session from A->C to B->C. GDPS manages the z/os Global Mirror sessions, so that only changed tracks need to be sent to the recovery site instead of requiring a full-volume copy to reestablish the disaster recovery copy. This can greatly reduce the time required (in some cases from hours down to minutes) to reconnect to your remote site, reducing the risk of not being protected

18 Page 18 7/30/2013 GDPS/MGM w/hyperswap Site1 CF1 Kp K1 Kp P1 P2 bkup Kg Non -z GM K-Sys runs in production LPAR HyperSwap protection Reduced resource requirement Kg A ETR or STP CF2 Site2 KP KP P1 bkup Metro Mirror P2 Kg Kg KgB Non -z Global Mirror A C CF3 R R A D P1 Bkup A F P2 Bkup Non-z Bkup Recovery Site F Recommended for FlashCopy 54 IBM Systems 2008 IBM Corporation The standard GDPS/MGM w/hyperswap configuration provides data replication from A->B->C. The ability to run the GDPS/GM Ksys in a GDPS/PPRC production system, reducing the number of z/os images required for an MGM configuration. (Kg) Incrementally resync A->C if Site2 or B-disk fails Requires A->C bandwidth GDPS/GM K-sys runs in a production system HyperSwap protection for GDPS/GM K-sys Reduced resource requirement Maintain disaster recovery position following resync Improved RPO The Kg System lives in P2. P2 is a production system. It runs GDPS/PPRC in one Netview. In another Netview it runs the GDPS/GM Ksys function. P2 disk is PPRCed and protected by HyperSwap. This includes any disk that is related to the "Kg system function". P2 is a production system that can live in either Site 1 or Site 2. It has Kg system as it's parasite. When you move P2, the Kg system function will be moved with it.

19 Page 19 7/30/ site configurations provide additional options as well as considerations when performing site switches. 1. If the two local sites are physically separated for both high availability and local D/R protection, when a remote site switch occurs is it still requirement to have two local sites physically split at that location as well? The alternatives would be to have two logical sites within the same physical site, perhaps separated by a physical fire wall. In the site toggle model this consideration may be very different than if the remote site is only used in the event of a disaster. In the disaster site scenario, when a disaster occurs, high availability may be added to that site after the business is back up and running again. The site toggle model views all sites as production ready sites, where as the disaster/recovery site model views the remote site as only being actually used in the event of a disaster. Both models are valid, and really vary based on the client s business requirements. 2. A complete understanding of the various fallback scenarios and additional copies of the disk required to support each of these scenarios should be investigated and understood with both the GDPS/MzGM and the GDPS/MGM options. 3. as mentioned above, end user Network connectivity to each data center can definitely influence the costs associated with the ultimate solution. 4-Site Configurations Several clients with an out of region D/R plus a high availability locally 3-site implementation have now moved to a 4-site configuration by implementing extending either GDPS/MzGM w/hyperswap or a GDPS/MGM w/hyperswap with a Global Copy implementation at the remote region which is then converted to a HyperSwap implementation on a region swap. A 4-Site configuration provides the exact same functionality at the target region (High Availability + Disaster Recovery protection) on both a planned and when possible, unplanned region switch. In addition, on a region switch, the ability to use asynchronous data replication back to the original production site is implemented. With this functionality, both sites provide the business equal functionality and enables a peer region configuration. The next three pictures outline 1) typical customer 4-site requirements followed by the 2) a 4-site implementation with IBM DS8000 Metro Mirror/zGM (XRC) and 3) Global copy as well as Metro Mirror/GM and Global Copy.. 4-Site solutions can be implemented today with GDPS a server/workload, data with a coordinated network switch solution, as well as TPC/R for a data only solution.

20 Page 20 7/30/2013

21 Page 21 7/30/2013 Distributed Systems As mentioned earlier in this paper, with the GDPS/DCM capability, GDPS automation can inter-operate with the IBM PowerHA solutions as well as the Tivoli Application Manager or Veritas Cluster Server solutions to provide end to end automated management of various distributed platforms in 2-site or 3-site configurations. Cross System data consistency can also be provided via the DS8000 open lun support. With this function, GDPS can provide a common restart point across all z/os and distributed systems data. Today, high availability of data is provided through distributed systems software mirroring typically called LVM Mirrors. Data availability for disaster recover can be provided through hardware and software based data replication functions. Functionality in this arena will continue to evolve as clients develop more and more cross platform applications. Future Vision The next chart outlines the evolution from a single server into an Enterprise Wide Business Continuity Solution. Single Servers, became clustered servers, clustered servers then spanned physical sites. This was then extended to end to end multi-site heterogeneous clusters, followed by integrated end to end multi-site clusters. The emerging trend for z/os is next toward multiple application level Active/Active Sites at distance coupled with the traditional platform based high availability and disaster/recovery solutions.

22 Page 22 7/30/2013. Conclusion The requirements for real time high availability, continuous operations and disaster recovery for z/os as well as distributed systems continue to push IBM to provide 24x7 computing environments with superior business resilience functionality. New Smarter Planet applications typically deal with real time data that needs to be captured, stored and analyzed in real time on a 24x7 basis. These applications and volumes of data also introduce new requirements in scalability as well as challenges in total cost of ownership. The management of IT Operations across a single site or multiple sites locally or at distance, presents the opportunity to optimize all compute resources to maximize their utilization, as well as enable them to meet the business requirements of the end user clients today and tomorrow. Emerging trends to enable applications and their platforms to be virtualized and run across physical data centers located around the world is the ultimate goal. The z/os platform, coupled with GDPS automation has become the leading edge of general purpose solutions towards this end...

23 Page 23 7/30/2013 Author Bob Kern - IBM Advanced Technical Support America s ( bobkern@us.ibm.com). Mr. Kern is an IBM Master Inventor & Executive IT Architect. He has 40 years experience in large system design and development and holds numerous patents in Storage related topics. For the last 30 years, Bob has specialized in disk device support and is a recognized expert in continuous availability, disaster recovery and real time disk mirroring. He created the DFSMS/MVS subcomponents for Asynchronous Operations Manager and the System Data Mover. Bob was named in 2003 a Master Inventor by the IBM Systems & Technology Group and is one of the inventors of Concurrent Copy, PPRC, XRC, GDPS and zcdp solutions. He continues to focus in the Disk Storage Architecture area on HW/SW solutions focused on Continuous Availability, and Data Replication. He is a member of the GDPS core architecture team and the GDPS Customer Design Council with focus on storage related topics.