Preparar para nova proteção e failback das VMs do VMware

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

Componentes de nova proteção ou failback

Você precisa de vários componentes e configurações prontos antes de poder proteger novamente e fazer failback do Azure.

Componente	Detalhes
Servidor de configuração local	O servidor de configuração local deve estar em execução e conectado ao Azure. A VM para a qual você está realizando o failback deve existir no banco de dados do servidor de configuração. Se o 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 de máquinas replicadas foram retidos no failover, a conectividade site a site (ou conectividade do ExpressRoute) deve ser estabelecida entre máquinas de VMs do Azure e a NIC de failback do servidor de configuração. Para endereços de IP retidos, o servidor de configuração precisa de dois NICs: um para a conectividade do computador de origem e outro para a conectividade de failback do Azure. Isso evita a sobreposição de intervalos de endereços de sub-rede para a origem e as VMs com failover.
Servidor de processos no Azure	Você precisa de um servidor de processo no Azure antes de fazer failback para o site local. O servidor de processo recebe dados da VM protegida do Azure 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 um desempenho de replicação superior. Como prova de conceito, você pode usar o servidor de processos local e o ExpressRoute 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 e o servidor de destino mestre no local.
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 anexados a ele. As VMs com failback têm mais do que um total coletivo de 60 discos, ou, se você estiver realizando o failback de grandes volumes de tráfego, crie um servidor de destino mestre separado para realizar o failover. Se os computadores forem coletados em um grupo de replicação para consistência de várias VMS, as VMs deverão ser todas do Windows ou devem ser todas do Linux. Por quê? 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 ou uma versão superior) que os computadores replicados. O servidor de destino mestre não deve ter nenhum instantâneo em seus discos. Caso contrário, a nova proteçã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 LSI Logic. Sem um controlador de Lógica LSI, a nova proteção falha.
Política de replicação de failback	Para replicar ao site local, você precisará de uma política de failback. Essa política é criada automaticamente quando você cria uma política de replicação de local para o Azure. A política é associada automaticamente ao servidor de configuração. Ele é definido com um limite de RPO de 15 minutos, retenção de ponto de recuperação de 24 horas e a frequência de instantâneo consistente com o aplicativo é de 60 minutos. A política não pode ser editada.
Emparelhamento privado VPN/ExpressRoute de site a site	A nova proteção e o failback precisam de uma conexão VPN site a site ou do emparelhamento privado do ExpressRoute para replicar dados.

Portas para nova proteção/failback

Um número de portas deve estar aberto para nova proteção/failback. O gráfico a seguir ilustra as portas e o fluxo de nova proteção/failback.

Implantar um servidor em processo no Azure

1. Configurar um servidor de processo no Azure para failback.
2. Verifique se as VMs do Azure podem alcançar o servidor de processo.
3. Verifique se a conexão VPN site a site ou a rede de emparelhamento privado do ExpressRoute 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 as limitaçõesdo servidor de destino mestre.

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

3. Verifique se você não usa o Storage vMotion para o servidor de destino mestre, ou o failback pode falhar. A máquina da VM não pode iniciar porque os discos não estão disponíveis para isso.

   • Para evitar essa situação, exclua o servidor de destino mestre de sua lista do vMotion.
   • Se um destino mestre passar por uma tarefa de vMotion de armazenamento depois que passou por uma nova proteção, os discos da VM protegida que estão anexados ao servidor de destino mestre migram para o destino da tarefa vMotion. Se você tentar realizar o failback após isso, a desanexação de disco falhará porque os discos não serão encontrados. Assim, será difícil localizar os discos em suas contas de armazenamento. Se isso ocorrer, localize-os manualmente e os anexe à VM. Depois disso, a VM local poderá ser reinicializada.

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 interromper os pontos no tempo em que a vVM replica para o site local. Observe esses critérios. Se eles não forem atendidos, a unidade não está 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 destino mestre e servidor de processo não está qualificado para um volume de retenção. Quando o servidor de processo e o destino mestre são instalados em um volume, o volume é um cache de destino mestre.
   • Não é o tipo de sistema de arquivos do volume FAT ou FAT32.
   • A capacidade do 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 o Linux é /mnt/retention.

5. Adicione uma unidade se você 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, ele não aparecer na lista suspensa de seleção no portal. Depois de adicionar uma unidade ao destino mestre local, levará 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 do VMware ou o open-vm-tools no servidor de destino principal. Sem as ferramentas, os datastores no host ESXi do destino mestre não podem ser detectados.

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

8. Verifique os requisitos de acesso do vCenter Server:

   • Se a VM para a qual você está realizando o failback estiver em um host ESXi gerenciado pelo VMware vCenter Server, o servidor de destino mestre precisará acessar o arquivo de Disco de Máquina Virtual (VMDK) da VM 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 nova proteçã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 que você deseja. O disco rígido da VM precisa estar em um armazenamento de dados acessível para o host no qual o servidor de destino mestre está em execução.
   • Outra opção, se a VM local já existir para failback, ela deverá ser excluída antes da execução de um failback. Em seguida, o failback cria uma nova VM no mesmo host que o host ESXi de destino mestre. Ao realizar o failback para um local alternativo, os dados são recuperados no mesmo armazenamento de dados e no mesmo host ESX usados pelo servidor de destino mestre local.

9. Para computadores físicos que executam failback em VMs VMware, você deve concluir a descoberta do host no qual o servidor de destino mestre está em execução, antes de proteger novamente o computador.

10. Certifique-se de que o host do ESX na qual a VM de destino mestre tem pelo menos uma máquina virtual arquivo system (VMFS) repositório de dados anexado a ele. Se não há armazenamentos de dados VMFS anexados, a entrada do armazenamento de dados na página nova proteção está vazia e não é possível continuar.

Próximas etapas

Saiba como proteger novamente uma VM.