was_intro

8/4/2019 WAS_Intro

1/18

Introduction

An Application Server cluster is a set of application servers running the same application. The

application server processes can run on the same machine, or on different machines. From a

client view, a cluster appears to be a single server instance. Clustered application servers behave

similarly to single servers, except that they provide load balancing and failover. All serverinstances in a cluster must reside in the same cell (defined below) of a WebSphere domain.

The benefits of clustering are to provide:

Scalability - to increase the capacity of an application, and High availability - if an application server instance in the cluster fails, the application

processing will continue on the other application server instances of the cluster.

To understand the Application Server architecture topology, start with some common terms:

Managed serverAn application server process running in its own Java Virtual Machine (JVM).

NodeA logical group of servers located on the same physical computer. Multiple nodes can

exist on the same computer, but for this article, assume that only one node exists per

physical computer.

Node agentAn administrative process that manages the servers running on a node. A node agent

resides on a single node.

CellA logical group of nodes belonging to the same administrative domain.

Cell managerAlso called network deployment manager, it manages the multiple nodes in a distributed

topology. Technically it is an application server running an instance of the administrationconsole that can manage all the application servers configured in the same cell. It does

this by interacting with the node agent running on each physical computer in the cell.

A base Application Server installation includes everything needed for a single application server

process, and the code needed to run the node agent. The node agent is used only after the node is

added to a cell. A network deployment installation of Application Server can support a networkof computer systems that are configured to run collaborating instances of a single server

installation.Figure 1shows which CD is needed to install the product.
http://www.ibm.com/developerworks/library/i-wasldbal/#figure1http://www.ibm.com/developerworks/library/i-wasldbal/#figure1http://www.ibm.com/developerworks/library/i-wasldbal/#figure1http://www.ibm.com/developerworks/library/i-wasldbal/#figure1

8/4/2019 WAS_Intro

2/18

Figure 1. CDs for installation

Back to top

Setting up a cluster for load balancing

Load balancing is the distribution of tasks across the application servers of a cluster. This section

details the steps required to set up an Application Server cluster that supports workload

management.

Installation

Figure 2shows the installation I will use for this example.
http://www.ibm.com/developerworks/library/i-wasldbal/#ibm-pconhttp://www.ibm.com/developerworks/library/i-wasldbal/#ibm-pconhttp://www.ibm.com/developerworks/library/i-wasldbal/#figure2http://www.ibm.com/developerworks/library/i-wasldbal/#figure2http://www.ibm.com/developerworks/library/i-wasldbal/#figure2http://www.ibm.com/developerworks/library/i-wasldbal/#ibm-pcon

8/4/2019 WAS_Intro

3/18

Figure 2. Cluster setup

To recreate this example on your own, you will first need to install the product. For this you will

need two network-connected computers with an operating system properly installed andconfigured. The examples in this article are based on Windows 2000 but can be easily extended

to other operating systems.

The two computers, TP1 and TP2, must have fixed IP addresses and must belong to a network

with a DNS server. If you do not have access to a DNS server, you should use the etc/hosts file

to configure your network.

The configuration for TP1 and TP2 in the etc/hosts file is shown inFigure 3. Note that the IP

address can vary depending on your network configuration.

8/4/2019 WAS_Intro

4/18

Figure 3. Configuration for TP1 and TP2

You must install Application Server on each computer. If you aren't familiar with installing theproduct, follow these steps:

1.

Launch the installer (install.bat or install.sh) from your Application Server CD.2. Choose the install language (English has been used for this example). English is thedefault choice if your Windows 2000 regional settings are English-US.

3. When asked for the setup type, select Full.

8/4/2019 WAS_Intro

5/18

4. For the installation directories, change the defaults according toFigure 4.Figure 4. Installation wizard

5. When you are asked to enter the node name and host name for this installation:- Enter TP1 for the node name and TP1 for the host name on the first computer.

