La semana pasada, los desarrolladores de GitHub
subieron el código fuente de su equilibrador de carga: GLB Director. El equipo trabajó en este proyecto durante varios años.
Lo que es notable es su decisión, cómo está organizado y quién más transfirió los sistemas de equilibrio de carga a código abierto, contamos más.
/ Flickr / theilr / cc¿Por qué GitHub posee su propio balanceador?
GitHub utiliza
una infraestructura de nube
desnuda para aumentar la productividad. En este caso, el software funciona sin niveles adicionales de virtualización en el metal desnudo.
Anteriormente, la compañía usaba
haproxy con una configuración de hardware especial para proporcionar equilibrio de carga, lo que proporcionaba tolerancia a fallas para conexiones Ethernet de 10 gigabits. Sin embargo, este enfoque no escalaba bien (escala vertical implícita), y GitHub decidió escribir su propio equilibrador de carga, que aún podría funcionar en hardware de bajo costo.
¿Qué puede y cómo funciona GLB Director?
El equilibrador GitHub garantiza conexiones TCP ininterrumpidas, gestiona la carga de servicios individuales, es resistente a los ataques DDoS y puede escalar horizontalmente. Está "
encarcelado " para trabajar en centros de datos, donde una gran cantidad de servidores anuncian una sola dirección IP a través de
BGP , y los enrutadores utilizan la estrategia
ECMP .
El equilibrio de carga
se realiza en los niveles L4 y L7. A diferencia de soluciones como
LVS , GLB Director no dirige todos los paquetes a un nodo director para redistribuirlos entre otros nodos. En su lugar,
utiliza una variación de hash de encuentro (
HRW ) para crear una tabla estática para seleccionar un par de servidores proxy (primario y secundario) para cada conexión entrante. Si uno de ellos falla, el paquete se envía al segundo. El sistema recuerda esta elección, y no es necesario realizarlo para cada paquete.
El "estado" de los servidores es monitoreado por la solución glb-healthcheck, que cambia los sistemas primarios y secundarios en caso de problemas. glb-healthcheck
supervisa el funcionamiento correcto de cada túnel
GUE (encapsulación UDP genérica) y un puerto HTTP arbitrario de servidores de fondo.
GLB también usa el sistema
Netfilter y la utilidad
iptables . Netfilter resuelve una tarea simple: determina si el paquete TCP / IP interno en cada paquete GUE cumple con la pila TCP del kernel de Linux. Si no, redirige el paquete al servidor proxy secundario, en lugar de decapsularlo localmente.
El diagrama de interacción de los componentes se ve así:
GitHub
espera que su equilibrador sea útil para todas las empresas que tienen sus propios centros de datos.
Puede encontrar cómo instalar GLB y comenzar a trabajar con él en la
guía de inicio rápido preparada por los desarrolladores .
Desarrollos similares
En mayo, Facebook también
compartió el código fuente de su biblioteca de equilibrador de carga Katran. El gigante de TI lo
utiliza para distribuir eficientemente la carga entre los servidores de fondo.
El equilibrador anterior de la compañía, L4LB, no podía hacer frente a la tarea, ya que requería servidores dedicados para el trabajo, lo que aumentaba la carga en la red. Para resolver este problema, la compañía desarrolló Katran. Se inicia utilizando el marco de ruta de datos eXpress y la máquina virtual eBPF. La VM amplía la funcionalidad general al ejecutar programas en puntos individuales en el kernel de Linux.
/ Flickr / da sal / ccEl equilibrador actualizado
distribuye más eficientemente
la carga en la infraestructura y aumenta la velocidad del procesamiento de paquetes. Desarrolladores de código fuente
"subidos" en GitHub.
El sistema Katran
tiene varias diferencias con la solución propuesta en GitHub. Por ejemplo, Facebook usa túneles XDP e IPIP que funcionan con el kernel de Linux. GLB, por el contrario, ha recurrido a la ayuda de DPDK para procesar paquetes desde el espacio del usuario.
Theo Julienne, el desarrollador de GitHub,
agregó que
DPDK le permite manejar grandes volúmenes de tráfico entrante. Esto garantiza un alto rendimiento (conexión de 10 gigabits) incluso en entornos de trabajo complejos y proporciona cierta protección contra ataques DDoS.
La transferencia de herramientas poderosas como GLB y Katran a código abierto abrirá nuevas oportunidades para otras compañías de TI y contribuirá al desarrollo más rápido del ecosistema de TI en el mundo.
PD: un par de artículos adicionales del primer blog corporativo de IaaS: