Laboratório de Troubleshooting: Configure Azure Site Recovery for Azure resources
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de infraestrutura habilitou a replicação de 12 VMs do Azure da região East US para West US usando o Azure Site Recovery. As VMs estão distribuídas em três resource groups diferentes. A conta de armazenamento de cache foi criada na região de origem com redundância LRS. O Cofre dos Serviços de Recuperação está na região West US.
Após 72 horas, o engenheiro responsável observa que 4 das 12 VMs apresentam o seguinte status no portal:
VM: vm-prod-db-02
Status de replicação: Aviso
Integridade: A replicação não gerou nenhum ponto de recuperação
nas últimas 24 horas.
Último ponto de recuperação consistente com aplicação: 71h atrás
Último ponto de recuperação consistente com falha: 23h atrás
As 8 outras VMs estão saudáveis e com RPO dentro do esperado. O engenheiro verifica que as 4 VMs problemáticas são todas do tipo Standard_D8s_v3 com discos Premium SSD de 2 TB cada. O time de banco de dados informa que essas VMs têm workload de escrita intensiva, com picos frequentes acima de 80 MB/s por disco. A rede entre as regiões não apresenta alertas e o status do serviço ASR está normal no painel de saúde do Azure.
Qual é a causa raiz do problema observado nessas 4 VMs?
A) O Cofre dos Serviços de Recuperação está na região de destino, o que impede a geração de pontos de recuperação consistentes com aplicação para VMs com discos Premium SSD.
B) A taxa de rotatividade de dados das VMs excede os limites suportados pelo ASR, fazendo com que a conta de armazenamento de cache não consiga processar e transferir os dados na velocidade necessária para gerar novos pontos de recuperação.
C) A conta de armazenamento de cache com redundância LRS está causando throttling nas operações de escrita, pois o nível LRS não suporta a taxa de transferência exigida por discos Premium SSD de 2 TB.
D) O agente de mobilidade instalado nessas 4 VMs está desatualizado e não consegue capturar alterações de disco acima de 50 MB/s, bloqueando a criação de pontos de recuperação.
Cenário 2 — Decisão de Ação
A equipe de operações identificou que a causa de uma falha de replicação em um grupo de VMs é a ausência de permissões adequadas na identidade gerenciada do Cofre dos Serviços de Recuperação sobre a conta de armazenamento de cache. O cofre não tem a role Storage Blob Data Contributor atribuída nessa conta.
O ambiente possui as seguintes restrições:
- O incidente está aberto com severidade 2, exigindo resolução em até 2 horas
- As VMs afetadas são de produção e não podem ser reiniciadas ou ter a replicação desabilitada neste momento
- O engenheiro possui permissão de Contributor no nível do resource group onde o cofre está, mas não tem permissão de Owner nem de User Access Administrator na assinatura ou no resource group da conta de armazenamento
- Um colega com permissão de Owner na assinatura está disponível e online
Qual é a ação correta a tomar neste momento?
A) Desabilitar e reabilitar a replicação das VMs afetadas para forçar o ASR a recriar as permissões automaticamente sobre a conta de armazenamento.
B) Solicitar ao colega com permissão de Owner que atribua a role Storage Blob Data Contributor à identidade gerenciada do cofre na conta de armazenamento, e aguardar a propagação antes de validar o status de replicação.
C) Criar uma nova conta de armazenamento de cache no resource group onde o engenheiro tem permissão de Contributor e redirecionar a replicação para ela.
D) Elevar temporariamente as próprias permissões via Microsoft Entra Privileged Identity Management (PIM) para Owner na assinatura e realizar a atribuição de role diretamente.
Cenário 3 — Causa Raiz
Um engenheiro de operações executa um failover de teste de uma VM crítica para validar o plano de recuperação antes de uma auditoria interna. O failover de teste é concluído sem erros no portal e o engenheiro marca o teste como bem-sucedido. Dois dias depois, ele percebe o seguinte no portal do ASR:
VM: vm-app-frontend-01
Status de replicação: Crítico
Detalhe: A replicação está suspensa.
O failover de teste não foi concluído corretamente.
Execute 'Limpar failover de teste' para retomar a replicação.
O engenheiro confirma que a VM de teste está desligada na região secundária desde ontem. A rede virtual isolada usada no teste ainda existe. A VM de origem está funcionando normalmente em produção. Os logs de atividade do cofre não mostram nenhuma operação de limpeza registrada após o failover de teste.
O engenheiro afirma que clicou em "Parar VM de teste" no portal após a validação.
Qual é a causa raiz do problema observado?
A) Clicar em "Parar VM de teste" não equivale a executar a operação de limpeza do failover de teste no ASR. A operação obrigatória de Limpar failover de teste não foi executada, e sem ela a replicação permanece suspensa.
B) A VM de teste foi desligada manualmente na região secundária, o que corrompeu o estado interno do ASR e suspendeu a replicação como mecanismo de proteção.
C) A rede virtual isolada usada no teste ainda existe, e o ASR interpreta isso como um conflito de recursos que impede a retomada da replicação.
D) O failover de teste gerou um snapshot de consistência que não foi liberado automaticamente, e o ASR suspendeu a replicação para evitar inconsistência entre o snapshot retido e os dados novos da VM de origem.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta informando que uma VM do Azure protegida pelo ASR apresenta status de replicação crítico. O administrador nunca investigou esse tipo de falha antes e precisa seguir uma sequência lógica de diagnóstico.
Os passos disponíveis são:
- Verificar os eventos de integridade do cofre no portal e identificar o código de erro específico associado à VM
- Confirmar se a VM de origem está ligada e acessível na região primária
- Verificar se a conta de armazenamento de cache está disponível e sem alertas de capacidade ou throttling
- Acessar o painel de saúde do serviço ASR no Azure Status para descartar falha global do serviço
- Analisar os logs do agente de mobilidade dentro da VM de origem para verificar erros de captura de disco
Qual é a sequência correta de diagnóstico?
A) 2 → 4 → 1 → 3 → 5
B) 4 → 2 → 1 → 3 → 5
C) 1 → 3 → 2 → 5 → 4
D) 3 → 1 → 4 → 2 → 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista central está na combinação de dois dados fornecidos: as 4 VMs afetadas são exclusivamente as de workload de escrita intensiva com picos acima de 80 MB/s por disco, enquanto as 8 VMs saudáveis não têm esse perfil. O ASR possui limites documentados de churn (rotatividade de dados) por disco e por VM. Quando esses limites são excedidos de forma consistente, o serviço não consegue processar e transferir os dados acumulados na conta de armazenamento de cache na velocidade necessária, resultando em pontos de recuperação cada vez mais antigos até a degradação completa do status.
A informação irrelevante neste cenário é a redundância LRS da conta de armazenamento de cache. O nível de redundância não afeta a capacidade de throughput do cache no contexto do ASR; ele não é a variável que determina se o churn pode ser absorvido. A alternativa C leva o leitor a focar nesse detalhe propositalmente inserido.
A alternativa D é o distrator mais perigoso: o agente de mobilidade desatualizado é uma causa real de problemas no ASR, mas o sintoma típico é falha de instalação ou erros de conectividade, não degradação gradual correlacionada à taxa de escrita de disco.
Agir com base em D levaria o engenheiro a atualizar agentes sem resolver o problema real, perdendo horas críticas enquanto o RPO continua degradando.
Gabarito — Cenário 2
Resposta: B
A causa já está identificada no enunciado: falta a role Storage Blob Data Contributor na identidade gerenciada do cofre sobre a conta de armazenamento. A restrição crítica é que o engenheiro não tem permissão para atribuir roles nessa conta. A ação correta é acionar o colega com permissão de Owner para realizar a atribuição, que é uma operação simples e direcionada ao recurso correto.
A alternativa A é tecnicamente incorreta: desabilitar e reabilitar a replicação não recria permissões de identidade gerenciada; esse comportamento não existe no ASR. Além disso, a restrição do enunciado proíbe explicitamente essa ação em produção.
A alternativa C ignora que redirecionar a replicação para uma nova conta de armazenamento exige desabilitar e reabilitar a replicação, o que viola diretamente a restrição declarada.
A alternativa D pode parecer válida se o ambiente tiver PIM configurado para Owner, mas o enunciado não menciona essa permissão como disponível para o engenheiro, e a ação mais proporcional e rápida é acionar o colega já disponível. Usar PIM para escalar a própria permissão quando há alguém competente e disponível é uma decisão de governança inadequada para o contexto.
Gabarito — Cenário 3
Resposta: A
A pista definitiva está nos logs de atividade do cofre: nenhuma operação de limpeza foi registrada após o failover de teste. O ASR exige que o administrador execute explicitamente a operação Limpar failover de teste para encerrar o ciclo do teste e retomar a replicação normal. Essa operação é distinta e separada de qualquer ação tomada na VM de teste em si, como desligá-la ou excluí-la.
A informação irrelevante é a existência da rede virtual isolada. Ela não interfere no estado de replicação; o ASR não monitora a presença ou ausência de VNets de teste como critério para suspender ou retomar a replicação.
A alternativa B inverte a causalidade: desligar a VM de teste não suspende a replicação; a suspensão já estava ativa desde que o failover de teste foi iniciado sem ser formalmente encerrado.
O distrator mais perigoso é C: é plausível imaginar um conflito de recursos, mas o ASR não usa a existência de VNets como gatilho de suspensão. Agir com base em C levaria o administrador a excluir a rede virtual sem resolver o problema, pois a causa é operacional, não de infraestrutura.
Gabarito — Cenário 4
Resposta: B
A sequência correta é: 4 → 2 → 1 → 3 → 5
O raciocínio diagnóstico correto segue do geral para o específico, e do mais rápido de verificar para o mais custoso:
Passo 4 descarta uma falha global do serviço ASR antes de qualquer investigação local. Se o serviço estiver com incidente ativo, toda investigação posterior é prematura.
Passo 2 confirma se a VM de origem está operacional. Sem isso, qualquer investigação de replicação não tem base.
Passo 1 acessa o código de erro específico do cofre, que direciona os próximos passos com precisão em vez de investigar às cegas.
Passo 3 verifica a conta de armazenamento de cache, que é um dos pontos de falha mais comuns e identificáveis no portal.
Passo 5 é o mais invasivo e demorado, exigindo acesso interno à VM, e deve ser o último recurso quando os passos anteriores não identificaram a causa.
A alternativa A começa verificando a VM de origem antes de descartar falha global, o que pode desperdiçar tempo. A alternativa C começa pelos eventos do cofre sem antes descartar falha global ou verificar se a VM está ativa, perdendo o contexto mais amplo. A alternativa D inicia pela conta de armazenamento, que é um componente específico, antes de qualquer triagem de escopo.
Árvore de Troubleshooting: Configure Azure Site Recovery for Azure resources
Legenda:
- Azul escuro: sintoma inicial ou ponto de entrada
- Azul: pergunta diagnóstica objetiva
- 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 é diretamente observável no portal ou na VM. Siga sempre o caminho que corresponde ao estado real do ambiente, sem pular perguntas. Os nós vermelhos indicam o momento em que a causa está identificada; a partir deles, siga para a ação recomendada correspondente e valide o resultado antes de encerrar o incidente.