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