Laboratório de Troubleshooting: Manage Virtual Machine Disks
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma VM de produção do tamanho Standard_DS2_v2 rodando Windows Server executa uma aplicação de processamento de arquivos. O time de operações relata que, desde ontem à noite, as operações de leitura no disco de dados estão significativamente mais lentas que o esperado. Nenhuma alteração de código foi feita na aplicação.
O administrador coleta as seguintes informações:
Disco de dados: Premium SSD LRS | 512 GB | P20
Cache configurado: None
IOPS provisionado no disco: 2.300
IOPS consumido (métrica no portal): 2.290 (99,5% do limite)
Disco de SO: Premium SSD LRS | 128 GB | P10
Cache configurado: Read/Write
IOPS consumido: 340
Tamanho da VM: Standard_DS2_v2
Max IOPS permitidos pela VM: 6.400
Throughput máx. permitido pela VM: 51.200 KB/s
O time de infraestrutura menciona que, na mesma noite, foi criado um segundo disco de dados de 512 GB do mesmo tipo e anexado à VM para uma tarefa de backup, mas que esse disco não está sendo usado pela aplicação.
Qual é a causa raiz da degradação de desempenho nas leituras do disco de dados?
A) O cache configurado como None no disco de dados impede que leituras recentes sejam servidas do cache do host, causando latência elevada.
B) O disco de dados atingiu o limite de IOPS provisionado pelo SKU P20, causando throttling no nível do disco.
C) O limite de IOPS da VM foi atingido em razão da soma de IOPS dos dois discos anexados, causando throttling no nível da VM.
D) O disco de SO com cache Read/Write está consumindo a maior parte da banda de throughput da VM, deixando menos recursos para o disco de dados.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o disco de SO de uma VM Linux de produção está completamente cheio, impedindo a escrita de logs e causando falhas intermitentes na aplicação. A VM está em execução e atende requisições em produção.
O administrador tem as seguintes restrições:
- Não há janela de manutenção aprovada para as próximas 6 horas
- A equipe de segurança exige aprovação formal para qualquer operação que cause downtime não planejado
- O tamanho atual do disco de SO é de 64 GB (SKU P6) e ainda há espaço alocado não particionado no disco
- A aplicação tolera uma reinicialização de serviço sem perda de dados, mas não tolera desalocação da VM
- Já existe um snapshot recente do disco
Qual é a ação correta a tomar neste momento?
A) Expandir o sistema de arquivos para utilizar o espaço não particionado existente no disco, sem desalocar a VM.
B) Criar um novo disco de dados maior, copiar os arquivos de log para ele e redirecionar o diretório de logs da aplicação.
C) Desalocar a VM, redimensionar o disco de SO para 128 GB no portal e reativar a VM.
D) Criar um novo snapshot do disco atual e restaurar a VM a partir do snapshot mais recente para liberar espaço.
Cenário 3 — Causa Raiz
Um administrador tenta anexar um disco gerenciado existente a uma nova VM e recebe a seguinte mensagem de erro no portal do Azure:
The disk 'disk-prod-data-01' is already attached to a VM.
Operation not allowed.
O administrador verifica no portal que a VM original à qual o disco estava vinculado foi excluída há dois dias. O grupo de recursos ainda existe e contém outros recursos. O disco aparece na listagem de discos gerenciados com o estado Attached.
Informações coletadas:
Disco: disk-prod-data-01
Estado reportado: Attached
VM original: vm-prod-app-01 (excluída)
Grupo de recursos: rg-producao
Assinatura: sub-prod-001
Região: East US
Tipo: Premium SSD LRS | 256 GB
O time de redes informa que houve uma falha temporária de conectividade com a região East US no momento em que a VM foi excluída, mas que a conectividade foi restabelecida minutos depois.
Qual é a causa raiz do estado inconsistente do disco?
A) A falha de conectividade com a região East US corrompeu os metadados do disco durante a exclusão da VM, exigindo restauração a partir de backup.
B) A exclusão da VM foi concluída, mas o processo de desanexação do disco não foi finalizado corretamente, deixando o disco em estado Attached de forma inconsistente na plataforma.
C) O disco está protegido por um bloqueio de recurso (Resource Lock) do tipo ReadOnly aplicado ao grupo de recursos, impedindo qualquer modificação de estado.
D) A VM foi excluída, mas a opção Delete disk with VM estava desmarcada, e esse comportamento impede que o disco retorne ao estado Unattached automaticamente.
Cenário 4 — Sequência de Diagnóstico
Uma VM Windows reporta que um disco de dados recém-anexado não aparece no Explorador de Arquivos, embora o disco esteja visível no portal do Azure como Attached e saudável.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Passo A: Verificar no Gerenciador de Discos do Windows se o disco aparece como offline, sem inicialização ou sem partição
- Passo B: Confirmar no portal do Azure que o disco está de fato no estado Attached à VM correta
- Passo C: Inicializar o disco, criar uma partição e formatar com o sistema de arquivos desejado
- Passo D: Atribuir uma letra de unidade ao volume para que ele apareça no Explorador de Arquivos
- Passo E: Verificar nos logs de eventos do Windows se há erros relacionados ao driver de disco
Qual é a sequência correta de diagnóstico e resolução?
A) B → A → C → D → E
B) B → E → A → D → C
C) B → A → E → C → D
D) A → B → C → E → D
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O indicador decisivo está nas métricas coletadas: o disco de dados P20 está operando em 99,5% do seu limite de IOPS provisionado (2.290 de 2.300). Esse valor caracteriza throttling no nível do disco, que é o mecanismo pelo qual o Azure limita operações adicionais quando o SKU do disco atinge seu teto de desempenho. O resultado prático é degradação de latência nas leituras, exatamente o sintoma relatado.
A informação sobre o segundo disco de dados anexado é a informação irrelevante inserida propositalmente. O enunciado deixa claro que esse disco não está sendo usado pela aplicação, e os dados de IOPS da VM mostram que o teto da VM (6.400 IOPS) não foi atingido, eliminando a alternativa C.
A alternativa A descreve um comportamento real do cache, mas o cache None em discos de dados é recomendado pela Microsoft justamente para cargas de leitura/escrita aleatória, e sua ausência não causa o padrão de degradação observado. A alternativa D é refutada pelos próprios dados: o disco de SO consome apenas 340 IOPS, longe de saturar o throughput da VM.
O distrator mais perigoso é o C, pois o segundo disco é uma informação visível e recente, criando a ilusão de que a soma de IOPS dos discos teria atingido o limite da VM, mas os números não sustentam essa conclusão.
Gabarito — Cenário 2
Resposta: A
O enunciado fornece uma informação técnica crítica: ainda há espaço alocado não particionado no disco de SO existente. Isso significa que é possível expandir o sistema de arquivos para aproveitar esse espaço sem nenhuma operação que cause downtime. Em Linux, isso pode ser feito com ferramentas como growpart e resize2fs (ou xfs_growfs para XFS) com a VM em execução, sem desalocação.
A alternativa C seria tecnicamente válida para expandir o disco além do espaço atual, mas exige desalocação da VM, o que viola duas restrições explícitas do cenário: ausência de janela de manutenção e exigência de aprovação formal para downtime. Agir com base nessa alternativa causaria uma interrupção não autorizada em produção.
A alternativa B é criativa, mas desnecessariamente complexa quando a solução não destrutiva e sem downtime já está disponível. A alternativa D revela um equívoco conceitual: restaurar um snapshot não libera espaço em disco; restaura o estado anterior, que pelo contexto do problema também estava sem espaço livre.
Gabarito — Cenário 3
Resposta: B
O estado Attached persistindo após a exclusão da VM é um comportamento de inconsistência de metadados na plataforma do Azure. Quando uma VM é excluída, o Azure inicia o processo de desanexar os discos associados e atualizar seu estado para Unattached. Em raras situações, esse processo pode não ser concluído corretamente, deixando o disco com o estado incorreto registrado nos metadados, mesmo que a VM não exista mais.
A resolução padrão é usar o Azure CLI para forçar a atualização do estado do disco:
az disk update --name disk-prod-data-01 \
--resource-group rg-producao \
--set managedBy=null
A informação irrelevante é a falha de conectividade relatada pelo time de redes. Ela não tem relação com o estado do disco e serve para desviar o diagnóstico para a alternativa A, que trata de corrupção de metadados e restauração de backup, uma resposta desproporcional e incorreta para o sintoma.
A alternativa C é plausível em outros contextos, mas o enunciado não menciona nenhum Resource Lock, e o estado Attached sem VM existente não é o comportamento esperado de um lock. A alternativa D mistura dois comportamentos distintos: a opção Delete disk with VM controla se o disco é excluído junto com a VM, não o estado de anexação do disco após a exclusão.
Gabarito — Cenário 4
Resposta: C
A sequência correta é: B → A → E → C → D
O raciocínio segue uma lógica de diagnóstico progressivo:
- B — Confirmar no portal que o disco está de fato Attached à VM correta é sempre o primeiro passo. Sem essa confirmação, qualquer investigação dentro do SO pode ser um esforço em vão.
- A — Com a confirmação do portal, o próximo passo é verificar como o SO enxerga o disco. O Gerenciador de Discos revelará se o disco está offline, sem inicialização ou sem partição, o que é o estado esperado para um disco recém-anexado no Windows.
- E — Verificar os logs de eventos antes de agir permite identificar se há erros de driver ou problemas que tornariam inútil o passo seguinte.
- C — Com o disco visível e saudável no Gerenciador de Discos, o próximo passo operacional é inicializá-lo, criar uma partição e formatar.
- D — Somente após a formatação é possível atribuir uma letra de unidade, que é o que fará o disco aparecer no Explorador de Arquivos.
A alternativa A coloca o passo C antes de E, o que significa agir sem verificar erros de driver previamente. A alternativa B inverte A e E, iniciando pela leitura de logs antes de confirmar o estado do disco no SO. A alternativa D começa pelo passo A sem a confirmação do portal, pulando a validação mais básica.
Árvore de Troubleshooting: Manage Virtual Machine Disks
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul médio | Pergunta de diagnóstico |
| Laranja | Validação ou verificação intermediária |
| Verde | Ação recomendada ou resolução |
| Vermelho | Causa identificada que requer intervenção corretiva |
Para usar esta árvore diante de um problema real, comece pelo nó raiz e responda cada pergunta com base no que você observa no portal, nas métricas e no sistema operacional. Não avance para um ramo sem confirmar a resposta ao nó anterior. Nós laranjas indicam que você precisa coletar mais uma informação antes de decidir. Nós verdes indicam que há uma ação direta disponível. Nós vermelhos indicam que o problema exige uma decisão de maior impacto, como redimensionamento, migração ou planejamento de janela de manutenção.