SRM: Guia de Replicação Assíncrona entre Datacenters

A replicação assíncrona é o coração de qualquer estratégia robusta de Disaster Recovery (DR) em ambientes corporativos modernos. Ao contrário da replicação síncrona, que exige links de fibra óptica dedicados com latência extremamente baixa para garantir zero perda de dados (RPO=0), a replicação assíncrona permite distâncias maiores entre os datacenters primário e de recuperação, sacrificando apenas alguns minutos ou segundos de dados em troca de viabilidade econômica e logística.

No ecossistema VMware, essa capacidade é orquestrada principalmente pelo VMware Site Recovery Manager (SRM). Quando combinado com o armazenamento nativo do vSAN ou arrays SAN externos que suportam replicação baseada em bloco, o SRM consegue automatizar o failover de máquinas virtuais críticas. Este tutorial detalha a arquitetura, configuração e validação da replicação assíncrona, integrando conceitos modernos de VMware Cloud Foundation (VCF), NSX-T e orquestração via VMware Aria.

1. Arquitetura e Pré-requisitos da Replicação Assíncrona

Antes de iniciar a configuração, é fundamental entender os componentes que interagem na cadeia de replicação. A replicação assíncrona no VMware não ocorre isoladamente; ela depende de uma infraestrutura de storage consistente e de conectividade de rede estável.

O fluxo de dados funciona da seguinte maneira: as escritas são confirmadas localmente no site primário e, subsequentemente, enviadas ao site secundário via protocolos como iSCSI, FC ou NFS. O SRM coordena essas operações através do vCenter Server associado a cada site.

• VMware Site Recovery Manager (SRM): Responsável pela orquestração dos planos de recuperação e pela comunicação entre os sites.
• vCenter Server: Deve haver um par de vCenters, um para o site primário e outro para o secundário, ou uma instância única gerenciando múltiplos clusters em cenários de VCF.
• Storage Array: O storage deve suportar replicação assíncrona nativa (ex: Dell EMC PowerStore, HPE Nimble, NetApp) ou ser um cluster vSAN configurado para replicação assíncrona via Stretched Cluster ou Remote vSAN.
• VMware NSX-T: Essencial para a reconexão automática de redes e segurança micro-segmentada durante o failover, especialmente em ambientes híbridos.

Para garantir a integridade dos dados, verifique se a largura de banda entre os datacenters suita o throughput necessário. Uma regra prática é calcular a taxa de mudança média (change rate) das suas VMs e garantir que o link tenha pelo menos 20% a mais de capacidade do que essa taxa para evitar congestionamento durante janelas de replicação pesadas.

2. Configuração do Site Recovery Manager

A instalação do SRM é realizada como uma extensão do vCenter Server. Cada site deve ter sua própria instância do SRM, que se comunicará com a instância remota através de um canal seguro.

Inicie o assistente de instalação no servidor Windows dedicado ou na VM de appliance (se utilizando SRM 8.x em ambiente VCF) no site primário. Durante a configuração, insira as credenciais do vCenter local e, crucialmente, os detalhes de conexão do vCenter remoto.

# Exemplo de verificação de conectividade via PowerShell antes da instalação
Test-NetConnection -ComputerName <IP_DO_VCENTER_REMOTO> -Port 443

