High availability configuration
The objective of any high availability configuration is to eliminate all single points of failure (SPOFs).
Figure 1. High Availability Configuration. This figure illustrates the recommended product configuration for high availability. The key elements are described in the text that accompanies this figure.
Following are the key elements of a high availability configuration:
- Network path redundancy leading up to the web servers and Applications Servers.
- Redundant web servers. (There must be at least two logical partitions
(LPARs) in a high availability sysplex configuration.)
- A highly available sysplex configuration. These LPARs should be on separate hardware instances to eliminate hardware and software Single Points of Failures (SPOFs).
- A node on each LPAR configured into a WAS Network Deployment cell. The deployment manager server ( required, and configured on its own node ) can be configured on either LPAR or on a separate LPAR. (The deployment manager server is not depicted in the preceding figure.) Also note, there
is a daemon process (WebSphere CORBA Location Service)
on each LPAR that has one or more nodes in the same cell.
- An application server defined on each node, and formed into a server cluster with the other application servers in the network.
- A dynamic virtual IP address (DVIPA) defined through the z/OS Sysplex
Distributor as the daemon IP name for the cell. This IP address enables WLM-balanced routing and fail over between the LPARs for IIOP requests.
- A dynamic virtual IP address (DVIPA) defined through Sysplex Distributor
as the HTTP transport name for the cell. This IP address enables WLM-balanced routing and fail over between the LPARs for sessionless
HTTP requests.
- A static IP address is required for each node as an auxiliary
HTTP transport name for the cell. This enables directed HTTP routing
for sessional HTTP requests.
- A WebSphere web server plug-in must be installed in each of the web servers and configured to use the HTTP DVIPA for sessionless requests, and the static IP addresses for sessional requests.
- If using HTTP sessions, session state must be shared between cluster member using the data replication service (DRS) or session data must be stored in DB2 . If we are using stateful session Enterprise JavaBeans, the stateful session persistent store must be configured on a shared HFS. (Using stateful session Enterprise JavaBeans is not a best practice.)
Related concepts
Related tasks