(ZOS) Set up a highly available sysplex environment

Set up a highly available sysplex environment allows us to control application rollout and workload routing.

• A highly available sysplex environment must include at least two logical partitions (LPARs). These LPARs should be on separate hardware instances to eliminate hardware single points of failure (SPOFs).

• There must be a network path redundancy leading up to the web servers and Applications Servers in your sysplex.

• If we are using HTTP sessions, session state must be shared between cluster member using the data replication service (DRS), or your session data must be stored in DB2 . If we are using stateful session EJBs, the stateful session persistent store must be configured on a shared HFS. It is not recommended that we use stateful session Enterprise JavaBeans.
• In environments with WebSphere Application Server running on a distributed platform cluster, along with several WAS for z/OS member systems running as a cluster, EJB workload management (WLM) failover on WAS for z/OS does not occur without making adjustments to the cache settings. Because interoperable object references (IORs) on WAS for z/OS are being workload managed, any pause in the WAS for z/OS results in all requests being dispatched to the surviving WebSphere Application for z/OS cluster. When the paused cluster member is resumed, only a very few requests (if any) are dispatched to this resumed cluster member, leading to an unbalanced system. The resumed cluster member has most of its CPU resources available, yet receives few (if any) requests to process, and as such, normal WLM processing does not occur after the paused system is resumed.

  Proper workload balancing can continue by setting a global JNDI cache expiration time for the entire server to some reasonable time (for example, com.ibm.websphere.naming.jndicache.maxcachelife=3, which results in a three minute cache expiration time).

Complete the following actions if to set up a highly available sysplex environment.

Tasks

1. Configure a node on each LPAR configured in the Network Deployment cell. The deployment manager Server, which is required, must be configured on its own node. It can be configured on either LPAR or on a separate LPAR.

2. Use the administrative console to verify that a location service daemon has been defined on each LPAR that has one or more nodes in the same cell.

3. Define an application server on each node, and form all of the application servers into a cluster.

   See the topic Add members to a cluster for more information on how to add application servers to a cluster.

4. Define the following dynamic virtual IP addresses (DVIPAs) through the z/OS Operating System's Sysplex Distributor.

   • Define a dynamic virtual IP address as the IP name of the daemon for the cell. This IP address enables WLM-balanced workload routing and fail over between the LPARs for IIOP requests.

   • Define a dynamic virtual IP address as the HTTP transport channel name for the cell. This IP address enables WLM-balanced routing and fail over between the LPARs for sessionless HTTP requests.

   See the z/OS Communications Server IP Configuration Guide for our version of the z/OS operating system for a description of how to define IP addresses through the z/OS Sysplex Distributor. This publication is available at http://www.ibm.com/servers/eserver/zseries/zos/bkserv/v1r4books.html.

5. Define a static IP address for each node as an auxiliary HTTP transport channel name for the cell. This IP address enables directed HTTP routing for sessional HTTP requests.

6. Configure web server plug-ins in each of the web servers. Configure the plug-ins to use the HTTP DVIPA for sessionless requests and the static IP addresses for sessional requests.

Subtopics

• Sysplex Distributor
  The IBM-recommended implementation, if we are running in a sysplex, is to set up your TCP/IP network with Sysplex Distributor. This makes use of dynamic virtual IP addresses (DVIPAs), which increase availability and aid in workload balancing.

• Set up the Server Runtime on multiple systems in a sysplex
  If the applications require workload balance, and high availability, and we want the ability to add new systems to meet demand as your workload grows, we might want to migrate your Application Server runtime and associated application servers from a monoplex to a sysplex configuration.

Related:

High availability configuration

Application update procedure in a high availability environment

Stopping an application server to manually update a high availability application

Modifying z/OS location service daemon settings

Add members to a cluster

Implement a web server plug-in