Gjenopprettingsplaner og automatisk failover

En Recovery Plan i Azure Site Recovery er en strukturert og ordnet sekvens av trinn som orkestrerer failover av flere virtuelle maskiner samlet. I stedet for å gjennomføre failover for hver virtuelle maskin separat, grupperer en gjenopprettingsplan dem i grupper som gjennomfører failover i rekkefølge – slik at infrastrukturen (database, mellomvare og web) starter i riktig rekkefølge, akkurat som ved den opprinnelige distribusjonen.

For å opprette en gjenopprettingsplan velger De kildestedet (primærregionen) og målstedet (den sekundære regionen), og legger deretter til de virtuelle maskinene som skal inkluderes. Veiviseren for planen oppretter automatisk en standardgruppe, men De kan legge til flere grupper for å styre rekkefølgen for failover. Virtuelle maskiner i samme gruppe gjennomfører failover samtidig, mens gruppene kjøres i nummerert rekkefølge.

For et typisk program med tre nivåer bør gjenopprettingsplanen ha tre grupper:

• Gruppe 1 – virtuelle maskiner på databasenivå (må starte først)
• Gruppe 2 – virtuelle maskiner på program- og mellomvarenivå
• Gruppe 3 – virtuelle maskiner for webfrontenden (starter sist)

Hver gruppe venter til den forrige gruppen har fullført failover, før den starter. Dette gjenspeiler riktig oppstartsrekkefølge og hindrer at virtuelle maskiner på webnivå starter før databasen er klar til å godta tilkoblinger.

Gjenopprettingsplaner støtter førhandlinger og etterhandlinger ved hver gruppeovergang. Disse kan være:

• Manuelle handlinger – sett failover på pause og vent på at en person bekrefter (for eksempel «Bekreft at databasen er klar»)
• Azure Automation-runbooker – kjør et skript automatisk (for eksempel oppdater DNS-poster eller deaktiver vedlikeholdsmodus)

Ved å bruke Automation-runbooker kan De gjennomføre fullstendig automatisert failover uten menneskelig inngripen for arbeidsbelastninger på nivå 1.

Azure Site Recovery støtter to typer failover:

• Planlagt failover – startes før en kjent hendelse (for eksempel vedlikehold av et datasenter). Den primære virtuelle maskinen slås av på en kontrollert måte, dataene synkroniseres, og deretter starter den sekundære virtuelle maskinen. Ingen data går tapt.
• Uplanlagt failover – utløses under en faktisk katastrofe. Den primære virtuelle maskinen kan være utilgjengelig, så ASR bruker det nyeste replikeringskontrollpunktet. Noe datatap er mulig, avhengig av RPO.

Etter en failover er de gjenopprettede virtuelle maskinene i den sekundære regionen i tilstanden pending commit. De må bekrefte failover-en for å bekrefte at det sekundære stedet nå er det aktive stedet, og at De ikke ønsker å rulle tilbake. Når den er bekreftet, kan De konfigurere reversert replikering for å beskytte det sekundære stedet og til slutt utføre failback til primærregionen når den er gjenopprettet.

Etter at en failover er bekreftet, replikeres ikke de replikerte elementene i den opprinnelige primærregionen lenger aktivt. For å gjenopprette beskyttelsen må De rebeskytte elementene – dette snur replikasjonsretningen, slik at den nye primærregionen (tidligere den sekundære) replikerer til den opprinnelige primærregionen. Reb eskyttelsen tar tid og bør startes så snart den opprinnelige primærregionen er tilgjengelig igjen.

Hvert trinn i en gjenopprettingsplan bidrar til den totale RTO-en. Vanlige tidstyver er:

• Oppstartstid for VM-er (2–5 minutter per VM)
• Oppvarmingstid for applikasjoner (initialisering av tilkoblingspool for databasen, oppvarming av hurtigbuffer)
• DNS-propagering etter IP-endringer
• Ventetid på manuelle godkjenningspunkter

Mål hvert trinn under testfailover, og summer tidene for å beregne den faktiske RTO-en sammenlignet med målet.

Etter en failover har VM-ene i den sekundære regionen andre IP-adresser. For applikasjoner som eksponerer et offentlig DNS-navn, må De oppdatere DNS slik at det peker til de nye IP-adressene. Bruk en Azure Automation runbook som en handling etter failover for å oppdatere Azure DNS eller helsetilstanden til Traffic Manager-endepunkter, slik at trafikken omdirigeres automatisk — og unngå dermed et manuelt trinn som kan forsinke RTO-en.

Under en failover viser visningen Azure portal Jobs i Recovery Services-hvelvet fremdriften i sanntid for hvert trinn i gjenopprettingsplanen. De kan se hvilken gruppe som kjører, hvilke VM-er som er startet, og om skript eller manuelle handlinger venter. Ved å overvåke denne visningen kan gjenopprettingsteamet gripe inn raskt hvis et trinn mislykkes.

Viktige anbefalinger for gjenopprettingsplaner:

• Hold gruppene små (5–10 VM-er) for å begrense konsekvensene hvis en gruppe mislykkes
• Bruk Automation-runbooker i stedet for manuelle handlinger når det er mulig, for å redusere RTO
• Dokumenter forventet oppstartstid for hver gruppe, slik at RTO kan beregnes
• Gjennomfør en testfailover minst hvert kvartal for å validere planen
• Gå gjennom og oppdater planen hver gang nye VM-er legges til, eller applikasjonsarkitekturen endres

I denne leksjonen lærte De at en gjenopprettingsplan orkestrerer failover i en bestemt rekkefølge for flere VM-er, med handlinger før og etter hvert gruppetrinn; uplanlagt failover bruker det siste replikeringskontrollpunktet, mens planlagt failover ikke medfører datatap; og at De etter failover må bekrefte og beskytte på nytt for å gjenopprette DR-beskyttelsen. Deretter ser vi på hvordan De kan teste DR-planer uten å påvirke produksjonen.