Confiabilidad en Azure Application Gateway v2

Azure Application Gateway es un equilibrador de carga de tráfico web que puede usar para administrar el tráfico a las aplicaciones web. Proporciona funciones avanzadas como el escalado automático, la redundancia de zona, las direcciones IP virtuales estáticas (VIP) y la integración del firewall de aplicaciones web (WAF) para ofrecer servicios de entrega de aplicaciones de alta disponibilidad y seguros.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Application Gateway v2 sea resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, interrupciones de zona de disponibilidad y interrupciones en regiones. También se resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de Application Gateway v2.

Recomendaciones de implementación de producción

Para obtener información sobre cómo implementar Application Gateway para admitir los requisitos de confiabilidad de la solución y cómo afecta la confiabilidad a otros aspectos de la arquitectura, consulte Procedimientos recomendados de arquitectura para Application Gateway en Azure Well-Architected Framework.

Introducción a la arquitectura de confiabilidad

Application Gateway es un servicio administrado. Es importante comprender algunos elementos clave de la arquitectura de servicio para que pueda tomar decisiones de confiabilidad informadas.

• Puerta de Enlace: Al implementar Application Gateway, se implementa una puerta de enlace, que es el recurso de Azure con el que trabaja.

• Instancias: Una instancia es una sola unidad de la puerta de enlace. Una puerta de enlace tiene varias instancias. Cada instancia tiene su propia dirección IP privada, controla el tráfico y enruta las solicitudes.

  Importante

  Para lograr una alta disponibilidad, cada puerta de enlace siempre se crea con un mínimo de dos instancias. Sin embargo, Azure Portal puede indicar que la puerta de enlace tiene una sola instancia, aunque realmente tenga dos.

  La plataforma administra automáticamente la creación de instancias, la supervisión del estado y la sustitución de instancias incorrectas. También administra la eliminación correcta de instancias durante los eventos de escalado horizontal. Este proceso se conoce como drenaje de conexiones.

  En el diagrama siguiente se muestra una puerta de enlace con dos instancias:

  

Para distribuir instancias entre varias zonas de disponibilidad y, por tanto, aumentar la redundancia y la disponibilidad durante los errores del centro de datos, puede habilitar la redundancia de zona.

• Escalado: un aspecto importante de la confiabilidad de una puerta de enlace es cómo se escala para satisfacer la demanda de tráfico. Si una puerta de enlace no se escala correctamente, el tráfico no puede fluir y la aplicación puede experimentar tiempo de inactividad. Puede configurar Application Gateway para que use uno de los siguientes modos de escalado.

  • Escalado automático: ajusta automáticamente el número de instancias dentro de un intervalo que especifique. El escalado automático escala el número de instancias en función de la demanda de tráfico actual.

  • Escalado manual: requiere que especifique un número exacto de instancias. Es responsable de seleccionar un recuento de instancias que cumpla la demanda de tráfico.

  Una unidad de capacidad representa una cantidad de capacidad que la puerta de enlace puede procesar. Una unidad de capacidad es una medida sintética que incorpora el tráfico, el número de conexiones y los recursos de proceso. Cada instancia puede controlar al menos 10 unidades de capacidad. Para más información, vea Escalado de Application Gateway v2 y WAF v2.

• Sondeos de estado: Application Gateway usa sondeos de estado para supervisar continuamente los servidores back-end, como los servidores de aplicaciones individuales. El tráfico se puede redirigir automáticamente a servidores de back-end correctos cuando se detectan servidores incorrectos.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Al usar Application Gateway, tenga en cuenta los procedimientos recomendados siguientes:

• Implementación de la lógica de reintento. Los clientes deben implementar mecanismos de reintento adecuados para errores de conexión transitorios.

