Ativar a proteção da VM no Azure Site Recovery
Assim que o destino e os ambientes de origem estiverem configurados, pode começar a ativar a proteção das VMs (da origem para o destino). Toda a configuração é efetuada no ambiente de destino, no próprio cofre Site Recovery.
Pré-requisitos
Pode configurar a política de replicação para as respetivas VMs que pretende proteger no cofre de Site Recovery. Estas 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, mas antes de começar, certifique-se de que os seguintes pré-requisitos são cumpridos:
A conectividade de rede de destino está configurada.
As redes virtuais de destino estão configuradas, onde cada uma das VMs protegidas está ligada quando ocorre uma ativação pós-falha.
A subscrição de utilizador de destino tem alocação de quota de computação suficiente para todas as VMs que planeia potencialmente efetuar a ativação pós-falha.
Estas redes virtuais podem ser configuradas da mesma forma que as redes de origem ou podem ter um design diferente, consoante o seu plano e objetivo de recuperação após desastre.
Confirme que os novos IPs públicos e privados funcionam conforme esperado para as cargas de trabalho específicas que está a proteger (quando ocorrem ativações pós-falha, as VMs com ativação pós-falha têm IPs do ambiente de destino).
A configuração do grupo de recursos pretendida é criada.
Ao configurar a replicação, também pode criar os grupos de recursos, mas, para um ambiente de produção, deve pré-criá-los de acordo com a sua política e estrutura de nomenclatura.
Certifique-se de que o RBAC correto está atribuído e de que as etiquetas estão implementadas, 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ária utilizada no processo de replicação.
Nota
O âmbito desta conta de armazenamento é complexo e o artigo Planear a capacidade de recuperação após desastre da VM hyper-V esclarece estes conceitos. Para o Azure Site Recovery no Azure Stack Hub, veja o artigo Capacity Planning (Planeamento de Capacidade).
Ativar a replicação
No ambiente de destino, no portal de utilizador do Azure Stack Hub, abra o cofre de Site Recovery e selecione Proteger cargas de trabalho:
Selecione a aplicação que configurou e verifique se está em bom estado de funcionamento:
Em seguida, o painel pede-lhe para selecionar o ambiente de origem e a subscrição de origem. Deverá ver todas as subscrições de Utilizador do Azure Stack Hub às quais o utilizador (ou SPN) que configurou tem acesso.
Selecione a subscrição que contém as cargas de trabalho de origem e selecione as VMs para as quais pretende ativar a proteção. Pode proteger até 10 VMs de cada vez. Estão disponíveis scripts do PowerShell que podem ativar implementações maiores.
O Azure Site Recovery replica todos os discos anexados à VM. Nesta versão, todos os discos estão protegidos.
No passo seguinte, selecione a configuração do ambiente de destino. Esta configuração inclui as redes às quais as VMs se ligam e a conta de armazenamento em cache que utilizam. Tem de utilizar o PowerShell para configurar a política de replicação. Estão disponíveis scripts que ajudam a iniciar o processo de personalização.
Reveja a configuração selecionada e ative a replicação:
Verificar o progresso da replicação e editar as definições
No cofre de Site Recovery, no painel Itens Replicados, pode ver cada uma das VMs para as quais ativou a replicação:
Selecionar estes itens permite-lhe ver o estado atual, editar as definições desse item protegido ou acionar ações como uma ativação pós-falha de teste:
Compreender os diferentes estados das VMs protegidas
Assim que uma VM estiver protegida e os dados forem replicados, poderá realizar mais tarefas:
Executar uma ativação pós-falha de teste:
- Pode executar uma ativação pós-falha de teste para validar a estratégia de replicação e recuperação após desastre, sem perda de dados ou período de indisponibilidade. Uma ativação pós-falha de teste não afeta a replicação em curso ou o ambiente de produção. Pode executar uma ativação pós-falha de teste numa VM específica ou num plano de recuperação que contenha várias VMs.
Uma ativação pós-falha de teste simula a ativação pós-falha desta VM (da origem para o destino) ao criar a VM de destino. Ao efetuar uma ativação pós-falha de teste, pode selecionar:
O ponto de recuperação para o onde efetuar a ativação pós-falha:
- Ponto de recuperação mais recente (RPO mais baixo): esta opção processa primeiro todos os dados que foram enviados para o serviço Site Recovery, para criar um ponto de recuperação para cada VM antes de efetuar a ativação pós-falha. Esta opção fornece o RPO mais baixo (Objetivo de Ponto de Recuperação), porque a VM criada após a ativação pós-falha terá todos os dados replicados para Site Recovery quando a ativação pós-falha for acionada.
- Processado mais recentemente (RTO mais baixo): efetua a ativação pós-falha de todas as VMs no plano para o ponto de recuperação mais recente processado por Site Recovery. Para ver o ponto de recuperação mais recente de uma VM específica, verifique os Pontos de Recuperação Mais Recentes nas definições da VM. Esta opção proporciona um RTO (Objetivo de Tempo de Recuperação) baixo, porque não é despendido tempo ao processar os dados não processados.
- Consistente com a aplicação mais recente: efetua a ativação pós-falha de todas as VMs no plano para o ponto de recuperação consistente com a aplicação mais recente processado por Site Recovery. Para ver o ponto de recuperação mais recente de uma VM específica, verifique os Pontos de Recuperação Mais Recentes nas definições da VM.
- Personalizado: utilize esta opção para efetuar a ativação pós-falha de uma VM específica para um determinado ponto de recuperação.
Não pode selecionar a rede neste momento. A rede de ativação pós-falha de teste está configurada para cada VM protegida. Se precisar de alterá-la, volte às propriedades da VM protegida e, em seguida, selecione Ver ou editar.
A ativação pós-falha de teste pode ajudar a verificar o comportamento da aplicação quando efetuou a ativação pós-falha. No entanto, a VM de origem pode ainda estar em execução. Tem de considerar este comportamento ao efetuar uma ativação pós-falha de teste.
Nota
O Azure Site Recovery replica completamente a VM ao efetuar uma ativação pós-falha de teste. A VM é executada em ambientes de origem e de destino. Tem de ter isto em conta, uma vez que pode afetar o comportamento da sua aplicação.
Quando a ativação pós-falha de teste estiver concluída, pode selecionar Limpar ativação pós-falha de teste. Esta opção elimina a VM de ativação pós-falha de teste e todos os recursos de teste
Ativação pós-falha:
Em caso de problema no ambiente de origem, pode optar por efetuar a ativação pós-falha das VMs para o ambiente de destino.
Ao iniciar o processo de ativação pós-falha, pode Encerrar a máquina antes de iniciar a ativação pós-falha. Uma vez que esta opção move toda a VM da origem para o destino, a VM de origem deve ser encerrada antes de selecionar esta opção.
Nota
Se não tiver sido efetuada nenhuma ativação pós-falha de teste nos últimos 180 dias, Site Recovery recomenda que execute uma antes de uma ativação pós-falha real. Ignorar a validação da replicação através da ativação pós-falha de teste pode levar à perda de dados ou a um período de indisponibilidade imprevisível.
Assim que o processo de ativação pós-falha estiver concluído, tem de consolidar as alterações para concluir totalmente o processo de ativação pós-falha. Se não se comprometer primeiro, tente voltar a proteger, a ação de voltar a proteger aciona primeiro uma consolidação e, em seguida, continua com a nova proteção (portanto, demora mais tempo porque ambas as operações são necessárias).
Depois de o ambiente de origem estar novamente em bom estado de funcionamento, pode iniciar um processo de "reativação pós-falha". Este processo é realizado em dois passos:
- Execute novamente a proteção para começar a replicar os dados de volta para a origem.
- Depois de os dados serem totalmente replicados, execute o failover planeado para mover o recurso de volta para o ambiente inicial.
Pode consultar a secção seguinte para obter uma lista das considerações necessárias durante cada uma destas fases.
Nota
Neste momento, não suportamos a reativação da proteção (após um processo de reativação pós-falha). Tem de desativar a proteção, remover o agente e, em seguida, ativar novamente a proteção para esta VM. Este processo pode ser automatizado e fornecemos scripts para o ajudar a começar.
Desinstalar a extensão de VM do Azure Site Recovery
Por predefinição, quando desinstala a extensão do Azure Site Recovery, não remove o serviço de mobilidade que é executado nessa VM. Isto bloqueia qualquer proteção futura e requer passos manuais para ativar novamente a proteção para essa VM.
Depois de remover a extensão de VM do Azure Site Recovery, tem de desinstalar o serviço de mobilidade que é executado nessa VM. Para tal, veja estes passos para Desinstalar Serviço de mobilidade.
Nota
Se planear reativar a proteção para essa VM, depois de seguir os passos anteriores, certifique-se de que reinicia a VM antes de tentar adicionar proteção com 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 compreender melhor os processos que ocorrem nos bastidores.
Para cada um dos estados, existem várias considerações:
Proteger novamente:
Confirme que a subscrição de origem inicial, o grupo de recursos inicial e a rede virtual/sub-rede da NIC primária inicial ainda existem no selo primário. Pode obter estas informações a partir do item protegido com o PowerShell:
Get-AzResource -ResourceID "/subscriptions/<subID>/resourceGroups/<RGname>/providers/Microsoft.DataReplication/replicationVaults/<vaultName>/protectedItems/<vmName>"
A imagem seguinte mostra o resultado de exemplo deste comando:
Antes de executar a nova proteção para VMs do Linux, certifique-se de que o certificado do serviço Site Recovery é considerado fidedigno nas VMs do Linux que pretende proteger novamente. Esta confiança desbloqueia o registo da VM com o serviço Site Recovery, o que é necessário para voltar a proteger.
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
Certifique-se de que a VM da aplicação Site Recovery tem blocos de disco de dados suficientes disponíveis. Os discos de réplica para nova proteção estão ligados à aplicação (verifique o Planeamento de Capacidade para obter mais informações).
Durante o processo de nova proteção, a VM de origem (que teria a origemAzStackVirtualMachineId no carimbo de origem) é encerrada assim que a nova proteção é acionada e o disco do SO e os discos de dados ligados à mesma são desanexados e ligados à aplicação como discos de réplica, se forem discos antigos. O disco do SO é substituído por um disco de SO temporário de tamanho 1 GB.
Mesmo que um disco possa ser reutilizado como réplica na nova proteção, mas estiver numa subscrição diferente da VM da aplicação, é criado um novo disco a partir do mesmo na mesma subscrição e grupo de recursos que a aplicação, para que o novo disco possa ser anexado à aplicação.
Os discos de dados anexados da aplicação não devem ser modificados/anexados/desanexados/alterados manualmente, uma vez que uma nova proteção da ressincronização manual não é suportada na pré-visualização pública (consulte o artigo de problemas conhecidos). Não é possível recuperar a nova proteção se os discos de réplica forem removidos.
Reativação pós-falha (failover planeado): reativação pós-falha de um item novamente protegido do carimbo de destino para o carimbo de origem:
- Confirme que a subscrição 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. Pode obter estas informações a partir do item protegido com o PowerShell.
- A VM com oazStackVirtualMachineId de origem é criada com os discos de réplica e os NICs recém-criados, caso não existam; ou é substituído por um disco de SO de réplica e discos de dados, se existir.
- Se a VM com a origemAzStackVirtualMachineId no selo primário existir, todos os discos ligados à mesma serão desanexados, mas não eliminados, e as NICs permanecerão as mesmas.
- Se a VM com o sourceAzStackVirtualMachineId no selo primário existir e se estiver numa subscrição diferente da VM da aplicação, os novos discos são criados na mesma subscrição e grupo de recursos que a VM de reativação pós-falha das réplicas desanexada da aplicação, para que os novos discos possam ser ligados à VM de reativação pós-falha.
Confirme que a ativação pós-falha/reativação pós-falha está concluída. A VM de ativação pós-falha no selo de recuperação é eliminada após a reativação pós-falha ser consolidada.
Ao desinstalar o Fornecedor de Recursos do Azure Site Recovery, todos os cofres criados nesses selos de destino do Azure Stack Hub também são removidos. Esta é uma ação de operador do Azure Stack Hub, sem avisos ou alertas para os utilizadores quando acontece.