Preparar para reproteção e reativação pós-falha de VMs do VMware

  • Artigo

Após o failover de VMs VMware locais ou servidores físicos para o Azure, você reprotege as VMs do Azure criadas após o failover, para que elas sejam replicadas de volta para o site local. Com a replicação do Azure para o local em vigor, você pode fazer failback executando um failover do Azure para o local quando estiver pronto.

Componentes de reproteção ou failback

Você precisa de vários componentes e configurações em vigor antes de poder reproteger e fazer failback do Azure.

Componente Detalhes
Servidor de configuração no local O servidor de configuração local deve estar em execução e conectado ao Azure.

A VM para a qual você está fazendo failback deve existir no banco de dados do servidor de configuração. Se um desastre afetar o servidor de configuração, restaure-o com o mesmo endereço IP para garantir que o failback funcione.

Se os endereços IP das máquinas replicadas forem mantidos no failover, a conectividade site a site (ou conectividade ExpressRoute) deverá ser estabelecida entre as máquinas VMs do Azure e a NIC de failback do servidor de configuração. Para endereços IP retidos, o servidor de configuração precisa de duas NICs - uma para conectividade de máquina de origem e outra para conectividade de failback do Azure. Isso evita a sobreposição de intervalos de endereços de sub-rede para as VMs de origem e failover.
Servidor de processo no Azure Você precisa de um servidor de processo no Azure antes de poder fazer failback para seu site local.

O servidor de processo recebe dados da VM do Azure protegida e os envia para o site local.

Você precisa de uma rede de baixa latência entre o servidor de processo e a VM protegida, portanto, recomendamos que você implante o servidor de processo no Azure para obter maior desempenho de replicação.

Para prova de conceito, você pode usar o servidor de processo local e a Rota Expressa com emparelhamento privado.

O servidor de processo deve estar na rede do Azure na qual a VM com failover está localizada. O servidor de processo também deve ser capaz de se comunicar com o servidor de configuração local e o servidor de destino mestre.
Servidor de destino mestre separado O servidor de destino mestre recebe dados de failback e, por padrão, um servidor de destino mestre do Windows é executado no servidor de configuração local.

Um servidor de destino mestre pode ter até 60 discos conectados a ele. Se as VMs que estão sendo failback tiverem mais de um total coletivo de 60 discos, ou se você estiver fazendo failback de grandes volumes de tráfego, crie um servidor de destino mestre separado para failback.

Se as máquinas forem reunidas em um grupo de replicação para consistência de várias VMs, todas as VMs deverão ser Windows ou Linux. Porquê? Porque todas as VMs em um grupo de replicação devem usar o mesmo servidor de destino mestre e o servidor de destino mestre deve ter o mesmo sistema operacional (com a mesma versão ou superior) que os das máquinas replicadas.

O servidor de destino mestre não deve ter nenhum snapshot em seus discos, caso contrário, a reproteção e o failback não funcionarão.

O destino mestre não pode ter um controlador SCSI Paravirtual. O controlador só pode ser um controlador lógico LSI. Sem um controlador lógico LSI, a reproteção falha.
Política de replicação de failback Para replicar de volta para o site local, você precisa de uma política de failback. Essa política é criada automaticamente quando você cria uma política de replicação para o Azure.

A política é associada automaticamente ao servidor de configuração. Ele é definido como um limite de RPO de 15 minutos, retenção de ponto de recuperação de 24 horas e frequência de instantâneo consistente com o aplicativo é de 60 minutos. A política não pode ser editada.
Emparelhamento privado VPN/ExpressRoute site a site A reproteção e o failback precisam de uma conexão VPN site a site ou emparelhamento privado da Rota Expressa para replicar dados.

Portas para reproteção/failback

Várias portas devem estar abertas para reproteção/failback. O gráfico a seguir ilustra as portas e o fluxo de reprotect/failback.

Portas para failover e failback

Implantar um servidor de processo no Azure

  1. Configure um servidor de processo no Azure para failback.
  2. Certifique-se de que as VMs do Azure possam acessar o servidor de processo.
  3. Verifique se a conexão VPN site a site ou a rede de emparelhamento privado da Rota Expressa tem largura de banda suficiente para enviar dados do servidor de processo para o site local.

