Dela via


Arkitektur för fysisk server till Azure-haveriberedskap – moderniserad

Den här artikeln beskriver den moderniserade arkitekturen och processerna som används när du replikerar, redundansväxlar och återställer fysiska Windows- och Linux-servrar mellan en lokal plats och Azure med hjälp av Azure Site Recovery-tjänsten .

Information om konfigurationsserverkrav i klassiska versioner finns i Fysisk server till Azure-haveriberedskapsarkitektur.

Kommentar

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

Arkitekturkomponenter

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

Skärmbild av moderniserad arkitektur.

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 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 krävs någon ytterligare Internetanslutning 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 återskydd. Den identifierar mellan en annan plats som återskyddas och den ursprungliga platsen återskyddas för en källdator.

Replikeringstjänst: Den här komponenten används för att replikera data från källplatsen till Azure.
Replikerade datorer Mobilitetstjänsten installeras på varje fysisk server 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! Se till att datorer som ska replikeras har åtkomst till detta.
aka.ms Tillåt åtkomst till aka.ms länkar. 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 Ansluta till url:en för Azure Site Recovery-identifieringstjänsten.
*.hypervrecoverymanager.windowsazure.com Ansluta 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

Replikeringsprocessen

  1. När du aktiverar replikering för ett system börjar den inledande replikeringen till Azure Storage med den angivna replikeringsprincipen. Notera följande:

    • För fysiska datorer är replikeringen blocknivå, nästan kontinuerlig, med hjälp av den tjänsten Mobility agent som körs på systemet.
    • 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 fysisk 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. Det går inte att replikera trafik via ett virtuellt privat nätverk (VPN) från en lokal plats till Azure.

  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:

    • Datorer kommunicerar med den lokala installationen på port HTTPS 443 inkommande för replikeringshantering.
    • Installationen dirigerar replikering med Azure via port HTTPS 443 utgående.
    • Datorer skickar replikeringsdata till processervern på port HTTPS 9443 inkommande. Den här porten kan ändras.
    • Processervern 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.

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

När du har konfigurerat replikering och kört ett haveriberedskapstest (redundanstest) för att kontrollera att allt fungerar som förväntat kan du köra fortsätt till redundans efter behov.

Kommentar

För fysiska servrar stöds inte återställning efter fel

  1. Du kan köra redundans för en enskild dator eller skapa en återställningsplan för att redundansväxlar flera servrar 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 servrar 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.

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 maskin måste stängas av
    • 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 ett system manuellt. Det gör du genom att gå till Azure Portal och välja den fysiska datorn >Omsynkronisera.
  6. Om standardsynkroniseringen misslyckas utanför kontorstid och en manuell åtgärd krävs genereras ett fel på den specifika datorn i Azure Portal. 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 Inaktiverad

Ögonblicksbilder och återställningspunkter

Återställningspunkter skapas från ögonblicksbilder av datorns diskar som tas vid en viss tidpunkt. När du redundansväxlar ett system använder du en återställningspunkt för att återställa den fysiska datorn som en virtuell dator 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 systemet 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å 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 prestandan för appar som körs på ett system som är aktiverat för replikering.

Nästa steg

Följ den här självstudien om du vill aktivera replikering av fysiska datorer och VMware till Azure.