Habilitar a proteção de VM no Azure Site Recovery

Artigo
03/22/2025

Depois que os ambientes de destino e de origem estiverem configurados, você poderá começar a habilitar a proteção de VMs (da origem ao destino). Toda a configuração é realizada no ambiente de destino, dentro do próprio cofre do Site Recovery.

Pré-requisitos

Você pode configurar a política de replicação para as respetivas VMs que deseja proteger no cofre do Site Recovery. Essas VMs estão no ambiente de origem, onde configuraram uma estrutura específica de grupo de recursos, redes virtuais, IPs públicos e NSGs.

A Recuperação de Site ajuda a replicar todos os dados da VM em si, mas antes de iniciar isso, verifique se os seguintes pré-requisitos são atendidos:

A conectividade de rede de destino está configurada.
As redes virtuais de destino são configuradas - onde cada uma das VMs protegidas é conectada quando ocorre um failover.
A assinatura de usuário de destino tem alocação de cota de computação suficiente para todas as VMs que você planeja potencialmente fazer failover.
Essas redes virtuais podem ser configuradas da mesma maneira que as redes de origem ou podem ter um design diferente, dependendo do seu plano e objetivo de recuperação de desastres.
Certifique-se de que os novos IPs públicos e privados funcionem como esperado para as cargas de trabalho específicas que está a proteger (quando ocorrem falhas, as VMs com falha têm IPs do ambiente de destino).
A configuração desejada do grupo de recursos é criada.
Ao configurar a replicação, você também pode criar os grupos de recursos, mas para um ambiente de produção, você deve pré-criá-los de acordo com sua política de nomenclatura e estrutura.
Certifique-se de que o RBAC correto seja atribuído e que a marcação esteja em vigor – tudo de acordo com a sua política empresarial.
A "conta de armazenamento em cache" é criada e está disponível.
A "conta de armazenamento em cache" é uma conta de armazenamento temporário usada no processo de replicação.

Observação

O âmbito desta conta de armazenamento é complexo e o artigo sobre a capacidade de recuperação de desastres de VM do plano Hyper-V clarifica esses conceitos. Para o Azure Site Recovery no Azure Stack Hub, consulte o artigo Capacity Planning.

Habilitar replicação

No ambiente de destino, no portal do utilizador do Azure Stack Hub, abra o cofre do Site Recovery e selecione Proteger cargas de trabalho:

Selecione o aparelho que configurou e verifique se está íntegro:

Em seguida, a folha solicita que você selecione o ambiente de origem e a assinatura de origem. Você deve ver todas as assinaturas de Usuário do Azure Stack Hub às quais o usuário (ou SPN) que você configurou tem acesso.

Selecione a assinatura que contém as cargas de trabalho de origem e selecione as VMs para as quais você planeja habilitar a proteção. Você pode proteger até 10 VMs de cada vez. Estão disponíveis scripts do PowerShell que podem permitir implantações maiores.

O Azure Site Recovery replica todos os discos anexados à VM. Nesta versão, todos os discos estão protegidos.

Na próxima etapa, selecione a configuração do ambiente de destino. Essa configuração inclui as redes às quais as VMs se conectam e a conta de armazenamento em cache que elas usam. Você deve usar o PowerShell para configurar a política de replicação. Estão disponíveis scripts que ajudam a iniciar o processo de personalização.

Revise a configuração selecionada e habilite a replicação:

Verificar o progresso da replicação e editar configurações

No cofre de Recuperação do Site, na blade Itens Replicados, pode ver cada uma das VMs para as quais habilitou a replicação:

A seleção desses itens permite que você visualize o estado atual, edite as configurações desse item protegido ou acione ações como um failover de teste:

Compreender os diferentes estados das VMs protegidas

Depois que uma VM é protegida e os dados replicados, há outras tarefas que você pode executar:

