Testando e Executando o Failover

Um plano de recuperação de desastre que nunca foi testado é apenas uma hipótese. O teste de failover permite validar se as VMs são inicializadas corretamente, se os aplicativos são iniciados e se a conectividade de rede funciona na região de destino — tudo isso sem interromper o ambiente de origem nem comprometer a replicação em andamento. Muitas organizações descobrem que seus planos de DR têm falhas somente quando ocorre um desastre real, exatamente quando um plano defeituoso causa o maior dano. Testes regulares de failover são uma exigência de conformidade para a maioria das estruturas regulatórias.

O ASR é compatível com três tipos de ações de failover. O teste de failover cria cópias das VMs que sofreram failover em uma rede isolada, na qual você especifica a VNet de destino, sem afetar a replicação nem o ambiente de origem. O failover planejado é usado para migrações ou manutenções agendadas — primeiro sincroniza as alterações restantes e, em seguida, desliga a origem antes de executar o failover. O failover não planejado, usado durante um desastre real, executa o failover imediatamente a partir do ponto de recuperação mais recente, sem aguardar uma sincronização final.

Para executar um teste de failover no portal: selecione o item protegido, clique em Teste de failover, escolha um ponto de recuperação — o mais recente consistente com falhas, o mais recente consistente com o aplicativo ou um ponto específico no tempo — e selecione uma rede virtual de destino, normalmente uma VNet de teste isolada e dedicada. O ASR inicia a VM na região de destino usando os discos de réplica. A VM de teste aparece ao lado da réplica, mas é completamente independente — a produção não é afetada. Depois do teste, clique em Limpar teste de failover para excluir as VMs de teste.

Durante o failover, você seleciona um ponto de recuperação na janela de retenção do ASR. As opções são: Mais recente (menor RPO) — o ponto de recuperação mais atual, consistente com falhas, minimizando a perda de dados. Mais recente processado — o ponto processado mais recentemente, que pode estar alguns minutos atrasado. Mais recente consistente com o aplicativo — o ponto de recuperação mais recente consistente com o aplicativo, que pode ser mais antigo, mas garante uma recuperação limpa do aplicativo. Personalizado — um ponto de recuperação específico e mais antigo para recuperar o sistema para um estado íntegro conhecido anterior a um incidente.

Um plano de recuperação agrupa várias VMs protegidas e define a sequência e o momento do failover delas. Você pode especificar quais VMs serão inicializadas primeiro, como servidores de banco de dados antes dos servidores de aplicativos, adicionar etapas de aprovação manual para pausar o failover e permitir a validação humana e inserir runbooks do Azure Automation para executar scripts antes e depois do failover, como atualizar registros DNS, configurar balanceadores de carga ou enviar notificações. Os planos de recuperação podem ser testados de forma independente com um teste de failover.

Um teste de failover oferece a oportunidade de medir o seu RTO (objetivo de tempo de recuperação) real. Inicie um cronômetro quando iniciar o failover e pare-o quando o aplicativo estiver totalmente funcional e acessível aos usuários. Um failover do Azure para o Azure normalmente é concluído em 15 a 30 minutos para uma única VM, mas aplicativos de várias camadas com dependências podem levar mais tempo. Documente todas as etapas que adicionarem tempo inesperado, como a propagação do DNS e o aquecimento do aplicativo, e resolva-as antes do próximo teste.

Após um failover planejado, como uma migração para uma nova região, execute Confirmar para finalizar o failover. A confirmação interrompe a replicação de volta a partir da origem e marca as VMs de destino como as novas VMs primárias. Depois da confirmação, você poderá habilitar a reproteção para inverter a direção da replicação, tornando a região de origem original o novo destino de DR. Isso permite executar o failback para a região original após a resolução do incidente.

Failback é o processo de devolver as cargas de trabalho à região original após um desastre ou uma migração planejada. As etapas são: reproteger as VMs que sofreram failover, invertendo a replicação para replicar da nova VM primária de volta para a região original; aguardar a conclusão da sincronização inicial; e executar um failover planejado de volta para a região original. O failback exige que a infraestrutura de origem original ainda esteja intacta — se ela tiver sido destruída, talvez seja necessário reconstruir a zona de destino antes de executar o failback.

Depois de um teste de failover, você deve executar Limpar teste de failover no portal para excluir as VMs de teste e os discos associados. Sem a limpeza, as VMs de teste continuarão em execução e acumulando custos de computação. A etapa de limpeza também redefine o status de teste de failover do item protegido, permitindo executar outro teste no futuro. Automatizar a limpeza, por exemplo, agendando-a para uma hora após o início do teste por meio de um runbook do Automation, evita que VMs de teste esquecidas permaneçam em execução por dias.

Todo teste de DR deve gerar um relatório do exercício de DR contendo: a data e o cenário testado, os pontos de recuperação usados, o RTO e o RPO alcançados, os problemas descobertos e as ações de correção realizadas. Essa documentação atende aos requisitos de auditoria de estruturas como ISO 27001 e SOC 2, que exigem testes regulares de DR. Armazene os relatórios dos exercícios em um local seguro, acessível às equipes de IT e de continuidade dos negócios.

Os preços do Azure Site Recovery são aplicados por instância protegida por mês — a tarifa cobre tanto o serviço de replicação quanto a orquestração. Também são cobrados o armazenamento consumido pelos discos de réplica gerenciados na região de destino e a conta de armazenamento de cache durante a replicação. A transferência de dados de saída entre regiões do Azure para o tráfego de replicação é cobrada pelas tarifas normais de saída, ao contrário do Azure Backup, no qual a saída entre regiões emparelhadas é gratuita. Na replicação do ambiente local para o Azure, as licenças do Windows Server para VMs do Azure podem usar o Azure Hybrid Benefit para reduzir os custos.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) abordados nesta lição.

Nesta lição, você aprendeu que o teste de failover valida seu plano de DR em uma rede isolada sem afetar a produção; os planos de recuperação organizam a sequência do failover de várias VMs com etapas manuais de aprovação e etapas de runbooks de automação; e o failback devolve as cargas de trabalho à região original invertendo a direção da replicação após um desastre. A seguir, exploraremos o Azure CDN para acelerar a entrega global de conteúdo.