WebSphere Scaling

A fourth major pillar on which WebSphere rests is scalability.  Just as WebSphere has tried to "build-in" support for database integration, transactions, and security, so it has tried to provide declarative support for several functions that contribute to system scaling.  These include generating and maintaining "clones" of software modules, automatic load-balancing among them, and a limited form of failover that derives from cloning.

Two key concept underlie these features.  The first is that the major components that comprise a WebSphere system can be separated and distributed across several computers.  These components include the following:

The second major idea is that, with the exception of the database, a system can be configured that includes multiple copies of these various components.  In-coming queries can then be distributed among the components by the system, transparently with respect  to both end-user and the programmer.

The general topic of scalability is too large and complex to be presented in detail here; see the IBM Redbook, WebSphere Scalability:  WLM and Clustering for an introduction to the topic.  Here, the discussion will emphasize basic concepts and configurations that might be appropriate for a small multi-node system.

In order to understand WebSphere's provisions for scaling, you need to understand the following concepts:  topology, model, clone, and work-load management.  Each will be discussed, below

Topology

Topology refers to the configuration of machines and processes running on those machines within a network environment. One of the strengths of WebSphere is that its various components can be separated and run on different machines in a variety of ways.  

Components that can be separated and run separately include the following:

By default, all of these components may be installed on a single machine, as shown in Figure 1.  This configuration can serve as a reference point by which to compare other topologies.

Figure 1:  Single machine configuration.

The most straight-forward separation of components is a three-tier architecture in which the HTTP server, the WebSphere system, and the DBMS are run on three separate machines.  This configuration is shown in Figure 2.

Figure 2:  Three-tier configuration.

The rationale for this configuration often begins at the back.  Many installations will have already installed a powerful and tuned Database Server.  Consequently, it makes sense to either use the installed DBMS or to install the DB2 (or alternative) DBMS system on it, as well.  Similarly, the HTTP server may provide conventional Web services in addition to the function provided by WebSphere. Consequently, running it on separate machine can increase throughput because of the additional cycles available from another computer. If the "WebSphere" includes not a single WebApp but a number of different applications, benefit may derive from running it on a separate machine, as well.

However, additional cycles from configurations involving multiple machines come at a cost -- that incurred from the network communication between the machines.  Thus, dividing the components into three tiers or across three machines may not be a helpful strategy for all systems, but it may be a relatively "natural" design for some.

Models and Clones

Whereas WebSphere allows the programmer or system administrator to configure the various components that comprise the overall WebSphere system, it also allows them to create multiple instances of particular application software components and distribute them in the various system components discussed in the section on Topology.  Thus, one can create multiple instances of a frequently run servlet or a high-demand set of ejbs and run them in multiple servlet engines or ejb containers running on multiple computers.  The technology provided by WebSphere for doing this is models and clones.

A clone is an exact copy or replica of a WebSphere component.  One can clone a particular application's servlet engine, its ejb container, or the entire Web application.  However, IBM recommends as a best practice only, and always, cloning the entire Web application.  

The mechanism by which clones are created is a model.  A model for a Web application, or other component, is a detailed but abstract representation of an application server.  It includes the definitions of servlet engines, ejb containers, the servlets and ejbs themselves, as well as all of the properties associated with them.  However, the model is not associated with any given mode and it does not "run" or correspond with an given server process.

To create a clone, one first creates a model of the construct to be cloned -- most likely, a Web application.  This is done through a simple set of panels provided by the WebSphere Console.  One of the important benefits of cloning, in addition to potential increased throughput and possible failover, is that any changes made to the model are automatically propagated to the clones based on that model.

Once the model is defined, the WebSphere Console provides mechanisms to create the actual (multiple) clones that can be run on the various machines or nodes in the overall topology.  Each clone runs in its own Java Virtual Machine.

Given the overall topology of the site, clones can be deployed in two basic ways:  vertically and horizontally.  

Vertical cloning refers to running multiple clones of a component within the same node.  Figure 3 shows such a deployment in which three clones of the WebApp are running, all on the same node.

Figure 3:  Vertical cloning configuration.

However, IBM notes that, in general, to achieve greater throughput with vertical cloning, a machine with at least four processors is needed.  Consequently, many applications will be better served by horizontal cloning.

Horizontal cloning refers to running multiple clones of a component on different nodes.  Figure 4 shows such a deployment in which two clones of the WebApp are running, on two different machines.  

Figure 4:  Horizontal cloning configuration.

This, or a similar topology, is likely to be more appropriate for most applications that need cloning but are not supported by large servers.

Workload Management

Workload Management refers to both strategic concerns, such as the overall and cloning topologies, and specific load balancing options that are defined declaratively. 

The strategic issues have been discussed in the sections on Topology and Models and Clones.  They will not be discussed further here.

Load balancing options refer to the policy used by WebSphere to assign a request or connection to a particular clone (running on a particular node).  The mechanism WebSphere uses is a so-called "smart stub."  If, for example, a configuration exists in which an HTTP request could be directed to a servlet engine in any one of three cloned Web apps, WebSphere generates stubs to all three.  When a request is received, the system automatically selects a particular (available) clone, through the mechanisms of the smart stubs, to which to send the request.

The particular stub, and, thus, the particular clone is selected based on a specified load-balencing policy.  WebSphere supports four such policies:  

As implied, the last two always select a stub that connects to a local clone, if one is available.  The first two apply a round robin or random selection algorithm without consideration of the location of associated clone.

A degree of failover is obtained through the way in which the smart stubs handle exceptions.  Whereas some exceptions -- those that could affect the semantics of the data or the system -- do not generate retries, those that can safely retried are automatically retried.  Some of the conditions that result in automatic retries are detection of an unavailable clone or node and communications that return a COMPLETION_STATUS  of COMPLETED_NO.