Arkitektur för haveriberedskap i VMware till Azure – Moderniserad

  • Artikel

Den här artikeln beskriver arkitekturen och processerna som används när du distribuerar replikering, redundans och återställning av virtuella VMware-datorer mellan en lokal VMware-plats och Azure med hjälp av den moderniserade VMware-/fysiska datorskyddsupplevelsen.

Kommentar

Se till att du skapar ett nytt Recovery Services-valv för att konfigurera ASR-replikeringsinstallationen. Använd inte ett befintligt valv.

Information om Azure Site Recovery-arkitektur i klassisk arkitektur finns i den här artikeln.

Arkitekturkomponenter

Följande tabell och grafik ger en översikt över de komponenter som används för haveriberedskap för virtuella VMware-datorer/fysiska datorer till Azure.

VMware to Azure architecture

Komponent Krav Detaljer
Azure En Azure-prenumeration, Ett Azure Storage-konto för cacheminne, hanterad disk och Ett Azure-nätverk. Replikerade data från lokala virtuella datorer lagras i Azure Storage. Virtuella Azure-datorer skapas med replikerade data när du kör en redundansväxling från en lokal plats till Azure. Virtuella Azure-datorer ansluter till det virtuella Azure-nätverket när de skapas.
Replikeringsinstallation för Azure Site Recovery Det här är den grundläggande byggstenen i hela den lokala Azure Site Recovery-infrastrukturen.

Alla komponenter i installationen samordnas med replikeringsinstallationen. Den här tjänsten övervakar alla Site Recovery-aktiviteter från slutpunkt till slutpunkt, inklusive övervakning av hälsotillståndet för skyddade datorer, datareplikering, automatiska uppdateringar osv.		 Installationen är värd för olika viktiga komponenter som:

Proxyserver: Den här komponenten fungerar som en proxykanal mellan mobilitetsagenten och Site Recovery-tjänster i molnet. Det säkerställer att det inte finns någon annan Internetanslutning som krävs från produktionsarbetsbelastningar för att generera återställningspunkter.

Identifierade objekt: Den här komponenten samlar in information om vCenter och koordinater med Azure Site Recovery-hanteringstjänsten i molnet.

Återskyddsserver: Den här komponenten samordnar mellan Azure och lokala datorer under återaktivering av skydd och återställning efter fel.

Processserver: Den här komponenten används för cachelagring, komprimering av data innan den skickas till Azure.

Läs mer om replikeringsinstallation och hur du använder flera replikeringsenheter.

Recovery Service-agent: Den här komponenten används för att konfigurera/registrera med Site Recovery-tjänster och för att övervaka hälsotillståndet för alla komponenter.

Site Recovery-provider: Den här komponenten används för att underlätta återaktivering av skyddet. Den identifierar mellan en alternativ plats som återaktiveras och den ursprungliga platsen återaktiveras för en källdator.

Replikeringstjänst: Den här komponenten används för att replikera data från källplatsen till Azure.
VMware-servrar Virtuella VMware-datorer finns på lokala vSphere ESXi-servrar. Vi rekommenderar en vCenter-server för att hantera värdarna. Under Site Recovery-distributionen lägger du till VMware-servrar i Recovery Services-valvet.
Replikerade datorer Mobilitetstjänsten installeras på varje virtuell VMware-dator som du replikerar. Vi rekommenderar att du tillåter automatisk installation av mobilitetstjänsten. Du kan också installera tjänsten manuellt.

Konfigurera utgående nätverksanslutning

För att Site Recovery ska fungera som förväntat måste du ändra utgående nätverksanslutning så att din miljö kan replikeras.

Kommentar

Site Recovery har inte stöd för en autentiseringsproxy för att styra nätverksanslutningar.

Utgående anslutning för webbadresser

Om du använder en URL-baserad brandväggsproxy för att styra utgående anslutning kan du tillåta åtkomst till dessa URL:er:

