Fundamentos del balanceo de carga

Los balanceadores de carga se han convertido en un componente esencial de la infraestructura moderna. El crecimiento de los sistemas distribuidos, el aumento exponencial del volumen de datos, las arquitecturas de microservicios dinámicas y la computación en el borde (edge computing) exigen que los servicios online sigan siendo rápidos, disponibles y fiables a gran escala. En este artículo repaso, sin entrar en demasiados detalles, los principales tipos de balanceadores de carga, sus algoritmos y los conceptos clave para entender cómo funcionan.

Equilibradores de carga frente a proxies inversos

Aunque ambos tipos de componentes se sitúan entre clientes y servidores en una arquitectura cliente-servidor —aceptando solicitudes del primero y devolviendo respuestas del segundo—, presentan diferencias sutiles y casos de uso distintos. Echemos un vistazo.

Equilibradores de carga

Un equilibrador de carga se centra en enrutar el tráfico entrante del cliente hacia el grupo de backend adecuado (dos o más servidores backend que sirven el mismo servicio) y distribuir el tráfico entre los servidores de ese grupo.

Las capacidades más habituales de un equilibrador de carga son:

• Enrutamiento de tráfico: reenvío de solicitudes de clientes al grupo de backend adecuado según reglas específicas.
• Equilibrio de carga: distribución de solicitudes entre el servidor backend más adecuado del grupo en función de algoritmos concretos.
• Descubrimiento de servicios: detección e identificación automática de servidores backend disponibles en la red.
• Persistencia de la sesión: mantenimiento del estado de la sesión de un usuario a través de múltiples solicitudes, garantizando que todas las solicitudes del mismo usuario se envíen al mismo servidor (también conocido como session affinity o afinidad de sesión).
• Health check: sondeo de los servidores backend intentando conectarse de forma periódica (también conocido como comprobación de estado activa).
• Circuit breaker: supervisión del tráfico en vivo en busca de errores y determinación del estado de los objetivos (también conocido como verificación de estado pasiva).

Es importante diferenciar los términos enrutamiento y equilibrio y no utilizarlos indistintamente. Ten en cuenta que el equilibrio de carga implica enrutar solicitudes, pero lo contrario no es necesariamente cierto. El enrutamiento del tráfico toma una decisión sobre dónde reenviar las solicitudes y el equilibrio de carga distribuye esas solicitudes entre un conjunto de recursos diseñados para procesarlas.

Los beneficios resultantes de estas funcionalidades incluyen:

• Rendimiento: la distribución del tráfico entre servidores backend mejora los tiempos de respuesta.
• Disponibilidad: detección y redirección del tráfico lejos de los servidores backend fallidos.
• Escalabilidad: permite un escalado horizontal fluido de servidores backend.
• Seguridad: ocultar los servidores backend reduce la superficie de ataque y limita las amenazas externas.

Proxies inversos

Por el contrario, un proxy inverso se centra únicamente en enrutar el tráfico entrante del cliente hacia el servidor backend adecuado, incluso cuando solo un servidor atiende un único servicio (normalmente un servidor web).

Ten en cuenta que la función principal de un proxy inverso es aceptar solicitudes y reenviarlas a los servidores; no es estrictamente necesaria ninguna lógica o funcionalidad adicional. Sin embargo, los proxies inversos suelen incorporar una amplia gama de capacidades, de las cuales el equilibrio de carga es solo una.

En consecuencia, un proxy inverso puede ofrecer, además de estas capacidades, las siguientes funcionalidades:

• Transformación de solicitud/respuesta: reescritura de URLs para adaptarlas a los requisitos del servidor backend, añadiendo o eliminando headers, modificando cookies o incluso el cuerpo de la respuesta.
• Caching: almacenamiento de contenido estático y dinámico para mejorar los tiempos de respuesta en solicitudes posteriores.
• Compresión: codificación, reestructuración o modificación de datos para reducir el tamaño de los datos transmitidos y mejorar la velocidad de entrega.
• Terminación SSL/TLS: proporciona un único punto de configuración y administración, y descarga el proceso de cifrado/descifrado del tráfico fuera de los servidores web.
• Firewall de aplicaciones web (WAF): inspección y filtrado de solicitudes entrantes para proteger los servidores backend de la exposición directa a Internet.
• Registro centralizado: intercepta las solicitudes de los clientes dirigidas a los servidores backend y las registra antes de reenviarlas.

