Balanceo de carga al detalle: el famoso F5 y casos reales

Quien hace operaciones o seguridad casi no puede esquivar un término: el balanceo de carga. Y al oír «balanceo de carga», a muchos la primera máquina que les salta a la cabeza es el «F5». Lo curioso es que F5 es en realidad el nombre de una empresa (F5 Networks), pero sus productos son tan famosos que acabaron convirtiéndose en el sinónimo del balanceador, igual que «búsquelo en Baidu» se volvió el apelativo de buscar.

Aquí lo contamos a fondo: qué es realmente F5, dónde se diferencian capa 4 y capa 7 y cómo se configura en escenarios reales.

1. Qué resuelve en realidad el balanceo de carga

El balanceo de carga (Load Balance) consiste, en esencia, en repartir el trabajo entre varias unidades operativas, como servidores web, FTP o servidores de aplicaciones críticas de la empresa, para que lo completen entre todos.

Desde el punto de vista técnico, expone hacia fuera unadirección de servidor virtual. Cuando el usuario se conecta, mediante NAT bidireccional deriva la conexión al servidor real más adecuado. El usuario siempre ve la misma entrada; detrás, un batallón de máquinas aguanta el peso.

Ataca tres problemas:miedo a la caída (punto único de fallo), miedo a no aguantar la carga (cuello de botella de rendimiento), miedo a no poder escalar (imposibilidad de escalar horizontalmente).

2. Capa 4 vs capa 7: la confusión más habitual

La diferencia central cabe en una frase:se debe o no interpretar el protocolo de la capa de aplicación. Ese matiz define directamente el techo de capacidades y el rendimiento.

Balanceo de capa 4 (capa de transporte)

• Nivel de trabajo: capa 4 de OSI, protocolos TCP/UDP
• Criterio de reenvío: IP de origen, IP de destino y puerto: sin tocar los datos de aplicación
• Capacidades clave: reenvío de puertos, reutilización de conexiones TCP, chequeos de salud de capa 4 (handshake TCP) y protección DDoS básica
• Rendimiento: eficiencia de reenvío altísima, al límite del hardware, latencias de microsegundos
• Escenarios típicos: bases de datos (MySQL/Redis), servicios TCP (servidores de juego, servicios Netty), balanceo de enlaces entre centros de datos
• Productos representativos: LVS, F5 (modo capa 4), HAProxy (modo capa 4), Nginx (módulo stream)

Balanceo de capa 7 (capa de aplicación)

• Nivel de trabajo: capa 7 de OSI, protocolos de aplicación como HTTP/HTTPS, DNS y FTP
• Criterio de reenvío: URL, cookies, cabeceras HTTP, parámetros de la petición, contenido JSON
• Capacidades clave: enrutado por contenido, descarga SSL, caché, limitación de tasa y circuit breakers, integración WAF, persistencia de sesión, despliegues canary
• Rendimiento: rica en funciones, pero al interpretar protocolos de aplicación la latencia sube algo (milisegundos); se compensa ampliando en clúster
• Escenarios típicos: aplicaciones web, APIs de microservicios, servicios HTTPS, despliegues canary, pasarelas de API
• Productos representativos: Nginx, HAProxy (modo capa 7), F5 (módulo capa 7), Kong, Spring Cloud Gateway

Truco para recordarlo: la capa 4 lee el «rótulo» (IP y puerto) y reenvía; la capa 7 «abre el paquete» (mira el contenido) antes de decidir a dónde mandarlo. Para rendimiento, capa 4; para florituras, capa 7.

3. Dónde radica realmente la fuerza del F5 BIG-IP

El producto estrella de F5, el BIG-IP LTM, se llama oficialmenteLocal Traffic Manager (gestor de tráfico local) y puede balancear de capa 4 a 7. No es un simple reenviador: su lista de funciones es larguísima: conmutación de aplicaciones, conmutación de sesiones, monitorización de estado, NAT inteligente, persistencia universal, gestión de errores de respuesta, pasarela IPv6, enrutado avanzado, aceleración SSL, compresión HTTP inteligente, optimización TCP, búfer de contenido, cifrado de cookies, filtrado de ataques de aplicación, protección DoS y contra SYN Flood, filtrado de paquetes tipo firewall…