URL Detaljer
portal.azure.com Navigera till Azure-portalen.
*.windows.net
*.msftauth.net
*.msauth.net
*.microsoft.com
*.live.com
*.office.com 		Logga in på din Azure-prenumeration.
*.microsoftonline.com Skapa Microsoft Entra-appar för installationen för att kommunicera med Azure Site Recovery.
management.azure.com Skapa Microsoft Entra-appar för installationen för att kommunicera med Azure Site Recovery-tjänsten.
*.services.visualstudio.com Ladda upp apploggar som används för intern övervakning.
*.vault.azure.net Hantera hemligheter i Azure Key Vault. Obs! Kontrollera att datorer som ska replikeras har åtkomst till detta.
aka.ms Tillåt åtkomst till länkar som även kallas för . Används för uppdateringar av Azure Site Recovery-installationen.
download.microsoft.com/download Tillåt nedladdningar från Microsofts nedladdning.
*.servicebus.windows.net Kommunikation mellan installationen och Azure Site Recovery-tjänsten.
*.discoverysrv.windowsazure.com Anslut till URL för Azure Site Recovery-identifieringstjänsten.
*.hypervrecoverymanager.windowsazure.com Anslut till Azure Site Recovery-url:er för mikrotjänster.
*.blob.core.windows.net Ladda upp data till Azure Storage, som används för att skapa måldiskar.
*.backup.windowsazure.com Url för skyddstjänsten – en mikrotjänst som används av Azure Site Recovery för bearbetning och skapande av replikerade diskar i Azure.
*.prod.migration.windowsazure.com För att upptäcka din lokala egendom.

Replikeringsprocessen

  1. När du aktiverar replikering för en virtuell dator påbörjas den inledande replikeringen till Azure Storage med den angivna replikeringsprincipen. Notera följande:

    • För virtuella VMware-datorer är replikeringen blocknivå, nästan kontinuerlig, med hjälp av den tjänsten Mobility agent som körs på den virtuella datorn.
    • Eventuella inställningar för replikeringsprinciper tillämpas:
      • Tröskelvärde för RPO. Den här inställningen påverkar inte replikeringen. Det hjälper till med övervakning. En händelse utlöses och du kan också skicka ett e-postmeddelande om det aktuella RPO:t överskrider den tröskelvärdesgräns som du anger.
      • Kvarhållning av återställningspunkt. Den här inställningen anger hur långt tillbaka i tiden du vill gå när ett avbrott inträffar. Maximal kvarhållning är 15 dagar.
      • Appkonsekventa ögonblicksbilder. Appkonsekvent ögonblicksbild kan tas var 1:e till 12:e timme, beroende på dina appbehov. Ögonblicksbilder är standardögonblicksbilder för Azure-blobar. Mobilitetsagenten som körs på en virtuell dator begär en VSS-ögonblicksbild i enlighet med den här inställningen och bokmärken som pekar i tid som en programkonsekvent punkt i replikeringsströmmen.

      Kommentar

      Kvarhållningsperioden för hög återställningspunkt kan påverka lagringskostnaden eftersom fler återställningspunkter kan behöva sparas.

  2. Trafiken replikeras till offentliga Slutpunkter för Azure Storage via Internet. Alternativt kan du använda Azure ExpressRoute med Microsoft-peering. Replikering av trafik via ett virtuellt privat nätverk (VPN) från en lokal plats till Azure stöds endast när du använder privata slutpunkter.

  3. Den inledande replikeringsåtgärden säkerställer att hela data på datorn vid tidpunkten för aktivering av replikering skickas till Azure. När den inledande replikeringen är klar börjar replikeringen av deltaändringar till Azure. Spårade ändringar för en dator skickas till processervern.

  4. Kommunikationen sker på följande sätt:

    • Virtuella datorer kommunicerar med den lokala installationen på port HTTPS 443 inkommande för replikeringshantering.
    • Virtuella datorer skickar replikeringsdata till installationen på port HTTPS 9443 inkommande. Den här porten kan ändras.
    • Installationen tar emot replikeringsdata, optimerar och krypterar dem och skickar dem till Azure Storage via utgående port 443.

  5. Replikeringsdataloggarna hamnar först i ett cachelagringskonto i Azure. Dessa loggar bearbetas och data lagras i en Azure Managed Disk (kallas asrseeddisk). Återställningspunkterna skapas på den här disken.

