Equilibrio de carga multiregión

Esta arquitectura es para aplicaciones globales y accesibles desde Internet que usan protocolos HTTP(S) y no HTTP(S). Cuenta con equilibrio de carga global basado en el sistema de nombres de dominio (DNS), dos formas de equilibrio de carga regional y emparejamiento de red virtual global para crear una arquitectura confiable. Las zonas de disponibilidad proporcionan resistencia dentro de cada región y la implementación de varias regiones proporciona capacidad de recuperación a partir de una interrupción regional. Azure Web Application Firewall y Azure Firewall inspeccionan el tráfico en varias capas.

Architecture

En esta sección se describen los flujos de tráfico a través de la arquitectura de HTTP(S), las solicitudes entrantes que no son HTTP(S) y salientes. Cada flujo muestra cómo la arquitectura enruta, inspecciona y distribuye el tráfico entre los niveles de aplicación en ambas regiones.

Flujos de tráfico HTTP(S) entrantes

El tráfico HTTP(S) pasa a través del firewall de aplicaciones web (WAF) de Azure Application Gateway y la inspección de seguridad de la capa de transporte Premium (TLS) de Azure Firewall antes de alcanzar los niveles de aplicación.

Descargue un archivo de Visio de esta arquitectura.

1. Azure Traffic Manager usa el enrutamiento basado en DNS para equilibrar la carga del tráfico entrante entre las dos regiones. Traffic Manager resuelve las consultas DNS de la aplicación en las direcciones IP públicas de los puntos de conexión de Application Gateway. Los puntos de conexión públicos de las instancias de Application Gateway actúan como puntos de conexión de back-end de Traffic Manager para el tráfico HTTP(S). Traffic Manager resuelve consultas DNS basadas en el método de enrutamiento elegido. El explorador u otro cliente HTTP se conecta directamente al punto de conexión. Para obtener más información, consulte Método de enrutamiento de tráfico prioritario.

2. Las instancias de Application Gateway implementadas entre zonas de disponibilidad reciben tráfico HTTP(S) desde el explorador y waf inspecciona ese tráfico para detectar ataques web. Las instancias de Application Gateway reenvía el tráfico al equilibrador de carga interno, que lo distribuye a las máquinas virtuales (VM) front-end. En este flujo, Application Gateway funciona como equilibrador de carga, por lo que no es necesario un equilibrador de carga interno adicional delante de los servidores web. Pero el equilibrador de carga interno se incluye en el diseño para mantener la coherencia con el flujo de aplicaciones que no son HTTP(S).

3. Las rutas definidas por el usuario (UDR) en la subred de Application Gateway redirigen el tráfico entre Application Gateway y el equilibrador de carga interno front-end a través de Azure Firewall Premium. Azure Firewall Premium tiene redundancia de zona y aplica la inspección TLS al tráfico para mayor seguridad. Si Azure Firewall detecta una amenaza, quita los paquetes. Si Azure Firewall no detecta una amenaza, reenvía el tráfico al equilibrador de carga interno del nivel web de destino.

4. El nivel web es la primera capa de la aplicación de tres niveles. Contiene la interfaz de usuario (UI) y analiza las interacciones del usuario. El equilibrador de carga de nivel web abarca las tres zonas de disponibilidad y distribuye el tráfico entre las tres máquinas virtuales de nivel web.

5. Las máquinas virtuales de nivel web abarcan las tres zonas de disponibilidad y se comunican con el nivel de negocio a través de un equilibrador de carga interno dedicado.

6. El nivel de negocio procesa las interacciones del usuario y determina los pasos siguientes. Se encuentra entre la capa web y la capa de datos. El equilibrador de carga interno del nivel de negocio distribuye el tráfico a las máquinas virtuales de nivel empresarial en las tres zonas de disponibilidad. El equilibrador de carga del nivel de negocio tiene redundancia de zona, al igual que el equilibrador de carga del nivel web.

7. Las máquinas virtuales de nivel empresarial abarcan zonas de disponibilidad y enrutan el tráfico al agente de escucha del grupo de disponibilidad de las bases de datos.

8. El nivel de datos almacena los datos de la aplicación, normalmente en una base de datos, almacenamiento de objetos o recurso compartido de archivos. Esta arquitectura tiene SQL Server en Azure Virtual Machines distribuido entre tres zonas de disponibilidad. Usan un grupo de disponibilidad Always On con cada máquina virtual de SQL Server en una subred separada. Una implementación de varias subredes permite al agente de escucha del grupo de disponibilidad enrutar el tráfico directamente a las réplicas y no requiere un equilibrador de carga de Azure ni un nombre de red distribuido (DNN).

Flujos de tráfico no HTTP(S) entrantes

