Confiabilidad en Azure Container Apps
En este artículo se describe la compatibilidad con la confiabilidad en Azure Container Apps y se trata la resistencia regional con zonas de disponibilidad y resistencia entre regiones con recuperación ante desastres. Para obtener información general más detallada sobre la confiabilidad de Azure, consulte Confiabilidad de Azure.
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 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 Container Apps usa zonas de disponibilidad en regiones donde están disponibles para proporcionar protección de alta disponibilidad para sus aplicaciones y datos frente a los errores del centro de datos.
Al habilitar la característica de redundancia de zona de Container Apps, las réplicas se distribuyen automáticamente entre las zonas de la región. La carga del tráfico se equilibra entre las réplicas. Si se produce una interrupción de zona, el tráfico se enruta automáticamente a las réplicas de las zonas restantes.
Nota:
No hay ningún cargo adicional por habilitar la redundancia de zona, pero solo proporcionará ventajas cuando tenga 2 o más réplicas, siendo con 3 o más ideal, ya que la mayoría de las regiones que admiten redundancia de zona tienen 3 zonas.
Requisitos previos
Azure Container Apps ofrece la misma compatibilidad de confiabilidad independientemente del tipo de plan.
Azure Container Apps usa zonas de disponibilidad en regiones donde están disponibles. Para obtener una lista de las regiones que admiten zonas de disponibilidad, consulte Servicio de zona de disponibilidad y compatibilidad regional.
Mejoras de SLA
No hay Acuerdos de nivel de servicio aumentados para Azure Container Apps. Para más información sobre los Acuerdos de Nivel de Servicio de Azure Container Apps, consulte Acuerdo de Nivel de Servicio para Azure Container Apps.
Creación de un recurso con la zona de disponibilidad habilitada
Configuración de la redundancia de zona en el entorno de Container Apps
Para aprovechar las zonas de disponibilidad, debe habilitar la redundancia de zona cuando cree un entorno de Container Apps. El entorno debe incluir una red virtual con una subred disponible. Para garantizar la distribución adecuada de las réplicas, establezca el recuento mínimo de réplicas de la aplicación en tres.
Habilitación de la redundancia de zona a través de Azure Portal
Para crear una aplicación de contenedor en un entorno con redundancia de zona habilitada mediante Azure Portal:
- Vaya a Azure Portal.
- Busque Container Apps en el cuadro de búsqueda superior.
- Seleccione Container Apps.
- Seleccione Crear nuevo en el campo Entorno de Container Apps para abrir el panel Crear entorno de Container Apps.
- Introduzca el nombre del entorno.
- Seleccione Habilitado para el campo Redundancia de zona.
La redundancia de zona requiere una red virtual con una subred de infraestructura. Puede elegir una red virtual existente o crear una nueva. Al crear una nueva red virtual, puede aceptar los valores proporcionados para usted o personalizar la configuración.
- Seleccione la pestaña Redes.
- Para asignar un nombre de red virtual personalizado, seleccione Crear nuevo en el campo Virtual Network.
- Para asignar un nombre de subred de infraestructura personalizado, seleccione Crear nuevo en el campo Subred de infraestructura.
- Puede seleccionar Interno o Externo para la IP virtual.
- Seleccione Crear.
Habilitación de la redundancia de zona con la CLI de Azure
Cree una red virtual y una subred de infraestructura que se incluyan con el entorno de Container Apps.
Cuando use estos comandos, reemplace <PLACEHOLDERS> por sus valores.
Nota:
El entorno de solo consumo requiere una subred dedicada con un rango CIDR de /23 o mayor. El entorno de perfiles de carga de trabajo requiere una subred dedicada con un rango CIDR de /27 o mayor. Para obtener más información sobre el ajuste de tamaño de subred, consulte la introducción a la arquitectura de red.
az network vnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--name <VNET_NAME> \
--location <LOCATION> \
--address-prefix 10.0.0.0/16
az network vnet subnet create \
--resource-group <RESOURCE_GROUP_NAME> \
--vnet-name <VNET_NAME> \
--name infrastructure \
--address-prefixes 10.0.0.0/21
A continuación, consulte el id. de subred de infraestructura.
INFRASTRUCTURE_SUBNET=`az network vnet subnet show --resource-group <RESOURCE_GROUP_NAME> --vnet-name <VNET_NAME> --name infrastructure --query "id" -o tsv | tr -d '[:space:]'`
Por último, cree el entorno con el parámetro --zone-redundant. La ubicación debe ser la misma ubicación que se usa al crear la red virtual.
az containerapp env create \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--location "<LOCATION>" \
--infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
--zone-redundant
Comprobación de la redundancia de zona con la CLI de Azure
Nota:
Azure Portal no muestra si la redundancia de zona está habilitada.
Use el comando az container app env show para comprobar que la redundancia de zona está habilitada para el entorno de Container Apps.
az containerapp env show \
--name <CONTAINER_APP_ENV_NAME> \
--resource-group <RESOURCE_GROUP_NAME> \
--subscription <SUBSCRIPTION_ID>
El comando devuelve una respuesta JSON. Compruebe que la respuesta contiene "zoneRedundant": true.
Técnicas de implementación segura
Al configurar la redundancia de zona en la aplicación de contenedor, las réplicas se distribuyen automáticamente entre las zonas de la región. Una vez distribuidas las réplicas, el tráfico se equilibra la carga entre ellas. Si se produce una interrupción de zona, el tráfico se enruta automáticamente a las réplicas de la zona restante.
Debe seguir usando técnicas de implementación seguras, como implementación azul-verde. Azure Container Apps no proporciona implementación o actualizaciones de una zona a la vez.
Si ha habilitado afinidad de sesión y una zona deja de funcionar, los clientes de esa zona se enrutan a nuevas réplicas porque las réplicas anteriores ya no están disponibles. Se pierde cualquier estado asociado a las réplicas anteriores.
Migración de zonas de disponibilidad
Para aprovechar las zonas de disponibilidad, habilite la redundancia de zona a medida que cree el entorno de Container Apps. El entorno debe incluir una red virtual con una subred disponible. No se puede migrar un entorno de Container Apps existente desde la compatibilidad de zona de no disponibilidad a la compatibilidad con la zona de disponibilidad.
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 el improbable caso de una interrupción de la región completa, tiene la opción de usar una de estas dos estrategias:
Recuperación manual: se implementa manualmente en una nueva región, o se espera a que la región se recupere, y luego se vuelven a implementar manualmente todos los entornos y aplicaciones.
Recuperación resistente: primero, implemente sus aplicaciones de contenedor por adelantado en varias regiones. A continuación, use Azure Front Door o Azure Traffic Manager para administrar las solicitudes entrantes, dirigiendo el tráfico a su región primaria. Entonces, si se produce una interrupción, puede redirigir el tráfico fuera de la región afectada. Para obtener más información, consulte Replicación entre regiones en Azure.
Nota
Sin importar la estrategia que elija, asegúrese de que los archivos de configuración de la implementación estén en el control de origen para que pueda volver a implementar fácilmente si es necesario.
Más instrucciones
Los siguientes recursos pueden ayudarle a crear su propio plan de recuperación ante desastres:
- Recuperación ante desastres y errores para aplicaciones de Azure
- Guía técnica sobre resistencia en Azure