Laboratório de Troubleshooting: Deploy virtual machines to availability zones and availability sets
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações reporta que, após uma janela de manutenção planejada pelo Azure na última madrugada, três VMs de um conjunto de quatro ficaram indisponíveis simultaneamente por aproximadamente 12 minutos. As quatro VMs fazem parte do Availability Set as-api-prod, que foi criado há seis meses. O time informa que o Availability Set foi configurado corretamente e está associado a um Load Balancer interno.
O administrador consulta as configurações do Availability Set e obtém a seguinte saída:
az vm availability-set show \
--name as-api-prod \
--resource-group rg-producao \
--query "{faultDomains:platformFaultDomainCount, updateDomains:platformUpdateDomainCount}"
{
"faultDomains": 2,
"updateDomains": 2
}
O administrador também verifica que todas as quatro VMs estão com o agente do Azure atualizado e que os discos são todos do tipo Premium SSD. O Load Balancer está com health probes configurados corretamente e respondendo normalmente agora.
Qual é a causa raiz do comportamento observado durante a manutenção?
A) O Load Balancer não redistribuiu o tráfego corretamente durante a manutenção, derrubando as conexões das VMs
B) O Availability Set foi configurado com apenas 2 Update Domains, o que permitiu que três das quatro VMs fossem reiniciadas no mesmo grupo de atualização
C) Os discos Premium SSD não são suportados em Availability Sets, causando falha durante a reinicialização
D) O agente do Azure desatualizado nas VMs impediu que o Azure coordenasse corretamente a sequência de manutenção
Cenário 2 — Sequência de Diagnóstico
Um administrador tenta criar uma VM no portal do Azure e, ao selecionar a opção de zona de disponibilidade, percebe que o campo de seleção de zona está completamente ausente na interface, como se o recurso não existisse para aquela configuração.
A VM está sendo criada com as seguintes características:
| Configuração | Valor |
|---|---|
| Região | East US |
| Tamanho | Standard_B2s |
| Sistema operacional | Windows Server 2022 |
| Disco OS | Standard HDD |
| Rede virtual | vnet-prod (existente) |
| Availability Set | as-frontend (existente) |
O administrador confirma que a assinatura está ativa, que tem permissão de Contributor no resource group e que a região East US suporta Availability Zones.
Qual é a sequência correta de investigação para identificar por que a opção de zona está ausente?
A) Verificar permissões da assinatura > Verificar suporte a zonas na região > Verificar o tamanho da VM > Remover a associação ao Availability Set
B) Verificar se o Availability Set está selecionado > Confirmar que Availability Set e Availability Zone são mutuamente exclusivos > Remover a associação ao Availability Set > Tentar selecionar a zona novamente
C) Verificar o tipo de disco > Alterar para Premium SSD > Verificar suporte a zonas na região > Remover a associação ao Availability Set
D) Verificar permissões do resource group > Verificar o sistema operacional > Verificar suporte a zonas na região > Remover a associação ao Availability Set
Cenário 3 — Causa Raiz
Uma empresa implantou sua camada de aplicação em três VMs distribuídas pelas Availability Zones 1, 2 e 3 na região Brazil South. O arquiteto declarou que a solução está protegida contra falha de zona e que o SLA de 99,99% se aplica à solução completa.
Dois meses após o deploy, ocorre uma falha na Zona 2 da região. O monitoramento indica que a VM na Zona 2 ficou inacessível, mas o restante da aplicação também apresentou degradação severa e perda parcial de dados em sessões ativas.
As informações do ambiente são:
VM zona 1: vm-app-z1 | IP público zone-redundant | Disco OS: Zone 1
VM zona 2: vm-app-z2 | IP público zone-redundant | Disco OS: Zone 2
VM zona 3: vm-app-z3 | IP público zone-redundant | Disco OS: Zone 3
Load Balancer: Standard SKU | Frontend IP: zone-redundant
Storage Account (sessões): Standard_LRS | Localização: Brazil South
O time de rede confirma que o Load Balancer Standard com IP zone-redundant funcionou corretamente e desviou o tráfego das zonas 1 e 3 dentro de segundos.
Qual é a causa raiz da degradação e da perda de dados nas sessões ativas?
A) O Load Balancer Standard não suporta distribuição de tráfego entre zonas durante falhas reais, apenas em testes
B) Os IPs públicos zone-redundant introduzem latência adicional que causa timeout nas sessões durante failover
C) A Storage Account com replicação LRS armazena dados apenas em uma zona; como as sessões estavam gravando nessa zona, houve perda de dados quando a Zona 2 falhou
D) O SLA de 99,99% se aplica apenas a VMs individuais, não à solução completa, e por isso a proteção não foi efetiva
Cenário 4 — Decisão de Ação
A causa foi identificada: uma VM crítica de produção chamada vm-db-primary está implantada sem Availability Zone e sem Availability Set. Ela roda um banco de dados relacional com dados que não podem ser perdidos. O time de negócio confirmou que há uma janela de manutenção disponível no próximo fim de semana, com tolerância a até 4 horas de indisponibilidade para migração.
O administrador sabe que:
- Não é possível adicionar uma VM existente a um Availability Set ou Availability Zone após a criação
- O banco de dados possui um mecanismo de backup e restore totalmente validado
- Existe um processo documentado de failover para uma réplica de leitura em outra VM
- A janela começa em 5 dias
Qual é a ação correta a tomar agora?
A) Recriar a VM imediatamente em uma Availability Zone, aproveitando que a janela ainda não começou, para minimizar o risco de falha nos próximos 5 dias
B) Planejar a recriação da VM durante a janela de manutenção, utilizando o backup validado para restaurar os dados após o deploy em uma Availability Zone, seguindo o processo documentado
C) Adicionar a VM atual a um Availability Set via CLI com o parâmetro --availability-set, aproveitando que o banco está em execução e sem janela de impacto
D) Aguardar uma falha real da VM atual para justificar o downtime de recriação fora da janela planejada
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
Explicações:
- A pista decisiva está na saída do comando:
"updateDomains": 2. Com apenas 2 Update Domains e 4 VMs, o Azure distribui as VMs ciclicamente: 2 VMs no UD 0 e 2 VMs no UD 1. Durante a manutenção, o Azure reinicia um Update Domain por vez, mas se metade das VMs (2) estiverem em cada UD e o comportamento de saúde do Load Balancer não compensar rapidamente, 2 VMs podem ficar indisponíveis simultaneamente. A configuração correta para 4 VMs seria utilizar o padrão de 5 Update Domains, garantindo no máximo 1 VM por grupo. - A informação irrelevante aqui é o tipo de disco Premium SSD e o estado atual dos health probes do Load Balancer. Ambos funcionam corretamente e não têm relação causal com o evento durante a manutenção.
- O distrator mais perigoso é a alternativa A, que culpa o Load Balancer. O Load Balancer está operacional agora e os health probes estão corretos; o problema foi a quantidade de VMs afetadas ao mesmo tempo, não a redistribuição de tráfego.
- Agir com base no distrator A levaria o administrador a reconfigurar um Load Balancer que não tem problema, deixando a causa real (Update Domains insuficientes) sem correção.
Gabarito — Cenário 2
Resposta: B
Explicações:
- A sequência correta começa pela observação mais direta disponível na interface: o próprio Availability Set já está selecionado. Confirmar que os dois mecanismos são mutuamente exclusivos é o passo seguinte de raciocínio, e remover o Availability Set é a ação que desbloqueará a seleção de zona.
- As alternativas C e D desviam o diagnóstico para tipo de disco e sistema operacional, que são completamente irrelevantes para a ausência da opção de zona neste contexto.
- A alternativa A inclui a ação correta no final (remover o Availability Set), mas insere verificações desnecessárias antes, como verificar permissões e tamanho da VM, que já foram confirmados como corretos pelo enunciado. Uma sequência de diagnóstico eficiente parte do sintoma mais específico disponível, não de verificações genéricas.
- O erro de raciocínio central nos distratores é ignorar a informação mais explícita do cenário (a presença do Availability Set) e buscar causas em elementos periféricos.
Gabarito — Cenário 3
Resposta: C
Explicações:
- O elemento crítico está na tabela de configuração:
Storage Account: Standard_LRS. O tipo LRS (Locally Redundant Storage) replica dados apenas dentro de uma única zona físicass. Quando a Zona 2 falhou, os dados de sessão que estavam sendo gravados nessa Storage Account ficaram inacessíveis ou foram perdidos, pois não havia cópia em outra zona. - O Load Balancer Standard com frontend zone-redundant funcionou corretamente, conforme confirmado pelo time de rede. Essa informação elimina a alternativa A do diagnóstico.
- A alternativa B é um distrator técnico plausível mas incorreto: IPs zone-redundant não introduzem latência perceptível e não causam timeout em sessões durante failover.
- A informação sobre o SLA de 99,99% mencionada pelo arquiteto é irrelevante para o diagnóstico da causa raiz. O SLA se refere à disponibilidade das VMs, não à integridade dos dados de uma Storage Account com LRS.
- O distrator mais perigoso é a alternativa D, que leva o administrador a questionar o SLA em vez de investigar a configuração de replicação do armazenamento. Isso atrasaria a identificação e correção do problema real, que é substituir LRS por ZRS (Zone-Redundant Storage) na Storage Account de sessões.
Gabarito — Cenário 4
Resposta: B
Explicações:
- A restrição central do cenário é a existência de uma janela de manutenção já aprovada, com tolerância definida e processo documentado. Agir dentro dessa janela é a decisão correta porque protege a integridade dos dados e respeita o processo validado de backup e restore.
- A alternativa A parece prudente, mas ignora uma restrição crítica: recriar a VM agora significa executar uma migração de banco de dados de produção sem a janela de manutenção aprovada, sem o alinhamento do negócio e com risco de impacto não planejado. O período de 5 dias sem o recurso não justifica esse risco.
- A alternativa C descreve uma operação impossível. Não existe forma de adicionar uma VM existente a um Availability Set após a criação, seja via CLI, portal ou API. Executar esse comando resultaria em erro.
- A alternativa D é a mais perigosa: aguardar uma falha real significa aceitar downtime não planejado e potencial perda de dados em um banco de dados sem proteção de zona, em vez de agir dentro de uma janela controlada já disponível.
- A disciplina de não agir fora da janela planejada, mesmo quando o risco parece urgente, é o comportamento correto para ambientes de produção com dados críticos.
Árvore de Troubleshooting: Deploy virtual machines to availability zones and availability sets
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta de diagnóstico |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação intermediária ou estado ambíguo |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e responda cada pergunta com base no que você consegue verificar diretamente no ambiente. Siga o caminho correspondente à sua resposta até alcançar um nó vermelho (causa identificada) ou verde (ação recomendada). Se chegar a um nó laranja, ele indica que mais verificação é necessária antes de concluir o diagnóstico. O objetivo é sempre percorrer o menor número de ramificações possível com base nas evidências disponíveis, evitando investigar caminhos que o próprio enunciado já descarta.