Realize um failover de teste:
- Você pode executar um failover de teste para validar sua estratégia de replicação e recuperação de desastres, sem perda de dados ou tempo de inatividade. Um failover de teste não afeta a replicação contínua nem o seu ambiente de produção. Você pode executar um teste de falha em uma VM específica ou em um plano de recuperação que contém várias VMs.
Durante um teste de failover, simula-se o processo de failover desta VM (da origem para o destino) através da criação da VM de destino. Ao fazer um failover de teste, você pode selecionar:
- O ponto de recuperação para failover para:
  - Ponto de recuperação mais recente (RPO mais baixo): esta opção processa primeiro todos os dados que foram enviados para o serviço de Recuperação de Site, a fim de criar um ponto de recuperação para cada VM antes de realizar a transferência para ela. Essa opção fornece o RPO (Recovery Point Objetive) mais baixo, porque a VM criada após o failover terá todos os dados replicados para a Recuperação de Site quando o failover for acionado.
  - Último processado (RTO mais baixo): efetua o failover de todas as VMs do plano para o ponto de recuperação mais recente processado pelo serviço Site Recovery. Para ver o ponto de recuperação mais recente para uma VM específica, verifique Pontos de recuperação mais recentes nas configurações da VM. Esta opção fornece um RTO (Recovery Time Objetive) baixo, porque nenhum tempo é gasto no processamento de dados não processados.
  - Aplicativo consistente mais recente: faz failover de todas as VMs do plano para o ponto de recuperação consistente com o aplicativo mais recente processado pelo Site Recovery. Para ver o ponto de recuperação mais recente para uma VM específica, verifique Pontos de recuperação mais recentes nas configurações da VM.
  - Personalizado: use essa opção para fazer failover de uma VM específica para um ponto de recuperação específico.
- Não é possível selecionar a rede neste momento. O de rede de failover de teste é configurado para cada VM protegida. Se precisar alterá-lo, volte para as propriedades da VM protegida e selecione Exibir ou editar .
O failover de teste pode ajudar a verificar o comportamento da aplicação durante o processo de failover. No entanto, sua VM de origem ainda pode estar em execução. Você deve considerar esse comportamento ao fazer um failover de teste.

Observação

O Azure Site Recovery replica completamente a VM ao fazer um failover de teste. A VM é executada em ambientes de origem e de destino. Você deve levar isso em consideração, pois isso pode afetar o comportamento do seu aplicativo.
Quando o failover de teste estiver concluído, você poderá selecionar Limpar failover de teste. Esta opção exclui a VM de failover de teste e todos os recursos de teste
Failover:
- No caso de um problema no ambiente de origem, você pode optar por fazer failover das VMs para o ambiente de destino.
- Ao iniciar o processo de failover, você pode Desligar a máquina antes de iniciar o failover. Como essa opção move toda a VM da origem para o destino, a VM de origem deve ser desligada antes de selecionar essa opção.
  
  Observação
  
  Se nenhum failover de teste foi feito nos últimos 180 dias, o Site Recovery recomenda que você execute um antes de um failover real. Ignorar a validação da replicação através de um teste de failover pode resultar em perda de dados ou tempo de inatividade imprevisível.
- Quando o processo de failover estiver concluído, você deverá confirmar as alterações para concluir totalmente o processo de failover. Se você não confirmar primeiro, tente proteger novamente, a ação de reproteção primeiro aciona uma confirmação e, em seguida, continua com a reproteção (portanto, leva mais tempo porque ambas as operações são necessárias).
- Depois que o ambiente de origem estiver íntegro novamente, você poderá iniciar um processo de "failback". Este processo é realizado em duas etapas:
  - Execute a proteção adicional para começar a replicar os dados de volta para a origem.
  - Quando os dados estiverem totalmente replicados, execute o failover planejado para mover o recurso de volta para o ambiente inicial.
  Você pode verificar a seção a seguir para obter uma lista de considerações necessárias durante cada uma dessas fases.
Observação

No momento, não oferecemos suporte à reativação da proteção (após um processo de failback). Você deve desabilitar a proteção, remover o agente e, em seguida, habilitar a proteção novamente para essa VM. Esse processo pode ser automatizado e fornecemos scripts para ajudá-lo a começar.

Desinstalar a extensão de VM do Azure Site Recovery

Por design, quando você desinstala a extensão do Azure Site Recovery, ela não remove o serviço de mobilidade executado nessa VM. Isso bloqueia qualquer proteção futura e requer etapas manuais para habilitar a proteção novamente para essa VM.

Depois de remover a extensão de VM do Azure Site Recovery, você deve desinstalar o serviço de mobilidade executado nessa VM. Para fazer isso, consulte os passos para desinstalar o serviço de mobilidade.

Observação

