Test og gennemførelse af failover

En katastrofegendannelsesplan, der aldrig er blevet testet, er kun en hypotese. Testfailover giver dig mulighed for at kontrollere, at dine VM'er starter korrekt, at applikationer starter, og at netværksforbindelsen fungerer i målområdet — uden at forstyrre kildemiljøet eller afbryde den igangværende replikering. Mange organisationer opdager først mangler i deres DR-planer, når en faktisk katastrofe indtræffer, og det er netop dér, en defekt plan forårsager størst skade. Regelmæssige testfailovers er et compliancekrav i de fleste lovgivningsmæssige rammeværk.

ASR understøtter tre typer failoverhandlinger. Testfailover opretter kopier af de failoverede VM'er i et isoleret netværk (du angiver mål-VNet'et) uden at påvirke replikeringen eller kildemiljøet. Planlagt failover bruges til planlagte migreringer eller vedligeholdelse — først synkroniseres eventuelle resterende ændringer, hvorefter kilden lukkes ned, før der failoveres. Uplanlagt failover (bruges under en reel katastrofe) failoverer straks fra det seneste gendannelsespunkt uden at vente på en afsluttende synkronisering.

Sådan kører du en testfailover i portalen: vælg det beskyttede element, klik på Test Failover, vælg et gendannelsespunkt (seneste crash-konsistente, seneste applikationskonsistente eller et bestemt tidspunkt), og vælg et virtuelt målnetværk (typisk et dedikeret, isoleret test-VNet). ASR starter VM'en i målområdet ved hjælp af replika-diskene. Test-VM'en vises sammen med replikaen, men er helt uafhængig — produktionen påvirkes ikke. Efter testen skal du klikke på Cleanup test failover for at slette test-VM'erne.

Under failover vælger du et gendannelsespunkt fra ASR's opbevaringsvindue. Mulighederne er: Latest (laveste RPO) — det mest aktuelle crash-konsistente gendannelsespunkt, som minimerer datatab. Latest processed — det senest behandlede punkt (kan være nogle minutter bagefter). Latest app-consistent — det seneste applikationskonsistente gendannelsespunkt, som kan være ældre, men garanterer ren applikationsgendannelse. Custom — et bestemt ældre gendannelsespunkt, hvis du vil gendanne til en kendt god tilstand før en hændelse.

En gendannelsesplan grupperer flere beskyttede VM'er og definerer rækkefølgen og tidspunktet for deres failover. Du kan angive, hvilke VM'er der skal starte først (f.eks. databaseservere før applikationsservere), tilføje manuelle godkendelsespunkter for at sætte failover på pause til manuel validering og indsætte Azure Automation-runbooks til at køre scripts før og efter failover (f.eks. opdatere DNS-poster, konfigurere load balancere eller sende meddelelser). Gendannelsesplaner kan testes separat med testfailover.

En testfailover giver mulighed for at måle din faktiske RTO (Recovery Time Objective). Start et stopur, når du igangsætter failover, og stop det, når applikationen fungerer fuldt ud og er tilgængelig for brugerne. En typisk Azure-til-Azure-failover for én VM gennemføres på 15–30 minutter, men applikationer i flere lag med afhængigheder kan tage længere tid. Dokumentér alle trin, der tager uventet lang tid (f.eks. DNS-propagering og opvarmning af applikationen), og afhjælp dem før den næste test.

Efter en planlagt failover (f.eks. ved migrering til et nyt område) kører du Commit for at afslutte failoveren. Commit stopper replikeringen tilbage fra kilden og markerer mål-VM'erne som de nye primære VM'er. Når den er gennemført, kan du aktivere re-protection for at vende replikeringens retning, så det oprindelige kildeområde bliver det nye DR-mål. Det giver dig mulighed for at failbacke til det oprindelige område, efter at hændelsen er løst.

Failback er processen med at føre arbejdsbelastninger tilbage til det oprindelige område efter en katastrofe eller planlagt migrering. Trinnene er: beskyt de failoverede VM'er igen (vend replikeringen, så der replikeres fra den nye primære placering tilbage til det oprindelige område), vent på, at den indledende synkronisering er gennemført, og udfør derefter en planlagt failover tilbage til det oprindelige område. Failback kræver, at den oprindelige kildeinfrastruktur stadig er intakt — hvis den blev ødelagt, skal du muligvis genopbygge landingszonen, før du kan failbacke.

Efter en testfailover skal du udføre Cleanup test failover i portalen for at slette test-VM'erne og deres tilknyttede diske. Uden oprydning fortsætter test-VM'erne med at køre og påføre beregningsomkostninger. Oprydningstrinnet nulstiller også testfailoverstatussen for det beskyttede element, så du kan køre en ny test senere. Automatiseret oprydning (f.eks. ved at planlægge den til én time efter testens start via en Automation-runbook) forhindrer, at glemte test-VM'er kører i dagevis.

Hver DR-test bør resultere i en rapport om DR-øvelsen, der indeholder: datoen og det testede scenarie, de anvendte gendannelsespunkter, den opnåede RTO og RPO, de fundne problemer og de gennemførte afhjælpningstiltag. Denne dokumentation opfylder revisorkravene i rammeværk som ISO 27001 og SOC 2, der kræver regelmæssig DR-test. Opbevar rapporterne om DR-øvelser på et sikkert sted, som både IT- og forretningskontinuitetsteams har adgang til.

Prisen for Azure Site Recovery beregnes pr. beskyttet instans pr. måned — gebyret dækker både replikeringstjenesten og orkestreringen. Du opkræves også betaling for den lagerplads, der bruges af administrerede replikadiske i målområdet, samt cachelagerkontoen under replikeringen. Udgående dataoverførsel mellem Azure-områder for replikerings trafik opkræves efter de normale satser for udgående trafik (i modsætning til Azure Backup, hvor udgående trafik mellem parrede områder er gratis). Ved replikering fra lokalt miljø til Azure kan Windows Server-licenser til Azure-VM'er bruge Azure Hybrid Benefit til at reducere omkostningerne.

I denne lektion har du lært, at testfailover validerer din DR-plan i et isoleret netværk uden at påvirke produktionen, at gendannelsesplaner fastlægger rækkefølgen for failover af flere VM'er med manuelle godkendelsespunkter og trin i automatiserings-runbooks, og at failback fører arbejdsbelastninger tilbage til det oprindelige område ved at vende replikeringens retning efter en katastrofe. Nu ser vi på Azure CDN, som gør global indholdslevering hurtigere.