Algunas cargas de trabajo aceptan tráfico a través de protocolos distintos de HTTP(S), como el Protocolo de transferencia de archivos seguro (SFTP) para la ingesta de datos basada en archivos de asociados comerciales o integraciones heredadas basadas en el Protocolo de control de transmisión (TCP). El tráfico que no es HTTP(S) se enruta directamente a Azure Firewall para la traducción de direcciones de red de destino (DNAT) e inspección, que omite Application Gateway.

Descargue un archivo de Visio de esta arquitectura.

1. Traffic Manager usa el enrutamiento basado en DNS para equilibrar la carga del tráfico entrante entre las dos regiones. Traffic Manager resuelve consultas de DNS para la aplicación en las direcciones IP públicas de los puntos de conexión de Azure. Los puntos de conexión públicos de Azure Firewall funcionan como puntos de conexión back-end de Traffic Manager para el tráfico que no es HTTP(S). Traffic Manager resuelve consultas DNS basadas en el método de enrutamiento elegido. El cliente se conecta directamente al punto de conexión resuelto. Para obtener más información, consulte Método de enrutamiento de tráfico prioritario.

2. Azure Firewall Premium es con redundancia de zona e inspecciona el tráfico entrante para la seguridad. Si Azure Firewall detecta una amenaza, quita los paquetes. Después de una inspección correcta, Azure Firewall aplica DNAT a los paquetes entrantes y reenvía el tráfico al equilibrador de carga interno del nivel web.

3. El nivel web es la primera capa de la aplicación de tres niveles. Contiene la interfaz de usuario y analiza las interacciones del usuario. El equilibrador de carga de nivel web abarca las tres zonas de disponibilidad y distribuye el tráfico a cada una de las tres máquinas virtuales de nivel web.

4. Las máquinas virtuales de nivel web abarcan las tres zonas de disponibilidad y se comunican con el nivel de negocio a través de un equilibrador de carga interno dedicado.

5. El nivel de negocio procesa las interacciones del usuario y determina los pasos siguientes. Se encuentra entre las capas web y las capas de datos. El equilibrador de carga interno del nivel de negocio distribuye el tráfico a las máquinas virtuales de nivel empresarial en las tres zonas de disponibilidad. El equilibrador de carga de la capa empresarial es redundante en zonas, como el del nivel web.

6. Las máquinas virtuales de nivel de negocio abarcan zonas de disponibilidad y enrutan el tráfico al listener del grupo de disponibilidad de las bases de datos.

7. El nivel de datos almacena los datos de la aplicación, normalmente en una base de datos, almacenamiento de objetos o recurso compartido de archivos. Esta arquitectura tiene SQL Server en máquinas virtuales distribuidas entre tres zonas de disponibilidad. Usan un grupo de disponibilidad Always On con cada máquina virtual de SQL Server en una subred independiente. Una implementación de varias subredes permite que el agente de escucha del grupo de disponibilidad enrute el tráfico directamente a las réplicas y elimine la necesidad de un balanceador de carga o DNN de Azure.

Flujos de tráfico saliente (todos los protocolos)

Los flujos de tráfico saliente para las actualizaciones de parches de las máquinas virtuales u otro tráfico con destino a Internet van desde las máquinas virtuales a Azure Firewall a través de UDRs. Azure Firewall aplica reglas de conectividad mediante categorías web y reglas de red y de aplicación para evitar que las cargas de trabajo accedan a contenido no permitido o filtrando datos.

Componentes

• Azure Firewall es un servicio en la nube de Microsoft que proporciona funcionalidades de firewall de próxima generación, incluida la inspección profunda de paquetes para flujos de tráfico norte-sur y este-oeste. En esta arquitectura, Azure Firewall proporciona seguridad de red para el tráfico web y no web. Usa la inspección de TLS para inspeccionar los flujos HTTP(S) entrantes desde Application Gateway, controla los flujos entrantes que no son HTTP(S) desde la red pública de Internet e inspecciona los flujos salientes de las máquinas virtuales para evitar la filtración de datos.

• Application Gateway es un equilibrador de carga de nivel 7 que proporciona funcionalidad de WAF. En esta arquitectura, Application Gateway proporciona equilibrio de carga regional para el tráfico HTTP(S), ayuda a detectar y evitar ataques web y proporciona terminación TLS y enrutamiento basado en rutas de acceso. Funciona como punto de conexión back-end para Traffic Manager.

• Traffic Manager es un equilibrador de carga de tráfico global basado en DNS que distribuye el tráfico a los servicios en regiones globales de Azure y proporciona alta disponibilidad y capacidad de respuesta. En esta arquitectura, Traffic Manager proporciona equilibrio de carga global y resuelve consultas DNS para dirigir el tráfico a los puntos de conexión regionales de la aplicación. Supervisa el estado del punto de conexión y redirige las respuestas DNS de regiones incorrectas.

