Re: redispatch does not work when httpchk fails?

Hi,

On Thu, Jun 04, 2009 at 05:11:54PM +0200, Anders Nordby wrote:
> Hi,
>
> I have a layer 7 setup where I load balance different URLs to the same
> servers separately depending on the status of the application server.
>
> 1) I tried with cookie JSESSIONID prefix, as the application uses
> JSESSIONID already:
>
> defaults
> mode http
> retries 3
> option redispatch
> contimeout 5000
> clitimeout 50000
> srvtimeout 1500000
>
> listen lb.xx.no 0.0.0.0:80
> option httpclose
> mode http
>
> frontend www *.80
> acl prodacl hdr_dom(host) -i app.xx.no app-lb.xx.no
> use_backend prod if prodacl
>
> backend prod
> log global
> balance roundrobin
> cookie JSESSIONID prefix
> option persist
> server web2.xx.no web2.xx.no:80 check inter 2000 rise 2 fall 2
> server web3.xx.no web3.xx.no:80 check inter 2000 rise 2 fall 2
> option httpchk HEAD /app/version.txt HTTP/1.1\r\nHost:\
> app.xx.no
> option redispatch
> retries 3
>
> 2) I also tried with cookie insert:
>
> backend prod
> log global
> balance roundrobin
> cookie SERVERID insert
> option persist
> server web2.xx.no web2.xx.no:80 check inter 2000 rise 2 fall 2 cookie app2.xx.no
> server web3.xx.no web3.xx.no:80 check inter 2000 rise 2 fall 2 cookie app3.xx.no
> option httpchk HEAD /app/version.txt HTTP/1.1\r\nHost:\
> app.xx.no
> option redispatch
> retries 3
>
> My problem is:
>
> 1) If I use JSESSIONID prefix, requests are sent to the two backends
> every second time each, meaning the session cookie is not respected.
> Why? How can I make the requests balanced separately per session? I
> tried roundrobin and lastconn.

you have not set "option httpclose", so haproxy adds the prefix to the cookie in the first response, but when the server sends it again with the second response in the same session, haproxy does not touch it so it reaches the browser intact, without persistence information.

> 2) If I insert a SERVERID cookie instead, that works, but if the server
> the user was being sent to goes down, requests still go to the failing
> backend because Apache is still responding - even though the backend has
> failed according to the httpchk test. Redispatch does not consider
> whether the backend has failed its httpchk test, it only considers if it
> is responding on http? Seems a bug to me.

This is because of the "option persist" which explicitly states that even on a server failure, you want persistent sessions to remain on that server. You just have to remove this option.

Regards,
Willy Received on 2009/06/05 06:45