Re: option redir and latest snapshot

From: florian iragne <florian.iragne#viewsurf.com>
Date: Fri, 15 Feb 2008 10:01:47 +0100

Willy Tarreau a écrit :
>> no, less than 10s. e.g., check inter 10000 fall 4 rise 1 works >> while check inter 20000 fall 4 rise 1 gives the strange behaviour i mention. Well, i've made a test, and now, it's really weird!

here is the config of my backends (i've changed the real addresses):

backend app_0

         stats enable
         stats auth toto:toto
         balance
         option httpclose
         option forceclose
         option forwardfor
         option httpchk HEAD /alive HTTP/1.1\r\nHost: www
         server app0_0 192.168.2.2:80 maxconn 2000 check inter 10000 

fall 4 rise 1

backend app_1

         stats enable
         stats auth toto
         balance
         option httpclose
         option forceclose
         option forwardfor
         option httpchk HEAD /alive HTTP/1.1\r\nHost: www
         server app1_0 IP1:80 redir http://domain.tld maxconn 2000 check 
inter 10000 fall 4 rise 1
         #server app1_1 IP2:80 redir http://domain2.tld maxconn 2000 

check inter 10000 fall 4 rise 1

backend app_2

         stats enable
         stats auth toto:toto
         balance
         option httpclose
         option forwardfor
         option httpchk
         server app2_0 192.168.2.3:80 check inter 20000 fall 4 rise 1

If i use an interval of 20000 for backend app_0, then backend app_1 is marked as down after few seconds, and never comes back.

If i use an interval of 20000 for backend app_1, then it's the app_2 backend that comes down and never comes back.

The last, but not the least : using an interval of 20000 for app_2, i can see that app_0 and app_1 works perfectly well, are continuously marked up, but app_2 is alternatively marked as up or up going down, and is never marked down.

Really weird isn't it?

>>> I have never seen such a strange behaviour! The checks are so simple, I
>>> would not even imagine what could cause this! Would you happen to have
>>> ip_conntrack loaded on the machine hosting haproxy ?
>> ip_conntrack is enabled (it must be since i use openvz virtualization).

>
> OK. Keep in mind that it often shows a huge performance hit if you have
> many hits/s (count about 50% performance impact).
I know, but we currently need this solution.

> If you can send me a trace of this when there are problems, that would
> be great.

I'm compiling traces using tcpdump -vv (with proper grep). Do you need other options for tcpdump or another trace using another soft?

cheers,

Florian Received on 2008/02/15 10:01