Confiabilidad en Azure App Service Environment

App Service Environment es una característica de Azure App Service que proporciona un entorno totalmente aislado y dedicado para ejecutar aplicaciones de App Service de forma segura a gran escala. Como servicio de Azure, App Service Environment proporciona una variedad de funcionalidades para satisfacer sus requisitos de confiabilidad.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe el soporte de confiabilidad en App Service Environment, incluida la resistencia a errores transitorios, fallos en zonas de disponibilidad e interrupciones a nivel regional. También se describen las estrategias de copia de seguridad y la resistencia al mantenimiento del servicio y se resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de App Service Environment.

Recomendaciones de implementación de producción para la confiabilidad

Se recomienda habilitar la redundancia de zona en el entorno y los planes de App Service, lo que requiere que los planes usen un mínimo de dos instancias.

Introducción a la arquitectura de confiabilidad

Cuando implementa un App Service Environment, implemente el entorno como contenedor para sus planes de App Service y aplicaciones web. Durante la configuración, configure los ajustes básicos de red y el aislamiento opcional del hardware. Elija si desea admitir la redundancia de zona en el entorno si la región admite zonas de disponibilidad.

Después de crear su entorno, puede crear uno o varios planes de App Service.

Un plan de App Service define un conjunto de recursos de proceso que ejecutan las aplicaciones web. Todas las Web Apps deben ejecutarse dentro de un plan. Puede escalar un plan para ejecutarse en varias instancias de máquina virtual, también denominadas trabajadores. Estas instancias proporcionan los recursos de proceso que ejecutan el código de su aplicación. Un único plan de App Service puede hospedar varias aplicaciones. Todas las aplicaciones se ejecutan en el mismo conjunto compartido de instancias de máquina virtual.

Para usar App Service Environment, sus planes deben usar el nivel de precios Aislado v2. Este nivel admite redundancia de zona y aplicaciones críticas a gran escala.

App Service ofrece las siguientes características de redundancia:

• Distribución entre dominios de error: En el nivel de plataforma, Azure distribuye automáticamente las instancias de máquina virtual del plan de App Service entre dominios de error dentro de la región de Azure. Esta distribución minimiza el riesgo de errores de hardware localizados mediante la agrupación de máquinas virtuales que comparten una fuente de alimentación común y un conmutador de red.

• Distribución entre zonas de disponibilidad: Si habilita la redundancia de zona en un plan de App Service compatible, Azure distribuye las instancias entre zonas de disponibilidad dentro de la región. Esta configuración proporciona una mayor resistencia si se produce una interrupción de zona. Para obtener más información sobre la redundancia de zonas, consulte Compatibilidad con zonas de disponibilidad.

• Escalado de aplicaciones: Al configurar el plan de App Service para ejecutar varias instancias de máquina virtual, todas las aplicaciones del plan se ejecutan en todas las instancias de forma predeterminada. Si configura su plan para el escalado automático, todas las aplicaciones se escalarán juntas según la configuración de escalado automático. Sin embargo, puede personalizar el número de instancias de plan que ejecutan una aplicación específica mediante el escalado por aplicación.

• Unidades de escalado: Internamente, App Service se ejecuta en una infraestructura de plataforma denominada unidades de escalado, también conocida como stamps o espacios web. Una unidad de escalado incluye todos los componentes necesarios para hospedar y ejecutar App Service, incluido el proceso, el almacenamiento, las redes y el equilibrio de carga. Azure administra las unidades de escalado para garantizar una distribución equilibrada de cargas de trabajo, realizar un mantenimiento rutinario y mantener la confiabilidad general de la plataforma.

  Es posible que algunas funcionalidades solo se apliquen a unidades de escalado específicas. Por ejemplo, algunas unidades de escalado de App Service pueden admitir la redundancia de zona, mientras que otras unidades de escala de la misma región no.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que sus aplicaciones puedan administrar errores transitorios, generalmente reintentando las solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Los SDK proporcionados por Microsoft suelen controlar errores transitorios. Dado que hospeda sus propias aplicaciones en App Service, siga los pasos necesarios para reducir la posibilidad de errores transitorios:

• Implemente varias instancias en el plan. App Service realiza actualizaciones automatizadas y otras formas de mantenimiento en instancias del plan. Si una instancia se vuelve incorrecta, el servicio puede reemplazar automáticamente esa instancia por una nueva instancia correcta. Durante el proceso de reemplazo, puede haber un breve período cuando la instancia anterior no está disponible y una nueva instancia no está lista para atender el tráfico. Para mitigar estos efectos, implemente varias instancias del plan de App Service.

