DR voor PaaS-services

Disaster recovery voor IaaS-services (VM's) omvat doorgaans Azure Site Recovery om het volledige besturingssysteem en de gegevensschijven naar een secundaire regio te repliceren. PaaS-services hebben andere DR-modellen, omdat de onderliggende infrastructuur door Microsoft wordt beheerd. Bij PaaS wordt DR meestal op de gegevenslaag geconfigureerd: de gegevens worden naar een secundaire regio gerepliceerd, terwijl het platform zelf automatisch wordt gestart.

Azure SQL Database biedt ingebouwde hoge beschikbaarheid op zoneniveau binnen één regio. Voor DR tussen regio's biedt het twee belangrijke mogelijkheden: actieve geo-replicatie (leesbare secundaire databases in maximaal vier andere regio's) en automatische failovergroepen (geautomatiseerde failover met één listener-endpoint). Deze worden op database- of serverniveau geconfigureerd, zonder dat Azure Site Recovery nodig is.

Automatische failovergroepen voegen automatisering en één verbindingseindpunt toe boven op geo-replicatie. Je configureert een groep op de primaire server, voegt de secundaire server toe en definieert een respijtperiode — de tijd die Azure wacht tot de primaire server is hersteld voordat een automatische failover wordt gestart. Toepassingen maken verbinding met het listener-endpoint (bijvoorbeeld mygroup.database.windows.net) en worden na een failover automatisch omgeleid zonder dat verbindingsreeksen moeten worden gewijzigd.

Geo-replicatie van Azure SQL Database is asynchroon: transacties worden op de primaire database vastgelegd en daarna naar de secundaire database gerepliceerd. Dit betekent dat er een kleine replicatievertraging is, onder normale omstandigheden meestal minder dan 5 seconden. De RPO voor SQL-geo-replicatie is daarom in de meeste scenario's ongeveer 5 seconden, waardoor deze geschikt is voor Tier 1- en Tier 2-werklasten die zeer weinig gegevensverlies vereisen.

Alle Azure SQL Database-lagen bevatten automatische back-ups: wekelijks volledige back-ups, elke 12 uur differentiële back-ups en elke 5-12 minuten back-ups van transactielogboeken. Hiermee wordt Point-in-Time Restore (PITR) mogelijk: de database herstellen naar elke seconde binnen de bewaarperiode (7-35 dagen voor Standard/General Purpose, maximaal 35 dagen voor Business Critical). PITR is nuttig voor herstel na het per ongeluk verwijderen of beschadigen van gegevens.

Azure Cosmos DB met schrijven naar meerdere regio's biedt voor wereldwijde toepassingen een RPO die vrijwel nul is. Alle geconfigureerde regio's kunnen tegelijkertijd schrijfbewerkingen accepteren en Cosmos DB synchroniseert de gegevens automatisch met behulp van het eigen replicatieprotocol. Als een regio uitvalt, wordt het verkeer automatisch naar de resterende gezonde regio's geleid zonder dat handmatige failover nodig is — waardoor de RTO en RPO bijna nul worden.

Azure App Service zelf is stateless (toepassingscode wordt vanuit bronbeheer of een ZIP-bestand geïmplementeerd). Bij DR ligt de focus op de gegevenslaag (database en blobopslag). App Service kan snel opnieuw in een secundaire regio worden geïmplementeerd via een CI/CD-pijplijn. Zorg er echter voor dat je aangepaste domein, TLS-certificaten en app-instellingen worden gerepliceerd of met scripts worden vastgelegd, zodat ze snel opnieuw in de secundaire regio kunnen worden gemaakt.

Azure Blob Storage met Geo-Redundant Storage (GRS) repliceert gegevens automatisch naar een secundaire regio op honderden kilometers afstand. Gegevens worden asynchroon gerepliceerd (RPO doorgaans minder dan 15 minuten). Met Read-Access GRS (RA-GRS) kun je al vóór het starten van een failover gegevens uit het secundaire eindpunt lezen. Dit is nuttig voor analyse- en rapportagewerklasten tijdens een storing in de primaire regio.

Azure Functions zijn van nature stateless, waardoor ze eenvoudig opnieuw kunnen worden geïmplementeerd. Implementeer voor DR dezelfde functie-app in een secundaire regio en gebruik Traffic Manager om HTTP-triggers tussen regio's te routeren. Configureer voor niet-HTTP-triggers (Service Bus, Event Grid) de berichtbron zo dat deze naar beide regio's vertakt, of laat de secundaire regio dezelfde bron pollen. De status van functies in Durable Functions wordt opgeslagen in Azure Storage — zorg ervoor dat die opslag GRS gebruikt.

Gebruik actieve geografische replicatie wanneer je gedetailleerde controle nodig hebt — bijvoorbeeld om leesverkeer voor betere prestaties naar een secundaire replica te sturen of meerdere secundaire replica's in verschillende regio's onafhankelijk te beheren. Gebruik groepen voor automatisch failover wanneer je eenvoud wilt: één listener-eindpunt, automatisch failover op basis van een timer en ingebouwde orkestratie van het failoverproces zonder handmatige tussenkomst.

PaaS-noodherstel is om verschillende redenen vaak goedkoper dan VM-gebaseerd noodherstel. Voor geografische replicatie van SQL Database betaal je alleen voor de opslag en rekenkracht van de secundaire replica; je betaalt niet voor een volledige VM-besturingssysteemlicentie. Voor Azure Cosmos DB betaal je voor de ingerichte RU's in elke regio. Azure Storage GRS voegt ongeveer tweemaal de opslagkosten toe. Voor VM's die met ASR worden gerepliceerd, moet je daarentegen in de secundaire regio de volledige kosten voor rekenkracht, opslag en licenties betalen.

In deze les heb je geleerd dat PaaS-noodherstel zich richt op de gegevenslaag in plaats van op VM-replicatie; dat Azure SQL-groepen voor automatisch failover één listener-eindpunt met geautomatiseerd failover bieden; en dat schrijven naar meerdere regio's met Cosmos DB voor globale toepassingen een RTO en RPO van bijna nul mogelijk maakt. Hierna bekijken we nalevingskaders van Azure en het model van gedeelde verantwoordelijkheid.