When using TCP load balancing with HAProxy, does all outbound traffic flow through the LB

haproxyload balancinglvs

I am setting up an app to be hosted using VMs(probably amazon, but that is not set in stone) which will require both HTTP load balancing and load balancing a large number(50k or so if possible) of persistant TCP connections. The amount of data is not all that high, but updates are frequent.

Right now I am evaluating load balancers and am a bit confused about the architecture of HAProxy. If I use HAProxy to balance the TCP connections, will all the resulting traffic have to flow through the load balancer? If so, would another solution(such as LVS or even nginx_tcp_proxy_module) be a better fit?

Best Answer

HAProxy (like many load balancers) generally maintain two conversations. The Proxy has a session (tcp in this case) with the client, and another session with the server. Therefore with proxies you end up seeing 2x the connections on the load balancer. Therefore all traffic flows through the load balancer.

When it comes to scaling across multiple load balancers I don't think you need to. But a practical and fairly easy way to do this is use something like keepalived with two floating IPs and round robin DNS between those two IPs. With keepalived, if one of the load balancers goes down the other would hold both IPs, so you get high availability this way. That being said, I think you will be fine with one active haproxy instance with your load.

HAProxy scales very well. An an example, the Stack Exchange network use web sockets which maintain open TCP connections. While I am posting this we have 143,000 established TCP sockets on a VMware virtual machine with no issues. The CPU usage on the VM is around 7%.

With this sort of setup with HAProxy make sure you set maxconn high enough. Here is some example HAProxy config to get you started:

frontend fe_websockets
        bind 123.123.123.123:80
        mode tcp
        log global
        option tcplog
        timeout client 3600s
        backlog 4096
        maxconn 50000
        default_backend be_nywebsockets

backend be_nywebsockets
        mode  tcp
        option log-health-checks
        option redispatch
        option tcplog
        balance roundrobin
        server web1 10.0.0.1:1234
        server web2 10.0.0.2:1234
        timeout connect 1s
        timeout queue 5s
        timeout server 3600s
Related Topic