On 19.08.2009 15:12, Markus Pohle wrote:
Hi list members,
I am Markus Pohle, new subscriber to this list and long time user of
apache tomcat and tomcat connector (with apache httpd).
I do have a question according to mod_jk and jkstatus for which I did
not find any answer or solution, neither on internet/google nor the
mailing list and I hope, someone of you can help me.
Here is the scenario:
- two physical frontend servers, each with one apache httpd webserver
with mod_jk
- two physical middle tier servers, each with two apache tomcat servers
- the two frontend servers use linux-ha and heartbeat for failover
- mod_jk on the frontend servers are used to connect thru ajp13 to the
tomcat servers and do simple loadbalancing and failover (for the tomcats)
- the both frontend servers with apache httpd have same mod_jk
configuration (of course!)
now it comes...
during uptime changes are made to the mod_jk configuration thru the
jkstatus pages, like disabling or stopping one tomcat node. if that
happens, the actual jkstatus configuration does not match the static
mod_jk-conf-file configuration any more. if the first frontend server
(or the apache httpd server on it) crashes, linux-ha and heartbeat do a
takeover to the second frontend server and start apache httpd on the
server. during apache httpd startup it loads its mod_jk configuration,
but that one differs from the actual jkstatus configuration on the
crashed first frontend server!
My problem is, that I do not know how to replicate the actual jkstatus
config from the first frontend server to the second one so that i case
of takeover the modified configuration from with jkstatus is being kept.
Does anybody ever had the same problem? Is there a solution? Any help
would be realy appreciated!
I don't have a nice answer, but I would
- use a script for the common tasks, like changing the activation state
- use administrative discipline for the unspecific rest of changes
jkstatus uses only GET requests, and the URLs are easy to compose. So
you can have a script using e.g. curl as an http commandline client and
looping over the nodes of your farm to apply chnges for all nodes. The
script can be run on any node, that has web access to jkstatus of all
Apaches. curl also knows how to do basic auth.
I plan to add saving of config changes, but this will not obviously
solve the replication problem. The saved changes will be most likely in
the form of a change protocol which gets replayed (added to the
workers.properties) during startup. So in a distributed situation you
would still need to apply the changes to all nodes.
Farm management is currently not close (in time).
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
