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

Artigo
08/05/2024

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

Pré-requisitos

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

Site Recovery ajuda a replicar todos os dados da VM em si, mas antes de começar, 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 – em que cada uma das VMs protegidas está 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 plano de recuperação de desastre e da meta.
Verifique se os novos IPs públicos e privados funcionam conforme o esperado para as cargas de trabalho específicas que você está protegendo (quando ocorrem failovers, as VMs com failover têm IPs do ambiente de destino).
A configuração do grupo de recursos desejada é criada.
Ao configurar a replicação, você também pode criar os grupos de recursos, mas para um ambiente de produção, você deve criá-los previamente de acordo com sua política de nomenclatura e estrutura.
Verifique se o RBAC certo está atribuído e se a marcação está em vigor , tudo de acordo com sua política corporativa.
A "conta de armazenamento em cache" é criada e disponível.
A "conta de armazenamento em cache" é uma conta de armazenamento temporária usada no processo de replicação.

Observação

O escopo dessa conta de armazenamento é complexo e o artigo Planejar a capacidade de recuperação de desastre de VM do Hyper-V esclarece esses conceitos. Para o Azure Site Recovery no Azure Stack Hub, consulte o artigo Planejamento de Capacidade.

Habilitar a replicação

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

Selecione o dispositivo configurado e marcar que ele 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 do Usuário do Azure Stack Hub para as quais o usuário (ou SPN) configurado 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 por vez. Os scripts do PowerShell estão disponíveis que podem habilitar implantações maiores.

O Azure Site Recovery replica todos os discos anexados à VM. Nesta versão, todos os discos sã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. Os scripts estão disponíveis para ajudar a iniciar o processo de personalização.

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

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

No cofre Site Recovery, na folha Itens Replicados, você pode ver cada uma das VMs para as quais você habilitou a replicação:

Selecionar esses itens permite exibir o estado atual, editar as configurações desse item protegido ou disparar ações como um failover de teste:

Entender os diferentes estados para VMs protegidas

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

Executar um failover de teste:
- Você pode executar um failover de teste para validar sua estratégia de replicação e recuperação de desastre, sem perda de dados ou tempo de inatividade. Um failover de teste não afeta a replicação em andamento nem o ambiente de produção. Você pode executar um failover de teste em uma VM específica ou em um plano de recuperação que contém várias VMs.
Um failover de teste simula o failover dessa VM (da origem para o destino) criando a VM de destino. Ao fazer um failover de teste, você pode selecionar:
- O ponto de recuperação para o qual fazer failover:
  - Ponto de recuperação mais recente (RPO mais baixo): essa opção primeiro processa todos os dados que foram enviados para o serviço Site Recovery, para criar um ponto de recuperação para cada VM antes de fazer failover para ela. Essa opção fornece o RPO mais baixo (Objetivo de Ponto de Recuperação), pois a VM criada após o failover terá todos os dados replicados para Site Recovery quando o failover for disparado.
  - Mais recente processado (RTO mais baixo): faz failover de todas as VMs no plano para o ponto de recuperação mais recente processado por Site Recovery. Para ver o último ponto de recuperação de uma VM específica, verifique os Pontos de Recuperação Mais Recentes nas configurações da VM. Essa opção fornece um RTO (Objetivo do Tempo de Recuperação) baixo porque não há tempo gasto para processar dados não processados.
  - Mais recente consistente com o aplicativo: faz failover de todas as VMs no plano para o ponto de recuperação mais recente consistente com o aplicativo processado por Site Recovery. Para ver o último ponto de recuperação de uma VM específica, verifique os 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. A rede de failover de teste está configurada para cada VM protegida. Se você precisar alterá-la, volte para as propriedades da VM protegida e selecione Exibir ou editar.
