Failback van virtuele VMware-machines na noodherstel naar Azure

Nadat u een failover naar Azure hebt uitgevoerd als onderdeel van uw herstelproces na noodgevallen, kunt u een failback uitvoeren naar uw on-premises site. Met Azure Site Recovery zijn twee soorten failback mogelijk:

• Failback naar de oorspronkelijke locatie
• Failback naar een alternatieve locatie

Als u een failover hebt uitgevoerd voor een virtuele VMware-machine, kunt u een failback uitvoeren naar dezelfde on-premises virtuele bronmachine als deze nog bestaat. In dit scenario worden alleen de wijzigingen terug gerepliceerd. Dit scenario wordt herstel van de oorspronkelijke locatie genoemd. Als de on-premises virtuele machine niet bestaat, is het scenario een alternatieve locatieherstel.

Notitie

U kunt alleen een failback uitvoeren naar de oorspronkelijke vCenter- en configuratieserver. U kunt geen nieuwe configuratieserver implementeren en een failback uitvoeren met deze server. U kunt ook geen nieuw vCenter toevoegen aan de bestaande configuratieserver en failback naar het nieuwe vCenter.

Oorspronkelijke locatieherstel (OLR)

Als u ervoor kiest om een failback uit te voeren naar de oorspronkelijke virtuele machine, moet aan de volgende voorwaarden worden voldaan:

• Als de virtuele machine wordt beheerd door een vCenter-server, moet de ESX-host van het hoofddoel toegang hebben tot het gegevensarchief van de virtuele machine.
• Als de virtuele machine zich op een ESX-host bevindt, maar niet wordt beheerd door vCenter, moet de harde schijf zich in een gegevensarchief bevinden dat toegankelijk is voor de host van het hoofddoel.
• Als uw virtuele machine zich op een ESX-host bevindt en geen vCenter gebruikt, moet u de detectie van de ESX-host van het hoofddoel voltooien voordat u de beveiliging opnieuw uitvoert. Dit geldt ook als u een failback van fysieke servers uitvoert.
• U kunt een failback uitvoeren naar een vSAN (Virtual Storage Area Network) of een schijf die is gebaseerd op toewijzing van onbewerkte apparaten (RDM) als de schijven al bestaan en zijn verbonden met de on-premises virtuele machine.

Belangrijk

Het is belangrijk om disk.enableUUID= TRUE in te schakelen, zodat de Azure Site Recovery-service tijdens failback de oorspronkelijke VMDK kan identificeren op de virtuele machine waarop de wijzigingen in behandeling zijn geschreven. Als deze waarde niet is ingesteld op TRUE, probeert de service de bijbehorende on-premises VMDK te identificeren op basis van de beste inspanning. Als de juiste VMDK niet wordt gevonden, wordt er een extra schijf gemaakt en worden de gegevens naar die schijf geschreven.

Alternatieve locatieherstel (ALR)

Als de on-premises virtuele machine niet bestaat voordat de virtuele machine opnieuw wordt beveiligd, wordt het scenario een alternatieve locatieherstel genoemd. Met de opnieuw beveiligde werkstroom wordt de on-premises virtuele machine opnieuw gemaakt. Dit veroorzaakt ook een volledige gegevensdownload.

• Wanneer u een failback uitvoert naar een alternatieve locatie, wordt de virtuele machine hersteld naar dezelfde ESX-host waarop de hoofddoelserver wordt geïmplementeerd. Het gegevensarchief dat wordt gebruikt om de schijf te maken, is hetzelfde gegevensarchief dat is geselecteerd bij het opnieuw beveiligen van de virtuele machine.
• U kunt alleen een failback uitvoeren naar een bestandssysteem van een virtuele machine (VMFS) of vSAN-gegevensopslag. Als u een RDM hebt, werkt het opnieuw beveiligen en failback niet.
• Opnieuw beveiligen omvat één grote initiële gegevensoverdracht die wordt gevolgd door de wijzigingen. Dit proces bestaat omdat de virtuele machine niet on-premises bestaat. De volledige gegevens moeten worden gerepliceerd. Dit opnieuw beveiligen kost ook meer tijd dan een oorspronkelijke locatieherstel.
• U kunt geen failback uitvoeren naar op RDM gebaseerde schijven. Alleen nieuwe virtuele-machineschijven (VMDK's) kunnen worden gemaakt in een VMFS-/vSAN-gegevensarchief.

Notitie

Een fysieke machine, wanneer een failover naar Azure wordt uitgevoerd, kan alleen als een virtuele VMware-machine worden uitgevoerd. Dit volgt dezelfde werkstroom als het herstel van de alternatieve locatie. Zorg ervoor dat u ten minste één hoofddoelserver en de benodigde ESX/ESXi-hosts detecteert waarvoor u een failback moet uitvoeren.

Volgende stappen

Volg de stappen om de failbackbewerking uit te voeren.