websocket - Bases web de equilibrio de carga

load-balancing server-push

Question

Tengo una pregunta sobre cómo cargar el equilibrio de los sockets web.

Tengo un servidor que admite sockets web. Los navegadores se conectan a mi sitio y cada uno abre un socket web a www.mydomain.com . De esta forma, mi aplicación de red social puede enviar mensajes a los clientes.

Tradicionalmente, usando solo solicitudes HTTP, ampliaba la escala agregando un segundo servidor y un equilibrador de carga en frente de los dos servidores web.

Con los sockets web, la conexión tiene que estar directamente con el servidor web, no con los balanceadores de carga, porque si una máquina tiene un límite físico de, digamos, 64k puertos abiertos, y los clientes se conectaban al balanceador de carga, entonces no podría más de 64k usuarios concurrentes.

Entonces, ¿cómo puedo ...

1. hacer que el cliente se conecte directamente al servidor web (en lugar del equilibrador de carga) cuando se carga la página? ¿Simplemente carga el JavaScript de un nodo y los equilibradores de carga (o lo que sea) modifican aleatoriamente la URL del script cada vez que se solicita inicialmente la página?

2. manejar un inicio de onda? El navegador notará que la conexión se cierra cuando el servidor web se apaga. Puedo escribir código JavaScript para intentar reabrir la conexión, pero el nodo desaparecerá por un tiempo. ¿Así que supongo que tendré que volver al equilibrador de carga para consultar la dirección del siguiente nodo a usar?

3. Me pregunté si los equilibradores de carga enviarían un redireccionamiento en la solicitud inicial, de modo que el navegador solicite inicialmente www.mydomain.com y sea redirigido a www34.mydomain.com . Eso funciona bastante bien, hasta que el nodo no funciona, y sitios como Facebook no hacen eso. ¿Cómo lo hicieron?

Answer 1

Coloque un equilibrador de carga L3 que distribuya los paquetes IP en función del hash de origen del puerto IP en su granja de servidores WebSocket. Dado que el equilibrador L3 no mantiene ningún estado (utilizando el puerto IP de origen hash), se escalará a velocidad de cable en hardware de gama baja (digamos 10 GbE). Dado que la distribución es determinista (utilizando el origen-IP-puerto hash), funcionará con TCP (y, por lo tanto, con WebSocket).

También tenga en cuenta que un límite estricto de 64k solo se aplica al TCP / IP saliente para una dirección IP dada (fuente). No se aplica a TCP / IP entrante. Hemos probado Autobahn (un servidor WebSocket de alto rendimiento) con 200k conexiones activas en una VM de 2 núcleos y 4 GB de RAM.

También tenga en cuenta que puede hacer un balanceo de carga L7 en la ruta HTTP anunciada durante el inicio de sesión inicial de WebSocket. En ese caso, el equilibrador de carga debe mantener el estado (qué par de puertos de IP de origen va a qué nodo de back-end). Sin embargo, probablemente se adaptará a millones de conexiones en una configuración decente.

Descargo de responsabilidad: soy autor original de Autobahn y trabajo para Tavendo.

Answer 2

También puede lograr el equilibrio de carga de la capa 7 con la inspección y la "funcionalidad de enrutamiento"

Consulte "Cómo inspeccionar y equilibrar la carga del tráfico de WebSockets con Stingray Traffic Manager, y cuando sea necesario, cómo administrar WebSockets y el tráfico HTTP que se recibe en la misma dirección IP y puerto". https://splash.riverbed.com/docs/DOC-1451

Answer 3

Tenga en cuenta que si su lógica de servidor websocket se ejecuta en nodejs con socket.io, puede indicarle a socket.io que use una clave / almacén de valores redis compartida para la sincronización. De esta forma, ni siquiera tiene que preocuparse por el equilibrador de carga, los eventos se propagarán entre las instancias del servidor.

var io = require(''socket.io'')(3000);
var redis = require(''socket.io-redis'');
io.adapter(redis({ host: ''localhost'', port: 6379 }));

Ver: http://socket.io/docs/using-multiple-nodes/

Pero en algún momento creo que Redis puede convertirse en el cuello de botella ...