redispatch does not work when httpchk fails?

From: Anders Nordby <anders#fupp.net>
Date: Thu, 4 Jun 2009 17:11:54 +0200


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.
  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.

Regards,  

-- 
Anders.
Received on 2009/06/04 17:11

This archive was generated by hypermail 2.2.0 : 2009/06/04 17:15 CEST