• Uso de ranuras de implementación. Las ranuras de implementación de App Service permiten implementaciones sin tiempo de inactividad de las aplicaciones. Use ranuras de implementación para minimizar el efecto de las implementaciones y los cambios de configuración para los usuarios. Las ranuras de implementación también reducen la probabilidad de que se reinicie la aplicación. Reiniciar la aplicación produce un error transitorio.

• Evite escalar o reducir verticalmente. Estas operaciones modifican la CPU, la memoria y otros recursos asignados a cada instancia, y pueden provocar el reinicio de la aplicación empresarial. En su lugar, seleccione un nivel y un tamaño de instancia que cumplan los requisitos de rendimiento bajo una carga típica. Para escalar y reducir horizontalmente, agregue y elimine instancias de forma dinámica para administrar los cambios en el volumen de tráfico.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Puede configurar su App Service Environment como redundante por zona. También puede configurar sus planes de App Service para que sean redundantes por zona, lo que los distribuye entre varias zonas de disponibilidad.

Sin embargo, puede habilitar o deshabilitar la redundancia de zona en cada plan. Esto significa que puede tener algunos planes en el entorno con redundancia de zona y otros que no.

Al crear un plan de App Service con redundancia de zona en el entorno, las instancias del plan de App Service se distribuyen entre las zonas de disponibilidad de la región. Para obtener más información, consulte Distribución de instancias entre zonas.

Requisitos

Para habilitar la redundancia de zona para su App Service Environment, debe cumplir los siguientes requisitos:

• Compatibilidad con regiones: Para ver qué regiones admiten zonas de disponibilidad para App Service Environment v3, consulte Regiones.

• Tipo de plan: Utilice tipos de plan Aislado versión 2.

• Número mínimo de instancias: Implemente un mínimo de dos instancias en el plan.

• Unidad de escalado: El entorno debe implementarse en una unidad de escalado que admita zonas de disponibilidad. No controla directamente la unidad de escalado que utiliza el entorno. En su lugar, al crear un entorno de App Service, el entorno se asigna a una unidad de escalado en función del grupo de recursos del entorno. Para determinar si la unidad de escalado de App Service Environment admite redundancia de zona, compruebe si hay compatibilidad con la redundancia de zona para un entorno de App Service.

  Si su entorno está en una unidad de escalado que no admite zonas de disponibilidad, no puede habilitar la redundancia de zona en su entorno ni en sus planes. En su lugar, debe crear un nuevo entorno en un nuevo grupo de recursos y volver a implementar las aplicaciones en nuevos planes dentro de ese entorno.

• Requisitos de configuración: Configure tanto su entorno del servicio de aplicaciones como sus planes para admitir la redundancia de zona. Puede habilitar la redundancia de zona durante la creación del entorno o actualizando un entorno existente.

Distribución de instancias a través de zonas

Al crear un plan de App Service con redundancia de zona, Azure distribuye las instancias del plan entre zonas de disponibilidad de la región. Esta distribución garantiza que sus aplicaciones sigan estando disponibles incluso si una zona sufre una interrupción del servicio.

La distribución de instancias en una implementación con redundancia de zona sigue reglas específicas. Estas reglas también se aplican a medida que la aplicación se escala y se reduce horizontalmente:

• Instancias mínimas: El plan de App Service debe tener un mínimo de dos instancias para la redundancia de zona.

• Zonas de disponibilidad máxima compatibles con el plan: Azure determina el número de zonas de disponibilidad que puede usar el plan, lo que se conoce como maximumNumberOfZones. Para ver el número de zonas de disponibilidad que puede usar su plan específico, consulte Comprobar la compatibilidad con la redundancia de zonas para un plan de App Service.

• Distribución de instancias: Cuando se habilita la redundancia de zona, Azure distribuye instancias de plan entre varias zonas de disponibilidad automáticamente. La distribución se basa en las reglas siguientes:

  • Si el número de instancias supera el maximumNumberOfZones y divide uniformemente, Azure distribuye las instancias uniformemente entre zonas.

  • Si el número de instancias no se divide de manera uniforme, Azure distribuye las instancias restantes entre las zonas restantes.

  • Cuando la plataforma de App Service asigna instancias para un plan de App Service con redundancia de zona, usa el equilibrio de zona de mejor esfuerzo que proporcionan los conjuntos de escalado de máquinas virtuales de Azure subyacentes. Un plan se equilibra si cada zona tiene el mismo número de máquinas virtuales o difiere en una instancia de todas las demás zonas. Para obtener más información, consulte Equilibrio de zona.

