Redundancia de enrutamiento global para aplicaciones web críticas

Importante

El diseño de implementaciones de redundancia que aborden las interrupciones globales de la plataforma con el fin de desarrollar una arquitectura crítica puede resultar complejo y costoso. Dados los posibles problemas que pueden surgir con este diseño, hay que tener muy en cuenta los inconvenientes.

En la mayoría de las situaciones, no necesitará la arquitectura que se describe en este artículo.

La finalidad de los sistemas críticos es minimizar los puntos únicos de error mediante la creación de redundancia y funcionalidades de recuperación automática en la solución en la medida de lo posible. Cualquier punto de entrada unificado del sistema se puede considerar un punto de error. Si este componente experimenta una interrupción, todo el sistema estará sin conexión para el usuario. Al elegir un servicio de enrutamiento, es importante tener en cuenta la confiabilidad del propio servicio.

En la arquitectura de línea base de una aplicación crítica, se eligió Azure Front Door por sus acuerdos de nivel de servicio (SLA) de elevado tiempo de actividad y su amplio conjunto de características:

• Enrutamiento del tráfico a varias regiones en un modelo activo-activo
• Conmutación por error transparente mediante la difusión por proximidad TCP
• Entrega de contenido estático desde nodos perimetrales mediante redes de entrega de contenido integradas (CDN)
• Bloqueo del acceso no autorizado mediante el firewall de aplicaciones web integrado

Front Door se ha diseñado para proporcionar una resistencia y una disponibilidad óptimas no solo a nuestros clientes externos, sino también a distintas propiedades de Microsoft. Para más información sobre las funcionalidades de Front Door, consulte Agilización y protección de su aplicación web con Azure Front Door.

Las funcionalidades de Front Door son más que suficientes para satisfacer la mayoría de los requisitos empresariales. No obstante, como ocurre con cualquier sistema distribuido, pueden producirse errores. Si los requisitos empresariales exigen un acuerdo de nivel de servicio compuesto superior o un tiempo de inactividad nulo en caso de interrupción, tendrá que recurrir a una ruta de acceso alternativa para la entrada de tráfico. Sin embargo, un acuerdo de nivel de servicio superior conlleva unos costes importantes, una sobrecarga operativa y una posible disminución de la confiabilidad general. Tenga muy en cuenta los inconvenientes y los problemas que la ruta de acceso alternativa podría provocar en otros componentes que se encuentran en la ruta crítica. Incluso aunque el efecto de la falta de disponibilidad sea considerable, la complejidad puede pesar más que las ventajas.

Uno de los enfoques consiste en definir una ruta de acceso secundaria, con servicios alternativos, que solo se active cuando Azure Front Door no esté disponible. La paridad de características con Front Door no debe tratarse como un requisito imprescindible. Dé prioridad a las características que realmente necesite a efectos de continuidad empresarial, incluso ante una posible ejecución en una capacidad limitada.

Otro de los enfoques consiste en usar tecnología de terceros para el enrutamiento global. Este enfoque requerirá una implementación activa-activa multinube con stamps hospedados en dos o más proveedores de servicios en la nube. Aunque Azure se puede integrar eficazmente con otras plataformas en la nube, este enfoque no es recomendable debido a la complejidad operativa en las distintas plataformas en la nube.

En este artículo se describen algunas estrategias para el enrutamiento global mediante Azure Traffic Manager como enrutador alternativo en las situaciones en las que Azure Front Door no está disponible.

Enfoque

En este diagrama de arquitectura se muestra un enfoque general con varias rutas de acceso de tráfico redundantes.

Con este enfoque, se presentan varios componentes y se proporcionan orientaciones que supondrán importantes cambios con respecto a la entrega de las aplicaciones web:

1. Azure Traffic Manager dirige el tráfico a Azure Front Door o al servicio alternativo que se haya seleccionado.

   Azure Traffic Manager es un equilibrador de carga global basado en DNS. El registro CNAME del dominio apunta a Traffic Manager, que determina el destino en función de cómo se configure el método de enrutamiento. Si se usa el enrutamiento de prioridad, el tráfico fluirá a través de Azure Front Door de forma predeterminada. Traffic Manager puede cambiar automáticamente el tráfico a la ruta de acceso alternativa si Azure Front Door no está disponible.

   Importante

   Esta solución mitiga los riesgos asociados a las interrupciones de Azure Front Door, pero es susceptible a las interrupciones de Azure Traffic Manager como punto de error global.

   También puede considerar la posibilidad de usar otro sistema de enrutamiento de tráfico global, como un equilibrador de carga global. No obstante, Traffic Manager funciona bien en muchas situaciones.