Por todo lo anterior, beneficios adicionales a los del balanceador de carga son:

• Flexibilidad: unificar varios dominios y subdominios bajo una misma dirección IP e identificar qué sistema backend debe manejar la solicitud.
• Mantenibilidad: abstraer a los clientes de los servidores backend facilita el mantenimiento y las actualizaciones, como desactivar un servidor o reemplazar software o hardware.
• Rendimiento: el caching, la compresión y la terminación SSL/TLS mejoran el rendimiento web al reducir el tiempo necesario para generar una respuesta y devolverla al cliente.
• Seguridad: inspeccionar y filtrar el tráfico del cliente protege los servidores backend de ataques DDoS, inyección SQL, cross-site scripting y otros comportamientos maliciosos.
• Observabilidad: debido a que todas las solicitudes de los clientes se enrutan a través del proxy inverso, es un punto excelente para el registro y la auditoría.

¿Son, por lo tanto, lo mismo los balanceadores de carga y los proxies inversos? La respuesta corta es no. Si bien los balanceadores de carga son un tipo particular de proxy inverso, no todos los proxy inversos funcionan necesariamente como balanceadores de carga. Sin embargo, debido a que los balanceadores de carga actúan principalmente como servidores proxy inversos, los términos equilibrador de carga y proxy inverso a menudo se tratan como equivalentes. Algunas soluciones populares de proxy de código abierto con capacidades de equilibrio de carga incluyen Apache (mod_proxy_balancer), Nginx, HAProxy y Envoy.

Balanceadores de carga de capa 4 frente a capa 7

Para comprender estas distinciones, es importante tener en cuenta el modelo OSI. Úsalo con precaución, ya que es un marco teórico destinado a brindar orientación más que una explicación universal. Sin embargo, una versión extremadamente simplificada servirá para nuestros propósitos:

Es importante tener en cuenta que un equilibrador de carga etiquetado con un nivel de capa podría proporcionar las capacidades de ese nivel y de los inferiores. Por lo tanto, un equilibrador de carga de capa 7 también podría realizar funciones de capa 4, etc.

Aunque técnicamente existen balanceadores de carga de capa 2, se utilizan en escenarios muy especializados. Por tanto, nos centraremos en los balanceadores de carga de capa 4 y capa 7, concretamente aquellos relacionados con los protocolos TCP y HTTP (ya que HTTP utiliza TCP como protocolo de transporte).

Capa 4

Los balanceadores de carga de capa 4 funcionan en la capa de transporte y toman decisiones de enrutamiento prácticamente en función de la dirección IP (capa 3) y el número de puerto (capa 4) que aparecen en el encabezado del paquete. No inspeccionan los datos de la aplicación, lo que los hace más rápidos e ideales para el tráfico TCP y UDP.

Ventajas:

• Rendimiento rápido: no hay inspección de datos; el equilibrador de carga simplemente reenvía paquetes de red opacos hacia y desde el servidor en función de puertos y direcciones IP.
• Pequeña superficie de ataque: dado que no hay inspección de datos, el contenido de los paquetes no puede verse comprometido.
• Conexiones TCP maximizadas: la cantidad de conexiones TCP simultáneas se maximiza manteniendo solo una conexión NAT entre el cliente y el servidor backend (máximo de conexiones simultáneas = número de servidores backend × máximo de conexiones por servidor backend).
• Independiente del protocolo de aplicación: operar en la capa de transporte maneja el movimiento de datos entre dispositivos sin conocimiento del contenido de los mensajes de las capas superiores.

Desventajas:

