Delen via

Architectuur voor herstel na noodgevallen van VMware naar Azure - Gemoderniseerd

  • 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 modernized VMware-/fysieke machinebeveiligingservaring.

Notitie

Zorg ervoor dat u een nieuwe Recovery Services-kluis maakt voor het instellen van het ASR-replicatieapparaat. Gebruik geen bestaande kluis.

Zie dit artikel voor informatie over de Architectuur van Azure Site Recovery in de klassieke 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.

VMware naar Azure-architectuur

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.
Azure Site Recovery-replicatieapparaat Dit is de basisbouwsteen van de volledige on-premises Infrastructuur van Azure Site Recovery.

Alle onderdelen in het apparaat coördineren met het replicatieapparaat. Deze service houdt toezicht op alle end-to-end Site Recovery-activiteiten, waaronder het bewaken van de status van beveiligde machines, gegevensreplicatie, automatische updates, enzovoort.		 Het apparaat host verschillende cruciale onderdelen, zoals:

Proxyserver: dit onderdeel fungeert als een proxykanaal tussen mobility-agent en Site Recovery-services in de cloud. Er is geen andere internetverbinding vereist voor productieworkloads om herstelpunten te genereren.

Gedetecteerde items: Dit onderdeel verzamelt informatie van vCenter en coördineert met de Azure Site Recovery-beheerservice in de cloud.

Server voor opnieuw beveiligen: dit onderdeel coördineert tussen Azure- en on-premises machines tijdens opnieuw beveiligen en failbackbewerkingen.

Processerver: dit onderdeel wordt gebruikt voor caching, compressie van gegevens voordat ze naar Azure worden verzonden.

Meer informatie over het replicatieapparaat en het gebruik van meerdere replicatieapparaten.

Recovery Service-agent: dit onderdeel wordt gebruikt voor het configureren/registreren bij Site Recovery-services en voor het bewaken van de status van alle onderdelen.

Site Recovery-provider: dit onderdeel wordt gebruikt om het opnieuw beveiligen te vergemakkelijken. Het identificeert tussen het opnieuw beveiligen van alternatieve locaties en de oorspronkelijke locatie opnieuw beveiligen voor een bronmachine.

Replicatieservice: dit onderdeel wordt gebruikt voor het repliceren van gegevens van de bronlocatie naar Azure.
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 van de Mobility-service toe te staan. U kunt de service ook handmatig installeren.

Uitgaande netwerkconnectiviteit instellen

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

Notitie

Site Recovery biedt geen ondersteuning voor het gebruiken van een verificatieproxy om netwerkconnectiviteit te beheren.

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:

URL DETAILS
portal.azure.com Navigeer naar de Azure Portal.
*.windows.net
*.msftauth.net
*.msauth.net
*.microsoft.com
*.live.com
*.office.com 		Meld u aan bij uw Azure-abonnement.
*.microsoftonline.com Maak Microsoft Entra-apps voor het apparaat om te communiceren met Azure Site Recovery.
management.azure.com Maak Microsoft Entra-apps voor het apparaat om te communiceren met de Azure Site Recovery-service.
*.services.visualstudio.com App-logboeken uploaden die worden gebruikt voor interne bewaking.
*.vault.azure.net Geheimen beheren in Azure Key Vault. Opmerking: Zorg ervoor dat machines die moeten worden gerepliceerd, toegang hebben tot dit.
aka.ms Hiermee staat u toegang toe tot koppelingen met de naam 'ook wel bekend als'. Wordt gebruikt voor azure Site Recovery-apparaatupdates.
download.microsoft.com/download Downloads van Microsoft downloaden toestaan.
*.servicebus.windows.net Communicatie tussen het apparaat en de Azure Site Recovery-service.
*.discoverysrv.windowsazure.com Verbinding maken met azure Site Recovery-detectieservice-URL.
*.hypervrecoverymanager.windowsazure.com Verbinding maken met microservice-URL's van Azure Site Recovery.
*.blob.core.windows.net Upload gegevens naar Azure Storage, die wordt gebruikt om doelschijven te maken.
*.backup.windowsazure.com URL van de beveiligingsservice: een microservice die wordt gebruikt door Azure Site Recovery voor verwerking en het maken van gerepliceerde schijven in Azure.
*.prod.migration.windowsazure.com Om uw on-premises landgoed te ontdekken.

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.
      • 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 alleen ondersteund bij het gebruik van privé-eindpunten.

  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 het on-premises apparaat op poort HTTPS 443 binnenkomend, voor replicatiebeheer.
    • VM's verzenden replicatiegegevens naar het apparaat op poort HTTPS 9443 binnenkomend. Deze poort kan worden gewijzigd.
    • Het apparaat ontvangt replicatiegegevens, optimaliseert en versleutelt het en verzendt het 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 (asrseeddisk genoemd). De herstelpunten worden op deze schijf gemaakt.

VMware-naar-Azure-gegevensstroom met poorten

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. Hersynchronisatie is standaard zo gepland dat deze automatisch buiten kantooruren wordt 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.

Beleid voor replicatie

Wanneer u Azure VM-replicatie inschakelt, maakt Site Recovery standaard een nieuw replicatiebeleid met de standaardinstellingen die in de tabel worden samengevat.

Beleidsinstelling DETAILS Standaard
Bewaarperiode van herstelpunt Hiermee geeft u op hoe lang Site Recovery herstelpunten bewaart 1 dag
Frequentie van de app-consistente momentopname Hoe vaak Site Recovery een app-consistente momentopname maakt Uitgeschakeld

Replicatiebeleid beheren

U kunt de standaardinstellingen voor replicatiebeleid als volgt beheren en wijzigen:

  • U kunt de instellingen wijzigen terwijl u replicatie inschakelt.
  • U kunt een nieuw replicatiebeleid maken of bewerken tijdens het inschakelen van replicatie.

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 4-workloads 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 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), waarmee de back-uptijd van het transactielogboek van Microsoft SQL en het volgnummer

2 niet wordt gewijzigd) 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 kunt een failover-overschakeling uitvoeren voor één machine of een herstelplan maken om tegelijkertijd een failover uit te voeren voor meerdere VM's. 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 voor grote hoeveelheden verkeer, stelt u een nieuw Azure Site Recovery-replicatieapparaat in.

    • 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.

Volgende stappen

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