Após a instalação no site primário, repita o processo no site secundário. Ao concluir as duas instalações, você precisará "emparelhar" os sites. Isso é feito acessando a interface web do SRM (geralmente em https://<SRM_HOST>/ui/) e navegando até Site Recovery > Sites.

Clique em Add Remote Site no site primário e insira o endereço IP/FQDN e as credenciais de administrador do SRM remoto. O sistema irá estabelecer um túnel seguro. Repita a ação inversamente no site secundário para adicionar o site primário como remoto. A sincronização inicial pode levar alguns minutos dependendo da complexidade dos inventários.

3. Definição do Protocolo de Replicação

O passo seguinte é definir como os dados serão replicados. Isso varia drasticamente dependendo se você usa armazenamento nativo (vSAN) ou arrays SAN externos.

3.1. Configuração para VMware vSAN (Remote Replication)

No contexto do VMware Cloud Foundation, a replicação assíncrona é gerenciada diretamente pela interface de gerenciamento do vSAN. Não há necessidade de configurar pares de dispositivos de armazenamento manualmente como em SANs tradicionais.

1. Acesse o vCenter Server e navegue até Hosts > Clusters.
2. Selecione o cluster que participará do DR.
3. No painel lateral, vá para vSAN > Remote Replication.
4. Clique em Create Replication Target.

Você precisará definir:

• Target Site: Selecione o cluster no site secundário.
• Protection Domain: Defina quais VMs ou grupos de políticas serão replicados.
• RPO (Recovery Point Objective): Para assíncrono, selecione valores como 5 minutos, 15 minutos ou 1 hora. Valores menores aumentam a carga na rede.

O vSAN começará imediatamente a enviar deltas de blocos alterados para o site remoto. O SRM detectará automaticamente esses volumes replicados e os mapeará para as VMs correspondentes durante a criação do plano de recuperação.

3.2. Configuração para Arrays SAN Externos

Se você utiliza arrays como Dell EMC, HPE ou NetApp, o processo é mais manual:

1. No vCenter, vá para Storage > Devices.
2. Localize os LUNs que contêm as VMs.
3. Clique com o botão direito e selecione Manage Replication.
4. Escolha o provedor de replicação do seu array (ex: "Dell EMC PowerMax").
5. Siga o wizard para criar um par de replicação, apontando para o LUN destino no site secundário.

O SRM deve ser configurado para reconhecer esse tipo de storage. Vá até Site Recovery > Storage Providers e adicione o provedor correspondente ao seu array, inserindo as credenciais de API do storage manager.

4. Criação do Plano de Recuperação (Recovery Plan)

O plano de recuperação é onde a mágica do DR acontece. Ele define a ordem de inicialização das VMs, o mapeamento de redes e as ações pré/pós-failover.

1. Acesse o SRM no site primário e clique em Create Recovery Plan.
2. Dê um nome descritivo ao plano (ex: "ERP-Critical-DR").
3. Selecione as VMs que deseja incluir. O SRM identificará automaticamente os discos que possuem réplicas assíncronas.

A etapa crítica é o mapeamento de rede. Em um cenário assíncrono, as redes lógicas no site secundário (NSX-T ou VLANs físicas) geralmente têm diferentes IDs ou nomes das do site primário.

No SRM, vá para a aba Network Mapping. Para cada interface de rede da VM no site primário, selecione a correspondente no site secundário. Se estiver usando VMware NSX-T, o mapeamento é feito via Logical Switch ID ou Segment ID. Certifique-se de que as regras de segurança (Security Groups) do NSX-T estão replicadas ou recriadas no site secundário para evitar bloqueios de tráfego após o failover.

Configure também a Boot Order. Bancos de dados e servidores de aplicação devem iniciar antes dos servidores web. Use a interface drag-and-drop do SRM para definir essa prioridade. Isso reduz significativamente o RTO (Recovery Time Objective).

5. Integração com VMware Aria Automation (VRA)

Para ambientes que utilizam infraestrutura como código, a integração com VMware Aria permite automatizar não apenas a recuperação, mas também a validação e o failback.

No VMware Aria Automation, você pode definir templates de recuperação que invocam APIs do SRM. Isso é útil para cenários de DR "as-a-Service", onde clientes internos solicitam testes de recuperação sob demanda.

# Exemplo conceitual de payload JSON para disparar um plano via API do SRM
POST /rest/vum/disaster_recovery/plans/{planId}/execute
{
  "action": "PLAN_RECOVERY",
  "params": {
    "failoverMode": "STAGED" 
  }
}

O uso de Staged Recovery (Recuperação Estagiada) é altamente recomendado. Diferente do failover completo, o staged recovery inicia as VMs no site secundário em modo "read-only" ou isolado, permitindo validar a integridade dos dados sem interromper o ambiente primário. O Aria pode orquestrar essa validação e, se aprovado, executar o failover final.

6. Execução de Testes de Failover

Nunca confie em uma solução de DR que não foi testada. Execute testes regulares para garantir que a replicação assíncrona está funcionando e que os planos são eficazes.

1. No SRM, selecione o Plano de Recuperação criado.
2. Clique em Recovery > Test Recovery.
3. Escolha o modo Isolated. Isso garante que as VMs testadas não interfiram na produção nem no ambiente secundário real.

O SRM irá provisionar as VMs em uma rede de teste isolada (vSwitch virtual ou VLAN dedicada). Aguarde até que o status indique Test Completed.

Conecte-se às VMs testadas via console ou RDP/SSH. Verifique:

• A integridade dos sistemas operacionais.
• O acesso aos bancos de dados.
• A funcionalidade das aplicações críticas.

Após o teste, é necessário limpar os recursos alocados para o teste. Clique em Test Recovery > Complete Test. Isso desliga e remove as VMs temporárias do site secundário, liberando recursos de CPU e RAM.

7. Monitoramento e Troubleshooting

A replicação assíncrona pode sofrer degradação devido a picos de I/O ou instabilidade na rede. Monitore os indicadores de saúde no vCenter e no SRM.

Indicadores Críticos:

• Lag da Replicação: Se o atraso entre o site primário e secundário exceder o RPO configurado, a replicação pode entrar em modo de "fail-safe" ou parar. Verifique a aba Replication no vCenter.
• Erro de Snapshot: Erros comuns incluem falta de espaço em disco nos repositórios de snapshot do SRM ou permissões inadequadas.

Se você encontrar erros persistentes, verifique os logs no diretório C:\ProgramData\VMware\vSphere HA\ (Windows) ou nos logs do appliance (Linux) para mensagens relacionadas a timeouts de conexão ou falhas de handshake SSL entre os vCenters.

Além disso, em ambientes com NSX-T, certifique-se de que as regras de firewall distribuído (DFW) não estão bloqueando o tráfego de replicação entre os transport zones dos dois sites. O tráfego de replicação do vSAN ou SAN utiliza portas específicas (ex: 443 para HTTPS, 2050-2060 para vSAN replication).

8. Considerações Finais sobre RPO e RTO

A escolha pela replicação assíncrona implica em aceitar um RPO maior que zero. Para a maioria das aplicações empresariais (ERP, CRM, Intranet), um RPO de 5 a 15 minutos é aceitável e economicamente viável.

No entanto, para sistemas financeiros transacionais ou saúde crítica, considere:

• Aumentar a frequência da replicação assíncrona (ex: cada minuto).
• Utilizar snapshots incrementais frequentes antes do failover para reduzir a janela de perda de dados.
• Avaliar a migração para soluções híbridas, onde o tier crítico usa síncrono e o resto usa assíncrono.

Lembre-se: a tecnologia é apenas parte da equidade. Processos documentados, treinamento da equipe de operações e testes regulares são tão importantes quanto a configuração do SRM. Com uma implementação sólida de replicação assíncrona, sua organização estará preparada para resilir contra desastres naturais, falhas de hardware em escala ou ransomware, garantindo a continuidade dos negócios com mínima interrupção.

A integração contínua entre VMware VCF, automação via Aria e segurança de rede com NSX-T transforma o DR de um exercício burocrático em uma competência estratégica de infraestrutura, permitindo que a TI foque na inovação enquanto a disponibilidade é garantida por design.