• Equilibrio de carga simple: no pueden diferenciar entre diferentes tipos de contenido ni aplicar reglas de enrutamiento específicas basadas en los datos de la aplicación.
• Conexiones fijas: todos los paquetes se enrutan a un único servidor en el backend hasta la siguiente conexión, cuando se volverá a seleccionar un servidor según el algoritmo (los protocolos de multiplexación/mantenimiento de actividad son un problema aquí).
• Opciones de persistencia limitadas: la dirección IP de origen es la única opción de persistencia cuando los datos compartidos o el estado de la sesión se almacenan localmente en el servidor backend.
• Contenido sin caché: debido a que no examinan el contenido de los paquetes que se transmiten, no pueden realizar el almacenamiento en caché.
• No orientado a microservicios: la rigidez y el equilibrio de carga simple los hacen menos efectivos para la comunicación entre procesos de microservicios basada en API REST.

Las técnicas de multiplexación y mantenimiento son cruciales para optimizar las comunicaciones de red, pero son conceptos diferentes. Si bien la multiplexación permite que múltiples solicitudes de servicio compartan una única conexión, keep-alive garantiza que la conexión entre dispositivos permanezca abierta incluso cuando no se transmiten datos, lo que reduce la sobrecarga de establecer nuevas conexiones.

Conexiones TCP de capa 4

También hay balanceadores de carga de proxy inverso de capa 4 que pueden terminar conexiones en la capa de equilibrio de carga y luego distribuir el tráfico TCP a los servidores, con o sin SSL. Sin embargo, para el tráfico HTTP/S, se recomienda utilizar un equilibrador de carga de capa 7.

Capa 7

Los balanceadores de carga de capa 7 funcionan en la capa de aplicación y toman decisiones de enrutamiento basadas principalmente en mensajes a nivel de aplicación (capas 7 a 5), como headers HTTP, cookies y URLs. Esto permite un enrutamiento más basado en contenido y algoritmos avanzados de equilibrio de carga.

Recuerda que nos estamos centrando en HTTP, pero las decisiones pueden basarse en datos de cualquier otro protocolo de aplicación soportado por el balanceador de carga, como MongoDB, MySQL o Redis (con soporte experimental en Istio).

Ventajas:

• Equilibrio de carga inteligente: lectura de mensajes en el tráfico de red y toma de decisiones de enrutamiento en función de su contenido, al que también se pueden aplicar optimizaciones y transformaciones.
• Contenido en caché: inspeccionar el contenido de los paquetes transmitidos permite cachear el contenido al que se accede con frecuencia, como imágenes o archivos estáticos, reduciendo la carga en los servidores backend.
• Conexiones equilibradas: creación de una conexión TCP con cada servidor para una única conexión de cliente en lugar de elegir un único servidor (funciona bien con protocolos de multiplexación y keep-alive).
• Múltiples opciones de persistencia: la dirección IP de origen, la cookie HTTP y el ID de sesión SSL son solo algunas opciones de persistencia cuando los datos compartidos o el estado de la sesión se almacenan localmente en el servidor backend.
• Orientado a microservicios: las conexiones equilibradas y el equilibrio de carga inteligente los hacen más adecuados para la comunicación entre procesos entre microservicios basada en APIs REST.

Desventajas:

• Mayor consumo de recursos: inspeccionar el contenido de los paquetes y manejar el cifrado y descifrado SSL/TLS son tareas que requieren un uso intensivo de la CPU y más potencia informática.
• Superficie de ataque más grande: almacenar certificados SSL en el balanceador de carga y examinar el contenido del paquete puede hacer que los problemas de seguridad de las aplicaciones sean explotables.
• Conexiones TCP limitadas: la cantidad de conexiones TCP simultáneas está limitada porque el tráfico finaliza y las conexiones TCP luego se crean o reutilizan en el servidor seleccionado (máximo de conexiones simultáneas = máximo de conexiones del balanceador de carga - número de servidores backend).
• Depende del protocolo de aplicación: el equilibrador de carga debe comprender el protocolo de la aplicación porque opera en la capa de aplicación y maneja el contenido de cada mensaje.

Conexiones TCP de capa 7

Topologías del balanceador de carga

