Opciones de equilibrio de carga

Azure Load Balancer
Azure Front Door
Azure Application Gateway
Administrador de tráfico de Azure

El término equilibrio de carga hace referencia a la distribución de cargas de trabajo entre varios recursos de proceso. El equilibrio de carga busca optimizar el uso de recursos, maximizar el rendimiento, minimizar el tiempo de respuesta y evitar la sobrecarga de un solo recurso. También puede mejorar la disponibilidad al compartir una carga de trabajo entre recursos de proceso redundantes.

Azure proporciona varios servicios de equilibrio de carga que puede usar para distribuir sus cargas de trabajo entre varios recursos de equipo. Estos recursos incluyen Azure Application Gateway, Azure Front Door, Azure Load Balancer y Azure Traffic Manager.

En este artículo se describen algunas consideraciones para determinar una solución de equilibrio de carga adecuada para las necesidades de la carga de trabajo.

Categorizaciones del servicio

Los servicios de equilibrio de carga de Azure se pueden clasificar en dos dimensiones: global frente a regional y HTTP(S) frente a no HTTP(S).

Global frente a regional

  • Global: estos servicios de equilibrio de carga distribuyen el tráfico entre back-ends regionales, nubes o servicios híbridos locales. Estos servicios admiten la administración de un único plano de control responsable del enrutamiento global del tráfico del usuario final a un back-end disponible. Suelen reaccionan a los cambios en la confiabilidad o el rendimiento del servicio para maximizar la disponibilidad y el rendimiento. Puede pensar en ellos como sistemas que equilibran la carga entre los stamp, puntos de conexión o unidades de escalado de la aplicación hospedados en diferentes regiones o zonas geográficas.
  • Regional: estos servicios de equilibrio de carga distribuyen el tráfico de las redes virtuales entre las máquinas virtuales (VM) o puntos de conexión de servicio zonales y con redundancia de zona de una región. Puede pensarlos como sistemas que equilibran la carga entre máquinas virtuales, contenedores o clústeres dentro de una región en una red virtual.

HTTP(S) frente a no HTTP(S)

  • HTTP(S): estos servicios de equilibrio de cargas son equilibradores de carga de capa 7 que solo aceptan el tráfico HTTP(S). Están diseñados para las aplicaciones web u otros puntos de conexión HTTP(S). Pueden incluir características, como la descarga de SSL, el firewall de aplicaciones web, el equilibrio de carga basado en rutas de acceso y la afinidad de sesión.
  • No de HTTP(S): estos servicios de equilibrio de carga son equilibradores de carga de nivel 4 que pueden controlar el tráfico que no es HTTP(S), principalmente los servicios TCP o UDP.

En la tabla siguiente se resumen los servicios de equilibrio de carga de Azure.

Servicio Global/regional Tráfico recomendado
Azure Front Door Global HTTP(S)
Administrador de tráfico de Azure Global No HTTP(S)
Azure Application Gateway Regional HTTP(S)
Azure Load Balancer Regional o global No HTTP(S)

Nota:

Azure Traffic Manager y Azure Load Balancer tienen las funcionalidades para distribuir el tráfico HTTP(S), pero no tienen características específicas para enrutar en función de la información de la unidad de datos de protocolo superior a la capa 4. Ambos admiten el tráfico HTTP(S), pero solo en los niveles de funcionalidad de nivel 4.

Servicios de equilibrio de carga de Azure

Estos son los servicios de equilibrio de carga principales actualmente disponibles en Azure:

  • Azure Front Door es una red de entrega de aplicaciones que proporciona equilibrio de carga global y un servicio de aceleración de sitios para las aplicaciones web. Ofrece funcionalidades de capa 7 para la aplicación, como la descarga SSL, el enrutamiento basado en rutas, la conmutación por error rápida y el almacenamiento en caché para mejorar el rendimiento y la alta disponibilidad de las aplicaciones.

  • Traffic Manager es un equilibrador de carga de tráfico basado en DNS que le permite distribuir el tráfico de forma óptima a servicios de regiones de Azure globales, al tiempo que proporciona una alta disponibilidad y capacidad de respuesta. Dado que Traffic Manager es un servicio de equilibrio de carga basado en DNS, solo equilibra la carga en el nivel del dominio. Por ese motivo, no puede conmutar por error tan rápidamente como con Azure Front Door, debido a los desafíos comunes relacionados con el almacenamiento en caché de DNS y a los sistemas que no respetan los TTL de DNS.

  • Application Gateway proporciona un controlador de entrega de aplicaciones como servicio, que proporciona varias funcionalidades de equilibrio de carga de nivel 7 y firewall de aplicaciones web. Úselo para pasar del espacio de red pública a los servidores web hospedados en un espacio de red privado dentro de una región.

  • Load Balancer proporciona un servicio de equilibrio de carga de capa 4 con latencia muy baja y alto rendimiento (entrante y saliente) para todos los protocolos UDP y TCP. Se diseñó para administrar millones de solicitudes por segundo, a la vez que garantiza que la solución tiene una alta disponibilidad. Load Balancer tiene redundancia de zona, lo que asegura una alta disponibilidad en todas las zonas de disponibilidad. Admite una topología de implementación regional y una topología entre regiones.