• Configure sondeos de estado con tolerancia. Configure los sondeos de estado a fin de permitir un período de gracia para errores transitorios. Los sondeos de estado se pueden configurar con un umbral incorrecto, que especifica el número de intentos de conexión con error consecutivos que deben desencadenar que el servidor de back-end se marque como incorrecto. El valor predeterminado de tres garantiza que los errores transitorios de los servidores back-end no desencadenen Application Gateway para marcar innecesariamente el servidor como incorrecto.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Application Gateway proporciona dos tipos de compatibilidad con zonas de disponibilidad al implementar una puerta de enlace de Standard_v2 o WAF_v2 en una región admitida.

• Con redundancia de zona: Azure distribuye automáticamente las instancias en dos o más zonas de disponibilidad.

  Al implementar un nuevo gateway, es redundante en zona por defecto.

  En el diagrama siguiente se muestra una puerta de enlace con redundancia de zona con tres instancias distribuidas entre tres zonas de disponibilidad:

  

• Zonal: Azure implementa todas las instancias de Application Gateway en una sola zona que seleccione en la región de Azure elegida.

  En el diagrama siguiente se muestra una puerta de enlace zonal con tres instancias que se implementan en la misma zona de disponibilidad:

  

  Importante

  La asignación a una sola zona de disponibilidad solo se recomienda cuando la latencia entre zonas es demasiado alta para sus necesidades y cuando se comprueba que la latencia no cumple sus requisitos. Por sí sola, una puerta de enlace zonal no proporciona resiliencia ante una interrupción del servicio en una zona de disponibilidad. Para mejorar la resistencia de una implementación de Application Gateway zonal, debe implementar explícitamente puertas de enlace independientes en varias zonas de disponibilidad y configurar el enrutamiento de tráfico y la conmutación por error.

Requisitos

• Compatibilidad con regiones: Application Gateway admite zonas de disponibilidad para los niveles de Standard_v2 y WAF_v2 en todas las regiones de Azure que admiten zonas de disponibilidad.

• SKU: Debe usar la Standard_v2 o WAF_v2 SKU para habilitar la compatibilidad con zonas de disponibilidad.

• Recuento de instancias: La puerta de enlace debe tener al menos dos instancias.

  Nota:

  Todas las puertas de enlace tienen un mínimo de dos instancias para garantizar alta disponibilidad. Incluso si Azure Portal indica que la puerta de enlace tiene una sola instancia, internamente siempre se crea con un mínimo de dos instancias.

Consideraciones

Las puertas de enlace con redundancia de zona se distribuyen entre dos o más zonas de disponibilidad en la región. Por ejemplo, en una región que tiene tres zonas de disponibilidad, una implementación de Application Gateway v2 con redundancia de zona tiene instancias en al menos dos de esas zonas. En función de la capacidad regional y las decisiones de plataforma, las instancias se pueden distribuir entre dos zonas o tres zonas.

Costos

La compatibilidad con la zona de disponibilidad para Application Gateway v2 no incurre en cargos adicionales más allá de los precios de la unidad de capacidad estándar. Para obtener más información sobre los precios, consulte Descripción de los precios de Application Gateway y WAF y Application Gateway.

Configurar soporte de zonas de disponibilidad

En esta sección se explica cómo configurar la compatibilidad con zonas de disponibilidad para las puertas de enlace.

