Forwarded to the list for posterity:
--- Begin Message ---
Hi Joe,
I'm pretty sure that if you are using LVS then you will have an iptables
redirect rule set up, that directs traffic back through the
loadbalancer, not directly back to the client - how can the client know
that the TCP session you are establishing from your server is related to
another IP address entirely?
Hope this helps point you in the right direction.
Chris
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.
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.
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.
Thanks again.
Joe
From: Willy Tarreau<[email protected]>
Date: Tue, 6 Apr 2010 07:10:04 +0200
To: Joseph Hardeman<[email protected]>
Cc:<[email protected]>
Subject: Re: Source IP instead of Haproxy server IP
On Tue, Apr 06, 2010 at 07:02:20AM +0200, Willy Tarreau wrote:
They are wanting their systems to send the data back to the visitor instead
of passing it back through haproxy.
Opps, sorry, I did not notice the end of the question. It is not
possible to send the data back to the client because it is not the
same TCP connection, so it's not a matter of using one address or
the other.
There is one connection from the client to haproxy and another one
from haproxy to the server. And even if you use the TPROXY feature,
the return traffic must still pass through haproxy.
This will be true for any layer7 load balancer BTW : the LB must
first accept the client's connection to find the contents, and by
doing so, it chooses TCP sequence numbers that will be different
from those that the final server will choose (and a lot of other
settings differ). So the server needs to pass through the LB for
the return traffic so that the LB can respond to the client with
its own settings.
If your customer is worried about the bandwidth, you should build
with LINUX_SPLICE and use a kernel>= 2.6.27.x which adds support
for TCP splicing. This is basically as fast as IP forwarding and
can even be faster on large objects. With this I reached 10 Gbps
in labs tests, but someone on the list has already reached 5 Gbps
of production traffic and is permanently above 3 Gbps.
So maybe this is what you're looking for. And yes, this is compatible
with LINUX_TPROXY, though the few iptables rules may noticeably
impact performance.
Regards,
Willy
--- End Message ---
