WebSphere® for z/OS® uses the zSeries® platform's internal error detection and correction internal capabilities. WebSphere for z/OS has recovery termination management that detects, isolates, corrects and recovers from software errors. WebSphere for z/OS can differentiate and prioritize work based on service level agreements. It offers clustering capability as well as the ability to make non-disruptive changes to software components, such as resource managers.

In a critical application, WebSphere for z/OS can implement a failure management facility of z/OS called automatic restart manager or ARM. This facility can detect application failures, and restart servers when failures occur. WebSphere uses ARM to recover application servers (servants). Each application server running on a z/OS system is registered with an ARM restart group.

WebSphere for z/OS can implement a feature called clustering. Clustering technology is used extensively in high availability solutions involving WebSphere, as shown in Figure 1.

A cluster consists of multiple copies of the same component with the expectation that at least one of the copies will be available to service a request. In general, the cluster works as a unit where there is some collaboration among the individual copies to ensure that the request can be directed toward a copy that is capable of servicing the request.

Designers of a high availability solution participate in establishing a service level as they determine the number and placement of individual members of clusters. WebSphere for z/OS provides management for some of the clusters needed to create the desired service level. Greater service levels of availability can be obtained as WebSphere clusters are supplemented with additional cluster technologies.

Figure 1. Clustering of servers in a cell

A WebSphere Application Server cluster is composed of individual cluster members, with each member containing the same set of applications. In front of a WebSphere Application Server cluster is a workload distributor, which routes the work to individual members.

Clusters can be vertical within an LPAR (that is, two or more members residing in a z/OS system) or they can be placed horizontally across LPARs to obtain the highest availability in the event an LPAR containing a member has an outage.

Workload in this case can still be taken on from the remaining cluster members. Also within these two configurations, it is possible to have a hybrid in which the cluster is composed of vertical and horizontal members (see Figure 2).

Figure 2. Vertical and horizontal clusters

You might wonder when to use vertical clustering as opposed to horizontal clustering. You might use vertical clustering to check the dispatching efficiency of a single system. In a vertical cluster, the servers compete with each other for resources.