On Fri, Jun 12, 2009 at 09:28:23PM +0200, benoit wrote:
> Michal Krajcirovic a écrit :
> >hello,
> >I need to do on one server balancer, which will operate as follows:
> >one of its IP will come all the requests, and he is sent to one 
> >server. in the event of failure, it will send one to the other.
> >
> >I need but to date correspond to those sites (eg large avi) netekly 
> >through the server with haproxy, but directly to the user.
> >
> >Can you do this?
> >
> >thanks
> Well, honestly i'm not sure of what you are trying to accomplish.
> 
> There is what i understood from your message:
> 
>    You want to setup some basic load-balancing in front of at least two 
> (web?) servers.
>    For some reason you doesn't want large static data to come back thru 
> the haproxy server.
> 
> This assymetric data path isn't supported by haproxy: you need a way to 
> translate back the backend
> IP adress to the frontend (public) IP so that your packets are correctly 
> interpreted by the web browser
> (or any application having initiated the data transfert).

You're right Benoit, but in fact it's not just a matter of translating
IP addresses, as this is the easy part. This principle is often called
DSR (direct server return). The real problem comes from the rest : ports,
sequence numbers, options, window... Since you have two distinct TCP
sessions, there is no magic solution to make one accept packets from
the other one.

> While F5's 
> BigIP devices does have a way to do
> this, it ain't very clean (quite the opposite in fact).

DSR can only be done on layer 3/4 LB, not on layer 7 because you have
a proxy in between. It can be clean. In fact I even find it cleaner
than destination NAT which is often the alternative. A lot of equipment
support this. Under Linux, it's supported by IPVS, in direct routing
mode.

> One simple solution with haproxy could be to have two domains, one will 
> use the haproxy ip adresse
> to provide failover, while the other will access directly to the 
> backends for static datas (using DNS RR
> for simple load sharing for example):
> 
>       www.domain.com   => 1.1.1.1   => haproxy box => 1.1.1.2 backend1
>                                                    => 1.1.1.3 backend2
>                                                    => 1.1.1.4 backend3
>                                                     ....
>       static.domain.com => 1.1.1.2 backend1
>                                   => 1.1.1.3 backend2

Yes indeed. For more robustness, you could set up VRRP addresses for
all those backends so that all the addresses announced in DNS are
always available. A better solution consists in setting up IPVS on
the LB and doing DSR to the backend servers.

But quite honnestly, Michal, how much traffic are you going to forward ?
Some people on this list are pushing nearly 5 Gbps of real production
traffic through their haproxies, so I would say that there are little
reasons nowadays to scratch your head with DSR. The only real valid
reason would be when you intend to process very large numbers of
concurrent sessions, but most sites don't need more than a few
tens of thousands of concurrent sessions, which can be easily achieved
with a reasonable amount of RAM.

A good rule of thumb with DSR is that it is interesting to use it
if your traffic is going to be very asymmetric, and far above the
capacity of your load-balancer's cumulated links. Today, a
dual-gigabit server costs less than $1000. So at less than 2 Gbps,
it's generally not interesting to play with DSR.

Regards,
Willy


Reply via email to