Apache Tomcat clustering is important to increase your system’s availability.
In this blog, we break down:
Clustering is two or more independent interconnected systems (nodes,) interlinked to provide reliability. Reliability can come in the form of higher availability (HA,) improved scalability, improved application availability and ease of maintenance.
Independent interconnected systems sounds complicated. But it actually is not.
In this blog, we share an overview of Tomcat clustering.
Tomcat clustering is a group of Tomcat instances that are connected. An instance of Tomcat is an independent system. Clustering instances of Tomcat makes them interconnected.
Tomcat instances in a Tomcat cluster are often referred to as a node. (Individual components in any network configuration can normally be referred to as nodes, but for the duration of this blog, we are referring to nodes as Tomcat instances.)
There are different ways that they can be connected. The Tomcat instances can be running on the same physical device, same virtual device, or disparate systems. There are many different options when it comes to clustering Tomcat.
Apache Tomcat clustering is important to prevent danger to your system.
Many companies run Apache Tomcat as an application container for revenue generating applications. But without clustering, there could be a catastrophic system failure. A solid Tomcat clustering design protects your company from systems failure.
Clustering can solve different problems.
For instance, you have a web application, serving approximately 5,000 concurrent requests, running on your server. Under this load, your single server is maxed out. New users receive “404” errors. Supporting larger numbers of concurrent requests is one of the advantages of high availability clustering.
Another example of a problem clustering is the solution for, failover. If your business is running a web application that earns income for your business and this web application is running in a non-clustered environment, you are at risk.
If your application is on a Tomcat server that is not clustered — and the Tomcat server fails — that source of revenue stops generating money every second the system is down.
If you set up a simple Tomcat cluster containing two instances, you can prevent this issue. In a properly configured cluster, all requests to the failed server will be directed to the remaining working instance. This will preserve your revenue stream even if there is performance degradation from losing 50% of the nodes in the cluster.
These are just some examples of why it pays off to cluster Tomcat.
In addition to these examples above, Tomcat improves your systems ‘availability’. High availability is a goal that many companies seek to improve the appearance and availability of their services.
A normal system’s yearly average uptime is called it’s ‘availability.’ High-availability is a prearranged, contracted level of performance that will be maintained during the contract length. Granted, that is not very easy to understand. An example of high-availability could be: your web server is guaranteed to be available 99.999% of the time (“five nines.”) This means that in a given year the server will have a maximum of 5.26 minutes of unscheduled downtime a year.
To achieve high availability, you need to implement geographic separation. Geographic separation, in regards to our server configuration, is installing nodes of the cluster in geographically different locations. This provides safety against regional power outages and other locational risks like storms and floods.
How Does Tomcat Fit Into Your Tech Stack?Tomcat is just one part of your open source stack. How does it fit in with the rest of your stack? More importantly, how can you build an ideal stack to drive efficiency in the enterprise? 🧱 Stack Builder
Tomcat is just one part of your open source stack. How does it fit in with the rest of your stack? More importantly, how can you build an ideal stack to drive efficiency in the enterprise?
🧱 Stack Builder
To set up your Apache Tomcat clustering configuration, you must evaluate the resources at hand.
There are three types of Tomcat clusters:
What does this mean? A vertically expanding cluster has limited horizontal layout. Horizontal layout would be multiple systems / resources. A vertical cluster is on a single machine. (A machine can be many things, including a physical device or a virtual host.) As need increases, Tomcat instances are spawned on the same machine, using configuration tweaks that allow multiple instances to run on the same system.
A horizontal cluster contains Tomcat instances running on separate machines. Let's say demand for processing increases and you had a pure, horizontal cluster configuration. You would install a new machine, virtual or physical. On that machine is a new Tomcat instance.
Real life is often very different from dictate. Companies rarely have a pure horizontal or vertical cluster configuration. Most systems are hybrids.
Is your setup going to be for multiple applications? Or just a few — or even just one? Do you have applications that require specific hardware? This determines whether or not you decide to use a homogeneous setup.
A homogeneous setup is very common. Companies will often duplicate their Tomcat environment, launching servers on many devices with a simple copy of the Tomcat directory. A Tomcat cluster that has the same web applications deployed on all nodes is considered homogeneous.
Homogeneous setups can be hard to keep truly identical. Sometimes, especially after node failure and replacement, it can be hard to synchronize the Tomcat instances. The best way to do this is to create an image of the Tomcat setup from a node designated as the “primary” node. As long as this image stays up-to-date you can distribute it over as many Tomcat setups as you prefer.
Load balancing happens outside of the Tomcat cluster.
Apache Httpd server has built in load balancing / gateway features. This is a common software load balancer in many enterprise systems.
To use Apache Httpd as a load balancer, you will configure it as a gateway. Once it is aware of it’s “nodes”, it is able to balance traffic across these nodes.
A hardware load balancer (HLB.) performs the same tasks as a software balancer (like the one in the Apache Httpd server). The main difference between a software balancer and a hardware balance (besides price,) is resources.
A HLB has dedicated hardware resources (RAM, Processor, Network adapters, etc..) This allows hardware balancers to perform at a much more efficient rate, while providing more features. This is also an infinitely more expensive method. But you can find many free open source load balancing solutions.
There are many factors in your Tomcat cluster configuration. When choosing how to configure your cluster, you must examine the resources available.
How do you choose your scalability options? This relies heavily on the availability of hardware resources.
For instance, you have 4 low end servers. They have one processor with 1–4 gigabytes of RAM. This would be an ideal situation for a horizontal cluster. Each member of the cluster would be able to run one instance of Tomcat efficiently. One of the servers could be used as a balancer running Apache Httpd server. Here is a drawing of the architecture.
If your situation was a bit different, and you had better servers, you could consider a hybrid cluster. If there are servers available with 2 or more processors and a large amount of ram (8 gigabytes or more) this would be ideal for multiple Tomcat instances. In this configuration you can setup a hybrid cluster by running multiple instances of Tomcat on multiple machines, and multiple instances of Apache Httpd to handle the load of load balancing. This configuration could look something like this:
Determining heterogeneous vs. homogeneous setup can be simple in some situations. The easiest situation is one with a single web application. If there is only one application to deploy, you deploy it to all members in the cluster. This is a very straightforward homogeneous configuration.
Unfortunately most companies do not have one single web application, however, this situation is not overly complicated, unless the company has an extremely large number of applications.
The division of your applications over Tomcat nodes will be your choice. The Tomcat configuration of the nodes will be a little more complicated.
If your company has an application that requires heavy processing and large amounts of ram (HPR1,) you can setup this application on two nodes by itself. After this, take the remaining applications (GUI) and place them on two different nodes in the cluster. This will prevent the GUI application from being bogged down when HPR1 is consuming the CPU and RAM. This cluster might look like this:
There are many things to take into consideration when designing and building your Tomcat cluster:
OpenLogic provides 24x7 support for your Tomcat and Apache Httpd configuration.
We can help you setup and configure your Tomcat cluster. And we can provide the support you need to ensure security, performance, and efficiency in your Tomcat configuration.
That's because we're experts in open source middleware. And we can help you maximize your open source middleware adoption, including Apache Tomcat.
When you partner with OpenLogic, you'll be able to offer your customers an extremely reliable, available service. And you'll have someone to turn to if you run into problems.
Talk to a Tomcat Expert
This blog was originally published on August 3, 2012 and has since been updated for accuracy and comprehensiveness.
Enterprise Solutions Architect, OpenLogic by Perforce
Andrew has been working in the IT industry since 1996, ranging from hardware and networking to application development. Andrew’s #1 specialty is Apache Tomcat, and he is recognized in the Tomcat community as a subject matter expert, assisting the Tomcat open source project in many ways.