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 :
> 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
Received on 2010/04/07 15:15
This archive was generated by hypermail 2.2.0 : 2010/04/07 15:30 CEST