2. Hay dos rutas de acceso de entrada:

   • Azure Front Door proporciona la ruta principal y procesa y enruta todo el tráfico de la aplicación.

   • Se usa otro enrutador como copia de seguridad de Azure Front Door. El tráfico solo fluye a través de esta ruta de acceso secundaria si Front Door no está disponible.

   La elección de un servicio específico para el enrutador secundario depende de muchos factores. Puede optar por usar servicios nativos de Azure o servicios de terceros. En estos artículos se proporcionan opciones nativas de Azure para no aumentar la complejidad operativa de la solución. Si usa servicios de terceros, tendrá que usar varios planos de control para administrar la solución.

3. Los servidores de aplicaciones de origen deben estar listos para aceptar el tráfico de cualquiera de los servicios. Tenga en cuenta cómo protege el tráfico que se dirige al origen y cuáles son las responsabilidades de Front Door y otros servicios ascendentes. Asegúrese de que la aplicación puede gestionar el tráfico de cualquier ruta por la que fluya.

Compromisos

Aunque esta estrategia de mitigación puede hacer que la aplicación esté disponible durante las interrupciones de la plataforma, hay algunos inconvenientes importantes. Debe sopesar las posibles ventajas frente a los costes y decidir de manera fundamentada si las ventajas compensan esos costes.

• Costes financieros: al implementar varias rutas de acceso redundantes en la aplicación, debe tener en cuenta los costes que conllevan la implementación y la ejecución de los recursos. Proporcionamos dos escenarios de ejemplo para distintos casos de uso, cada uno de ellos con un perfil de costes diferente.

• Complejidad operativa: cada vez que agrega componentes adicionales a la solución, aumenta la sobrecarga de administración. Cualquier cambio en un componente puede afectar a otros componentes.

  Supongamos que decide usar las nuevas funcionalidades de Azure Front Door. Debe comprobar si la ruta de acceso de tráfico alternativa también proporciona una funcionalidad equivalente y, si no es así, debe decidir cómo gestionar la diferencia de comportamiento entre las dos rutas de acceso de tráfico. En las aplicaciones reales, estas complejidades pueden suponer un elevado coste, así como un riesgo importante para la estabilidad del sistema.

• Rendimiento: este diseño requiere búsquedas adicionales de CNAME durante la resolución de nombres. En la mayoría de las aplicaciones, no es un problema significativo, pero debe evaluar si el rendimiento de la aplicación se verá afectado al introducir capas adicionales en la ruta de acceso de entrada.

• Coste de oportunidad: el diseño y la implementación de rutas de entrada redundantes requiere una inversión considerable en ingeniería, lo que en última instancia conlleva un coste de oportunidad para el desarrollo de características y otras mejoras de la plataforma.

Advertencia

El diseño y la implementación de una solución compleja de alta disponibilidad debe hacerse con cuidado, ya que, de lo contrario, podría empeorar la disponibilidad. Si aumenta la cantidad de componentes de la arquitectura, aumentará la cantidad de puntos de error. También aumentará la complejidad operativa. Al agregar componentes adicionales, debe revisar cuidadosamente todos los cambios que realice para comprender cómo afectan a la solución general.

Disponibilidad de Azure Traffic Manager

Azure Traffic Manager es un servicio confiable, pero el acuerdo de nivel de servicio no garantiza una disponibilidad del 100 %. Si Traffic Manager no está disponible, es posible que los usuarios no puedan acceder a la aplicación, incluso aunque Azure Front Door y el servicio alternativo estén disponibles. Es importante planificar cómo seguirá funcionando la solución en estas circunstancias.

Traffic Manager devuelve respuestas DNS almacenables en caché. Si el tiempo de vida (TTL) de los registros DNS permite el almacenamiento en caché, puede que las interrupciones breves de Traffic Manager no supongan ningún problema, ya que es posible que las resoluciones DNS descendentes hayan almacenado en caché una respuesta anterior. Debe prepararse para las interrupciones prolongadas. Puede optar por reconfigurar manualmente los servidores DNS para dirigir a los usuarios a Azure Front Door en caso de que Traffic Manager no esté disponible.

Coherencia del enrutamiento del tráfico

