“z/OS Multi-Site Business Continuity” September, 2012

9/11/2012
2 © Copyright IBM Corporation, 2012
“z/OS Multi-Site Business Continuity”
September, 2012
Robert F. Kern
E-mail: BOBKERN@US.IBM.COM,

9/11/2012
Notices
Copyright © 2012 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 10504-1785
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.

9/11/2012
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,
while minimizing the impact to their business during the site switch operation.

9/11/2012
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.
Future vision.
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

9/11/2012
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.
6 © 2009 IBM Corporation Copyright IBM 2009
Business Continuity - Aspects of Availability
High Availability
Fault-tolerant, failure-
resistant infrastructure
supporting continuous
application processing
Continuous Operations
Non-disruptive backups and
system maintenance coupled
with continuous availability of
applications
Disaster Recovery
Protection against
unplanned outages
such as disasters
through reliable,
predictable recovery
Protection of critical business data
Recovery is predictable and reliable
Operations continue after a disaster
Costs are predictable and manageable
GDPS Solutions Overview

9/11/2012
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.

9/11/2012
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!

9/11/2012
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 inter-
operate 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 Tivoli AppMan and/or
Symantec Veritas Cluster Server can provide such a solution for clients.

9/11/2012
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 DCM automation feature can inter-operate 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’.

9/11/2012
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.

9/11/2012
38 IBM Systems© 2008 IBM Corporation
GDPS/PPRC: a Continuous Availabilty and/or
Disaster Recovery Solution
- Metropolitan Distance
SITE 1
NETWORK
SITE 2
NETWORK
1
12
2
3
4
5
6
7
8
9
10
11
1
12
2
3
4
567
8
9
10
11
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
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)

9/11/2012
2. 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 pre-
deposit 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 40-50 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.

9/11/2012
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

9/11/2012
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 would typically be called a 4-site configuration 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.

9/11/2012
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.

9/11/2012
3-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 ‘2nd
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 80+ GDPS/MzGM w/HyperSwap or GDPS/MGM
with HyperSwap multi-site configurations. The following figures outline these
implementations.

9/11/2012
GDPS/MzGM w/HyperSwap & Incremental Resync
Site1Site1Site1Site1
K1
Metro
Mirror
P2
bkup
CF1
KgB
Data Replication A->B & A -> C
Incremental resynch B C
if Site1 or A-disk fails
Maintains disaster recovery position
Improved RTO
Optional: CFs / Prod systems in Site2
P1 Unix
K1K1
A
K2 P1
bkup
CF2
P2
K2
Incremental Resync
Recovery SiteRecovery SiteRecovery SiteRecovery Site
A
C
A
F
SDM
1
12
2
3
4
5
6
7
8
9
10
11
Kx
CF1SDM Kx
P2
Bkup
P1
Bkup
z/OS Global Mirror
1
12
2
3
4
5
6
7
8
9
10
11
F Recommended for FlashCopy
1
12
2
3
4
5
6
7
8
9
10
11
1
12
2
3
4
5
6
7
8
9
10
11
ETR or STP
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

9/11/2012
GDPS/MGM w/HyperSwap
Site2Site2Site2Site2 Recovery SiteRecovery SiteRecovery SiteRecovery Site
Kp
R P1
Bkup
A
D
A
C
Global Mirror
P2
bkup
P2
Bkup
A
F
CF1
1
12
2
3
4
5
6
7
8
9
10
11
1
12
2
3
4
5
6
7
8
9
10
11
1
12
2
3
4
5
6
7
8
9
10
11
KgB
GM K-Sys runs in production LPAR
► HyperSwap protection
Reduced resource requirement
CF3
Non-z
Bkup
P1 Non
-z
K1Kp
A
KP P1
bkup
CF2
P2 Non
-z
KP
R
Metro
Mirror
Kg
Kg
Kg
Kg
ETR or STP
F Recommended for FlashCopy
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.

9/11/2012
3 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.
A recognized customer requirement in this area is to provide the exact same
functionality at the target site (High Availability + Disaster Recovery protection) on
both a planned and when possible an unplanned site switch. That is, the ability to use
asynchronous data replication back to the original production site as well as providing
local HyperSwap functionality. With this functionality, both sites provide the business
equal functionality to the business and enables a peer site configuration.
Distributed Systems
As mentioned earlier in this paper, with the GDPS/DCM capability, GDPS automation
can inter-operate with either Tivoli AppMan or Veritas Cluster Server 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.

9/11/2012
. 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...

9/11/2012
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 36 years experience in large system design and
development and holds numerous patents in Storage related topics. For the last 28 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.

“z/OS Multi-Site Business Continuity” September, 2012

Recommended

Recommended

More Related Content

What's hot

What's hot (9)

Similar to “z/OS Multi-Site Business Continuity” September, 2012

Similar to “z/OS Multi-Site Business Continuity” September, 2012 (20)

More from IBM India Smarter Computing

More from IBM India Smarter Computing (20)

Recently uploaded

Recently uploaded (20)

“z/OS Multi-Site Business Continuity” September, 2012