I didn't see my original post(s) come back from haproxy@ mail-list, so I'm trying again, hopefully consolidated a bit smaller :)
I have the configuration lines:
option httpchk balance roundrobin timeout connect 5s timeout client 5s timeout server 5s server LDAP1 220.127.116.11:389 check addr localhost port 9101 inter 5s downinter 120s fall 3 server LDAP2 18.104.22.168:389 check addr localhost port 9102 inter 5s downinter 120s fall 3
So haproxy checks every 5 seconds. Say LDAP1 is down, and after 3 failure responses, that realserver service is marked unavailable. What happens to incoming connections during that 15s? Half go to LDAP2 (since it's round-robin) and get answered ok. The other go to LDAP1 and stall? The early ones, I guess, will timeout because of the 5s timeout limit and then just get rejected or whatever and the client can try again (and hopefully get LDAP2?) What about ones near the end of that 15s time? If a connection is still in its 5s timeout server timeframe, and the server is marked as unavailable, will that connection be rerouted to the other server(s) in the pool?
Second, is there a way to get customized health check scripts launched by haproxy itself? I realize you might not want haproxy to be held hostage by poorly written user scripts. Perhaps a forked child process or something? Right now, I use xinetd and launch a script whenever haproxy connects to port 9101 or 9102, and the script does an actual LDAP query and prints out HTTP200 if the query returs a known good value, or HTTP500 for any other result. I find myself now having to do many more such localhost xinetd type expansion, one for every server
Finally, I'm using the VRRP part of keepalived to handle failover of the actual load-balancer that runs haproxy. If anyone has any tips/hints on better intergating haproxy and keepalived, I'd greatly appreciate it. It's working for me right now, and I can unplug the network cable and it fails over to the other load-balancer (which also has haproxy running) and my clients go merrily on their way. But anything to smooth that out, or any gotchas I should watch out for.
-- Paul Hirose : pthirose#ucdavis.edu : Sysadm Motto: rm -fr /MyLifeReceived on 2009/12/23 20:31
This archive was generated by hypermail 2.2.0 : 2009/12/23 20:45 CET