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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
