Hi Cyril,
On Sun, Jan 31, 2010 at 07:54:55PM +0100, Cyril Bonté wrote:
> Hi willy,
> this is a first attempt to add a maintenance mode on servers, using the stat
> socket (in admin level).
>
> It can be done with the following command :
> set maintenance <backend>/<server> on (or off to leave the maintenance mode).
>
> In this mode, no more checks will be performed on the server and it will be
> marked as a special DOWN state (MAINT).
OK. Is the server subject to the slowstart timer once it
leaves maintenance mode ?
> If some servers were tracking it, they'll go UP until the server leave the
> maintenance mode.
This is dangerous and often unwanted :
1) the main use of the tracking is to perform checks only once on a
server which appears in multiple backends. Now this means that we
can't do that anymore, otherwise when one is disabled, the other
ones remain UP though they are stopped too.
2) sometimes they will not be the same server, but tracking will be
there to ensure that service dependencies are properly handled.
Setting a tracking server UP while the tracked server is down
would also break that.
3) another advantage of tracked servers is that hashes are consistent
across all backends which track each others. People doing source
IP or URL hashing on anti-virus proxies will want the same requests
or users to always go to the same server. Thus it is important not
to make the hashes diverge that when tracking is set up.
For those reasons, I'd really want all tracking servers to be set down
if a tracked server is set down. For the same reason, we should refuse
to set a tracking server in maintenance mode from the interface and
instead report the identifier of the server it is tied to.
> The stats page and the CSV export also display this special state.
OK
> This can be used to disable the server in haproxy before doing some
> operations on this server itself. This is a good complement to the
> "http-check disable-on-404" keyword and works in TCP mode.
In fact at first I thought that you could achieve the same with the
"set weight" command, but then I remembered that "set weight" does
not prevent users with cookies to reach the disabled server. So yes,
both features are different.
> Tell me if it looks OK for you or if it needs some more work.
Well, please reconsider my comments above. I also believe that
using "on" to disable a server and "off" to enable it can be quite
confusing, especially for operations which finish very late at
night. I think that using just "disable <bk>/<srv>" or
"enable <bk>/<srv>" would be fine, I just wonder whether we'd not
regret later to have reserved those two common keywords for servers.
Or maybe use "enable server <bk>/<srv>" to leave room for extension ?
Concerning David's comments, I think that later we may evolve towards
a 4-phase down state :
UP -> weight decay -> weight 0 -> DOWN
I really don't see in which case the weight decay is *that* useful,
because the load already progressively decays when setting the weight
to zero, since only new users are balanced to other servers. The only
case it could help in my opinion would be for applications running
without cookies (caches ?). Anyway, if we find a valid reason to have
this phase, we should be able to set two timers, one for the decay
("stop" state) and one for the weight 0 stage (current "nolb" state).
We'd send commands looking like this :
disable server back/srv1 stop 1m nolb 5m
But let's do that later ;-)
Last point Cyril, at some places in your code below, your indentations
are made with 4 spaces instead of tabs. Would you mind fixing them in
your next versions please ?
Otherwise it looks fine.
Thanks!
Willy
