Confiabilidad en Azure App Service
En este artículo se describe la compatibilidad con la confiabilidad de Azure App Service, y se trata tanto la resiliencia intrarregional con zonas de disponibilidad como la recuperación ante desastres y la continuidad del negocio entre regiones. Para obtener información general más detallada sobre los principios de confiabilidad de Azure, consulte Confiabilidad de Azure.
Azure App Service es un servicio basado en HTTP para hospedar aplicaciones web, API de REST y back-end móviles; y agrega la eficacia de Microsoft Azure a la aplicación, como:
- Seguridad
- Equilibrio de carga
- Escalado automático
- Administración automatizada
Para explorar la manera en que Azure App Service puede aumentar la confiabilidad y la resistencia de la carga de trabajo de una aplicación, consulte ¿Por qué usar App Service?
Recomendaciones sobre la confiabilidad
Esta sección contiene recomendaciones para lograr la resistencia y la disponibilidad. Cada recomendación se divide en una de las dos categorías:
Los elementos de mantenimiento abarcan áreas como los elementos de configuración y el funcionamiento correcto de los principales componentes que se encargan de su carga de trabajo de Azure, como la configuración de recursos de Azure, dependencias de otros servicios, etc.
Los elementos de riesgo abarcan áreas como los requisitos de disponibilidad y recuperación, pruebas, supervisión, implementación y otros elementos que, si se dejan sin resolver, aumentarán la probabilidad de que surjan problemas en el entorno.
Matriz de prioridad de recomendaciones de fiabilidad
Cada recomendación se marca según la siguiente matriz de prioridad:
| Imagen | Prioridad | Descripción |
|---|---|---|
|
Alto | Se necesita corrección inmediata. |
|
Media | Corregir en un plazo de entre 3 y 6 meses. |
|
Bajo | Necesita revisión. |
Resumen de recomendaciones de fiabilidad
Alta disponibilidad
ASP-1: Implementación de planes de App Service con redundancia de zona
Para mejorar la resistencia y la confiabilidad de las cargas de trabajo críticas para la empresa, se recomienda implementar los nuevos planes de App Service con redundancia de zona. Siga los pasos para volver a implementar la compatibilidad con la zona de disponibilidad, configure las canalizaciones para volver a implementar la aplicación web en el nuevo plan de App Services y, a continuación, use un enfoque de implementación azul-verde para la conmutación por error en el nuevo sitio.
Al distribuir las aplicaciones en varias zonas de disponibilidad, puede garantizar su operación continua incluso en caso de un error de nivel de centro de datos. Para obtener más información sobre la compatibilidad con zonas de disponibilidad en Azure App Service, consulte Compatibilidad con zonas de disponibilidad.
// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
// Its important to check regions that support availability zones for Azure App Services running on multi-tenant and App Service Environments https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service?tabs=graph%2Ccli#:~:text=The%20following%20regions%20support%20Azure%20App%20Services%20running%20on%20multi%2Dtenant%20environments%3A
resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where (tolower(sku_tier) contains "isolated" or tolower(sku_tier) contains "premium") and zoneRedundant == false
| project recommendationid="asp-1", name, id, tags, param1=sku_tier, param2="Not Zone Redundant"
Resistencia
ASP-2: Uso de un plan de App Service que admite zonas de disponibilidad
La compatibilidad con zonas de disponibilidad solo está disponible en determinados planes de App Service. Para ver qué plan necesita para usar zonas de disponibilidad, consulte Requisitos previos de la zona de disponibilidad.
// Azure Resource Graph Query
// Provides a list of Azure App Service Plans that are not in the "Standard", "Premium", or "IsolatedV2" SKU tiers.
resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where tolower(sku_tier) !contains "standard" and
tolower(sku_tier) !contains "premium" and
tolower(sku_tier) !contains "isolatedv2"
| project recommendationid="asp-2", name, id, tags, param1= strcat("SKU=",sku_tier)
ASP-4: Creación de planes de App Service independientes para producción y prueba
Para mejorar la resistencia y la confiabilidad de las cargas de trabajo críticas para la empresa, debe migrar los planes de App Service existentes y los entornos de App Service a la compatibilidad con zonas de disponibilidad. Al distribuir las aplicaciones en varias zonas de disponibilidad, puede garantizar su operación continua incluso en caso de un error de nivel de centro de datos. Para obtener más información sobre la compatibilidad con zonas de disponibilidad en Azure App Service, consulte Compatibilidad con zonas de disponibilidad.
Escalabilidad
ASP-3: Evitar el escalado o la reducción vertical con frecuencia
Se recomienda evitar el escalado o la reducción vertical de las instancias de Azure App Service con frecuencia. En su lugar, elija un nivel y un tamaño de instancia adecuados que puedan controlar la carga de trabajo típica y escale horizontalmente las instancias para dar cabida a los cambios en el volumen de tráfico. El escalado o la reducción vertical puede desencadenar un reinicio de la aplicación, lo que puede provocar interrupciones del servicio.
ASP-5: Habilitación de la escalabilidad automática/el escalado automático para asegurarse de que los recursos adecuados estén disponibles para las solicitudes de servicio
Se recomienda habilitar la escalabilidad automática o el escalado automático para la instancia de Azure App Service para asegurarse de que haya suficientes recursos disponibles para controlar las solicitudes entrantes. La escalabilidad automática es el escalado basado en reglas, mientras que el escalado automático realiza el escalado automático en función del tráfico HTTP. Para obtener más información, consulte Escalado automático en Azure App Service o introducción a la escalabilidad automática en Azure.
// under-development
Compatibilidad de zonas de disponibilidad
Las zonas de disponibilidad de Azure son al menos tres grupos de centros de datos físicamente independientes dentro de cada región de Azure. Los centros de datos de cada zona están equipados con infraestructura de alimentación, refrigeración y red independientes. En el caso de un error en la zona local, las zonas de disponibilidad están diseñadas de manera que, si se ve afectada una zona, los servicios, la capacidad y la alta disponibilidad regionales serán proporcionadas por las dos zonas restantes.
Estos errores pueden abarcar desde errores de software y hardware hasta eventos como terremotos, inundaciones e incendios. La tolerancia a los errores se logra con la redundancia y el aislamiento lógico de los servicios de Azure. Para más información sobre las zonas de disponibilidad en Azure, consulte Regiones y zonas de disponibilidad.
Los servicios habilitados para zonas de disponibilidad de Azure están diseñados para proporcionar el nivel adecuado de confiabilidad y flexibilidad. Se pueden configurar de dos maneras. Pueden tener redundancia de zona, con una replicación automática entre zonas o ser zonales, con instancias ancladas a una zona específica. También puede combinar ambos enfoques. Para obtener más información sobre la arquitectura zonal frente a la arquitectura con redundancia de zona, consulte Recomendaciones para el uso de zonas de disponibilidad y regiones.
Azure App Service se puede implementar en zonas de disponibilidad (AZ) para poder lograr resistencia y confiabilidad en las cargas de trabajo críticas para la empresa. Esta arquitectura también se conoce como redundancia de zona.
Al configurar App Service para que tenga redundancia de zona, la plataforma propaga automáticamente las instancias del plan de Azure App Service entre las tres zonas de la región seleccionada.
La propagación de instancias con una implementación con redundancia de zona se determina dentro de las reglas siguientes, incluso cuando la aplicación se escala y se reduce horizontalmente:
- El recuento mínimo de instancias del plan de App Service es tres.
- Si se especifica una capacidad superior a tres y el número de instancias es divisible entre tres, las instancias se distribuyen de manera uniforme.
- Cualquier recuento de instancias más allá de 3*N se distribuye entre las dos zonas restantes.
El soporte de la zona de disponibilidad es una propiedad del plan de App Service. Los planes de App Service se pueden crear en un entorno multiinquilino administrado o en un entorno dedicado mediante App Service Environment v3. Para obtener más información sobre App Service Environment v3, consulte Introducción a App Service Environment v3.
En el caso de App Services que no están configurados para que sean redundantes de zona, las instancias de máquina virtual no son resistentes a la zona y pueden experimentar tiempo de inactividad durante una interrupción en cualquier zona de esa región.
Para obtener información sobre la arquitectura de implementación empresarial, consulte Implementación empresarial de alta disponibilidad mediante App Service Environment.
Requisitos previos
Los requisitos y limitaciones actuales para habilitar zonas de disponibilidad son:
Se admite Windows y Linux.
Las zonas de disponibilidad solo se admiten en la superficie más reciente de App Service. Incluso si usa una de las regiones admitidas, recibirá un error si no se admiten zonas de disponibilidad para el grupo de recursos. Para asegurarse de que las cargas de trabajo se encuentren en una unidad de escalado que admita zonas de disponibilidad, es posible que tenga que crear un nuevo grupo de recursos, un plan de App Service y App Service.
El plan de App Services debe ser uno de los siguientes planes que admiten zonas de disponibilidad:
- En un entorno multiinquilino mediante planes de App Service Premium v2 o Premium v3.
- En un entorno dedicado mediante App Service Environment v3, que se usa con planes de App Service aislados v2.
Para entornos dedicados, el App Service Environment debe ser v3.
Importante
App Service Environment v2 y v1 se retirarán el 31 de agosto de 2024. App Service Environment v3 resulta más fácil de usar y se ejecuta en una infraestructura más eficaz. Para obtener más información sobre App Service Environment v3, vea Introducción a App Service Environment. Si actualmente usa App Service Environment v2, o v1 y quiere actualizar a v3 siga los pasos descritos en este artículo para migrar a la nueva versión.
Se aplica un recuento instancias mínimo de tres zonas. La plataforma aplicará este recuento mínimo en segundo plano si especifica un recuento de instancias inferior a tres.
Las zonas de disponibilidad solo se pueden especificar al crear un nuevo plan de App Service. Un plan de App Service existente no se puede convertir para que use zonas de disponibilidad.
Las siguientes regiones admiten Azure App Services que se ejecutan en entornos multiinquilino:
- Este de Australia
- Sur de Brasil
- Centro de Canadá
- Centro de la India
- Centro de EE. UU.
- Este de Asia
- Este de EE. UU.
- Este de EE. UU. 2
- Centro de Francia
- Centro-oeste de Alemania
- Japón Oriental
- Centro de Corea del Sur
- Norte de Europa
- Este de Noruega
- Centro de Polonia
- Centro de Catar
- Norte de Sudáfrica
- Centro-sur de EE. UU.
- Sudeste de Asia
- Centro de Suecia
- Norte de Suiza
- Norte de Emiratos Árabes Unidos
- Sur de Reino Unido
- Oeste de Europa
- Oeste de EE. UU. 2
- Oeste de EE. UU. 3
- Microsoft Azure operado por 21Vianet: Norte de China 3
- Azure Government: US Gov Virginia
Para ver qué regiones son compatibles con las zonas de disponibilidad de App Service Environment v3, consulta Regiones.
Creación de un recurso con la zona de disponibilidad habilitada
Para implementar un App Service con redundancia de zona multiinquilino
Para habilitar la disponibilidad de zonas mediante la CLI de Azure, incluya el parámetro --zone-redundant cuando cree el plan de App Service. También puede incluir el parámetro --number-of-workers para especificar la capacidad. Si no especifica una capacidad, el valor predeterminado de la plataforma es tres. La capacidad debe establecerse en función del requisito de carga de trabajo, pero no menos de tres. Una buena regla general para elegir la capacidad consiste en garantizar instancias suficientes para la aplicación, de modo que la pérdida de una zona de instancias deje capacidad suficiente para controlar la carga esperada.
az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6
Sugerencia
Para decidir la capacidad de la instancia, puede usar el cálculo siguiente:
Como la plataforma distribuye las máquinas virtuales entre tres zonas y debe tener en cuenta al menos el error de una de ellas, multiplique el número máximo de instancias de carga de trabajo por un factor de zonas/(zonas-1) o 3/2. Por ejemplo, si la carga de trabajo máxima típica necesita cuatro instancias, debería aprovisionar seis instancias: (2/3 * 6 instancias) = 4 instancias.
Implementación de un App Service con redundancia de zona mediante un entorno dedicado
Para obtener información sobre cómo crear un App Service Environment v3 en el plan v2 aislado, consulta Crear un entorno de servicio de aplicaciones.
Solucionar problemas
| Mensaje de error | Descripción | Recomendación |
|---|---|---|
| La redundancia de zona no está disponible para el grupo de recursos "RG-NAME". Implemente el plan de App Service "ASP-NAME" en un nuevo grupo de recursos. | Las zonas de disponibilidad solo se admiten en la superficie más reciente de App Service. Incluso si usa una de las regiones admitidas, recibirá un error si no se admiten zonas de disponibilidad para el grupo de recursos. | Para asegurarse de que las cargas de trabajo se encuentren en una unidad de escalado que admita zonas de disponibilidad, cree un nuevo grupo de recursos, un plan de App Service y App Service. |
Tolerancia a errores
Para prepararse para los errores de zona de disponibilidad, debe sobreaprovisionar la capacidad del servicio para asegurarse de que la solución puede tolerar la pérdida de capacidad 1/3 y seguir funcionando sin degradar el rendimiento durante interrupciones en toda la zona. Como la plataforma distribuye las máquinas virtuales entre tres zonas y debe tener en cuenta al menos el error de una de ellas, multiplique el número máximo de instancias de carga de trabajo por un factor de zonas/(zonas-1) o 3/2. Por ejemplo, si la carga de trabajo máxima típica necesita cuatro instancias, debería aprovisionar seis instancias: (2/3 * 6 instancias) = 4 instancias.
Experiencia a nivel de zona
El tráfico se enruta a todas las instancias de App Service disponibles. Si una zona está fuera de servicio, la plataforma App Service detectará las instancias perdidas e intentará encontrar automáticamente nuevas instancias de reemplazo y distribuir el tráfico según sea necesario. Si tiene configurada la escalabilidad automática y esta determina que se necesitan más instancias, emitirá una solicitud a App Service para que agregue más instancias. Tenga en cuenta que el comportamiento de escalado automático es independiente del comportamiento de la plataforma de App Service y que la especificación de recuento de instancias de escalado automático no necesita ser un múltiplo de tres.
Nota
No hay ninguna garantía de que las solicitudes de instancias adicionales en un escenario de zona descendente se realicen correctamente. El relleno de las instancias perdidas se produce de la mejor manera posible. La solución recomendada consiste en crear y configurar los planes de App Service para tener en cuenta la pérdida de una zona, tal como se describe en la siguiente sección.
Las aplicaciones implementadas en un plan de App Service con las zonas de disponibilidad habilitada seguirán ejecutándose y atenderán todo el tráfico, incluso cuando otras zonas de la misma región sufran una interrupción. Pero es posible que los comportamientos que no sean de tiempo de ejecución, incluidos el escalado del plan de App Service y la creación, configuración y publicación de aplicaciones, se puedan ver afectados por una interrupción en otras zonas de disponibilidad. La redundancia de zona para los planes de App Service solo garantiza un tiempo de actividad continuado para las aplicaciones implementadas.
Cuando la plataforma App Service asigna instancias a un plan de App Service con redundancia de zona, usa el mejor esfuerzo de equilibrio de zona que ofrece la instancia de Azure Virtual Machine Scale Sets subyacente. Un plan de App Service se "equilibrará" si cada zona tiene el mismo número de máquinas virtuales o +/- una máquina virtual en todas las demás zonas usadas por el plan de App Service.
Migración de zonas de disponibilidad
No se pueden migrar instancias de App Service existentes ni recursos de entorno de compatibilidad con zonas que no son de disponibilidad a compatibilidad con zonas de disponibilidad. Para obtener compatibilidad con zonas de disponibilidad, deberá crear recursos con las zonas de disponibilidad habilitadas.
Precios
No existen costes adicionales asociados a la habilitación de zonas de disponibilidad. Los precios de una instancia de App Service con redundancia de zona son los mismos que los de una instancia de App Service con una zona. Se le cobrará en función de la SKU del plan de App Service, la capacidad que especifique y las instancias a las que escale en función de los criterios de escalado automático. Si habilita la disponibilidad de zonas, pero especifica una capacidad inferior a tres, la plataforma aplicará un mínimo de tres instancias y le realizará un cargo por ellas. Para obtener información sobre los precios de App Service Environment v3, consulta Precios.
Recuperación ante desastres entre regiones y continuidad empresarial
La recuperación ante desastres (DR) consiste en recuperarse de eventos de alto impacto, como desastres naturales o implementaciones con errores, lo que produce tiempo de inactividad y pérdida de datos. Independientemente de la causa, el mejor remedio para un desastre es un plan de recuperación ante desastres bien definido y probado y un diseño de aplicaciones que apoye activamente la recuperación ante desastres. Antes de empezar a pensar en la creación del plan de recuperación ante desastres, vea Recomendaciones para diseñar una estrategia de recuperación ante desastres.
En lo que respecta a la recuperación ante desastres, Microsoft usa el modelo de responsabilidad compartida. En un modelo de responsabilidad compartida, Microsoft garantiza que la infraestructura de línea base y los servicios de plataforma estén disponibles. Al mismo tiempo, muchos servicios de Azure no replican automáticamente datos ni se revierten desde una región con errores para realizar la replicación cruzada en otra región habilitada. Para esos servicios, usted es el responsable de configurar un plan de recuperación ante desastres que funcione para la carga de trabajo. La mayoría de los servicios que se ejecutan en ofertas de plataforma como servicio (PaaS) de Azure proporcionan características e instrucciones para admitir la recuperación ante desastres y puede usar características específicas del servicio para admitir la recuperación rápida para ayudar a desarrollar el plan de recuperación ante desastres.
En esta sección se tratan algunas estrategias comunes para las aplicaciones web implementadas en App Service.
Cuando crea una aplicación web en App Service y elige una región de Azure durante la creación de recursos, se trata de una aplicación de una sola región. Cuando la región deja de estar disponible durante un desastre, la aplicación también deja de estar disponible. Si crea una implementación idéntica en una región secundaria de Azure mediante una arquitectura de geografía de varias regiones, la aplicación se vuelve menos susceptible a un desastre de una sola región, lo que garantiza la continuidad empresarial. Cualquier replicación de datos en las regiones le permite recuperar el último estado de la aplicación.
Para TI, los planes de continuidad empresarial se controlan en gran medida por el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Para obtener más información sobre RTO y RPO, consulte Objetivos de recuperación.
Normalmente, el mantenimiento de un Acuerdo de Nivel de Servicio en torno al RTO no es práctico para los desastres regionales y normalmente diseñaría la estrategia de recuperación ante desastres en torno al RPO por sí solo (es decir, centrarse en la recuperación de datos y no en minimizar la interrupción). Sin embargo, con Azure no solo es más práctico, sino que incluso puede ser más sencillo implementar App Service para las conmutaciones por error geográficas automáticas. Esto le permite realizar pruebas ante desastres de las aplicaciones con el cuidado de RTO y RPO.
En función de las métricas de RTO y RPO deseadas, se suelen usar tres arquitecturas de recuperación ante desastres para entornos multiinquilino de App Service y App Service. Cada arquitectura se describe en la siguiente tabla:
| Métrica | Activo-activo | Activo-pasivo | Pasiva o de acceso esporádico |
|---|---|---|---|
| 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í | Sí/tal vez | 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 |
Nota:
La aplicación probablemente depende de otros servicios de datos de Azure, como Azure SQL Database y las cuentas de Azure Storage. Se recomienda desarrollar estrategias de recuperación ante desastres para cada uno de estos servicios de Azure dependientes. En el caso de SQL Database, consulte Replicación geográfica activa para Azure SQL Database. En el caso de Azure Storage, consulte Redundancia de Azure Storage.
Recuperación ante desastres en la geografía de varias regiones
Hay varias maneras de replicar el contenido y las configuraciones de las aplicaciones web en regiones de Azure en una arquitectura activa-activa o activa-pasiva, como el uso de copias de seguridad y restauración de App Service. Sin embargo, la copia de seguridad y la restauración crean instantáneas a un momento dado y, finalmente, conducen a desafíos de control de versiones de aplicaciones web entre regiones. Consulte la siguiente tabla para obtener una comparación entre la guía de restauración y la guía de restauración frente a la guía de recuperación ante desastres:
Copia de seguridad y restauración frente a recuperación ante desastres
| Plataforma | Guía sobre copia de seguridad y restauración | Guía de recuperación ante desastres |
|---|---|---|
| App Service Web Apps (Plan de tarifa compartido y gratis) |
Si tiene aplicaciones web implementadas en el nivel Gratis o Compartido y requiere acceso a funcionalidades de copia de seguridad y restauración para estas aplicaciones web, escale verticalmente hasta el nivel Básico o superior. | Vuelva a poner en línea los recursos de App Service en una región de Azure diferente durante un desastre regional. A partir del 31 de marzo de 2025, las aplicaciones de App Service no se colocarán en modo de recuperación ante desastres durante un desastre en una región de Azure, como se explica en el artículo recuperación de errores en toda la región. Se recomienda implementar las técnicas de recuperación ante desastres usadas habitualmente para evitar tiempos de inactividad y pérdida de datos durante un desastre regional. |
| App Service Web Apps (Plan de tarifa Básico\Estándar\Premium) |
En Azure App Service, puede realizar copias de seguridad personalizadas a petición o usar copias de seguridad automáticas. Puede restaurar una copia de seguridad sobrescribiendo una aplicación existente mediante la restauración en una nueva aplicación o ranura. Consulte Copia de seguridad y restauración de la aplicación en Azure App Service para obtener más información. |
Las instrucciones actuales sobre cómo volver a poner los recursos de App Service línea en otra región de Azure durante un desastre regional están disponibles en Recuperación de un error en toda la región: Azure App Service. A partir del 31 de marzo de 2025, las aplicaciones web de Azure App Service ya no se pondrán en modo de recuperación ante desastres durante un desastre en una región de Azure, como se explica en el artículo Recuperación de un error en toda la región. Le recomendamos que implemente técnicas de recuperación ante desastres usadas habitualmente para evitar la pérdida de funcionalidades o datos de las aplicaciones web si se produjera un desastre regional. |
| App Service Environment (V2 y V3) | En Azure App Service Environment, puede realizar copias de seguridad personalizadas a petición o usar copias de seguridad automáticas. Las copias de seguridad se pueden restaurar en una aplicación de destino dentro del mismo ASE, no en otro ASE. Las copias de seguridad personalizadas se pueden restaurar en una aplicación de destino en otro ASE (por ejemplo, desde un ASE V2 a un ASE V3). Las copias de seguridad se pueden restaurar en la aplicación de destino de la misma plataforma del sistema operativo que la aplicación de origen. Consulte Copia de seguridad y restauración de la aplicación en Azure App Service para obtener más información. |
Le recomendamos que implemente la guía de recuperación ante desastres para las aplicaciones web implementadas en App Service Environment mediante técnicas de recuperación ante desastres usadas habitualmente. |
| Azure Functions (dedicado) | En Azure Functions, puede realizar copias de seguridad personalizadas a petición o usar copias de seguridad automáticas. Puede restaurar una copia de seguridad sobrescribiendo una aplicación existente mediante la restauración en una nueva aplicación o ranura. Consulte Copia de seguridad y restauración de la aplicación en Azure App Service para obtener más información. |
Las instrucciones actuales sobre cómo volver a poner los recursos de aplicación Azure Functions (dedicado) en línea en otra región de Azure durante un desastre regional están disponibles en Recuperación de un error en toda la región: Azure App Service. A partir del 31 de marzo de 2025, las aplicaciones de App Service no se colocarán en modo de recuperación ante desastres durante un desastre en una región de Azure, como se explica en el artículo recuperación de errores en toda la región. En su lugar, implemente la recuperación ante desastres geográfica de Azure Functions. Además, también puede consultar las técnicas de recuperación ante desastres que se usan habitualmente para Azure Functions dedicado. |
| Azure Functions Consumo y Premium | Las funciones de Azure implementadas en planes de consumo y Premium no proporcionan acceso a copias de seguridad personalizadas y automáticas. El contenido de la aplicación de funciones está en una cuenta de almacenamiento de Azure. Use las opciones de redundancia de Azure Storage para asegurarse de que la cuenta de almacenamiento cumple sus objetivos de disponibilidad y durabilidad durante una interrupción. Si creó las funciones mediante el editor de Azure Portal, también puede descargar el proyecto de la aplicación de funciones existente como un archivo .zip. |
Le recomendamos que implemente la recuperación ante desastres geográfica y la confiabilidad de Azure Functions. |
Para evitar estas limitaciones de los métodos de copia de seguridad y restauración, configure las canalizaciones de CI/CD para implementar código en ambas regiones de Azure. Considere la posibilidad de usar Azure Pipelines o Acciones de GitHub. Para más información, consulte Implementación continua en Azure App Service.
Detección, notificación y administración de interrupciones
Se recomienda configurar la supervisión y las alertas para que las aplicaciones web realicen notificaciones oportunas durante un desastre. Para más información, consulte Pruebas de disponibilidad de Application Insights.
Para administrar los recursos de la aplicación en Azure, 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 usar una herramienta de IaC, como las plantillas de Azure Resource Manager o Terraform.
Configuración de la recuperación ante desastres y la detección de interrupciones
Para prepararse para la recuperación ante desastres en una geografía de varias regiones, puede usar una arquitectura activa-activa o activa-pasiva.
Arquitectura activa-activa
En la arquitectura de recuperación ante desastres, las aplicaciones web idénticas se implementan en dos regiones independientes y Azure Front Door se usa para enrutar el tráfico a ambas regiones activas.
Con esta arquitectura de ejemplo:
- Las aplicaciones de App Service idénticas se implementan en dos regiones independientes, incluido el plan de tarifa y el recuento de instancias.
- El tráfico público que va directamente a las aplicaciones de App Service se bloquea.
- Azure Front Door se usa para enrutar el tráfico a ambas regiones activas.
- Durante un desastre, una de las regiones se queda sin conexión y Azure Front Door enruta el tráfico exclusivamente a la región que permanece en línea. El RTO durante una conmutación por error geográfica es casi cero.
- Los archivos de aplicación deben implementarse en ambas aplicaciones web con una solución de CI/CD. Esto garantiza que el RPO sea prácticamente cero.
- Si la aplicación modifica activamente el sistema de archivos, la mejor manera de minimizar el RPO es escribir solo 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.
Los pasos para crear una arquitectura activa-activa para la aplicación web en App Service se resumen de la siguiente manera:
Cree dos planes de App Service en dos regiones de Azure diferentes. Configure los dos planes de App Service de forma idéntica.
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.
- Dos grupos de origen, cada uno con una prioridad de 1. La prioridad igual indica a Azure Front Door que enrute el tráfico a ambas regiones igualmente (por lo tanto activo-activo).
- Una ruta.
Limite el tráfico de red a las aplicaciones web solo desde la instancia de Azure Front Door.
Configure todos los demás servicios de back-end de Azure, 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. Los mismos pasos con cambios mínimos (establecer la prioridad en “1” para ambos orígenes en el grupo de origen de Azure Front Door) proporcionan una arquitectura activa-activa.
Arquitectura activa-pasiva
En este enfoque de recuperación ante desastres, las aplicaciones web idénticas se implementan en dos regiones independientes y Azure Front Door se usa para enrutar el tráfico a una única región (la región activa).
Con esta arquitectura de ejemplo:
Se implementan aplicaciones de App Service idénticas en dos regiones distintas.
El tráfico público que va directamente a las aplicaciones de App Service se bloquea.
Azure Front Door se usa para enrutar el tráfico a la región primaria.
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 de App Service secundario 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 de App Service secundario tiene el mismo tipo de plan de tarifa (por ejemplo, PremiumV3), pero el tamaño de máquina virtual más pequeño, con menos instancias. 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.
El menos preferido El plan de App Service secundario 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.
La escalabilidad automática se configura en la región secundaria en caso de que la región activa se vuelva inactiva. Es aconsejable tener reglas de escalabilidad automática similares en regiones activas y pasivas.
Durante un desastre, la región primaria se vuelve inactiva y la región secundaria comienza a recibir tráfico y 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.
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.
Cuando la región primaria vuelve a estar activa, Azure Front Door dirige automáticamente el tráfico hacia ella y la arquitectura vuelve a ser activa-pasiva, como antes.
Los archivos de aplicación deben implementarse en ambas aplicaciones web con una solución de CI/CD. Esto garantiza que el RPO sea prácticamente cero.
Si la aplicación modifica activamente el sistema de archivos, la mejor manera de minimizar el RPO es escribir solo 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.
Los pasos para crear una arquitectura activa-pasiva para la aplicación web en App Service se resumen de la siguiente manera:
- 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 una prioridad de 1 para la región primaria.
- Un segundo grupo de origen con una prioridad de 2 para 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 todos los demás servicios de back-end de Azure, 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
Use una arquitectura pasiva o de acceso esporádico para crear y mantener copias de seguridad periódicas de las aplicaciones web en una cuenta de Azure Storage que se encuentra en otra región.
Con esta arquitectura de ejemplo:
Se implementa una sola aplicación web en una sola región.
Periódicamente se realiza una copia de seguridad de la aplicación web en una cuenta de Azure Storage en la misma región.
La replicación entre regiones de las copias de seguridad depende de la configuración de redundancia de datos en la cuenta de almacenamiento de Azure. Si es posible, debe establecer la cuenta de Azure Storage como GZRS. GZRS ofrece redundancia de zona sincrónica dentro de una región y asincrónica en una región secundaria. Si GZRS no está disponible, configure la cuenta como GRS. Tanto GZRS como GRS tienen un RPO de unos 15 minutos.
Para asegurarse de que puede recuperar copias de seguridad cuando la región primaria de la cuenta de almacenamiento deje de estar disponible, habilite el acceso de solo lectura a la región secundaria (haciendo que la cuenta de almacenamiento sea RA-GZRS o RA-GRS, respectivamente). Para obtener más información sobre cómo diseñar aplicaciones para aprovechar las ventajas de la redundancia geográfica, consulte Uso de redundancia geográfica para diseñar aplicaciones de alta disponibilidad.
Durante un desastre en la región de la aplicación web, debe implementar manualmente todos los recursos dependientes de App Service necesarios mediante las copias de seguridad de la cuenta de Azure Storage, lo más probable es que sea desde la región secundaria con acceso de lectura. El RTO pueden ser horas o días.
Para minimizar el RTO, se recomienda encarecidamente que tenga 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.
Los pasos para crear una región pasiva o de acceso esporádico para la aplicación web en App Service se resumen de la siguiente manera:
Cree una cuenta de almacenamiento de Azure en la misma región que la aplicación web. Elija el nivel de rendimiento estándar y seleccione la 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.
Sugerencia
Además de Azure Front Door, 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.
Recuperación ante desastres en una sola región geográfica
Si la región de la aplicación web no tiene almacenamiento GZRS o GRS o si está en una región de Azure de que no es un par regional, deberá usar almacenamiento con redundancia de zona (ZRS) o almacenamiento con redundancia local (LRS) para crear una arquitectura similar. Por ejemplo, puede crear manualmente una región secundaria para la cuenta de almacenamiento de la siguiente manera:
Los pasos para crear una región pasiva-de acceso esporádico sin GRS y GZRS se resumen de la siguiente manera:
Cree una cuenta de almacenamiento de Azure en la misma región que la aplicación web. Elija el nivel de rendimiento estándar y seleccione la redundancia como almacenamiento con redundancia de zona (ZRS).
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.
Cree una segunda cuenta de almacenamiento de Azure en otra región. Elija el nivel de rendimiento estándar y seleccione la redundancia como almacenamiento con redundancia local (LRS).
Mediante el uso de una herramienta como AzCopy, replique la copia de seguridad personalizada (archivos ZIP, XML y de registro) de la región primaria al almacenamiento secundario. Por ejemplo:
azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'Puede usar Azure Automation con un runbook de flujo de trabajo de PowerShell para ejecutar el script de replicación según una programación. Asegúrese de que la programación de replicación siga una programación similar a las copias de seguridad de la aplicación web.