 A
Primer on J2EE Clusters for Webhosting
Hosting websites often means guaranteeing
a certain amount of uptime for your clients' sites -- especially
when you are hosting e-commerce sites, where time offline means
money lost. Often, the best way to maintain this uptime involves
using server clusters. This article explains the advantages of server
clusters and describes several cluster configurations you might
consider using, depending on your situation.
Definition of a Cluster
A cluster is a parallel or distributed system consisting
of independent computers that cooperate as a single system. Generally
speaking, clusters offer a way to utilize computer resources more
productively in comparison to when the same number of machines are
working in a standalone format. In a cluster, the total result is
greater than the sum of the separate parts.
Basically, vendors of J2EE application servers implement
cluster technology in one of the following two ways: with and without
a dispatcher. Both implementations have advantages and disadvantages,
but they will not be discussed in detail in this article.
In the cluster implementation with a dispatcher,
the dispatcher stands in front of the whole group of machines and
accepts incoming client requests. To clients, the whole group of
machines in the cluster appears as one unit; the IP address of the
dispatcher is the IP address of the whole cluster. Clients neither
see the IP addresses of the servers in the cluster, nor need to
be aware that there are multiple IP addresses. But cluster administrators,
of course, know the IP addresses of the dispatchers and servers
in the cluster.
The other implementation of cluster technology is
a cluster without a dispatcher. In it, all machines communicate
directly with each other. This type of cluster requires that all
machines have static IP addresses, which must be visible and reachable
for clients.
When clustered, servers are still physically separated
as different machines. They share data storage and management resources,
but they do not share memory or processors. The main advantages
of clusters are scalability, high availability, load balancing,
fail over, and easy administration.
For a big Web project, the above mentioned advantages
of clusters might prove to be vital prerequisites for success, rather
than abstract benefits. Depending on the specifics of the application,
the order of advantages might be reversed; there are times when
high availability is more important than scalability, for example.
What I mean is that the order in which different advantages are
described, does not necessarily reflect their ranking of importance
in all possible cases.
Scalability
The ability to "plug-in" additional resources
at any time, when more power is needed, without having to stop and
restart the system, is one of the main advantages of clusters and
distributed systems. With J2EE application servers, which can run
on various platforms and operating systems (Windows, Linux, Solaris,
etc.), scalability means that administrators are able to use less
or more powerful, cheaper or more expensive equipment to achieve
uninterrupted functioning of the system. Additionally, scalability
allows administrators to easily add new services to the already
existing ones, thus providing the opportunity to effortlessly integrate
with existing systems.
High Availability
Under most scenarios, high availability is the main
advantage of clusters. High availability encompasses the periods
during which the cluster is accessible and services clients' requests
within a reasonable time. For non-critical applications, availability
of 98 percent (i.e. about seven days a year cummulative downtime)
might be acceptable, while for others availability of at least 99.99
percent (about 50 minutes a year cummulative downtime) is mandatory.
High availability is a prerequisite for the other
two truly important cluster advantages: load balancing and fail
over.
Load Balancing
Load balancing allows incoming requests to be sent
for processing to the least busy server in the cluster, thus increasing
productivity and better utilizing available resources. If there
is no single point of failure, load balancing can dramatically increase
performance. A prerequisite for load balancing is the existence
in the cluster of multiple copies of the object that can perform
the particular job.
There are several algorithms for load balancing
used by all or some of the J2EE application server vendors. Generally,
these algorithms are: round-robin, weight-based, and random.
The round-robin load balancing algorithm is the
simplest. It cycles through the list of active server instances
and when a new request arrives, it is sent to the instance whose
turn it is to service a request. Round-robin can be used for any
type of clusterable objects.
The weight-based algorithm is more sophisticated.
It calculates the load of different participants in the cluster
and sends the request to the least busy one. Its implementation
with different vendors differs, but usually can be used only for
some of the clusterable objects, such as EJB or RMI objects.
The random load balancing algorithm, as the name
implies, sends incoming requests to any server that is available
in the cluster. Again, it is applicable only for EJB and RMI objects.
Fail Over and Redundancy
Fail over means that if one of the participants
in the cluster (a server or a dispatcher) is temporarily or permanently
unavailable, its functions are undertaken by another participant.
The result is that incoming requests are automatically redirected
to a running server, without interruption in service.
For true fail over and redundancy, there must not
be a single point of failure in the system. This means that if the
database, for instance, is the bottleneck, no application server's
cluster solution can compensate for this. Also, hardware and connectivity
requirements must be taken into account when planning for faill
over and redundancy.
Easy Administration
Managing the cluster from a centralized control
point is easier than managing standalone servers as separate machines.
Integrated administration gives at a glance the complete view of
all critical components, allowing administrators to fine-tune their
performance. The tools for remote administration and cluster-level
log files also contribute to easier administration and increased
efficiency.
Determining the cluster architecture is the first
step in configuring the cluster. Since there are many diverse deployment
scenarios, it is logical that the possible configurations are also
diverse. Although there is no universally recommended cluster architecture,
there are some universally valid rules to keep in mind when configuring
the cluster.
First, you need to consider what kind of applications
will be deployed. Then, taking into account the available hardware
resources, consider how you will implement load balancing and fail
over. It is also very important to think in advance about which
objects will be clustered and how exactly you plan to do it. As
you have already guessed, there are so many possible cluster architectures
that there is hardly one that fits all cases. The next three diagrams
present three very basic architectures.
A Combined Tier Cluster Without a Dispatcher
The next diagram presents a basic confuguration
for a cluster solution without a dispatcher. This is a combined
tier architecture and each server runs the same objects (HTTP pages,
servlets, EJBs, etc.) as the other servers in the cluster. No server
instance communicates directly with clients, but all servers can
communicate directly with each other and with the backend (the database)
when needed to service a client's request.
The advantages of a combined tier without a dispatcher
configuration are its simplicity and robustness, and this is absolutely
enough in many situations, although it does not fully utilize the
load balancing and fail over capabilities of clusters. In some cases
you will choose hardware load balancing, which needs additional
configuration for faultless communication with the cluster.
Combined Tier Cluster With a Dispatcher
The combined cluster tier with a dispatcher is basically
the same as the one without a dispatecher in regard to the way objects
(HTTP pages, EJBs, JSPs, etc.) are deployed. In this case, the dispatcher
is part of the cluster itself, and no external hardware or software
is necessary to ensure load balancing and fail over. Again, simplicity
and ease of administration are among its major advantages, but the
dispatcher itself could turn into a bottleneck and a single point
of failure.
Of course, it is not mandatory to have only one
dispatcher. If the load is heavy, you could easily set up two or
more dispatchers, and it is possible for each of them to communicate
with all the servers in the cluster. It is true that several dispatchers
in a cluster are like several managers of a team; it takes more
communication and synchronization efforts to avoid each dispatcher
giving contradicting requests to the the servers, but for servicing
millions or billions of clients' requests, this is the escape from
the single point of failure trap.
A multi-tier architecture with a dispatcher can
actually be called a cluster within the cluster, because there are
separate server instances which host the Web presentation layer
(HTTP pages, JSPs, and Servlets), while EJB and JDBC objects are
located on separate machines. For big applications, a configuration
of that kind could be the best choice, because it provides better
load balancing and fail over. It also gives a chance to adjust to
the application specifics. For instance, if your application relies
heavily on HTTP but there are no frequent invocations of EJBs, you
can have only two servers for EJBs, and perhaps five for the Web
layer. But if there are a lot of static pages that need to be serviced,
you can consider even a separate HTTP cluster.
Generally, the Web and the objects layer do not
communicate intensively with each other. If they do communicate
heavily, then a combined tier architecture could be more appropriate.
The dispacher communicates with all server instances and redirects
incoming and outgoing requests as necessary. All servers communicate
with the database. For better redundancy, you can have a second,
standby database.
The three architectures described here are neither
the only ones, nor even the most typical ones. Since each application
is unique, there is no single architecture that can be applied in
all cases. The aim was more to give you a basic idea of how J2EE
clusters work. When you come to the point of deploying your applications,
you will no doubt have to read in more detail about the particular
server you have chosen on which to deploy your applications.
|
Latest
articles