Arquitetura de recuperação de desastre do Hyper-V para o Azure
Este artigo descreve a arquitetura e os processos usados quando você faz a replicação, o failover e a recuperação de VMs (máquinas virtuais) do Hyper-V entre hosts Hyper-V locais e o Azure usando o serviço Azure Site Recovery.
Os hosts Hyper-V podem ser opcionalmente gerenciados em nuvens privadas do System Center VMM (Virtual Machine Manager).
Componentes de arquitetura – Hyper-V sem VMM
A tabela e o gráfico a seguir fornecem uma visão geral dos componentes usados para replicação do Hyper-V para o Azure quando hosts Hyper-V não são gerenciados por VMM.
| Componente | Requisito | Detalhes |
|---|---|---|
| Azure | Uma assinatura do Azure, uma conta de armazenamento do Azure e uma rede do Azure. | Os dados replicados de cargas de trabalho de máquina virtual locais são colocados na conta de armazenamento. As máquinas virtuais do Azure são criadas com os dados de carga de trabalho replicados quando ocorre failover do site local. As máquinas virtuais do Azure se conectam à rede virtual do Azure quando são criadas. |
| Hyper-V | Durante a implantação do Site Recovery, você reúne hosts Hyper-V e clusters em sites do Hyper-V. Você instala o Provedor do Azure Site Recovery e o agente dos Serviços de Recuperação em cada host autônomo do Hyper-V em cada nó de cluster do Hyper-V. | O Provedor coordena a replicação com o Site Recovery pela internet. O agente dos Serviços de Recuperação trata da replicação de dados. As comunicações do provedor e do agente são protegidas e criptografadas. Os dados replicados no armazenamento do Azure também são criptografados. |
| VMs Hyper-V | Uma ou mais máquinas virtuais em execução no Hyper-V. | Nada precisa ser explicitamente instalado em VMs. |
Arquitetura do Hyper-V para o Azure (sem VMM)
Componentes de arquitetura – Hyper-V com VMM
A tabela e o gráfico a seguir fornecem uma visão geral dos componentes usados para replicação do Hyper-V para o Azure quando hosts Hyper-V são gerenciados em nuvens VMM.
| Componente | Requisito | Detalhes |
|---|---|---|
| Azure | Uma assinatura do Azure, uma conta de armazenamento do Azure e uma rede do Azure. | Os dados replicados de cargas de trabalho de máquina virtual locais são colocados na conta de armazenamento. As máquinas virtuais do Azure são criadas com os dados replicados quando ocorre failover do site local. As máquinas virtuais do Azure se conectam à rede virtual do Azure quando são criadas. |
| Servidor VMM | O servidor VMM tem uma ou mais nuvens que contém hosts Hyper-V. | Você instala o Provedor do Site Recovery no servidor VMM para orquestrar a replicação com o Site Recovery e registre o servidor no cofre dos Serviços de Recuperação. |
| Host do Hyper-V | Um ou mais hosts/clusters Hyper-V gerenciados pelo VMM. | Você pode instalar o agente dos Serviços de Recuperação em cada host ou nó do cluster do Hyper-V. |
| VMs Hyper-V | Uma ou máquinas virtuais em execução em um servidor host Hyper-V. | Nada precisa ser explicitamente instalado em máquinas virtuais. |
| Rede | Redes de máquinas virtuais e lógicas configuradas no servidor VMM. A rede de máquinas virtuais deve ser vinculada a uma rede lógica associada à nuvem. | Redes de VMs são mapeadas para redes virtuais do Azure. Quando as VMs do Azure são criadas após o failover, elas são adicionadas à rede do Azure que é mapeada para a rede de VMs. |
Arquitetura do Hyper-V para o Azure (com VMM)
Configurar a conectividade de rede de saída
Para que o Site Recovery funcione conforme o esperado, você precisa modificar a conectividade de rede de saída para permitir que seu ambiente seja replicado.
Observação
O Site Recovery não dá suporte ao uso de um proxy de autenticação para controlar a conectividade de rede.
Conectividade de saída para URLs
Caso esteja usando um proxy de firewall baseado em URL para controlar a conectividade de saída, permita acesso a estas URLs:
| Nome | Comercial | Governo | Descrição |
|---|---|---|---|
| Armazenamento | *.blob.core.windows.net |
*.blob.core.usgovcloudapi.net |
Permite que os dados sejam gravados da máquina virtual para a conta de armazenamento em cache na região de origem. |
| Microsoft Entra ID | login.microsoftonline.com |
login.microsoftonline.us |
Fornece autorização e autenticação para as URLs do serviço Site Recovery. |
| Replicação | *.hypervrecoverymanager.windowsazure.com |
*.hypervrecoverymanager.windowsazure.com |
Permite que a máquina virtual se comunique com o serviço do Site Recovery. |
| Barramento de Serviço | *.servicebus.windows.net |
*.servicebus.usgovcloudapi.net |
Permite que a máquina virtual escreva dados de diagnóstico e monitoramento do Site Recovery. |
Processo de replicação
Processo de replicação e recuperação
Habilitar proteção
- Depois de habilitar a proteção para uma máquina virtual do Hyper-V, no portal do Azure ou no local, a opção Habilitar proteção é iniciada.
- O trabalho verifica se o computador está em conformidade com os pré-requisitos antes de invocar CreateReplicationRelationship para configurar a replicação com as configurações definidas por você.
- O trabalho é iniciado com a replicação inicial, invocando o método StartReplication, para inicializar uma replicação completa de VM e enviar os discos virtuais da VM no Azure.
- Você pode monitorar o trabalho na guia Trabalhos.
Replicação de dados inicial
- Quando a replicação inicial é disparada, é tirado um instantâneo de VM do Hyper-V.
- Discos rígidos virtuais na VM são replicados individualmente até serem todos copiados para o Azure. Isso pode demorar um pouco, dependendo do tamanho da VM e largura de banda de rede. Saiba como aumentar a largura de banda de rede.
- Se houver alterações no disco durante a replicação inicial, o Rastreador de Replicação de Réplica do Hyper-V mostrará essas alterações como logs de replicação do Hyper-V (.hrl). Esses arquivos de log estão localizados na mesma pasta que os discos. Cada disco tem um arquivo .hrl associado que é enviado ao armazenamento secundário. O instantâneo e os arquivos de log consomem recursos de disco durante a replicação inicial.
- Quando a replicação inicial termina, o instantâneo de VM é excluído.
- As alterações de disco delta no log são sincronizadas e mescladas para o disco pai.
Finalizar processo de proteção
- Após a conclusão da replicação inicial, o trabalho Finalizar proteção na máquina virtual é executado. Ele configura a rede e outras configurações pós-replicação, de modo que a VM fica protegida.
- Neste estágio, você pode verificar as configurações da VM para certificar-se de que ela está pronta para failover. Você pode executar uma simulação de recuperação de desastre (failover de teste) para a VM, para verificar se ela faz failover conforme esperado.
Replicação delta
- Após a replicação inicial, a replicação delta se inicia, de acordo com a política de replicação.
- O Rastreador de Replicação de Réplica do Hyper-V acompanha as alterações em um disco rígido virtual como arquivos .hrl. Cada disco configurado para a replicação tem um arquivo .hrl associado.
- Esse log é enviado para a conta de armazenamento do cliente. Quando um log está em trânsito para o Azure, as alterações no disco primário são rastreadas em outro arquivo de log na mesma pasta.
- Durante a replicação inicial e delta, você pode monitorar a VM no portal do Azure.
Processo de ressincronização
Se a replicação delta falhar, e uma replicação completa for dispendiosa em termos de largura de banda ou tempo, a VM fica marcada para ressincronização.
- Por exemplo, se os arquivos .hrl alcançarem 50% do tamanho do disco, a VM será marcada para ressincronização.
- Por padrão, a ressincronização está agendada para execução automática fora das horas de trabalho.
A ressincronização envia somente dados delta.
- Ela minimiza a quantidade de dados enviados calculando somas de verificação das VMs de origem e de destino.
- Ela usa um algoritmo de agrupamento de bloco fixo em que os arquivos de origem e destino são divididos em partes fixas.
- As somas de verificação para cada parte são geradas. Elas são comparadas para determinar quais blocos da origem precisam ser aplicados ao destino.
Após a conclusão da ressincronização, a replicação delta normal deverá ser retomada.
Se você não quiser aguardar a ressincronização fora do horário de trabalho, você poderá ressincronizar uma VM manualmente. Por exemplo, se ocorrer uma interrupção. Para fazer isso, no portal do Azure, selecione a VM >Ressincronizar.
Processo de tentar novamente
Se um erro de replicação ocorrer, haverá uma repetição interna. Tentar novamente é classificado conforme descrito na tabela.
| Categoria | Detalhes |
|---|---|
| Erros não recuperáveis | Nenhuma nova tentativa é feita. O status da VM será Crítico e há necessidade de intervenção do administrador. Exemplos desses erros incluem uma cadeia VHD quebrada, um estado inválido para a VM de réplica, erros de autenticação de rede, erros de autorização e erros de VM não encontrada (para servidores Hyper-V autônomos). |
| Erros recuperáveis | Novas tentativas ocorrem a cada intervalo da replicação usando de modo exponencial a retirada, o que aumenta o intervalo de repetição desde o início da primeira tentativa por 1, 2, 4, 8 e 10 minutos. Se o erro persistir, repita a operação a cada 30 minutos. Exemplos desses erros incluem: erros da rede, erros de pouco espaço em disco, condições de memória insuficiente. |
Processo de failover e failback
- Você pode executar uma recuperação planejada ou não planejada de VMs Hyper-V locais para o Azure. Se você executar uma recuperação planejada, as VMs de origem serão desligadas para evitar a perda de dados. Execute um failover não planejado se o seu site primário não está acessível.
- Você pode fazer o failover de um único computador ou criar planos de recuperação para orquestrar o failover de várias máquinas virtuais.
- Você executa um failover. Após a conclusão do primeiro estágio do failover, você deverá ser capaz de ver as VMs de réplica criadas no Azure. Você pode atribuir um endereço IP público à VM, se necessário.
- Você confirma então o failover para começar a acessar a carga de trabalho por meio da VM do Azure de réplica.
Depois que sua infraestrutura local estiver funcionando novamente, você poderá fazer failback. O failback ocorre em três estágios:
Dispare um failover planejado do Azure para o site local:
- Minimizar o tempo de inatividade: se você usar essa opção, o Site Recovery sincronizará os dados antes do failover. Ele verifica blocos de dados alterados e baixa-os para o site local, enquanto a VM do Azure continua em execução, minimizando o tempo de inatividade. Quando você especificar manualmente que o failover deve ser concluído, a VM do Azure será desligada, quaisquer eventuais alterações delta finais serão copiadas e o failover iniciará.
- Download completo: com essa opção, os dados são sincronizados durante o failover. Esta opção baixa todo o disco. Ela é mais rápida porque nenhuma soma de verificação é calculada, mas há mais tempo de inatividade. Use essa opção se você esteve executando as VMs de réplica do Azure por algum tempo ou se a VM local foi excluída.
- Criar uma máquina virtual: você pode selecionar fazer failback para a mesma máquina virtual ou para uma máquina virtual alternativa. Você pode especificar que o Site Recovery deve criar a VM se ela ainda não existe.
Após a conclusão da sincronização inicial, você seleciona para concluir o failover. Depois que isso é concluído, você pode fazer logon na VM local para verificar se tudo está funcionando conforme o esperado. No portal do Azure, você pode ver que as VMs do Azure foram interrompidas.
Em seguida, você confirma o failover para concluir e começar a acessar a carga de trabalho da VM local novamente.
Após o failback das cargas de trabalho, você habilita a replicação inversa, de modo que as VMs locais são replicadas novamente para o Azure.
Próximas etapas
Siga este tutorial para conhecer a replicação do Hyper-V para o Azure.