Re: Avoid 503 during failover to backup?

From: Krzysztof Oledzki <ole#ans.pl>
Date: Tue, 2 Dec 2008 20:12:35 +0100 (CET)

On Tue, 2 Dec 2008, Jim Jones wrote:

> Hello Willy and list,

Hello,

> We're running haproxy with (roughly) the following config:
>
> listen foo 0.0.0.0:8080
> balance leastconn
> cookie C insert indirect nocache
> option persist
> option redispatch
> option allbackups
> option httpchk HEAD /test HTTP/1.0
> fullconn 200
> server www1 192.168.0.1 weight 1 minconn 3 maxconn 100 cookie A check inter 5000
>  server www2 192.168.0.2 weight 1 minconn 3 maxconn 100 cookie B check inter 5000
>  server www3 192.168.0.3 weight 1 minconn 3 maxconn 100 cookie C check inter 5000
> server bu1 192.168.0.10 weight 1 minconn 3 maxconn 100 check inter 20000 backup
> 
> When we shut down all www servers (www1-www3) haproxy will shortly after
> route requests to the backup server - just as intended.
>
> Our problem is that *during* the failover some requests will get a 503
> response from haproxy: "No server available to serve your request".

This is simply because haproxy needs some time to detect and mark all the active servers (www1-www3) down and to activate the backup one (bu1).

> More precisely: When we shut down all www servers and then make a
> request before the 5 second timeout has elapsed this request will
> receive the 503 response.

It should take even longer (fall*inter = 3*5s=15s). However, you may use "fastinter 1000" to make it much shorter.

> Is there a way to avoid this gap and make the failover
> completely transparent?

Currently backup servers are only activated if there are no other active servers, moreover redispatcher (option redispatch) does not redispatch to an inactive backup server. I have a patch that mitigates this behavior but as it was a quick&dirty solution I have never intended to make public, but now I think I'll get on this, clean it and post it here. ;)

Best regards,

                                 Krzysztof Olędzki Received on 2008/12/02 20:12

This archive was generated by hypermail 2.2.0 : 2008/12/02 20:15 CET