Failover testen en uitvoeren

Een plan voor herstel na noodgevallen dat nooit is getest, is slechts een hypothese. Met een testfailover kun je controleren of je VM's correct opstarten, toepassingen starten en netwerkverbindingen in de doelregio werken — zonder de bronomgeving te verstoren of de lopende replicatie te onderbreken. Veel organisaties ontdekken pas wanneer zich een echte ramp voordoet dat hun plannen voor herstel na noodgevallen tekortkomingen bevatten. Juist dan veroorzaakt een gebrekkig plan de grootste schade. Regelmatige testfailovers zijn voor de meeste regelgevingskaders een nalevingsvereiste.

ASR ondersteunt drie typen failoveracties. Met testfailover maak je kopieën van de overgeschakelde VM's in een geïsoleerd netwerk, waarbij je het doel-VNet opgeeft, zonder de replicatie of bronomgeving te beïnvloeden. Geplande failover wordt gebruikt voor geplande migraties of onderhoud — eerst worden resterende wijzigingen gesynchroniseerd en daarna wordt de bron uitgeschakeld voordat de failover plaatsvindt. Bij een ongeplande failover, die tijdens een echte ramp wordt gebruikt, vindt de failover onmiddellijk plaats vanaf het meest recente herstelpunt, zonder op een laatste synchronisatie te wachten.

Voer in de portal een testfailover uit door het beveiligde item te selecteren, op Testfailover te klikken, een herstelpunt te kiezen (het meest recente crashconsistente herstelpunt, het meest recente applicatieconsistente herstelpunt of een specifiek tijdstip) en een doelvirtueel netwerk te selecteren, meestal een speciaal geïsoleerd test-VNet. ASR start de VM in de doelregio met de replicaschijven. De test-VM verschijnt naast de replica, maar is volledig onafhankelijk — de productieomgeving blijft onaangetast. Klik na het testen op Testfailover opschonen om de test-VM's te verwijderen.

Tijdens een failover selecteer je een herstelpunt uit het bewaartermijnvenster van ASR. De opties zijn: Meest recente (laagste RPO) — het meest actuele crashconsistente herstelpunt, waardoor gegevensverlies wordt beperkt. Meest recent verwerkt — het meest recent verwerkte punt, dat enkele minuten kan achterlopen. Meest recente applicatieconsistente — het meest recente applicatieconsistente herstelpunt. Dit kan ouder zijn, maar garandeert schoon herstel van de toepassing. Aangepast — een specifiek ouder herstelpunt om te herstellen naar een bekende goede toestand vóór een incident.

Een herstelplan groepeert meerdere beveiligde VM's en bepaalt de volgorde en timing van hun failover. Je kunt opgeven welke VM's als eerste opstarten, bijvoorbeeld databaseservers vóór toepassingsservers, handmatige goedkeuringspoorten toevoegen om de failover te pauzeren voor menselijke controle en Azure Automation-runbooks invoegen om scripts vóór en na de failover uit te voeren, zoals het bijwerken van DNS-records, het configureren van load balancers of het verzenden van meldingen. Herstelplannen kunnen onafhankelijk worden getest met een testfailover.

Een testfailover biedt de mogelijkheid om je daadwerkelijke RTO (Recovery Time Objective) te meten. Start een stopwatch wanneer je de failover initieert en stop deze wanneer de toepassing volledig functioneel en toegankelijk is voor gebruikers. Een Azure-naar-Azure-failover voor één VM is doorgaans binnen 15–30 minuten voltooid, maar toepassingen met meerdere lagen en afhankelijkheden kunnen langer duren. Leg alle stappen vast die onverwacht veel tijd kosten, zoals DNS-propagatie of het opwarmen van de toepassing, en pak deze aan vóór de volgende test.

Na een geplande failover, bijvoorbeeld bij een migratie naar een nieuwe regio, voer je Commit uit om de failover definitief te maken. Met Commit stop je de replicatie vanaf de bron en markeer je de doel-VM's als de nieuwe primaire VM's. Nadat je de failover hebt vastgelegd, kun je herbeveiliging inschakelen om de replicatierichting om te keren, zodat de oorspronkelijke bronregio de nieuwe DR-doelregio wordt. Hierdoor kun je na het oplossen van het incident terugschakelen naar de oorspronkelijke regio.

Terugschakelen is het proces waarbij werklasten na een ramp of geplande migratie naar de oorspronkelijke regio worden teruggebracht. De stappen zijn: de overgeschakelde VM's opnieuw beveiligen door de replicatie om te keren, zodat er vanaf de nieuwe primaire regio naar de oorspronkelijke regio wordt gerepliceerd; wachten tot de eerste synchronisatie is voltooid; en vervolgens een geplande failover terug naar de oorspronkelijke regio uitvoeren. Voor terugschakelen moet de oorspronkelijke broninfrastructuur nog intact zijn. Als deze is vernietigd, moet je mogelijk de landingszone opnieuw opbouwen voordat je kunt terugschakelen.

Na een testfailover moet je in de portal Testfailover opschonen uitvoeren om de test-VM's en de bijbehorende schijven te verwijderen. Zonder opschoning blijven de test-VM's actief en lopen de rekenkosten door. Met deze stap wordt ook de testfailoverstatus van het beveiligde item opnieuw ingesteld, zodat je later opnieuw een test kunt uitvoeren. Door het opschonen te automatiseren, bijvoorbeeld door het via een Automation-runbook een uur na de start van de test te plannen, voorkom je dat vergeten test-VM's dagenlang actief blijven.

Elke DR-test moet een rapport van de DR-oefening opleveren met daarin: de geteste datum en het scenario, de gebruikte herstelpunten, de behaalde RTO en RPO, ontdekte problemen en uitgevoerde herstelacties. Deze documentatie voldoet aan de eisen van auditors voor kaders zoals ISO 27001 en SOC 2, waarin regelmatige DR-tests verplicht zijn. Bewaar rapporten van oefeningen op een veilige locatie die toegankelijk is voor zowel IT-teams als teams voor bedrijfscontinuïteit.

De prijs van Azure Site Recovery wordt per beveiligd exemplaar per maand berekend. De kosten omvatten zowel de replicatieservice als de orkestratie. Daarnaast betaal je voor de opslag die wordt gebruikt door beheerde replicaschijven in de doelregio en door het cacheopslagaccount tijdens de replicatie. Uitgaande gegevensoverdracht tussen Azure-regio's voor replicatieverkeer wordt tegen de normale tarieven voor uitgaand verkeer in rekening gebracht, anders dan bij Azure Backup, waarbij uitgaand verkeer tussen gekoppelde regio's gratis is. Bij replicatie van on-premises naar Azure kunnen Windows Server-licenties voor Azure-VM's gebruikmaken van Azure Hybrid Benefit om de kosten te verlagen.

In deze les heb je geleerd dat een testfailover je DR-plan valideert in een geïsoleerd netwerk zonder gevolgen voor de productieomgeving, dat herstelplannen een failover van meerdere VM's ordenen met handmatige goedkeuringspoorten en stappen in Automation-runbooks en dat terugschakelen werklasten na een ramp terugbrengt naar de oorspronkelijke regio door de replicatierichting om te keren. Hierna bekijken we Azure CDN voor het versnellen van wereldwijde contentlevering.