Failback de máquinas virtuais VMware após recuperação de desastres para o Azure

Depois de fazer failover para o Azure como parte do seu processo de recuperação de desastres, você pode fazer failover de volta para o site local. Com o Azure Site Recovery, dois tipos de failback são possíveis:

• Failback para o local original
• Failback para um local alternativo

Se você fez failover em uma máquina virtual VMware, poderá fazer failover para a mesma máquina virtual local de origem, se ela ainda existir. Nesse cenário, somente as alterações são replicadas de volta. Esse cenário é conhecido como recuperação de local original. Se a máquina virtual local não existir, o cenário será uma recuperação de local alternativo.

Nota

Você só pode fazer failback para o vCenter original e servidor de configuração. Não é possível implantar um novo servidor de configuração e fazer failover usando-o. Além disso, não é possível adicionar um novo vCenter ao servidor de configuração existente e failback no novo vCenter.

Recuperação de localização original (OLR)

Se você optar por fazer failback para a máquina virtual original, as seguintes condições precisam ser atendidas:

• Se a máquina virtual for gerenciada por um servidor vCenter, o host ESX do destino mestre deverá ter acesso ao armazenamento de dados da máquina virtual.
• Se a máquina virtual estiver em um host ESX, mas não for gerenciada pelo vCenter, seu disco rígido deverá residir em um armazenamento de dados acessível ao host do destino principal.
• Se sua máquina virtual estiver em um host ESX e não usar o vCenter, você deverá concluir a descoberta do host ESX do destino mestre antes de proteger novamente. Isso também se aplica se você estiver fazendo failback de servidores físicos.
• Você pode fazer failover para uma rede de área de armazenamento virtual (vSAN) ou um disco baseado em mapeamento de dispositivo bruto (RDM) se os discos já existirem e estiverem conectados à máquina virtual local.

Importante

É importante habilitar disk.enableUUID= TRUE para que, durante o failback, o serviço Azure Site Recovery possa identificar o VMDK original na máquina virtual na qual as alterações pendentes são gravadas. Se esse valor não estiver definido como TRUE, o serviço tentará identificar o VMDK local correspondente com base no melhor esforço. Se o VMDK correto não for encontrado, ele criará um disco extra e os dados serão gravados nele.

Recuperação de local alternativo (ALR)

Se a máquina virtual local não existir antes de reproteger a máquina virtual, o cenário será chamado de recuperação de local alternativo. O fluxo de trabalho reprotegido cria a máquina virtual local novamente. Isso também causa um download de dados completo.

• Quando você faz failover para um local alternativo, a máquina virtual é recuperada para o mesmo host ESX no qual o servidor de destino mestre está implantado. O armazenamento de dados usado para criar o disco é o mesmo armazenamento de dados que foi selecionado ao reproteger a máquina virtual.
• Você pode fazer failback somente para um sistema de arquivos de máquina virtual (VMFS) ou armazenamento de dados vSAN. Se você tiver um RDM, o reproteger e o failback não funcionarão.
• O Reprotect envolve uma grande transferência inicial de dados seguida pelas alterações. Esse processo existe porque a máquina virtual não existe localmente. Os dados completos têm de ser replicados de volta. Essa reproteção também leva mais tempo do que uma recuperação de local original.
• Não é possível fazer failback para discos baseados em RDM. Somente novos discos de máquina virtual (VMDKs) podem ser criados em um armazenamento de dados VMFS/vSAN.

Nota

Uma máquina física, quando faz failover para o Azure, pode ser retornada somente como uma máquina virtual VMware. Isso segue o mesmo fluxo de trabalho que a recuperação de local alternativo. Certifique-se de descobrir pelo menos um servidor de destino mestre e os hosts ESX/ESXi necessários para os quais você precisa fazer failback.

Próximos passos

Siga as etapas para executar a operação de failback.