El equilibrio de carga del lado del cliente y del lado del servidor son dos formas de distribuir la carga de trabajo entre varios servidores. La principal diferencia es dónde se encuentra la lógica de equilibrio de carga y quién toma la decisión de a qué servidor enviar la solicitud.

Lado del servidor

En el equilibrio de carga del lado del servidor, las instancias de un servicio se implementan en varios servidores y se coloca un equilibrador de carga delante de ellos. Primero, todas las solicitudes entrantes llegan al balanceador de carga, que actúa como intermediario. Luego determina qué servidor debe recibir cada solicitud según un algoritmo. Dependiendo de cómo esté conectado a la red y a los servidores, tenemos:

Un brazo

En una configuración de un solo brazo, el equilibrador de carga no está en la ruta del tráfico entre el cliente y el servidor, sino que actúa como un proxy que realiza NAT/SNAT de origen para enrutar el tráfico entre ellos.

Topología de un brazo del lado del servidor

Dos brazos

En una configuración de dos brazos, el equilibrador de carga tiene dos interfaces de red conectadas a dos subredes diferentes. En este modo, el equilibrador de carga actúa como un puente entre el cliente y el servidor, y los servicios virtuales y los servidores están en subredes diferentes.

Topología de dos brazos del lado del servidor

Lado del cliente

En el equilibrio de carga del lado del cliente, las instancias de un microservicio se implementan en varios servidores. La lógica de equilibrio de carga es parte del propio cliente: mantiene una lista de servidores y determina qué servidor debe recibir cada solicitud basándose en un algoritmo. Hay dos enfoques:

Sidecars

Los balanceadores de carga Sidecar se ejecutan como procesos o contenedores separados junto con las aplicaciones cliente. Distribuyen el tráfico entre múltiples servidores sin agregar un salto de red adicional o un cuello de botella centralizado. También proporcionan funciones como comprobaciones de estado, reintentos, interrupción de circuitos y métricas. Los ejemplos populares incluyen:

• Envoy (Istio): Istio utiliza una versión extendida del proxy Envoy, un proxy de alto rendimiento desarrollado en C++, para mediar en todo el tráfico entrante y saliente de los servicios en la malla de servicios. Implementados como sidecars, los proxies de Envoy son los únicos componentes de Istio que interactúan con el tráfico del plano de datos, mejorando los servicios con las funciones integradas de Envoy.

• Linkerd2-proxy (Linkerd): el plano de datos de Linkerd comprende microproxies ultraligeros escritos en Rust e implementados como contenedores sidecar dentro de módulos de aplicaciones. Estos servidores proxy interceptan de forma transparente las conexiones TCP hacia y desde cada pod. A diferencia de Envoy, Linkerd2-proxy está diseñado específicamente para casos de uso de malla de servicios en lugar de como un proxy de propósito general.

Topología sidecar del lado del cliente

Bibliotecas

Un equilibrador de carga del lado del cliente basado en biblioteca es un componente de software que se ejecuta dentro de la aplicación cliente y distribuye solicitudes entre múltiples servidores sin un componente centralizado. Requiere un mecanismo de descubrimiento de servicios para obtener la lista de servidores disponibles y un algoritmo de equilibrio de carga para seleccionar el mejor servidor para cada solicitud. Los ejemplos populares incluyen:

• Ribbon (Netflix OSS): es una biblioteca en la nube que proporciona equilibrio de carga del lado del cliente para aplicaciones distribuidas. Es parte del software de código abierto de Netflix (Netflix OSS) y se integra con otros componentes de Netflix, como Eureka e Hystrix. Ribbon permite a los usuarios implementar tus propias políticas de equilibrio de carga o utilizar políticas predefinidas, como round robin, filtrado de disponibilidad, round robin ponderado, ring hash y solicitud mínima.

• Spring Cloud Loadbalancer (Spring Cloud): es una biblioteca de balanceador de carga que proporciona equilibrio de carga del lado del cliente para aplicaciones Spring Cloud. Admite modos reactivos y de bloqueo, integración de descubrimiento de servicios, verificación de estado, almacenamiento en caché y métricas. Spring Cloud Loadbalancer puede utilizar diferentes algoritmos de equilibrio de carga, como round robin, aleatorio y el mejor disponible.

