Thank you Willy for your answer and the team for their work on Haproxy.
Sorry for my big mail, then I will be shorter in my further mail.
Thank you for you advise. it provides the good answer to my question.



Willy Tarreau a écrit :
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




Reply via email to