Fiabilidade nas Aplicações de Contentor do Azure

Este artigo descreve o suporte à confiabilidade nos Aplicativos de Contêiner do Azure e aborda a resiliência regional com zonas de disponibilidade e a resiliência entre regiões com recuperação de desastres. Para obter uma visão geral mais detalhada da confiabilidade no Azure, consulte Confiabilidade do Azure.

Suporte à zona de disponibilidade

As zonas de disponibilidade do Azure são pelo menos três grupos fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas duas zonas restantes.

As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.

Os serviços habilitados para zonas de disponibilidade do Azure são projetados para fornecer o nível certo de confiabilidade e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ser redundantes de zona, com replicação automática entre zonas, ou zonais, com instâncias fixadas a uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus arquitetura com redundância de zona, consulte Recomendações para usar zonas e regiões de disponibilidade.

Os Aplicativos de Contêiner do Azure usam zonas de disponibilidade em regiões onde estão disponíveis para fornecer proteção de alta disponibilidade para seus aplicativos e dados contra falhas de data center.

Ao habilitar o recurso de redundância de zona dos Aplicativos de Contêiner, as réplicas são distribuídas automaticamente pelas zonas da região. O tráfego é balanceado entre as réplicas. Se ocorrer uma interrupção de zona, o tráfego será automaticamente roteado para as réplicas nas zonas restantes.

Nota

Não há cobrança extra para habilitar a redundância de zona, mas ela só oferece benefícios quando você tem 2 ou mais réplicas, sendo 3 ou mais ideais, já que a maioria das regiões que suportam redundância de zona tem 3 zonas.

Pré-requisitos

Os Aplicativos de Contêiner do Azure oferecem o mesmo suporte de confiabilidade, independentemente do tipo de plano.

Os Aplicativos de Contêiner do Azure usam zonas de disponibilidade em regiões onde estão disponíveis. Para obter uma lista de regiões que oferecem suporte a zonas de disponibilidade, consulte Serviço de zona de disponibilidade e suporte regional.

Melhorias no SLA

Não há SLAs aumentados para Aplicativos de Contêiner do Azure. Para obter mais informações sobre os SLAs dos Aplicativos de Contêiner do Azure, consulte Contrato de Nível de Serviço para Aplicativos de Contêiner do Azure.

Criar um recurso com a zona de disponibilidade ativada

Configurar a redundância de zona em seu ambiente de Aplicativos de Contêiner

Para aproveitar as zonas de disponibilidade, você deve habilitar a redundância de zona ao criar um ambiente de Aplicativos de Contêiner. O ambiente deve incluir uma rede virtual com uma sub-rede disponível. Para garantir a distribuição adequada de réplicas, defina a contagem mínima de réplicas do seu aplicativo como três.

Habilitar redundância de zona por meio do portal do Azure

Para criar um aplicativo de contêiner em um ambiente com redundância de zona habilitada usando o portal do Azure:

1. Navegue para o portal do Azure.
2. Procure Aplicativos de contêiner na caixa de pesquisa superior.
3. Selecione Aplicativos de contêiner.
4. Selecione Criar novo no campo Ambiente de aplicativos de contêiner para abrir o painel Criar ambiente de aplicativos de contêiner.
5. Insira o nome do ambiente.
6. Selecione Habilitado para o campo Redundância de zona.

A redundância de zona requer uma rede virtual com uma sub-rede de infraestrutura. Você pode escolher uma rede virtual existente ou criar uma nova. Ao criar uma nova rede virtual, você pode aceitar os valores fornecidos para você ou personalizar as configurações.

1. Selecione o separador Rede.
2. Para atribuir um nome de rede virtual personalizado, selecione Criar novo no campo Rede virtual.
3. Para atribuir um nome de sub-rede de infraestrutura personalizado, selecione Criar novo no campo Sub-rede de infraestrutura.
4. Você pode selecionar Interno ou Externo para o IP Virtual.
5. Selecione Criar.

