Enfoques de aplicaciones de App Service de varias regiones para la recuperación ante desastres
Al implementar una aplicación web de App de Azure Service en una sola región que, debido a un desastre o una interrupción, deja de estar disponible, se corre el riesgo de que la aplicación deje de estar disponible. Para asegurarse de que la aplicación sigue estando disponible cuando la región no está disponible, puede implementar una arquitectura de varias regiones. Con una arquitectura de varias regiones, se crea una implementación idéntica en una región secundaria de Azure. Con una implementación de región secundaria, puede replicar los datos para recuperar el último estado de la aplicación; y también pueden replicar otros componentes de la solución.
En este artículo se describen tres enfoques arquitectónicos de varias regiones que se usan habitualmente para App Service y App Service Environment.
Enfoques a tener en cuenta
Los planes de continuidad empresarial están influenciados por dos métricas clave:
- Objetivo de tiempo de recuperación (RTO), que es el tiempo de inactividad tolerable máximo durante un desastre.
- Objetivo de punto de recuperación (RPO), que es la pérdida máxima tolerable de datos durante un desastre.
Para obtener más información sobre los objetivos de recuperación, como RTO y RPO, consulte Objetivos de recuperación y Recomendaciones para definir objetivos de confiabilidad.
Con la plataforma Azure, puede diseñar soluciones de aplicaciones de varias regiones de diferentes maneras. En este artículo se describen las arquitecturas que admiten diferentes requisitos de RTO y RPO, y que tienen otros inconvenientes para el costo y la complejidad:
| Métrica | Activo-activo | Activo-pasivo | Pasivo/frío |
|---|---|---|---|
| RTO | Tiempo real o segundos | Minutos | Horas |
| RPO | Tiempo real o segundos | Minutos | Horas |
| Coste | $$$ | $$ | $ |
| Escenarios | Aplicaciones críticas | Aplicaciones de alta prioridad | Aplicaciones de baja prioridad |
| Capacidad de atender el tráfico de usuarios de varias regiones | Sí | No | No |
| Implementación de código | Canalizaciones de CI/CD preferidas | Canalizaciones de CI/CD preferidas | Copia de seguridad y restauración |
| Creación de nuevos recursos de App Service durante el tiempo de inactividad | No se requiere | No se requiere | Obligatorio |
Aunque los tres enfoques descritos aquí son comunes, no son la única manera de lograr una solución de varias regiones en Azure. Adapte las soluciones para satisfacer sus propios requisitos.
Nota:
La aplicación probablemente depende de otros servicios de Azure, como Azure SQL Database, cuentas de Azure Storage y colas de mensajes. Al diseñar una estrategia de recuperación ante desastres, también debe tener en cuenta cada uno de estos servicios de Azure dependientes.
Para más información sobre las soluciones de varias regiones para los servicios de Azure, consulte Guías de confiabilidad de servicios de Azure.
Supervisión
Es importante configurar la supervisión y las alertas de las aplicaciones web para que el equipo reciba notificaciones oportunas durante un error de región. App de Azure lication Insights, las pruebas de disponibilidad proporcionan una manera de supervisar la disponibilidad de una aplicación. Para más información, consulte Pruebas de disponibilidad de Application Insights.
Implementación
Las soluciones de varias regiones pueden ser complejas para implementar y configurar. Es importante que las instancias de cada región se mantengan sincronizadas.
Para administrar la implementación y configuración de recursos de Azure como App Service, use un mecanismo de infraestructura como código (IaC). En una implementación compleja en varias regiones, administrar las regiones de forma independiente y mantener la configuración sincronizada entre regiones de forma fiable requiere un proceso predecible, comprobable y repetible. Considere una herramienta iaC, como Bicep, plantillas de Azure Resource Manager o Terraform.
También debe configurar las canalizaciones de CI/CD para implementar el código, incluido cuando se usan varias regiones. Considere la posibilidad de usar Azure Pipelines o Acciones de GitHub. Para más información, consulte Implementación continua en Azure App Service.
Arquitectura activa-activa
En una arquitectura activa-activa, las aplicaciones web idénticas se implementan en dos regiones independientes. Azure Front Door se usa para enrutar el tráfico a ambas regiones activas:
Las aplicaciones de App Service de cada región usan la misma configuración, incluido el plan de tarifa y el recuento de instancias.
Durante las operaciones normales, se bloquea el tráfico público directo a la aplicación de App Service. En su lugar, el tráfico se enruta a través de Azure Front Door a ambas regiones activas. Este enfoque le ayuda a garantizar que el firewall de aplicaciones web (WAF) de Azure Front Door inspeccione las solicitudes, o que de lo contrario estén protegidas o administradas de forma centralizada.
Durante un error de región, si una de las regiones se queda sin conexión, los sondeos de estado de Azure Front Door detectan el origen defectuoso y vuelven a configurar las rutas para que el tráfico se envíe exclusivamente a la región que permanece en línea.
Durante una recuperación de regiones erróneas (conmutación por recuperación), los sondeos de estado de Azure Front Door detectan el origen correcto y restauran el enrutamiento de tráfico normal.
Recomendaciones
Para cumplir un RPO de cero para el contenido de la aplicación, use una solución de CI/CD para implementar archivos de aplicación en ambas aplicaciones web.
Siempre que sea posible, almacene el estado de la aplicación fuera del sistema de archivos de App Service, como en una base de datos o Azure Storage. Configure esos componentes para cumplir los requisitos de redundancia geográfica.
Sugerencia
Si la aplicación modifica activamente el sistema de archivos y la región de la aplicación de App Service tiene una región emparejada, puede reducir el RPO del sistema de archivos escribiendo en un recurso compartido de Azure Storage montado en lugar de escribir directamente en el recurso compartido de contenido /home de la aplicación web. A continuación, use las características de redundancia de Azure Storage (GZRS o GRS) para el recurso compartido montado, que tiene un RPO de unos 15 minutos.
Consideraciones
RTO bajo: el RTO durante una conmutación por error geográfica depende de la rapidz en que los sondeos de estado detecten la región defectuosa. De forma predeterminada, los sondeos comprueban cada 30 segundos, pero puede configurar una frecuencia de sondeo diferente.
Equilibrio de carga y conmutación por error: este enfoque usa Azure Front Door para el equilibrio de carga global, la distribución del tráfico y la conmutación por error. Azure proporciona otras opciones de equilibrio de carga, como Azure Traffic Manager. Para ver una comparación de las distintas opciones, consulte Opciones de equilibrio de carga: Centro de arquitectura de Azure.
Implementación de aplicaciones web de App Service activas y activas
Siga estos pasos para crear un enfoque activo-activo para las aplicaciones web mediante App Service:
Cree dos planes de App Service en dos regiones de Azure diferentes. Configure de forma idéntica los dos planes de App Service.
Cree dos instancias de la aplicación web, con una en cada plan de App Service.
Cree un perfil de Azure Front Door con:
- Extremo.
- Un grupo de origen con dos orígenes, cada uno con una prioridad de 1. Los valores de prioridad igual indican a Azure Front Door que enrute el tráfico a las aplicaciones de ambas regiones igualmente (activo-activo).
- Una ruta.
Limite el tráfico de red a las aplicaciones web solo desde la instancia de Azure Front Door.
Configure y configure el resto del servicio de Azure back-end, como bases de datos, cuentas de almacenamiento y proveedores de autenticación.
Implemente código en ambas aplicaciones web con implementación continua.
En el tutorial Creación de una aplicación de varias regiones de alta disponibilidad en App de Azure Service se muestra cómo configurar una arquitectura activa-pasiva. Para implementar un enfoque activo-activo, siga los mismos pasos, pero con una excepción: en Azure Front Door, configure ambos orígenes en el grupo de origen para que tengan una prioridad de 1.
Arquitectura activa-pasiva
En una arquitectura activa-pasiva, las aplicaciones web idénticas se implementan en dos regiones independientes. Azure Front Door se usa para enrutar el tráfico solo a una región (la región activa ).
Durante las operaciones normales, Azure Front Door solo enruta el tráfico a la región primaria. El tráfico público que va directamente a las aplicaciones de App Service se bloquea.
Durante un error de región, si la región primaria deja de estar inactiva, los sondeos de estado de Azure Front Door detectan el origen defectuoso y comienzan el enrutamiento del tráfico al origen de la región secundaria. A continuación, la región secundaria se convierte en la región activa. Una vez activa la región secundaria, la carga de red desencadena reglas de escalabilidad automática preconfiguradas para escalar horizontalmente la aplicación web secundaria.
Durante una recuperación de regiones erróneas (conmutación por recuperación), Azure Front Door dirige automáticamente el tráfico a la región primaria y la arquitectura vuelve a ser activa-pasiva como antes.
Nota:
Es posible que tenga que escalar verticalmente el plan de tarifa de la región secundaria manualmente, si aún no tiene las características necesarias para ejecutarse como la región activa. Por ejemplo, la escalabilidad automática requiere el nivel estándar o superior.
Recomendaciones
Para cumplir un RPO de cero para el contenido de la aplicación, use una solución de CI/CD para implementar archivos de aplicación en ambas aplicaciones web.
Siempre que sea posible, almacene el estado de la aplicación fuera del sistema de archivos de App Service, como en una base de datos o Azure Storage. Configure esos componentes para cumplir los requisitos de redundancia geográfica.
Sugerencia
Si la aplicación modifica activamente el sistema de archivos y la región de la aplicación de App Service tiene una región emparejada, puede reducir el RPO del sistema de archivos escribiendo en un recurso compartido de Azure Storage montado en lugar de escribir directamente en el recurso compartido de contenido /home de la aplicación web. A continuación, use las características de redundancia de Azure Storage (GZRS o GRS) para el recurso compartido montado, que tiene un RPO de unos 15 minutos.
Consideraciones
Controles de costos: las aplicaciones idénticas de App Service se implementan en dos regiones independientes. Para ahorrar costos, el plan de App Service secundario está configurado para tener menos instancias o estar en un plan de tarifa inferior. Hay tres enfoques posibles:
Preferido: el plan secundario de App Service tiene el mismo plan de tarifa que el principal, con el mismo número de instancias o menos. Este enfoque garantiza la paridad tanto en la característica como en el ajuste de tamaño de las máquinas virtuales para los dos planes de App Service. El RTO durante una conmutación por error geográfica solo depende del tiempo para escalar horizontalmente las instancias.
Menos preferido: el plan secundario de App Service tiene el mismo tipo de plan de tarifa (por ejemplo, PremiumV3), pero el tamaño de máquina virtual más pequeño, con instancias menores. Por ejemplo, la región primaria puede estar en el nivel P3V3 mientras que la región secundaria está en el nivel P1V3. Este enfoque sigue garantizando la paridad de características para los dos planes de App Service, pero la falta de paridad en el tamaño puede requerir un escalado vertical manual cuando la región secundaria se convierta en la región activa. El RTO durante una conmutación por error geográfica depende del tiempo para escalar verticalmente y horizontalmente las instancias.
Menos preferido: el plan secundario de App Service tiene un plan de tarifa diferente al de las instancias principales y menores. Por ejemplo, la región primaria puede estar en el nivel P3V3 mientras que la región secundaria está en el nivel S1. Asegúrese de que el plan de App Service secundario tenga todas las características que necesita la aplicación para poder ejecutarse. Las diferencias en la disponibilidad de características entre los dos pueden provocar retrasos en la recuperación de la aplicación web. El RTO durante una conmutación por error geográfica depende del tiempo para escalar verticalmente y horizontalmente las instancias.
El escalado automático debe configurarse en la región secundaria en caso de que se redirija el tráfico y haya una entrada repentina de solicitudes. Es aconsejable tener reglas de escalabilidad automática similares en regiones activas y pasivas.
Equilibrio de carga y conmutación por error: este enfoque usa Azure Front Door para el equilibrio de carga global, la distribución del tráfico y la conmutación por error. Azure proporciona otras opciones de equilibrio de carga, como Azure Traffic Manager. Para ver una comparación de las distintas opciones, consulte Opciones de equilibrio de carga: Centro de arquitectura de Azure.
Implementación de aplicaciones web de App Service activas y pasivas
Siga estos pasos para crear un enfoque activo-pasivo para las aplicaciones web mediante App Service:
Cree dos planes de App Service en dos regiones de Azure diferentes. El plan de App Service secundario se puede aprovisionar mediante uno de los enfoques mencionados anteriormente.
Configure reglas de escalabilidad automática para el plan de App Service secundario para que se escale al mismo recuento de instancias que el principal cuando la región primaria se vuelva inactiva.
Cree dos instancias de la aplicación web, con una en cada plan de App Service.
Cree un perfil de Azure Front Door con:
Extremo.
Un grupo de origen con dos orígenes:
- Origen con una prioridad de 1 para la aplicación en la región primaria.
- Un segundo origen con una prioridad de 2 para la aplicación en la región secundaria.
La diferencia de prioridad indica a Azure Front Door que prefiera la región primaria cuando esté en línea (por lo tanto, activa-pasiva).
Una ruta.
Limite el tráfico de red a las aplicaciones web solo desde la instancia de Azure Front Door.
Configure y configure el resto del servicio de Azure back-end, como bases de datos, cuentas de almacenamiento y proveedores de autenticación.
Implemente código en ambas aplicaciones web con implementación continua.
En Tutorial: Creación de una aplicación de varias regiones de alta disponibilidad en Azure App Service se muestra cómo configurar una arquitectura activa-pasiva.
Arquitectura pasiva de acceso esporádico
En una arquitectura pasiva o inactiva, la aplicación web se implementa en una sola región primaria. Los archivos de aplicación y algunas bases de datos se realizan copias de seguridad en una cuenta de Azure Storage. Las copias de seguridad se replican en otra región. Si la región primaria no está disponible, implementará manualmente otra aplicación en una segunda región y restaurará desde la copia de seguridad.
Nota:
Los enfoques de frío pasivo dependen de la intervención manual durante una región falure y, a menudo, producen un tiempo de inactividad significativo y una pérdida de datos. Para la mayoría de las soluciones de nivel de producción, debe considerar una solución activa-activa o activa-pasiva.
Replicación entre regiones
Este enfoque usa la copia de seguridad de App Service para realizar copias de seguridad periódicas de la aplicación web en una cuenta de Azure Storage en la misma región. Configure la replicación entre regiones de las copias de seguridad mediante la configuración de la cuenta de almacenamiento.
El enfoque que se usa para configurar la replicación entre regiones depende de si la región tiene un par. Para más información, consulte Regiones emparejadas de Azure con zonas de disponibilidad y sin par de regiones.
Use la replicación RA-GZRS , si está disponible. RA-GZRS ofrece redundancia de zona sincrónica dentro de una región y asincrónica en una región secundaria. También proporciona acceso de solo lectura dentro de la región secundaria, lo que es esencial para asegurarse de que puede recuperar copias de seguridad cuando la región primaria de la cuenta de almacenamiento deja de estar disponible.
Si RA-GZRS no está disponible, configure la cuenta como RA-GRS.
Ra-GZRS y RA-GRS tienen un RPO de unos 15 minutos.
Para obtener más información sobre cómo diseñar las aplicaciones para aprovechar el almacenamiento con redundancia geográfica, consulte Uso de redundancia geográfica para diseñar aplicaciones de alta disponibilidad.
Experiencia de región descendente
Si la región primaria no está disponible, debe detectar la pérdida de región. Para más información, consulte Supervisión.
Para preparar la región secundaria para recibir tráfico, implemente todos los recursos necesarios de App Service y los recursos dependientes mediante las copias de seguridad de la cuenta de Azure Storage en la región secundaria.
Consideraciones
RTO alto: dado que este proceso requiere detección y respuesta manuales, el RTO para este escenario podría ser horas o incluso días. Para minimizar el RTO, compile y pruebe un cuaderno de estrategias completo que describa todos los pasos necesarios para restaurar la copia de seguridad de la aplicación web en otra región de Azure.
Incluso después de crear la aplicación en la región secundaria, es posible que tenga que tratar con complejidades como registros DNS y certificados TLS. Asegúrese de que ha planeado cada paso necesario para enviar tráfico a la región secundaria y probar los planes con regularidad.
RPO elevado: las copias de seguridad se pueden programar hasta una vez por hora. Si la aplicación principal se queda sin conexión, es posible que la copia de seguridad que restaure en una región secundaria esté obsoleta. El RPO depende de la frecuencia de las copias de seguridad, así como de la rapidez con la que se replican esas copias de seguridad entre regiones.
Pasos de procedimientos
Los pasos que se usan para configurar una implementación pasiva en frío dependen de si la región tiene un par. Para más información, consulte Regiones emparejadas de Azure con zonas de disponibilidad y sin par de regiones.
Los pasos para crear una región inactiva pasiva para la aplicación web en App Service son los siguientes:
Cree una cuenta de almacenamiento de Azure en la misma región que la aplicación web. Elija Nivel de rendimiento estándar y seleccione redundancia como almacenamiento con redundancia geográfica (GRS) o almacenamiento con redundancia de zona geográfica (GZRS).
Habilite RA-GRS o RA-GZRS (acceso de lectura para la región secundaria).
Configure la copia de seguridad personalizada para la aplicación web. Puede decidir establecer una programación para las copias de seguridad de la aplicación web, como por ejemplo, cada hora.
Compruebe que los archivos de copia de seguridad de la aplicación web se pueden recuperar en la región secundaria de la cuenta de almacenamiento.
Pasos siguientes
Revise las arquitecturas de referencia del servicio App de Azure:
- Para obtener una aplicación con redundancia de zona de una sola región, consulte Aplicación web con redundancia de zona de alta disponibilidad de línea base.
- Para obtener una aplicación multiregión activa/pasiva, consulte Aplicación web de varias regiones de alta disponibilidad.