Teste og gjennomføre failover

En katastrofegjenopprettingsplan som aldri er testet, er bare en hypotese. Test failover gjør det mulig å kontrollere at VM-ene starter riktig, at programmene starter, og at nettverkstilkoblingen fungerer i målregionen — uten å forstyrre kildemiljøet eller avbryte den pågående replikeringen. Mange organisasjoner oppdager først ved en faktisk katastrofe at DR-planene har mangler, og det er nettopp da en mangelfull plan gjør størst skade. Regelmessige testfailover er et krav til samsvar i de fleste regulatoriske rammeverk.

ASR støtter tre typer failover-handlinger. Test failover oppretter kopier av VM-ene som gjennomfører failover, i et isolert nettverk (De angir mål-VNet-et), uten å påvirke replikeringen eller kildemiljøet. Planned failover brukes til planlagte migreringer eller vedlikehold — først synkroniseres gjenværende endringer, og deretter slås kilden av før failover utføres. Unplanned failover (som brukes ved en faktisk katastrofe) utfører failover umiddelbart fra det nyeste gjenopprettingspunktet uten å vente på en siste synkronisering.

Slik kjører De en testfailover i portalen: Velg det beskyttede elementet, klikk på Test Failover, velg et gjenopprettingspunkt (nyeste krasjkonsistente, nyeste programkonsistente eller et bestemt tidspunkt), og velg et virtuelt målnettverk (vanligvis et dedikert, isolert test-VNet). ASR starter VM-en i målregionen ved hjelp av replikadiskene. Test-VM-en vises sammen med replikaen, men er helt uavhengig — produksjonsmiljøet påvirkes ikke. Når testen er fullført, klikker De på Cleanup test failover for å slette test-VM-ene.

Under failover velger De et gjenopprettingspunkt fra ASRs oppbevaringsvindu. Alternativene er: Latest (lowest RPO) — det nyeste krasjkonsistente gjenopprettingspunktet, som minimerer datatapet. Latest processed — det sist behandlede punktet, som kan ligge noen minutter etter. Latest app-consistent — det nyeste programkonsistente gjenopprettingspunktet, som kan være eldre, men garanterer ren gjenoppretting av programmet. Custom — et bestemt eldre gjenopprettingspunkt for gjenoppretting til en kjent, fungerende tilstand før en hendelse.

En gjenopprettingsplan grupperer flere beskyttede VM-er og definerer rekkefølgen og tidspunktet for failover. De kan angi hvilke VM-er som skal starte først, for eksempel databaseservere før applikasjonsservere, legge til manuelle godkjenningspunkter for å stanse failover mens en person kontrollerer resultatet, og sette inn Azure Automation-runbooks som kjører skript før og etter failover, for eksempel oppdatering av DNS-poster, konfigurasjon av belastningsfordelere eller sending av varsler. Gjenopprettingsplaner kan testes separat med testfailover.

En testfailover gir Dem mulighet til å måle den faktiske RTO (Recovery Time Objective). Start en stoppeklokke når De starter failover, og stopp den når programmet fungerer fullt ut og er tilgjengelig for brukerne. En typisk Azure-til-Azure-failover for én VM fullføres på 15–30 minutter, men applikasjoner med flere nivåer og avhengigheter kan ta lengre tid. Dokumenter alle trinn som tar uventet lang tid, for eksempel DNS-spredning eller oppvarming av programmet, og håndter dem før neste test.

Etter en planned failover, for eksempel ved migrering til en ny region, kjører De Commit for å sluttføre failover. Bekreftelsen stopper replikeringen fra kilden og markerer mål-VM-ene som de nye primære VM-ene. Når failover er bekreftet, kan De aktivere re-protection for å snu replikeringsretningen, slik at den opprinnelige kilderegionen blir det nye DR-målet. Dette gjør det mulig å utføre failback til den opprinnelige regionen når hendelsen er løst.

Failback er prosessen med å returnere arbeidsbelastninger til den opprinnelige regionen etter en katastrofe eller planlagt migrering. Trinnene er: Beskytt VM-ene som gjennomførte failover på nytt (snu replikeringen slik at det replikeres fra den nye primære regionen tilbake til den opprinnelige regionen), vent til den første synkroniseringen er fullført, og utfør deretter en planlagt failover tilbake til den opprinnelige regionen. Failback krever at den opprinnelige kildeinfrastrukturen fortsatt er intakt. Hvis den er ødelagt, kan det hende De må bygge landingssonen på nytt før failback kan utføres.

Etter en testfailover må De utføre Cleanup test failover i portalen for å slette test-VM-ene og de tilknyttede diskene. Uten opprydding fortsetter test-VM-ene å kjøre og påløper databehandlingskostnader. Oppryddingstrinnet tilbakestiller også testfailover-statusen for det beskyttede elementet, slik at De kan kjøre en ny test senere. Automatisert opprydding, for eksempel ved å planlegge den én time etter at testen starter via en Automation-runbook, hindrer at glemte test-VM-er kjører i flere dager.

Hver DR-test bør resultere i en DR-øvingsrapport som dokumenterer datoen og scenarioet som ble testet, hvilke gjenopprettingspunkter som ble brukt, oppnådd RTO og RPO, oppdagede problemer og gjennomførte utbedringstiltak. Denne dokumentasjonen oppfyller revisorkravene i rammeverk som ISO 27001 og SOC 2, som krever regelmessig DR-testing. Lagre øvingsrapportene på et sikkert sted som både IT- og forretningskontinuitetsteamene har tilgang til.

Prisen for Azure Site Recovery beregnes per beskyttet instans per måned — avgiften dekker både replikerings- og orkestreringstjenesten. De belastes også for lagringen som brukes av administrerte replikadisker i målregionen og hurtigbufferlagringskontoen under replikeringen. Utgående dataoverføring mellom Azure-regioner for replikerings trafikk belastes etter vanlige priser for utgående trafikk (i motsetning til Azure Backup, der utgående trafikk mellom sammenkoblede regioner er kostnadsfri). Ved replikering fra lokalt miljø til Azure kan Windows Server-lisenser for Azure-VM-er bruke Azure Hybrid Benefit for å redusere kostnadene.

I denne leksjonen har De lært at test failover validerer DR-planen i et isolert nettverk uten å påvirke produksjonsmiljøet, at gjenopprettingsplaner ordner failover for flere VM-er ved hjelp av manuelle godkjenningspunkter og trinn i automatiserte runbooks, og at failback returnerer arbeidsbelastninger til den opprinnelige regionen ved å snu replikeringsretningen etter en katastrofe. Deretter skal vi se på Azure CDN for raskere global innholdslevering.