Nota:

La tecnología de agrupación en clústeres, como Azure Container Apps o Azure Kubernetes Service, contiene construcciones de equilibrio de carga que funcionan principalmente dentro del ámbito de sus propios límites de clúster, enrutando el tráfico a las instancias de aplicación disponibles en función de la preparación y los sondeos de estado. Estas opciones de equilibrio de carga no se tratan en este artículo.

Árbol de decisión para el equilibrio de carga en Azure

Tenga en cuenta factores como estos al seleccionar una solución de equilibrio de carga:

  • Tipo de tráfico: ¿es una aplicación web HTTP(s)? ¿Se trata de una aplicación pública o privada?
  • Global o regional: ¿necesita equilibrar la carga de máquinas virtuales o contenedores dentro de una red virtual, o equilibrar la carga de la unidad de escalado/las implementaciones entre regiones, o ambas cosas?
  • Disponibilidad: ¿Cuál es el contrato de nivel de servicio?
  • Costo: para más información, consulte Precios de Azure. Además del costo del propio servicio, tenga en cuenta el de las operaciones de administración de una solución basada en ese servicio.
  • Características y límites: ¿qué funcionalidades se admiten en cada servicio y cuáles son los límites de servicio de cada servicio?

[SUGERENCIA] Azure Portal ofrece una guía basada en cuestionarios similar al siguiente diagrama de flujo. En Azure Portal, busque "Equilibrio de carga: ayúdeme a elegir". Al responder a las preguntas, puede restringir las opciones de equilibrio de carga.

El diagrama de flujo siguiente le ayudará a elegir una solución de equilibrio de carga para la aplicación. El diagrama de flujo le guía a través de un conjunto de criterios de decisión clave para alcanzar una recomendación.

Tratar este diagrama de flujo como un punto de partida. Cada aplicación tiene requisitos únicos, por lo que debe usar la recomendación como un punto de partida. A continuación, realice una evaluación más detallada.

Cuando la carga de trabajo implica varios servicios que requieren equilibrio de carga, es importante evaluar cada servicio individualmente. En muchos casos, una configuración eficaz usa más de un tipo de solución de equilibrio de carga. Puede incorporar estas soluciones en diferentes lugares de la arquitectura de la carga de trabajo, cada una de las cuales atiende una función o un rol únicos.

Diagrama que muestra un árbol de decisión para el equilibrio de carga en Azure.

