SRM: Como Executar Simulação de Failover no VMware

O que é SRM e por que validar o plano de recuperação?

O VMware Site Recovery Manager (SRM) é uma solução robusta de Disaster Recovery (DR) projetada para automatizar a recuperação de máquinas virtuais entre sites. No entanto, um plano de DR não validado é apenas uma promessa. A execução de testes simulados (Simulated Failover) é o processo crítico que garante que a configuração está correta, as políticas de replicação estão sincronizadas e, principalmente, que os scripts pós-recuperação funcionam como esperado.

Diferente de um failover real, a execução simulada não interrompe os serviços no site primário. Ela cria cópias isoladas das VMs no site secundário, aplica as transformações necessárias (como mudança de IP e DNS) e, em seguida, desfaz todas as alterações, restaurando o ambiente ao estado original sem impacto na produção. Este tutorial detalha como realizar esse teste com segurança.

Pré-requisitos e Verificações Iniciais

Antes de iniciar o processo de simulação, é fundamental garantir que a infraestrutura esteja preparada. A ausência dessas verificações pode levar a falhas no teste ou, pior, na recuperação real durante um desastre.

1. Sincronização do Relógio: Certifique-se de que os servidores vCenter em ambos os sites (primário e secundário) estejam sincronizados via NTP. Diferenças de horário podem causar falhas na replicação ou no reconhecimento dos objetos.
2. Permissões Adequadas: O usuário utilizado para executar o teste deve ter permissões de administrador no vCenter do site primário e, preferencialmente, direitos de leitura/escrita limitados no site secundário para a execução da simulação.
3. Recursos no Site Secundário: Verifique se há recursos de CPU e memória suficientes no cluster de DR. O teste consome recursos temporários até ser desfeito.
4. Integridade da Replicação: No painel do SRM, confirme que o status de replicação das VMs alvo está como Synchronized. Se houver atrasos ou erros de replicação, o teste pode resultar em dados inconsistentes.
5. Compatibilidade com NSX-T (Se Aplicável): Se estiver utilizando VMware NSX-T para redes definidas por software, certifique-se de que os componentes de segurança e as políticas de rede estão replicados ou mapeados corretamente no site secundário. O SRM precisa interagir com o NSX Manager para reconfigurar as interfaces de rede das VMs durante a recuperação.

Passo 1: Acessando o Console do Site Recovery Manager

O gerenciamento do SRM é feito através da interface web do vSphere Client ou diretamente no console dedicado do SRM. Para este tutorial, utilizaremos a abordagem padrão via vSphere Client integrado.

Navegue até o host ou cluster onde o serviço SRM está registrado e clique na aba Site Recovery. Se você não visualizar essa aba, verifique se o plugin foi carregado corretamente. No painel lateral esquerdo, expanda a árvore de inventário para localizar os Recovery Plans (Planos de Recuperação).

Dica Técnica: Se estiver gerenciando múltiplos sites, certifique-se de estar conectado ao vCenter do site primário. A ação de iniciar o teste será orquestrada a partir daqui.

Passo 2: Selecionando e Iniciando o Plano de Recuperação

Clique no nome do Plano de Recuperação que deseja testar. Isso abrirá um painel detalhado mostrando o status atual, os grupos de VMs e as dependências configuradas.

1. No canto superior direito do painel do plano, clique no botão Run (Executar).
2. O assistente de teste será aberto. Selecione a opção Simulated Failover.
   Não selecione "Planned Failover" ou "Unplanned Failover", pois estes modos alteram o estado de produção.
3. Clique em Next.

O SRM irá realizar uma pré-verificação automática. Esta etapa é crucial, pois simula todas as etapas da recuperação real para identificar conflitos potenciais antes de executá-los.

Passo 3: Análise dos Resultados da Pré-Verificação

A tela de verificação apresentará uma lista de checklists. Cada item representará um aspecto da infraestrutura, desde a conectividade de rede até a disponibilidade de armazenamento.

• Status Passed: Indicadores verdes significam que o ambiente está pronto para o teste.
• Status Failed: Indicadores vermelhos indicam bloqueios. Exemplos comuns incluem: VMs ligadas no site secundário (que devem estar desligadas para replicação), falta de permissão de acesso ao datastore, ou incompatibilidade de versão do ESXi.
• Warnings: Alertas que não impedem o teste, mas podem afetar o resultado (ex: espaço em disco baixo no site secundário).

Se houver erros críticos, clique nos detalhes para investigar. Corrija os problemas identificados (como mover VMs conflitantes ou ajustar permissões) e tente novamente. Somente quando todos os itens estiverem com status Passed o botão Finish ficará habilitado.

Passo 4: Execução da Simulação

Ao clicar em Finish, o SRM iniciará a tarefa de simulação. Você verá uma barra de progresso no painel inferior do vSphere Client. Este processo pode levar minutos ou horas, dependendo do número de VMs e da latência entre os sites.

Durante esta fase, o SRM realiza as seguintes operações internamente:

