J2EE clustering, Part 1

Clustering technology is crucial to good Website design; do you know the basics?

1 2 3 Page 3
Page 3 of 3

In a WSI-based cluster, a user connects to a dispatcher, which load balances and failovers HTTP requests to Web servers. Each Web server has a plug-in that points to a load balancer fronting a SilverStream cluster. The WSI cluster does not use redirection, so every HTTP request is load balanced across any of the Web servers. The secondary load balancer insures failover at the application server tier. A WSI architecture advantage over the dispatcher architecture: the ability to independently scale static and dynamic portions of a site. In a major disadvantage, the ArgoPersistenceManager is required for HttpSession failover. In either architecture, EJB clients still cannot failover in between method calls. EJB failover totally remains the developer's responsibility. Finally, SilverStream does not support clustered JMS.

HttpSession failover:

SilverStream provides HttpSession failover by a centralized database and the ArgoPersistenceManager. The solution, unfortunately, is proprietary. Instead of using the standard HttpSession to store session information to a database, you must use the product's ArgoPersistenceManager class -- a drawback.

Cluster convergence time:

Least, when compared with centralized and shared global JNDI tree clusters.

Single points of failure:

None with the above architectures.

Flexible cluster topology:

All clustering topologies supported.

Maintenance:

Cache manager and dynamic class-loaders provide an easy way to deploy and upgrade running applications with little interruption to active clients. When an application is updated on one server in the cluster, the update gets written to a database and the cache manager invalidates the caches on all other servers, forcing them to refetch the updated parts of the application on next access. The only downside of this approach is the time needed to load applications out of the database and into active memory during the initial access.

BEA WebLogic Server 6.0

Figure 7. BEA WebLogic Server 6.0 topology. Click on thumbnail to view full-size image. (6 KB)

General cluster summary:

WebLogic Server implements clustering through a shared global JNDI cluster tree. Under this setup, when an individual server starts up it puts its JNDI tree into the shared global JNDI tree. The server then uses its copy of the tree to service requests, allowing an individual server to know the exact location of all objects in the cluster. Stubs that clients utilize are cluster-aware, meaning that they are optimized to work on their server of origin but also possess knowledge of all other replica objects running in different application servers. Because clusterable stubs have knowledge of all replica objects in the cluster, they can transparently failover to other replica objects in the cluster. A unique feature of WebLogic Server is in-memory replication of stateful session beans as well as configurable automatic failover of EJB remote objects. WebLogic defines clusterable as a service that can run in a cluster. JMS is clusterable but each Topic or Queue only runs on a single server within the cluster. You cannot load balance or failover JMS Topics or Queues in a cluster -- a major weakness of WebLogic's JMS implementation.

HttpSession failover:

WebLogic Server provides HttpSession failover by transparent in-memory state replication to an arbitrary backup server or database server. Every machine in the cluster picks a different backup machine. If the primary server fails, the backup becomes a primary and the primary picks a new backup server. A unique feature of WebLogic is cookie independence. Both HP Bluestone and Enterprise Application Server require cookies for HttpSession failover. WebLogic can use encrypted information in the URL to direct a client to the backup server if there is a failure.

Single points of failure:

JMS and Administration server.

Flexible cluster topology:

All clustering topologies supported.

Maintenance:

WebLogic's weakness is maintenance. Although BEA has made positive steps with configuration synchronization, WebLogic Server does not provide any monitoring agents, dynamic application launchers, or file synchronization services. This shortfall requires you to buy a third-party solution for the single points of failure or implement sneaker HA. With sneaker HA, all WebLogic Administrators have to wear Nike Air Streak Vapor IV racing shoes. If a server goes down they must sprint to the machine and troubleshoot the problem. However, if you employ SAN you don't need file synchronization services, but most developers are just beginning to realize the benefits of SAN.

Analysis

Overall BEA WebLogic Server 6.0 has the most robust and well thought-out clustering implementation. HP Bluestone Total-e-Server 2.7.1, Sybase Enterprise Application Server 3.6, and SilverStream Application Server 3.7 would be the next choices, in that order.

Picking the right application server entails making tradeoffs. If you are writing an application where you will have EJB clients (applets and applications), Web clients, extensive use of HttpSession (for caching), and ease of scaling and failover, you will want to go with BEA WebLogic 6.0. If your application requires heavy use of JMS and most of your clients are Web clients, Bluestone will probably be a better choice. From a clustering standpoint Sybase Enterprise Application Server 3.7 lacks important clustering features such as JMS, in-memory HttpSession replication, session-based server affinity, and partitioning through Web server plug-ins. Sybase Enterprise Application Server 3.7 does, however, bring to the table file and configuration synchronization services. But this benefit is minimized if you are using SAN. SilverStream Application Server has the weakest implementation of clustering and lacks clustered JMS, in-memory HttpSession replication, and failover.

Conclusion

In this article you have gained a foundational understanding of clustering, clustering methods, and important cluster services. We have examined the benefits and drawbacks of each application server and discussed the important cluster-related features to look for in an application server. With this knowledge, you now understand how to set up clusters for high availability and scalability. However, this represents just the beginning of your journey. Go out, get some evaluation clustering licenses, and Control-C some application servers.

In Part 2, we will start writing code, test the application server vendors' claims, and provide failover and cluster strategies for each of the different application servers. Further, we will use the J2EE Java Pet Store for load testing and cluster convergence benchmarks.

Abraham Kang is the scalability and high availability architect for Infogain's Delivery Operations Group. He has over a year and a half of experience clustering J2EE application servers. Moreover, he is a Sun-certified programmer and developer, Oracle 8i-certified professional DBA, Cisco-certified network associate, and Cisco-certified design associate. Abraham would like to thank his manager, Jessie Spencer-Cooke, for supporting his efforts to write this article and providing a environment for excellence.

Learn more about this topic

1 2 3 Page 3
Page 3 of 3