Hi All, Well, you can also use a couple of LVS clusters in DSR mode: between clients and HAProxy, DSR mode, source hash load-balancing. Between HAProxy and servers, DSR mode, destination hash load-balancing. and you're done :)
Your architecture becomes scallable and you avoid this dirty RRDNS trick! That said, I agree with Lukas, maybe a single server is enough for your needs :) keep in mind the KISS method. Baptiste On Sun, Aug 18, 2013 at 5:52 PM, Lukas Tribus <luky...@hotmail.com> wrote: > Hi Donovan, > > >> Have you considered using Haproxy with Direct Server Return to work >> around the routing issue? > > You cannot use HAProxy with "Direct Server Return", because HAProxy > terminates the TCP connection on both sides. > > > >> Now the customer has added the requirement that the requests look like >> they came from the client — i.e. transparent proxying. > > If you have all those requirements, you need "Direct Server Return", as > Vivek mentioned. This is probably how the Foundry solution works. > > I suspect you can do this (Direct Return) only with LVS. Anyway, I wouldn't > recommend such a solution. Things like SYN floods will directly hit your > backends. > > > >> I've asked if the customer can use the X-Forwarded-For header instead, but >> I'm not expecting them to agree to that. > > Keep in mind that you cannot insert any HTTP headers on the proxy when the > traffic is passing SSL/TLS encrypted. You would have to offload SSL on the > load balancer to be able to insert the IP in the header. > > > >> The best option I can come up with is to break the backends into groups and >> assign each group to an haproxy, which would then be the backends' default >> gateway. But then my backends are silo'd and I'm really relying on >> round-robin DNS to keep things even, which I don't consider reliable. > > Thats correct. > > Consider that reverse proxying in TCP mode is extremely cheap in terms of > CPU and memory. With decent hardware (10G NIC, lots of RAM and a beefy CPU) > you will be able to forward 20Gbps on a single box. > > Depending on your load you may be able to do everything with a single > active/standby proxy "group". > > If thats not enough, and you need even more performance (or you need to be > able to scale horizontally), an alternative to RRDNS would be some geo-based > load balancing (via DNS for example). > > Then you can deploy proxies and backends more closer to the client and > lower the load on a single proxies, thus eliminating the need for backend > "groups". > > > >> Persistence is a bonus (to reduce SSL negotiations) but not absolutely >> required > > You probably want to make this a hard requirement, as those SSL negotiations > will have a huge performance impact. > > > > Regards, > > Lukas