1. Criação de Cópias: O SRM solicita ao vSphere que clone as VMs replicadas no site secundário.
2. Inicialização (Power On): As cópias são ligadas no ambiente isolado do site de DR.
3. Transformação de Rede: Aqui entra a complexidade com VMware Aria (antigo vRealize Automation) ou scripts personalizados. O SRM aplica as regras de mapeamento de rede definidas no plano. Se você estiver usando VMware VCF (VMware Cloud Foundation), o sistema garante que as redes lógicas do NSX sejam respeitadas, mudando as VMs para a sub-rede de recuperação correta.
4. Execução de Scripts Pós-Recovery: Se configurados, os scripts vROps ou PowerShell definidos no plano serão executados. Isso valida se serviços dependentes (como SQL Server, Active Directory) iniciam corretamente após a mudança de IP.

Nota sobre VMware NSX-T: Em ambientes com NSX-T, o SRM deve ter permissão para reconfigurar os adaptadores de rede das VMs. Durante a simulação, observe se as VMs obtêm endereços IP corretos via DHCP ou estáticos, conforme mapeado no plano de recuperação.

Passo 5: Validação dos Resultados

Após a conclusão da tarefa, o status do plano mudará para Simulated Failover Completed. É hora de validar se tudo funcionou como esperado.

1. No mesmo painel do Plano de Recuperação, clique em View Details ou navegue até a seção de logs da execução.
2. Verificação de Rede: Acesse o console virtual das VMs no site secundário (via Console HTML/Flash) e verifique se os endereços IP estão corretos. Se estiver usando VMware Aria para automação, confirme que a configuração de rede foi aplicada dinamicamente.
3. Verificação de Aplicação: Execute comandos básicos de conectividade dentro das VMs testadas. Por exemplo:

# Verificar conectividade com banco de dados dependente
ping <IP_DO_BANCO_DE_DADOS>

# Verificar status do serviço crítico
systemctl status nginx

Se os scripts pós-recuperação foram usados, verifique seus logs no diretório C:\ProgramData\VMware\vRops (no Windows) ou /var/log/vmware/ (no Linux) para confirmar a execução bem-sucedida.

Passo 6: Desfazendo o Teste (Undo Simulated Failover)

A vantagem crítica da simulação é que ela não deixa resíduos. No entanto, as VMs de teste ainda estão ligadas no site secundário e consomem recursos. Você deve desfazer a operação para limpar o ambiente.

1. No painel do Plano de Recuperação, clique novamente em Run.
2. Selecione a opção Undo Simulated Failover.
3. Clique em Next e confirme a ação.

O SRM irá:

1. Desligar as VMs de teste no site secundário.
2. Remover as cópias clonadas do armazenamento.
3. Restaurar o inventário e as configurações de rede ao estado original.

Atenção: Não desligue manualmente as VMs ou exclua os discos pelo vSphere Client durante este processo. Isso corrompe o registro do SRM e pode impedir futuras execuções, exigindo intervenção manual complexa para reparar o estado da replicação.

Bônus: Integração com Veeam e VMware VCF

Embora o SRM nativo seja poderoso, muitos ambientes modernos utilizam estratégias híbridas ou plataformas unificadas.

Veeam para VMware

O Veeam oferece uma integração nativa com o SRM. Se você utiliza Veeam como solução de backup e replicação leve, pode usar o Veeam para iniciar testes de failover simulados diretamente pelo console do Veeam Backup & Replication. Isso é particularmente útil em ambientes onde a replicação contínua do vSphere Replication não é viável devido a custos de licença ou largura de banda.

VMware Cloud Foundation (VCF)

No ecossistema VMware VCF, o SRM é integrado ao SDDC Manager. A automação é mais profunda, permitindo que testes de recuperação sejam orquestrados junto com a validação da infraestrutura subjacente (NSX e vSAN). Em VCF, os testes simulados devem considerar a topologia de armazenamento distribuído e as políticas de desempenho do cluster.

Melhores Práticas para Manutenção Contínua

A execução de um teste é apenas o início. Para manter a confiabilidade do seu plano de DR:

• Frequência: Execute testes simulados regularmente (mensalmente ou trimestralmente). Mudanças na infraestrutura, patches e atualizações de VMware Aria podem quebrar configurações antigas.
• Documentação: Registre os resultados de cada teste. Se um script falhar, documente a correção aplicada.
• Monitoramento com vROps: Utilize o VMware Aria Operations para monitorar a saúde da replicação em tempo real. Crie alertas customizados que notifiquem quando a latência de replicação exceder um limite aceitável.
• Validação de Scripts: Mantenha seus scripts de pós-recuperação (PowerShell/Bash) versionados no Git. Isso permite revisar mudanças e testar a sintaxe antes de implementá-las no SRM.

Conclusão

A execução simulada de testes de failover no VMware SRM é a única maneira de garantir que seu plano de Disaster Recovery funcionará quando a crise chegar. Ao seguir estes passos rigorosamente, você minimiza riscos operacionais e valida não apenas a infraestrutura de virtualização, mas também as camadas superiores de rede com NSX-T, automação com VMware Aria e integrações externas como Veeam.

Lembre-se: um teste sem desfazimento (undo) adequadamente executado pode resultar em duplicidade de IP e conflitos de rede que impactam a produção. Sempre utilize o botão "Undo Simulated Failover" dentro do console SRM para manter a integridade do ambiente.