VC5

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.

Acerca de

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.

Objetivos/estado

• ✅ Implementación simple con un solo binario
• ✅ Selección de backend estable con el algoritmo de hash Maglev
• ✅ Inyección de salud de ruta manejada automáticamente; no es necesario ejecutar otro software como ExaBGP
• ✅ Mínimamente invasivo; no requiere ninguna modificación de las reglas de iptables en el balanceador
• ✅ Sin modificación de los servidores backend más allá de agregar la VIP a un dispositivo loopback/terminación de túnel con distribución L3
• ✅ Las comprobaciones de salud se ejecutan contra la VIP en los servidores backend, no en sus direcciones reales
• ✅ Comprobaciones de salud HTTP/HTTPS, sonda SYN semiabierta y UDP/TCP DNS incorporadas
• ✅ Conmutación de paquetes en el kernel con eBPF/XDP; los controladores en modo nativo evitan la asignación de sk_buff
• ✅ Soporte de múltiples VLAN
• ✅ Soporte de múltiples NIC para aplicaciones de menor ancho de banda/desarrollo
• ✅ Dispositivos de red etiquetados/enlazados para soportar alta disponibilidad/alto ancho de banda
• ✅ Observabilidad a través de una consola web, registro en Elasticsearch (en desarrollo) y métricas de Prometheus
• ✅ Soporte de IPv6 y capacidad de mezclar backends IPv4 e IPv6 con cualquier tipo de VIP.
• ✅ Distribución de tráfico de capa 3 con soporte para IP-in-IP, GRE, FOU y GUE.

Inicio rápido

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.git
• cd vc5/cmd
• cp 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)
• Una consola web estará en el puerto 80 de su servidor balanceador de carga por defecto.
• Agregue su VIP al dispositivo loopback en sus servidores backend (por ejemplo: ip addr add 192.168.101.1/32 dev lo)
• Configure su red/cliente para enviar tráfico para su VIP al balanceador de carga, ya sea mediante BGP (consulte el archivo de configuración) o enrutamiento estático.

Es casi seguro que es más fácil usar el binario de la última versión de Github (compilado para x86-64). Este habrá sido probado en producción, por lo que debería ser confiable. Asegúrese de que su configuración sea compatible con esta versión utilizando el script config.pl de la versión etiquetada (o, por supuesto, puede crear su propio JSON de configuración como prefiera).

Si actualiza el archivo de configuración YAML y regenera el JSON (make config.json), puede recargar la nueva configuración enviando una SIGINT (Ctrl-C) o SIGUSR2 al proceso. SIGQUIT (Ctrl-\) o SIGTERM harán que el proceso cierre las conexiones BGP de forma ordenada y salga.

Un ejemplo más complejo con un dispositivo Ethernet enlazado LACP que consta de dos interfaces (Intel X520 de 10 Gbps en mi servidor de pruebas), con modo de controlador XDP nativo habilitado y VLAN etiquetadas:

Entrada vlans de config.yaml:

vlans:
  10: 10.1.10.0/24
  20: 10.1.20.0/24
  30: 10.1.30.0/24

Línea de comandos:

./vc5 -n 10.1.10.100 config.json enp130s0f0 enp130s0f1

El binario detectará sus interfaces VLAN buscando dispositivos con direcciones IP contenidas en los prefijos de VLAN del archivo de configuración. Si usa interfaces físicas separadas sin etiquetar, esto ahora debería funcionar de forma transparente sin configuración adicional; simplemente enumere todas las interfaces en la línea de comandos para que el código eBPF se cargue en cada una de ellas.

Debido a que el estado de la conexión se rastrea por núcleo (BPF_MAP_TYPE_LRU_PERCPU_HASH), debe asegurarse de que RSS (Receive Side Scaling) enrute consistentemente los paquetes de un flujo al mismo núcleo de CPU en caso de que su conmutador seleccione una interfaz diferente cuando cambie la topología LACP. Desactive irqbalance, asegúrese de que la configuración de canales sea la misma en cada interfaz (ethtool -l/-L) y que la coincidencia del hash de flujo RSS coincida (ethtool -x/-X).

