Confiabilidade nos Aplicativos de Contêiner do Azure

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

Suporte à zona de disponibilidade

As zonas de disponibilidade do Azure são pelo menos três grupos de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas 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 é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.

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

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

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

Observação

Não há nenhum custo extra para habilitar a redundância de zona, mas ela só oferece benefícios quando você tem duas ou mais réplicas, sendo três ou mais o ideal, pois a maioria das regiões que dão suporte à redundância de zona tem três 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 em que estão disponíveis. Para obter uma lista de regiões que dão suporte a zonas de disponibilidade, consulte o Serviço de zona de disponibilidade e o suporte regional.

Aprimoramentos do SLA

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

Criar um recurso com a zona de disponibilidade habilitada

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

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

Redundância de zona habilitada 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 até o portal do Azure.
2. Pesquise por 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 exige 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ê poderá aceitar os valores fornecidos ou personalizar as configurações.

1. Selecione a guia 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 infraestrutura.
4. Você pode selecionar Interno ou Externo para o IP Virtual.
5. Selecione Criar.

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

Crie uma rede virtual e uma sub-rede de infraestrutura para incluir no ambiente de Aplicativos de Contêiner.

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

Observação

O ambiente Somente Consumo requer uma sub-rede dedicada com um intervalo CIDR igual a /23 ou maior. O ambiente de perfis de carga de trabalho requer uma sub-rede dedicada com um intervalo CIDR igual a /27 ou maior. Para saber mais sobre o dimensionamento de sub-rede, 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

PowerShell do Azure

$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 a ID da sub-rede da 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:]'`

PowerShell do Azure

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

Por fim, crie o ambiente com o parâmetro --zone-redundant. O local deverá 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

PowerShell do Azure

Um workspace do Log Analytics é necessário para o ambiente de Aplicativos de Contêiner. Os comandos a seguir criam um workspace do Log Analytics e salvam a ID do workspace 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

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

Observação

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

Use o comando az container app env show para verificar se a 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>

PowerShell do Azure

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 implantação segura

Quando você configura a redundância de zona em seu aplicativo de contêiner, as réplicas são distribuídas automaticamente entre as 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á roteado automaticamente para as réplicas nas zonas restantes.

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

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

Migração da zona de disponibilidade

Para aproveitar as zonas de disponibilidade, será necessário habilitar a redundância de zona ao criar o ambiente de Aplicativos de Contêiner. O ambiente deverá incluir uma rede virtual com uma sub-rede disponível. Você não pode migrar um ambiente de Aplicativos de Contêiner existente do suporte à zona de não disponibilidade para o suporte à zona de disponibilidade.

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

A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.

Quando o assunto é 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 de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastre que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.

No caso improvável de ocorrer uma interrupção em uma região completa, 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 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 Gerenciador de Tráfego do Azure para lidar com solicitações de entrada, apontando o tráfego para a região primária. Em seguida, se ocorrer uma interrupção, você poderá redirecionar o tráfego para longe da região afetada. Para saber mais, confira Replicação entre regiões no Azure.

Observação

Qualquer que seja a estratégia escolhida, verifique se os arquivos de configuração da implantação estão no controle do código-fonte para que você possa reimplantar facilmente, se necessário.

Mais diretrizes

Além disso, os seguintes recursos podem ajudar você a criar seu plano de recuperação de desastre:

• Recuperação de desastre e falha para aplicativos do Azure
• Orientações técnicas de resiliência do Azure

Próximas etapas

Confiabilidade no Azure