Cuando se usa el equilibrio de carga TCP con HAProxy, ¿fluye todo el tráfico saliente a través del LB?

Estoy configurando una aplicación para que esté alojada usando máquinas virtuales (probablemente Amazon, pero eso no está establecido en piedra) que requerirá tanto el equilibrio de carga HTTP como el equilibrio de carga un gran número (50k más o menos, si es posible) de conexiones TCP persistentes. La cantidad de datos no es tan alta, pero las actualizaciones son frecuentes.

En este momento estoy evaluando equilibradores de carga y estoy un poco confundido acerca de la arquitectura de HAProxy. Si uso HAProxy para equilibrar las conexiones TCP, ¿tendrá que fluir todo el tráfico resultante a través del equilibrador de carga? Si es así, ¿sería mejor otra solución (como LVS o incluso nginx_tcp_proxy_module)?

HAProxy (como muchos equilibradores de carga) generalmente mantienen dos conversaciones. El Proxy tiene una sesión (tcp en este caso) con el cliente y otra sesión con el servidor. Por lo tanto, con los proxies terminas viendo 2 veces las conexiones en el equilibrador de carga. Por lo tanto, todo el tráfico fluye a través del equilibrador de carga.

Cuando se trata de escalar en varios equilibradores de carga, no creo que sea necesario. Pero una forma práctica y bastante fácil de hacer esto es usar algo como keepalived con dos IP flotantes y DNS round robin entre esas dos IP. Con keepalived, si uno de los equilibradores de carga cae, el otro mantendría ambas IP, por lo que obtendrá una alta disponibilidad de esta manera. Dicho esto, creo que estará bien con una instancia de haproxy activa con su carga.

HAProxy escala muy bien. Un ejemplo, la red de Stack Exchange usa sockets web que mantienen conexiones TCP abiertas. Mientras publico esto, tenemos 143,000 sockets TCP establecidos en una máquina virtual VMware sin problemas. El uso de CPU en la VM es de alrededor del 7%.

Con este tipo de configuración con HAProxy, asegúrese de configurar maxconnlo suficientemente alto. Aquí hay algunos ejemplos de configuración de HAProxy para comenzar:

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

Sí, todo el tráfico debería pasar normalmente por el equilibrador de carga. El equilibrador de carga recibe las solicitudes y las respuestas se envían de vuelta al equilibrador de carga que las envía de vuelta a los clientes.

Para elegir la herramienta adecuada, no tengo mucha experiencia sobre las otras opciones. Estoy usando haproxy y es realmente bueno y estable y puede manejar una gran cantidad de tráfico. Además, sus capacidades de ACL son excelentes.

Existe la posibilidad de usar y configurar DSR (Direct Server Return), pero esto no tiene nada que ver con Loadbalancer, pero está configurado en la pila tcp (tablas de enrutamiento). Hemos estado usando esto para un gran portal de transmisión de video. Aunque funciona, le dará grandes cantidades de dolor de cabeza con respecto a la complejidad del enrutamiento necesario.

Por lo tanto, no recomendaría usar esta técnica sin considerar el uso y los inconvenientes a fondo.

Tal vez hay algunos consejos para comenzar allí:

• http://www.remsys.com/blog/configuring-dsr-on-the-alteon-load-balancers
• http://community.brocade.com/docs/DOC-1650

¡Que te diviertas!