Ao usar o balanceamento de carga TCP com HAProxy, todo o tráfego de saída flui através do LB?

Estou configurando um aplicativo para ser hospedado usando VMs (provavelmente da Amazon, mas isso não está definido), o que exigirá o balanceamento de carga HTTP e o balanceamento de carga de um grande número (50k, se possível) de conexões TCP persistentes. A quantidade de dados não é tão alta, mas as atualizações são frequentes.

No momento, estou avaliando os balanceadores de carga e estou um pouco confuso sobre a arquitetura do HAProxy. Se eu usar o HAProxy para equilibrar as conexões TCP, todo o tráfego resultante precisará fluir através do balanceador de carga? Em caso afirmativo, outra solução (como LVS ou mesmo nginx_tcp_proxy_module) seria mais adequada?

O HAProxy (como muitos balanceadores de carga) geralmente mantém duas conversas. O Proxy possui uma sessão (tcp neste caso) com o cliente e outra sessão com o servidor. Portanto, com proxies, você acaba vendo duas vezes mais conexões no balanceador de carga. Portanto, todo o tráfego flui através do balanceador de carga.

Quando se trata de dimensionar vários balanceadores de carga, não acho que você precise. Mas uma maneira prática e bastante fácil de fazer isso é usar algo como keepalived com dois IPs flutuantes e DNS de rodízio entre esses dois IPs. Com keepalived, se um dos balanceadores de carga cair, o outro manteria os dois IPs, para que você obtenha alta disponibilidade dessa maneira. Dito isto, acho que você ficará bem com uma instância ativa de haproxy com sua carga.

O HAProxy escala muito bem. Por exemplo, a rede Stack Exchange usa soquetes da web que mantêm conexões TCP abertas. Enquanto estou postando isso, temos 143.000 soquetes TCP estabelecidos em uma máquina virtual VMware sem problemas. O uso da CPU na VM é de cerca de 7%.

Com esse tipo de configuração com o HAProxy, certifique-se de definir maxconnalto o suficiente. Aqui está um exemplo de configuração do HAProxy para você começar:

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

Sim, todo o tráfego normalmente deve passar pelo balanceador de carga. As solicitações são recebidas pelo balanceador de carga e as respostas são enviadas de volta ao balanceador de carga que as envia de volta aos clientes.

Para escolher a ferramenta certa, não tenho muita experiência com as outras opções. Estou usando haproxy e é realmente bom e estável e pode lidar com uma grande quantidade de tráfego. Além disso, seus recursos de ACLs são excelentes.

Existe a possibilidade de usar e configurar o DSR (retorno direto do servidor), mas isso não tem nada a ver com o Loadbalancer, mas está configurado na pilha tcp (tabelas de roteamento). Usamos isso para um grande portal de transmissão de vídeo. Embora funcione, ele fornecerá uma quantidade significativa de dor de cabeça em relação à complexidade do roteamento necessário.

Portanto, eu não recomendaria usar essa técnica sem considerar minuciosamente o uso e as desvantagens.

Talvez haja algumas dicas para começar lá:

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

Diverta-se!