- Enter TP2 for the node name and TP2 for the host name on the second computer.(Be sure that TP1 and TP2 are valid entries in your DNS server or are in your etc/hosts

files).6. For Windows it is not necessary to run WebSphere as a service, but you should keep IBM

HTTP Server as a service on TP1. Enter an appropriate administrator user ID and

password for your system.7. Follow the default steps to finish the installation.

Now, Application Server installation is complete for the two computers. The next step is toinstall WebSphere Application Server Network Deployment on TP1, as follows:

1. Launch the installer (install.bat or install.sh) from the WebSphere Application ServerNetwork Deployment CD.2. Select English.3. Follow the installer steps. In the features selection, only the deployment manager is

required.

4. Change the default installation directory to C:\WebSphere\DeploymentManager5. Keep TP1Manager for the node name, TP1 for the host name and TP1Network for the

cell name.

8/4/2019 WAS_Intro

6/18

6. For Windows you can keep the deployment manager to run as a service.7. Follow the steps to complete the install.

After completing the installation, your configuration will be:

Computer 1Base Application Server installed. Application Server deployment manager installed.IBM HTTP Server installed and running as a Windows service.

Computer 2Base Application Server installed.

Configuration

Figure 5shows the configuration for the cluster.

Figure 5. Configuration for the cluster

Creating the deployment manager cellStart the deployment manager process on TP1. The two WebSphere nodes must be added to the

cell for the deployment manager. To do this, use the addNode command, which can be found inthe /bin directory for the WebSphere Application Server install on each system, as shown in

Figure 6below. The command must not be issued on the two nodes at the same time. Execute

addNode on computer TP1 first, wait for the command to complete, and then do it on computer

TP2. The command requires the parameter for the host name of the computer running the

deployment manager process. In this case, the host name is TP1.
http://www.ibm.com/developerworks/library/i-wasldbal/#figure5http://www.ibm.com/developerworks/library/i-wasldbal/#figure5http://www.ibm.com/developerworks/library/i-wasldbal/#figure6http://www.ibm.com/developerworks/library/i-wasldbal/#figure6http://www.ibm.com/developerworks/library/i-wasldbal/#figure6http://www.ibm.com/developerworks/library/i-wasldbal/#figure5

8/4/2019 WAS_Intro

7/18

Figure 6. addNode

After the command completes, you should get a message that the node has been successfully

federated, as shown inFigure 7.

Figure 7. Success message

Do not forget to issue the same command on TP2 (addNode.bat TP1, where TP1 is the host nameof the computer running the deployment manager).

So far you have a deployment manager, a node agent running on TP1, and a node agent runningon TP2. To verify the installation to this point, review the following logs:

8/4/2019 WAS_Intro

8/18

C:\WebSphere\AppServer\logs\nodeagent\SystemOut.log (on TP1 and TP2) C:\WebSphere\DeploymentManager\logs\dmgr\SystemOut.log (on TP1)

A message "Serverxxx open for e-business" will indicate that the process is started, wherexxx is

either dmgror nodeagent.

Creating the clusterAs described earlier, a cluster is a set of application servers running the same application. Within

a cluster, each application server is often called a clone. InFigure 3, there are three clones: two

on TP2, and one on TP1. In Version 5 of Application Server, a clone is allocated a given weight

used for load balancing. The weight is a relative value between all the clones in the cluster.

For this scenario, you want to share requests evenly across all computers. To do this, set the

weighting for clone 3 to be the same as the weighting of clone 1 added to the weighting of clone2. For example, you can set the weight values to 2 for clone 1, 2 for clone 2, and 4 for clone 3.

Using other values such as 3, 3, and 6 would have given the same result. You shouldn't use high

numbers for the relative weight of the clones.

To create the cluster of application servers, use the WebSphere Administrative Console. In

Servers > Clusters press New to create a new cluster, as shown inFigure 8.

Figure 8. Creating the cluster of application servers