De lo más práctico, destacaría:

1. Balanceo y redundancia de múltiples enlaces

Los servicios críticos suelen conectarse a varias líneas ISP para asegurar la calidad y eliminar el punto único de fallo. Aquí hay dos direcciones:

• Tráfico OUTBOUND (red interna hacia internet): el BIG-IP LC reparte inteligentemente el tráfico entre las distintas interfaces de internet y aplica NAT de dirección de origen
• Tráfico INBOUND (internet hacia la red interna): liga las direcciones públicas de los dos ISP, resuelve las peticiones DNS de ambos y responde inteligentemente según la salud de los servidores y los tiempos RTT

2. Balanceo de servidores

Ofrece el servicio a través de una VIP (IP virtual, compuesta por dirección IP y puerto TCP/UDP) y somete a los servidores objetivo a chequeos de salud continuos de L4 a L7. Al detectar un servidor averiado, lo retira del grupo de balanceo. Con iRules, además, puede abrir los paquetes TCP/UDP y aplicarles reglas según su contenido, por ejemplo dirigir el tráfico a distintos servidores según la URL.

3. Alta disponibilidad del sistema

Es donde F5 más presume. En modo redundante de dos equipos,la conmutación es de milisegundos (en el mejor caso, en menos de 200 ms) y presume un 99.999 % de disponibilidad. El principio: todas las sesiones que pasan por el equipo Active se sincronizan por el cable de datos de sincronización al equipo Backup, por eso el acceso del usuario no se interrumpe al conmutar. El chip watchdog de cada equipo vigila el pulso del otro por el cable de latidos; si el Active cae, avisa al Backup al instante para que asuma la Shared IP y las VIP.

4. Seguridad

El BIG-IP sigue el principio de diseño de un firewall:denegación por defecto. Puede cortar conexiones inactivas para frenar DoS, hacer seguimiento de ruta de origen contra la suplantación de IP y rechazar SYN sin ACK contra los ataques SYN. Su función Dynamic Reaping elimina con eficacia las conexiones inactivas durante un ataque DoS, yacelera el ritmo de corte de conexiones a medida que crece el ataque: ese detalle tiene punch. La técnica Delay Binding, por su parte, da a los servidores de backend una protección completa contra SYN Flood.

5. Aceleración SSL

Cada BIG-IP trae un chip de aceleración SSL por hardware, con una licencia incluida de 100 TPS sin coste adicional. Si más adelante necesitas ampliar, basta con subir la licencia.

4. ¿F5 o Nginx? Comparativa para elegir

Es la pregunta más repetida en el trabajo real. No compiten: más bien se complementan.

F5 BIG-IP (hardware)

• Forma de despliegue: appliance de hardware dedicado (con chips a medida)
• Rendimiento: millones de conexiones TCP, latencia de reenvío en microsegundos
• Funciones: todoterreno: capa 4+7, descarga SSL, protección DDoS, WAF, VPN, balanceo de enlaces
• Fiabilidad: redundancia por hardware (respaldo en caliente de dos equipos), 99.999 % de disponibilidad
• Coste: elevado (decenas o cientos de miles), con mantenimiento de ingenieros especializados
• Escalabilidad: depende de actualizar el hardware, poca flexibilidad
• Operación: compleja, exige conocer su interfaz de configuración y CLI propias

Nginx (software)

• Forma de despliegue: software, sobre servidores genéricos o máquinas en la nube
• Rendimiento: cientos de miles de conexiones TCP, latencia en milisegundos, escalable en clúster
• Funciones: ligero y eficaz: núcleo en capa 7, con soporte de capa 4, descarga SSL, caché, limitación de tasa y proxy inverso
• Fiabilidad: el respaldo en caliente hay que configurarlo a mano (Keepalived) y depende de la estabilidad del hardware del servidor
• Coste: gratis en su versión open source; Nginx Plus también es bastante asequible
• Escalabilidad: admite despliegue en clúster y escalado elástico en la nube
• Operación: simple, con archivos de configuración legibles; un backend lo domina rápido

Cruce de caminos para decidir, síguelo tal cual:

