Clustering in the Brave New Virtual World

High Availability(HA) and Fault Tolerance(FT) in the Enterprise Java world is not the same as HA/FT in the VMware world, but the overarching goals are the same. HA in the Java world involves proper load balancing across more than one application server so that a single server failure does not take the entire application offline. The worst case scenario for the user is to get kicked out of the application and bounced back to the login page. The goal of FT is to eliminate the user kick out event and make the failover seamless. In the Java world, FT is usually delivered by using application server clustering. The biggest difference between Java and VMware FT is Java based clustering does not shadow copy at the VM(Virtual Machine) level. Instead only the "application state" is copied. On the HA side, Java applications will use either a hardware or software load balancer instead of vSphere and DRS(Distributed Resource Scheduler). Java based FT is painful. Does replication of just "application state" warrant the added complexity?

Clustering is a Cluster

For years, clustering has been a hot button issue in the Enterprise Java world. Architects desire both High Availability(HA) and Fault Tolerance(FT) and there are two leading approaches to HA/FT. The first approach is to architect a purely stateless solution and the other is to "minimize the use of state". In a stateless application, there is no need to replicate state and the only thing required to deliver HA/FT is a load balanced set of application servers. The "minimize the use of state" part was not the original intent of J2EE but Stateful Session Beans(SFSBs) and vertical scaling delivered worst of breed results. Worst of breed in that the hardware and software was extremely expensive, yet a very profitable business for BEA and IBM. And, even the best SFSB based systems performed and scaled worse than a stateless architecture. Even JBoss, the low cost alternative to WebSphere/Weblogic, was unable to deliver adequate scalability and performance for applications that use a lot of state. Thankfully, smart architects altered software design such that either "stateless" or "minimized use of state" is used. And, that design decision made Tomcat and JBoss a better, cheaper platform for most enterprise Java applications.

Modern Enterprise Java

For a typical Java application there are only two major "state" components:

1. HTTPSession - usually limited to user profile data or potentially "web conversations". Each user has an HTTPSession and that session remains available as long as the user is logged in to the application. HTTPSession is like a student's back pack. You can shove the back pack full of heavy books or go with an iPad. Spring Webflow, Grails and Seam provide a very nice way of "minimizing the use of state" just like an iPad minimizes a back pack's weight. More information about Spring Webflow based conversations can be found here: http://static.springsource.org/spring-webflow/docs/2.0.x/reference/html/ch03s05.html
2. Second level data cache - This state component sometimes violates the "minimized use of state" mantra but it is very common. Database intensive Java applications will store database query results in the cache so that future requests do not result in a subsequent round trip to the database. Most second level caches are not clustered, and a clustered second level cache is usually a bad sign unless a high end caching product like Terracotta or GemFire is used. For high end products, cache clustering is handled separate from application server clustering. A good cache will be "distributed" and "transactional", which is just a fancy way of saying that the cache product provides its own HA, FT and proper data synchronization with the underlying database.

Bottom Line

Virtualized Java applications may benefit from VMware based FT/HA instead of traditional load balancing(HA) and clustering(FT). There are not enough vSphere/FT/HA based Java deployments to prove that traditional load balancing and clustering are obsolete but that may be the case. Right now, the best practice way to deliver HA/FT is to have a:

• Properly configured hardware or software load balancer (F5, Cisco, Apache, ERS).
• Properly architected application that minimizes the use of state and a lightweight application server that supports HTTPSession clustering (Tomcat, tcServer, JBoss).
• Properly architected data cache that is either NOT clustered or relegate data caching to a high end data cache product. (Ehcache or JBossCache for non-clustered), (GemFire or Terracotta for a clustered cache).
  

DISCLAIMER: I am employed by VMWare. The views expressed on this blog do not necessarily reflect the views of my employer. I am completely responsible for all content displayed here. Furthermore, no content of cfossguy.blogspot.com has ever been reviewed and/or endorsed by my employer.