Laboratório de Troubleshooting: Perform a Failover to a Secondary Region by Using Site Recovery
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um administrador tenta iniciar um failover não planejado de uma VM chamada prod-app-vm para a região secundária após uma indisponibilidade na região primária. O Recovery Services Vault está configurado na região secundária. A VM possui um disco de sistema operacional e dois discos de dados.
No portal do Azure, ao clicar em "Failover", o assistente apresenta a seguinte mensagem e não permite prosseguir:
Error: The virtual machine 'prod-app-vm' is not in a protected state.
Replication health: Critical
Last successful recovery point: 72 hours ago
Pending actions: None
O administrador verifica que a VM de origem ainda está em execução na região primária e que o Recovery Services Vault existe e está acessível. A conta de armazenamento de cache usada pela replicação está na mesma região da VM de origem e foi criada há seis meses. Ele também nota que a assinatura atingiu o limite de núcleos disponíveis na região secundária há três dias, mas o problema foi resolvido ontem com um aumento de cota aprovado.
Qual é a causa raiz que impede o failover?
A) O limite de cota de núcleos na região secundária ainda está ativo, impedindo a criação de recursos durante o failover.
B) A replicação está em estado crítico, possivelmente por falha na transferência de dados para a conta de armazenamento de cache, o que resultou em ausência de pontos de recuperação recentes válidos.
C) O Recovery Services Vault está na região incorreta; ele deveria estar na região de origem, não na secundária.
D) A VM de origem está em execução, e o Site Recovery exige que ela seja desligada antes de iniciar um failover não planejado.
Cenário 2 — Decisão de Ação
A equipe de operações executou com sucesso um failover não planejado de toda a camada de aplicação para a região secundária. O failover foi concluído há 40 minutos. Os sistemas estão operacionais e os usuários foram redirecionados. A causa raiz da falha na região primária foi identificada: uma atualização de firmware em um conjunto de hosts físicos causou indisponibilidade temporária. A Microsoft confirmou que a região primária voltará ao normal em aproximadamente duas horas.
A equipe quer garantir que, assim que a região primária for restaurada, possam retornar as cargas de trabalho para ela com proteção de replicação ativa.
A causa identificada é: o failover foi executado mas ainda não foi confirmado (commit não realizado).
Qual é a ação correta a tomar neste momento?
A) Executar o failback imediatamente para a região primária enquanto ela ainda está em processo de recuperação, aproveitando o estado pendente do failover para reverter sem necessidade de commit.
B) Executar o "Commit" do failover agora para finalizar o estado das VMs na região secundária e, em seguida, aguardar a recuperação da região primária para executar o "Re-protect".
C) Executar o "Re-protect" imediatamente, sem realizar o commit, para antecipar a configuração da replicação inversa enquanto a região primária se recupera.
D) Descartar o failover ("Discard Failover") para manter o estado original e aguardar o retorno completo da região primária antes de qualquer ação.
Cenário 3 — Causa Raiz
Uma VM chamada db-primary-vm foi replicada com sucesso para a região secundária durante três meses. O administrador executa um failover de teste bem-sucedido na semana anterior. Hoje, ao executar o failover real (não planejado), a VM sobe na região secundária, mas a aplicação não consegue se conectar ao banco de dados.
O administrador verifica o seguinte:
# Saída do comando az vm list-ip-addresses na regiao secundaria
{
"virtualMachine": {
"name": "db-primary-vm",
"network": {
"privateIpAddresses": ["10.1.0.5"]
}
}
}
A configuração original da VM na região primária era:
| Propriedade | Região Primária | Região Secundária (observado) |
|---|---|---|
| IP privado | 10.0.0.5 | 10.1.0.5 |
| Nome da VM | db-primary-vm | db-primary-vm |
| Rede virtual | vnet-primary | vnet-secondary |
| Grupo de segurança | nsg-db | nsg-db |
A string de conexão da aplicação usa o endereço IP 10.0.0.5 fixo no arquivo de configuração. O administrador nota que o NSG aplicado à VM na região secundária é o mesmo utilizado na primária e que a porta 1433 está liberada.
Qual é a causa raiz da falha de conectividade?
A) O NSG herdado da região primária está bloqueando conexões de entrada na rede virtual secundária por diferença de regras de rota.
B) O endereço IP da VM na região secundária é diferente do IP configurado na string de conexão da aplicação, que aponta para o IP original da região primária.
C) A rede virtual secundária não está emparelhada com a rede primária, impedindo que a aplicação alcance o banco de dados.
D) O failover de teste da semana anterior corrompeu o estado da replicação, fazendo com que o IP original não fosse preservado no failover real.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe um alerta informando que a integridade da replicação de um grupo de VMs está em estado de aviso ("Warning") no Recovery Services Vault. Nenhum failover foi executado. As VMs continuam em execução na região primária.
Os passos de investigação disponíveis estão fora de ordem:
- Verificar se há espaço disponível na conta de armazenamento de cache e se ela está acessível.
- Consultar o painel "Replication Health" do vault para identificar quais VMs específicas estão em estado de aviso.
- Verificar os eventos de replicação da VM afetada no vault para identificar mensagens de erro específicas.
- Confirmar se o agente de mobilidade instalado na VM está na versão compatível com a configuração atual do vault.
- Verificar a conectividade de saída da VM de origem para as URLs do Site Recovery exigidas pela Microsoft.
Qual é a sequência correta de investigação?
A) 1 → 5 → 2 → 3 → 4
B) 2 → 3 → 5 → 1 → 4
C) 4 → 2 → 3 → 1 → 5
D) 2 → 1 → 5 → 4 → 3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na saída do portal: Replication health: Critical e Last successful recovery point: 72 hours ago. Isso indica que a replicação interrompeu a transferência de dados para a conta de armazenamento de cache, tornando os pontos de recuperação obsoletos. O Site Recovery bloqueia o failover quando não há um ponto de recuperação válido e recente, pois não há garantia de consistência dos dados.
A informação sobre o limite de cota de núcleos (alternativa A) é propositalmente irrelevante: o enunciado confirma que o problema foi resolvido no dia anterior. Focar nesse dado é um erro clássico de diagnóstico por ancoragem no evento mais recente percebido como negativo.
A alternativa C está incorreta: o Recovery Services Vault deve residir na região secundária, que é o destino da replicação. A alternativa D representa um equívoco frequente; o failover não planejado não exige que a VM de origem seja desligada previamente, ao contrário do failover planejado.
O distrator mais perigoso é A, porque o problema de cota foi real e recente, levando o administrador a agir sobre a infraestrutura de cota em vez de investigar o estado da replicação.
Gabarito — Cenário 2
Resposta: B
O enunciado declara explicitamente que o commit ainda não foi executado. O commit é o passo que finaliza formalmente o failover, consolida o estado das VMs na região secundária e descarta os pontos de recuperação anteriores. Sem ele, o failover permanece em estado pendente e o "Re-protect" não pode ser iniciado.
A alternativa C representa o erro mais comum nesse contexto: tentar executar o "Re-protect" sem antes realizar o commit. O Site Recovery não permite essa operação fora de ordem; ela resultará em erro.
A alternativa A é perigosa porque a região primária ainda está indisponível. Executar failback para uma região em recuperação é uma decisão de alto risco que pode resultar em perda de dados ou em um segundo failover não planejado em seguida.
A alternativa D descartaria todo o trabalho já realizado e retornaria as VMs ao estado anterior ao failover, o que conflita diretamente com o objetivo declarado da equipe de manter as operações na região secundária e preparar a replicação inversa.
Gabarito — Cenário 3
Resposta: B
A causa está diretamente visível na tabela de comparação: o IP privado da VM na região secundária é 10.1.0.5, enquanto a string de conexão da aplicação aponta para 10.0.0.5, que era o IP na região primária. O Site Recovery não garante preservação de endereço IP quando a sub-rede de destino possui um bloco de endereçamento diferente.
A informação sobre o failover de teste da semana anterior (alternativa D) é irrelevante e foi incluída propositalmente. Um failover de teste bem-sucedido não altera o IP que será atribuído no failover real, e não interfere na lógica de atribuição de IPs da rede de destino.
A alternativa A é um distrator plausível, pois NSGs podem causar falhas de conectividade, mas o enunciado confirma que a porta 1433 está liberada. A alternativa C descreve um problema real em outros contextos, mas não há nenhuma indicação no enunciado de que a aplicação tenta alcançar a rede primária; ela simplesmente usa um IP fixo que agora não existe mais naquele endereço.
O impacto de não identificar essa causa é crítico: o administrador pode perder horas investigando NSGs e peering de rede enquanto a causa real é a configuração estática de IP na aplicação.
Gabarito — Cenário 4
Resposta: B
A sequência correta é 2 → 3 → 5 → 1 → 4, que segue a lógica de diagnóstico do geral para o específico:
- Passo 2 identifica quais VMs estão afetadas antes de qualquer investigação técnica. Sem isso, todos os passos seguintes são investigação às cegas.
- Passo 3 examina os eventos da VM afetada para obter a mensagem de erro específica, que orienta os passos seguintes.
- Passo 5 verifica conectividade de saída, que é a causa mais frequente de interrupção de replicação em ambientes corporativos com proxy ou firewall restritivo.
- Passo 1 valida a conta de armazenamento de cache, que é verificada após descartar problemas de conectividade.
- Passo 4 verifica a versão do agente de mobilidade, que é a causa menos provável de um estado de aviso súbito em um ambiente que funcionava corretamente, sendo o passo de verificação mais específico e demorado.
A alternativa C é o distrator mais perigoso porque começa pela versão do agente, que é uma verificação válida mas de baixa prioridade quando o ambiente estava funcionando recentemente. Isso leva o administrador a uma verificação demorada e potencialmente desnecessária antes de investigar causas mais prováveis.
Árvore de Troubleshooting: Perform a Failover to a Secondary Region by Using Site Recovery
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
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 ou nos logs. Siga o ramo correspondente à sua resposta sem pular etapas. Cada caminho termina em uma causa identificada seguida de uma ação concreta. Resistir ao impulso de agir antes de chegar a um nó vermelho é a disciplina central que esta árvore reforça.