Definiciones

  • Aplicación web (HTTP/HTTPS): hace referencia a la necesidad de tener la capacidad de tomar una decisión de enrutamiento para los datos de nivel 7, como la ruta de acceso URL, admitir la inspección de la carga de comunicación (como un cuerpo de solicitud HTTP) o controlar la funcionalidad TLS.

  • Aplicación orientada a Internet: aplicaciones que son de acceso público desde Internet. Como procedimiento recomendado, los propietarios de las aplicaciones deben aplicar directivas de acceso restrictivas o proteger la aplicación mediante la configuración de ofertas como el firewall de aplicaciones web y la protección contra DDoS.

  • Global o implementado en varias regiones: si este equilibrador de carga debe tener un único plano de control de alta disponibilidad responsable de enrutar el tráfico a puntos de conexión públicos en la aplicación distribuida globalmente. Esto puede ser para admitir topologías activas-activas o activas-pasivas entre regiones.

    Nota:

    Es posible usar un servicio regional, como Application Gateway, para equilibrar la carga entre los back-end que abarcan varias regiones y controlar el enrutamiento a través de un único plano de control. Esa arquitectura se hace posible mediante Private Link entre regiones, emparejamiento de red virtual global o incluso direcciones IP públicas de servicios en otras regiones.

    Sin embargo, este escenario no es el punto principal de esta decisión.

    El uso de un recurso regional como enrutador para los back-end distribuidos globalmente introduce un único punto de error regional e incurre en latencia adicional, ya que el tráfico se ve forzado a pasar por una región antes de ir a otra y luego volver.

  • Plataforma como servicio (PaaS): proporciona un entorno de hospedaje administrado, donde puede implementar la aplicación sin necesidad de administrar las máquinas virtuales o los recursos de red. En este caso, PaaS hace referencia a los servicios que proporcionan equilibrio de carga integrado dentro de una región. Para más información, consulte Elección de un servicio de proceso: escalabilidad.

  • Azure Kubernetes Service (AKS): permite implementar y administrar aplicaciones contenedorizadas. AKS proporciona Kubernetes sin servidor, una experiencia integrada de integración continua y entrega continua, así como seguridad y gobernanza de nivel empresarial. Para más información sobre nuestros recursos arquitectónicos de AKS, consulte Diseño de arquitectura de Azure Kubernetes Service.

  • Infraestructura como servicio (IaaS); es una opción de proceso en la que se aprovisionan las máquinas virtuales que se necesitan junto con los componentes de red y almacenamiento asociados. Las aplicaciones IaaS requieren de equilibrio de carga interno dentro de la red virtual mediante Load Balancer.

  • Procesamiento de nivel de aplicación: hace referencia al enrutamiento especial dentro de una red virtual. Por ejemplo, el enrutamiento basado en rutas dentro de la red virtual entre máquinas virtuales o conjuntos de escalado de máquinas virtuales. Para más información, consulte ¿Cuándo se debe implementar una instancia de Application Gateway detrás de Azure Front Door?

  • Aceleración del rendimiento: hace referencia a características que aceleran el acceso web. La aceleración del rendimiento se puede lograr mediante redes de entrega de contenido (CDN) o una entrada optimizada de punto de presencia para la incorporación acelerada de clientes a la red de destino. Azure Front Door admite la aceleración del tráfico Anycast y de CDN. Las ventajas de ambas características se pueden obtener con o sin Application Gateway en la arquitectura.

Consideraciones adicionales

Cada servicio de equilibrio de carga también tiene detalles de compatibilidad o implementación de funcionalidades que también se deben tener en cuenta. Estos son algunos ejemplos que podrían ser relevantes para el escenario de equilibrio de carga.

  • Compatibilidad con sockets web
  • Compatibilidad con HTTP/2 (tanto la recepción como la continuación de los nodos back-end)
  • Compatibilidad con sesiones permanentes
  • Mecanismo de supervisión del estado del nodo de back-end
  • Experiencia del cliente o retraso entre la detección de nodos incorrectos y la eliminación de la lógica de enrutamiento.

Ejemplos

En la tabla siguiente se enumeran varios artículos basados en los servicios de equilibrio de carga que se usan como solución.

Servicios Artículo Descripción
Load Balancer Equilibrio de carga de máquinas virtuales (VM) entre zonas de disponibilidad Equilibrar la carga de VM entre zonas de disponibilidad contribuye a proteger los datos y aplicaciones de la improbable pérdida o error de todo un centro de datos. Con la redundancia de zona, aunque se produzcan errores en una o varias zonas disponibilidad, la ruta de los datos puede mantenerse a salvo siempre que una zona de la región permanezca en buen estado.
Azure Front Door Compartir ubicación en tiempo real mediante servicios de Azure sin servidor económicos Use Azure Front Door para proporcionar a las aplicaciones una disponibilidad mayor que si se implementa en una única región. Si una interrupción regional afecta a la región primaria, puede usar Azure Front Door para realizar una conmutación por error a la región secundaria.
Traffic Manager Aplicación web de varios niveles creada para lograr alta disponibilidad y recuperación ante desastres Implemente aplicaciones resistentes de varios niveles diseñadas para una alta disponibilidad y recuperación ante desastres. Si la región principal no está disponible, Traffic Manager conmuta por error en la región secundaria.
Azure Front Door + Application Gateway SaaS multiinquilino en Azure Use una solución de varios inquilinos que incluya una combinación de Azure Front Door y Application Gateway. Azure Front Door ayuda a equilibrar la carga del tráfico entre regiones. Application Gateway enruta el tráfico internamente en la aplicación a los diversos servicios que satisfacen las necesidades empresariales de los clientes y equilibra la carga.
Traffic Manager + Load Balancer Aplicación de niveles N para varias regiones Una aplicación multirregión de nivel N que usa Traffic Manager para dirigir las solicitudes entrantes a una región primaria. Si dicha región no está disponible, Traffic Manager conmuta por error a la región secundaria.
Traffic Manager y Application Gateway Equilibrio de carga de varias regiones con Traffic Manager y Application Gateway Obtenga información sobre cómo servir cargas de trabajo web e implementar aplicaciones de varios niveles resistentes en varias regiones de Azure, con el fin de lograr una alta disponibilidad y una sólida infraestructura de recuperación ante desastres.

Pasos siguientes