Compartir a través de


Soluciones de equilibrio de carga de Azure: Una guía para ayudarlo a elegir la opción correcta(es-MX)

Artículo Original: https://blogs.msdn.microsoft.com/premier_developer/2018/04/25/azure-load-balancing-solutions-a-guide-to-help-you-choose-the-correct-option/

 En esta publicación, el Gerente de desarrollo de aplicaciones Sr. Fidelis Ekezue explica las opciones de Equilibrio de carga de Azure y resalta las consideraciones para elegir una solución.

Soluciones Azure Load Balancing: ¿cuándo elegir cuál?

Microsoft Azure proporciona a los clientes varias formas de equilibrar la carga de las solicitudes de tráfico a sus entornos. Los clientes tienen las opciones para elegir Traffic Manager, Azure Load Balancer, Azure Application Gateway o la combinación de los tres en sus soluciones de Azure. Con la tasa de tráfico web aumentando a un ritmo más rápido, ninguna solución distribuida está completa sin el uso de un equilibrador de carga para dirigir el tráfico y distribuir cargas de trabajo para garantizar la disponibilidad, una mejor escala y en ocasiones cumplir con los requisitos de gobierno. Este blog proporciona un resumen conciso de las diferentes soluciones de equilibrio de carga disponibles en Microsoft Azure Cloud. El objetivo es ayudar a los clientes a tomar decisiones sobre qué solución de equilibrio de carga usar con sus aplicaciones. Aunque cada una de estas opciones de equilibrio de carga se puede usar de forma independiente, existen escenarios en los que se necesita una combinación de dos o más para cumplir con los requisitos comerciales y normativos.

Azure Load Balancer

Azure Load Balancer es la solución de equilibrio de carga de primera generación para Microsoft Azure y opera en la capa 4 (Capa de transporte) de la pila de red OSI, y admite protocolos TCP y UDP. Azure Load Balancer viene en dos SKU, a saber, Básico y Estándar. El equilibrador de carga estándar es un nuevo producto de Load Balancer con más características y capacidades que Basic Load Balancer, y se puede usar como balanceador de carga público o interno. Una diferencia importante entre Basic y el Load Balancer estándar es el alcance. Mientras Basic Load Balancer se establece en un conjunto de disponibilidad, el Standard Load Balancer tiene un alcance para toda la red virtual. Mientras que el Basic admite hasta 100 instancias, el estándar admite hasta 1000 instancias. Consulte los artículos vinculados para obtener una comparación más detallada entre Basic Load Balancer y Standard Load Balancer.

Al momento de escribir este artículo, el SKU estándar está en Vista previa, por lo que el enfoque de este blog está en el SKU básico. El tráfico se distribuye a instancias saludables (máquinas virtuales) utilizando el modo de distribución basado en hash. El algoritmo Hashing utiliza un 5-tuple (IP de origen, puerto de origen, IP de destino, puerto de destino, tipo de protocolo) para que el tráfico de la misma IP de origen se reenvíe a la misma instancia, por lo que se garantiza la adherencia dentro de la sesión de transporte. Cuando una aplicación requiere conexión del mismo cliente para ir a la misma IP de destino independientemente del número de puerto, Azure Load Balancer utiliza un algoritmo de distribución diferente basado en hash 2-tupla (IP de origen e IP de destino) o hash 3-tupla (Fuente IP, IP de destino y protocolo). Esto se conoce como Afinidad de IP de origen o Afinidad de sesión. Algunos de los escenarios de uso incluyen:

  • Las aplicaciones que necesitan cargar solicitudes de saldo a los recursos internos en la red privada.
  • Aplicaciones que requieren afinidad de IP de origen o afinidad de sesión.

Azure Application Gateway

Azure Application Gateway es un servicio altamente escalable y de alta disponibilidad de Azure que ofrece capacidades de equilibrio de carga de capa 7 (Aplicación) para distribuir solicitudes de clientes a backends de Azure. Algunas de las características clave de Application Gateway son la capacidad de descargar TLS (también conocido como SSL) y, por lo tanto, mejorar el rendimiento de las aplicaciones web, el Web Application Firewall para proporcionar seguridad adicional a la aplicación y el alojamiento de múltiples sitios. Visite el siguiente enlace para obtener una lista completa de las características de Application Gateway. Algunos de los escenarios de uso para Azure Application Gateway incluyen:

  • Las aplicaciones que requieren el uso de diferentes criterios como la ruta URL o el encabezado del dominio. Application Gateway puede configurarse para reenviar solicitudes a diferentes carpetas en el servidor web, por ejemplo, imágenes reenviadas a un grupo de back-end diferente y videos a otro.
  • Las aplicaciones que requieren un uso extensivo de TLS (SSL) para cifrar y descifrar el tráfico pueden tener un impacto negativo en el rendimiento del servidor web. Application Gateway ofrece un medio para descargar estas tareas de cifrado / descifrado al finalizar la conexión TLS en la puerta de enlace. Antes de 2017, se recomendaba TLS Offload, sin embargo, Microsoft modificó sus requisitos de controles de seguridad internos para el uso de TLS para todas las conexiones, desde recomendado hasta obligatorio. Por lo tanto, la descarga de TLS no es la mejor práctica recomendada y debe evitarse.
  • Las aplicaciones web que requieren la protección de los exploits y vulnerabilidades comunes, como los ataques de inyección SQL, los ataques de cross site scripting (XSS) y los ataques de falsificación de solicitudes entre sitios (XSRF). Azure Application Manager proporciona estas protecciones a través del Web Application Firewall (WAF) que se basa en las reglas de los conjuntos de reglas centrales de OWASP.
  • Las aplicaciones web que requieren monitoreo de ataques en tiempo real también pueden usar esta función WAF de Application Gateway. Se puede integrar con el Centro de seguridad de Azure para permitir que el personal de seguridad tenga una vista completa de la seguridad de sus recursos de Azure.
  • Para las aplicaciones que abarcan tanto la nube de Azure como los recursos en las instalaciones, Application Gateway no se aplica solo a los recursos de la nube de Azure, sino que se puede usar para aplicaciones que se ejecutan en las instalaciones.
  • Las aplicaciones que requieren cierta afinidad pueden aprovechar Application Gateway debido a su compatibilidad con la afinidad basada en cookies.