• Servicios TCP de alta concurrencia (juegos, bolsa) + disponibilidad extrema → F5 en capa 4
• Entrada de negocio crítico + necesidades de seguridad (WAF/DDoS) → F5 en capa 7
• Pasarela de APIs de microservicios + despliegue en nube → Nginx en capa 7
• Carga de base de datos/Redis + buena relación valor/costo → Nginx en capa 4
• Negocio mediano o pequeño + iteración rápida → Nginx (capa 4/7)
• Centro de datos corporativo + múltiples enlaces → F5 de entrada y Nginx para el balanceo interno

Esa última combinación es muy habitual en las grandes empresas: F5 custodia la puerta y Nginx gobierna el interior.

5. Caso práctico: lo retorcido que es configurar F5

La primera reacción de muchos al recibir un F5:esto no tiene nada que ver con la lógica de un switch; no sé ni por dónde empezar. Su lógica de configuración es otro sistema.

Escenario: dos servidores web dan servicio al exterior con IPs 192.168.192.10-20/24, y hay que balancear la carga mediante el puerto 80 de la dirección externa 192.168.27.100.

El balanceo más sencillo exige solo tres piezas, y su relación es de capas encadenadas:

• Node (nodo): la definición más básica; cada servidor es un Node
• Pool (grupo de recursos): un conjunto de Node que reciben y procesan tráfico, como un clúster de servidores web
• Virtual Server (servidor virtual): la entrada hacia fuera, vinculada al Pool

Flujo de datos: petición del cliente → Virtual Server → Pool → Node.

Pasos prácticos (interfaz de administración BIG-IP):

• Paso 1: activar el equipo. Al llegar el F5, actívalo primero; el asistente es sencillo, pero recuerdaque necesitas conexión a internet y conviene dejarlo hecho antes de instalarlo en el rack: lección aprendida a base de baches
• Paso 2: iniciar sesión. Abre en el navegador https://IPdeGestión; el usuario y la contraseña por defecto son admin
• Paso 3: crear las VLAN. En Network → VLANs, crea la VLAN y añade las interfaces (elígelas como Untagged)
• Paso 4: configurar las IPs. En Networks → Self IPs, define una dirección para cada VLAN
• Paso 5: configurar las rutas. En Networks → Routes, fija la pasarela por defecto o rutas estáticas
• Paso 6: configurar el Pool. En Local Traffic → Virtual Servers → Pools, define nombre, chequeo de salud (p. ej. TCP), algoritmo de balanceo (p. ej. observed-member, método de observación), e IP y puerto de los servidores reales
• Paso 7: configurar el Virtual Server. En Local Traffic → Virtual Servers, vincula el Pool de arriba y elige el método de turnos (suele usarse RoundRobin)
• Paso 8: configurar el Monitor. En Local Traffic → Monitors, comprueba la salud de los servidores y asócialo al Pool
• Paso 9: configurar Redundant, para la redundancia de dos equipos

6. Parámetros clave del Virtual Server

El corazón de F5 es el Virtual Server; descuidar unos cuantos parámetros trae problemas.

VS Type (tipo), hay tres tipos habituales:

• Performance L4: reenvío puro de capa 4; el TMM solo reparte conexiones, no toca los parámetros TCP, y la conexión cliente-servidor es 1:1. Reenvía a gran velocidad y se usa mucho en empresas. Para minimizar el impacto sobre la aplicación,si puedes elegir, da prioridad a este
• Standard VS: las conexiones TCP cliente-servidor son totalmente independientes. Se usa cuando hacen falta funciones de capa 7 (persistencia por Cookie, por Session ID, por Header, división de conexiones largas por transacción, protección contra ataques SYN). Ojo con una característica:su puerto queda siempre abierto hacia fuera: aunque todos los Node de backend estén caídos, el puerto 80 de la VIP sigue respondiendo por telnet; solo que la web no abre. Tenlo presente al diagnosticar fallos
• Forwarding IP: sirve para conectar redes internas y externas; no tiene Pool Members y el reenvío depende de la ruta local. Por defecto F5 no enruta, y hay que crear un VS en 0.0.0.0 para activar el enrutado

Los Timeout deben coincidir (este es un bache de verdad). Si en el VS hay un TCP Profile configurado, las conexiones UDP no se aceptan. Y cuidado con el valor de Idle Timeout dentro de tcp:debe ir a la par con el servidor. Si el F5 está en 150 segundos y el servidor IIS en 300, se generan montones de errores. Hay que poner de acuerdo los dos tiempos.

