Introduction to the New Mainframe: Large-Scale Commercial Computing

Chapter 5. Availability 95

support and appropriate planning, concurrent upgrades

can also be nondisruptive to the operating system. Such

upgrades provide additional capacity (memory,

processors) without a server outage.

Capacity upgrades can be either permanent or temporary:

Permanent

- Capacity Upgrade on Demand (CUoD)

- Customer Initiated Upgrade (CIU)

Temporar y

- On/Off Capacity on Demand (On/Off CoD)

- Capacity BackUp (CBU)

Refer to 3.3.6, “Workload Manager (WLM)” on page 56 to

learn more about CUoD, CIU, and OOCoD. Concepts

such as dynamic, nondisruptive addition of processor

resources like processors, memory and I/O for permanent

use reduce the need for planned outages.

Capacity Backup (CBU)

Capacity Backup (CBU) is the temporary activation of CPs, IFLs, ICFs, zAAPs

and zIIPs for robust disaster recovery. The CBU features provide the ability to

concurrently increment the CP or specialty engine capacity of your System z

server, using Licensed Internal Code, Control Code (LIC-CC), in the event of an

unforeseen loss of substantial System z computing capacity at one or more sites.

The CBU features contain additional resources and alter the target server to an

agreed-upon configuration for up to a 90-day period.

5.4.2 Accessing peripheral devices

In a continuous availability environment, keep the following points in mind when

configuring the peripherals.

򐂰 Create a configuration that will survive the loss of any single component

within the subsystem.

򐂰 Configure your storage subsystem such that you can survive, or at least

recover from, a complete loss of the whole subsystem.

򐂰 Mirror your data such you can survive even if you lost a storage subsystem, or

even a complete data center.

96 Introduction to the New Mainframe: Large-Scale Commercial Computing

Create a redundant I/O configuration

Chapter 6, “Accessing large amounts of data” on page 109, explains the main

concept of accessing data through the channel subsystem. Figure 5-1 on

page 96 illustrates how to create an I/O configuration to meet availability goals.

Figure 5-1 Example redundant I/O configuration

Configure the storage subsystem

Features in today’s storage subsystems that are used by mainframe servers

support this. Note, however, that although some are standard features, others

are optional, and some are not available on all storage subsystem types. They

are:

򐂰 Independent dual power feeds

򐂰 N+1 power supply technology/hot swappable power supplies, fans

򐂰 N+1 cooling

򐂰 Battery backup

򐂰 Non-Volatile Subsystem cache, to protect writes that have not been hardened

to DASD yet

򐂰 Non disruptive maintenance

򐂰 Concurrent LIC activation

򐂰 Concurrent repair and replace actions

򐂰 RAID architecture

򐂰 Redundant microprocessors and data paths

򐂰 Concurrent upgrade support (that is, ability to add disks while subsystem is

online)

򐂰 Redundant shared memory

LPAR1

LPARn

LPAR2

CSS /

CHPID

LPAR1

LPARn

LPAR2

Director

(Switch)

....

DASD CUDASD CUDASD CUDASD CU

Chapter 5. Availability 97

򐂰 Spare disk drives

򐂰 Remote Copy to a second storage subsystem

– Synchronous - Peer-to-Peer Remote Copy (PPRC)

– Asynchronous - Extended Remote Copy (XRC)

Explaining the details of storage subsystems is beyond the scope of this

document. However, an example is the current high-end IBM System Storage™

DS8000™; for details about this system, visit:

http://www.ibm.com/servers/storage/disk/ds8000/

Mirroring data

For backup, recovery and disaster recovery scenarios, you need to mirror your

data, not only by using the internal RAID functions of the storage subsystem, but

also a second storage subsystem. Refer to 4.2.5, “Data backup and recovery” on

page 75, for more details about this topic.

Figure 5-2 Disk mirroring using PPRC and XRC

Figure 5-2 illustrates disk mirroring PPRC and XRC. Peer-to-Peer Remote Copy

(PPRC) is a

synchronous copy technology. As soon as data is written to the

Primary disk subsystem, the control unit forwards it to the secondary subsystem.

The secondary writes it and sends an acknowledgement back to the primary. At

this point, the primary lets the application know that the I/O completed. Because

the control unit does not care where the I/O request came from, PPRC supports

any operating system.

Extended Remote Copy (XRC) is an

asynchronous copy technology. The System

Data Mover (SDM) is a component of z/OS. It reads data from the primary control

units, and coordinates applying them to the secondary volumes. Note: XRC only

works with z/OS data.

System z

System z

z/OS

z/OS

1

4

3

2

PPRC

System z

System z

z/OS

z/OS

1

4

3

2

PPRC

1 4 3 2

SDM

SDM

XRC

1 4 3 2

SDM

SDM

XRC