• Azure Load Balancer es un equilibrador de carga de nivel 4 que distribuye el tráfico de red entrante entre los recursos back-end. En esta arquitectura, Load Balancer proporciona equilibrio de carga interno entre los niveles de aplicación y mantiene la alta disponibilidad entre zonas de disponibilidad dentro de cada región.

• Azure DDoS Protection es un servicio que ayuda a protegerse frente a ataques de denegación de servicio distribuido (DDoS). En esta arquitectura, DDoS Protection proporciona protección para direcciones IP públicas y ayuda a garantizar la disponibilidad durante escenarios de ataque.

• Azure DNS es un servicio de hospedaje para dominios DNS. Proporciona resolución de nombres a través de la infraestructura de Azure. En esta arquitectura, Azure DNS administra los registros DNS y funciona con Traffic Manager para proporcionar funcionalidades globales de equilibrio de carga y conmutación por error basadas en DNS.

• Las zonas DNS privadas de Azure son una característica de Azure DNS. Las zonas DNS privadas de Azure proporcionan resolución de nombres dentro de una red virtual y entre redes virtuales. En esta arquitectura, las zonas DNS privadas de Azure proporcionan resolución de nombres interna para los recursos dentro de la infraestructura de red virtual.

• Azure Virtual Machines es un servicio que proporciona recursos informáticos escalables a petición que proporcionan la flexibilidad de virtualización, pero eliminan las demandas de mantenimiento del hardware físico. En esta arquitectura, Virtual Machines hospeda los niveles de aplicación, que se distribuyen entre zonas de disponibilidad para la resistencia y entre varias regiones para la capacidad de recuperación.

• Azure Virtual Machine Scale Sets con orquestación flexible es un servicio que puede usar para crear y administrar un grupo de máquinas virtuales con equilibrio de carga que se pueden escalar automáticamente en función de la demanda. En esta arquitectura, los conjuntos de escalado de máquinas virtuales hospedan las máquinas virtuales de nivel de negocio y web en todas las zonas de disponibilidad de cada región. El nivel de datos usa máquinas virtuales de SQL Server independientes, como se describe a continuación.

• SQL Server en Virtual Machines es un servicio que proporciona versiones completas de SQL Server en la nube para que no sea necesario administrar ningún hardware local. En esta arquitectura, SQL Server en máquinas virtuales independientes forma el nivel de datos con grupos de disponibilidad AlwaysOn distribuidos entre zonas de disponibilidad en una configuración de varias subredes.

• Azure Virtual Network proporciona una red privada segura en la nube. Conecta máquinas virtuales entre sí, a Internet y a redes entre locales. En esta arquitectura, Virtual Network proporciona aislamiento de red y conectividad para todos los componentes. El emparejamiento de red virtual global proporciona comunicación de baja latencia entre regiones.

• Las UDR son un mecanismo para invalidar el enrutamiento predeterminado en las redes virtuales. En esta arquitectura, fuerzan los flujos de tráfico entrante y saliente a atravesar Azure Firewall para la inspección de seguridad y la aplicación de directivas.

Alternatives

Esta arquitectura usa opciones de tecnología específicas para admitir cargas de trabajo de protocolo mixto y de varias regiones. Los requisitos de carga de trabajo pueden dar lugar a diferentes opciones. Tenga en cuenta las siguientes alternativas.

Equilibrador de carga global

Enfoque actual: Traffic Manager proporciona equilibrio de carga global basado en DNS que admite protocolos HTTP(S) y no HTTP(S). Esta arquitectura usa Traffic Manager porque debe enrutar flujos que no son HTTP(S), como SFTP e integraciones TCP heredadas, a través de Azure Firewall para la inspección de nivel de red. Traffic Manager está basado en DNS, por lo que los clientes se conectan directamente a los puntos de conexión back-end, lo que requiere que Application Gateway y Azure Firewall tengan direcciones IP públicas.

Enfoque alternativo: Use Azure Front Door en lugar de Traffic Manager. Azure Front Door es un equilibrador de carga global de nivel 7 para el tráfico HTTP(S) que proporciona almacenamiento en caché, aceleración del tráfico, terminación TLS, administración de certificados y WAF integrado. Azure Front Door es un proxy inverso, por lo que puede conectarse a Application Gateway a través de Azure Private Link, lo que elimina la necesidad de direcciones IP públicas en la infraestructura de back-end. Es la solución de enrutamiento global preferida para cargas de trabajo solo HTTP(S).

Considere Azure Front Door si la carga de trabajo cumple las condiciones siguientes:

• Todo el tráfico entrante usa protocolos HTTP(S).

• No necesita Azure Firewall para la inspección profunda de paquetes del tráfico entrante.

• Quiere funcionalidades integradas de waf y red de entrega de contenido en el perímetro global.

Plataforma de computación

Enfoque actual: Los niveles de datos, negocio y web se ejecutan en conjuntos de escalado de máquinas virtuales con SQL Server en máquinas virtuales. Este enfoque de infraestructura como servicio (IaaS) proporciona control total sobre el sistema operativo (SO), el middleware y la configuración del motor de base de datos.

Enfoque alternativo: Reemplace niveles específicos por recursos de plataforma como servicio (PaaS), como Azure App Service para el nivel web o Azure SQL Database para el nivel de datos. La arquitectura de red general no cambia significativamente si usa la integración de red virtual de Private Link y App Service para integrar estos servicios PaaS en la red virtual.

Considere las alternativas de PaaS si la carga de trabajo cumple las condiciones siguientes:

• No necesita control directo de configuración de nivel de sistema operativo o middleware.

• Quiere reducir la sobrecarga operativa para la gestión de parches, escalado y gestión de disponibilidad.

• La carga de trabajo de la base de datos es compatible con el conjunto de características y los límites de SQL Database.

Combinación de servicios de equilibrio de carga

Enfoque actual: Esta arquitectura usa Traffic Manager para el enrutamiento global basado en DNS. Dentro de cada región, Application Gateway controla el procesamiento de capa 7 y la inspección de WAF, y Load Balancer administra la distribución de capa 4, de capa a capa.

Enfoque alternativo: Los requisitos de protocolo, latencia y seguridad de la carga de trabajo pueden requerir una combinación diferente de servicios de equilibrio de carga. Por ejemplo, las cargas de trabajo que no necesitan un WAF pueden usar Load Balancer solo para la distribución regional. Las cargas de trabajo que necesitan enrutamiento basado en rutas de acceso sin un firewall pueden usar Application Gateway sin Azure Firewall delante de él.

Para determinar qué servicios se ajustan a su escenario, consulte Opciones de equilibrio de carga en Azure.

Topología de red

Enfoque actual: Esta arquitectura usa un diseño de red virtual plana con todos los componentes de una sola red virtual para cada región.

Enfoque alternativo: Adapte esta arquitectura a un diseño de red virtual hub-spoke, en el que Azure Firewall reside en la red del concentrador y Application Gateway reside en el concentrador o en uno de los satélites. Si implementa Application Gateway en el centro, use varias instancias para distintos grupos de aplicaciones para controlar el ámbito de control de acceso basado en rol (RBAC) de Azure y permanecer dentro de los límites de Application Gateway. En un entorno de Azure Virtual WAN, no puedes implementar instancias de Application Gateway en el hub, por lo que las instalas en redes virtuales 'spoke'.

Detalles del escenario

• Enrutamiento de tráfico global: Traffic Manager usa el enrutamiento de rendimiento para dirigir a cada usuario al punto de conexión que tiene la latencia más baja y se ajusta automáticamente a medida que cambian las condiciones. Las comprobaciones de estado y el enrutamiento prioritario redirigen las respuestas DNS de regiones no saludables.

• Redundancia de zona: La arquitectura implementa recursos en tres zonas de disponibilidad en cada región. Application Gateway, equilibradores de carga internos y máquinas virtuales abarcan las tres zonas de disponibilidad. Si una sola zona experimenta una interrupción, las zonas restantes absorberán la carga sin desencadenar una conmutación por error regional.

• Equilibrio de carga regional y WAF: Application Gateway proporciona funcionalidades de nivel 7 dentro de cada región, como WAF, terminación TLS, enrutamiento basado en rutas de acceso y afinidad de sesión basada en cookies.

• Seguridad de red y inspección profunda de paquetes: Esta arquitectura coloca Application Gateway delante de Azure Firewall para la doble inspección del contenido web. Las topologías alternativas se documentan en Azure Firewall y Application Gateway para redes virtuales. Esta topología conserva la dirección IP de origen del cliente en el encabezado HTTP X-Forwarded-For , proporciona cifrado de un extremo a otro y evita que los clientes pasen el WAF.

  Azure Firewall Premium inspecciona tres tipos de flujos:

  • Flujos HTTP(S) entrantes provenientes de Application Gateway, protegidos mediante la inspección de TLS.

  • Flujos entrantes que no son HTTP(S) desde la red pública de Internet, inspeccionados con el conjunto de características Premium completo. Application Gateway también admite el proxy de nivel 4 (TCP/TLS), que consolida el tráfico HTTP y no HTTP en un único punto de entrada. Esta funcionalidad está en versión preliminar y WAF no se aplica al tráfico de nivel 4, por lo que esta arquitectura usa una ruta de acceso independiente para flujos que no son HTTP(S).

  • Flujos de salida de VMs para prevenir la exfiltración de datos y el acceso a destinos prohibidos.

