06.01.2013 Views

Download PDF - IBM Redbooks

Download PDF - IBM Redbooks

Download PDF - IBM Redbooks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

2.7.3 DB2 data sharing and GDPS<br />

The objective of DB2 data sharing in a Parallel Sysplex environment is to keep the SAP<br />

business applications available even if a single database member needs to be stopped.<br />

If a connection is lost to the DB2 server, an SAP NetWeaver AS instantly reconnects to<br />

another DB2 member in the same data sharing group. This way, SAP workloads can be<br />

moved smoothly without being affected by these kinds of failures.<br />

With the help of <strong>IBM</strong> Geographically Dispersed Parallel Sysplex (<strong>IBM</strong> GDPS®) on top of the<br />

<strong>IBM</strong> System z Parallel Sysplex, you can apply this mechanism to geographically distributed<br />

environments (connected over large distances). GDPS technology is also used to integrate<br />

and ensure disaster recovery in such distributed environments.<br />

If a local disaster occurs, disk <strong>IBM</strong> HyperSwap® technology ensures that systems<br />

automatically swap to a synchronously mirrored site.<br />

2.7.4 <strong>IBM</strong> System z Coupling Facility<br />

The <strong>IBM</strong> System Coupling Facility that is used for the lock and shared communications area<br />

(SCA) structures of the DB2 data sharing group must be failure isolated from the z/OS<br />

systems that serve the data sharing group. The SCA is a list structure in the coupling facility.<br />

2.8 Network setup<br />

2.9 I/O setup<br />

2.9.1 Metro Mirror<br />

To ensure high-availability of the network, use static z/OS VIPAs for each LPAR running on a<br />

DB2 member. This setup allows the SAP components to re-establish their connections to the<br />

moved and restarted services by attempting to reconnect to the same VIPA.<br />

This section highlights two technologies that differ in disaster resilience and are available for<br />

storage subsystems. With the Metro Mirror and Metro/Global Mirror Copy Services features,<br />

you can set up a relationship between two volumes, so that updates that are made by an<br />

application to one volume are mirrored on the other volume. The volumes can be in the same<br />

system or on two different systems.<br />

With Metro Mirror technology (shown in Figure 2-7 on page 22), application failover occurs<br />

across multiple servers. The GDPS/Peer-to-Peer Remote Copy (PPRC) HyperSwap Manager<br />

controls the data replication in a single sysplex within a data center or simplifies replication<br />

between two sites that are within the supported distance.<br />

If a storage or subsystem failure occurs, with the GDPS HyperSwap Manager, seamless<br />

takeover occurs within a few seconds. Within the process of swapping to another location, all<br />

application and system-relevant data is included and consistently maintained.<br />

With the DS8000 Remote Pair FlashCopy®, you can permanently mirror data to create DB2<br />

backups and to allow GDPS to start HyperSwap when necessary so that all volumes are in<br />

full duplex mode and network traffic is reduced.<br />

Chapter 2. Architectural overview of SAP NetWeaver with DB2 for z/OS 21

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!