Replikering med Azure Site Recovery

Azure Site Recovery (ASR) er en tjeneste til katastrofegendannelse, der replikerer arbejdsbelastninger fra en primær placering til en sekundær placering, så du kan udføre failover, hvis den primære placering bliver utilgængelig. I modsætning til Azure Backup, som opretter gendannelsespunkter på bestemte tidspunkter, vedligeholder ASR en løbende opdateret replika af dine VM'er, så du kan udføre failover med minimalt datatab. ASR understøtter replikering fra Azure til Azure, fra VMware eller Hyper-V i lokale miljøer til Azure samt fra fysiske servere til Azure.

Ved replikering fra Azure til Azure bruger ASR Mobility Service (installeres automatisk som en VM-udvidelse) til at registrere skrive-I/O fra kildens VM-diske. De registrerede data overføres via Azures backbone til en lagerkonto til cachelagring i målområdet og skrives derefter til administrerede replikadiske. En Recovery Services-hvælving i målområdet koordinerer replikeringen. Kilde-VM'en fortsætter med at køre normalt under replikeringen — skrivninger har ingen ydelsespåvirkning, så længe de ligger under replikeringens båndbredde.

Hvis du vil aktivere replikering, skal du gå til kilde-VM'en i portalen, vælge Disaster Recovery, vælge målområdet og konfigurere målressourcegruppen, det virtuelle netværk og lagerkontoen til cachelagring. ASR opretter målressourcerne og starter fasen med indledende replikering — hvor hele diskindholdet kopieres til målområdet. Når den indledende synkronisering er fuldført, går ASR over i tilstanden delta-replikering, hvor kun ændrede blokke sendes løbende.

ASR-dashboardet i Recovery Services-hvælvingen viser replikeringstilstanden for hver beskyttet VM. Mulige tilstande omfatter sund, advarsel og kritisk. Målingen opnået RPO (Recovery Point Objective) viser, hvor langt replikaen er bagefter kilden — ved replikering fra Azure til Azure opnår ASR typisk en RPO på under 1 minut under normale forhold. Du kan også se forbruget af replikeringens båndbredde og eventuelle fejltilstande.

En replikeringspolitik definerer frekvensen for nedbrudskonsistente gendannelsespunkter (hvert 5. minut som standard) og frekvensen for applikationskonsistente gendannelsespunkter (hver 60. minut som standard). Nedbrudskonsistente gendannelsespunkter tages uden at sætte applikationen i en konsistent tilstand; applikationskonsistente gendannelsespunkter bruger VSS/scripts for at sikre, at applikationen kan gendannes korrekt. Politikken angiver også, hvor længe gendannelsespunkter opbevares — fra 0 til 72 timer for nedbrudskonsistente og fra 0 til 48 timer for applikationskonsistente.

Under opsætningen af replikeringen opretter eller tilknytter ASR ressourcer i målområdet: en målressourcegruppe, et virtuelt målnetværk, en lagerkonto til cachelagring og administrerede replikadiske. Du kan tilpasse måltilknytningen for netværket, så VM'erne ved failover placeres i bestemte undernet, tildeles statiske private IP-adresser og får konfigurerede VM-størrelser (som kan afvige fra kildens størrelse — nyttigt til tilpasning af størrelsen under katastrofegendannelse). Disse indstillinger gemmes i konfigurationen Compute and Network for det beskyttede element.

For applikationer, der strækker sig over flere VM'er (f.eks. en webserver og en databaseserver), kan du gruppere dem i en konsistensgruppe med flere VM'er. ASR koordinerer derefter nedbrudskonsistente og applikationskonsistente gendannelsespunkter på tværs af alle VM'er i gruppen samtidigt. Det sikrer, at alle VM'er gendannes til samme tidspunkt, når du udfører failover — og forhindrer datainkonsistens mellem applikationslaget og databaselaget, som ellers ville medføre applikationsfejl efter failover.

Netværksmapping angiver, hvilket virtuelt målnetværk hvert kilde-VNet mappes til, når VM'er failoveres. Hvis din kilde-VM er placeret i et VNet med navnet prod-vnet i East US, konfigurerer du en netværksmapping, så VM'en ved failover placeres i dr-vnet i West US. Uden en netværksmapping placeres failoverede VM'er i det første tilgængelige VNet, hvilket kan give forbindelsesproblemer, hvis VNet-topologien er anderledes end i kildeområdet.

ASR-replikering bruger Azure-netværket i Azure-til-Azure-scenarier — du betaler ikke for udgående båndbredde mellem parrede Azure-områder for replikerings trafik. Deltareplikeringshastigheden må dog ikke overstige den tilgængelige uploadbåndbredde for kilde-VM'ens lager. Ved arbejdsbelastninger med mange skrivninger (f.eks. store SQL Server-databaser med meget skrivetrafik) skal du bruge værktøjet ASR Deployment Planner til at estimere den nødvendige båndbredde og kontrollere, at dit miljø er kompatibelt, før du aktiverer replikering.

ASR understøtter replikering af både administrerede og ikke-administrerede diske (blob-baserede diske), men replikering af administrerede diske anbefales kraftigt, fordi det eliminerer administration af lagerkonti og giver bedre ydeevne. Når du replikerer VM'er med administrerede diske, opretter ASR tilsvarende administrerede replikadiske i målområdet. Du kan også udelukke bestemte datadiske fra replikeringen (f.eks. midlertidige diske eller scratch-diske) for at reducere replikeringsbåndbredde og omkostninger.

ASR og Azure Backup supplerer hinanden; de er ikke alternativer. Azure Backup beskytter mod datakorruption, utilsigtet sletning og ransomware — du gendanner til en kendt god tilstand fra dage eller uger tidligere. ASR beskytter mod regionale udfald — du failoverer til en replika, der er sekunder til minutter bagefter kilden. En produktionsarbejdsbelastning har typisk brug for begge: Backup til databeskyttelse og ASR til katastrofegendannelse og forretningskontinuitet.

I denne lektion har du lært, at Azure Site Recovery leverer kontinuerlig deltareplikering af VM'er til et målområde for at muliggøre katastrofegendannelse med næsten nul RPO, at replikeringspolitikker styrer hyppigheden af crash-konsistente og applikationskonsistente gendannelsespunkter, og at netværksmapping sikrer, at failoverede VM'er placeres i det korrekte mål-VNet. Nu ser vi på, hvordan du sikkert tester og udfører failover med ASR.