VMware to Azure data flow with ports

Omsynkroniseringsprocess

  1. Ibland kan det under den inledande replikeringen eller vid överföring av deltaändringar uppstå problem med nätverksanslutningen mellan källdatorn för att bearbeta servern eller mellan processervern till Azure. Något av dessa kan leda till fel vid dataöverföring till Azure tillfälligt.
  2. För att undvika dataintegritetsproblem och minimera kostnaderna för dataöverföring markerar Site Recovery en dator för omsynkronisering.
  3. En dator kan också markeras för omsynkronisering i situationer som följande för att upprätthålla konsekvens mellan källdatorn och data som lagras i Azure
    • Om en dator genomgår tvångsavstängning
    • Om en dator genomgår konfigurationsändringar som storleksändring av disk (ändra storleken på disken från 2 TB till 4 TB)
  4. Omsynkronisering skickar endast deltadata till Azure. Dataöverföring mellan lokal plats och Azure genom att minimeras genom databeräkning av datakontrollsummor mellan källdatorn och data som lagras i Azure.
  5. Omsynkroniseringen schemaläggs som standard att köras automatiskt utanför kontorstid. Om du inte vill vänta på standardsynkronisering utanför timmar kan du synkronisera om en virtuell dator manuellt. Det gör du genom att gå till Azure-portalen och välja den virtuella datorns >omsynkronisering.
  6. Om standardsynkroniseringen misslyckas utanför kontorstid och en manuell åtgärd krävs genereras ett fel på den specifika datorn i Azure-portalen. Du kan lösa felet och utlösa omsynkroniseringen manuellt.
  7. När omsynkroniseringen har slutförts återupptas replikeringen av deltaändringar.

Replikeringsprincip

När du aktiverar replikering av virtuella Azure-datorer skapar Site Recovery som standard en ny replikeringsprincip med standardinställningarna som sammanfattas i tabellen.

Sekretessinställning Detaljer Standardvärde
Kvarhållning av återställningspunkt Anger hur länge Site Recovery behåller återställningspunkter 1 dag
Appkonsekvent ögonblicksbildsfrekvens Hur ofta Site Recovery tar en appkonsekvent ögonblicksbild Inaktiverat

Hantera replikeringsprinciper

Du kan hantera och ändra standardinställningarna för replikeringsprinciper på följande sätt:

  • Du kan ändra inställningarna när du aktiverar replikering.
  • Du kan skapa eller redigera en ny replikeringsprincip när du försöker aktivera replikering.

Konsekvens för flera virtuella datorer

Om du vill att virtuella datorer ska replikeras tillsammans och har delade kraschkonsekventa och appkonsekventa återställningspunkter vid redundansväxling kan du samla dem i en replikeringsgrupp. Konsekvens för flera virtuella datorer påverkar arbetsbelastningens prestanda och bör endast användas för virtuella datorer 4 arbetsbelastningar som behöver konsekvens på alla datorer.

Ögonblicksbilder och återställningspunkter

Återställningspunkter skapas från ögonblicksbilder av virtuella datordiskar som tas vid en viss tidpunkt. När du redundansväxlar en virtuell dator använder du en återställningspunkt för att återställa den virtuella datorn på målplatsen.

När vi reder över vill vi vanligtvis se till att den virtuella datorn börjar utan skada eller dataförlust, och att vm-data är konsekventa för operativsystemet och för appar som körs på den virtuella datorn. Detta beror på vilken typ av ögonblicksbilder som tas.

Site Recovery tar ögonblicksbilder på följande sätt:

  1. Site Recovery tar kraschkonsekventa ögonblicksbilder av data som standard och appkonsekventa ögonblicksbilder om du anger en frekvens för dem.
  2. Återställningspunkter skapas från ögonblicksbilderna och lagras i enlighet med kvarhållningsinställningarna i replikeringsprincipen.

