Clustering with JBoss 3.0by Bill Burke, Sacha Labourey
Whenever an organization thinks about building and deploying a J2EE application, they think scalability and reliability. How can my Web site stay up 24/7? Will my infrastructure be able to handle the traffic? How can I ensure that I don't lose any transactions or data? How do I manage large server farms?
To answer these questions, many Java architects look to their application server's clustering features. This article looks at the kinds of features needed to develop robust J2EE applications and how JBoss 3.0, an open source J2EE application server, can be the solution of choice.
The following is a clustering feature overview for JBoss 3.0:
- Automatic cluster membership discovery.
- Fail-over and load-balancing features for JNDI, RMI, Entity Beans, Stateful Session Beans with in-memory state replication, and Stateless Session Beans.
- Pluggable load-balance policies.
- HTTP session replication with Tomcat and Jetty (CVS
- Dynamic JNDI discovery. JNDI clients can automatically discover the JNDI
- Cluster-wide replicated JNDI tree.
- Network Boot.
- Farming: Distributed cluster-wide hot-deployment.
For a more detailed feature matrix, see this PDF file.
Fail-over and Load-Balancing
HTTP and EJB
A good J2EE application needs to be scalable and reliable. HTTP session replication and EJB client fail-over are the first things people usually think about. Although JBoss does provide these features, you need to ask yourself the question, "Do I really need to cluster-enable my HTTP sessions and EJBs?"
For Web applications, a hardware- or software-based HTTP load-balancer usually sits in front of the application servers within a cluster. These load-balancers can be used to decrypt HTTPS requests quickly, distribute the load between nodes in the cluster, and detect server failures. The usual setup is to have a user session live entirely on one server that is picked by the load-balancer. This is called a "sticky" session.
HTTP session replication is expensive for a J2EE application server. If you can live with forcing a user to log in again after a server failure, then an HTTP load-balancer probably provides all of the fail-over and load-balancing functionality you need, as far as HTTP requests go. Also, since JBoss recommends running your servlet engine (Tomcat or Jetty) within the same VM for performance reasons, you really don't need EJB fail-over or replication either.
Some available HTTP load-balancers are:
Now, you may not need HTTP-session or EJB clustering, but if you are storing things other than EJB Home references in your JNDI tree, then you may need clustered JNDI. JBoss has a cluster-wide JNDI tree that is replicated across the entire cluster. It requires no additional configuration and boots up with a cluster-enabled JBoss configuration. Remote JBoss JNDI clients can also implicitly use multicast to discover the JNDI tree.
It should be easy to configure the J2EE nodes that make up your cluster. You shouldn't have to manage lists of servers or hire an expensive consultant to do the magic to get your cluster up and running. One of the primary goals of the first release of JBoss clustering was for it to run out-of-the-box with minimal (or no) additional configuration.
JBoss cluster nodes automatically discover each other when they boot up -- out-of-the-box and with no additional configuration. Nodes that join the cluster at a later time have their state automatically initialized and synchronized by the rest of the group. As EJBs are deployed, all nodes in the cluster update their lists of standby fail-over targets. This applies to client proxies as well. Clustering should be seamless to the client application and the application server. Auto-discovery is one of the things that make this possible.
As your cluster topology starts to grow beyond two nodes, management of installations and upgrades of your application can become a problem. Although NFS could be used to alleviate this, it could introduce a single point of failure into the system and is not viable in some large, geographically distributed applications.
To solve this problem, JBoss 3.0 introduces the concept of a net-boot through its JMX Microkernel-based architecture. With a small 40K JAR, you can boot up an entire cluster-enabled J2EE application just by supplying a URL on the command line. You can try a demo of this.
Pages: 1, 2