• gRPC Load Balancer (Google): gRPC es un marco RPC implementado sobre HTTP/2. El equilibrio de carga del lado del cliente permite a los clientes gRPC distribuir la carga de manera óptima entre los servidores disponibles. El cliente recibe informes de carga de los servidores backend e implementa los algoritmos de equilibrio de carga.

Topología de biblioteca del lado del cliente

Modos de equilibrio de carga

Los modos de equilibrio de carga se pueden implementar según cómo los equilibradores de carga manejan las direcciones IP de origen y destino de los paquetes que se reenvían entre los clientes y los servidores. El modo más apropiado dependerá del escenario y la topología específicos, teniendo en cuenta que se pueden usar múltiples modos de equilibrio de carga al mismo tiempo o en combinación entre sí.

Enrutamiento directo de capa 4 (DR)

También conocido como Direct Server Return o nPath, este modo permite a los servidores backend devolver directamente las respuestas a los clientes, sin pasar por el equilibrador de carga. Este modo requiere pocos cambios en tu infraestructura existente y ofrece alto rendimiento y escalabilidad, ya que reduce el ancho de banda y la carga de procesamiento en el balanceador de carga. Sin embargo, también requiere algunos cambios de configuración en los servidores y la conectividad de capa 2, por lo que el equilibrador de carga debe estar en la misma subred que los servidores.

El modo DR funciona cambiando la dirección MAC de destino del paquete entrante para que coincida con el servidor seleccionado sobre la marcha (suplantación de identidad ARP). Cuando el paquete llega al servidor, el servidor debe poseer la dirección IP de los Servicios Virtuales (VIP). Esto significa que debe asegurarse de que:

• Los servidores (y la aplicación de equilibrio de carga) responden tanto a la propia dirección IP de los servidores como a la VIP.
• Los servidores no responden a las solicitudes ARP para el VIP (solo el equilibrador de carga debe hacer esto).

Modo de enrutamiento directo de capa 4

El modo DR no admite la traducción de puertos (por ejemplo, VIP:80 a RIP:8080) y es transparente: el servidor ve la dirección IP de origen del cliente.

Túnel de capa 4 (TUN)

De manera similar a la DR de capa 4, TUN también utiliza el retorno directo del servidor, pero utiliza un túnel IP para reenviar solicitudes desde el equilibrador de carga a los servidores. Esto permite utilizar servidores de diferentes centros de datos y envía las respuestas directamente a los clientes sin pasar por el equilibrador de carga.

El modo TUN puede funcionar en cualquier red, siempre que el equilibrador de carga y los servidores admitan el túnel IP, una técnica que encapsula un paquete IP dentro de otro paquete IP, creando un túnel entre dos puntos finales. El equilibrador de carga utiliza esta técnica para enviar la solicitud del cliente original al servidor, sin modificar las direcciones IP de origen o destino. El servidor extrae la solicitud original del túnel, la procesa y envía la respuesta al cliente utilizando la dirección IP de origen original como destino.

Modo Túnel de Capa 4

El modo TUN no admite la traducción de puertos y depende de cómo estén configurados el equilibrador de carga y los servidores para la transparencia.

Traducción de direcciones de red (NAT) de capa 4

El modo NAT de capa 4 también es una solución de alto rendimiento, aunque no tan rápido como el modo DR de capa 4 porque las respuestas del servidor deben regresar al cliente a través del equilibrador de carga en lugar de hacerlo directamente. El equilibrador de carga traduce todas las solicitudes del Servicio Virtual a los servidores. El modo NAT se puede implementar de las siguientes maneras:

One-Arm: El VIP se encuentra en la misma subred que los servidores. Para admitir clientes remotos, la puerta de enlace predeterminada en los servidores debe ser una dirección IP en el balanceador de carga y el enrutamiento en el balanceador de carga debe configurarse para que el tráfico de retorno se enrute a través del enrutador. Para admitir clientes locales, el tráfico de retorno normalmente se enviaría directamente al cliente sin pasar por el equilibrador de carga, lo que interrumpiría el modo NAT. Para solucionar este problema, se debe modificar la tabla de enrutamiento de los servidores para forzar que el tráfico de retorno pase a través del equilibrador de carga.

Modo de un brazo NAT de capa 4

Dos brazos: El VIP está ubicado en una subred y los servidores en la otra. Esto se puede lograr utilizando dos adaptadores de red o creando VLAN en un solo adaptador. La puerta de enlace predeterminada en los servidores debe configurarse para que sea una dirección IP en el equilibrador de carga. Los clientes pueden ubicarse en la misma subred que el VIP o en cualquier subred remota siempre que puedan enrutarse al VIP.

Modo de dos brazos NAT de capa 4

Si deseas que se pueda acceder a los servidores a través de sus propias direcciones IP para servicios sin equilibrio de carga, como SSH, deberás configurar reglas de script de firewall SNAT y DNAT individuales para cada servidor o agregar VIP adicionales.

El modo NAT admite la traducción de puertos y también es transparente.

Capa 4/7 Traducción de direcciones de red de origen (SNAT)

El modo SNAT de capa 4 también es una solución de alto rendimiento, aunque no tan rápido como el modo NAT de capa 4 o el modo DR de capa 4. El balanceador de carga traduce todas las solicitudes de la misma manera que el modo NAT, pero una regla SNAT de iptables traduce la dirección IP de origen para que sea el balanceador de carga en lugar de la dirección IP original del cliente.

Cuando se trata del modo SNAT de capa 7, se convierte en un proxy completo en la capa de aplicación, por lo que cualquier servidor en el clúster puede estar en cualquier subred accesible, incluso a través de Internet o WAN. Las solicitudes entrantes finalizan en el equilibrador de carga y el proxy genera una nueva solicitud correspondiente al servidor elegido, lo que no resulta tan rápido como los modos de Capa 4.

El modo SNAT de capa 4/7 no requiere cambios de configuración específicos del modo en los servidores y se puede implementar usando una configuración de uno o dos brazos:

Modo SNAT de un brazo de capa 4/7

Modo de dos brazos SNAT de capa 4/7

No debe utilizar la misma combinación RIP:PORT para los VIP del modo SNAT de capa 4/7 porque las reglas de firewall requeridas entran en conflicto.

El modo SNAT de capa 4/7 admite la traducción de puertos y no es transparente.

Si se requiere transparencia, el modo SNAT de capa 7 se puede configurar para proporcionar la dirección IP del cliente a los servidores de dos maneras:

• Insertando un encabezado que contiene la dirección IP de origen del cliente.
• Modificando el campo de dirección de origen de los paquetes IP y reemplazando la dirección IP del balanceador de carga con la dirección IP del cliente.

Algoritmos de equilibrio de carga

Finalmente, veamos los algoritmos de equilibrio de carga: un conjunto de reglas implementadas en diferentes capas del modelo OSI que sigue un equilibrador de carga para seleccionar el mejor servidor en un grupo para cada solicitud de cliente mientras se mantiene la distribución uniforme y eficiente. Los algoritmos de equilibrio de carga se dividen en dos categorías principales:

Algoritmos de equilibrio de carga estático

El equilibrio de carga estático sigue reglas fijas y es independiente del estado actual del servidor, enviando una cantidad igual de tráfico a cada servidor de un grupo, ya sea en un orden específico o de forma aleatoria. Se recomiendan algoritmos de equilibrio de carga estático cuando:

• Tienes una fluctuación baja o estable en el tráfico entrante y no necesitas adaptarte a las condiciones cambiantes de la red.
• Quieres simplificar la configuración y el mantenimiento de tus servidores y balanceador de carga.
• Tienes servidores con capacidades y recursos similares y deseas distribuir el tráfico de manera uniforme entre ellos.
• Te preocupa el consumo de recursos y la latencia de tu balanceador de carga y servidores.