Implantar um servidor de destino mestre separado

  1. Observe os requisitos e limitações do servidor de destino mestre.

  2. Crie um servidor de destino mestre Windows ou Linux para corresponder ao sistema operacional das VMs que você deseja proteger novamente e fazer failback.

  3. Certifique-se de não usar o Storage vMotion para o servidor de destino mestre, ou o failback pode falhar. A máquina VM não pode ser iniciada porque os discos não estão disponíveis para ela.

    • Para evitar isso, exclua o servidor de destino mestre da sua lista vMotion.
    • Se um destino mestre passar por uma tarefa Storage vMotion após a reproteção, os discos de VM protegidos conectados ao servidor de destino mestre migrarão para o destino da tarefa vMotion. Se você tentar fazer failback depois disso, o desligamento de disco falhará porque os discos não foram encontrados. Nesse caso, é difícil encontrar os discos em suas contas de armazenamento. Se isso ocorrer, localize-os manualmente e anexe-os à VM. Depois disso, a VM local pode ser inicializada.

  4. Adicione uma unidade de retenção ao servidor de destino mestre do Windows existente. Adicione um novo disco e formate a unidade. A unidade de retenção é usada para parar os pontos no tempo em que a VM é replicada de volta para o site local. Observe estes critérios. Se eles não forem atendidos, a unidade não estará listada para o servidor de destino mestre:

    • O volume não é usado para nenhuma outra finalidade, como um destino de replicação, e não está no modo de bloqueio.
    • O volume não é um volume de cache. O volume de instalação personalizado para o servidor de processo e o destino mestre não é elegível para um volume de retenção. Quando o servidor de processo e o destino mestre são instalados em um volume, o volume é um volume de cache do destino mestre.
    • O tipo de sistema de arquivos do volume não é FAT ou FAT32.
    • A capacidade de volume é diferente de zero.
    • O volume de retenção padrão para o Windows é o volume R.
    • O volume de retenção padrão para Linux é /mnt/retention.

  5. Adicione uma unidade se estiver usando um servidor de processo existente. A nova unidade deve atender aos requisitos na última etapa. Se a unidade de retenção não estiver presente, ela não aparecerá na lista suspensa de seleção no portal. Depois de adicionar uma unidade ao destino mestre local, leva até 15 minutos para que a unidade apareça na seleção no portal. Você pode atualizar o servidor de configuração se a unidade não aparecer após 15 minutos.

  6. Instale as ferramentas VMware ou open-vm-tools no servidor de destino mestre. Sem as ferramentas, os armazenamentos de dados no host ESXi do destino mestre não podem ser detetados.

  7. Defina o disco. EnableUUID=true setting nos parâmetros de configuração da VM de destino mestre no VMware. Se essa linha não existir, adicione-a. Essa configuração é necessária para fornecer um UUID consistente para o VMDK para que ele seja montado corretamente.

  8. Verifique os requisitos de acesso ao vCenter Server:

    • Se a VM para a qual você está fazendo failback estiver em um host ESXi gerenciado pelo VMware vCenter Server, o servidor de destino mestre precisará acessar o arquivo VM Virtual Machine Disk (VMDK) local para gravar os dados replicados nos discos da máquina virtual. Verifique se o armazenamento de dados da VM local está montado no host de destino mestre com acesso de leitura/gravação.
    • Se a VM não estiver em um host ESXi gerenciado por um VMware vCenter Server, o Site Recovery criará uma nova VM durante a reproteção. Essa VM é criada no host ESXi no qual você cria a VM do servidor de destino mestre. Escolha o host ESXi com cuidado para criar a VM no host desejado. O disco rígido da VM tem de estar num arquivo de dados que seja acessível pelo anfitrião no qual o servidor de destino principal está em execução.
    • Outra opção, se a VM local já existir para failback, é excluí-la antes de fazer um failback. Em seguida, o failback cria uma nova VM no mesmo host que o host ESXi de destino mestre. Quando você faz failover para um local alternativo, os dados são recuperados para o mesmo armazenamento de dados e o mesmo host ESXi usado pelo servidor de destino mestre local.

  9. Para máquinas físicas com falha de volta para VMs VMware, você deve concluir a descoberta do host no qual o servidor de destino mestre está sendo executado, antes de poder reproteger a máquina.

  10. Verifique se o host ESXi no qual a VM de destino mestre tem pelo menos um armazenamento de dados do sistema de arquivos de máquina virtual (VMFS) conectado a ele. Se nenhum armazenamento de dados VMFS estiver anexado, a entrada do armazenamento de dados nas configurações de reproteção estará vazia e você não poderá continuar.

Próximos passos

Saiba como reproteger uma VM.