Ao usar o balanceamento de carga TCP com HAProxy, todo o fluxo de tráfego de saída passa pelo LB?

Question

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

Agora estou avaliando 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 terá que fluir através do balanceador de carga? Em caso afirmativo, outra solução (como LVS ou mesmo nginx_tcp_proxy_module) seria mais adequada?

    

Answer 1

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

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

HAProxy escala muito bem. Um exemplo, a rede do Stack Exchange usa soquetes da Web que mantêm conexões TCP abertas. Enquanto eu 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 maxconn alto 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

    

Answer 2

Sim, todo o tráfego deve passar normalmente 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 sobre as outras opções. Eu estou usando haproxy e é muito bom e estável e pode lidar com uma grande quantidade de tráfego. Além disso, seus recursos de ACLs são ótimos.

    

Answer 3

Existe a possibilidade de usar e configurar o DSR (Direct Server Return), mas isso não tem nada a ver com o Loadbalancer, mas é configurado na tcp-stack (tabelas de roteamento). Estamos usando isso para um grande portal de streaming de vídeo. Embora funcione, isso lhe dará uma quantidade significativa de dor de cabeça com relação à complexidade do roteamento necessário.

Assim, eu não recomendaria usar essa técnica sem considerar o uso e as desvantagens muito detalhadamente.

Talvez haja algumas dicas para começar:

• link
• link

Divirta-se!