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