Compartir vía

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 se queda 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 una aplicación de misión crítica, Azure Front Door se elige debido a su acuerdo de nivel de servicio (SLA) de alto tiempo de actividad y un conjunto de características enriquecido.

  • Enrutar el tráfico a varias regiones, ya sea en un modelo activo-activo o activo-pasivo
  • 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

Para más información sobre las funcionalidades de Azure Front Door, consulte Aceleración y protección de la aplicación web con Azure Front Door.

Azure Front Door está diseñado para proporcionar la máxima resistencia y disponibilidad no solo para nuestros clientes externos, sino también para varias propiedades en Microsoft. Las funcionalidades de Azure Front Door son más que suficientes para cumplir la mayoría de los requisitos empresariales, pero con cualquier sistema distribuido, se espera un error. Ningún componente o sistema es infalible. Microsoft ofrece un acuerdo de nivel de servicio (SLA) líder del sector para Azure Front Door. Incluso si un proveedor ofrece un SLA (Acuerdo de Nivel de Servicio) con una disponibilidad del 100%, esto no garantiza que no haya tiempo de inactividad. Los Acuerdos de Nivel de Servicio suelen proporcionar créditos de servicio en caso de interrupción.

Si los requisitos empresariales exigen un Objetivo de Nivel de Servicio (SLO) compuesto mayor o cero tiempo de inactividad en caso de interrupción, debe confiar en varias rutas de ingreso de tráfico alternativas. Muchas organizaciones grandes y propiedades web de alto perfil usan este enfoque para garantizar la mayor disponibilidad posible y optimizar el rendimiento de la entrega. Sin embargo, perseguir un SLO más alto implica costos significativos, sobrecarga operativa y puede reducir la confiabilidad general de manera inadvertida. Tenga en cuenta cuidadosamente los inconvenientes y los posibles problemas que la ruta alternativa podría introducir 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.

Un enfoque consiste en definir una ruta de acceso secundaria, con servicios alternativos, que se convierte en la ruta de acceso principal cuando Azure Front Door no está disponible. La paridad de características con Azure Front Door no debe tratarse como requisito estricto. Dé prioridad a las características que realmente necesite a efectos de continuidad empresarial, incluso ante una posible ejecución en una capacidad limitada.

Existen varias estrategias para lograr una alta disponibilidad en las cargas de trabajo web. El enfoque detallado aquí ofrece una solución sencilla y manual de emergencia que le permite conmutar rápidamente durante una interrupción y restaurar el tráfico sin interrupciones a Azure Front Door una vez confirmado el estado del servicio.

En este artículo se describen algunas estrategias para el enrutamiento global mediante Azure Traffic Manager para dirigir el tráfico a un enrutador alternativo en 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.

Diagrama que muestra cómo Traffic Manager dirige las solicitudes a Azure Front Door o a otro servicio y, a continuación, al servidor de origen.

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. Para una arquitectura crítica, se recomienda usar el método de enrutamiento ponderado , que se puede configurar fácilmente para enviar parte o todo el tráfico a diferentes puntos de conexión. Normalmente, en operaciones normales, 100% del tráfico se dirige a través de Azure Front Door.

    Se recomienda deshabilitar la supervisión de puntos de conexión de Traffic Manager. Debe tener procedimientos para detectar cuándo la ruta de tráfico principal no está disponible y para responder mediante el reencaminamiento del tráfico hacia la ruta secundaria.

    También puede considerar el uso de un sistema de enrutamiento de tráfico global diferente. No obstante, Traffic Manager funciona bien en muchas situaciones.

  2. Hay dos rutas de acceso:

    • Azure Front Door proporciona la ruta de acceso principal. En las operaciones normales, procesa y enruta todo o la mayoría del tráfico de la aplicación.

    • Se usa otro enrutador como copia de seguridad de Azure Front Door. El tráfico 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 siempre que sea posible, para evitar agregar complejidad operativa adicional a 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 Azure 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.

Contrapartidas

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 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 con un Acuerdo de Nivel de Servicio líder del sector, pero la administración del tráfico necesita medidas adicionales para proporcionar 100% disponibilidad. 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 comprender las funcionalidades y características de Azure Front Door que usted utiliza y de las cuales depende si va a usar otro servicio. 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 un 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, esto no es una buena práctica de seguridad y no se recomienda.

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.

Consideraciones adicionales para la alta disponibilidad

Al diseñar una arquitectura web crítica, hay muchos factores que pueden afectar a la disponibilidad y el rendimiento de la aplicación. Muchos de estos factores van más allá de la configuración y las funcionalidades de Azure Front Door, y en su lugar se relacionan con el ecosistema general y el diseño de soluciones.

Nombres de dominio y DNS

La aplicación crítica debe usar nombres de dominio personalizados para controlar cómo fluye el tráfico a la aplicación y reducir las dependencias de un único proveedor. Tenga en cuenta los siguientes puntos al planear el enfoque dns:

  • Servicio DNS: Se recomienda 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.

  • Solucionadores DNS: Se recomienda usar varios solucionadores DNS para aumentar la resistencia general aún más.

  • Dominios raíz: Use un CNAME para apuntar su nombre de dominio a su nombre de dominio de Traffic Manager. Los estándares DNS no permiten crear un CNAME en el vértice (o raíz) de un dominio. Se recomienda hospedar el dominio DNS en Azure DNS y usar registros de alias para que apunten a su perfil de Traffic Manager.

  • Encadenamiento 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 CNAME. Por ejemplo, al configurar su dominio personalizado, puede ver cinco o más registros CNAME antes de que se devuelva la 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. Se reduce el número de posibles problemas con esta arquitectura compleja.

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, puede haber 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.

