Too Much Isn t Always a Good Thing

What Is Clustering?

In general, a cluster is a group of redundant services that work together and in parallel to provide a more scalable and more reliable application platform than a single server can. Clustering in an application is purposely made transparent to its clients . Even though there can be many servers in the cluster, a client typically will not be aware which server in the cluster is servicing a request.

Unfortunately, the EJB 2.0 Specification does not provide any standards for supporting load balancing, or specifically clustering, as part of an enterprise application. How and even if a vendor provides load-balancing features as part of its EJB server product is left to the vendor to decide. All the well-known EJB vendors, and many of the lesser-known vendors , do provide some support for clustering. As you'll see later in this chapter, just which pieces a vendor can cluster and precisely how they're clustered can vary.

A clustered enterprise application provides two important features beyond one that is not clustered. Those features are

• Scalability

• High availability

Scalability

Scalability is the capability to dynamically add new resources ( potentially software and hardware) to the enterprise application architecture without much effort and without changing software code, to increase the capacity of the application.

This means that, through administration and management of the application, you are able to grow the capacity without making programmatic changes to the application. This growth might be adding hardware, such as memory or disk drives , or it could be just starting up more services to handle more requests . The most important point is that it should be effortless and not require any additional software changes to the application.

High Availability

High availability means that the application is available to service the end users for a high percentage of the time. In some cases, this might mean 24 hours a day, 7 days a week, and for other applications, it can just mean most of the time. Availability usually is expressed as a percentage between 0 and 100 percent. A very important point to remember about availability is that it's not how many times the application goes down, but rather the total amount of down time. So, an application might fail often but still achieve a high availability. Of course, developers hope that their applications don't fail often, either. You could also have an application fail once and be down for a considerable amount of time for repairs and have a low availability.

The level of availability for hardware or software is sometimes referred to as levels of nine. Levels of nine indicate the number of the nine digits in the amount of availability. For example, 99.999 is said to have five levels of nine because there are five digits. Table 22.1 shows the approximate percentage of down time for a particular level.

Table 22.1. Application Availability Levels

Availability	Approximate Hours of Down Time Per Year
99%	87.6 hours
99.9%	8.8 hours
99.99%	.9 hours
99.999%	0.09 (about 5 minutes)

Looking at Table 22.1, you might think that four levels of nine (about an hour of down time per year) is an awesome amount of availability. However, if the application was for a brokerage firm and the application was down for five minutes every day for 12 straight days when the markets opened, the business would lose a lot of revenue. It's still only about an hour total time and would still be four levels of nine, but very bad for the company. As you can see, how much time and when it's down is much more important than the number of times.

A part of what makes high availability possible is the concept of failover. Failover assures that even if a system failure occurs, other redundant components or services can handle the requests and insulate the clients from the failures. The capability to failover from a failed component or service to another functioning one increases the availability of the application to its clients. The switchover because of a system failure should be transparent to the end client.

Because there is no clustering component to the EJB specification, our discussion will have to be a little generic. If you need specific information on whether or how a vendor supports clustering in its application server, you'll need to check the vendor's documentation.