Habilitar redundância de zona com a CLI do Azure

Crie uma rede virtual e uma sub-rede de infraestrutura para incluir no ambiente Container Apps.

Ao usar esses comandos, substitua o <PLACEHOLDERS> por seus valores.

Nota

O ambiente Somente consumo requer uma sub-rede dedicada com um intervalo CIDR igual /23 ou maior. O ambiente de perfis de carga de trabalho requer uma sub-rede dedicada com um intervalo CIDR igual /27 ou maior. Para saber mais sobre o dimensionamento de sub-redes, consulte a visão geral da arquitetura de rede.

CLI do 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

Em seguida, consulte o ID da sub-rede de infraestrutura.

CLI do 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 fim, crie o ambiente com o --zone-redundant parâmetro. O local deve ser o mesmo local usado ao criar a rede virtual.

CLI do 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

Um espaço de trabalho do Log Analytics é necessário para o ambiente Container Apps. Os comandos a seguir criam um espaço de trabalho do Log Analytics e salvam o ID do espaço de trabalho e a chave compartilhada primária em variáveis de ambiente.

$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 criar o ambiente, execute o seguinte comando:

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

Verificar a redundância de zona com a CLI do Azure

Nota

O Portal do Azure não mostra se a redundância de zona está habilitada.

Use o comando para verificar se a az container app env show redundância de zona está habilitada para seu ambiente de Aplicativos de Contêiner.

CLI do 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>

O comando retorna uma resposta JSON. Verifique se a resposta contém "zoneRedundant": true.

Técnicas de implementação seguras

Quando você configura a redundância de zona em seu aplicativo de contêiner, as réplicas são distribuídas automaticamente pelas zonas da região. Depois que as réplicas são distribuídas, o tráfego é balanceado entre elas. Se ocorrer uma interrupção de zona, o tráfego será encaminhado automaticamente para as réplicas na zona restante.

Você ainda deve usar técnicas de implantação seguras, como a implantação azul-verde. Os Aplicativos de Contêiner do Azure não fornecem implantação ou atualizações de uma zona de cada vez.

Se você tiver habilitado a afinidade de sessão e uma zona ficar inativa, os clientes dessa zona serão roteados para novas réplicas porque as réplicas anteriores não estarão mais disponíveis. Qualquer estado associado às réplicas anteriores é perdido.

Migração da zona de disponibilidade

Para aproveitar as zonas de disponibilidade, habilite a redundância de zona ao criar o ambiente de Aplicativos de Contêiner. O ambiente deve incluir uma rede virtual com uma sub-rede disponível. Não é possível migrar um ambiente existente de Aplicativos de Contêiner do suporte à zona de indisponibilidade para o suporte à zona de disponibilidade.

Recuperação de desastres entre regiões e continuidade de negócios

A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Quando se trata de DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de DR.

No caso improvável de uma interrupção completa da região, você tem a opção de usar uma das duas estratégias:

• Recuperação manual: implante manualmente em uma nova região ou aguarde a recuperação da região e, em seguida, reimplante manualmente todos os ambientes e aplicativos.

• Recuperação resiliente: primeiro, implante seus aplicativos de contêiner com antecedência em várias regiões. Em seguida, use o Azure Front Door ou o Azure Traffic Manager para lidar com solicitações de entrada, apontando o tráfego para sua região principal. Em seguida, caso ocorra uma interrupção, você pode redirecionar o tráfego para fora da região afetada. Para obter mais informações, consulte Replicação entre regiões no Azure.

Nota

Independentemente da estratégia escolhida, certifique-se de que os arquivos de configuração de implantação estejam sob controle do código-fonte para que você possa reimplantar facilmente, se necessário.

Mais orientações

Os seguintes recursos podem ajudá-lo a criar seu próprio plano de recuperação de desastres:

• Falha e recuperação após desastre para aplicações do Azure
• Orientações técnicas sobre resiliência do Azure

Próximos passos

Fiabilidade no Azure