Veamos algunos ejemplos de algoritmos de equilibrio de carga estático:

Round-robin: Es una forma sencilla de distribuir las solicitudes de los clientes entre un grupo de servidores. Se envía una solicitud de un cliente a cada servidor por turno. El algoritmo le indica al equilibrador de carga que regrese al principio de la lista y repita el proceso. Es fácil de implementar y es el algoritmo de equilibrio de carga más utilizado, y funciona mejor cuando los servidores tienen capacidades informáticas aproximadamente idénticas.

Algoritmo de turnos

Round-Robin ponderado: es una mejora con respecto al algoritmo de round-robin anterior que puede resultar en una distribución desigual del tráfico. Distribuye las solicitudes de los clientes en función de las capacidades o pesos individuales de los servidores. Un servidor con un peso mayor recibirá más solicitudes que un servidor con un peso menor. El algoritmo recorre los servidores y asigna un número fijo de solicitudes a cada servidor según tu peso.

Algoritmo de turnos ponderado

IP Hash: Se basa en las direcciones IP de origen y destino de cada paquete. Utiliza un cálculo matemático para generar un valor hash que determina a qué servidor enviar el paquete. De esta manera, los paquetes de las mismas direcciones IP de origen y destino siempre se envían al mismo servidor, lo que garantiza la persistencia de la sesión y un rendimiento óptimo.

Algoritmo Hash de IP

Algoritmos de equilibrio de carga dinámico

El equilibrio de carga dinámico utiliza algoritmos que tienen en cuenta la disponibilidad actual, la carga de trabajo y el estado de cada servidor y distribuyen el tráfico en consecuencia. Se recomiendan algoritmos de equilibrio de carga dinámico cuando:

• Tienes una gran fluctuación en el tráfico entrante y necesitas adaptarte a las condiciones cambiantes de la red.
• Quieres evitar sobrecargar o fallar cualquier servidor y garantizar un rendimiento y disponibilidad óptimos para tu aplicación.
• Tienes servidores con diferentes capacidades y recursos y deseas distribuir el tráfico en consecuencia.
• Estás dispuesto a invertir en una configuración y monitoreo más complejos de tus servidores y balanceador de carga.

Veamos algunos ejemplos de algoritmos de equilibrio de carga dinámico:

Menos conexiones: Comprueba qué servidores tienen la menor cantidad de conexiones abiertas en ese momento y envía tráfico a esos servidores. Esto supone que todas las conexiones requieren aproximadamente la misma potencia de procesamiento.

Algoritmo de conexión mínima

Conexión mínima ponderada: Asigna diferentes pesos a cada servidor, asumiendo que algunos servidores pueden manejar más conexiones que otros. Las solicitudes entrantes se distribuyen a los servidores con el tiempo de respuesta más bajo en relación con tu peso.

Algoritmo de conexión mínima ponderada

Mínimo tiempo de respuesta: Distribuye el tráfico de red entre los servidores en función del número de conexiones activas y el tiempo de respuesta promedio de cada servidor (tiempo hasta el primer byte o TTFB). Esto supone que los servidores con tiempos de respuesta más bajos están menos ocupados y pueden manejar nuevas solicitudes más rápido.

Algoritmo de menor tiempo de respuesta

Tiempo de respuesta mínimo ponderado: Nuevamente, se asignan pesos diferentes a cada servidor. Las solicitudes entrantes se distribuyen al servidor con la menor proporción de peso y conexiones activas, y valores de tiempo de respuesta.

Algoritmo de tiempo de respuesta mínimo ponderado

Conclusión

En este artículo has visto los conceptos clave que conviene conocer al trabajar con infraestructuras basadas en balanceadores de carga y proxies inversos: sus diferencias, los niveles de capa 4 y capa 7, las topologías cliente-servidor, los modos de balanceo y los principales algoritmos, tanto estáticos como dinámicos.

Se trata, no obstante, de un campo lo bastante amplio y complejo como para merecer un estudio propio. En próximas entradas te mostraré cómo implementar algunas soluciones actuales para escenarios concretos.