Nikola Milutinovic wrote:
Hi all.
This is just a question out of curiousity. Is there a balancer
solution that can allow for controlled migration/upgrade of nodes?
To explain, suppose you have Apache/mod_jk and you have N Tomcats in
balance over that setup, same web application on all of them. Now,
suppose you would like to upgrade the application without disrupting
the service. Suppose you have fixed a bug.
It would be nice if one of the nodes in "cluster" could be brought
out of the cluster, but gracefully. By "gracefully" I refer to
stopping new requests to the node and letting existing requests
"drain out". When all requests are over, it can be brought down and
upgraded. Then it would obviously need to be brought back in. Let us
suppose that the new web application is not in "semantical
inbalanace" with the old nodes.
Of course, this brings into question what is "draining out existing
requests"? Does that mean open HTTP sessions or just rrunning
requests. I suppose, in case of session, we could turn to sticky
sessions, right?
So, what are your thoughts on the subject? Ever seen something like
that in the wild? Or at least in the lab? A balancer that can be
reconfigured (almost) online and one that allows for requests to the
node being evicted to finish, first.
Nix.
If you want to drain sessions, you can do that with mod_jk by simply
setting load balancer members to state "disabled". It will still send
requests with routing suffix attached to their session id to the sticky
node, but will not send new sessions to the "disabled" node. It's not
perfect in case your users have bookmarked requests with URL encoded
sessions but it works well enough very often. How long it takes to drain
depends of course a lot on the average session duration.
In this scenario cluster could be simply farm, without session replication.
If you only want to drain requests, you can do that by setting a load
balancer member to "stopped". This will immediately stopping forwarding
any new requests. In this case you want to add session replication (or
use stateless webapps).
Both actions are possible via the status worker GUI. What's missing is
making the change persistent from the GUI. If you change a workers state
only via the GUI and restart Apache, the change will be overwritten by
the configuration on disk. So in order to make those changes persist
over the next httpd restart, you'll also need to enter it into the
config file. Chaning the status in mod_jk does not need you to restart
(even gracefully) Apache though. The change applied via the status GUI
will immediately become active for all Apache children.
And yes, session draining is used in real life environments.
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
