Architectuur voor herstel na noodherstel van VMware naar Azure - klassiek
In dit artikel worden de architectuur en processen beschreven die worden gebruikt bij het implementeren van replicatie na noodherstel, 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 architectuurdetails in preview
Architectuuronderdelen
De volgende tabel en afbeelding bieden een overzicht op hoog niveau van de onderdelen die worden gebruikt voor VMware-VM's/fysieke machines na noodherstel 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. Azure-VM's worden gemaakt met de gerepliceerde gegevens wanneer u een failover van on-premises naar Azure hebt uitgevoerd. 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 uitgevoerd, waaronder de configuratieserver, de processerver en de masterdoelserver. |
Configuratieserver: coördineert de communicatie tussen on-premises en Azure en beheert gegevensreplicatie. Processerver: standaard geïnstalleerd op de configuratieserver. Deze ontvangt replicatiegegevens; optimaliseert deze 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 te verwerken. Masterdoelserver: standaard geïnstalleerd op de configuratieserver. Replicatiegegevens worden tijdens de failback vanuit Azure verwerkt. 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 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. | 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. |
Uitgaande netwerkconnectiviteit instellen
Om Site Recovery te laten werken zoals verwacht, moet u de uitgaande netwerkconnectiviteit wijzigen zodat uw omgeving kan repliceren.
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:
| 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. |
| Azure Active Directory | 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 vereisten voor een volledige lijst met URL's die moeten worden gefilterd voor communicatie tussen on-premises Azure Site Recovery-infrastructuur en Azure-services.
Replicatieproces
Wanneer u replicatie voor een VM inschakelen, begint de initiële replicatie naar Azure Storage met behulp van het opgegeven replicatiebeleid. Houd rekening met het volgende:
- Voor VMware-VM's is replicatie bijna doorlopend op blokniveau, met behulp van de Mobility-service agent die wordt uitgevoerd op de VM.
- Instellingen voor replicatiebeleid worden toegepast:
- RPO-drempelwaarde. Deze instelling heeft geen invloed op replicatie. Het helpt bij de bewaking. Er wordt een gebeurtenis verhoogd en eventueel een e-mailbericht verzonden als de huidige RPO de door u opgegeven drempelwaarde overschrijdt.
- Bewaarperiode van herstelpunt. Met deze instelling bepaalt u hoe ver terug in de tijd u wilt gaan wanneer er een onderbreking optreedt. De maximale retentie voor Premium Storage is 24 uur. Bij standaardopslag is dit 72 uur.
- 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 die op een bepaald tijdstip als een toepassingsconsys consistent punt in de replicatiestroom worden gebruikt.
Verkeer wordt via internet gerepliceerd naar openbare eindpunten van Azure Storage. U kunt ook een Azure ExpressRoute 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.
De initiële replicatiebewerking zorgt ervoor dat volledige gegevens op de machine op het moment van inschakelen naar Azure worden verzonden. Nadat de initiële replicatie is uitgevoerd, begint de replicatie van deltawijzigingen naar Azure. Bij te houden wijzigingen voor een machine worden verzonden naar de processerver.
De communicatie vindt als volgt plaats:
- VM's communiceren met de on-premises configuratieserver op binnenkomende HTTPS-poort 443 voor replicatiebeheer.
- De configuratieserver orkestreert replicatie met Azure via uitgaande HTTPS-poort 443.
- VM's verzenden replicatiegegevens naar de processerver (die wordt uitgevoerd op de configuratieservermachine) op binnenkomende HTTPS-poort 9443. Deze poort kan worden gewijzigd.
- De processerver ontvangt replicatiegegevens, optimaliseert en versleutelt deze en verzendt deze naar Azure Storage via uitgaande poort 443.
De replicatiegegevenslogboeken worden eerst in een cacheopslagaccount in Azure geplaatst. Deze logboeken worden verwerkt en de gegevens worden opgeslagen in een Azure Managed Disk (aangeroepen als Azure Site Recovery seed-schijf). De herstelpunten worden op deze schijf gemaakt.
Hersynchronisatieproces
- Soms, tijdens de initiële replicatie of tijdens het overbrengen van deltawijzigingen, kunnen er problemen zijn met de netwerkverbinding tussen de bronmachine en de processerver of tussen de processerver en Azure. Beide kunnen tijdelijk leiden tot fouten bij gegevensoverdracht naar Azure.
- Om problemen met de gegevensintegriteit te voorkomen en de kosten voor gegevensoverdracht te minimaliseren, Site Recovery een machine voor hersynchronisatie markeert.
- Een machine kan ook worden gemarkeerd voor hersynchronisatie in situaties zoals de volgende om consistentie te behouden tussen de bronmachine en gegevens die zijn opgeslagen in Azure
- Als een machine geforceerf wordt afgesloten
- Als een machine configuratiewijzigingen ondergaat, zoals het wijzigen van de grootte van de schijf (van 2 TB tot 4 TB)
- Hersynchronisatie verzendt alleen deltagegevens naar Azure. Gegevensoverdracht tussen on-premises en Azure door controlesomen van gegevens tussen de broncomputer en gegevens die zijn opgeslagen in Azure te berekenen, wordt geminimaliseerd.
- Hersynchronisatie is standaard gepland om automatisch buiten kantooruren te worden uitgevoerd. Als u niet buiten uren wilt wachten op standaard hersynchronisatie, kunt u een VM handmatig opnieuw synchroniseren. Ga hiervoor naar Azure Portal, selecteer de VM-> Opnieuw synchroniseren.
- Als de standaardsynchronisatie buiten kantooruren mislukt en handmatig ingrijpen is vereist, wordt er een fout gegenereerd op de specifieke computer in Azure Portal. U kunt de fout oplossen en de hersynchronisatie handmatig activeren.
- Nadat de hersynchronisatie is voltooid, wordt de replicatie van deltawijzigingen hervat.
Beleid voor replicatie
Wanneer u Azure VM-replicatie inschakelen, maakt Site Recovery 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 behoudt | 24 uur |
| Frequentie van de app-consistente momentopname | Hoe vaak Site Recovery een app-consistente momentopname maakt. | Om de vier uur |
Replicatiebeleid beheren
U kunt de standaardinstellingen voor replicatiebeleid als volgt beheren en wijzigen:
- U kunt de instellingen wijzigen wanneer u replicatie inschakelen.
- U kunt op elk moment een replicatiebeleid maken en dit vervolgens toepassen wanneer u replicatie inschakelen.
Consistentie van meerdere VM's
Als u wilt dat VM's samen worden gerepliceerd en gedeelde crash-consistente en app-consistente herstelpunten hebben tijdens failover, kunt u deze samenbrengen in een replicatiegroep. Consistentie met meerdere VM's is van invloed op de prestaties van de werkbelasting en mag alleen worden gebruikt voor VM's met workloads die consistentie op alle computers nodig hebben.
Momentopnamen en herstelpunten
Herstelpunten worden gemaakt van momentopnamen van VM-schijven die op een bepaald tijdstip zijn gemaakt. Wanneer u een fail over een VM maakt, gebruikt u een herstelpunt om de VM op de doellocatie te herstellen.
Wanneer er een fout wordt uitgevoerd, willen we er doorgaans voor zorgen dat de VM zonder beschadiging of gegevensverlies begint, 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:
- Site Recovery maakt standaard crash-consistente momentopnamen van gegevens en app-consistente momentopnamen als u er een frequentie voor opgeeft.
- 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.
Crash-consistent
| Beschrijving | Details | Aanbeveling |
|---|---|---|
| Een crash-consistente momentopname legt gegevens vast die op de schijf stonden toen de momentopname werd gemaakt. Er wordt niets in het geheugen opgeslagen. Het bevat het equivalent van de on-disk-gegevens die aanwezig zouden zijn als de VM is vastgelopen of als het netsnoer van de server werd gehaald op het moment dat de momentopname werd gemaakt. Crashconsistent biedt geen garantie voor gegevensconsistentie voor het besturingssysteem of voor apps op de VM. |
Site Recovery maakt standaard elke vijf minuten crash-consistente herstelpunten. Deze instelling kan niet worden gewijzigd. |
Tegenwoordig kunnen de meeste apps goed worden hersteld vanaf crash-consistente punten. Crash-consistente 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 vanuit app-consistente momentopnamen. Een app-consistente momentopname bevat alle informatie in een crash-consistente momentopname, plus alle gegevens in het geheugen en de transacties die worden uitgevoerd. |
App-consistente momentopnamen gebruiken de Volume Shadow Copy Service (VSS): 1) Azure Site Recovery de methode Copy Only backup (VSS_BT_COPY) gebruikt, waardoor de back-uptijd en het volgnummer van het transactielogboek van Microsoft SQL niet worden gewijzigd 2) Wanneer een momentopname wordt gestart, voert VSS een COPY-on-write-bewerking (COPY) uit op het volume. 3) Voordat de WORDT UITGEVOERD, informeert VSS elke app op de computer dat de in het geheugen opgeslagen gegevens naar de schijf moeten worden leeg gemaakt. 4) VSS staat vervolgens de app voor back-up/herstel na noodgeval toe (in dit geval Site Recovery) 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 hebt ingesteld voor het behouden van herstelpunten. Als u herstelpunten bijvoorbeeld behoudt met de standaardinstelling van 24 uur, moet u de frequentie instellen op minder dan 24 uur. Ze zijn complexer en duren langer dan crash-consistente 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 noodhersteloefening (test-failover) hebt uitgevoerd om te controleren of alles werkt zoals verwacht, kunt u naar behoefte failover en failback uitvoeren.
U kunt een fail uitvoeren voor één computer of een herstelplan maken om tegelijkertijd een fail over meerdere VM's uit te voeren. Het voordeel van een herstelplan in plaats van failover van één machine is:
- U kunt app-afhankelijkheden modelleren door alle VM's in de app in één herstelplan op te geven.
- U kunt scripts, Azure-runbooks toevoegen en onderbreken voor handmatige acties.
Na het activeren van de eerste failover, geeft u deze door om toegang te krijgen tot de workload vanaf de Azure-VM.
Wanneer uw primaire on-premises site weer beschikbaar is, kunt u zich voorbereiden op failback. Als u een failback wilt maken, moet u een failback-infrastructuur instellen, waaronder:
- Tijdelijke processerver in Azure: als u een failback vanuit Azure wilt uitvoeren, 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 masterdoelserver: de hoofddoelserver die met de configuratieserver op de on-premises VMware-VM is geïnstalleerd, verwerkt standaard de failback. Als u een failback wilt maken van grote hoeveelheden verkeer, stelt u een afzonderlijke on-premises doelserver voor dit doel 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.
Nadat de onderdelen zijn op hun plaats, vindt failback plaats in drie acties:
- Fase 1: beveilig de Azure-VM's opnieuw, zodat ze vanuit Azure worden gerepliceerd naar de on-premises VMware-VM's.
- Fase 2: voer een failover uit naar de on-premises site.
- Fase 3: nadat er een fout is opgetreden in workloads, kunt u replicatie voor de on-premises VM's opnieuw in- of uitvoeren.
Volgende stappen
Volg deze zelfstudie om replicatie van VMware naar Azure in teschakelen.