he latest version of the Tomcat 5 servlet container provides built-in support for monitoring server components using the Java Management Extensions (JMX) API. This article concentrates on the clustering and load balancing components, and provides an overview of configuring and using JMX MBeans in managing the elements in a J2EE cluster. You'll also see how to use the JMX API to automate various administration tasks in the Tomcat container.
A sample Web application (see the downloadable sample code
) to demonstrate the steps involved in configuring Tomcat server instances with load balancing and clustering features enabled. This application provides the ability to monitor the run-time statistics of the cluster elements such as load balancer, cluster members, session manager, and replication valve.
Clustering, Load Balancing, and Fault Tolerance
|What You Need
|Tomcat 5, Ant, MX4J, Commons Modeler, Commons Digester, Commons Collections, Eclipse
Before getting into the design and implementation details of a Tomcat cluster, here's a brief overview of clustering in J2EE servers. A cluster is a group of application servers that transparently run a J2EE application as if it were a single entity. In other words, the application runs on multiple cooperating servers. Clustering helps achieve scalability
(a system's ability to support increasing numbers of users) because you can add additional servers to the cluster, and also helps achieve high availability
(providing redundancy in the system so if one server instance fails for some reason, another member in the cluster can transparently take over the Web requests).
Load balancing, also known as "high availability switch over," is a mechanism that distributes server load to different nodes within the server cluster based on a load balancing policy. For example, rather than execute an application on a specific single server, the system executes that application code on a dynamically selected server. When a client requests a service, the load-balancing system selects one (or more) of the cooperating servers to execute the request.
Fault tolerance is a system's ability to allow a computation to continue or "fail over"as transparently to the end user as possibleon another server when a server in the cluster goes down. The cluster service should detect when a server instance is no longer available to take requests and stop sending requests to that instance. It should also periodically check to see if a failed cluster member is available again, and automatically add it to the pool of active cluster nodes.
Many Web applications need to store per-user values on the server. The values for all the individual active sessions are collectively called session data. The problem is that each server in the cluster must have equal access to the session data for load-balancing and fail-over to work. One way to handle the problem is to persist session state at multiple servers in the cluster, a process called session replication. With session replication, a client can seamlessly get session information from another server in the cluster if the original server, on which the client first established a session, fails. The main goal of session replication is to prevent the loss of any session information if a cluster member crashes.
Clustering in Tomcat 5
Clustering was available in Tomcat's previous version (version 4.1) as a third-party library (JavaGroups is a popular choice for adding clustering capabilities in Tomcat 4.1); but in Tomcat 5 clustering is built-in. It's available in the main installation package. Session replication in Tomcat 5 is an all-to-all replication of session state, meaning that session attributes are constantly propagated to all other cluster members.
However, load balancing capability was not available in the previous versions of Tomcat. Until now, people have used the Apache Web server as the popular choice for load balancing HTTP requests. Tomcat 5 provides load balancing in three different ways: using the JK native connector, using Apache 2 with mod_proxy and mod_rewrite, or using the balancer Web application.
For more details on Tomcat 5 support for clustering refer to the article "Clustering and Load Balancing in Tomcat 5, Part 1".
Server Manageability Using JMX
The Java Management Extensions (JMX) specification defines the architecture, services, and API for the distributed management of resources using Java. As a Java technology standard for instrumentation, JMX introduces a JavaBeans model for representing the manageability of resources and a set of services to help manage these resources. Similar to JDBC (for accessing relational databases) and JNDI (for accessing application and directory resources), JMX is transparent and hides the details of managing enterprise resources. It acts as an isolation layer between the applications and the management systems. In real-world applications, JMX is used for JDBC connection pool management, HTTP session management, cache monitoring, and JMS queue management.
JMX has three main components (layers) that work together to provide manageability for J2EE application resources.
- Instrumentation Layer: This layer contains managed beans (MBeans) and their manageable resources.
- Agent Layer: This contains JMX agents used to expose MBeans, such as MBean Server and monitoring, timing, relation, and class-loading services. These standard agent services include M-Let Service, Timer Service, Monitoring Service, Relation Service.
- Distributed Layer: This layer contains components that enable management applications to communicate with JMX agents. The distributed layer consists of one or more adapters that are used to translate between JMX components and their respective management systems. Some of these adapters are HTTP Adapter (Web pages for viewing management data), RMI Adapter, SOAP Adapter, and SNMP Adapter.