Equilibrio de carga de varias regiones con Traffic Manager y Application Gateway

Esta arquitectura de referencia sirve cargas de trabajo web con aplicaciones resistentes de varios niveles y realiza implementaciones en varias regiones de Azure para lograr una alta disponibilidad y una recuperación ante desastres sólida.

Microsoft Azure Traffic Manager equilibra el tráfico entre regiones y hay un equilibrador de carga regional basado en Azure Application Gateway. Esta combinación le ofrece las ventajas del enrutamiento flexible de Traffic Manager, así como varias funcionalidades de Application Gateway, entre las que se incluyen:

• Web Application Firewall (WAF).
• Terminación de Seguridad de la capa de transporte (TLS).
• Enrutamiento basado en rutas de acceso.
• Afinidad de sesión basada en cookies.

En este escenario, la aplicación consta de tres niveles:

• Nivel web: se trata del nivel superior y tiene la interfaz de usuario. Analiza las interacciones del usuario y pasa las acciones al siguiente nivel para su procesamiento.
• Nivel empresarial: procesa las interacciones del usuario y determina los pasos siguientes. Conecta las capas web y de datos.
• Capa de datos: almacena los datos de la aplicación, normalmente en una base de datos, un almacenamiento de objetos o archivos.

Architecture

Traffic Manager funciona en el nivel de DNS para dirigir el tráfico de la aplicación según el método de enrutamiento que elija. Por ejemplo, podría dirigir las solicitudes para que se envíen a los puntos de conexión más cercanos para mejorar la capacidad de respuesta. En cambio, Application Gateway equilibra la carga de las solicitudes HTTP(S) y WebSocket y las enruta a los servidores del grupo de back-end. El back-end pueden ser puntos de conexión públicos o privados, máquinas virtuales, Azure Virtual Machine Scale Sets, App Services o clústeres de AKS. Puede enrutar el tráfico en función de los atributos de una solicitud HTTP, como un nombre de host y una ruta de acceso de URI.

Componentes

• Las máquinas virtuales de Azure Virtual Machines son recursos de computación escalables que ofrecen la flexibilidad de la virtualización sin necesidad de mantener las demandas del hardware físico. Las opciones de sistema operativo incluyen Windows y Linux. Las máquinas virtuales son un recurso a petición y escalable.
• Azure Virtual Machine Scale Sets es un escalado automatizado de máquinas virtuales con equilibrio de carga que simplifica la administración de las aplicaciones y aumenta la disponibilidad.
• Traffic Manager es un equilibrador de carga de tráfico basado en DNS que distribuye el tráfico de forma óptima a servicios de regiones de Azure globales, al tiempo que proporciona una alta disponibilidad y capacidad de respuesta. Para más información, consulte la sección Configuración de Traffic Manager.
• Application Gateway es un equilibrador de carga de nivel 7. En esta arquitectura, una instancia de Application Gateway con redundancia de zona enruta las solicitudes HTTP al front-end web. Application Gateway proporciona también un firewall de aplicaciones web que protege la aplicación contra puntos vulnerables de la seguridad comunes. La versión v2 de la SKU de Application Gateway admite la redundancia entre zonas. Una sola implementación de Application Gateway puede ejecutar varias instancias de la puerta de enlace.
• Azure Load Balancer es un equilibrador de carga de capa 4. Hay dos SKU: estándar y básica. En esta arquitectura, una instancia de Standard Load Balancer con redundancia de zona dirige el tráfico de red del nivel web al nivel empresarial. Como una instancia de Load Balancer con redundancia de zona no está anclada a una zona específica, la aplicación seguirá distribuyendo el tráfico de red en caso de que se produzca un error de zona.
• Azure DDoS Protection tiene características mejoradas para protegerse frente a ataques de denegación de servicio distribuido (DDoS), características que van más allá de la protección básica que proporciona Azure.
• Azure DNS es un servicio de hospedaje para dominios DNS. Proporciona resolución de nombres mediante la infraestructura de Microsoft Azure. Al hospedar dominios en Azure, puede administrar los registros DNS con las mismas credenciales, API, herramientas y facturación que con los demás servicios de Azure. Azure DNS también admite zonas DNS privadas. Azure DNS Private Zones proporcionan la resolución de nombres dentro de una red virtual, así como entre redes virtuales. Los registros contenidos en una zona DNS privada no se pueden resolver desde Internet. La resolución de DNS en una zona DNS privada solo funciona desde redes virtuales vinculadas a ella.
• Azure Virtual Network proporciona una red privada segura en la nube. Conecta máquinas virtuales entre sí, a Internet y a redes locales.
• Azure Bastion proporciona acceso de protocolo de escritorio remoto y Secure Shell seguro y sin interrupción a las máquinas virtuales de la red virtual. Esto proporciona acceso al limitar las direcciones IP públicas expuestas de las máquinas virtuales en la red virtual. Azure Bastion proporciona una alternativa rentable a una máquina virtual aprovisionada para proporcionar acceso a todas las VM de la misma red virtual.