Azure Traffic Manager

A diferencia de Application Gateway y Azure Load Balancer que enruta el tráfico mediante el protocolo TCP/IP, Traffic Manager utiliza DNS para dirigir el tráfico al grupo de back-end apropiado. El grupo de back-end admite cualquier DNS CNAME público, por lo tanto, es adecuado para escenarios en los que las solicitudes se dirigen tanto a la aplicación local como a la aplicación en la nube. Debido a que Azure Traffic Manager opera en el nivel de DNS, no existe el concepto de "Dirección IP" para Traffic Manager, por decir palabra, el Traffic Manager no tiene conocimiento de la dirección IP del endpoint porque funciona con registros DNS CNAME. El registro CNAME no se correlaciona con las direcciones IP, sino que asigna un nombre DNS a otro. Una mejor descripción de Jonathan Tuliani es la publicación del foro que describió Traffic Manager de la siguiente manera:

"Traffic Manager proporciona enrutamiento de tráfico de nivel DNS. Funciona usando registros 'CNAME'. Un registro 'CNAME' es como un 'alias', asigna un nombre DNS a otro. No correlaciona nombres con direcciones IP (esto se hace mediante registros DNS 'A'). Por lo tanto, cuando se utiliza Traffic Manager con los servicios de Azure, la ruta de resolución del nombre se configura normalmente de esta manera:

  1. Su nombre de dominio de servicio en su dominio de vanidad, p. www.contoso.com, CNAME para:
  2. El nombre de dominio de Traffic Manager, p. contoso.trafficmanager.net, CNAME a
  3. El registro 'A' para cada punto final del servicio, p. contoso-eu.cloudapp.net y contoso-us.cloudapp.net, que son registros A que apuntan a sus respectivas direcciones IP del servicio

Traffic Manager no consume directamente la dirección IP (estática o no). Solo está configurado con el nombre DNS del registro A que apunta a la dirección IP del servicio. Desde el punto de vista del Administrador de tráfico, no importa si la dirección IP detrás de ese registro A es estática o no ".

A diferencia de Azure Load Balancer y Application Gateway que operan en la capa 4 y en la capa 7, respectivamente, de la pila de red OSI, Azure Traffic Manager utiliza la resolución de DNS para determinar cómo distribuir las solicitudes. Por lo tanto, los cambios en los registros DNS pueden verse afectados por la rapidez con que se actualicen los registros DNS almacenados en caché. Este tiempo está determinado por el valor TTL de DNS (Time-To-Live). Los escenarios típicos de clientes donde se usa Azure Traffic Manager incluyen:

  • Aplicaciones que requieren distribuciones de tráfico en las regiones Azure.
  • Aplicaciones que requieren que los usuarios de una región geográfica específica sean atendidos por una aplicación diferente para cumplir con los requisitos normativos o de soberanía.

El siguiente es un resumen conciso de las características y capacidades de las tres soluciones de equilibrio de carga descritas anteriormente.

Service

Azure Load Balancer

Application Gateway

Traffic Manager

Technology

Transport level (Layer 4), per flow

Application level (Layer 7), per HTTP/HTTPS request

DNS resolver

Protocol support

Any TCP & UDP protocol

HTTP, HTTPS, HTTP/2 & WebSockets

DNS resolution

Backend pool

  • Azure virtual machines (IaaS VMs and Cloud Services instances)
  • Can be used for both public and internal (VNet) endpoints. Can support both endpoints at the same time.
  • Any IP address (public and internal, including Azure VM, VMSS, Azure Web Apps, or Azure Cloud Service)
  • Can be used for both Internet facing and internal (VNet) applications. Can support both endpoints at the same time.
  • Any public DNS CNAME (including Azure VMs, Cloud Services, Azure Web Apps, and public endpoints)

Health Monitoring

  • TCP probe
  • HTTP probe
  • HTTP probe
  • HTTPS probe
  • HTTP probe
  • HTTPS probe
  • TCP probe

Outbound connections

Supported

Not supported

Not supported

Availability Zones

  • Zonal and zone-redundant single IP address for public and internal frontends
  • inbound and outbound connections
  • cross-zone load balancing
  • Cross-zone load balancing
  • Single DNS record for multiple public endpoints
  • Cross-zone load balancing

HTTP/HTTP protocol support

  • Pass through, per flow
  • Per HTTP request
  • TLS Offloading & TLS Policy
  • URL/Host:-based routing
  • TLS Re-encryption
  • Web Application Firewall
  • HTTP Redirection Support
  • Protocol agnostic

Source IP/Sticky session

Supported, 2- or 3-tuple source affinity

Supported, cookie-based affinity

Not Supported

Traffic controls

Network Security Groups

Network Security Groups

Geo-traffic Restriction

El Soporte Premier para Desarrolladores proporciona orientación tecnológica estratégica, cobertura de soporte crítico y una gama de servicios esenciales para ayudar a los equipos a optimizar los ciclos de vida de desarrollo y mejorar la calidad del software. Póngase en contacto con su Administrador de desarrollo de aplicaciones (ADM) o envíenos un correo electrónico para obtener más información sobre lo que podemos hacer por usted.