• Orquestación de proceso: Los tres niveles de aplicación usan conjuntos de escalado de máquinas virtuales con orquestación flexible. El grupo de disponibilidad de SQL Server de varias subredes del nivel de datos requiere que coloque máquinas virtuales individuales en subredes y dominios de error específicos, lo cual solo es compatible con la orquestación flexible. Los niveles web y de negocio también usan orquestación flexible para mantener un único modelo operativo en la carga de trabajo en lugar de mezclar modos de orquestación entre niveles.

• Conectividad entre regiones: El emparejamiento de red virtual global proporciona replicación de datos de alto ancho de banda y baja latencia entre regiones a través de la red troncal de Microsoft. En una topología hub-and-spoke, existen conexiones entre redes hub-and-spoke dentro de cada región y entre hubs en distintas regiones.

Consideraciones

Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Well-Architected Framework.

Confiabilidad

La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.

• Implementación de varias regiones: Implemente en al menos dos regiones de Azure para la capacidad de recuperación. Una configuración de varias regiones activa-pasiva o activa-activa ayuda a la carga de trabajo a recuperarse de una interrupción regional. Traffic Manager supervisa el estado del punto de conexión y redirige las respuestas DNS de regiones incorrectas, pero debe asegurarse de que la región secundaria está lista para atender el tráfico, incluida la replicación de datos y la preparación de la aplicación.

  • En el caso de la región secundaria, prefiera una región emparejada cuando esté disponible una región emparejada porque proporciona una secuenciación de recuperación prioritaria y actualizaciones de plataforma escalonadas. Si su región no tiene una región asociada, puede crear una solución multirregional. Pero algunos servicios, como el almacenamiento con redundancia geográfica (GRS), requieren enfoques de replicación alternativos. Factorice la distancia geográfica, la residencia de datos, la disponibilidad del servicio y el costo. Para más información, consulte Seleccionar regiones de Azure.

  • Las réplicas de los grupos de disponibilidad Always On de SQL Server en la región secundaria utilizan confirmación asincrónica con conmutación por error manual. Dado que el modo de confirmación es asincrónico, es posible que la región secundaria no reciba algunas transacciones confirmadas durante una interrupción regional, por lo que planee la posible pérdida de datos. Defina su objetivo de punto de recuperación (RPO) y pruebe si el retraso de replicación bajo el volumen de escritura de su carga de trabajo permanece dentro de ese objetivo. La conmutación por error a la región secundaria es una operación manual que requiere un operador o un libro de procedimientos para activar o promover la réplica asincrónica.

• Resistencia zonal: Esta arquitectura implementa Application Gateway, Azure Firewall, Load Balancer y Virtual Machine Scale Sets en varias zonas de disponibilidad dentro de cada región para proporcionar resistencia frente a errores de nivel de centro de datos.

• Conjuntos de escalado de máquinas virtuales: La orquestación flexible distribuye las instancias de máquina virtual entre dominios de error dentro de cada zona de disponibilidad, lo que reduce el radio de explosión de un único error de host. También proporciona el control de selección de ubicación por máquina virtual que requiere la configuración del grupo de disponibilidad de SQL Server de varias subredes .

Enrutamiento global

• Use el método de enrutamiento de tráfico que mejor se adapte a las necesidades de los clientes. Traffic Manager admite varios métodos de enrutamiento de tráfico para enrutar de forma determinista el tráfico a los distintos puntos de conexión de servicio.

  Use Traffic Manager en una configuración anidada si necesita un control más pormenorizado para elegir una opción de conmutación por error preferida dentro de una región.

• Use la vista de tráfico para ver los patrones de tráfico y las métricas de latencia. La vista de tráfico puede ayudarle a planear la expansión en nuevas regiones de Azure.

Puerta de enlace de aplicaciones

Para mantener un flujo de tráfico confiable a través de Application Gateway, siga estos procedimientos:

• Confíe en que la plataforma distribuya instancias entre dominios de fallo y dominios de actualización. En las regiones que admiten zonas de disponibilidad, Application Gateway es redundante de zona de forma predeterminada, por lo que las instancias también abarcan zonas de disponibilidad para la tolerancia a errores zonales.

• Active el escalado automático y establezca el recuento mínimo de instancias en al menos dos. Esta capacidad reservada garantiza que Application Gateway pueda atender el tráfico sin el retraso de tres a cinco minutos para aprovisionar nuevas instancias. Para más información, consulte Escalado automático de Application Gateway.