Recomendaciones

Las siguientes recomendaciones sirven para la mayoría de los escenarios. Sígalas a menos que tenga un requisito concreto que las invalide.

• Use al menos dos regiones de Azure para mayor disponibilidad. Puede implementar la aplicación en varias regiones de Azure en configuraciones activas/pasivas o activas/activas. Para más información, consulte Varias regiones.
• En el caso de cargas de trabajo de producción, ejecute al menos dos instancias de puerta de enlace. Tenga en cuenta que, en esta arquitectura, los puntos de conexión públicos de las instancias de Application Gateway están configurados como los back-end de Traffic Manager.
• Use reglas de grupos de seguridad de red (NSG) para restringir el tráfico entre niveles. Para más información, consulte Grupos de seguridad de red.

Consideraciones sobre disponibilidad

Azure Availability Zones

Azure Availability Zones proporciona alta disponibilidad dentro de una región. Una red regional conecta al menos tres centros de datos ubicados estratégicamente distintos físicamente en cada región.

Varias regiones

Una implementación en varias regiones puede proporcionar una mayor disponibilidad que la implementación en una sola región. Si una interrupción regional afecta a la región primaria, puede usar Traffic Manager para conmutar por error en la región secundaria. Varias regiones también pueden ayudar si un determinado subsistema de la aplicación produce un error.

Tenga en cuenta que esta arquitectura es aplicable a las configuraciones activas/pasivas y activas/activas en todas las regiones de Azure.

Para obtener información técnica, consulte Regiones y Availability Zones en Azure.

Regiones emparejadas

Cada región de Azure se empareja con otra región de la misma geografía (por ejemplo, Estados Unidos, Europa o Asia). Este enfoque permite la replicación de recursos, como el almacenamiento de máquinas virtuales, entre regiones. La idea es mantener una región disponible incluso si la otra deja de estarlo debido a un desastre natural, un conflicto civil, una pérdida de energía, una interrupción de la red, entre otros.

Existen otras ventajas del emparejamiento regional, entre las que se incluyen:

• En caso de producirse una interrupción de Azure más amplia, una región tiene prioridad por cada pareja para ayudar a reducir el tiempo de restauración de las aplicaciones.
• Las actualizaciones planeadas de Azure se implementan una a una en regiones emparejadas para minimizar el tiempo de inactividad y el riesgo de interrupción de la aplicación.
• Los datos siguen residiendo en la misma zona geográfica que su pareja (excepto Sur de Brasil) con fines de jurisdicción fiscal y de aplicación de la ley.

Asegúrese de que ambas regiones admitan todos los servicios de Azure que necesita su aplicación (consulte Servicios por región). Para más información sobre los pares regionales, consulte Continuidad empresarial y recuperación ante desastres (BCDR): Regiones emparejadas de Azure.

Configuración de Traffic Manager

Traffic Manager ofrece alta disponibilidad para las aplicaciones más importantes al supervisar los puntos de conexión y proporcionar la conmutación automática por error cuando un punto de conexión deja de funcionar.

Al configurar Traffic Manager, tenga en cuenta lo siguiente:

• Enrutamiento: Azure Traffic Manager admite seis métodos de enrutamiento de tráfico para determinar cómo enrutar el tráfico a los diversos puntos de conexión del servicio. En esta arquitectura se usa el enrutamiento de rendimiento, que enruta el tráfico al punto de conexión que tiene la latencia más baja para el usuario. Traffic Manager se ajusta automáticamente a medida que cambian las latencias del punto de conexión. Además, si necesita un control más pormenorizado para, por ejemplo, elegir una conmutación por error preferente dentro de una región, puede usar Traffic Manager en una configuración anidada.

  Para más información sobre la configuración, consulte Configuración del método de enrutamiento de tráfico de rendimiento.

  Para más información sobre los métodos de enrutamiento, consulte Métodos de enrutamiento de Traffic Manager.

