Architectuur voor herstel na noodgevallen van VMware naar Azure - Gemoderniseerd

In dit artikel worden de architectuur en processen beschreven die worden gebruikt bij het implementeren van replicatie van herstel na noodgevallen, failover en herstel van virtuele VMware-machines (VM's) tussen een on-premises VMware-site en Azure met behulp van de gemoderniseerde 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 meer informatie over de architectuur van Azure Site Recovery in de klassieke architectuur.

Architectuuronderdelen

De volgende tabel en afbeelding bieden een overzicht op hoog niveau 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. Azure-VM's 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 hele 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. Het zorgt ervoor dat er geen andere internetverbinding is vereist van productieworkloads om herstelpunten te genereren.

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

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

Processerver: Dit onderdeel wordt gebruikt voor caching en 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 met Site Recovery-services en voor het bewaken van de status van alle onderdelen.

Site Recovery provider: dit onderdeel wordt gebruikt voor het vergemakkelijken van opnieuw beveiligen. Er wordt aangegeven tussen alternatieve locatie opnieuw beveiligen en 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 Site Recovery implementatie voegt u VMware-servers toe aan de Recovery Services-kluis.
Gerepliceerde machines Mobility Service wordt geïnstalleerd op elke VMware-VM die u repliceert. We raden u aan automatische installatie van de Mobility-service toe te staan. U kunt de service ook handmatig installeren.

Uitgaande netwerkconnectiviteit instellen

Voor 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
Aanmelden bij uw Azure-abonnement.
*.microsoftonline.com Maak Azure Active Directory-apps (AD) voor het apparaat om te communiceren met Azure Site Recovery.
management.azure.com Maak Azure AD-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 de Azure Key Vault. Opmerking: Zorg ervoor dat machines die moeten worden gerepliceerd, hier toegang toe hebben.
aka.ms Toegang tot 'ook bekend als'-koppelingen toestaan. Wordt gebruikt voor updates van Azure Site Recovery-apparaten.
download.microsoft.com/download Download van Microsoft toestaan.
*.servicebus.windows.net Communicatie tussen het apparaat en de Azure Site Recovery-service.
*.discoverysrv.windowsazure.com Maak verbinding met de URL van de Azure Site Recovery-detectieservice.
*.hypervrecoverymanager.windowsazure.com Verbinding maken met Azure Site Recovery microservice-URL's
*.blob.core.windows.net Gegevens uploaden naar Azure Storage, dat wordt gebruikt om doelschijven te maken
*.backup.windowsazure.com URL van de beveiligingsservice: een microservice die wordt gebruikt door Azure Site Recovery voor het verwerken & van het maken van gerepliceerde schijven in Azure

Replicatieproces

  1. Wanneer u replicatie voor een VM inschakelt, wordt de initiële replicatie naar Azure Storage gestart met behulp van het opgegeven replicatiebeleid. Houd rekening met het volgende:

    • Voor VMware-VM's is replicatie op blokniveau, bijna continu, met behulp van de Mobility-service-agent die op de VM wordt uitgevoerd.
    • Alle instellingen voor replicatiebeleid worden toegepast:
      • RPO-drempelwaarde. Deze instelling heeft geen invloed op replicatie. Het helpt bij de bewaking. Er wordt een gebeurtenis gegenereerd en eventueel een e-mailbericht verzonden als de huidige RPO de drempelwaarde overschrijdt die u opgeeft.
      • Retentie van herstelpunt. Deze instelling geeft aan hoe ver terug in de tijd u wilt gaan wanneer er een onderbreking optreedt. De maximale retentie is 15 dagen.
      • App-consistente momentopnamen. App-consistente momentopnamen kunnen 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 VM vraagt een VSS-momentopname aan in overeenstemming met deze instelling en bladwijzers voor dat tijdstip als een toepassingsconsistent punt in de replicatiestroom.

      Notitie

      Een hoge bewaarperiode voor herstelpunten kan van toepassing zijn op de opslagkosten, omdat er mogelijk meer herstelpunten moeten worden opgeslagen.

  2. Verkeer wordt via internet gerepliceerd naar openbare eindpunten van Azure Storage. 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 computer op het moment van het inschakelen van replicatie naar Azure worden verzonden. Nadat de initiële replicatie is voltooid, begint de replicatie van deltawijzigingen naar Azure. Bijgehouden wijzigingen voor een machine worden verzonden naar de processerver.

  4. Communicatie vindt als volgt plaats:

    • VM's communiceren met het on-premises apparaat op poort HTTPS 443 voor inkomend verkeer, voor replicatiebeheer.
    • VM's verzenden replicatiegegevens naar het apparaat op poort HTTPS 9443 inkomend. Deze poort kan worden gewijzigd.
    • Het apparaat ontvangt replicatiegegevens, optimaliseert en versleutelt deze en verzendt deze naar Azure Storage via poort 443 uitgaand.
  5. De replicatiegegevenslogboeken 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 en de processerver naar Azure. Een van beide kan tijdelijk leiden tot fouten in de gegevensoverdracht naar Azure.
  2. Om problemen met gegevensintegriteit te voorkomen en de kosten voor gegevensoverdracht te minimaliseren, markeert Site Recovery een machine voor hersynchronisatie.
  3. Een machine kan ook worden gemarkeerd voor hersynchronisatie in situaties zoals de volgende om consistentie te behouden tussen de broncomputer en gegevens die zijn opgeslagen in Azure
    • Als een machine geforceerd wordt afgesloten
    • Als een computer configuratiewijzigingen ondergaat, zoals schijfgrootte wijzigen (de grootte van de schijf wijzigen van 2 TB in 4 TB)
  4. Met hersynchronisatie worden alleen deltagegevens naar Azure verzonden. Gegevensoverdracht tussen on-premises en Azure door te minimaliseren door controlesommen van gegevens tussen de broncomputer en gegevens die zijn opgeslagen in Azure te berekenen.
  5. Hersynchronisatie is standaard zo gepland dat deze automatisch buiten kantooruren wordt uitgevoerd. Als u buiten uren niet wilt wachten op standaardhersynchronisatie, kunt u een VM handmatig opnieuw synchroniseren. Ga hiervoor naar Azure Portal en selecteer 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. Na voltooiing van de hersynchronisatie 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 wanneer u replicatie inschakelt.
  • U kunt nieuw replicatiebeleid maken of bewerken terwijl u replicatie probeert in te schakelen.

Multi-VM-consistentie

Als u wilt dat VM's samen repliceren en gedeelde crashconsistente en app-consistente herstelpunten hebben bij failover, kunt u ze samen verzamelen in een replicatiegroep. Multi-VM-consistentie is van invloed op de prestaties van workloads en mag alleen worden gebruikt voor VM's 4-workloads die consistentie op alle machines 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 VM, gebruikt u een herstelpunt om de VM op de doellocatie te herstellen.

Wanneer een failover wordt uitgevoerd, willen we er over het algemeen voor zorgen dat de VM wordt gestart zonder beschadiging of gegevensverlies, en dat de VM-gegevens consistent zijn voor het besturingssysteem en voor apps die op de VM worden uitgevoerd. 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 retentie-instellingen in het replicatiebeleid.

Consistentie

In de volgende tabel worden de verschillende typen consistentie uitgelegd.

Crashconsistent

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

Het bevat het equivalent van de gegevens op schijf die aanwezig zouden zijn als de VM is vastgelopen of het netsnoer van de server is gehaald op het moment dat de momentopname is gemaakt.

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

Tegenwoordig kunnen de meeste apps goed herstellen na crashconsistente punten.

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

App-consistent

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 back-upmethode alleen kopiëren (VSS_BT_COPY), waardoor de back-uptijd van het microsoft SQL-transactielogboek en het volgnummer

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

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

4) VSS staat vervolgens toe dat de app voor back-up/herstel na noodgevallen (in dit geval Site Recovery) de momentopnamegegevens kan lezen en verder kan gaan.
App-consistente momentopnamen worden gemaakt in overeenstemming met de frequentie die u opgeeft. Deze frequentie moet altijd lager zijn dan u hebt ingesteld voor het behouden van herstelpunten. Als u bijvoorbeeld herstelpunten behoudt met de standaardinstelling van 24 uur, moet u de frequentie instellen op minder dan 24 uur.

Ze zijn complexer en duren langer 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) hebt uitgevoerd om te controleren of alles naar verwachting werkt, kunt u failover en failback uitvoeren als dat nodig is.

  1. U kunt failover uitvoeren voor één computer of een herstelplan maken om een failover van meerdere VM's tegelijk uit te voeren. 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 genomen in één herstelplan.
    • U kunt scripts, Azure-runbooks toevoegen en onderbreken voor handmatige acties.
  2. Nadat u de eerste failover hebt geactiveerd, moet u deze doorvoeren 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 een failback. Als u een failback moet uitvoeren voor grote hoeveelheden verkeer, stelt u een nieuw Azure Site Recovery-replicatieapparaat in.

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

Volgende stappen

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