O failover de teste pode ajudar a marcar o comportamento do aplicativo quando há 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 conta, pois isso pode afetar o comportamento do seu aplicativo.
Quando o failover de teste for concluído, você poderá selecionar Limpar failover de teste. Essa 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 o computador 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 tiver sido feito nos últimos 180 dias, Site Recovery recomenda que você execute um antes de um failover real. Ignorar a validação da replicação por meio de failover de teste pode levar a perda de dados ou tempo de inatividade imprevisível.
- Depois que o processo de failover for 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 nova proteção primeiro dispara um commit e, em seguida, continua com a nova proteçã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". Esse processo é executado em duas etapas:
  - Execute a proteção novamente para começar a replicar os dados de volta para a origem.
  - Depois que os dados forem totalmente replicados, execute o recuperação panejada para mover o recurso de volta para o ambiente inicial.
  Você pode marcar 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 há suporte para a reabilitação da proteção (após um processo de failback). Você deve desabilitar a proteção, remover o agente e 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 de Site Recovery do Azure, ela não remove o serviço de mobilidade executado dentro dessa 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 Site Recovery do Azure, você deve desinstalar o serviço de mobilidade executado dentro dessa VM. Para fazer isso, consulte estas etapas para Desinstalar serviço Mobilidade.

Observação

Se você planeja reabilitar a proteção para essa VM, depois de seguir as etapas anteriores, reinicie a VM antes de tentar adicionar proteção usando o Azure Site Recovery.

Considerações

As informações a seguir não são necessárias para operações normais. No entanto, essas anotações podem ajudar a entender melhor os processos que ocorrem nos bastidores.

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

Proteger novamente:
- Verifique se a assinatura de origem inicial, o grupo de recursos inicial e a rede virtual/sub-rede da NIC primária inicial ainda existem 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 novamente a proteção para VMs Linux, verifique se o certificado do serviço Site Recovery é confiável nas VMs do Linux que você deseja proteger novamente. Essa relação de confiança desbloqueia o registro de VM com o serviço Site Recovery, o que exige a 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 VMs do Red Hat:
```
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 Site Recovery dispositivo tem slots de disco de dados suficientes disponíveis. Os discos réplica para reproteção são anexados à dispositivo (marcar o Planejamento de Capacidade para obter mais informações).
- Durante o processo de reproteção, a VM de origem (que teria a sourceAzStackVirtualMachineId no carimbo de origem) é desligada quando a nova proteção é disparada e o disco do sistema operacional e os discos de dados anexados a ele são desanexados e anexados ao dispositivo como discos réplica se forem os antigos. O disco do sistema operacional é substituído por um disco temporário do sistema operacional de tamanho 1GB.
- Mesmo que um disco possa ser reutilizado como réplica na nova proteção, mas estiver em uma assinatura diferente da VM dispositivo, um novo disco será criado com base nele na mesma assinatura e grupo de recursos que o dispositivo, para que o novo disco possa ser anexado ao dispositivo.
- Os discos de dados anexados do dispositivo não devem ser modificados/anexados/desanexados/alterados manualmente, pois não há suporte para uma nova proteção manual na visualização pública (consulte o artigo problemas conhecidos). A nova proteção não poderá ser recuperada se os discos réplica forem removidos.
Failback (recuperação panejada): faça failback de um item protegido novamente do carimbo de destino para o carimbo de origem:
- Verifique se a assinatura de origem inicial, o grupo de recursos inicial e a rede virtual/sub-rede 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 réplica e NICs recém-criados se ela não existir; ou será substituída por um disco do sistema operacional réplica e discos de dados, se existir.
- Se a VM com 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 primário existir e se estiver em uma assinatura diferente da VM dispositivo, novos discos serão criados na mesma assinatura e grupo de recursos que a VM de failback do réplica desanexadas do dispositivo, para que os novos discos possam ser anexados à VM de failback.
Confirme se o failover/failback foi feito. A VM com failover no carimbo de recuperação é excluída após o failback ser confirmado.
Quando você desinstala o Provedor de Recursos Site Recovery do Azure, todos os cofres criados nesses selos de destino do Azure Stack Hub também são removidos. Essa é uma ação do operador do Azure Stack Hub, sem avisos ou alertas para os usuários quando isso acontece.

Próximas etapas

Visão geral sobre o Azure Site Recovery

Compartilhar via