• Sondeo de estado: Traffic Manager usa un sondeo HTTP (o HTTPS) para supervisar la disponibilidad de cada región. El sondeo comprueba si hay una respuesta HTTP 200 para una ruta de acceso de dirección URL especificada. Como procedimiento recomendado, cree un punto de conexión que indique el estado general de la aplicación y úselo para el sondeo de estado. En caso contrario, el sondeo podría informar de un punto de conexión correcto cuando se producen errores en partes críticas de la aplicación. Para más información, consulte Patrón Health Endpoint Monitoring.

  Cuando Traffic Manager conmuta por error, hay un período de tiempo en que los clientes no pueden comunicarse con la aplicación. La duración viene determinada por los siguientes factores:

  • El sondeo de estado debe detectar que la región primaria se ha vuelto inaccesible.
  • Los servidores DNS deben actualizar los registros DNS almacenados en caché con la dirección IP, lo cual depende del período de vida (TTL) de DNS. El TTL predeterminado es de 300 segundos (5 minutos), pero puede configurar este valor al crear el perfil de Traffic Manager.

  Para más información, consulte el artículo acerca de la supervisión de Traffic Manager.

• Vista de tráfico: habilite Vista de tráfico para entender qué regiones tienen una gran cantidad de tráfico pero experimentan latencias más altas. Luego puede usar esta información para planear la expansión de la superficie a nuevas regiones de Azure. De este modo, los usuarios tienen una experiencia de menor latencia. Consulte Vista de tráfico de Traffic Manager para obtener más información.

Application Gateway

• La SKU v1 de Application Gateway admite escenarios de alta disponibilidad cuando se han implementado dos o más instancias. Azure distribuye estas instancias entre dominios de actualización y de errores para asegurarse de que las instancias no produzcan un error todas al mismo tiempo. La SKU v1 admite escalabilidad mediante la incorporación de varias instancias de la misma puerta de enlace para compartir la carga.
• La SKU v2 de Application Gateway garantiza automáticamente que las nuevas instancias se distribuyan entre dominios de error y dominios de actualización. Si elige la redundancia de zona, las instancias más recientes también se distribuyen entre las zonas de disponibilidad para ofrecer resistencia ante errores de zona.

Sondeos de estado

Application Gateway y Load Balancer usan sondeos de mantenimiento para supervisar la disponibilidad de las instancias de máquina virtual.

• Application Gateway siempre usa un sondeo HTTP.
• Load Balancer puede probar HTTP o TCP. Por lo general, si una máquina virtual ejecuta un servidor HTTP, use un sondeo HTTP. De lo contrario, use TCP.

Si un sondeo no puede acceder a una instancia dentro del período de tiempo de expiración, Application Gateway o Load Balancer deja de enviar tráfico a esa máquina virtual. El sondeo continúa realizando comprobaciones y devolverá la máquina virtual al grupo de back-end si la máquina virtual vuelve a estar disponible. Los sondeos HTTP envían una solicitud GET HTTP a una ruta de acceso determinada y escuchan una respuesta HTTP 200. Puede ser la ruta de acceso raíz ("/") o un punto de conexión de supervisión de mantenimiento que implementa lógica personalizada para comprobar el mantenimiento de la aplicación. El punto de conexión debe permitir solicitudes HTTP anónimas.

Para más información sobre los sondeos de estado, consulte:

• Sondeos de estado de Load Balancer
• Información general sobre la supervisión de estado de Application Gateway

Para conocer las consideraciones sobre el diseño de un punto de conexión de sondeo de estado, consulte Patrón Health Endpoint Monitoring.

Consideraciones sobre la manejabilidad