• Ubicación de zona física: Puede ver la zona de disponibilidad física que se usa para cada una de las instancias del plan de App Service. Para más información, consulte Visualización de zonas físicas para un plan de App Service.

Consideraciones

Una interrupción de la zona de disponibilidad puede afectar a algunos aspectos de App Service, aunque la aplicación siga sirviendo al tráfico. Estos comportamientos incluyen el escalado del plan de App Service, la creación de aplicaciones, la configuración de la aplicación y la publicación de aplicaciones.

Al habilitar la redundancia de zona en su plan de App Service, también mejora la resiliencia durante las actualizaciones de la plataforma. Para obtener más información, consulte Resistencia al mantenimiento del servicio.

En los planes de App Service que no son redundantes por zona, las instancias de máquina virtual subyacentes no son resistentes a los errores de la zona de disponibilidad. Pueden experimentar tiempo de inactividad durante una interrupción en cualquier zona de esa región.

Costos

Puede habilitar la redundancia de zona en un App Service Environment o sus planes sin coste adicional. Sin embargo, la redundancia de zona de un plan requiere que tenga dos o más instancias. 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 según los criterios de escalado automático.

Si habilita las zonas de disponibilidad pero especifica una capacidad inferior a dos instancias, la plataforma impone un mínimo de dos instancias. La plataforma le cobra por esas dos instancias.

Configurar soporte de zonas de disponibilidad

Para obtener información sobre cómo crear, habilitar o deshabilitar un nuevo App Service Environment redundante en zonas y nuevos planes de App Service redundantes en zonas, consulte Configurar App Service Environments y planes de App Service aislados v2 para la redundancia en zonas.

Planeamiento y administración de capacidad

Para prepararse para errores de zona de disponibilidad, considere la posibilidad de sobreaprovisionar la capacidad del plan de App Service. Este enfoque permite que la solución tolere cierta pérdida de capacidad y siga funcionando sin que se vea afectado su rendimiento. Para obtener más información, consulte Administración de la capacidad mediante el aprovisionamiento excesivo.

Comportamiento cuando todas las zonas están en buen estado

En la siguiente lista se describe qué esperar cuando los planes de App Service están configurados para la redundancia de zona y todas las zonas de disponibilidad están operativas:

• Enrutamiento del tráfico entre zonas: Durante el funcionamiento normal, el tráfico se enruta entre todas las instancias disponibles del plan de App Service en todas las zonas de disponibilidad.

• Replicación de datos entre zonas: Durante las operaciones normales, cualquier estado almacenado en el sistema de archivos de la aplicación se almacena en el almacenamiento con redundancia de zona y se replica sincrónicamente entre zonas de disponibilidad.

Comportamiento durante un fallo de zona

Una interrupción de la zona de disponibilidad puede afectar a algunos aspectos de App Service, aunque la aplicación siga sirviendo al tráfico. Estos comportamientos incluyen el escalado del plan de App Service, la creación de aplicaciones, la configuración de la aplicación y la publicación de aplicaciones.

La siguiente lista describe qué puede ocurrir cuando los planes de App Service están configurados para la redundancia de zona y una o varias zonas de disponibilidad no están disponibles:

• Detección y respuesta: La plataforma de App Service detecta automáticamente errores en una zona de disponibilidad e inicia una respuesta. No se requiere ninguna intervención manual para iniciar una conmutación por error de zona.

• Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas. También puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

• Solicitudes activas: Las solicitudes en curso que se conectan a una instancia del plan de App Service en la zona de disponibilidad defectuosa se finalizan. Reintentar esas solicitudes.

• Enrutamiento del tráfico:App Service detecta las instancias perdidas de esa zona e intenta encontrar nuevas instancias de reemplazo Después de que App Service encuentre reemplazos, distribuye el tráfico entre las nuevas instancias según sea necesario.

  Si se configura el ajuste automático y se determina que se necesitan más instancias, se solicitan instancias a App Service. El comportamiento de escalabilidad automática funciona independientemente del comportamiento de la plataforma de App Service. Por lo tanto, la especificación del número de instancias no tiene por qué ser un múltiplo de dos. Para más información, consulte Escalado vertical de una aplicación en App Service y Información general sobre el escalado automático.

  Importante

  Azure no garantiza que las solicitudes de más instancias se realicen correctamente en un escenario de zona descendente. La plataforma intenta reponer instancias perdidas de forma óptima. Si necesita capacidad garantizada durante un error de zona de disponibilidad, cree y configure sus planes de App Service para tener en cuenta la pérdida de zona mediante el sobreaprovisionamiento de la capacidad.