• Cree una nueva puerta de enlace con compatibilidad con la zona de disponibilidad. El enfoque que se usa para configurar zonas de disponibilidad depende de si desea crear una puerta de enlace con redundancia de zona o zonal.

  • Con redundancia de zona: las puertas de enlace se crean como con redundancia de zona de manera predeterminada. Las instancias se distribuyen entre varias zonas de disponibilidad y pueden usar dos o más zonas en la región.

    Para implementar una nueva puerta de enlace, consulte Inicio rápido: tráfico web directo mediante Application Gateway: Azure Portal.

    Si usa la CLI de Azure, Azure PowerShell, Bicep, plantillas de Azure Resource Manager (plantillas de ARM) o Terraform, puede especificar opcionalmente las zonas de disponibilidad en las que implementar la puerta de enlace. Puede implementar una puerta de enlace con redundancia de zona si especifica dos o más zonas. Sin embargo, se recomienda omitir la lista de zonas para que la puerta de enlace pueda usar todas las zonas de disponibilidad, a menos que tenga una razón específica para no usar una zona específica.

  • Zonal: Puede implementar una puerta de enlace zonal mediante las siguientes herramientas.

    • CLI de Azure: debe seleccionar explícitamente zonas mediante el parámetro --zones en el comando az network application-gateway create. Para anclar la puerta de enlace a una sola zona, especifique el número de zona lógica.

    • Azure PowerShell: use el parámetro -Zone en el comando New-AzApplicationGateway. Para anclar la puerta de enlace a una sola zona, especifique el número de zona lógica.

    • Plantillas de Bicep y ARM: Configure la zones propiedad en la definición de recursos. Para anclar la puerta de enlace a una sola zona, especifique el número de zona lógica.

    Nota:

    Cuando selecciona qué zonas de disponibilidad usar, en realidad está seleccionando la zona de disponibilidad lógica. Si implementa otros componentes de la carga de trabajo en una suscripción de Azure diferente, podrían usar un número de zona de disponibilidad lógica distinto para acceder a la misma zona de disponibilidad física. Para obtener más información, consulte zonas de disponibilidad física y lógica.

• Cambie la configuración de zona de disponibilidad de una instancia de Application Gateway v2 existente. Todas las puertas de enlace tienen redundancia de zona a menos que se configuren para que sean zonales.

  Si necesita pasar de una puerta de enlace con redundancia de zona a una configuración zonal, debe implementar una nueva puerta de enlace.

• Deshabilite la compatibilidad con la zona de disponibilidad. No se puede deshabilitar la compatibilidad con la zona de disponibilidad. Todas las puertas de enlace de regiones que admiten zonas de disponibilidad deben ser con redundancia de zona o zonales.

Planeamiento y administración de capacidad

Cuando planifique fallos de zona para una puerta de enlace de aplicaciones redundante por zonas o varias puertas de enlace zonales implementadas en varias zonas, tenga en cuenta que las instancias de las zonas supervivientes pueden experimentar un aumento de la carga a medida que se redistribuye el tráfico. Las conexiones pueden experimentar interrupciones breves que pueden durar unos segundos.

Para administrar la capacidad de forma eficaz, realice las siguientes acciones:

• Use el escalado automático. Configure el escalado automático con los recuentos máximos de instancias adecuados para controlar la posible redistribución del tráfico durante las interrupciones de zona.

  Si usa el escalado manual, a fin de prepararse para el error de zona de disponibilidad, considere la posibilidad de sobreaprovisionar el número de instancias de la puerta de enlace. El aprovisionamiento excesivo permite a la solución tolerar cierto grado de pérdida de capacidad, al tiempo que sigue funcionando sin un rendimiento degradado. Para más información, consulte Administración de la capacidad con sobreaprovisionamiento.

• Responder a los cambios en los patrones de tráfico. Supervise las métricas de capacidad y ajuste los parámetros de escalado en función de los patrones de tráfico y los requisitos de rendimiento.

Comportamiento cuando todas las zonas están en buen estado

En la siguiente sección se describe qué se puede esperar cuando Application Gateway v2 se configura con compatibilidad con zonas de disponibilidad y todas las zonas de disponibilidad están operativas.

• Enrutamiento de tráfico entre zonas: Application Gateway distribuye automáticamente las solicitudes entrantes entre instancias de todas las zonas que usa la puerta de enlace. Esta configuración activa-activa garantiza un rendimiento y una distribución de carga óptimos en condiciones de funcionamiento normales.

• Administración de instancias: la plataforma administra automáticamente la colocación de instancias en las zonas que usa la puerta de enlace. Reemplaza las instancias con errores y mantiene el recuento de instancias configurados. El seguimiento de estado garantiza que solo las instancias correctas reciban tráfico.

Comportamiento durante un fallo de zona