In step 1, choose cluster1 for the name of the cluster. You will see the meaning of the replicationdomain later inFailover and replication in a cluster. For now, set create Republication Domain

for this cluster and don't enable prefer local.
http://www.ibm.com/developerworks/library/i-wasldbal/#figure3http://www.ibm.com/developerworks/library/i-wasldbal/#figure3http://www.ibm.com/developerworks/library/i-wasldbal/#figure3http://www.ibm.com/developerworks/library/i-wasldbal/#figure8http://www.ibm.com/developerworks/library/i-wasldbal/#figure8http://www.ibm.com/developerworks/library/i-wasldbal/#figure8http://www.ibm.com/developerworks/library/i-wasldbal/#PartIIhttp://www.ibm.com/developerworks/library/i-wasldbal/#PartIIhttp://www.ibm.com/developerworks/library/i-wasldbal/#PartIIhttp://www.ibm.com/developerworks/library/i-wasldbal/#PartIIhttp://www.ibm.com/developerworks/library/i-wasldbal/#figure8http://www.ibm.com/developerworks/library/i-wasldbal/#figure3

8/4/2019 WAS_Intro

9/18

Figure 9a. Entering basic cluster information

ClickNext to go to step 2.

8/4/2019 WAS_Intro

10/18

Figure 9b. Creating new clustered servers

In step 2, as shown inFigure 9babove, create a clone called clone1 on node TP2. Set a weight of

2, Unique Http Ports, and Create Replication Entry in this Server. Use the defaultapplication server template and clickApply.

Repeat step 2 to create a clone called clone2 on node TP2. Set a weight of2, Unique Http Ports,and Create Replication Entry in this Server. Use the default application server template and

clickApply. Repeat step 2 again to create a clone called clone3 on node TP1. Set a weight of4,

Unique Http Ports, and Create Replication Entry in this Server. Use the default applicationserver template and clickNext.

Check in the summary that the cluster contains the three clones with the right attributes, click

Finish, and save the changes.

You're done creating the cluster definition. The next step is to install an enterprise application.For this exercise, use the DefaultApplication.ear in the /installableApps directory of the

WebSphere Application Server installation. The procedure for installing an enterprise applicationonto a cluster is identical to installing onto a standalone application server, with one exception: at

the step "Map modules to applications servers," you must select cluster1 for all modules. SeeFigure 10below for an example. (It is out of the scope of this article to give detailed installation

steps for an enterprise application.)
http://www.ibm.com/developerworks/library/i-wasldbal/#figure9bhttp://www.ibm.com/developerworks/library/i-wasldbal/#figure9bhttp://www.ibm.com/developerworks/library/i-wasldbal/#figure9bhttp://www.ibm.com/developerworks/library/i-wasldbal/#figure10http://www.ibm.com/developerworks/library/i-wasldbal/#figure10http://www.ibm.com/developerworks/library/i-wasldbal/#figure10http://www.ibm.com/developerworks/library/i-wasldbal/#figure9b

8/4/2019 WAS_Intro

11/18

Figure 10. Map modules to application servers

During the setup of the cluster, three clones were created with unique HTTP ports, meaning thatthe HTTP listeners for the internal servers running in each application server have specificvalues. The algorithm used by the admin process to create new ports uses a default value (9080

for HTTP transport) and increments up to the next free value for each new server that is defined.

In this case, when you installed Application Server, a standalone server called server1 was

created. When the node was added to the deployment manager, server1 was also migrated to

become a manager server. Server1 uses port 9080 for its HTTP transport. On TP2, clone1 was

created using the port 9081 and clone2 using the port 9082. When installing theDefaultApplication.ear, the default_host virtual host was used for the Web modules. By default,

the default_host accepts HTTP requests only on port 9080, so you need to configure this virtual

host to also accept requests for ports 9081 and 9082.

