Clustering of Java EE App Servers

Last month, we did the first developer oriented story in our clustering

series. The story was widely acknowledged by our readers. As a result we have

been emboldened to pursue the developer angle this time as well. Now we have

deployed an App server on top of our cluster. To do so, we decided to go with

BEA WebLogic Server and ran it on our 20 node cluster. We have not talked about

any benchmarking on the Webapp cluster but have only talked about its

deployment. Next month we promise to deliver more of this along with the

performance testing and tweaking stuff.

Clustering concepts



For enterprises deploying huge and complex applications over Java EE application
servers ensuring two aspects becomes a life-line. First is ensuring high

availability of their applications, and the second of course is scalability.

Availability in this context is the ability to keep the application up and

running at all times despite server failovers, and scalability refers to the

acceptance of any number of client requests without an apparent degradation in

performance. Talking in application server terms a cluster means a group of

servers working in conjunction to transparently provide services (for example

JNDI support, JMS, EJB, component failover, Servlets and more) to ensure the two

aspects aforesaid. The vendors provide different definitions for the same

concept as each of them, viz. BEA, Sun, IBM and Oracle implement it differently.

The implements differ from being one where servers assign a request to a

particular member in the cluster, to one where in we have a coupled architecture

defined. Another way of categorizing the differences between the application

servers is the way they use the underlying storage. Here again you can either

have a cluster where each of the member servers have their own storage and their

own copy of applications running in them. It becomes nightmarish to perform

updates and maintenance on such a cluster as each update needs some or the other

change throughout the cluster. The other way is to deploy a cluster on a shared

storage wherein all the servers share a single copy of the applications and

other resources. However, in such cases the storage has to be capable enough to

provide failover or fallback capabilities, SAN becomes quite a necessity in such

implementations, and it is the advent of this storage technology that has made

this approach failover capable.

Implementation types



The implementation types can be classified into three major types for the
application servers providing clustering support. Although all of them are based

on JNDI there clustering method is essentially a derivative from their JNDI

implementation. Some servers utilize an Independent JNDI tree based

implementation, wherein each of the participating server's JNDI tree is

independent and thus none of them have any information about the



existence of other servers in the cluster, the inherent advantages are easy
scalability as all you need to do is add a server, and very high convergence in

the cluster, that is achieved as soon as two machines are up. The one big

disadvantage is the fact that failover is heavily left over for the developer,

as owing to its structure this can't be readily provided by the servers. The

second one is the Centralized JNDI tree architecture wherein the JNDI trees are

centralized and use the CORBA based CosNaming service for JNDI. Name Servers

keep track of the JNDI tree and on startup every server binds itself to the tree

as well as the name servers. Though getting an EJB reference becomes a simple

process here, the setup requires quite some time to recover in case one of the

name servers fail because all the servers bound to it have to rebind all of

their objects again to the new failover name server. The last one we take up

here is the 'Globally Shared' JNDI tree architecture. In this architecture

while each server during startup binds its objects to the globally shared JNDI

tree, they also maintain a local JNDI tree to which also all the objects are

mapped during startup. The advantages with this approach are faster JNDI lookups

and failover for both local remote stubs due to presence of both local and

global shared JNDI tree. Due to its shared nature the global tree makes each

server in cluster aware of all the bounded objects and their locations as well.

All the servers use IP multicast to initially announce their presence at startup

to the tree and all the other servers in the cluster. This is a drawback of such

implementation as it generates a lot of traffic during startup. The BEA WebLogic

server that we'll use for implementing the cluster uses this type of JNDI tree

architecture.

Setting up a Java EE cluster



We used the BEA WebLogic 9.0 for setting up an Application Server Cluster
because of the implementation type of the server. We installed identical copies

of WebLogic on a cluster with 10 nodes, each of which were running on 256MB of

RAM and an Intel PIV 2.4GHz processor. The cluster's master or management node

add an additionalone GB of RAM. There are a few prerequisites as far as cluster

of BEA servers is concerned. The cluster should have only static IP Addresses on

all the nodes, this is because the domain configured in the BEA server is

completely independent of the Windows domain. The cluster should contain one

Administrative Server that is used to control all other servers running in the



cluster nodes, which are called 'Managed Servers'. All the servers part
icipating in the cluster should be identical installations i.e. of the same

version. A minimum 1 GB RAM and at least 2 GHz processors are required on each

machine for server installation.

Creating Domain and Administration Server



We first installed the server on our controller, which was a pretty simple
procedure. Once you have installed the server you need to start the 'Configuration

Wizard' form BEA Products>Tools>Configuration Wizard in Programs menu.

The screen starts off with options for creating a new domain or extending an

existing one. Choose the former option and proceed. You then need to provide the

username and password for administration of the domain you are about to create

on the cluster. The screen that follows gives an option for additional

configurations



accept the option for additional configuration and proceed to the 'Administration
Server Page'. Over here you need to give a name to the administrative server,

the IP address of the controller enables the option for SSL as we will need that

later. In the following pages of the wizard you can add the machine for the

