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:
- Navegue até o portal do Azure.
- Pesquise por Aplicativos de Contêiner na caixa de pesquisa superior.
- Selecione Aplicativos de Contêiner.
- Selecione Criar Novo no campo Ambiente de Aplicativos de Contêiner para abrir o painel Criar Ambiente de Aplicativos de Contêiner.
- Insira o nome do ambiente.
- 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.
- Selecione a guia Rede.
- Para atribuir um nome de rede virtual personalizado, selecione Criar Novo no campo Rede Virtual.
- Para atribuir um nome de sub-rede de infraestrutura personalizado, selecione Criar Novo no campo Sub-rede infraestrutura.
- Você pode selecionar Interno ou Externo para o IP Virtual.
- 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.
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
Em seguida, consulte a ID da sub-rede da infraestrutura.
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 fim, crie o ambiente com o parâmetro --zone-redundant
. O local deverá ser o mesmo local usado ao criar a rede 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
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.
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
Comentários
https://aka.ms/ContentUserFeedback.
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulteEnviar e exibir comentários de