En la siguiente sección se describe qué ocurre cuando Application Gateway v2 se configura con compatibilidad con zonas de disponibilidad y una o varias zonas de disponibilidad no están disponibles.

• Detección y respuesta: la responsabilidad de la detección y la respuesta depende de la configuración de zona de disponibilidad que usa la puerta de enlace.

  • Con redundancia de zona: Microsoft administra la detección de errores de zona e inicia automáticamente la conmutación por error. No se requiere ninguna acción del cliente.

  • Zonal: debe detectar la pérdida de una zona de disponibilidad e iniciar una conmutación por error a una puerta de enlace secundaria que cree en otra zona de disponibilidad.

• • Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas. También puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: durante una interrupción de zona, se finalizan las solicitudes que procesan las instancias de esa zona. Los clientes deben reintentar las solicitudes siguiendo las instrucciones para controlar errores transitorios.

• Pérdida de datos esperada: no se espera que los errores de zona causen pérdida de datos porque Application Gateway es un servicio sin estado.

• Tiempo de inactividad esperado: El tiempo de inactividad que puede esperar depende de la configuración de zona de disponibilidad que usa la puerta de enlace.

  • Con redundancia de zona: Durante las interrupciones de zona, las conexiones pueden experimentar interrupciones breves que suelen durar unos segundos a medida que se redistribuye el tráfico.

  • Zonal: cuando una zona no está disponible, la puerta de enlace no está disponible hasta que se recupere la zona de disponibilidad.

• Administración de instancias: el comportamiento de administración de instancias depende de la configuración de zona de disponibilidad que usa la puerta de enlace.

  • Con redundancia de zona: la plataforma intenta mantener la capacidad de la puerta de enlace mediante la creación de instancias temporales en otras zonas de disponibilidad.

    Internamente, Application Gateway usa conjuntos de escalado de máquinas virtuales, que realizan el equilibrio de zona más indicado. Debido a este comportamiento, es posible que las operaciones de escalado no se produzcan cuando la capacidad no se pueda dividir uniformemente entre zonas (+/- 1 instancia).

  • Zonal: es responsable de crear instancias en zonas correctas si las necesita.

• Re enrutamiento del tráfico: El comportamiento se re direcciona del tráfico depende de la configuración de zona de disponibilidad que usa la puerta de enlace.

  • Con redundancia de zona: Application Gateway redistribuye inmediatamente el tráfico a las instancias de zonas correctas, incluidas las que se crean temporalmente.

  • Zonal: cuando una zona no está disponible, la puerta de enlace no está disponible. Si tiene una puerta de enlace secundaria en otra zona de disponibilidad, es responsable de redirigir el tráfico a esa puerta de enlace secundaria.

Recuperación de zona

El comportamiento de recuperación de zona depende de la configuración de zona de disponibilidad que usa la puerta de enlace:

• Con redundancia de zona: Cuando se recupera la zona de disponibilidad afectada, Application Gateway realiza automáticamente las siguientes acciones:

  • Restaura instancias en la zona recuperada

  • Quita las instancias temporales que se hayan creado en otras zonas durante la interrupción

  • Vuelve a la distribución normal del tráfico en todas las zonas disponibles

• Zonal: es responsable de redirigir el tráfico a la puerta de enlace en la zona de disponibilidad original después de que se recupere la zona de disponibilidad.

Prueba de fallos de zona

Las opciones para probar errores de zona dependen de la configuración de zona de disponibilidad que usa la puerta de enlace.

• Con redundancia de zona: La plataforma Application Gateway administra completamente el enrutamiento del tráfico, la conmutación por error y la conmutación por recuperación para las puertas de enlace con redundancia de zona. Como Microsoft administra esta característica, no es necesario iniciar ni validar los procesos de error de zona de disponibilidad. La plataforma controla todos los escenarios de error de zona de forma transparente.

