Introduction

In a typical application server environment, it is common to have the servers clustered for scalability. WebSphere Application Server V4.0 is quite easy to cluster. With clustering, all the data required to run a Web application will be stored in a central location. As soon as this central location is accessible by all the parties in a cluster, we are able to accomplish our clustering goals. There are two main methods for clustering: vertical and horizontal scaling. This article looks at scaling options and how they relate to the WebSphere Application Server.

Back to top

The Go-ForIt project

The Go-ForIt.com project is an e-business application built on a logical three-tier architecture. It consists of Enterprise JavaBeans (EJB) components, JavaBeans, servlets, and more. We started out by deploying Go-ForIt on a single node consisting of the Web server (IBM HTTP Server), WebSphere Application Server, and DB2 UDB. With an increasing number of customer requests, and to maintain reliability of the application, we implemented clustering using horizontal scaling.

The different components of the application were deployed into a single application server process. We created a server group and five clones from this server group. Then we installed two clones per node. All the nodes that participated in the cluster are part of a single WebSphere domain cluster. Reliability was achieved by deploying the clone on multiple machines. Because of cloning and the need to handle sessions that are established by customers, the immediate question that pops up is how to handle session persistence in such a situation. Using the session manager feature of the WebSphere Application Server, we can specify that all the sessions be persisted to a database. Once this is done, even if one clone went out of service, the other available clone that services the cutomer request will look at the common database repository and continue the session the customer previously established.

Back to top

Clustering terminology

HTTP server and plug-in

The WebSphere Application Server works with an HTTP server, or Web server, to handle requests for dynamic content, such as servlets, from Web applications. (We use the terms HTTP server and Web server interchangeably in this article.) The HTTP server and application server communicate using the WebSphere HTTP plug-in for the HTTP server. The HTTP plug-in uses an easy-to-read XML configuration file to determine whether a request should be handled by the Web server or the application server. It uses the standard HTTP protocol to communicate with the application server, and can also be configured to use secure HTTPS, if required. The HTTP plug-in is available for popular Web servers, including IBM HTTP Server, Apache, Microsoft IIS, and Netscape iPlanet.

Server groups

A server group is a template for creating additional, nearly identical copies of an application server and its contents. It is a logical representation of the application server.

Clones

Cloning is the process of creating a server group based upon an existing fully configured server; the copies are called clones. Clones are identical in every way to the server group from which they were created. Unlike server groups, the clones created from a server group represent real application server processes running on real physical nodes.

Back to top

Vertical scaling

In the simplest case, you can configure many application server clones on a single machine, and this single machine also runs the HTTP server process. You typically start by defining a server group from an application server process. Next you create a clone of the server group and deploy that clone on the same machine where the application server and the Web server are installed. As the user demand increases, you can deploy additional clones and they will all be deployed on the same server. The ability to add more clones depends on the power of a single machine. If the number of clones is causing the CPU to be fully used, adding more clones is not going to eliminate the problem in vertical scaling. The different components installed on the two machines are shown in Table 1, below; the configuration is shown in Figure 1.

Table 1. Vertical scaling components

In Figure 1, the Web server and WebSphere Application Server are both on Machine A and the Database Server is on Machine B. In this scenario, Machine A must have the power to handle multiple clones of an application server. The HTTP plug-in in the figure knows how to communicate and transfer control over to the application server clones, keeping sessions in mind.

Vertical scaling is possible, but requires a powerful machine to help address different clones on the same machine. A more reliable and robust solution for scaling is the horizontal scaling model.

Back to top

Horizontal scaling

The horizontal scaling model is a more suitable configuration for better scalability, depending on physical resources. In this configuration you first create a clone out of the server group. Then you create clones and can deploy the clones on different machines to achieve reliability and scalability. Compared to vertical scaling, horizontal scaling does not limit you to the power of a single machine. If the clones (on different machines) are being fully used, adding more machines will help eliminate the problem. The different components installed on the four machines are shown in Table 2, below; the configuration is shown in Figure 2.

Table 2. Horizontal scaling components

In the scenario in Figure 2, Machine A is running the HTTP Server and the required plug-in to communicate with the application servers. Machines B and C are similar, as they both have multiple application servers running with their own respective clones. Plus, with the help of the DB2 Client, they are able to communicate back to the Database Server on Machine D.

In this article we focus on the horizontal scaling model in Figure 2, which suggests four machines to be configured. For demonstration purposes, though, we'll use just two machines in the examples. In a production environment, you should consider using the four machine model. The remainder of this article presents links to detailed step-by-step instructions for installing and configuring the components on the machines in the two machine model.

Back to top

Prerequisites

Before starting the installation process, you'll need to have two machines, with the following hardware/software requirements:

• Pentium III with 800 MHz
• 10 GB hard disk
• 512 MB RAM
• Windows 2000 with Service Pack 2

To further eliminate network problems, we configured a simple network using the 192.168.X.X private network addresses. This simple configuration with their IP addresses is shown in Figure 3 below.

Back to top

Installing DB2 and WebSphere Application Server on DB2WAS machine

The links here give you detailed instructions for each step in the process.

1. Install IBM DB2 UDB v 7.2.1 EE
2. Configure IBM DB2 UDB v 7.2.1 EE
3. Set up the WebSphere Administrative Database
4. Install FixPak 3 including WAS 4 and DB2 patches
5. Install WebSphere Application Server 4.0

Once the DB2WAS machine is up and running, set up the HTTPWAS machine next.

Back to top

Installing DB2 Client and WebSphere Application Server on HTTPWAS machine

1. Install the DB2 client
2. Verify the DB2 Client installation
3. Set up access to the remote administrative database
4. Install FixPak 3 including WAS 4 and DB2 patches
5. Install WebSphere Application Server 4.0

Resources

• Follow the tale of the DragonSlayers by reading previous articles.
  
  
• Explore techniques to scale applications in WebSphere Application Server in this Redbook on WebSphere Scalability: WLM and Clustering Using WebSphere Application Server, Advanced Edition.
  
  
• Learn how to maximize Web site availability in this article on WebSphere Developer Domain.
  
  
• Take advantage of resources to help you plan, design, and build an e-business solution for high volume Web sites on the High Volume Web Sites Zone on WebSphere Developer Domain.
  
  

About the authors

Rohit Sahasrabudhe is an e-business Architect for IBM Developer Relations Technical Consulting in Austin, Texas. Rohit is an IBM Certified for e-business Solution Designer, a Solution Technologist, and a Red Hat Certified Engineer. He holds a BS from the University of Louisville in Engineering in Math and Computer Science. He did three co-ops, including one in Germany, before joining IBM in 2000. He joined IBM as a Software Engineer, working on Lotus Domino Solutions. He is always working on improving his WebSphere skills and is looking forward to traveling around the world, consulting, and teaching courses. You can contact Rohit at sahas@us.ibm.com.

Balu is an e-business architect for IBM Developer Relations Technical Consulting in Austin, Texas, providing education, enablement, and consulting to independent software vendors (ISVs). He is a certified Java Programmer, certified WebSphere Specialist, and certified e-business technologist. You can contact Balu at balur@us.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• The Go-ForIt project
• Clustering terminology
• Vertical scaling
• Horizontal scaling
• Prerequisites
• Installing DB2 and WebSphere Application Server on DB2WAS machine
• Installing DB2 Client and WebSphere Application Server on HTTPWAS machine
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America