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?

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
  • Centro de Israel
  • Norte de Italia
  • Japón Oriental
  • Centro de Corea del Sur
  • Centro de México
  • 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 España
  • 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

az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6

"resources": [
  {
    "type": "Microsoft.Web/serverfarms",
    "apiVersion": "2018-02-01",
    "name": "your-appserviceplan-name-here",
    "location": "West US 3",
    "sku": {
        "name": "P1v3",
        "tier": "PremiumV3",
        "size": "P1v3",
        "family": "Pv3",
        "capacity": 3
    },
    "kind": "app",
    "properties": {
        "zoneRedundant": true
    }
  }
]

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

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.

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

En el caso de entornos multiinquilino que usan planes de App Service Premium v2 o Premium v3, no hay ningún costo adicional asociado a la habilitación de zonas de disponibilidad siempre que tenga tres o más instancias en el plan de App Service. 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. App Service Environment v3 tiene un modelo de precios diferente para las zonas de disponibilidad. 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:

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

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:

1. Cree dos planes de App Service en dos regiones de Azure diferentes. Configure los dos planes de App Service de forma idéntica.

2. Cree dos instancias de la aplicación web, con una en cada plan de App Service.

3. 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.

4. Limite el tráfico de red a las aplicaciones web solo desde la instancia de Azure Front Door.

5. Configure todos los demás servicios de back-end de Azure, como bases de datos, cuentas de almacenamiento y proveedores de autenticación.

6. 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:

1. 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.
2. 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.
3. Cree dos instancias de la aplicación web, con una en cada plan de App Service.
4. 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.
5. Limite el tráfico de red a las aplicaciones web solo desde la instancia de Azure Front Door.
6. Configure todos los demás servicios de back-end de Azure, como bases de datos, cuentas de almacenamiento y proveedores de autenticación.
7. 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:

1. 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).

2. Habilite RA-GRS o RA-GZRS (acceso de lectura para la región secundaria).

3. 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.

4. 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.

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:

1. 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).

2. 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.

3. 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.

4. 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).

5. 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.

Pasos siguientes

• Tutorial: Creación de una aplicación de varias regiones con alta disponibilidad en Azure App Service
• Confiabilidad en Azure