Hello, first, there are too many questions for a single mail, it's hard for list subscribers to find enough time to reply to everything, and it is likely that you'll only get partial responses.
On Fri, May 21, 2010 at 03:15:54PM +0200, eni-urgence wrote: > Hello all. > > I discover haproxy few weeks ago and I want to thanks willy for his > very good product. Thanks, but I'm not the only one :-) > I'm planing to integrate haproxy to our dmz. > I want to use haproxy for loadbalancing heavy secure php/ajax > applications with cookie persitence: a collaborate scheduler and a > image consult extranet. > > stunnel service will handle https connections and forward decrypted > requests to haproxy on port 88. Then haproxy will forward > connections to web server on port 10088, 100089 (and so...) on a mass > virtual host configuration of apache (see below). > In /var/www/vhost-SSL/ on web server, there is some symbolic links to > the php sources. Some domains are not linked to same path because > they don't provide the same application. So i don't want to have to > delete/rename the "running.ok" file on every path when I want to > shutdown the webserver. > I want to use the httpcheck on port 10081 and the file "running.ok" > . But I want a soft stop of service. I want haproxy to stop > forwarding new connection if he don't find the "running.ok" file but > continue to forward connection if cookie is initialised. so i will > configure a backup server with same cookies (like said in Haproxy > documentation). Now you can proceed more easily : use the "http-check disable-on-404" feature. It says that if the server responds 404 to a health check, then it just doesn't want any new user but those with cookies are still welcome. That's precisely what you're doing, and was designed exactly for this usage. > So now my questions : > - is it possible to check only the header like this /HEAD / > HTTP/1.0 /for backup server ? Yes and it's even recommended. Haproxy will only care about the HTTP status code, not the rest. So it's pointless to ask the server to emit the data. > - Like said in the article of willy > (http://1wt.eu/articles/2006_lb/),it is good to load balance the > encryption/decryption flow too. So a haproxy instance in tcp mode > (layer 4), seems to be a good solution. But our applications have to > know the client IP for security reasons. I read that a recompiled > kernel with tproxy support will forward connections keeping the real > client IP. Is that true ? Recent linux kernels (>= 2.6.28) integrate the patch. Maybe your distro was compiled with it enabled and you don't even need to recompile. However, you should be aware that you have to adjust the routing on your servers so that the response traffic passes through haproxy. You can also use LVS for the pure layer 4 LB, it has the advantage of supporting direct server return since it basically only changes the destination MAC address of the packets. > - I want to manage a multi site configuration keeping the > session persistence. How can I manage to do so? simply use a same cookie name with different values. Have all your haproxy instances know all the servers. If there are too many servers, then a different option is possible. Have the cookie name (or value) indicate what site handles the session, and have all haproxy instances know about each other and be able to forward traffic to each other. Example : frontend site1 bind :80 acl is_site1 hdr_sub(cookie) SERVERID=a acl is_site2 hdr_sub(cookie) SERVERID=b acl is_site3 hdr_sub(cookie) SERVERID=c use_backend site2 if is_site2 use_backend site3 if is_site3 default_backend local backend local # handles site1's traffic as well as non-site specific traffic # all cookies are prefixed with "a" cookie SERVERID server srv1 1.0.0.1:80 cookie a1 server srv2 1.0.0.1:80 cookie a2 server srv3 1.0.0.1:80 cookie a3 backend site2 # reroute traffic to site 2's load balancer server site2 2.2.2.2:80 backend site3 # reroute traffic to site 2's load balancer server site3 3.3.3.3:80 Hoping this helps, Willy