La configuración se puede probar iniciando una conexión de larga duración (por ejemplo, usando iperf con la opción -t) a un conjunto de servidores backend, luego deshabilitando el backend elegido con un asterisco después de la dirección IP en el archivo de configuración, determinando qué interfaz está recibiendo el flujo en el balanceador de carga (por ejemplo, watch -d 'cat /proc/interrupts | grep enp130s0f' y busque el contador IRQ que aumenta rápidamente) y luego sacando esta interfaz de LACP (ifenslave -d bond0 enp130s0f0). Debería ver que el flujo se mueve a la otra interfaz de red pero aún llega al mismo núcleo.

Cuando use backends en múltiples subredes, para obtener el mejor rendimiento debe asegurarse de que todas las VLAN estén etiquetadas en una única interfaz troncal (enlazada LACP si tiene más de una interfaz física) con asignaciones de subred/ID de VLAN especificadas en la sección vlans del archivo de configuración.

Si esto no es posible (por ejemplo, crear interfaces troncales en vSphere no es simple), entonces puede asignar cada subred a una interfaz diferente sin etiquetar:

./vc5 10.1.10.100 config.json eth0 eth1 eth2

Antecedentes/más información

Un buen resumen de los conceptos utilizados se discute en la charla de Patrick Shuff "Building a Billion User Load Balancer" y la charla de Nitika Shirokov sobre Katran

Se incluye una consola web básica y un servidor de métricas de Prometheus:

Ahora se incluye soporte experimental de elasticsearch para registro (directo a su clúster, no es necesario raspar los registros del sistema). Cada sonda a los servidores backend se registra, por lo que si uno falla, puede ver exactamente qué error se devolvió, así como todo tipo de otras condiciones. Esto requerirá mucho refinamiento y una denominación más sensata de los parámetros de registro, etc. (si tiene alguna idea, comuníquese), pero debería permitir obtener buenas perspectivas de lo que está sucediendo con el sistema: mi primer intento muy inepto creando un panel de Kibana como ejemplo:

Rendimiento

Esto se ha probado principalmente con servidores backend Icecast con clientes extrayendo una mezcla de flujos de baja y alta tasa de bits (48 kbps - 192 kbps).

Parece que un invitado de VMware (4 núcleos, 8 GB) usando el controlador genérico XDP soporta 100 000 clientes concurrentes, 380 Mbps/700 000 pps a través del balanceador de carga y 8 Gbps de tráfico desde los backends directamente a los clientes.

En un solo Intel Xeon Gold 6314U CPU (2,30 GHz, 32 núcleos físicos, con hyperthreading habilitado para 64 núcleos lógicos) y una tarjeta Ethernet Intel 10G 4P X710-T4L-t, pude ejecutar 700 000 streams a 2 Gbps/3,8 Mpps de tráfico de entrada y 46,5 Gbps de salida. El servidor estaba más del 90 % inactivo. Desafortunadamente, no tenía los recursos disponibles para crear más clientes/servidores.

Operación

Hay tres modos de operación: simple, VLAN y basado en múltiples NIC. En modo simple, todos los hosts deben estar en la misma subred que la dirección principal del balanceador de carga. En modo VLAN (habilitado al declarar entradas en la sección "vlans" del archivo de configuración YAML/JSON), las entradas del servidor deben coincidir con una entrada de subred/CIDR de VLAN. Las interfaces etiquetadas con VLAN deben crearse en el SO y tener una dirección IP asignada dentro de la subred. En modo multi-NIC, las subredes reciben ID de la misma manera que las VLAN, pero se usa bpf_redirect() para enviar el tráfico a través de la interfaz configurada adecuadamente (en lugar de cambiar el ID de VLAN y usar XDP_TX).

En modo VLAN, todo el tráfico para el balanceador de carga debe estar en una VLAN etiquetada (todavía no se realiza inserción ni extracción de 802.1Q).