davidcoles/vc5Un balanceador de carga de capa 4 escalable horizontalmente con retorno directo del servidor para Linux que utiliza XDP/eBPF
Este README se está actualizando actualmente para reflejar cambios recientes; es posible que alguna información no refleje el código base actual. Esta iteración del código aún no está lista para producción; use una versión v0.2 para entornos de producción.
Un balanceador de carga de capa 4 (L4LB) de Retorno Directo al Servidor (DSR) horizontalmente escalable para Linux que utiliza XDP/eBPF.
Si cree que esto puede ser útil o tiene alguna pregunta/sugerencia, no dude en contactarme en [email protected] o abrir un issue en GitHub.
¡Ahora compatible con IPv6 y distribución en capa 3 (también conocido como tunelización)! La biblioteca XVS se ha actualizado para incluir estas funciones, y también elimina la necesidad de ejecutar comprobaciones de salud desde un namespace de red, simplificando considerablemente el código. Esto eliminará el requisito de que todos los backends compartan una VLAN con el balanceador de carga.
Las restricciones del código actualmente significan que no se admite habilitar la tunelización
por servicio. Usar la opción -tunnel permite
habilitar globalmente la tunelización de capa 3 utilizando un solo esquema
(IP-in-IP, GRE, FOU o GUE). En el futuro, el código se actualizará
para permitir configurar la tunelización a nivel de servicio.
El balanceo de carga de capa 2 continuará siendo compatible; la razón principal para iniciar el proyecto fue la falta de soporte de capa 2 por parte del balanceador de carga Katran de Facebook.
Se incluye un archivo de configuración de ejemplo IPv6/L3; mejor documentación próximamente.
VC5 es un balanceador de carga de red diseñado para funcionar como reemplazo de
dispositivos de hardware heredados. Permite que los servicios con direcciones IP
virtuales (VIP) se distribuyan a conjuntos de servidores backend ("reales").
Los servidores reales pueden ejecutar los servicios ellos mismos o actuar como
proxies para otra capa de servidores (por ejemplo, HAProxy que actúa como
enrutador HTTP de capa 7/descarga SSL cuando se deben tomar decisiones a nivel
de aplicación). El único requisito es que las VIP deben configurarse en un
dispositivo loopback en cada servidor real, por ejemplo: ip addr add 192.168.101.1/32 dev lo
Los servicios y servidores reales se especifican en un archivo de configuración, junto con definiciones de comprobaciones de salud. Cuando los servidores backend pasan las comprobaciones y hay suficientes disponibles para proporcionar un servicio, las direcciones IP virtuales se anuncian a los enrutadores mediante BGP.
Ahora se admite la distribución de tráfico tanto en capa 2 como en capa 3. La distribución de capa 2 requiere que los servidores reales compartan una VLAN con el balanceador de carga; al recibir un paquete que debe distribuirse, el balanceador de carga actualiza las direcciones de hardware Ethernet en el paquete para usar la dirección MAC del servidor real como destino y su propia dirección MAC como origen, y reenvía el paquete a través de la interfaz adecuada, actualizando el ID de VLAN 802.1Q si los paquetes están etiquetados con VLAN.
La distribución de capa 3 requiere que los paquetes se encapsulen en un protocolo de tunelización dirigido a la IP del servidor real y se reenvíen a través de un enrutador (a menos que el servidor y el balanceador de carga compartan una VLAN). Si, al encapsularse, un paquete supera el tamaño máximo de transmisión de la red, se envía un mensaje ICMP al origen con consejo sobre la MTU adecuada a utilizar. Los servidores backend solo necesitan desencapsular paquetes; no se requiere tunelización bidireccional con balanceadores de carga.
Un servidor con una interfaz de red de 10 Gbit/s debería ser capaz de soportar un servicio HTTP con un ancho de banda de salida superior a 100 Gbit/s debido a la naturaleza asimétrica de la mayor parte del tráfico de Internet. Para servicios más pequeños, una máquina virtual modesta o dos probablemente manejarán un servicio que genere varios Gbit/s de tráfico de salida.
Si una instancia no es suficiente, se pueden agregar más servidores para escalar horizontalmente la capacidad (y proporcionar redundancia) utilizando la función ECMP de su enrutador. Se admite el enlace de interfaces 802.3ad y el trunking de VLAN 802.1Q (consulte el directorio examples/).
No se requieren módulos de kernel ni configuraciones complejas, aunque para un mejor rendimiento se recomienda un controlador de tarjeta de red con soporte de modo nativo XDP (por ejemplo: mlx4, mlx5, i40e, ixgbe, ixgbevf, nfp, bnxt, thunder, dpaa2, qede). Una lista completa está disponible en la página de soporte de controladores del Proyecto XDP.
Para mejores resultados, debe deshabilitar/desinstalar irqbalance.
Deberá seleccionar una IP principal para pasar al balanceador. Esta se utiliza para el ID del enrutador BGP.
Un ejemplo simple en un servidor con una única interfaz Ethernet sin etiquetar:
apt-get install git make libelf-dev golang-1.20 libyaml-perl libjson-perl ethtool (o el equivalente de su distribución)ln -s /usr/lib/go-1.20/bin/go /usr/local/bin/go (asegúrese de que el binario de Go esté en su PATH)git clone https://github.com/davidcoles/vc5.gitcd vc5/cmdcp config.sample.yaml config.yaml (edite config.yaml para que coincida con sus requisitos)make (descarga la biblioteca libbpf, compila el binario y el archivo de configuración JSON)./vc5 10.1.10.100 config.json eth0 (ajuste para usar la dirección IP de su servidor y la interfaz Ethernet)ip addr add 192.168.101.1/32 dev lo)