• Active la purga de conexiones para que las solicitudes en curso se completen antes de que el Application Gateway elimine las instancias backend. Sin él, los eventos de escalado y las actualizaciones de configuración provocan errores transitorios de solicitud.

Azure Firewall

Este diseño requiere Azure Firewall Premium para proporcionar la inspección de TLS. Azure Firewall intercepta las sesiones TLS entre Application Gateway y las máquinas virtuales de nivel web, genera sus propios certificados e inspecciona los flujos de tráfico salientes de las redes virtuales a la red pública de Internet. Para más información, consulte Red de confianza cero para aplicaciones web que usan Azure Firewall y Application Gateway.

Supervise las fechas de expiración de los certificados intermedios de entidad de certificación (CA) que Azure Firewall usa para la inspección de TLS. Un certificado expirado interrumpe el intercambio inicial TLS, por lo que el tráfico no puede llegar a los servidores de respaldo, aunque todos los componentes de infraestructura sigan funcionando bien. Para más información, consulte Cadena de confianza de certificados TLS.

Recomendaciones de comprobación de salud del sistema

Tenga en cuenta las siguientes recomendaciones para los sondeos de estado de salud en Traffic Manager, Application Gateway y Load Balancer.

Traffic Manager

• Estado del punto de conexión: Cree un punto de conexión que informe del estado general de la aplicación. Traffic Manager usa un sondeo HTTP(S) para supervisar la disponibilidad de cada región. El sondeo comprueba si hay una respuesta HTTP 200 (OK) para una ruta de acceso url especificada. Use el punto de conexión que cree para el sondeo de estado porque otros puntos de conexión podrían provocar que el sondeo notifique un estado correcto incluso cuando se produzca un error en las partes críticas de la aplicación. Para más información, consulte Patrón Health Endpoint Monitoring.

• Retraso de conmutación por error: Traffic Manager tiene un retraso de conmutación por error. Los siguientes factores determinan la duración del retraso:

  • Intervalos de sondeo: Frecuencia con la que el sondeo comprueba el estado del punto de conexión.

  • Número tolerado de errores: Cuántos errores tolera el sondeo antes de marcar el punto de conexión como no saludable.

  • Tiempo de espera de sondeo: Cuánto tiempo antes de que Traffic Manager considere que el punto de conexión es incorrecto.

  • Período de vida (TTL): Los servidores DNS deben actualizar los registros DNS almacenados en caché para la dirección IP. El tiempo necesario depende del TTL de DNS. El TTL predeterminado es de 300 segundos (5 minutos), pero puede establecer este valor al crear el perfil de Traffic Manager. Para obtener más información, consulte Traffic Manager monitoring.

Application Gateway y Balanceador de Carga

Familiarícese con las directivas de sondeo de estado de Application Gateway y Load Balancer para asegurarse de que comprende el estado de las máquinas virtuales:

• Application Gateway siempre usa un sondeo HTTP.

• Load Balancer puede evaluar HTTP o TCP. Use un sondeo HTTP si una máquina virtual ejecuta un servidor HTTP. Use TCP para todos los demás casos.

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

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, vea Lista de comprobación para la revisión de diseño de seguridad.

Esta arquitectura presupone que no hay confianza implícita entre los componentes. Varias capas inspeccionan y autorizan el tráfico. Application Gateway WAF filtra amenazas de nivel HTTP. Azure Firewall Premium inspecciona todos los flujos de tráfico en un nivel de paquete profundo. Los grupos de seguridad de red (NSG) aplican la segmentación con privilegios mínimos entre niveles. El cifrado TLS protege los datos en tránsito en cada salto de red. Ninguna capa única bloquea todas las amenazas.

• WAF: La funcionalidad waf de Application Gateway detecta e impide ataques en el nivel HTTP, como la inyección de CÓDIGO SQL (SQLi) o el scripting entre sitios (XSS).

• Firewall de próxima generación: Azure Firewall Premium proporciona una capa adicional de defensa mediante la inspección del contenido de ataques no web, como archivos malintencionados cargados a través de HTTP(S) u otros protocolos.

• Cifrado de un extremo a otro: El tráfico siempre se cifra cuando atraviesa la red de Azure. Application Gateway y Azure Firewall cifran el tráfico antes de enviarlo al sistema back-end correspondiente.

• Cadena de confianza de certificados TLS: Azure Firewall Premium funciona como proxy de reenvío y genera dinámicamente certificados firmados por una entidad de certificación privada durante la inspección de TLS. Configure Application Gateway para confiar en el certificado de entidad de certificación raíz que utiliza Azure Firewall, de modo que el intercambio TLS entre ellos se realice correctamente.

  En el caso de las implementaciones de producción, use una infraestructura de clave pública empresarial (PKI) para generar el certificado de ca intermedio. Para más información, consulte Implementación y configuración de certificados de entidad de certificación de empresa para Azure Firewall y los detalles de la cadena de certificados para esta arquitectura.

