Hay muchos factores que intervienen para que su sitio web sea rápido y fiable. Uno de los más importantes es el balancear de carga: el proceso de distribuir el tráfico entre varios servidores o recursos para que ningún servidor se sobrecargue mientras los demás están subutilizados.
Un balanceador de carga puede hacer más rápido su sitio web enviando a los usuarios hacia el servidor con el menor número de peticiones, o enviándolos hacia el servidor que tenga la mejor velocidad de conexión o Incluso puede dirigir el tráfico en función del tipo de aplicación (por ejemplo, dirigir todas las peticiones de archivos estáticos a un servidor, o todas las peticiones dinámicas a otro).
¿Qué es un Balanceador de Cargas o Load Balancer?
Un balanceador de carga es una herramienta que distribuye el tráfico entre los backends utilizando verificaciones de estado para garantizar que solo las instancias en buen estado reciban tráfico.
Puedes ver que utilizamos el concepto de backend o instancias en lugar de Servidores porque el balanceador puede trabajar con una variedad más amplia de dispositivos que van más allá de los servidores o máquinas virtuales.
En general la arquitectura de un balanceador de carga consta de 5 elementos:
- Dirección IP. Una dirección IP pública si se pretende que sea de cara al público o una dirección IP privada si se pretende que sea interna.
- Grupo backend. Un grupo backend de máquinas virtuales y reglas sobre cuáles deben recibir tráfico.
- Sondas de Salud. Son sondas o reglas diseñadas para evaluar el estado de los recursos en el grupo backend.
- Regla de equilibrio de carga. Combina direcciones IP, grupo de backend y sondas de estado, junto con reglas sobre cómo equilibrar la carga de tráfico a los recursos de backend y en qué puerto de backend del grupo de backend debe ir el tráfico.
- Regla NAT opcional. Permite la traducción de direcciones de red (NAT) de puerto a uno de los servidores backend en un puerto específico del grupo.
Tipos de balanceadores de carga
Existen varios tipos de balanceadores en base a sus capacidades, pero a grandes rasgos los podemos dividir en dos grupos: Los balanceadores de aplicaciones y los balanceadores de red.
Los balanceadores de carga de red (Network Load Balancer) trabajan en la capa 4 del modelo OSI (TCP, UDP) lo que significa que enruta los paquetes basándose en sus direcciones IP de origen y destino, así como en los puertos TCP o UDP. Estos balanceadores son más rápidos, pero tienen ciertas limitaciones.
Los balanceadores de carga de red, no son una buena solución para todos los problemas. Por ejemplo, si está intentando equilibrar la carga entre distintos tipos de componentes de aplicaciones (servidores web frente a servidores de bases de datos), un balanceador de carga de red no le ayudará mucho, ya que sólo equilibra las peticiones entre servidores del mismo nivel. En este caso, tendrá que encontrar otra forma de resolver las solicitudes en función de su tipo de contenido, es aquí donde entre en juego el balanceador de aplicaciones.
Los balanceadores de aplicaciones (Aplication Load Balancer) operan en la capa 7 del modelo OSI (HTTP y HTTPS), que es el nivel más alto. Este tipo de balancedores pueede tener en cuenta una gama de datos más amplia para balancear, que sus homólogos de capa 4, como las cabeceras HTTP y los identificadores de sesión SSL, por lo que son los preferidos para balancear aplicaciones web.
Estos dos tipos de balanceador pueden ser tanto físico o se pueden encontrar en forma de un aplicativo en la nube. Entre los balanceadores físicos más populares encontramos los BIG IP de F5 mientras que en la nube podemos encontrar balanceadores propietarios de Azure, AWS, Google o F5 entre otros.
¿Cuándo se requiere un balanceador de carga?
El balanceador de carga distribuye la carga de trabajo de una única aplicación o servicio entre varios servidores para aumentar la capacidad, fiabilidad y eficiencia de la aplicación o servicio. Por lo que podemos decir que se requiere un balanceador cuando se desea aumentar los siguientes aspectos en la solución:
- Disponibilidad
- Escalabilidad
- Seguridad
- Desempeño
Balanceadores de carga públicos vs internos
Un balanceador de carga público se utiliza cuando necesita equilibrar la carga del tráfico entrante de Internet hacia sus máquinas virtuales. Este tipo de balanceador de carga requiere que asigne una dirección IP pública al frontend del balanceador de carga. También es importante tener en cuenta que los balanceadores de carga públicos pueden proporcionar conexiones salientes a Internet para las máquinas virtuales que se encuentran dentro de su red virtual. Para que esto suceda, lo que hacen los balanceadores de carga públicos es traducir las direcciones IP privadas de las máquinas virtuales a IP públicas. Esto les permite comunicarse externamente aunque las propias máquinas virtuales no tengan direcciones IP públicas.
Los balanceadores de carga internos pueden utilizarse en situaciones en las que sólo se requieren direcciones IP privadas en el frontend. Esto significa que los equilibradores de carga internos se limitan a casos de uso en los que sólo necesita equilibrar la carga de tráfico dentro de su red virtual Azure, o desde una red local que se ha conectado a su red virtual a través de una conexión VPN o ExpressRoute.
Cuáles son los tipos de balanceadores de carga en Azure
Debido a la propia naturaleza de la nube, la oferta de los balanceadores se incrementa con soluciones específicas para cada necesidad de disponibilidad geográfica y tipo de tráfico a balancear. Por ejemplo en Azure podemos encontrar cuatro herramientas que cubren la función de balanceo:
- Azure Application Gateway
- Azure Front Door
- Azure Load Balancer
- Azure Traffic Manager
La siguiente imagen de la página de Azure muesra la descripción de los servicios con un par de anotaciónes importantes.
Azure hace mucho incapie en las caracteristicas regionales y globales de cada balanceador ya que nos permiten aumentar la disponibilidad y controlar la latencia a nivel global.
Balanceadores Globales vs Regionales
Estos balanceadores pueden clasificarse en dos categorías: globales vs regionales y HTTP(S) vs No-HTTP(S).
Los balanceadores de carga globales distribuyen el tráfico de red entre varias regiones (por ejemplo, Norteamérica o Europa). Son adecuados para cargas de trabajo que requieren una latencia de red constante entre usuarios finales y servidores con distintas ubicaciones geográficas.
Los balanceadores de carga regionales distribuyen el tráfico de red sólo dentro de la misma región. Son adecuados para cargas de trabajo que no requieren una conectividad constante entre usuarios finales y servidores en distintas ubicaciones geográficas y cuando la latencia no es un problema.
Cada uno de los servicios de Azure presenta sus propias caracterisitcas, que se enlistan a continuación:Front Door es una red global de entrega de aplicaciones que proporciona funciones de equilibrio de carga y aceleración para aplicaciones web. Incluye funciones como entrega de aplicaciones de capa 7, como descarga TLS/SSL, enrutamiento basado en rutas, conmutación rápida por error, cortafuegos de aplicaciones web y almacenamiento en caché para mejorar el rendimiento y la alta disponibilidad de las aplicaciones web. Esta opción se utilizaría en escenarios como el equilibrio de carga de una aplicación implementada en varias regiones de Azure.
Podemos decir que el Azure Front Door es el hijo con esteroides entre el Microsoft Azure Content Delivery Network y el Azure Web Application Firewall. En otras palabras podemos decir que es el Azure Content Delivery Network, similar al de Cloudflafe, AWS Cloudfront con las funcionalidades de seguridad incluidas.
Azure Traffic Manager
El Traffic Manager es un balanceador basado en DNS que permite distribuir el tráfico a regiones Azure globales proporcionando alta disponibilidad, sin embargo, a diferencia del balanceo por DNS tradicional (DNS Round Robin) en el que no se monitorean las instancias, el servicio de Azure Trafic Manager supervisa los puntos de conexión para comprobar su estado.
El Traffic Manager integra tres categorías de algoritmos de equilibrio de carga:
- Algoritmo de rendimiento: dirige al usuario al nodo de equilibrio de carga más cercano en función de la latencia.
- Algoritmo de conmutación por error: normalmente dirige al usuario al nodo principal, pero si éste no funciona, redirige al cliente a un nodo de reserva.
- Algoritmo Round Robin – Implementa un enfoque distribuido para dirigir a los usuarios a un nodo, utilizando los pesos atribuidos a dichos nodos.
Ventajas del Azure Traffic Manager
- Distribución de Tráfico Geográfico: Azure Traffic Manager permite distribuir el tráfico de manera eficiente entre diferentes ubicaciones geográficas. Puedes dirigir a los usuarios a la instancia del servicio más cercana geográficamente, lo que mejora la latencia y la velocidad de respuesta de la aplicación. Esto es especialmente beneficioso para aplicaciones que se utilizan a nivel mundial y que requieren baja latencia para proporcionar una experiencia de usuario óptima.
- Alta Disponibilidad y Tolerancia a Fallos: Azure Traffic Manager ofrece alta disponibilidad al permitir la distribución del tráfico entre varias instancias de una aplicación en diferentes regiones de Azure. En caso de que una región experimente problemas o una instancia de la aplicación falle, el tráfico se redirige automáticamente a otras instancias disponibles. Esto mejora la tolerancia a fallos y asegura que la aplicación siga siendo accesible incluso en situaciones adversas.
- Flexibilidad en el Enrutamiento del Tráfico: Azure Traffic Manager proporciona flexibilidad en la configuración del enrutamiento del tráfico. Puedes implementar estrategias de enrutamiento basadas en la ponderación del tráfico, la disponibilidad de las instancias o reglas de enrutamiento personalizadas. Esto permite adaptar el comportamiento de enrutamiento según los requisitos específicos de la aplicación y las necesidades de negocio.
Desventajas del Azure Traffic Manager
La principal desventaja contra el Azure Load Balancer y contra el Azure Aplication Gateway es que la supervisión de estados de las instancias es más rudimentaria. Por otro lado se tienen dependencias del cache de los DNSs recursivos donde el tiempo de propagación de los cambios está supeditado al tiempo del cache del DNSs recursivo. Si se detecta que un servidor no está funcionado, el Traffic manager excluirá dicho balanceador de la rotación, sin embargo esta indicación debe viajar a través de los DNSs recursivos los cuales tienen una memoria cache con cierto tiempo e vida (TTL). Mientras esta indicación no se propague y se actualice la información del cache, el servidor afectado seguirá recibiendo tráfico que no podrá ser procesado.
Por otro lado el Traffic Manager no soporta sticky sessions (afinidad de sesiones o sesiones persistentes). Las sesiones permanentes se requieren para que un mismo servidor conteste todas las interacciones de un cliente, lo cual se requiere en escenarios como la autenticación.
Aunque el Azure Traffic Manager si soporta tráfico HTTP(S) algunos autores no lo recomiendan por la falta de capacidad para soportar Sticky Session o Sesiones Persistentes. Para escenarios donde se requieren HTTP(s) y Sesiones Persistentes se recomienda utiizar Aplication Gateway y el Azure Front Door.
Application Gateway
Application Gateway proporciona un controlador de entrega de aplicaciones (ADC) como servicio, que ofrece diversas capacidades de balanceo de carga en la capa 7. Puede utilizarlo para optimizar la productividad descargando la terminación del tráfico TLS/SSL de sus servidores web con mayor actividad de CPU al enlace de puerta de entrada. Application Gateway funciona dentro de una región en lugar de globalmente
Azure Load Balancer
Azure Load Balancer proporciona un servicio de equilibrio de carga de capa 4 con una latencia muy baja y un alto rendimiento (entrante y saliente) tanto para protocolos UDP como TCP. Se diseñó para gestionar millones de solicitudes por segundo, garantizando al mismo tiempo una alta disponibilidad de la solución. Azure Load Balancer tiene redundancia de zona, lo que garantiza una alta disponibilidad en zonas con zonas de disponibilidad. Azure Load Balancer opera dentro de una región en lugar de globalmente.
Ventajas del Azure Load Balancer
- Alta Disponibilidad y Fiabilidad: Azure Load Balancer distribuye el tráfico de red entre varias instancias de servicios, lo que garantiza la disponibilidad continua de la aplicación incluso si una instancia o región experimenta problemas. Puedes configurar Load Balancer para distribuir el tráfico entre máquinas virtuales, conjuntos de disponibilidad o direcciones IP, lo que mejora la resiliencia de la aplicación frente a fallos de hardware o actualizaciones.
- Equilibrio de Carga para Optimización del Rendimiento: El servicio de Load Balancer distribuye de manera equitativa el tráfico entre las instancias disponibles, lo que mejora la utilización de recursos y optimiza el rendimiento de la aplicación. Puedes configurar algoritmos de equilibrio de carga, como Round Robin, para garantizar una distribución uniforme del tráfico, lo que contribuye a una utilización eficiente de los recursos y a una mejor respuesta de la aplicación.
Desventajas del Balanceador de Carga de Azure (Load Balancer):
Azure Load Balancer es un balanceador básico de capa 4 y algunas de sus carencias son:
- La principal desventaja contra el Aplication Gateway es que Azure Load Balancer NO soporta TLS/SSL. El balanceador no tiene la capacidad de terminar conexiones TLS (TLS Offloading), por lo tanto la documentación de Azure menciona que el Balanceador de Cargas de Azure no esta recomendado para aplicaciones donde se utiliza HTTP(S).
- El Azure Load Balancer no es compatible con los servicios PaaS. Esto significa que no puede utilizarse con Azure App Service o Azure Traffic Manager para proporcionar alta disponibilidad a sus aplicaciones web. Esta pensado más para tráfico entre Máquinas Virtuales (VMs).
- Como mencionamos, el Azure Load Balancer se ejecuta en el nivel 4 del modelo OSI, por lo que carece de mecanismos de enrutamiento de tráfico inteligentes y basados en el contenido para el tráfico URL o HTTP. A diferencia de muchas otras soluciones de equilibrio de carga, Azure Load Balancer no actúa como proxy inverso ni interactúa con la carga útil de un flujo TCP o UDP.
Comparativa de Balanceadores Azure
Tabla comparativa de balanceadores Azure, traduccion del original de la página: https://tutorialsdojo.com/azure-load-balancer-vs-app-gateway-vs-traffic-manager/
| Traffic Manager | Load Balancer | Application Gateway | Front Door | |
| Servicio | Balanceo de tráfico basado en DNS. | Balanceador de Carga de Red. | Balanceador de Carga Web. | Entrega de aplicaciones globales |
| Network Protocols (OSI) | Capa 7 (DNS) | Capa 4 (TCP or UDP) | Capa 7 (HTTP/HTTPS) | Capa 7 (HTTP/HTTPS) |
| Tipos | – | Interno y Público | Estandar y WAF | Standard y Premium |
| Ruteo | Desempeño, Weighted, Prioridad, Geográfico, MultiValor, Subnet | Hash-based, Afinidad por IP | Basado en ruta | Latencia, Prioridad, Peso, Afinidad de la sesión |
| Servicio Global/Regional | Global | Global | Regional | Global |
| Traffico Recomendado | HTTP(S) | No-HTTP(S) | HTTP(S) | HTTP(S) |
| Endpoints | Servicio de nube, App service/slot, IP Publica | NIC (VM/VMSS), direcciones IP | direcciones IP /FQDN, Máquinas Virtuales, App services | App service, Servicio de nube, almacenamiento, Application Gateway, API Management, Direcciones IP públicas, Traffic Manager, Custom Host |
| Monitoreo de Endpoint | HTTP/HTTPS GET requests | Health probes (Sondeo de estado) | Health probes (Sondeo de estado) | Health probes (Sondeo de estado) |
| Redundacia | Resiliente a las fallas regionales | Zone redundant and Zonal | Redundante a nivel Zona | Resilient to regional failures |
| Terminación SSL/TLS | – | – | Soportado | Soportado |
| Web Application Firewall (WAF) | – | – | Soportado | Soportado |
| Sticky Sessions (Sesiones persistentes) | – | Soportado | Soportado | Soportado |
| VNet Peering | – | Soportado | Soportado | – |
| SKU | – | Basico y Estandard | Estandard y WAF (v1 & v2) | Estandard y Premium |
¿Dónde se coloca el balanceador de carga?
La ubicación más habitual es entre los servidores backend y el firewall. Esto le permite utilizar la tecnología de equilibrio de carga en esos servidores sin necesidad de modificarlos ni de modificar su configuración. Colocar el balancaeador de carga después del firewall le permite protegerse contra el tráfico malicioso que podría tratar de eludirlo yendo directamente a través del firewall en lugar de a través de su servidor web; sin embargo, esto también puede causar problemas si no hay hardware o software redundante disponible en otro lugar en caso de que algo vaya mal con uno u otro componente (por ejemplo, si ambos fallan a la vez).
