Planos de recuperação e failover automatizado

Um Recovery Plan no Azure Site Recovery é uma sequência estruturada e ordenada de etapas que coordena o failover de várias VMs em conjunto. Em vez de realizar o failover de cada VM individualmente, um Recovery Plan as agrupa em grupos que executam o failover em sequência, garantindo que a infraestrutura (banco de dados, middleware e camada web) seja iniciada na ordem correta, assim como ocorreria durante a implantação inicial.

Para criar um Recovery Plan, selecione o site de origem (região primária) e o site de destino (região secundária) e adicione as VMs que deseja incluir. O assistente do plano cria automaticamente um grupo padrão, mas você pode adicionar mais grupos para controlar a sequência de failover. As VMs no mesmo grupo executam o failover simultaneamente; os grupos são executados na ordem numérica.

Para uma aplicação típica de três camadas, o Recovery Plan deve ter três grupos:

• Grupo 1 — VMs da camada de banco de dados (devem ser iniciadas primeiro)
• Grupo 2 — VMs da camada de aplicação/middleware
• Grupo 3 — VMs da camada de apresentação web (iniciadas por último)

Cada grupo aguarda a conclusão bem-sucedida do failover do grupo anterior antes de iniciar. Isso reproduz a ordem correta de inicialização e impede que as VMs da camada web sejam iniciadas antes que o banco de dados esteja pronto para aceitar conexões.

Os Recovery Plans são compatíveis com ações anteriores e ações posteriores nos limites de cada grupo. Elas podem ser:

• Ações manuais — pausam o failover e aguardam a confirmação de uma pessoa (por exemplo, “Verificar se o banco de dados está pronto”)
• runbooks do Azure Automation — executam automaticamente um script (por exemplo, atualizar registros DNS e desabilitar o modo de manutenção)

O uso de runbooks do Automation permite um failover totalmente automatizado, sem intervenção humana, para cargas de trabalho do nível 1.

O Azure Site Recovery é compatível com dois tipos de failover:

• Failover planejado — iniciado antes de um evento conhecido (por exemplo, manutenção do centro de dados). A VM primária é desligada de forma limpa, os dados são sincronizados e, em seguida, a VM secundária é iniciada. Não há perda de dados.
• Failover não planejado — acionado durante um desastre real. A VM primária pode estar indisponível, portanto o ASR usa o ponto de verificação de replicação mais recente. É possível ocorrer alguma perda de dados, dependendo do RPO.

Após um failover, as VMs recuperadas na região secundária ficam no estado commit pendente. Você deve confirmar o failover para indicar que o site secundário agora é o site ativo e que não deseja reverter a operação. Depois da confirmação, você pode configurar a replicação reversa para proteger o site secundário e, posteriormente, fazer o failback para a região primária quando ela for restaurada.

Após confirmar um failover, os itens replicados na região primária original deixam de ser replicados ativamente. Para restaurar a proteção, você deve reproteger os itens — isso inverte a direção da replicação, fazendo com que a nova região primária (antes secundária) replique para a região primária original. O restabelecimento da proteção leva tempo e deve ser iniciado assim que a região primária original estiver disponível novamente.

Cada etapa de um plano de recuperação contribui para o RTO total. Os principais fatores que consomem tempo incluem:

• Tempo de inicialização das VMs (2 a 5 minutos por VM)
• Tempo de aquecimento da aplicação (inicialização do pool de conexões do banco de dados e aquecimento do cache)
• Propagação do DNS após alterações nos endereços IP
• Tempo de espera por aprovações manuais

Meça cada etapa durante os failovers de teste e some os tempos para calcular seu RTO real e compará-lo com o seu objetivo.

Após um failover, as VMs na região secundária têm endereços IP diferentes. Para aplicações que expõem um nome DNS público, é necessário atualizar o DNS para apontar para os novos IPs. Use um runbook de Automação do Azure como ação pós-failover para atualizar o DNS do Azure ou a integridade dos pontos de extremidade do Traffic Manager e redirecionar o tráfego automaticamente — evitando uma etapa manual que poderia atrasar o RTO.

Durante um failover, a exibição de trabalhos do portal do Azure no cofre dos Serviços de Recuperação mostra o progresso em tempo real de cada etapa do plano de recuperação. É possível ver qual grupo está sendo executado, quais VMs foram iniciadas com sucesso e se há scripts ou ações manuais pendentes. Monitorar essa exibição permite que a equipe de recuperação intervenha rapidamente caso uma etapa falhe.

Principais práticas recomendadas para planos de recuperação:

• Mantenha os grupos pequenos (5 a 10 VMs) para limitar o impacto caso um grupo falhe
• Use runbooks de Automação em vez de ações manuais sempre que possível para reduzir o RTO
• Documente o tempo de inicialização esperado de cada grupo para que o RTO possa ser calculado
• Execute um failover de teste pelo menos trimestralmente para validar o plano
• Revise e atualize o plano sempre que novas VMs forem adicionadas ou a arquitetura da aplicação for alterada

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

Nesta lição, você aprendeu que: um plano de recuperação orquestra o failover ordenado de várias VMs, com ações anteriores e posteriores em cada grupo; o failover não planejado usa o último ponto de verificação da replicação, enquanto o failover planejado não causa perda de dados; e, após o failover, é necessário confirmar e reproteger para restaurar a proteção de DR. A seguir, exploraremos como testar planos de DR sem afetar a produção.