• Grupos de recursos: use grupos de recursos para administrar los recursos de Azure por duración, propietario y otras características.
• Emparejamiento de red virtual: use el emparejamiento de red virtual para conectar sin problemas dos o más redes virtuales en Azure. A efectos de conectividad las redes virtuales aparecen como una sola. El tráfico entre las máquinas virtuales de la red virtual emparejada usa la infraestructura de la red troncal de Microsoft. Asegúrese de que el espacio de direcciones de las redes virtuales no se superpone. En este escenario, las redes virtuales se emparejan a través del emparejamiento de red virtual global para permitir la replicación de datos de la región primaria en la secundaria.
• Red virtual y subredes: las máquinas virtuales de Azure y los recursos específicos de Azure (como Application Gateway y Azure Load Balancer) se implementan en una red virtual que se puede segmentar en subredes. Cree una subred independiente para cada nivel.

Consideraciones sobre la seguridad

• Use DDoS Protection estándar para obtener una mayor protección contra DDoS que la protección básica que proporciona Azure. Para obtener más información, vea Consideraciones sobre la seguridad.
• Use grupos de seguridad de red (NSG) para restringir el tráfico de red en la red virtual. Por ejemplo, en la arquitectura de tres niveles que se muestra aquí, el nivel de base de datos solo acepta el tráfico procedente del nivel empresarial y la subred de Bastion, no el procedente del front-end web.

Grupos de seguridad de red

Solo el nivel empresarial se comunica directamente con el nivel de base de datos. Para aplicar esta regla, el nivel de base de datos debe bloquear todo el tráfico entrante excepto el de la subred del nivel empresarial.

1. Deniegue todo el tráfico entrante de la red virtual. (Use la etiqueta VIRTUAL_NETWORK en la regla).
2. Permita el tráfico entrante de la subred del nivel empresarial.
3. Permita el tráfico entrante de la propia subred del nivel de la base de datos. Esta regla permite la comunicación entre las máquinas virtuales de la base de datos, lo cual es necesario para la replicación y la conmutación por error de esta.

Cree las reglas 2 y 3 con una prioridad más alta que la primera regla para que puedan invalidarla.

Puede usar etiquetas de servicio para definir controles de acceso a la red en grupos de seguridad de red o Azure Firewall. Consulte Configuración de la infraestructura de Azure Application Gateway para más información sobre los requisitos de los grupos de seguridad de red de Application Gateway.

Precios

Puede usar la calculadora de precios de Azure para calcular los costos. Estas son algunas otras consideraciones.

Virtual Machine Scale Sets

Virtual Machine Scale Sets está disponible en todos los tamaños de máquina virtual Windows. Solo se le cobrará por las máquinas virtuales de Azure que implemente y por los recursos de infraestructura subyacente adicionales que haya consumido, como el almacenamiento y las redes. No hay cargos incrementales por el servicio de Virtual Machine Scale Sets.

Para ver las opciones de precios de las VM únicas, consulte Precios de Windows Virtual Machines.

Standard Load Balancer

Los precios de Standard Load Balancer se basan por hora en función del número de reglas de equilibrio de carga de salida configuradas. Las reglas NAT de entrada son gratuitas. Cuando no se configuran reglas, la instancia de Load Balancer de SKU estándar no se cobra por hora. También hay un cargo por la cantidad de datos que Load Balancer procesa.

Para más información, consulte Precios de Equilibrio de carga.

SKU v2 de Application Gateway

Application Gateway debe aprovisionarse con la SKU v2 y puede abarcar varias zonas de disponibilidad. Con la SKU de la versión 2, el modelo de precios está determinado por el consumo y tiene dos componentes: precio fijo por hora y un costo basado en el consumo.

Para más información, consulte Precios de Application Gateway.

Traffic Manager

La facturación de Traffic Manager está basada en el número de consultas de DNS recibidas, con un descuento para los servicios que reciben más de mil millones de consultas mensuales. También se le cobra por cada punto de conexión supervisado. Para obtener información de precios, consulte Precios de Traffic Manager.

Emparejamiento de redes virtuales de Azure

Una implementación de alta disponibilidad que aproveche varias regiones de Azure hará uso del emparejamiento de red virtual. Los cargos por el emparejamiento de red virtual dentro de la misma región no son los mismos que los cargos por el emparejamiento de red virtual global.

Para más información, consulte Precios de Virtual Network.

Pasos siguientes

Para conocer más arquitecturas de referencia que utilicen las mismas tecnologías, consulte:

• Aplicación de n niveles para varias regiones
• IaaS: aplicación web con base de datos relacional