What features of Haproxy do you plan to use in this scenario? Have you considered using Haproxy with Direct Server Return to work around the routing issue?
Have you considered using LVS? I believe LVS supports Source based hashing (http://www.linuxvirtualserver.org/docs/scheduling.html). If you do divide the backend servers into groups, you can distribute load between servers in a group evenly. Like you mentioned distribution of load between server groups can be uneven as it depends on DNS client. If you have multiple LVS directors/Haproxy servers (ie leaders) distributing load to the same group, I am not aware of any way of making sure that one leader knows of load distribution done by another leader. So, load can be potentially unevenly distributed across the backend servers. You can potentially use the patch mentioned at http://blog.loadbalancer.org/open-source-windows-service-for-reporting-server-load-back-to-haproxy-load-balancer-feedback-agent/ to dynamically manage weights. Regards, Vivek On Fri, Aug 16, 2013 at 3:47 PM, Meyers, Donovan <[email protected]> wrote: > Hello! > > I've been asked to architect software load balancing for a web farm to > support hundreds of thousands of concurrent connections. I planned to use > multiple haproxy instances and round-robin DNS to make it scalable (we've > done this before with success). We need to support SSL connections, but > terminated on the backend. Persistence is a bonus (to reduce SSL > negotiations) but not absolutely required, so I planned to use source IP > persistence and expect the hash to be consistent across > identically-configured instances. > > Now the customer has added the requirement that the requests look like they > came from the client — i.e. transparent proxying. > > So I need to set the default gateway of the backends to the haproxy > instance, or else I get asynchronous routing.But if I have multiple haproxy > instances, I can't route through just one; if the request came from a > different haproxy instance, I'll be async again. > > 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. > > I've asked if the customer can use the X-Forwarded-For header instead, but > I'm not expecting them to agree to that. This is a rebuild of an environment > that had its own Foundry ServerIron, so they've come to expect certain > features. > > I haven't had any luck searching the web for something like this. > > Am I correct about all this? > > Does anyone have a better idea? > > Thank you!!! > > Donovan
