Voorbereiden op opnieuw beveiligen en uitvoeren van failback van virtuele VMware-machines
Na een failover van on-premises VMware-VM's of fysieke servers naar Azure, beveiligt u de Azure-VM's die zijn gemaakt na een failover, zodat ze weer worden gerepliceerd naar de on-premises site. Met replicatie van Azure naar on-premises kunt u vervolgens een failback uitvoeren door een failover uit te voeren van Azure naar on-premises wanneer u klaar bent.
Opnieuw beveiligen of failbackonderdelen
U hebt een aantal onderdelen en instellingen nodig voordat u opnieuw kunt beveiligen en failback vanuit Azure kunt uitvoeren.
| Onderdeel | DETAILS |
|---|---|
| On-premises configuratieserver | De on-premises configuratieserver moet worden uitgevoerd en verbonden met Azure. De VM waarnaar u een failback uitvoert, moet aanwezig zijn in de configuratieserverdatabase. Als een noodgeval van invloed is op de configuratieserver, herstelt u deze met hetzelfde IP-adres om ervoor te zorgen dat failback werkt. Als IP-adressen van gerepliceerde machines zijn bewaard tijdens failover, moet er site-naar-site-connectiviteit (of ExpressRoute-connectiviteit) tot stand worden gebracht tussen azure-VM-machines en de failback-NIC van de configuratieserver. Voor bewaarde IP-adressen heeft de configuratieserver twee NIC's nodig: één voor de connectiviteit van de bronmachine en één voor azure-failbackconnectiviteit. Dit voorkomt overlapping van subnetadresbereiken voor de bron en failover-VM's. |
| Processerver in Azure | U hebt een processerver in Azure nodig voordat u een failback naar uw on-premises site kunt uitvoeren. De processerver ontvangt gegevens van de beveiligde Azure-VM en verzendt deze naar de on-premises site. U hebt een netwerk met lage latentie nodig tussen de processerver en de beveiligde VM. Daarom raden we u aan de processerver in Azure te implementeren voor hogere replicatieprestaties. Voor proof-of-concept kunt u de on-premises processerver en ExpressRoute gebruiken met persoonlijke peering. De processerver moet zich in het Azure-netwerk bevinden waarin de failover-VM zich bevindt. De processerver moet ook kunnen communiceren met de on-premises configuratieserver en hoofddoelserver. |
| Afzonderlijke hoofddoelserver | De hoofddoelserver ontvangt failbackgegevens en standaard wordt een Windows-hoofddoelserver uitgevoerd op de on-premises configuratieserver. Aan een hoofddoelserver kunnen maximaal 60 schijven zijn gekoppeld. Als de VM's waarvoor een failback wordt uitgevoerd, meer dan een gezamenlijk totaal van 60 schijven hebben, of als u een failback van grote hoeveelheden verkeer uitvoert, maakt u een afzonderlijke hoofddoelserver voor failback. Als machines worden verzameld in een replicatiegroep voor consistentie met meerdere VM's, moeten de VM's allemaal Windows zijn of allemaal Linux zijn. Waarom? Omdat alle VM's in een replicatiegroep dezelfde hoofddoelserver moeten gebruiken en de hoofddoelserver hetzelfde besturingssysteem (met dezelfde of een hogere versie) moet hebben dan die van de gerepliceerde machines. De hoofddoelserver mag geen momentopnamen op de schijven hebben, anders werken opnieuw beveiligen en failback niet. Het hoofddoel kan geen paravirtuele SCSI-controller hebben. De controller kan alleen een LSI Logic Controller zijn. Zonder een LSI Logic Controller mislukt het opnieuw beveiligen. |
| Replicatiebeleid voor failback | Als u wilt repliceren naar een on-premises site, hebt u een failbackbeleid nodig. Dit beleid wordt automatisch gemaakt wanneer u een replicatiebeleid naar Azure maakt. Het beleid wordt automatisch gekoppeld aan de configuratieserver. Deze is ingesteld op een RPO-drempelwaarde van 15 minuten, retentie van herstelpunten van 24 uur en app-consistente momentopnamefrequentie is 60 minuten. Het beleid kan niet worden bewerkt. |
| Privépeering van site-naar-site-VPN/ExpressRoute | Voor opnieuw beveiligen en failback is een site-naar-site-VPN-verbinding of expressRoute-privépeering nodig om gegevens te repliceren. |
Poorten voor opnieuw beveiligen/failback
Er moeten een aantal poorten zijn geopend voor opnieuw beveiligen/failback. In de volgende afbeelding ziet u de poorten en de stroom voor opnieuw beveiligen/failback.
Een processerver implementeren in Azure
- Stel een processerver in Azure in voor failback.
- Zorg ervoor dat azure-VM's de processerver kunnen bereiken.
- Zorg ervoor dat de site-naar-site-VPN-verbinding of het expressRoute-privépeeringsnetwerk voldoende bandbreedte heeft om gegevens van de processerver naar de on-premises site te verzenden.
Een afzonderlijke hoofddoelserver implementeren
Noteer de vereisten en beperkingen van de hoofddoelserver.
Maak een Windows - of Linux-hoofddoelserver , zodat deze overeenkomt met het besturingssysteem van de VM's die u opnieuw wilt beveiligen en failback wilt uitvoeren.
Zorg ervoor dat u Storage vMotion niet gebruikt voor de hoofddoelserver of failback kan mislukken. De VM-machine kan niet worden gestart omdat de schijven er niet beschikbaar voor zijn.
- Om dit te voorkomen, sluit u de hoofddoelserver uit van uw vMotion-lijst.
- Als een hoofddoel na het opnieuw beveiligen een Storage vMotion-taak ondergaat, worden de beveiligde VM-schijven die zijn gekoppeld aan de hoofddoelserver, gemigreerd naar het doel van de vMotion-taak. Als u hierna een failback probeert uit te geven, mislukt schijfontkoppeling omdat de schijven niet worden gevonden. Het is dan moeilijk om de schijven in uw opslagaccounts te vinden. Als dit gebeurt, zoekt u deze handmatig en koppelt u deze aan de VIRTUELE machine. Daarna kan de on-premises VM worden opgestart.
Voeg een bewaarstation toe aan de bestaande Windows-hoofddoelserver. Voeg een nieuwe schijf toe en formatteer het station. Het bewaarstation wordt gebruikt om de tijdstippen te stoppen waarop de virtuele machine wordt gerepliceerd naar de on-premises site. Let op deze criteria. Als er niet aan wordt voldaan, wordt het station niet vermeld voor de hoofddoelserver:
- Het volume wordt niet gebruikt voor andere doeleinden, zoals een replicatiedoel en is niet in de vergrendelingsmodus.
- Het volume is geen cachevolume. Het aangepaste installatievolume voor de processerver en het hoofddoel komt niet in aanmerking voor een bewaarvolume. Wanneer de processerver en het hoofddoel op een volume zijn geïnstalleerd, is het volume een cachevolume van het hoofddoel.
- Het bestandssysteemtype van het volume is niet FAT of FAT32.
- De volumecapaciteit is niet-nul.
- Het standaardretentievolume voor Windows is het R-volume.
- Het standaardretentievolume voor Linux is /mnt/retention.
Voeg een station toe als u een bestaande processerver gebruikt. Het nieuwe station moet voldoen aan de vereisten in de laatste stap. Als het retentiestation niet aanwezig is, wordt het niet weergegeven in de vervolgkeuzelijst voor selecties in de portal. Nadat u een station hebt toegevoegd aan het on-premises hoofddoel, duurt het maximaal 15 minuten voordat het station wordt weergegeven in de selectie in de portal. U kunt de configuratieserver vernieuwen als het station na 15 minuten niet wordt weergegeven.
Installeer VMware-hulpprogramma's of open-vm-tools op de hoofddoelserver. Zonder de hulpprogramma's kunnen de gegevensarchieven op de ESXi-host van het hoofddoel niet worden gedetecteerd.
Stel de schijf in. EnableUUID=true-instelling in de configuratieparameters van de hoofddoel-VM in VMware. Als deze rij niet bestaat, voegt u deze toe. Deze instelling is vereist om een consistente UUID aan de VMDK te bieden, zodat deze correct wordt gekoppeld.
Controleer de toegangsvereisten voor vCenter Server:
- Als de VM waarop u een failback uitvoert zich op een ESXi-host die wordt beheerd door VMware vCenter Server, moet de hoofddoelserver toegang hebben tot het on-premises VM-bestand (VMDK) om de gerepliceerde gegevens naar de schijven van de virtuele machine te schrijven. Zorg ervoor dat het on-premises VM-gegevensarchief is gekoppeld aan de hoofddoelhost met lees-/schrijftoegang.
- Als de VM zich niet op een ESXi-host bevindt die wordt beheerd door een VMware vCenter Server, maakt Site Recovery een nieuwe VM tijdens het opnieuw beveiligen. Deze VM wordt gemaakt op de ESXi-host waarop u de hoofddoelserver-VM maakt. Kies de ESXi-host zorgvuldig om de VIRTUELE machine te maken op de gewenste host. De harde schijf van de VM moet zich in een gegevensopslag bevinden die toegankelijk is voor de host waarop de hoofddoelserver wordt uitgevoerd.
- Een andere optie, als de on-premises VM al bestaat voor failback, is om deze te verwijderen voordat u een failback uitvoert. Failback maakt vervolgens een nieuwe VIRTUELE machine op dezelfde host als de ESXi-hoofdhost. Wanneer u een failback uitvoert naar een alternatieve locatie, worden de gegevens hersteld naar hetzelfde gegevensarchief en dezelfde ESXi-host als die wordt gebruikt door de on-premises hoofddoelserver.
Voor fysieke machines die een failback uitvoeren naar VMware-VM's, moet u de detectie voltooien van de host waarop de hoofddoelserver wordt uitgevoerd, voordat u de machine opnieuw kunt beveiligen.
Controleer of de ESXi-host waarop de hoofddoel-VM ten minste één VM-gegevensarchief (Virtual Machine File System) bevat. Als er geen VMFS-gegevensarchieven zijn gekoppeld, is de invoer van het gegevensarchief in de instellingen voor opnieuw beveiligen leeg en kunt u niet doorgaan.
Volgende stappen
Meer informatie over het opnieuw beveiligen van een virtuele machine.