Moving to a Cluster... @ JDJ

You've engineered a J2EE application that has become mission critical for your business operations. You know that downtime will be less acceptable as the business starts to rely more on the application, so you want to start eliminating single points of failure and improve availability. One of your first thoughts might be: "Let's move to a clustered application server environment."

Migrating to a clustered environment is a reasonable thing to do, but if this is your first experience with clustering application servers, make sure you understand what you're getting into when you go to your project owner and tell him or her about your plans.

Project Considerations
Why Are You Migrating to a Cluster?
Before anything, make sure you're migrating to a cluster at the right time and for the right reasons. A clustered application server environment can give you failover capabilities, which will help you sleep a little better at night and should help distribute the load a little bit, delaying the point at which your hardware becomes inadequate. If you're squeezed by tight budgets, make sure you're tackling the highest priority issue in your system so you make the most of your limited resources.

What are the consequences of not doing it? Business owners who have lean budgets might need to understand the chances of downtime occurring and its implications. Also, you could consider alternatives, such as a multiserver environment that doesn't involve clustering. Clustering can give you advantages such as:

• Load distribution
• High availability
• Session failover
• EJB sharing
• Centralized control

However, there are other ways to distribute the load among servers, and you might not be using EJBs for persistence, so you wouldn't need to take advantage of EJB sharing. Adding other server instances in a nonclustered fashion could give you the high availability you desire. Your decision to go with a cluster might come down to whether or not it is important that all users who had been hitting a server keep their session intact and not notice if that server goes down. The bottom line is that there is a cost-benefit consideration that needs to be made, and, usually, if there are external customers or important business processes involved, it is easy to see how failover and clustering can be important. Just remember that you have options.

In any case, be sure that there is a need and be ready to discuss not only the migration costs, but also some of the ongoing costs described below.

One Change at a Time, Please
Migrating to a cluster isn't always straightforward. Don't make your life more difficult by changing the application's functionality as part of your project. If you are managing a migration project, make sure that business owners don't try to tack on new functionality or other application changes as part of the project. After rollout, you'll need to be able to determine if a problem is related to the new environment. Adding new functionality will make troubleshooting that much more difficult after rollout. Also, you'll want to be able to make a fair comparison between the old and new environments based on metrics and measurements, identifying if performance has improved after the migration; changes in functionality will skew such measurements.