IBM eServer zSeries 900 Technical Guide

186 IBM eServer zSeries 900 Technical Guide

򐂰 Minimized overhead of duplexing during mainline operation via hardware-assisted

serialization and synchronization between the primary and secondary structure updates

򐂰 Maximized availability in failure scenarios by providing a rapid failover to the unaffected

structure instance of the duplexed pair, with very little disruption to the ongoing execution

of work by the exploiter and applications

System-managed duplexing rebuild provides robust failure recovery capability via the

redundancy of duplexing, and low exploitation cost via system-managed, internalized

processing. Structure failures, CF failures, or losses of CF connectivity can be handled by:

1. Hiding the observed failure condition from the active connectors to the structure, so that

they do not perform unnecessary recovery actions

2. Switching over to the structure instance that did not experience the failure

3. Re-establishing a new duplex copy of the structure if appropriate as the Coupling Facility

becomes available again or on a third CF in the Parallel Sysplex

System messages are generated as the structure falls back to simplex mode for monitoring

and automation purposes. The structure operates in simplex mode until a new duplexed

structure can be established, and can be recovered using whatever existing recovery

techniques are supported by the exploiter.

System-managed duplexing's main focus is providing this robust recovery capability for

structures whose users do not support user-managed duplexing rebuild processes, or do not

even support user-managed rebuild at all.

5.3.3 Configuration planning

A new connectivity requirement for system-managed CF structure duplexing is that there

must be bi-directional CF-to-CF connectivity between each pair of CFs in which duplexed

structure instances reside. With peer links this connectivity can be provided by a single

bi-directional link (two with redundancy).

CF-to-CF links can either be dedicated or shared via MIF. They can be shared with

z/OS-to-CF links between z/OS and CF images in the pair of CECs they connect. When

planning sharing links, remember that receiver links can not be shared, and peer links can

only be shared by one coupling facility partition.

Whenever possible, try to comply with the following recommendations:

򐂰 Provide two or more physical CF-to-CF links (peer mode), or two or more physical

CF-to-CF links in each direction (sender/receiver mode), between each pair of CFs

participating in duplexing. The physical CF-to-CF links may be shared by a combination of

z/OS-to-CF links and CF-to-CF links.

򐂰 For redundancy, provide two or more z/OS-to-CF links from each system to each CF.

Provide dedicated z/OS-to-CF links if possible. If z/OS-to-CF links are shared between

z/OS partitions, the occurrence of path busy conditions should be limited to at most 10 to

20 percent of total requests. If path busy exceeds this guideline, either provide dedicated

links, or provide additional shared links, to eliminate or reduce the contention for these link

resources. Use peer links whenever possible.

򐂰 You can provide either dedicated or shared z/OS CPs when using system-managed CF

structure duplexing. Dedicated coupling facility CPs are highly recommended for

system-managed CF structure duplexing.