tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Tomcat clustering for simplified config
Date Wed, 07 Oct 2015 07:43:22 GMT
On 07/10/2015 00:36, Mark Bramer wrote:
> Hi list,
> 
> I just signed up to the list - please forgive any newb mistakes but hopefully I'm following
the right format, style and content.
> 
> I currently work in a production environment with eight app servers, all running the
same version of Tomcat (currently 7.0.62).  Four servers support version 1 of our app, the
other four servers support version 2.  Within each group of four, two serve completely open
content via 80, the other two support queries of sensitive data via 443.  Servers are named
with a number system where all odd-named servers are for the secure content, all evens are
open.  
> 
> So here's the setup in a hopefully clearer portrayal:
> 
> App Version 1:
> Server 01: secure queries via 443
> Server 02: open content via 80
> Server 03: secure queries via 443
> Server 04: open content via 80
> 
> App Version 2:
> Server 05: secure queries via 443
> Server 06: open content via 80
> Server 07: secure queries via 443
> Server 08: open content via 80
> 
> Each pair of even and odd named servers are *conceptually* linked, but physically stand
on their own.  All http traffic and https traffic for each version is directed to a particular
server by a load balancer.  No Apache Web Server is in the mix and we would like to keep it
that way for simplicity.  Load-wise, our eight Tomcats are not taxed.
> 
> I'm responsible for upkeep of these servers, which requires regular version upgrades
and configuration changes when any vulnerability is found by regular, periodic Nessus scans
(http://www.tenable.com/products/nessus-vulnerability-scanner).  Sometimes the changes are
related to ciphers, sometimes other things, but I'd say 90% of the time, I just need to upgrade
to a newer version.
> 
> So no big deal conceptually, I fully admit, but doing this across eight servers is TEDIOUS.
 And more importantly, it's a ripe opportunity for introducing user error.  On three occasions
I have brought our production systems by stupid mistakes in server.xml or other config files,
or most recently, accidentally copying the wrong ROOT from a version 2 (05) box into the version
one boxes (01 and 03). I got things up and running fine with no serious consequences but this
being the third time, I thought "there has to be a better way" right after I talked myself
off the "you're a complete idiot" ledge.  
> 
> I'm starting to research Tomcat clustering but everything I see just talks about load
balancing and failover.  **What about ease of configuration??** I'd like to be able to set
up Tomcat <something> (clusters?) to help automate what I've described above to make
it less tedious and reduce the chances of making stupid mistakes when I'm on the 6th, 7th,
8th server.  I'm not sure if Tomcat clustering is what I need, or if I should look at something
else.
> 
> Can you nice folks help direct me to where I should look for starters?  Will Tomcat clustering
get me what I want?  or something else, like Zookeeper?

Tomcat clustering won't help.

A couple of things you might want to look at:

1. Use separate CATALINA_HOME / CATALINA_BASE. That reduces version
upgrades to:
- extract archive for new version
- stop instance
- edit startup script to point to new CATALINA_HOME
- start instance

2. Consider using ${your.property.name} style substitution in your xml
files. This lets you have a common configuration file that you can
simply copy across all your servers with server specific settings
defined as properties (that can be picked up from catalina.properties).
This allows 'global' changes to server.xml (or any other xml config
file) to be rolled out by copying the same file to all instances. You
should be able to use the same file in test and production, reducing the
chances of errors during changes.

HTH,

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message