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

Depois de fazer failover para o Azure como parte do processo de recuperação de desastre, você pode fazer failback para seu 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 de uma máquina virtual VMware, você pode executar failback para a mesma máquina de virtual do local de origem se ele ainda existe. Nessa situação, apenas as alterações passarão por failback. Esse cenário é conhecido como recuperação no local original. Se não houver máquina virtual local, o cenário será uma recuperação de local alternativa.

Observação

Você só pode fazer failback para o vCenter original e o servidor de Configuração. Você não poderá implantar um novo servidor de Configuração e usá-lo em failback. Além disso, não será possível adicionar um novo vCenter ao servidor de Configuração existente e o failback no novo vCenter.

OLR (Recuperação no Local Original)

Se você optar por executar failback para a máquina virtual original, as condições a seguir deverão ser atendidas:

• Se a máquina virtual for gerenciada por um servidor vCenter, o host do ESX de Destino Mestre deve ter acesso ao repositório de dados das máquinas virtuais.
• 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 mestre.
• Se sua máquina virtual estiver em um host ESX e não usar o vCenter, complete a descoberta do host ESX do destino mestre antes de protegê-la novamente. Isso se aplicará se você também estiver realizando o failback de servidores físicos.
• Você pode executar failback para uma rede de área de armazenamento virtual (vSAN) ou um disco com base no mapeamento (RDM) se os discos já existem e estão conectados à máquina virtual local de dispositivo bruto.

Importante

É importante habilitar disk.enableUUID= TRUE para que, durante o failback, o serviço do Azure Site Recovery seja capaz de identificar o VMDK original na máquina virtual para qual as alterações pendentes serão gravadas. Se esse valor não for configurado como TRUE, o serviço tentará identificar o VMDK local apropriado no melhor esforço. Se o VMDK correto não for localizado, ele criará um disco adicional onde os dados serão gravados.

ALR (Recuperação de Local Alterativo)

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

• Ao realizar failback para um local alternativo, a máquina virtual é recuperada para o mesmo host ESX no qual o servidor de destino principal 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 executar failback somente para um repositório de dados de sistema de arquivo de máquina virtual (VMFS) ou vSAN. Se você tiver um RDM, a reproteção e o failback não funcionarão.
• O proteger novamente envolve uma grande transferência inicial de dados seguida pelas alterações. Esse processo existe porque a máquina virtual não existe no local. Os dados completos deverão ser replicados de volta. Essa reproteção também leva mais tempo do que uma recuperação do 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 repositório de dados VMFS/vSAN.

Observação

Um computador físico, após failover no Azure, somente poderá executar failback como uma máquina virtual VMware. Isso segue o mesmo fluxo de trabalho que a recuperação de local alternativo. Descubra, pelo menos, um servidor de destino mestre juntamente com os hosts ESX/ESXi necessários para os quais você precisa fazer failback.

Próximas etapas

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