Address/Port Translation: vienen activados por defecto. Abre Address Translation cuando la IP del VS difiera de la de la máquina real; abre Port Translation cuando el puerto 8080 del VS apunte al puerto 80 de la dirección real.

SNAT AutoMap: por la VLAN que salga la petición, la dirección de origen SNAT es la Self IP de esa VLAN. Si hay varias Self IPs en una VLAN, se van turnando.

7. Por qué hay que entender la «persistencia de sesión»

Es el concepto más pasado por alto del balanceo de carga y también el que más líos provoca.

En sistemas de comercio electrónico o de autenticación en línea, un cliente atraviesa varias interacciones para completar una transacción. Esas interacciones estánfuertemente ligadas: al procesar el segundo paso, el servidor suele necesitar el resultado del primero. Eso exige que todas esas interaccioneslas complete el mismo servidor, sin que el balanceador las desparrame entre máquinas distintas.

Para eso existe la persistencia de sesión (Persistence). F5 la implementa vía Connectivity, con varios modos a elegir:

• Persistencia por dirección de origen: liga por la IP de origen del cliente
• Persistencia por cookie: F5 inserta automáticamente la cookie de sesión, lo más común en capa 7
• Persistencia por SSL Session ID: reutiliza la sesión SSL
• Tabla de persistencia de sesión: admite varios temporizadores y reglas de emparejamiento

¿Y si se configura mal? El usuario añade algo al carrito, refresca y ya no está, porque la petición cayó en otro servidor. Averiguar este tipo de fallo en producción cuesta muchísimo.

8. Unos cuantos detalles prácticos inevitables

Para acabar, unos baches que ya pisaron otros, con la conclusión directa:

• El chequeo de salud debe ir en el nivel correcto: si solo miras el handshake TCP, un servidor con el puerto vivo pero la aplicación muerta sigue recibiendo tráfico; para chequear la capa de aplicación, usa un Monitor de tipo HTTP y sondea interfaces como /actuator/health
• Los firewalls deben ir en «sándwich»: un solo firewall suele rondar el 30 % del caudal de línea; para subir, hay que apilar varios. Pero el firewall exige que los datos entren y salgan por él, o rechaza la conexión; la solución de balanceo de firewalls de F5 resuelve esto y da continuidad a los equipos transparentes
• La descarga SSL es el gran ahorro de CPU: deja que el F5 gestione el handshake HTTPS y el cifrado/descifrado; la aplicación Java del backend solo atiende HTTP, y la mejora de rendimiento se nota
• Antes de conectar a producción, prueba de carga: la capa 4 es rápida, pero si activas la persistencia de sesión en un VS de capa 4, introduces estado y las expectativas de rendimiento hay que recalcularlas
• Vigila tres métricas: estado del pool, caudal del servidor virtual y salud de los nodos
• Comandos de diagnóstico: tmsh show ltm pool <pool-name> para el estado del pool; tmsh show ltm virtual <vs-name> para el del servidor virtual

Para cerrar

El balanceo de carga parece un «equipo que reenvía», pero ocupa el punto más crítico de toda la arquitectura: todo el tráfico pasa por sus manos. Si está bien configurado, el usuario no percibe que existe; si está mal, el teléfono de madrugada te busca a ti.

Con la ola cloud native, soluciones de software como LVS, Nginx y HAProxy sobran para escenarios medianos y pequeños, con ventaja de coste clara. Pero en las entradas críticas de banca, bolsa o gran comercio electrónico, el valor del balanceo por hardware —estabilidad, conmutación en milisegundos, seguridad todo en uno— sigue sin tener sustituto a corto plazo.

En cuanto al nombre «F5», su paso de empresa a categoría lo dice todo: cuando un producto se usa como verbo, es que ya ganó ese mercado.

Capa 4 lee el rótulo, capa 7 abre el paquete; rendimiento, capa 4; florituras, capa 7.

Referencias: documentación oficial de F5 BIG-IP LTM, caso de balanceo F5 de la revista Network Operations and Management, comparativa técnica de balanceo capa 4/7