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 son grupos físicamente separados de centros de datos dentro de cada región de Azure. Cuando se produce un error en una zona, los servicios pueden conmutar por error a una de las zonas restantes.

Para más información sobre las zonas de disponibilidad en Azure, consulte ¿Qué son las zonas de disponibilidad?.

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 regiones que admiten zonas de disponibilidad, consulte Regiones de Azure con Availability Zones.

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:

1. Vaya a Azure Portal.
2. Busque Container Apps en el cuadro de búsqueda superior.
3. Seleccione Container Apps.
4. Seleccione Crear nuevo en el campo Entorno de Container Apps para abrir el panel Crear entorno de Container Apps.
5. Introduzca el nombre del entorno.
6. 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.

1. Seleccione la pestaña Redes.
2. Para asignar un nombre de red virtual personalizado, seleccione Crear nuevo en el campo Virtual Network.
3. Para asignar un nombre de subred de infraestructura personalizado, seleccione Crear nuevo en el campo Subred de infraestructura.
4. Puede seleccionar Interno o Externo para la IP virtual.
5. 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.

CLI de Azure

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

Azure PowerShell

$SubnetArgs = @{
    Name = 'infrastructure-subnet'
    AddressPrefix = '10.0.0.0/21'
}
$subnet = New-AzVirtualNetworkSubnetConfig @SubnetArgs

$VnetArgs = @{
    Name = <VNetName>
    Location = <Location>
    ResourceGroupName = <ResourceGroupName>
    AddressPrefix = '10.0.0.0/16'
    Subnet = $subnet 
}
$vnet = New-AzVirtualNetwork @VnetArgs

A continuación, consulte el id. de subred de infraestructura.

CLI de Azure

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:]'`

Azure PowerShell

$InfrastructureSubnet=(Get-AzVirtualNetworkSubnetConfig -Name $SubnetArgs.Name -VirtualNetwork $vnet).Id

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.

CLI de Azure

az containerapp env create \
  --name <CONTAINER_APP_ENV_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --location "<LOCATION>" \
  --infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET \
  --zone-redundant

Azure PowerShell

Se requiere un área de trabajo de Log Analytics para el entorno de Container Apps. Los siguientes comandos crean un área de trabajo de Log Analytics y guardan el id. del área de trabajo y la clave compartida principal en variables de entorno.

$WorkspaceArgs = @{
    Name = 'myworkspace'
    ResourceGroupName = <ResourceGroupName>
    Location = <Location>
    PublicNetworkAccessForIngestion = 'Enabled'
    PublicNetworkAccessForQuery = 'Enabled'
}
New-AzOperationalInsightsWorkspace @WorkspaceArgs
$WorkspaceId = (Get-AzOperationalInsightsWorkspace -ResourceGroupName <ResourceGroupName> -Name $WorkspaceArgs.Name).CustomerId
$WorkspaceSharedKey = (Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName <ResourceGroupName> -Name $WorkspaceArgs.Name).PrimarySharedKey

Para crear el entorno, ejecute el comando siguiente:

$EnvArgs = @{
    EnvName = <EnvironmentName>
    ResourceGroupName = <ResourceGroupName>
    Location = <Location>
    AppLogConfigurationDestination = "log-analytics"
    LogAnalyticConfigurationCustomerId = $WorkspaceId
    LogAnalyticConfigurationSharedKey = $WorkspaceSharedKey
    VnetConfigurationInfrastructureSubnetId = $InfrastructureSubnet
    VnetConfigurationInternal = $true
}
New-AzContainerAppManagedEnv @EnvArgs

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.

CLI de Azure

az containerapp env show \
  --name <CONTAINER_APP_ENV_NAME> \
  --resource-group <RESOURCE_GROUP_NAME> \
  --subscription <SUBSCRIPTION_ID>

Azure PowerShell

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, es 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

Pasos siguientes

Confiabilidad en Azure