Architectuur voor herstel na noodgevallen van VMware naar Azure - klassiek

  • Artikel

In dit artikel worden de architectuur en processen beschreven die worden gebruikt bij het implementeren van replicatie, failover en herstel van virtuele VMware-machines (VM's) tussen een on-premises VMware-site en Azure met behulp van de Azure Site Recovery-service - klassiek.

Zie dit artikel voor meer informatie over de gemoderniseerde architectuur

Architectuuronderdelen

De volgende tabel en afbeelding bieden een algemeen overzicht van de onderdelen die worden gebruikt voor herstel na noodgevallen van VMware-VM's/fysieke machines naar Azure.

Onderdeel Vereiste Details
Azure Een Azure-abonnement, Azure Storage-account voor cache, Managed Disk en Azure-netwerk. Gerepliceerde gegevens van on-premises VM's worden opgeslagen in Azure Storage. Virtuele Azure-machines worden gemaakt met de gerepliceerde gegevens wanneer u een failover uitvoert van on-premises naar Azure. De Azure-VM's maken verbinding met het virtuele Azure-netwerk wanneer ze worden gemaakt.
Configuratieservermachine Eén on-premises machine. U wordt aangeraden deze uit te voeren als een VMware-VM die kan worden geïmplementeerd vanuit een gedownloade OVF-sjabloon.

Op de computer worden alle on-premises Site Recovery-onderdelen uitgevoerd, waaronder de configuratieserver, de processerver en de hoofddoelserver.		 Configuratieserver: coördineert de communicatie tussen on-premises en Azure en beheert de gegevensreplicatie.

Processerver: standaard geïnstalleerd op de configuratieserver. Het ontvangt replicatiegegevens; optimaliseert het met caching, compressie en versleuteling; en verzendt deze naar Azure Storage. De processerver installeert ook Azure Site Recovery Mobility Service op VM's die u wilt repliceren, en detecteert automatisch on-premises computers. Naarmate uw implementatie groeit, kunt u extra, afzonderlijke processervers toevoegen om grotere volumes replicatieverkeer af te handelen.

Hoofddoelserver: standaard geïnstalleerd op de configuratieserver. Het verwerkt replicatiegegevens tijdens failback vanuit Azure. Voor grote implementaties kunt u een extra, afzonderlijke hoofddoelserver voor failback toevoegen.
VMware-servers VMware-VM's worden gehost op on-premises vSphere ESXi-servers. We raden een vCenter-server aan om de hosts te beheren. Tijdens de implementatie van Site Recovery voegt u VMware-servers toe aan de Recovery Services-kluis.
Gerepliceerde machines Mobility Service wordt geïnstalleerd op elke virtuele VMware-machine die u repliceert. U wordt aangeraden automatische installatie vanaf de processerver toe te staan. U kunt de service ook handmatig installeren of een geautomatiseerde implementatiemethode gebruiken, zoals Configuration Manager.

Diagram showing VMware to Azure replication architecture relationships.

Uitgaande netwerkconnectiviteit instellen

Als Site Recovery werkt zoals verwacht, moet u de uitgaande netwerkverbinding wijzigen zodat uw omgeving kan worden gerepliceerd.

Notitie

Site Recovery van VMware-/fysieke machines die gebruikmaken van de klassieke architectuur biedt geen ondersteuning voor het gebruik van een verificatieproxy om de netwerkverbinding te beheren. Hetzelfde wordt ondersteund bij het gebruik van de gemoderniseerde architecutre.

Uitgaande connectiviteit voor URL's

Als u een URL-firewallproxy gebruikt om de uitgaande connectiviteit te beheren, staat u toegang tot deze URL’s toe:

Naam Commercieel Overheid Beschrijving
Storage *.blob.core.windows.net *.blob.core.usgovcloudapi.net Hiermee kunnen gegevens van de VM naar het cache-opslagaccount in de bronregio worden geschreven.
Microsoft Entra ID login.microsoftonline.com login.microsoftonline.us Verzorgt autorisatie en authenticatie voor de URL’s van Site Recovery.
Replicatie *.hypervrecoverymanager.windowsazure.com *.hypervrecoverymanager.windowsazure.us Maakt het de VM mogelijk te communiceren met de Site Recovery-service.
Service Bus *.servicebus.windows.net *.servicebus.usgovcloudapi.net Maakt het de VM mogelijk bewakings- en diagnosegegevens van Site Recovery te schrijven.

Raadpleeg de sectie netwerkvereisten in het artikel over vereisten voor uitgebreide lijst met URL's die moeten worden gefilterd voor communicatie tussen de on-premises Azure Site Recovery-infrastructuur en Azure-services.

Replicatieproces

  1. Wanneer u replicatie voor een VIRTUELE machine inschakelt, begint de initiële replicatie naar Azure Storage met behulp van het opgegeven replicatiebeleid. Let op het volgende:

    • Voor virtuele VMware-machines is replicatie op blokniveau, bijna doorlopend, met behulp van de Mobility-service-agent die wordt uitgevoerd op de virtuele machine.
    • Alle instellingen voor replicatiebeleid worden toegepast:
      • RPO-drempelwaarde. Deze instelling heeft geen invloed op replicatie. Het helpt bij het bewaken. Er wordt een gebeurtenis gegenereerd en eventueel een e-mailbericht verzonden als de huidige RPO de drempelwaarde overschrijdt die u opgeeft.
      • Bewaarperiode van herstelpunt. Met deze instelling geeft u op hoe ver terug in de tijd u wilt gaan wanneer er een onderbreking optreedt. Maximale retentie is 15 dagen op beheerde schijf.
      • App-consistente momentopnamen. App-consistente momentopname kan elke 1 tot 12 uur worden gemaakt, afhankelijk van de behoeften van uw app. Momentopnamen zijn standaard Azure Blob-momentopnamen. De Mobility-agent die wordt uitgevoerd op een virtuele machine vraagt een VSS-momentopname aan overeenkomstig deze instelling en bladwijzers die naar een bepaald tijdstip verwijzen als een toepassingsconsistent punt in de replicatiestroom.

      Notitie

      Een hoge bewaarperiode voor herstelpunten kan een implicatie hebben voor de opslagkosten, omdat er mogelijk meer herstelpunten moeten worden opgeslagen.

  2. Verkeer repliceert naar openbare Eindpunten van Azure Storage via internet. U kunt ook Azure ExpressRoute gebruiken met Microsoft-peering. Het repliceren van verkeer via een site-naar-site virtueel particulier netwerk (VPN) van een on-premises site naar Azure wordt niet ondersteund.

  3. De initiële replicatiebewerking zorgt ervoor dat volledige gegevens op de machine op het moment dat replicatie is ingeschakeld, naar Azure worden verzonden. Nadat de initiële replicatie is voltooid, begint de replicatie van deltawijzigingen in Azure. Bijgehouden wijzigingen voor een machine worden naar de processerver verzonden.

  4. Communicatie vindt als volgt plaats:

    • VM's communiceren met de on-premises configuratieserver op poort HTTPS 443 binnenkomend, voor replicatiebeheer.
    • De configuratieserver organiseert replicatie met Azure via poort HTTPS 443 uitgaand.
    • VIRTUELE machines verzenden replicatiegegevens naar de processerver (uitgevoerd op de configuratieservercomputer) op poort HTTPS 9443 inkomend verkeer. Deze poort kan worden gewijzigd.
    • De processerver ontvangt replicatiegegevens, optimaliseert en versleutelt deze en verzendt deze naar Azure-opslag via poort 443 uitgaand.

  5. De logboeken voor replicatiegegevens komen eerst terecht in een cacheopslagaccount in Azure. Deze logboeken worden verwerkt en de gegevens worden opgeslagen in een Azure Managed Disk (ook wel Azure Site Recovery seed disk genoemd). De herstelpunten worden op deze schijf gemaakt.

Diagram showing the VMware to Azure replication process.

Hersynchronisatieproces

  1. Soms, tijdens de initiële replicatie of tijdens het overdragen van deltawijzigingen, kunnen er netwerkverbindingsproblemen zijn tussen de broncomputer om de server of tussen processervers naar Azure te verwerken. Een van deze kan leiden tot fouten in gegevensoverdracht naar Azure.
  2. Site Recovery markeert een machine voor hersynchronisatie om problemen met gegevensintegriteit te voorkomen en de kosten voor gegevensoverdracht te minimaliseren.
  3. Een machine kan ook worden gemarkeerd voor hersynchronisatie in situaties zoals het volgende om consistentie te behouden tussen de bronmachine en de gegevens die zijn opgeslagen in Azure
    • Als een machine geforceerd wordt afgesloten
    • Als een machine configuratiewijzigingen ondergaat, zoals schijfgrootte wijzigen (de grootte van de schijf wijzigen van 2 TB in 4 TB)
  4. Hersynchronisatie verzendt alleen deltagegevens naar Azure. Gegevensoverdracht tussen on-premises en Azure wordt geminimaliseerd door controlesommen van gegevens te berekenen tussen de bronmachine en de gegevens die zijn opgeslagen in Azure.
  5. Standaard is hersynchronisatie gepland om automatisch buiten kantooruren te worden uitgevoerd. Als u niet wilt wachten op standaardhersynchronisatie buiten kantooruren, kunt u een virtuele machine handmatig opnieuw synchroniseren. Hiervoor gaat u naar Azure Portal en selecteert u de VM >opnieuw synchroniseren.
  6. Als de standaardhersynchronisatie buiten kantooruren mislukt en handmatige interventie is vereist, wordt er een fout gegenereerd op de specifieke computer in Azure Portal. U kunt de fout oplossen en de hersynchronisatie handmatig activeren.
  7. Nadat de hersynchronisatie is voltooid, wordt de replicatie van deltawijzigingen hervat.

Replicatiebeleid beheren

  • U kunt de instellingen van replicatiebeleid aanpassen terwijl u replicatie inschakelt.
  • U kunt op elk gewenst moment een replicatiebeleid maken en dit toepassen wanneer u replicatie inschakelt.

Consistentie van meerdere VM's

Als u wilt dat VM's samen worden gerepliceerd en gedeelde crashconsistente en app-consistente herstelpunten bij failover hebben, kunt u deze samen verzamelen in een replicatiegroep. Consistentie met meerdere VM's heeft invloed op de workloadprestaties en mag alleen worden gebruikt voor VM's waarop workloads worden uitgevoerd die consistentie op alle computers nodig hebben.

Momentopnamen en herstelpunten

Herstelpunten worden gemaakt op basis van momentopnamen van VM-schijven die op een bepaald tijdstip zijn gemaakt. Wanneer u een failover uitvoert voor een virtuele machine, gebruikt u een herstelpunt om de VM op de doellocatie te herstellen.

Wanneer u een failover uitvoert, willen we er over het algemeen voor zorgen dat de VIRTUELE machine begint zonder beschadiging of gegevensverlies en dat de VM-gegevens consistent zijn voor het besturingssysteem en voor apps die worden uitgevoerd op de VIRTUELE machine. Dit is afhankelijk van het type momentopnamen dat is gemaakt.

Site Recovery maakt als volgt momentopnamen:

  1. Site Recovery maakt standaard crashconsistente momentopnamen van gegevens en app-consistente momentopnamen als u een frequentie voor deze momentopnamen opgeeft.
  2. Herstelpunten worden gemaakt op basis van de momentopnamen en opgeslagen in overeenstemming met de bewaarinstellingen in het replicatiebeleid.

Consistentie

In de volgende tabel worden verschillende typen consistentie uitgelegd.

Crashconsistent

Beschrijving DETAILS Aanbeveling
Een crashconsistente momentopname legt gegevens vast die zich op de schijf bevinden toen de momentopname werd gemaakt. Het bevat niets in het geheugen.

Het bevat het equivalent van de on-disk-gegevens die aanwezig zouden zijn als de virtuele machine vastliep of het netsnoer van de server werd gehaald op het moment dat de momentopname werd gemaakt.

Een crashconsistente garandeert geen gegevensconsistentie voor het besturingssysteem of voor apps op de VIRTUELE machine.		 Site Recovery maakt standaard om de vijf minuten crashconsistente herstelpunten. Deze instelling kan niet worden gewijzigd.

 Tegenwoordig kunnen de meeste apps goed herstellen van crashconsistente punten.

Crashconsistente herstelpunten zijn meestal voldoende voor de replicatie van besturingssystemen en apps zoals DHCP-servers en afdrukservers.

Appconsistent

Beschrijving DETAILS Aanbeveling
App-consistente herstelpunten worden gemaakt op basis van app-consistente momentopnamen.

Een app-consistente momentopname bevat alle informatie in een crashconsistente momentopname, plus alle gegevens in het geheugen en transacties die worden uitgevoerd.		 App-consistente momentopnamen maken gebruik van de Volume Shadow Copy Service (VSS):

1) Azure Site Recovery maakt gebruik van de methode Alleen back-up kopiëren (VSS_BT_COPY), die de back-uptijd van het transactielogboek van Microsoft SQL en het volgnummer

