Re: Maintenance mode

Dear Alexander,

On Mit 10.09.2008 23:03, Alexander Staubo wrote:
>
>Guys, I would like to bring this subject up again. I have not been able
>to work out a satisfactory solution to the problem.
>
>In a nutshell, when we -- my company -- perform a site update, we want
>to display a static web page showing the current maintenance state. A
>site update usually involves taking down all Rails processes, checking
>out new code, and bringing Rails up again. So while this is going on,
>HAProxy will attempt, and fail, to connect to its backend servers.

how about

http://haproxy.1wt.eu/download/1.3/doc/configuration.txt

nbsrv

###
frontend www

         mode http
         acl site_dead nbsrv(dynamic) lt 1
         acl site_dead nbsrv(static)  lt 1
         monitor-uri   /site_alive
         monitor fail  if site_dead

As the thread start with the nginx example, please can you tell us, only if you can / want, how your setup looks like?

e.g.: ? -> haproxy -> mongrel -> rails

on the same server?

What are the steps @site update?

Maybe it is possible to send a http errorcode other then 503 e.g. 506 to haproxy and you can catch it with

acl maintenance_mode status 506

http://haproxy.1wt.eu/download/1.3/doc/haproxy-en.txt acl status_error status 400:599

Yust some ideas.

but yes this is not a easy task, with the lower excludes.

>There are a few possible solutions, all of them unsatisfactory:

[snipp the not working ways]

>Now, I have a suggestion for a proper solution, and if Willy likes it I
>will try my hand at coughing up a patch. The idea is to support
>user-defined variables that are settable at runtime. In the
>configuration, these variables would be usable as ACLs:
>
> frontend http
> ...
> acl variable maintenance_mode true
> use_backend maintenance if maintenance_mode
>
>To control a variable you would invoke the haproxy binary:
>
> $ haproxy -S maintenance_mode=true
>
>or
>
> $ haproxy -S maintenance_mode=false
>
>Using shared memory for these variables is probably the easiest,
>fastest and secure. It would be mapped into HAProxy's local address
>space, so a lookup is essentially just a local memory read, cheap
>enough to check on every request. Similarly, read and write access to
>the variables could then be limited to the HAProxy user, if I remember
>my POSIX shared memory semantics correctly.
>
>Having such variables at hand would also let you do other tricks not
>specifically related to maintenance. For example, you can have
>external monitoring scripts that modify the behaviour of HAProxy based
>on some sort of load parameter.
>
>Thoughts?

Sounds nice, but very deep intervention into haproxy.

If you have the time and leisure, yes a fast and small shared memory implementaion would be a nice benefit for haproxy, from my point of view ;-)

Aleks Received on 2008/09/10 23:47