Konsekvens

I följande tabell beskrivs olika typer av konsekvens.

Kraschkonsekvent

Beskrivning Detaljer Rekommendation
En krasch konsekvent ögonblicksbild samlar in data som fanns på disken när ögonblicksbilden togs. Den innehåller inte något i minnet.

Den innehåller motsvarigheten till de data på disken som skulle finnas om den virtuella datorn kraschade eller strömkabeln hämtades från servern när ögonblicksbilden togs.

En kraschkonsekvent garanterar inte datakonsekvens för operativsystemet eller för appar på den virtuella datorn.		 Site Recovery skapar kraschkonsekventa återställningspunkter var femte minut som standard. Den här inställningen går inte att ändra.

 I dag kan de flesta appar återställas bra från kraschkonsekventa punkter.

Kraschkonsekventa återställningspunkter räcker vanligtvis för replikering av operativsystem och appar som DHCP-servrar och utskriftsservrar.

Appkonsekvent

Beskrivning Detaljer Rekommendation
Appkonsekventa återställningspunkter skapas från appkonsekventa ögonblicksbilder.

En appkonsekvent ögonblicksbild innehåller all information i en kraschkonsekvent ögonblicksbild, plus alla data i minnet och pågående transaktioner.		 Appkonsekventa ögonblicksbilder använder Volume Shadow Copy Service (VSS):

1) Azure Site Recovery använder metoden Kopiera endast säkerhetskopiering (VSS_BT_COPY), som inte ändrar Microsoft SQL:s säkerhetskopieringstid för transaktionslogg och sekvensnummer

2) När en ögonblicksbild initieras utför VSS en kopieringsåtgärd (COW) på volymen.

3) Innan den utför COW informerar VSS varje app på datorn om att den behöver tömma sina minnesbaserade data till disken.

4) VSS tillåter sedan säkerhetskopierings-/haveriberedskapsappen (i det här fallet Site Recovery) att läsa ögonblicksbilddata och fortsätta.		 Appkonsekventa ögonblicksbilder tas i enlighet med den frekvens du anger. Den här frekvensen bör alltid vara mindre än du har angett för att behålla återställningspunkter. Om du till exempel behåller återställningspunkter med standardinställningen 24 timmar bör du ange frekvensen på mindre än 24 timmar.

De är mer komplexa och tar längre tid att slutföra än kraschkonsekventa ögonblicksbilder.

De påverkar prestanda för appar som körs på en virtuell dator som är aktiverade för replikering.

Processen för redundans och återställning efter fel

När replikeringen har konfigurerats och du kör ett haveriberedskapstest (redundanstest) för att kontrollera att allt fungerar som förväntat kan du köra redundans och återställning efter fel som du behöver.

  1. Du kan köra redundansväxling för en enskild dator eller skapa en återställningsplan för att redundansväxla flera virtuella datorer samtidigt. Fördelen med en återställningsplan i stället för redundans för en enskild dator är:

    • Du kan modellera appberoenden genom att inkludera alla virtuella datorer i appen i en enda återställningsplan.
    • Du kan lägga till skript, Azure-runbooks och pausa för manuella åtgärder.

  2. När du har utlöst den första redundansväxlingen checkar du in den för att börja komma åt arbetsbelastningen från den virtuella Azure-datorn.

  3. När din primära lokala plats är tillgänglig igen kan du förbereda för återställning efter fel. Om du behöver återställa stora trafikvolymer konfigurerar du en ny Azure Site Recovery-replikeringsinstallation.

    • Steg 1: Skydda de virtuella Azure-datorerna igen så att de replikeras från Azure tillbaka till de lokala virtuella VMware-datorerna.
    • Steg 2: Kör en redundansväxling till den lokala platsen.
    • Steg 3: När arbetsbelastningarna har misslyckats igen kan du återaktivera replikering för de lokala virtuella datorerna.

Nästa steg

Följ den här självstudien om du vill aktivera VMware till Azure-replikering.