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.
| 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
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.
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.
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.
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.
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
- 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.
- 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
- 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.
- För att undvika dataintegritetsproblem och minimera kostnaderna för dataöverföring markerar Site Recovery en dator för omsynkronisering.
- 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)
- 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.
- 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.
- 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.
- 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:
- Site Recovery tar kraschkonsekventa ögonblicksbilder av data som standard och appkonsekventa ögonblicksbilder om du anger en frekvens för dem.
- Å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.