Dimensione o HAProxy para mais de 64k websockets

8

Estamos tentando projetar uma arquitetura capaz de lidar com mais de 64k websockets.

Primeiro tentamos com o Amazon ELB, mas seu design não permite pico inesperado de tráfego nem soquete da web. (O modo TCP atinge o tempo limite dos webs inesperadamente)

Com o HAProxy, esses limites não se aplicam, mas estaremos limitados a ~ 64k websockets mantidos entre a HA e os servidores de back-end.

Várias soluções que vieram à mente:

Várias instâncias HAProxy, equilíbrio de carga com DNS (Route53 tem uma opção ponderada)
Duas instâncias HAProxy com Keepalived, vários endereços IP internos (não tenho certeza se é possível)

Existe uma maneira melhor de fazer isso ?

— Bastien974
fonte

1

Por que limite de 64k? É uma coisa de porta de origem? Se for esse o caso, você pode simplesmente adicionar mais 'servidores' para o servidor que são obrigados a portas diferentes ...

— Kyle Brandt

@ Bastien974, a maneira mais fácil, é ip fonte uso differents para backends, a escala para 130K conexões, eu usei dois ips e tw_reuse opção sysctl

— c4f4t0r

7

Se o seu limite de 64k é devido a portas de origem, você pode fazer algo como o seguinte (um pouco hacky, mas atualmente fazemos no SE para websockets (temos algo como 0,5 milhão simultâneo geralmente com HAProxy):

server ny-web01-1 10.0.0.1:8081 check
server ny-web01-2 10.0.0.1:8082 check
server ny-web01-3 10.0.0.1:8083 check

Também várias instâncias são possíveis com keepalived. Basta fazer algo como DNS de rodízio em vários IPs. Apenas garanta que os IPs sempre sejam capturados pelos balanceadores de carga ativos, pois o próprio DNS não fornecerá o balanceamento de carga (há mais opções aqui também, essa é apenas uma simples).

— Kyle Brandt
fonte

1

Se eu entendi corretamente, como uma conexão TCP é definida por srcIP: srcPORT / destIP: destPORT, se eu conseguir escutar nos servidores back-end em várias portas, isso significaria que entre os servidores HAProxy e back-end seria possível ter várias conexões do mesmo 127.0.0.1:12345 -> 10.0.0.1:8081, 127.0.0.1:12345 -> 10.0.0.1:8082, etc? Isso realmente funciona?

— precisa saber é o seguinte

@ Bastien974: Você entende corretamente - funciona.

— Kyle Brandt

@ Bastien974: Você pode usar source 0.0.0.0 usesrc clientna configuração de back-end do haproxy para obter a transparência do código-fonte do tproxy. Dessa forma, srcIP: srcPORT será o IP / portas do cliente real (e não os IPs internos da máquina), ideal para o log também.

— Wqw

0

Você pode configurar vários sistemas HAproxy que compartilham os mesmos IPs usando Anycast e BGP ou algum outro protocolo de roteamento de borda. Dessa forma, todos os sistemas HAproxy estão ativos; se alguma dessas falhas for interrompida, você para de anunciar a rota BGP nesse sistema e, em ~ 30 segundos, deixa de receber tráfego; que será redistribuído para outros sistemas disponíveis que anunciam o mesmo intervalo.

Por exemplo, verifique este URL sobre como configurar esse layout

— Hrvoje Špoljar
fonte

Não tenho certeza se isso funcionaria dentro de uma infraestrutura da AWS VPC, pois preciso usar o Elastic IP associado a cada instância. Sua solução seria muito próxima da DNS, pois o Amazon Route53 oferece a opção de adicionar uma verificação de integridade. Minha preocupação é que, mesmo com um TTL baixo, não podemos esperar a propagação para outros países (temos clientes em todo o mundo) para parar de enviar tráfego para uma instância de HA "morta".

— precisa saber é o seguinte