Es importante que comprenda las funcionalidades y características de Azure Front Door que utiliza y necesita. A la hora de elegir el servicio alternativo, determine qué capacidades mínimas necesita y qué otras características deben omitirse cuando la solución se encuentre en modo degradado.

A la hora de planificar una ruta de acceso de tráfico alternativa, estas son algunas de las preguntas clave que debe tener en cuenta:

• ¿Usa las características de almacenamiento en caché de Azure Front Door? Si el almacenamiento en caché no está disponible, ¿pueden los servidores de origen gestionar el tráfico?
• ¿Usa el motor de reglas de Azure Front Door para ejecutar una lógica de enrutamiento personalizada o para reescribir las solicitudes?
• ¿Usa el firewall de aplicaciones web (WAF) de Azure Front Door para proteger las aplicaciones?
• ¿Restringe el tráfico en función de la dirección IP o la ubicación geográfica?
• ¿Quién emite y administra los certificados TLS?
• ¿Cómo restringe el acceso a los servidores de aplicaciones de origen para asegurarse de que este pasa a través de Azure Front Door? ¿Usa Private Link o se basa en direcciones IP públicas con etiquetas de servicio y encabezados de identificador?
• ¿Los servidores de aplicaciones aceptan tráfico desde algún otro lugar que no sea Azure Front Door? Si es así, ¿qué protocolos aceptan?
• ¿Los clientes usan la compatibilidad con HTTP/2 de Azure Front Door?

Firewall de aplicaciones web (WAF)

Si usa el WAF de Azure Front Door para proteger la aplicación, tenga en cuenta qué sucede si el tráfico no pasa por Azure Front Door.

Si la ruta de acceso alternativa también proporciona un WAF, tenga en cuenta las siguientes preguntas:

• ¿Se puede configurar de la misma manera que el WAF de Azure Front Door?
• ¿Hay que ajustarlo y probarlo de forma independiente para reducir la probabilidad de detecciones de falsos positivos?

Advertencia

Puede optar por no usar el WAF para la ruta de acceso de entrada alternativa. Puede considerarse que este enfoque permite alcanzar el objetivo de confiabilidad de la aplicación. Sin embargo, no es una buena práctica, por lo que no lo recomendamos.

Debe tener en cuenta el inconveniente de aceptar el tráfico de Internet sin ningún tipo de comprobación. Si un atacante detecta una ruta de acceso de tráfico secundaria a la aplicación que no esté protegida, puede enviar tráfico malintencionado a través de esta incluso aunque la ruta de acceso principal cuente con un WAF.

Es mejor proteger todas las rutas de acceso a los servidores de aplicaciones.

Nombres de dominio y DNS

La aplicación crítica debe usar un nombre de dominio personalizado. Así, podrá controlar cómo fluye el tráfico a la aplicación y reducir las dependencias de un único proveedor.

También es recomendable usar un servicio DNS resistente y de alta calidad para el nombre de dominio, como Azure DNS. Si los servidores DNS del nombre de dominio no están disponibles, los usuarios no podrán acceder al servicio.

Se recomienda usar varias resoluciones DNS para aumentar aún más la resistencia general.

Encadenamiento de CNAME

Las soluciones que combinan Traffic Manager, Azure Front Door y otros servicios usan un proceso de resolución CNAME de DNS de varias capas, también denominado encadenamiento de CNAME. Por ejemplo, al resolver su propio dominio personalizado, es posible que vea cinco o más registros CNAME antes de que se devuelva una dirección IP.

Agregar vínculos adicionales a una cadena CNAME puede afectar al rendimiento de la resolución de nombres DNS. Sin embargo, las respuestas DNS suelen almacenarse en caché, lo que reduce el impacto en el rendimiento.

Certificados TLS

Para una aplicación crítica, se recomienda aprovisionar y usar certificados TLS propios en lugar de los certificados administrados que Azure Front Door proporciona. Así se reducirá la cantidad de problemas que puede plantear esta compleja arquitectura.

Estas son algunas ventajas:

• Para emitir y renovar certificados TLS administrados, Azure Front Door comprueba la propiedad del dominio. En el proceso de comprobación del dominio se presupone que los registros CNAME del dominio apuntan directamente a Azure Front Door. Pero no siempre es así. Puede suceder que la emisión y renovación de certificados TLS administrados en Azure Front Door no funcione correctamente, con lo que aumentará el riesgo de interrupciones derivadas de problemas con los certificados TLS.

