Implementing IBM WebSphere Application Server clustering

To implement clustering, create an IBM® WebSphere® Application Server Network Deployment cell across your computers, and define a cluster that contains application servers within the cell.

An IBM WebSphere Application Server Network Deployment implementation consists of one or more application server processes. These processes run on one or more computers or logical partitions (LPARs). IBM WebSphere Application Server Network Deployment allows you to set up a node agent to manage a subgroup of the application server processes in the implementation. A node agent monitors the application servers and routes administrative requests to them. The group of application servers plus their associated node agent is called a managed node. You can have multiple managed nodes per implementation.

The node agents communicate with a deployment manager (DMgr). Deployment managers are administrative agents that provide a centralized management view for the nodes. The group of processes (application servers and node agents) managed by a deployment manager is called a cell.

A cluster is a logical subgroup of the application servers within the cell that are all running the same set of applications and services. The application servers within a cluster are called members of that cluster. The cluster is managed by the Deployment Manager in the cell.

The following diagram shows a cell that contains two managed nodes that are managed by a Deployment Manager. Each node contains multiple application servers that are managed by a node agent. Each node agent communicates with the Deployment Manager. The diagram also shows a cluster that contains the application servers in each node.

Figure 1. Cell that contains two managed nodes that are managed by a Deployment Manager

This figure is described in the surrounding text.

To further enhance the high availability of the services tier, you can horizontally scale the cluster by adding more managed nodes on other computers. Adding more nodes also enhances performance and throughput, because the nodes in the cluster share the workload. You can also vertically scale the cluster by adding application servers to managed nodes on the same computer. Vertical scaling improves performance and throughput, but does not improve availability except at the application server level (that is, if an application server in a managed node fails, other application servers in the node continue to function. If an entire computer fails, all application servers on the computer fail).

WebSphere Application Server supports several cluster topologies. IBM InfoSphere™ Information Server supports most WebSphere Application Server cluster topologies for the services tier, with the following restrictions.

You must deploy each InfoSphere Information Server cluster in its own dedicated cell. The cell cannot contain other clusters, Master Data Management (MDM) servers, or stand-alone application servers.
The application servers within the cluster must be the same version: the same major release (for example, 6.1 or 7.0) and the same fix pack version (for example, fix pack n.n.n.n).
All computers spanned by a cluster must run the same operating system and fix pack level.
You must deploy a front-end HTTP server, a load balancer (hardware or software), or a mix of HTTP servers and load balancers (IP sprayer topology). For more information, see Building a highly available and scalable front-end configuration to an IBM WebSphere Application Server cluster.

The following diagram illustrates vertical and horizontal InfoSphere Information Server cluster topologies, and shows some topology elements that are not allowed in an InfoSphere Information Server cell.

Figure 2. Vertical and horizontal cluster topologies (allowed and not allowed)

Additional restrictions to assigning metadata repositories to InfoSphere Information Server clusters include:

Each InfoSphere Information Server cluster must be assigned only one metadata repository.
InfoSphere Information Server cluster members that are not part of the same cluster cannot share the same metadata repository.
Members of a given InfoSphere Information Server cluster cannot be associated with multiple metadata repositories.
An InfoSphere Information Server cluster member and a stand-alone application server cannot share the same metadata repository. (The InfoSphere Information Server installation program enforces this restriction.)
You must use a distributed user registry such as the InfoSphere Information Server custom registry or an LDAP registry. Local operating system registries do not work in cluster environments.

The following diagram shows an InfoSphere Information Server cluster, and relationships that are allowed and not allowed between the cluster members and metadata repositories.

Figure 3. Allowed and not allowed relationships between cluster members and metadata repositories

This figure illustrates the restrictions that are described in the surrounding text.

The following diagram shows the location of application server node agents and the Deployment Manager in a sample configuration. There is only one Deployment Manager per cell, running on one of the computers. If the node agents are running, a cluster can continue to perform most runtime functions if the Deployment Manager is not active, so the Deployment Manager is not a single point of failure for these operations. However, for administration operations such as IBM InfoSphere Information Services Director application deployment, the Deployment Manager must be running. Also, the WebSphere Application Server console is hosted in the Deployment Manager, so the Deployment Manager must be running for you to use this console.

Figure 4. Application server node agents and Deployment Manager in a sample configuration