Laboratório de Troubleshooting: Deploy and configure an Azure Virtual Machine Scale Sets
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um VMSS de produção com 8 instâncias está configurado com autoscaling habilitado. O time de monitoramento abre um chamado relatando que, nas últimas 6 horas, o número de instâncias nunca ultrapassou 4, mesmo com a CPU média consistentemente acima de 80% por períodos superiores a 10 minutos.
O administrador verifica o Activity Log e encontra eventos de scale-out sendo gerados corretamente pelo autoscaler. A subscription tem cota suficiente para o SKU utilizado. O VMSS está implantado na região East US com zonas de disponibilidade 1, 2 e 3 habilitadas.
Ao executar o comando abaixo, o administrador obtém a seguinte saída:
az vmss show \
--name vmss-prod-api \
--resource-group rg-producao \
--query "sku" \
--output json
{
"capacity": 4,
"name": "Standard_D2s_v3",
"tier": "Standard"
}
Em seguida, verifica o perfil de autoscaling:
az monitor autoscale show \
--name autoscale-vmss-prod \
--resource-group rg-producao \
--query "profiles[0].capacity" \
--output json
{
"default": "2",
"maximum": "4",
"minimum": "2"
}
O time de redes informa que, na mesma janela de tempo, houve um incidente de latência no gateway VPN que conecta o ambiente on-premises ao Azure, mas o acesso externo ao VMSS via Load Balancer nunca foi interrompido.
Qual é a causa raiz da limitação no número de instâncias?
A) A cota da subscription para o SKU Standard_D2s_v3 na região East US foi atingida, impedindo o provisionamento de novas instâncias além de 4.
B) O incidente no gateway VPN degradou a comunicação entre o agente de monitoramento e o Azure Monitor, fazendo com que as métricas de CPU chegassem com atraso, atrasando as decisões de scale-out.
C) O valor de maximum no perfil de autoscaling está definido como 4, impedindo que o autoscaler ultrapasse esse limite mesmo diante de alta carga.
D) A distribuição por zonas de disponibilidade está forçando o VMSS a balancear instâncias igualmente entre as 3 zonas, limitando a capacidade total a múltiplos de 3.
Cenário 2 — Decisão de Ação
A equipe de infraestrutura identificou que um VMSS de homologação está realizando scale-in agressivo durante horários de baixa utilização, encerrando instâncias que ainda possuem sessões de usuário ativas. A investigação confirmou que a causa é a ausência de uma Instance Protection configurada nas instâncias que estão sendo encerradas.
O ambiente tem as seguintes restrições:
- O VMSS usa modo de orquestração Flexible
- Há 6 instâncias ativas no momento
- 2 instâncias possuem sessões ativas com usuários realizando testes de carga manuais que não podem ser interrompidos
- O time de segurança não autoriza alterações na política de autoscaling neste momento
- O prazo para a janela de testes é de mais 4 horas
Qual é a ação correta a tomar agora?
A) Aumentar o valor de minimum no perfil de autoscaling para 6, garantindo que nenhuma instância seja encerrada durante a janela de testes.
B) Aplicar Instance Protection do tipo protectFromScaleIn diretamente nas 2 instâncias com sessões ativas, sem alterar a política de autoscaling.
C) Alterar o upgradePolicy.mode para Manual para suspender qualquer ação automática do VMSS até o fim da janela de testes.
D) Criar um bloqueio de recurso (ReadOnly) no VMSS para impedir que o autoscaler encerre instâncias durante a janela.
Cenário 3 — Causa Raiz
Um VMSS foi atualizado com uma nova imagem base que inclui uma versão mais recente do agente de monitoramento. O upgradePolicy.mode está configurado como Automatic. Após a atualização, o time de operações observa que as instâncias mais antigas do VMSS continuam exibindo a versão anterior do agente, enquanto as instâncias criadas após a atualização da imagem já possuem a versão nova.
O administrador executa:
az vmss get-instance-view \
--name vmss-monit \
--resource-group rg-monit \
--instance-id 0 \
--query "extensions[?name=='CustomScriptExtension'].statuses" \
--output json
[
[
{
"code": "ProvisioningState/succeeded",
"displayStatus": "Provisioning succeeded",
"level": "Info",
"message": "Enable succeeded"
}
]
]
O time informa que a nova imagem foi publicada na galeria compartilhada (Azure Compute Gallery) há 3 dias, e que o VMSS foi atualizado para referenciar a nova versão da imagem no mesmo dia. O Load Balancer associado ao VMSS reporta que todas as instâncias estão respondendo normalmente às health probes.
O VMSS tem 10 instâncias. A saída abaixo mostra o estado das instâncias:
az vmss list-instances \
--name vmss-monit \
--resource-group rg-monit \
--query "[].{id:instanceId, model:latestModelApplied}" \
--output table
InstanceId LatestModelApplied
------------ --------------------
0 False
1 False
2 False
3 True
4 True
5 False
6 False
7 True
8 False
9 False
Qual é a causa raiz do comportamento observado?
A) A extensão CustomScriptExtension nas instâncias antigas falhou silenciosamente durante o upgrade automático, impedindo que o novo agente fosse instalado sem impactar o status de saúde reportado ao Load Balancer.
B) O campo latestModelApplied: False indica que as instâncias antigas ainda não foram atualizadas para o modelo mais recente, o que contradiz o comportamento esperado do modo Automatic e aponta para uma falha no processo de upgrade automático.
C) O modo Automatic não atualiza instâncias que estão respondendo às health probes, pois o sistema interpreta instâncias saudáveis como não candidatas a reinicialização.
D) A imagem referenciada no VMSS aponta para a versão nova na galeria, mas o VMSS ainda está usando uma image reference com versão fixada (1.0.0) em vez de latest, fazendo com que apenas novas instâncias provisionadas recebam a imagem correta.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte alerta às 14h32:
"VMSS vmss-web-frontend: scale-out operation failed. 0 of 3 requested instances were provisioned."
O VMSS está em produção, com tráfego ativo. O administrador precisa diagnosticar a falha e, se possível, provisionar as instâncias com o menor impacto ao serviço.
Os passos de investigação disponíveis são:
- Passo P: Verificar o Activity Log do VMSS para identificar a mensagem de erro detalhada da operação de scale-out falha.
- Passo Q: Verificar a cota de vCPUs da subscription para o SKU utilizado na região do VMSS.
- Passo R: Confirmar se o perfil de autoscaling tem um
maximumconfigurado acima do número atual de instâncias. - Passo S: Verificar se há um bloqueio de recurso (
ReadOnlyouDelete) aplicado ao resource group ou ao VMSS. - Passo T: Provisionar as instâncias manualmente via
az vmss scaleapós confirmar a causa e corrigir o impedimento.
Qual é a sequência correta de diagnóstico e ação?
A) R, P, Q, S, T
B) P, R, S, Q, T
C) S, Q, R, P, T
D) Q, P, S, R, T
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: C
A pista definitiva está na saída do comando az monitor autoscale show, que exibe "maximum": "4". O autoscaler respeita esse limite como um teto absoluto, independentemente da demanda de CPU ou da disponibilidade de cota na subscription. Os eventos de scale-out sendo gerados corretamente no Activity Log confirmam que o autoscaler está funcionando, mas está sendo bloqueado pelo próprio limite configurado.
A informação sobre o incidente no gateway VPN é propositalmente irrelevante. O acesso via Load Balancer nunca foi interrompido e o autoscaler opera com métricas do Azure Monitor, que não dependem da conectividade VPN. Incluir esse detalhe força o leitor a resistir à tentação de atribuir a causa a um incidente de infraestrutura mais visível.
A alternativa A é um distrator sofisticado: a mensagem de erro que apareceria em caso de cota esgotada seria visível no Activity Log, e o enunciado não menciona nenhum erro de provisionamento, apenas a limitação no número de instâncias. A alternativa D representa um equívoco real sobre como o balanceamento por zonas funciona: o VMSS distribui instâncias entre zonas mas não limita a capacidade total a múltiplos do número de zonas.
O distrator mais perigoso é o A. Um administrador que fosse abrir uma solicitação de aumento de cota sem verificar o perfil de autoscaling desperdiçaria tempo em produção sem resolver o problema real.
Gabarito — Cenário 2
Resposta: B
A causa foi identificada explicitamente no enunciado: ausência de Instance Protection nas instâncias com sessões ativas. A restrição crítica é que o time de segurança não autoriza alterações na política de autoscaling. Isso elimina diretamente as alternativas A e C, pois ambas envolvem modificar o comportamento do autoscaler de forma sistêmica.
A alternativa B aplica proteção cirúrgica apenas nas 2 instâncias afetadas, sem tocar na política de autoscaling, respeitando todas as restrições do cenário. O protectFromScaleIn no modo Flexible é aplicado diretamente na instância via propriedade protectionPolicy, sem exigir alterações na configuração do scale set.
A alternativa D representa um erro crítico de raciocínio: um bloqueio ReadOnly impediria não apenas o scale-in mas qualquer operação de escrita no VMSS, incluindo operações legítimas de gerenciamento e potencialmente o próprio autoscaling de scale-out, causando um impacto muito maior do que o problema que se pretende resolver.
A alternativa C confunde o upgradePolicy.mode com o controle de autoscaling. Alterar a política de upgrade para Manual não suspende as ações do autoscaler; são configurações independentes.
Gabarito — Cenário 3
Resposta: D
A pista central está na coluna LatestModelApplied: False para 7 das 10 instâncias, combinada com o fato de que as instâncias criadas após a atualização já possuem o modelo correto. Isso indica que o VMSS está aplicando a nova imagem apenas para instâncias novas, mas não está atualizando as existentes.
O modo Automatic deveria atualizar todas as instâncias progressivamente sem intervenção manual. Se 7 instâncias permanecem com latestModelApplied: False após 3 dias, o upgrade automático não está ocorrendo para elas. A causa mais direta para esse comportamento é uma image reference com versão fixada: quando a referência usa "version": "1.0.0" em vez de "latest", o VMSS não detecta automaticamente que há uma nova versão disponível. Novas instâncias recebem a imagem mais recente porque são provisionadas do zero com o modelo atual do scale set, que foi atualizado manualmente para apontar para a nova versão, mas o gatilho de upgrade automático das instâncias existentes não é disparado.
A alternativa B descreve o sintoma corretamente, mas não é uma causa raiz. Ela é uma reformulação do problema. A alternativa C é tecnicamente falsa: o modo Automatic atualiza instâncias saudáveis normalmente; instâncias unhealthy é que podem ser bloqueadas em alguns cenários.
A informação sobre o status da CustomScriptExtension é irrelevante para o diagnóstico e foi incluída para distrair o leitor em direção à alternativa A.
Gabarito — Cenário 4
Resposta: B
A sequência correta é P, R, S, Q, T, que segue a lógica de diagnóstico progressivo do mais simples para o mais específico, sem executar ações corretivas antes de confirmar a causa.
O primeiro passo é sempre P (Activity Log), pois a mensagem de erro detalhada da operação falha já pode revelar a causa sem necessidade de investigação adicional. O Activity Log é o ponto de entrada diagnóstico para qualquer operação falha no Azure.
Com a mensagem de erro em mãos, os passos seguintes filtram hipóteses em ordem de probabilidade e facilidade de verificação: R (limite de maximum no autoscaling) é verificado rapidamente via CLI e resolve a maioria dos casos de scale-out bloqueado silenciosamente. S (bloqueio de recurso) é menos comum mas crítico, pois um ReadOnly lock impediria qualquer operação de escrita. Q (cota de vCPUs) é verificado em último lugar entre as hipóteses, pois exige acesso ao painel de cotas da subscription e é um problema de resolução mais lenta.
Somente após confirmar e corrigir o impedimento executa-se T (provisionamento manual).
A sequência A começa por R, o que pode levar o administrador a alterar o maximum desnecessariamente antes de sequer ler a mensagem de erro. A sequência C começa por S (bloqueio), que é a causa menos provável e mais difícil de verificar rapidamente. A sequência D começa por Q (cota), que é a investigação mais demorada e menos provável para uma falha repentina em um VMSS que funcionava anteriormente.
Árvore de Troubleshooting: Deploy and configure an Azure Virtual Machine Scale Sets
Legenda:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica ou decisão |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando o tipo de sintoma observado: escalonamento bloqueado, modelo desatualizado, encerramento indevido de instâncias ou upgrade travado. Siga as ramificações respondendo cada pergunta com base no que é observável diretamente via CLI ou portal. Sempre passe pelos nós de validação antes de executar ações corretivas, pois eles garantem que o diagnóstico está correto antes de qualquer mudança no ambiente. Ao atingir um nó de causa, a ação recomendada correspondente indica o próximo passo operacional.