Workload management

---

The objective of workload management (WLM) in WebSphere Application Server is to support load balancing and failover capabilities. WLM technology allows enterprises to configure, prioritize, and use all available resources to optimally service incoming requests. These features are essential in maintaining application server performance in an enterprise, especially when the applications' use of resources varies.

Workload management can be implemented at three places in the execution path of WebSphere Application Server.

1. A load balancer can route HTTP requests to a cluster of Web servers

2. A Web server can route HTTP requests to a cluster of WebSphere Application Servers - workload management at the Web container

3. A WebSphere Application Server or a Java client can route IIOP requests to a cluster of WebSphere Application Servers

This chapter focuses on the second option, the use of HTTP workload management to implement the sharing of application server resources. HTTP WLM sprays requests to a cluster of Web containers (servlet engines). This option is illustrated in Figure 4-4-1.

Figure 4-1 shows a single HTTP server in which the WebSphere plug-in distributes the incoming workload across six application server clones, three clones in each of two application server nodes.

Figure 4-1: Illustration of workload management

This type of load management provides clustering, failover, and high availability for the Web container tier. WebSphere Application Server interacts with traditional Web servers such as Apache, IBM HTTP Server, Sun iPlanet, Lotus® Domino®, and Microsoft Internet Information Services (IIS) using the native Web server plug-in architecture. The WebSphere plug-in interacts with the Web containers through the internal HTTP transports. Because workload management of HTTP requests is implemented in the plug-in, load balancing is available for HTTP requests that enter into the WebSphere Application Server domain through an external HTTP server.

As can be seen in Figure 4-2, our test configuration was more complicated than that illustrated above, having four HTTP servers and four application servers. However, within each of the Web servers, the WebSphere plug-in distributed the workload across all the application server clones in the system - in our case a total of twelve clones, three in each of our four application server nodes.

Figure 4-2: Schematic of the test configuration

In addition, workload was spread across our four HTTP servers using a network dispatcher (option 1 in the above list). The Network Dispatcher was not the focus of our tests and is not addressed significantly in this chapter.

Failover and high availability

WebSphere Application Server's clustering features provide high availability and workload management capabilities in application server shared environments.

In a shared or virtualized environment, horizontal clustering can be used to eliminate any single machine as a point of failure. At a minimum, all applications should be deployed in a two-server horizontal clustering environment where application server processes are physically separated onto two different machines. Vertical clustering, or multiple application server processes on the same physical machine, can be used to improve process availability, or better use of resources on a single node. However, horizontal-clustering rules should not be overlooked for each separate application server process in the vertical cluster to assure availability and failover needs are met.

Workload management using the IBM HTTP Server version 1.x on AIX

The following information applies to IBM HTTP Server (IHS) version 1.x in AIX. IHS version 2 has a different structure.

Our tests used IHS version 1.3.19.4 on AIX. To understand the behavior of WebSphere workload management in a system using IHS version 1.x on AIX, it is important to be clear about the system structure. IHS 1.x on AIX is a process-based server. A separate HTTP server process services each client connection. The maxclients directive in the HTTP server configuration file (httpd.conf) sets the maximum number of concurrent HTTP server processes. In our test configuration, there were four HTTP servers, and when fully loaded each typically had in excess of 500 concurrent HTTP processes -- meaning a total of over 2,000 HTTP server processes in the HTTP server tier.

In AIX, each HTTP server process runs a separate instance of the WebSphere plug-in. These separate instances operate independently and do not share state information. This has the following consequences that are important in terms of understanding WebSphere workload management:

1. Each instance of the plug-in separately makes its own discoveries about application server clones being inaccessible.

Each instance of the plug-in separately operates its RetryInterval timer starting when it first marks a clone as down. This controls when the plug-in instance next marks the unavailable clone as being potentially available.

Because there are numerous plug-ins operating independently, the end-to-end behavior of workload management is the statistical aggregate of the decisions they make.

---