• Zonal: puede simular algunos aspectos del error de una zona de disponibilidad si detiene explícitamente una puerta de enlace. Al detener la puerta de enlace, puede probar cómo otros sistemas y equilibradores de carga controlan una interrupción en la puerta de enlace. Para más información, consulte Cómo detener e iniciar Application Gateway.

Resistencia a errores en toda la región

Application Gateway v2 es un servicio de una sola región. Si la región deja de estar disponible, la puerta de enlace tampoco está disponible.

Soluciones personalizadas de varias regiones para la resistencia

Para lograr la resistencia de varias regiones mediante Application Gateway v2, debe implementar puertas de enlace independientes en cada región deseada e implementar la administración del tráfico entre regiones. Es responsable de implementar y configurar cada una de las puertas de enlace, así como el enrutamiento del tráfico y la conmutación por error. Considere los siguientes puntos:

• Configure reglas y directivas coherentes de Application Gateway entre regiones. Puede definir la infraestructura como código (IaC) mediante herramientas como Bicep o Terraform para simplificar las implementaciones y configuraciones entre regiones.

• Implemente una solución de equilibrio de carga global que pueda enviar tráfico entre las puertas de enlace regionales. Los servicios globales de equilibrio de carga en Azure son Azure Traffic Manager y Azure Front Door. Cada servicio enruta el tráfico en función de las comprobaciones de estado, la proximidad geográfica o las métricas de rendimiento. Azure Front Door también proporciona una variedad de otras funcionalidades, incluida la protección contra ataques por denegación de servicio distribuido (DDoS), las funcionalidades de WAF y las reglas avanzadas y las características de enrutamiento.

• Más allá de la puerta de enlace, considere la posibilidad de replicar aplicaciones de back-end y datos entre regiones. Consulte las guías de confiabilidad de cada servicio de Azure para comprender los enfoques de implementación de varias regiones.

Para obtener un enfoque de ejemplo, consulte Uso de Application Gateway con Traffic Manager.

Copias de seguridad y restauración

Application Gateway v2 es un servicio sin estado que no requiere operaciones tradicionales de copia de seguridad y restauración. Todos los datos de configuración se almacenan en Resource Manager y se pueden volver a implementar mediante enfoques IaC, como archivos de Bicep o plantillas de ARM.

Para la administración de la configuración y la recuperación ante desastres, debe realizar las siguientes acciones:

• Defina la configuración de la implementación de Application Gateway mediante archivos de Bicep o plantillas de ARM, o bien exporte la configuración de una puerta de enlace existente.

• Almacene certificados de seguridad de la capa de transporte (TLS) en Azure Key Vault para la administración y replicación seguras.

• Directivas, reglas y configuraciones personalizadas de control de versiones y documentos.

• Implemente canalizaciones de implementación automatizadas para el aprovisionamiento coherente de la puerta de enlace.

Para la mayoría de las soluciones, no debe confiar exclusivamente en copias de seguridad. En su lugar, utilice las otras capacidades descritas en esta guía para apoyar los requisitos de resiliencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no. Para más información, consulte ¿Qué son la redundancia, la replicación y la copia de seguridad?.

Resistencia al mantenimiento del servicio

Application Gateway v2 realiza actualizaciones de servicio periódicas y otras tareas de mantenimiento. Para mantener la capacidad esperada durante una actualización, la plataforma agrega automáticamente instancias adicionales de la puerta de enlace durante el proceso de actualización. Sin embargo, debe asegurarse de que la subred de la puerta de enlace tenga suficiente espacio de direcciones IP libre para que se creen las instancias temporales. Para obtener más información, consulte ¿Cómo controla Application Gateway el mantenimiento rutinario?.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Para que una puerta de enlace sea apta para el Acuerdo de Nivel de Servicio de disponibilidad de Application Gateway, debe cumplir los criterios siguientes:

• Debe configurarse correctamente para realizar el equilibrio de carga HTTP.
• Debe tener redundancia de zona o debe configurarse para usar la escalabilidad automática.

Contenido relacionado

• Introducción a la confiabilidad de Azure