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 >
