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 that
is configured into a WebSphere® Application Server, 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 you 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.)