Escale HAProxy para más de 64k websockets

8

Estamos tratando de diseñar una arquitectura que pueda manejar más de 64k websockets.

Primero probamos con Amazon ELB, pero su diseño no permite un pico inesperado de tráfico ni websocket. (El modo TCP agotó el tiempo de espera de los websockets inesperadamente)

Con HAProxy, esos límites no se aplican, pero estaremos limitados a ~ 64k websockets mantenidos entre HA y los servidores de fondo.

Múltiples soluciones que me vinieron a la mente:

  • Múltiples instancias HAProxy, equilibrio de carga con DNS (Route53 tiene una opción ponderada)
  • Dos instancias HAProxy con Keepalived, múltiples direcciones IP internas (no estoy seguro de si es factible)

Hay una mejor manera de hacer esto ?

domain-name-system load-balancing haproxy scalability websocket Bastien974
fuente
1
¿Por qué límite de 64k? ¿Es una cosa de puerto fuente? Si ese es el caso, simplemente puede agregar más 'servidores' al backend que están vinculados a diferentes puertos ...
Kyle Brandt
@ Bastien974, la forma más fácil, es usar IP de origen diferente para backends, para escalar a conexiones de 130K, utilicé dos ips y la opción sysctl
tw_reuse

Respuestas:

7

Si su límite de 64k se debe a puertos de origen, puede hacer algo como lo siguiente (un poco hacky, pero era lo que hacemos actualmente en SE para websockets (tenemos algo así como .5 millones concurrentes generalmente con 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

También se pueden hacer múltiples instancias con keepalived. Simplemente haga algo como DNS round robin sobre múltiples IP. Solo asegúrese de que las IP siempre sean recogidas por los equilibradores de carga activos ya que el DNS en sí mismo no le dará el equilibrio de carga (también hay más opciones aquí, esta es simplemente simple).

Kyle Brandt
fuente
1
Si lo entiendo correctamente, dado que srcIP define una conexión TCP: srcPORT / destIP: destPORT, si puedo escuchar en los servidores de back-end en múltiples puertos, eso significaría que entre HAProxy y los servidores de back-end podría tener conexión múltiple desde el mismo 127.0.0.1:12345 -> 10.0.0.1:8081, 127.0.0.1:12345 -> 10.0.0.1:8082, etc. ¿Esto realmente funciona?
Bastien974
@ Bastien974: Entiendes correctamente, funciona.
Kyle Brandt
@ Bastien974: Puede usar source 0.0.0.0 usesrc clientla configuración de back-end de haproxy para la transparencia de fuente de tproxy. De esta manera, srcIP: srcPORT serán los puertos / IP del cliente real (no las IP internas de la máquina haproxy), también es perfecto para el registro.
wqw
0

Puede configurar múltiples sistemas HAproxy que comparten las mismas IP utilizando Anycast y BGP o algún otro protocolo de enrutamiento de borde. De esta manera, todos los sistemas HAproxy están activos; si alguno de esos falla, deja de anunciar la ruta BGP en ese sistema y dejará de recibir tráfico en ~ 30 segundos; que se redistribuirá a otros sistemas disponibles que anuncian el mismo rango.

Por ejemplo, consulte esta url sobre cómo configurar dicho diseño

Hrvoje Špoljar
fuente
No estoy muy seguro de que esto funcione dentro de una infraestructura de AWS VPC, ya que necesito usar Elastic IP asociado a cada instancia. Su solución sería muy parecida a la de DNS, ya que Amazon Route53 ofrece la opción de agregar una comprobación de estado. Mi preocupación es que incluso con un TTL bajo, no podemos permitirnos esperar la propagación a otros países (tenemos clientes en todo el mundo) para dejar de enviar tráfico a una instancia de HA "muerta".
Bastien974