Laboratório de Troubleshooting: Manage Virtual Machine Sizes
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador tenta redimensionar uma VM de produção chamada vm-api-prod de Standard_D4s_v3 para Standard_D16s_v3 pelo portal do Azure. A VM está em execução, atende a uma API crítica e está localizada na região East US. O storage account associado foi criado há dois anos e usa replicação LRS. O disco do SO é gerenciado e tem 128 GB.
Ao tentar confirmar o redimensionamento, o administrador recebe a seguinte mensagem:
Resize virtual machine
The following VM sizes are not available for this VM.
Standard_D16s_v3 — Not available in current allocation cluster
O administrador verifica no portal que o tamanho Standard_D16s_v3 aparece na lista de tamanhos disponíveis para a região East US. O disco gerenciado está saudável e sem erros. A conta de armazenamento LRS não apresenta nenhum alerta ativo.
Qual é a causa raiz do problema?
A) O tamanho Standard_D16s_v3 foi descontinuado e não está mais disponível para novas alocações na região East US
B) A VM está alocada em um cluster de hardware que não possui hosts com suporte ao tamanho de destino
C) O disco gerenciado de 128 GB é incompatível com o tamanho Standard_D16s_v3
D) A conta de armazenamento LRS impede o redimensionamento para tamanhos com mais de 8 vCPUs
Cenário 2 — Decisão de Ação
A equipe de operações identificou que uma VM crítica de banco de dados precisa ser migrada da família Standard_D para a família Standard_E para atender a novos requisitos de memória. A causa foi diagnosticada e confirmada: o tamanho de destino Standard_E8s_v3 não está disponível no cluster atual da VM, e a operação só pode ser concluída após desalocação.
A VM está em produção ativa, com uma janela de manutenção programada para as 02h00 de sábado, aprovada pelo time de negócio. São quinta-feira, 14h00. O administrador tem permissão de Contributor no resource group. A VM não faz parte de um Availability Set.
Qual é a ação correta a tomar neste momento?
A) Desalocar a VM imediatamente, executar o redimensionamento e reiniciar, aproveitando que o diagnóstico já foi confirmado
B) Aguardar a janela de manutenção aprovada, desalocar a VM, aplicar o redimensionamento e reiniciar
C) Criar uma nova VM com o tamanho correto agora e migrar os dados sem aguardar a janela
D) Redimensionar a VM sem desalocação usando o Azure CLI, contornando a restrição do portal
Cenário 3 — Causa Raiz
Um desenvolvedor reporta que a VM vm-render-01, usada para processamento de imagens, está com performance de CPU muito abaixo do esperado durante picos de carga. O tamanho atual da VM é Standard_B4ms. Nos últimos 7 dias, o Azure Monitor registrou utilização de CPU consistentemente acima de 90% durante o horário comercial.
A equipe revisou a configuração e verificou os seguintes dados:
VM Size: Standard_B4ms
vCPUs: 4
RAM: 16 GiB
CPU Credits: Remaining: 0 / Max: 576
Baseline CPU %: 90%
Disk IOPS: Sem throttling detectado
Network: Sem perda de pacotes
A VM foi criada há três semanas. O time de infraestrutura menciona que o disco premium está corretamente configurado e que a rede não apresenta nenhum problema. Recentemente, a equipe também atualizou o agente de monitoramento na VM.
Qual é a causa raiz da degradação de performance observada?
A) O agente de monitoramento atualizado está consumindo recursos de CPU e causando o gargalo
B) O disco premium, apesar de aparentemente correto, está com IOPS insuficiente para a carga
C) A VM esgotou os créditos de CPU acumulados e está operando no limite da baseline da série B
D) O tamanho Standard_B4ms tem restrição de uso contínuo e entra em modo de throttling após 21 dias
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte alerta às 08h15:
[ALERTA] vm-web-prod: operação de redimensionamento falhou
Horário: 08:12
Tamanho solicitado: Standard_F8s_v2
Tamanho atual: Standard_F2s_v2
Erro: OperationNotAllowed — QuotaExceeded
Região: Brazil South
O administrador nunca investigou esse tipo de falha antes e precisa resolver o problema. Abaixo estão os passos de investigação disponíveis, fora de ordem:
[P1] Verificar o uso atual de vCPUs na assinatura para a região Brazil South
[P2] Abrir um ticket de suporte solicitando aumento de cota de vCPUs para a família F
[P3] Confirmar que o erro OperationNotAllowed com QuotaExceeded indica esgotamento de cota
[P4] Validar que o aumento de cota foi aprovado e tentar o redimensionamento novamente
[P5] Identificar quantas vCPUs adicionais serão consumidas pelo novo tamanho
Qual sequência de diagnóstico e ação representa a abordagem correta?
A) P3 -> P1 -> P5 -> P2 -> P4
B) P1 -> P3 -> P2 -> P5 -> P4
C) P5 -> P1 -> P3 -> P4 -> P2
D) P3 -> P5 -> P1 -> P4 -> P2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A mensagem de erro descreve com precisão o problema: o tamanho solicitado não está disponível no cluster de alocação atual da VM. Isso ocorre porque o Azure aloca VMs em clusters de hardware físico dentro de uma região, e nem todos os tamanhos existem em todos os clusters. A disponibilidade regional listada no portal indica que o tamanho existe na região, não que ele está acessível no cluster específico onde a VM reside.
A pista determinante no enunciado é exatamente o texto do erro: "Not available in current allocation cluster", que nomeia diretamente o cluster como o limitador, não a região.
As informações sobre a conta de armazenamento LRS e o disco de 128 GB são propositalmente irrelevantes e foram incluídas para induzir o diagnóstico equivocado. O tipo de replicação de storage e o tamanho do disco não influenciam a disponibilidade de tamanhos de VM em clusters.
O distrator mais perigoso é o D, que poderia convencer alguém a tentar migrar o storage account antes de identificar a causa real. Agir com base nessa hipótese desperdiçaria tempo e não resolveria o problema.
A solução correta é desalocar a VM, o que libera o vínculo com o cluster atual e permite ao Azure realocá-la em um host que suporte o tamanho desejado.
Gabarito — Cenário 2
Resposta: B
A causa já está confirmada e a solução técnica é conhecida: desalocar e redimensionar. O que determina a resposta correta neste cenário é a restrição de contexto operacional: a janela de manutenção foi aprovada pelo time de negócio para sábado às 02h00, e a ação ainda está a mais de 36 horas de distância.
Executar a desalocação imediatamente (alternativa A) é tecnicamente correto, mas viola a restrição operacional. A VM está em produção ativa e a desalocação causa indisponibilidade. Antecipar uma ação impactante sem autorização é um erro de governança, não técnico.
A alternativa C ignora a janela ao criar uma nova VM agora, com risco de problemas na migração de dados sem planejamento adequado. A alternativa D é factualmente incorreta: o Azure CLI também exige desalocação quando o tamanho-alvo não está disponível no cluster atual; o portal não é a limitação, o comportamento do Azure é.
A disciplina de aguardar a janela aprovada demonstra que o diagnóstico correto não autoriza a ação imediata quando há restrições operacionais vigentes.
Gabarito — Cenário 3
Resposta: C
O dado determinante está no bloco de métricas: CPU Credits Remaining: 0. A série B opera com um modelo de créditos de CPU. Quando a VM opera acima da baseline, consome créditos. Quando os créditos se esgotam, a performance de CPU é limitada à baseline definida para o tamanho. Para o Standard_B4ms, a baseline é de 90% por vCPU, o que significa que, sem créditos, a VM não consegue sustentar picos além desse nível, gerando exatamente o comportamento reportado.
A informação sobre a atualização do agente de monitoramento é propositalmente irrelevante e foi incluída para desviar o diagnóstico para um caminho de software. Agentes de monitoramento consomem CPU marginal e não explicam utilização sustentada acima de 90%.
O distrator mais perigoso é o A, pois a atualização de software recente é um evento visível no histórico e naturalmente atrai suspeita. Agir com base nessa hipótese levaria a rollback do agente sem nenhum ganho de performance.
O distrator D é tecnicamente inválido: a série B não possui limite de uso por tempo de atividade da VM.
A resolução correta é migrar para um tamanho com CPU dedicada constante, como a série D ou F, adequado para cargas com utilização contínua e previsível.
Gabarito — Cenário 4
Resposta: A
A sequência correta é P3 -> P1 -> P5 -> P2 -> P4.
O raciocínio diagnóstico progressivo exige:
- P3: Confirmar o que o erro significa antes de qualquer ação. O erro QuotaExceeded indica esgotamento de cota de vCPUs, não falha de cluster ou indisponibilidade regional.
- P1: Verificar o uso atual de vCPUs na assinatura para a região afetada, estabelecendo a linha de base do consumo.
- P5: Calcular quantas vCPUs adicionais o novo tamanho exige, para saber exatamente quanto de cota adicional solicitar. Abrir um ticket sem esse número resulta em solicitação imprecisa.
- P2: Com a informação necessária em mãos, abrir o ticket de suporte com o valor correto de aumento.
- P4: Validar que o aumento foi aprovado antes de tentar novamente.
A alternativa B parece razoável, mas inverte P3 e P1: verificar o uso antes de entender o que o erro significa é investigar sem diagnóstico. A alternativa C começa pelo P5 sem validar o que o erro representa, pulando a etapa de confirmação de diagnóstico. A alternativa D pula o cálculo de vCPUs adicionais antes de abrir o ticket, resultando em uma solicitação possivelmente subdimensionada.
Árvore de Troubleshooting: Manage Virtual Machine Sizes
Legenda de cores:
- Azul escuro: sintoma ou ponto de entrada
- Azul: pergunta diagnóstica ou decisão de investigaçã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 e responda cada pergunta com base no que você observou no ambiente. Se a operação gerou erro, identifique o tipo de erro antes de qualquer ação. Se o problema é silencioso, como degradação de performance sem erro explícito, siga o caminho de investigação de serie e créditos. Cada ramificação termina em uma causa precisa ou em uma ação concreta, evitando que você atue sobre hipóteses não confirmadas.