An In-Depth Look at Tomcat’s Clustering Mechanisms

  

 Email Article  

Tweet  

  

This post is part 1 of a 3 part blog series that will look at leveraging Apache Tomcat clustering, in order to increase your system’s availability.

The entire series of posts will include:

1. What is clustering & why should you cluster your tomcat application servers?
2. Different clustering setups and choosing the best for I.T. infrastructure
3. Example configurations and common issues

Please feel free to leave your comments, questions, or suggestions at the bottom of the post.

The dangers of “unreliable” systems

Running apache tomcat as an application container for revenue generating applications is a decision many companies make every day.  Unfortunately, this is where the decision making stops.  The design should continue to include a system configuration that will protect these cash generating applications even in the event of catastrophic system failure.  This is where tomcat clustering plays a role.  By implementing a solid clustering design you protect your company from systems failure

What is clustering?

Clustering, when referring to Information Technology systems, 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, although it is not.  In the case of this blog we are referring to tomcat systems.  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.)

A tomcat cluster is a group of tomcat instances that are connected.  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, and we will discuss these in detail later in this blog.

Why should you cluster?

Clustering can solve different problems.  For instance, you have a web application, serving approximately five thousand concurrent requests, running on your server.  Under this load, your single server is maxed out.  New users are receiving “404” errors. Supporting larger numbers of concurrent requests is one of the advantages of high availability clustering.  The goal of HA clustering is the “five nines,” and we will discuss this later.

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.  Setting up a simple tomcat cluster containing two instances, this issue is preventable.  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, or at least research a little more.  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 pre-arranged, 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.

What clustering setup is best for my architecture?

In the next installment of this blog we will discuss the different clustering configurations.  Additionally, we hope to help you choose which clustering configuration fits you and your business the best.

The information contained in this blog is good motivation to rethink your single application service instance design.  If you follow along in the next part of this series, we will give you the information you need to build a reliable, stable, and available application container platform.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @CloudSwing

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.