|
|
A complete WebSphere environment can include several Web server instances as well as several WAS instances. Each HTTP server is configured to run the WebSphere Web server plug-in. The cluster members can all reside on a single node or can be distributed across multiple nodes in the WebSphere cell (vertical or horizontal scaling).
Each request coming into the Web server is passed through the plug-in, which uses its configuration information to determine if the request should be routed to WebSphere, and if so, to which appserver (that is to which Web container) the request should be routed to (see Figure 2-5). The communication between the plug-in and the appservers can be either HTTP or HTTPS. The Web server plug-in distributes requests around cluster members that are not available.
Figure 2-5 Plug-in (Web container) workload management
The plug-in, which runs in-process with the Web server itself, is responsible for deciding which Web container the request should be passed to. It uses the following mechanisms for WLM and failover:
- Application server clustering which creates server process redundancy for failover support. All appservers in a cluster host the same application or applications.
- The workload management routing technique built into the WebSphere Web server plug-in. It controls the routing of client requests among redundant server processes. This routing is based purely on the weights associated with the cluster members. If all cluster members have identical weights, the plug-in sends an equal number of requests to all members of the cluster, when assuming no session affinity. If the weights are different, the plug-in routes requests to those cluster members with the higher weight value more often.
- Session management and failover mechanism, which provides HTTP session data for redundant server processes.
Thus, satisfactory failover support for Web clients can only be achieved by the use of all three mechanisms.