To add support for additional ports to the default host, in the WebSphere AdministrativeConsole, use Environment > Virtual Hosts > default_host > Host Aliases. ClickNew to add a

new alias. Use * for the hostname ( * represents any hostname) and 9081 for the port. Repeat this

task for the port 9082, as shown inFigure 11.

8/4/2019 WAS_Intro

12/18

Figure 11. Additional ports to the default host

Save the configuration, ensuring that Synchronize changes with Nodes is checked.

Now that you have an application installed in your cluster, it's time to test it. There are three

types of processes in the runtime: the cell manager, node agents, and application servers. Each is

a separate Java process at the system level.

You can use the Administrative Console of the cell manager to start and stop the cluster. Beforedoing that, the node agent must be running on each node. You can use the commands inTable 1

to control the cell manager and node agents in this installation.

Table 1. Commands for controlling cell manager and node agents

To: Enter the command:

Start the node

agentC:\WebSphere\AppServer\bin\startNode.bat

Stop the node

agent C:\WebSphere\AppServer\bin\stopNode.bat

Start thedeployment

danager

C:\WebSphere\DeploymentManager\bin\startManager.bat

Stop the

deploymentmanager

C:\WebSphere\DeploymentManager\bin\stopManager.bat
http://www.ibm.com/developerworks/library/i-wasldbal/#Table1http://www.ibm.com/developerworks/library/i-wasldbal/#Table1http://www.ibm.com/developerworks/library/i-wasldbal/#Table1http://www.ibm.com/developerworks/library/i-wasldbal/#Table1

8/4/2019 WAS_Intro

13/18

The node agent should still be running from when the addNode command was executedpreviously. To check that the node agents for TP1 and TP2 are running, use System

Administration > Node Agent from the WebSphere Administrative Console. Then look at the

status for the nodes TP1 and TP2. If the node agent is unavailable on one of the computers, startit from the command line of that computer. When all the node agents are started, you can start

the cluster from the WebSphere Administrative Console, as shown inFigure 12. The startingprocess might take a few minutes, depending on your hardware configuration.

Figure 12. Starting the cluster

Before testing the workload management, it is useful to verify that the clones are workingindividually. Launch a browser and check the following URLs:

http://TP2:9081/hello - to see if clone1 is working http://TP2:9082/hello - for clone2 http://TP1:9081/hello - for clone3.

8/4/2019 WAS_Intro

14/18

Figure 13. Verifying that servers are functioning

If the three URLs return the result shown in

Figure 13

, it demonstrates that all servers in the cluster are functioning and that they're using the correct

ports. Close your browser.

Testing workload managementThe HTTP server plugin provides workload management for a Web application. The IBM HTTPServer was installed at the same time as the WebSphere Application Server on TP1. The plugin

uses, by default, the configuration file plugin-cfg.xml in the

C:\WebSphere\AppServer\config\cells directory. To generate the plugin configuration, use

Environment >Update Web Server Plugin from the Administrative Console.

The deployment manager Administrative Console will generate the file inC:\WebSphere\DeploymentManager\config\cells. So, you need to manually copy the generatedfile where the HTTP server plugin expects to find it, such as

C:\WebSphere\AppServer\config\cells.

The snoop servlet in the DefaultApplication.ear is useful for testing workload. It displays the

name of the process used to execute the request. Launch a browser and enter the URL

http://TP1/snoop. (The IBM HTTP Server is installed on TP1.)
http://www.ibm.com/developerworks/library/i-wasldbal/#figure13http://www.ibm.com/developerworks/library/i-wasldbal/#figure13http://www.ibm.com/developerworks/library/i-wasldbal/#figure13

8/4/2019 WAS_Intro

15/18

Figure 14. Testing workload

ClickReload a few times and see which clone executes the request. You should get a sequence

such as 1233, 1233, and so on, reflecting the relative weightings applied when the clones wereconfigured. Note: If you always see the same clone ID, close your browser and relaunch it. This

will remove the cookie that WebSphere uses for session affinity.