• DDoS: Use Azure DDoS Network Protection para una mayor protección contra DDoS que la protección básica que proporciona Azure.

• NSG: Use grupos de seguridad de red para restringir el tráfico de red dentro de la red virtual. Por ejemplo, en la arquitectura de tres niveles, el nivel de datos acepta tráfico solo desde el nivel empresarial y no desde el nivel web. Para aplicar esta regla, el nivel de base de datos bloquea todo el tráfico entrante, excepto la subred de nivel empresarial:

  1. Permitir el tráfico entrante desde la subred de la capa empresarial.

  2. Permita el tráfico entrante desde la subred del nivel de base de datos. Esta regla permite la comunicación entre las máquinas virtuales de la base de datos. La replicación de bases de datos y la conmutación por error dependen de esta regla.

  3. Deniega todo el tráfico entrante de la red virtual usando la etiqueta VirtualNetwork en la regla para sobrescribir la instrucción de permitir en las reglas predeterminadas del NSG.

  Crear la regla 3 con prioridad más baja (número más alto) que las primeras reglas.

  Puede usar etiquetas de servicio para definir controles de acceso de red en NSG (grupos de seguridad de red) o Azure Firewall. Application Gateway también tiene sus propias reglas de NSG necesarias que debe permitir en su subred dedicada.

Optimización de costos

La optimización de costos se centra en formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

• Costo de línea base de varias regiones: Esta arquitectura implementa una marca de infraestructura completa en cada región, incluidos los conjuntos de escalado de máquinas virtuales en tres niveles, Application Gateway, Azure Firewall Premium y equilibradores de carga. La región secundaria incurre en un costo si atiende el tráfico o no. En una configuración activa-pasiva, escale las instancias de Virtual Machine Scale Sets de la región secundaria al mínimo necesario para una conmutación por error oportuna en lugar de ejecutarlas en una capacidad de producción completa.

• Máquinas virtuales: Las máquinas virtuales son el principal factor de costo porque cada nivel en ambas regiones ejecuta cómputo de forma continua. Use Instancias Reservadas de Máquinas Virtuales de Azure o planes de ahorro de Azure para cómputo. Las instancias reservadas funcionan bien para la capacidad siempre activa mínima, mientras que los planes de ahorro proporcionan flexibilidad si los tamaños de máquina virtual cambian con el tiempo.

• Azure Firewall Premium: Azure Firewall Premium tiene un cargo fijo por hora por unidad de implementación y tarifas de procesamiento variables por gigabyte (GB), y funciona en ambas regiones. Si la carga de trabajo no requiere la detección y prevención de intrusiones (IDPS) o la inspección de TLS, determine si Azure Firewall Standard cumple los requisitos de seguridad a un precio más bajo.

• Descuento de protección de red DDoS y WAF:Protección de red DDoS tiene un costo mensual fijo que cubre hasta 100 direcciones IP públicas entre suscripciones de una entidad.

  Al activar DDoS Network Protection, Azure factura las instancias de WAF de Application Gateway a la tasa estándar más baja en lugar de la tasa de WAF. En el caso de las arquitecturas que tienen varias instancias de Application Gateway, el descuento de WAF puede compensar una parte significativa del costo del plan DDoS.

• Escalado de Application Gateway: Application Gateway cobra una tarifa por hora fija más los costos unitarios de capacidad variable. Un mayor número mínimo de instancias de autoscalado reserva unidades de capacidad que se deben pagar independientemente de la cantidad de tráfico. Equilibre el número mínimo de instancias con respecto a la latencia aceptable de arranque en frío para evitar pagar por la capacidad sin usar.

Para obtener detalles de precios específicos del servicio, consulte los siguientes recursos:

• Precios de Máquinas virtuales
• Precios de Application Gateway
• Azure Firewall: precios
• Precios de DDoS Protection
• Precios de Traffic Manager

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

• Infraestructura como código (IaC): Esta arquitectura tiene un área expuesta de recursos grande que incluye Traffic Manager, dos sellos regionales que tienen Application Gateway, Azure Firewall y equilibradores de carga, conjuntos de escalado de máquinas virtuales, grupos de seguridad de red, redes virtuales y subredes. Defina todos los recursos en Bicep o Terraform para garantizar que ambos sellos regionales sigan siendo coherentes y para despliegues repetibles.