• Comportamientos fuera del tiempo de ejecución: Las aplicaciones en un plan de App Service con redundancia de zona continúan ejecutándose y prestando servicio al tráfico incluso si una zona de disponibilidad sufre una interrupción. Sin embargo, los comportamientos que no son de ejecución pueden verse afectados durante una interrupción de la zona de disponibilidad. Estos comportamientos incluyen el escalado del plan de App Service, la creación de aplicaciones, la configuración de la aplicación y la publicación de aplicaciones.

Recuperación de zona

Cuando se recupera la zona de disponibilidad, App Service crea automáticamente instancias en la zona de disponibilidad recuperada, quita las instancias temporales creadas en las otras zonas de disponibilidad y enruta el tráfico entre las instancias como de costumbre.

Prueba de fallos de zona

La plataforma de App Service administra el enrutamiento del tráfico, la conmutación por error y la conmutación por recuperación para planes de App Service con redundancia de zona. Esta característica está totalmente administrada, por lo que no es necesario iniciar ni validar los procesos de error de zona de disponibilidad.

Resistencia a errores en toda la región

App Service es un servicio de una sola región. Si la región deja de estar disponible, su entorno y sus planes y aplicaciones también dejarán de estar disponibles.

Soluciones personalizadas de varias regiones para la resistencia

Para reducir el riesgo de un error de una sola región que afecte a la aplicación, implemente varias instancias de App Service Environment en varias regiones. Los pasos siguientes ayudan a reforzar la resistencia:

• Implemente la aplicación en los entornos de App Service en cada región.
• Configure directivas de equilibrio de carga y conmutación por error.
• Replique los datos entre regiones para que pueda recuperar el último estado de la aplicación.

Para obtener un enfoque de ejemplo que ilustra esta arquitectura, consulte Implementación empresarial de alta disponibilidad mediante App Service Environment.

Copias de seguridad y restauración

Para realizar una copia de seguridad de las aplicaciones de App Service en un archivo, use las funcionalidades de copia de seguridad y restauración de App Service.

Estas funcionalidades resultan útiles cuando resulta complicado volver a implementar el código o cuando se almacena el estado en el disco. La mayoría de las soluciones no deberían depender exclusivamente de las copias de seguridad. En su lugar, use las otras capacidades de esta guía para satisfacer sus requisitos de resistencia. Sin embargo, las copias de seguridad protegen contra algunos riesgos que otros enfoques no.

Resistencia al mantenimiento del servicio

App Service realiza actualizaciones de servicio periódicas y otras tareas de mantenimiento. Para mantener la capacidad esperada durante una actualización, la plataforma agrega automáticamente instancias adicionales del plan de App Service durante el proceso de actualización.

Habilitación de la redundancia de zona. Al habilitar la redundancia de zona en su plan de App Service, también mejora la resiliencia durante las actualizaciones de la plataforma. Los dominios de actualización constan de colecciones de máquinas virtuales que se desconectan durante una actualización y se asignan a zonas de disponibilidad. La implementación de varias instancias en su plan de App Service y la habilitación de la redundancia de zona para su plan agregan una capa adicional de resistencia en caso de que una instancia o zona sea incorrecta durante una actualización.

Personalice el ciclo de actualización. Puede personalizar el ciclo de actualización de un entorno de App Service. Si necesita validar el efecto de las actualizaciones en su carga de trabajo, habilite las actualizaciones manuales. Este enfoque le permite realizar validaciones y pruebas en una instancia que no es de producción antes de aplicarlas a su instancia de producción.

Para obtener más información sobre las preferencias de mantenimiento, consulte Preferencias de actualización para el mantenimiento planificado de App Service Environment.

Acuerdo de nivel de servicio

El contrato de nivel de servicio (SLA) para los servicios de Azure describe la disponibilidad esperada de cada servicio y las condiciones que la solución deberá cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Al implementar un plan de App Service con redundancia de zona, aumenta el porcentaje de tiempo de actividad definido en el Acuerdo de Nivel de Servicio.

Contenido relacionado

• Confiabilidad en Azure
• Confiabilidad en App Service