Back to top

Failover and replication in a cluster

Failoveris when a task executed by an application becomes unavailable for any reason, and that

task is executed on another process running the same application. To make this possible, the stateof the original task must be available on the new process. Application Server provides a

mechanism to copy an application state so it can be restored in a different process.

Now it's time to test the failover. The best way to demonstrate failover is to kill a process and seewhat happens. For that, you will need to know the process ID (pid) of each process, which you

can learn from:

The server logs, shown inFigure 15 The .pid file in the logs directory (for example,

C:\WebSphere\DeploymentManager\logs\dmgr\dmgr.pid)

The server runtime information in the WebSphere Administrative Console.
http://www.ibm.com/developerworks/library/i-wasldbal/#ibm-pconhttp://www.ibm.com/developerworks/library/i-wasldbal/#ibm-pconhttp://www.ibm.com/developerworks/library/i-wasldbal/#figure15http://www.ibm.com/developerworks/library/i-wasldbal/#figure15http://www.ibm.com/developerworks/library/i-wasldbal/#figure15http://www.ibm.com/developerworks/library/i-wasldbal/#figure15http://www.ibm.com/developerworks/library/i-wasldbal/#ibm-pcon

8/4/2019 WAS_Intro

16/18

Figure 15. Process ID

Do all the tests to verify that:

Killing a clone in a cluster does not affect other clones. Notice that when the process ofan application server is killed, it is automatically restarted. The node agent is in charge of

monitoring the application servers running in that node, and if it detects that a process has

disappeared for whatever reason (voluntarily killed or a crash), then it restarts it.

Killing a node manager doesn't affect the running clones. Killing the deployment manager doesn't affect the runtime of a cluster, but just prevents

the administration of the cell through the WebSphere Administrative Console.

By doing the tests you will see that there is no single point of failure in the cluster.

Refer to the commands inTable 1to start the deployment manager and the node agent.

During the cluster creation steps, a Replication Domain and a Replication Entry for each clone iscreated. WebSphere provides a replication service that can replicate HTTP session data among

processes and retrieve the HTTP session if the process that currently maintains the HTTP session

fails.
http://www.ibm.com/developerworks/library/i-wasldbal/#Table1http://www.ibm.com/developerworks/library/i-wasldbal/#Table1http://www.ibm.com/developerworks/library/i-wasldbal/#Table1http://www.ibm.com/developerworks/library/i-wasldbal/#Table1

8/4/2019 WAS_Intro

17/18

1. Launch a browser and enter the URL http://TP1/hitcount.Figure 16. Hit Count demonstration

2. Select Session state (create if necessary) and clickIncrement. Repeat the operation afew times until you get 5 for the Hit Count value.

3. In the same browser window, change the URL to http://TP1/snoop.4. ClickReload a few times and see that the same clone always executes the request.

By default, WebSphere uses session affinity. When an HTTP session is created by an

application, the HTTP plugin will try the same clone first for all subsequent requests.

Now see what happens if the clone becomes unavailable.

1. Find the process ID for the clone that executes the snoop servlet and kill it.2. Do a reload in your browser for the URL http://TP1/snoop. You must get a new clone ID

as expected.

3. In the same browser window, change the URL to http://TP1hitcount.

8/4/2019 WAS_Intro

18/18

4. Select Session state (create if necessary) and clickIncrement. The Hit Count valueshould be 6.

This shows that the HTTP session was not lost when the clone was killed and that the replication

service worked as expected.

Back to top

Conclusion

In this article, I showed you how to set up a cluster for load balancing and failover with IBM

WebSphere Application Server Version 5.
http://www.ibm.com/developerworks/library/i-wasldbal/#ibm-pconhttp://www.ibm.com/developerworks/library/i-wasldbal/#ibm-pconhttp://www.ibm.com/developerworks/library/i-wasldbal/#ibm-pcon

was_intro

Documents