2 niet wijzigt) Wanneer een momentopname wordt gestart, voert VSS een copy-on-write-bewerking (COW) uit op het volume.

3) Voordat de COW wordt uitgevoerd, informeert VSS elke app op de computer dat deze de geheugen-residente gegevens naar de schijf moet leegmaken.

4) VSS staat de back-up-/noodherstel-app (in dit geval Site Recovery) toe om de momentopnamegegevens te lezen en door te gaan.		 App-consistente momentopnamen worden gemaakt volgens de frequentie die u opgeeft. Deze frequentie moet altijd kleiner zijn dan u instelt voor het behouden van herstelpunten. Als u bijvoorbeeld herstelpunten behoudt met behulp van de standaardinstelling van 24 uur, moet u de frequentie instellen op minder dan 24 uur.

Ze zijn complexer en duren langer om te voltooien dan crashconsistente momentopnamen.

Ze zijn van invloed op de prestaties van apps die worden uitgevoerd op een VM die is ingeschakeld voor replicatie.

Failover- en failbackproces

Nadat de replicatie is ingesteld en u een noodherstelanalyse (testfailover) uitvoert om te controleren of alles werkt zoals verwacht, kunt u failover en failback uitvoeren zoals dat nodig is.

  1. U voert een failover uit voor één machine of maakt een herstelplan voor een failover van meerdere VM's tegelijk. Het voordeel van een herstelplan in plaats van failover van één machine zijn:

    • U kunt app-afhankelijkheden modelleren door alle VM's in de app op te geven in één herstelplan.
    • U kunt scripts, Azure-runbooks toevoegen en onderbreken voor handmatige acties.

  2. Nadat u de eerste failover hebt geactiveerd, voert u deze door om toegang te krijgen tot de workload vanaf de Azure-VM.

  3. Wanneer uw primaire on-premises site weer beschikbaar is, kunt u zich voorbereiden op failback. Als u een failback wilt uitvoeren, moet u een failback-infrastructuur instellen, waaronder:

    • Tijdelijke processerver in Azure: als u een failback wilt uitvoeren vanuit Azure, stelt u een Azure-VM in om te fungeren als processerver voor het afhandelen van replicatie vanuit Azure. U kunt deze virtuele machine verwijderen wanneer de failback is voltooid.
    • VPN-verbinding: als u een failback wilt uitvoeren, hebt u een VPN-verbinding (of ExpressRoute) van het Azure-netwerk naar de on-premises site nodig.
    • Afzonderlijke hoofddoelserver: de hoofddoelserver die is geïnstalleerd met de configuratieserver op de on-premises VMware-VM verwerkt failback. Als u een failback wilt uitvoeren voor grote hoeveelheden verkeer, stelt u hiervoor een afzonderlijke on-premises hoofddoelserver in.
    • Failbackbeleid: als u wilt repliceren naar de on-premises site, hebt u een failbackbeleid nodig. Dit beleid wordt automatisch gemaakt wanneer u een replicatiebeleid maakt van on-premises naar Azure.

  4. Nadat de onderdelen zijn ingesteld, vindt failback plaats in drie acties:

    • Fase 1: Beveilig de Virtuele Azure-machines opnieuw zodat ze van Azure worden gerepliceerd naar de on-premises VMware-VM's.
    • Fase 2: Voer een failover uit naar de on-premises site.
    • Fase 3: Nadat de failover van workloads is mislukt, kunt u replicatie voor de on-premises VM's opnieuw inschakelen.

Diagram showing VMware failback from Azure.

Volgende stappen

Volg deze zelfstudie om replicatie van VMware naar Azure in te schakelen.