Sin embargo, hay operaciones adicionales relacionadas con la renovación y actualización de los certificados antes de que expiren.

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. Azure Front Door solo responde al tráfico HTTP válido, lo que también ayuda a reducir la exposición a muchas amenazas basadas en protocolos. Si cambia su arquitectura para permitir rutas de ingreso alternativas, debe evaluar si ha aumentado accidentalmente la exposición a amenazas de su origen.

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 su origen utiliza la etiqueta de servicio de Azure Front Door y el encabezado X-Azure-FDID para validar que el tráfico ha fluido a través de Azure Front Door, considere cómo sus orígenes pueden reconfigurarse para validar que el tráfico ha fluido a través de cualquiera de sus caminos válidos. 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 el aprovisionamiento de direcciones IP públicas dedicadas es necesario para la ruta de tráfico alternativa. 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, considere si debe implementar Azure DDoS Protection para reducir el riesgo de ataques de denegación de servicio contra sus orígenes. Además, tenga 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 salud

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 ejecuta en un estado degradado.

** Incluya estas preguntas en el diseño del modelo de salud.

  • ¿Cómo supervisan los distintos componentes de la solución el estado de los componentes descendentes?
  • ¿Cuándo deberían los monitores de salud considerar que los componentes descendentes no son saludables?
  • ¿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?

Monitoreo de la salud

Hay varias soluciones de equilibrio de carga globales que permiten cambiar a una plataforma secundaria si se produce una interrupción. Azure Traffic Manager es adecuado en la mayoría de los casos.

Al usar Traffic Manager con Azure Front Door, debe tener su propia solución de supervisión de terceros o personalizada para detectar cuándo Azure Front Door no está disponible e iniciar los procesos de respuesta. Dado que Azure Front Door es un sistema distribuido globalmente que usa redes anycast, es importante realizar comprobaciones de conectividad desde las mismas regiones geográficas que sus clientes.

Importante

En el caso de las cargas de trabajo globales que requieren validación de estado desde varias zonas geográficas, se recomienda deshabilitar la supervisión de puntos de conexión de Traffic Manager y, en su lugar, usar procedimientos manuales de conmutación por error.

También debe estar preparado para desencadenar los procedimientos de respuesta manualmente si los sistemas de supervisión no lo detectan.

Procedimientos de respuesta

Si los sistemas de supervisión detectan que Azure Front Door no está disponible, debe volver a configurar Traffic Manager para dirigir todo el tráfico a través de la ruta de acceso alternativa mediante uno de estos enfoques:

Importante

Redirigir todo el tráfico a través de la ruta de acceso secundaria es una solución a corto plazo que permite la continuidad empresarial durante una interrupción continua. Una vez resuelta la interrupción, restaure las operaciones normales a través de Azure Front Door tan pronto como sea posible.

Varios factores influyen en la cantidad de tiempo que la interrupción afecta al tráfico, entre los que se incluyen:

  • Período de vida (TTL) de los registros DNS.
  • Qué sistema de supervisión (Traffic Manager o su propia supervisión personalizada) detecta primero la interrupción.
  • Frecuencia con la que se ejecutan comprobaciones de estado.
  • ¿Cuántas comprobaciones de estado con errores deben registrarse 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 manuales se consideran demasiado lentos para que la aplicación siga respondiendo.

Consulte: Área de diseño de misión crítica: modelado de salud

Procesos de reconfiguración resilientes

Cuando planee cómo operar una solución con una ruta de acceso de entrada redundante, también debe planear cómo implementar o configurar los servicios cuando se degradan. 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.

Cuando planifique su estrategia de conmutación por error, no dependa de una sola herramienta como el portal de Azure en caso de que se interrumpa la conectividad. Obtenga información sobre cómo usar herramientas como la CLI de Azure, Azure PowerShell o las API REST para realizar los pasos de reconfiguración, como redirigir el tráfico. Para ver comandos de ejemplo que puede incluir en guiones de conmutación por error, consulte Procedimientos de respuesta.

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 soportan el nivel de tráfico de producción que espera recibir? ¿Está el camino secundario listo para recibir tráfico de producción con advertencia mínima o ninguna?
  • ¿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.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autores principales:

  • Dave Burkhardt | Administrador de programas principal, Azure Front Door
  • John Downs | Ingeniero principal de software, Patrones y prácticas de Azure
  • Akhil Karmalkar | Administrador de programas principal, Azure Front Door
  • Priyanka Wilkins | Desarrollador principal de contenido, patrones y prácticas de Azure

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Revise los artículos siguientes de esta serie para obtener instrucciones específicas sobre estos escenarios:

Ingreso HTTP global de misión crítica

Entrega de contenido global de misión crítica

  • Last updated on