Se você planeja reativar a proteção para essa VM, depois de seguir as etapas anteriores, certifique-se de reiniciar a VM antes de tentar adicionar proteção usando o Azure Site Recovery.

Considerações

As seguintes informações não são necessárias para operações normais. No entanto, estas notas podem ajudar a dar-lhe uma melhor compreensão dos processos que ocorrem nos bastidores.

Para cada um dos estados, há várias considerações:

Reproteja:
- Certifique-se de que a assinatura de origem inicial, o grupo de recursos inicial e a rede/sub-rede virtual da NIC primária inicial ainda existam no carimbo primário. Você pode recuperar essas informações do item protegido usando o PowerShell:
```
Get-AzResource -ResourceID "/subscriptions/<subID>/resourceGroups/<RGname>/providers/Microsoft.DataReplication/replicationVaults/<vaultName>/protectedItems/<vmName>"
```
  A imagem a seguir mostra a saída de exemplo deste comando:
- Antes de executar a reproteção para VMs Linux, verifique se o certificado do serviço de Recuperação de Site é confiável nas VMs Linux que você deseja proteger novamente. Essa relação de confiança desbloqueia o registro da VM com o serviço de Recuperação de Site, que requer uma nova proteção.
  
  Para VMs Ubuntu/Debian:
```
sudo cp /var/lib/waagent/Certificates.pem /usr/local/share/ca-certificates/Certificates.crt

sudo update-ca-certificates
```
  Para Red Hat VMs:
```
sudo update-ca-trust force-enable

sudo cp /var/lib/waagent/Certificates.pem /etc/pki/ca-trust/source/anchors/

sudo update-ca-trust extract
```
- Verifique se a VM do dispositivo de Recuperação de Site tem slots de disco de dados suficientes disponíveis. Os discos de réplica para reproteção são anexados ao dispositivo (verifique o Planejamento de capacidade para obter mais informações).
- Durante o processo de reproteção, a VM de origem (que teria o sourceAzStackVirtualMachineId no carimbo de origem) é desligada assim que a reproteção é acionada, e o disco do sistema operacional e os discos de dados conectados a ela são separados e anexados ao dispositivo como discos de réplica, se forem os antigos. O disco do SO é substituído por um disco temporário do SO de tamanho 1GB.
- Mesmo que um disco possa ser reutilizado como réplica no re-protect, mas esteja em uma assinatura diferente da VM do dispositivo, um novo disco é criado a partir dele no mesmo grupo de assinatura e recursos do dispositivo, para que o novo disco possa ser conectado ao dispositivo.
- Os discos de dados anexados do dispositivo não devem ser modificados/anexados/separados/alterados manualmente, pois uma ressincronização manual de reproteção não é suportada na visualização pública (consulte o artigo sobre problemas conhecidos). A reproteção não pode ser recuperada se os discos de réplica forem removidos.
Retorno (failover planejado): retorne um item reprotegido da marca de destino para a marca de origem.
- Verifique se a assinatura de origem inicial, o grupo de recursos inicial e a rede/sub-rede virtual da NIC primária inicial ainda existem no carimbo de origem. Você pode recuperar essas informações do item protegido usando o PowerShell.
- A VM com o sourceAzStackVirtualMachineId no carimbo de origem é criada com os discos de réplica e NICs recém-criados, se não existir; ou é substituída pelos discos de réplica do sistema operativo e dados, se existir.
- Se a VM com o sourceAzStackVirtualMachineId no carimbo primário existir, todos os discos anexados a ela serão desanexados, mas não excluídos, e as NICs permanecerão as mesmas.
- Se a VM com o sourceAzStackVirtualMachineId no carimbo principal existir, e se estiver numa subscrição diferente da VM do dispositivo, novos discos serão criados na mesma subscrição e grupo de recursos que a VM de failback, a partir das réplicas previamente destacadas do dispositivo, para que os novos discos possam ser anexados à VM de failback.
Confirme que o failover/failback está concluído. A VM com failover no carimbo de recuperação é excluída após o failback ser confirmado.
Quando você desinstala o Provedor de Recursos do Azure Site Recovery, todos os cofres criados nesses carimbos do Azure Stack Hub de destino também são removidos. Esta é uma ação do operador do Azure Stack Hub, sem avisos ou alertas para os usuários quando isso acontece.

Próximos passos

Visão geral do Azure Site Recovery

Partilhar via