• Aunque los demás servicios proporcionen certificados TLS administrados, es posible que no puedan comprobar la propiedad del dominio.

• Si cada servicio obtiene sus propios certificados TLS administrados de forma independiente, podrían surgir problemas. Por ejemplo, que los usuarios no esperen ver diferentes certificados TLS emitidos por diferentes autoridades o con diferentes fechas de caducidad o huellas digitales.

Ahora bien, habrá operaciones adicionales relacionadas con la renovación y actualización de los certificados antes de que estos caduquen.

Seguridad de origen

Si configura el origen para que solo acepte el tráfico a través de Azure Front Door, obtendrá protección contra los ataques DDoS de niveles 3 y 4. Dado que Azure Front Door solo responde al tráfico HTTP válido, también permite reducir la exposición a muchas de las amenazas basadas en protocolos. Si cambia la arquitectura para permitir rutas de acceso de entrada alternativas, debe evaluar si ha aumentado accidentalmente la exposición del origen a las amenazas.

Si usa Private Link para conectarse desde Azure Front Door al servidor de origen, ¿cómo fluye el tráfico a través de la ruta de acceso alternativa? ¿Puede usar direcciones IP privadas para acceder a los orígenes o debe usar direcciones IP públicas?

Si el origen usa la etiqueta de servicio de Azure Front Door y el encabezado X-Azure-IDFD para validar que el tráfico ha fluido a través de Azure Front Door, tenga en cuenta cómo se pueden volver a configurar los orígenes para validar que el tráfico ha fluido a través de cualquiera de las rutas de acceso válidas. Debe realizar una prueba para comprobar que no ha abierto accidentalmente el origen al tráfico a través de otras rutas de acceso, incluidos los perfiles de Azure Front Door de otros clientes.

Al planificar la seguridad del origen, compruebe si la ruta de acceso de tráfico alternativa depende del aprovisionamiento de direcciones IP públicas dedicadas. En ese caso, podría ser necesario un proceso desencadenado manualmente para poner en línea la ruta de acceso a la copia de seguridad.

Si hay direcciones IP públicas dedicadas, plantéese si debe implementar Azure DDoS Protection para reducir el riesgo de ataques de denegación de servicio contra los orígenes. Tenga también en cuenta si necesita implementar Azure Firewall u otro firewall capaz de protegerle frente a diversas amenazas de red. Es posible que además necesite más estrategias de detección de intrusiones. Estos controles pueden ser componentes importantes en una arquitectura más compleja de varias rutas.

Modelado de estado

La metodología de diseño crítica requiere un modelo de estado del sistema que proporcione una observabilidad general de la solución y sus componentes. Si usa varias rutas de acceso de entrada de tráfico, debe supervisar el estado de una de ellas. Si el tráfico se redirige a la ruta de acceso de entrada secundaria, el modelo de estado debe reflejar el hecho de que el sistema sigue funcionando, pero se está ejecutando en un estado degradado.

Incluya estas preguntas en el diseño del modelo de estado:

• ¿Cómo supervisan los distintos componentes de la solución el estado de los componentes descendentes?
• ¿Cuándo se debe considerar que el estado de los componentes descendentes es incorrecto?
• ¿Cuánto tiempo se tarda en detectar una interrupción?
• Una vez que se detecta una interrupción, ¿cuánto tiempo tarda el tráfico en enrutarse a través de una ruta de acceso alternativa?

Hay varias soluciones de equilibrio de carga globales que permiten supervisar el estado de Azure Front Door y desencadenar una conmutación automática por error a una plataforma de copia de seguridad si se produce una interrupción. Azure Traffic Manager es adecuado en la mayoría de los casos. Con Traffic Manager, puede configurar la supervisión de puntos de conexión para supervisar los servicios descendentes especificando la dirección URL que se debe comprobar, la frecuencia con la que se comprobará esa dirección URL y cuándo se debe considerar que el estado del servicio descendente es incorrecto en función de las respuestas de sondeo. En general, cuanto menor sea el intervalo entre comprobaciones, menos tiempo tardará Traffic Manager en dirigir el tráfico a través de una ruta de acceso alternativa para llegar al servidor de origen.

Si Front Door no está disponible, hay varios factores que influyen en la cantidad de tiempo que la interrupción afecta al tráfico, entre los que se incluyen:

• El período de vida (TTL) de los registros DNS.
• La frecuencia con la que Traffic Manager ejecuta las comprobaciones de estado.
• La cantidad configurada de sondeos con errores que Traffic Manager debe ver antes de redirigir el tráfico.
• Durante cuánto tiempo los clientes y los servidores DNS ascendentes almacenan en caché las respuestas DNS de Traffic Manager.

También tiene que determinar cuáles de esos factores están bajo su control y si los servicios ascendentes que escapan a su control pueden afectar a la experiencia del usuario. Por ejemplo, aunque use un valor de TTL bajo en los registros DNS, es posible que las cachés DNS ascendentes sigan atendiendo respuestas obsoletas durante más tiempo del que deberían. Este comportamiento puede empeorar los efectos de una interrupción o hacer que parezca que la aplicación no está disponible, incluso aunque Traffic Manager ya haya empezado a enviar las solicitudes a la ruta de acceso de tráfico alternativa.

Sugerencia

Las soluciones críticas requieren enfoques de conmutación por error automatizada siempre que sea posible. Los procesos de conmutación por error manual se consideran lentos para mantener la capacidad de respuesta de la aplicación.

Consulte: Área de diseño crítica: modelado de estado

Implementación sin tiempo de inactividad

A la hora de planificar el funcionamiento de una solución con una ruta de acceso de entrada redundante, también debe planificar cómo implementar o configurar los servicios cuando se degraden. Para la mayoría de los servicios de Azure, los acuerdos de nivel de servicio se aplican al tiempo de actividad del propio servicio, no a las operaciones de administración ni a las implementaciones. Tenga en cuenta si los procesos de implementación y configuración deben ser resistentes a las interrupciones del servicio.

También debe tener en cuenta la cantidad de planos de control independientes con los que debe interactuar para administrar la solución. Cuando se usan servicios de Azure, Azure Resource Manager proporciona un plano de control unificado y coherente. Sin embargo, si usa un servicio de terceros para enrutar el tráfico, es posible que tenga que usar un plano de control independiente para configurar el servicio, lo que aumenta la complejidad operativa.

Advertencia

El uso de múltiples planos de control supone una mayor complejidad y un mayor riesgo para la solución. Cada punto de diferencia aumenta la probabilidad de que alguien omita accidentalmente un ajuste de configuración o aplique configuraciones diferentes a componentes redundantes. Asegúrese de que los procedimientos operativos mitiguen este riesgo.

Consulte: Área de diseño crítica: implementación sin tiempo de inactividad

Validación continua

Para una solución crítica, los procedimientos de prueba deben comprobar que la solución cumple los requisitos independientemente de la ruta de acceso por la que fluye el tráfico de la aplicación. Tenga en cuenta cada parte de la solución y cómo probarla para cada tipo de interrupción.

Asegúrese de que los procesos de prueba incluyan los siguientes elementos:

• ¿Puede comprobar que el tráfico se redirige correctamente a través de la ruta de acceso alternativa cuando la ruta de acceso principal no está disponible?
• ¿Ambas rutas de acceso admiten el nivel de tráfico de producción que espera recibir?
• ¿Ambas rutas de acceso están adecuadamente protegidas para evitar abrir o exponer vulnerabilidades en un estado degradado?

Consulte: Área de diseño crítica: validación continua

Escenarios frecuentes

Estos son escenarios comunes en los que se puede usar este diseño:

• Entrega de contenido global: suele consistir en la entrega de contenido estático y elementos multimedia, así como aplicaciones de comercio electrónico a gran escala. En este escenario, el almacenamiento en caché es una parte fundamental de la arquitectura de la solución, por lo que los errores en la memoria caché pueden provocar una degradación considerable del rendimiento o la confiabilidad.

• Entrada HTTP global: se aplica normalmente a las API y las aplicaciones dinámicas críticas. En este escenario, el requisito principal es enrutar el tráfico al servidor de origen de forma confiable y eficaz. Con frecuencia, uno de los controles de seguridad más importantes que se utilizan en estas soluciones es un WAF.

Advertencia

El diseño y la implementación de una solución compleja de entrada múltiple debe hacerse con cuidado, ya que, de lo contrario, podría empeorar la disponibilidad. Si aumenta la cantidad de componentes de la arquitectura, aumentará la cantidad de puntos de error. También aumentará la complejidad operativa. Al agregar componentes adicionales, debe revisar cuidadosamente todos los cambios que realice para comprender cómo afectan a la solución general.

Pasos siguientes

Revise los escenarios de entrada HTTP global y entrega de contenido global para saber si se aplican a la solución.