• Coordinación de la implementación: En las implementaciones que tienen dos stamps regionales activos, implemente actualizaciones en la región secundaria y validelas antes de promover los cambios en la región primaria. Use prácticas de implementación seguras con exposición progresiva para limitar el ámbito de impacto. La ponderación de DNS del Traffic Manager puede admitir cambios de tráfico canario entre regiones durante las fases de despliegue.

• Supervisión: Implemente un área de trabajo de Log Analytics en cada región para que la supervisión permanezca funcional incluso durante una interrupción regional.

  Utilice consultas entre áreas de trabajo y libros de trabajo de Azure Monitor para correlacionar las señales a través de ambas regiones en una vista operativa unificada. Cree un modelo de salud que combine sondeos de puntos de conexión de Traffic Manager, estado de back-end de Application Gateway, registros de Azure Firewall y métricas de nivel de máquina virtual en un estado de salud compuesto.

• Desfase de configuración: Dos sellos regionales idénticos crean un riesgo continuo de desfase de configuración. Use Azure Policy para aplicar directrices, como reglas de NSG, versiones de políticas de Azure Firewall y conjuntos de reglas WAF de Application Gateway que se mantengan coherentes en todas las regiones.

• Organización de recursos: Use grupos de recursos independientes para cada marca regional para poder administrar, implementar y limpiar los recursos por región de forma independiente. Coloque recursos globales compartidos como Traffic Manager y zonas DNS en su propio grupo de recursos.

• Pruebas de conmutación por error: Pruebe periódicamente la conmutación por error regional para validar que los sondeos de estado de Traffic Manager detectan interrupciones rápidamente, que el grupo de disponibilidad de SQL Server promueve correctamente en la región secundaria y que la marca secundaria controla la carga de producción. Los procedimientos de conmutación por error no probados suelen fallar cuando se necesita usarlos.

• Sobrecarga operativa: Esta arquitectura de IaaS requiere que administre la configuración del middleware, la rotación de certificados, el ajuste de reglas de firewall y el estado del grupo de disponibilidad de SQL Server en ambas regiones.

  La orquestación flexible admite el parcheo automático de invitados para parches críticos y de seguridad, pero no admite actualizaciones automáticas de imágenes de SO. Utilice Azure Update Manager o la canalización de implementación para gestionar las actualizaciones de imágenes del sistema operativo.

  Esta carga operativa continua es la principal compensación por el control y la flexibilidad que proporciona IaaS. Si el equipo no necesita este nivel de control, tenga en cuenta las alternativas de PaaS.

Eficiencia en el rendimiento

La eficiencia del rendimiento hace referencia a la capacidad de escalado de la carga de trabajo para satisfacer las demandas de los usuarios de forma eficaz. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.

• Conjuntos de escalado de máquinas virtuales: Implemente una instancia independiente de Virtual Machine Scale Sets con orquestación flexible para cada nivel de aplicación, incluidos los niveles web, empresariales y de datos. Los conjuntos de escalado independientes permiten escalar cada nivel de forma independiente en función de su propio perfil de demanda. Configure directivas de escalado automático en los niveles web y de negocio para escalar horizontalmente durante los aumentos de la demanda y escalar verticalmente durante períodos de baja demanda.

• Latencia de inspección doble: En esta arquitectura, el flujo HTTP(S) pasa el tráfico a través del WAF de Application Gateway y de la inspección TLS de Azure Firewall Premium. Esta defensa superpuesta agrega latencia a cada solicitud. Pruebe el rendimiento de la aplicación bajo carga realista para confirmar que el tiempo de inspección adicional cumple los requisitos de tiempo de respuesta.

• Rendimiento de Azure Firewall: IdPS en modos de alerta y denegación reduce significativamente el rendimiento máximo de Azure Firewall en comparación con otros modos. Si la carga de trabajo requiere tanto el modo de denegación de IDPS como el alto rendimiento, planee la capacidad en consecuencia y supervise las métricas de rendimiento del firewall. Para obtener más información, consulte el rendimiento de Azure Firewall.

• Capacidad de Application Gateway: El procesamiento de reglas waf y las operaciones TLS consumen unidades de proceso y reducen el rendimiento por instancia. Supervise las métricas de unidad de capacidad y unidad de proceso para confirmar que el escalado automático sigue el ritmo de la demanda.

• Enrutamiento de solo lectura: Los secundarios del grupo de disponibilidad AlwaysOn de esta arquitectura pueden servir consultas de solo lectura, como las cargas de trabajo de informes o análisis. Configure enrutamiento de solo lectura para desviar el tráfico de lectura desde la réplica principal y convertir la inversión de alta disponibilidad en una ventaja de rendimiento.

Recurso relacionado

• Línea base de AKS para clústeres de varias regiones