administrative server by giving it a name and providing the machine name and IP

address of your cluster controller. Also in the 'Node Manager Listen Address'

column provide the IP address of the controller. The Node Manager communicates

to the managed servers in the cluster over SSL, the port number is provided by

default so you can then proceed to add the machine on which the administrative

server is running i.e. the controller. Skip the Configure Manage Servers pages

and the pages that follow as we'll do those tasks later. The wizard then

reaches the final page where you provide a name for the domain and click 'Next'.

The wizard creates the domain and all the configurations that you have provided.

Install the application server on each of the nodes that will participate in

your cluster after the Administrative Server and Domain have been constructed.

Adding Managed Servers



To configure the cluster we need to add managed servers, their machines and then
assign each of the managed servers to their respective machines. All of which

can be done by launching the Admin Console from BEA Products>User

Projects>Your Domain>Admin Server Console in the Programs menu. Where Your

Domain is the domain name you have provided during domain creation in

Configuration wizard. On the console home page, there is a top left panel called

the 'Change Center.' Basically whatever changes we make to configurations

are applied by the server after locking the configuration files, thus for any

changes we first need to obtain a lock on the configuration file by clicking on

the 'Lock & Edit' button in that panel. Once through with the changes

you need to click the Apply Changes button in the same panel for changes to take

effect.

On the home page of Admin console click on the Servers link to add a new

managed server. In the Summary of Servers page that opens you will see the

administrative server in a table with all the buttons on the page disabled.

First click on the Lock & Edit button in the Change Center to activate the

buttons. Click on 'New' button to add a managed server. In the Create a New

Server page provide a name for the managed server. In the Listen Address field

provide the IP address of one of the cluster nodes, and you can keep the port

number to default. Similarly, add Managed Servers for each node on which you

have installed the server. Once you are done with it, click on the 'Activate

Changes' button to commit the changes made. The Summary of Servers shows all

the servers you have added. Now we need to add machines and then assign servers

to machines. For this click on Machines on the home page of the console and from

the Summary of Machines page click on the New button, you just need to provide a

name for the machine, and in case the nodes are running on windows keep the OS

choice as other in the drop down list for specifying OS in the page that opens.

Create machines for all the nodes running the servers on your cluster.

Once all the machines and servers have been created we need to assign the

servers to machines. For this you again need to go to the Summary of servers

page where you will find all the servers listed in a table format. Click on a

server name to open its Properties page. Choose a machine from the machine drop

down list and commit the changes. Similarly add machines for the servers. The

task left after this is the creation of cluster. This can be done by clicking on

the Cluster link from the main page in the Admin console. Initially the cluster

creation page just asks for Cluster name, a Multicast IP address and a port.

After you have given the information and saved changes, you will reach back to

Summary of Clusters page. Click on the cluster you have just created to edit its

Properties. You will find a Cluster Address field that is to be populated with

either the IP



addresses of all the nodes in the cluster or in case you have a domain name
mapped to the IP addresses you can provide that as well. The defaults should be

kept as such. With this last step you have the cluster completely configured.

Now, to make it up an running you need to navigate to \user_projects\domains\\bin

where BEA home is the root directory of the bea installation and your domain

refers to the domain you have created for the cluster. Issue the following

command from the command line of your controller:

startManagedWebLogic

For example, in our case the command looked like:

startManagedWebLogic PCQ_ManagedServer1

192.168.4.1:7001

You need to issue the command once for every instance of managed server you

want to boot. If the state and health columns show RUNNING and OK respectively

for the managed servers in the Summary of Servers page, kudos! Your cluster is

up and running.

Deploying Apps on a cluster



Deploying applications on a cluster is similar to deploying them on a single
server, the only difference here is that you need to specify the target for

deployment. This in case of BEA WebLogic can either be the entire cluster, or it

can be one single managed server of the cluster.

To deploy an application first obtain a lock by clicking on the Lock &

Edit button on the change center from the home page of the Admin console. Then

you need to navigate to Summary of Deployments page from the home page by

clicking on the Deployments link. Click on the Install button and you can

navigate to the directory where your application archive resides. The server

displays all the applications in that directory. Select the one you want to

install and proceed to the next page. You get two options in the new page. 'Deploy

as a Library' deploys the application as a shared library amongst applications

and 'Deploy as an Application' deploys the application without any sharing.

Choose 'Deploy as an Application' option and proceed to the next page. On

this page you need to specify the target of deployment that can be the

administrative server, or the entire server or a particular managed server.

Choose the option as per your requirement and click Next to view Optional

Settings for the application. After you are through with editing the Optional

settings click on Finish to deploy the application.

You can create managed server entries by simply providing name and IP address for each of the cluster nodes	To add a machine just give a name on this page. For non-Unix OS, the OS type has to be 'Other'
Once all servers and machines have been created, you can map the two on the server properties page	Populate IP addresses of all nodes that will participate in the cluster except the Administrative Server
For deployment, you need to browse the directory containing the application archives and select the one you need to deploy	For installation, choose specifically which managed server will host which component of the Java EE Application