On Wed, Apr 07, 2010 at 08:27:26AM -0400, Joseph Hardeman wrote:
> Willy,
>
> Thank you for the response, its interesting that I can't do this with
> haproxy, I was successful in doing this with LVS before.
This is because both work very differently :
- LVS does not inspect contents, it just forwards traffic to the server
- LVS is already in the middle of the IP stack in the kernel, where it's
possible to mangle anything.
> Web Visitor
> ^ |
> | |
> | V
> | Haproxy
> | /|\
> | / | \
> Cluster of servers
>
> I understand that haproxy is a layer 7 proxy and I am looking at using it as
> a transparent forwarding load balancer, at least for this step.
>
> Even with haproxy compiled with tproxy, you mentioned this wont work.
With tproxy you will be able to make haproxy connect to the servers from the
client's IP address. But this is just spoofing. That means that there is one
connection from the client to haproxy, another one from haproxy to the server
and the server believes it's the original client which is connecting to it
because it sees its IP as the source of the connection. Your servers will
still have to route the traffic back through haproxy in order for each
connection to work. Also, keep in mind that your kernel will have to be
patched to support doing this, and that the required iptables rules may reduce
the performance.
> I want to stay with haproxy, but I need to have haproxy at this first step
> pass the visitors' ip as the source to the next set of systems instead of
> changing it out for haproxy server IP address.
Quite honnestly, while I understand in which cases it can help (eg. when you
host servers for multiple customers), I don't think there is any long-term
benefit in doing this. It eases deployment but is more complicated to maintain
in the long term (patched kernel, routing issues, etc...). Having a web server
being aware to use standard methods to get the client's IP address is generally
preferred.
Regards,
Willy
