Haveriberedskap för PaaS-tjänster

Haveriberedskap för IaaS-tjänster (virtuella datorer) innebär vanligtvis att Azure Site Recovery replikerar hela operativsystemet och datadiskarna till en sekundär region. PaaS-tjänster har andra DR-modeller eftersom den underliggande infrastrukturen hanteras av Microsoft. För PaaS konfigureras DR vanligtvis på dataskiktet — data replikeras till en sekundär region medan själva plattformen startas automatiskt.

Azure SQL Database tillhandahåller inbyggd hög tillgänglighet på zonnivå inom en enda region. För DR mellan regioner erbjuder tjänsten två viktiga funktioner: active geo-replication (läsbara sekundära databaser i upp till fyra andra regioner) och auto-failover groups (automatisk växling med en enda lyssnar-slutpunkt). Dessa konfigureras på databas- eller servernivå utan att Azure Site Recovery behövs.

Auto-failover groups lägger till automatisering och en enda anslutningsslutpunkt ovanpå geo-replikering. Du konfigurerar en grupp på den primära servern, lägger till den sekundära servern och definierar en nådatidsperiod — den tid Azure väntar på att den primära servern ska återhämta sig innan en automatisk växling utlöses. Program ansluter till lyssnar-slutpunkten (t.ex. mygroup.database.windows.net) och omdirigeras automatiskt efter växlingen utan att anslutningssträngarna behöver ändras.

Geo-replikering i Azure SQL Database är asynkron — transaktioner bekräftas på den primära servern och replikeras sedan till den sekundära. Det innebär en liten replikeringsfördröjning, vanligtvis mindre än 5 sekunder under normala förhållanden. RPO för SQL geo-replikering är därför cirka 5 sekunder i de flesta scenarier, vilket gör den lämplig för arbetsbelastningar i nivå 1 och 2 som kräver mycket liten dataförlust.

Alla nivåer i Azure SQL Database omfattar automatiserade säkerhetskopior: fullständiga säkerhetskopior varje vecka, differentiella säkerhetskopior var tolfte timme och säkerhetskopior av transaktionsloggen var 5–12:e minut. Detta möjliggör Point-in-Time Restore (PITR) — att återställa databasen till valfri sekund inom kvarhållningsperioden (7–35 dagar för Standard/General Purpose, upp till 35 dagar för Business Critical). PITR är användbart för återställning efter oavsiktlig dataradering eller datakorruption.

Azure Cosmos DB med skrivningar i flera regioner ger nästan noll RPO för globala program. Alla konfigurerade regioner kan ta emot skrivåtgärder samtidigt, och Cosmos DB synkroniserar data automatiskt med sitt egenutvecklade replikeringsprotokoll. Om en region slutar fungera dirigeras trafiken automatiskt till de återstående fungerande regionerna utan att någon manuell växling krävs — vilket ger en RTO och RPO nära noll.

Azure App Service är till sin natur tillståndslös (programkoden distribueras från källkontroll eller en ZIP-fil). För DR ligger fokus på dataskiktet (databas och blob-lagring). App Service kan snabbt distribueras på nytt till en sekundär region via en CI/CD-pipeline. Du bör dock säkerställa att din anpassade domän, dina TLS-certifikat och dina appinställningar replikeras eller skriptas så att de snabbt kan återskapas i den sekundära regionen.

Azure Blob Storage med Geo-Redundant Storage (GRS) replikerar automatiskt data till en sekundär region flera hundra kilometer bort. Data replikeras asynkront (RPO vanligtvis under 15 minuter). Read-Access GRS (RA-GRS) gör det möjligt att läsa från den sekundära slutpunkten även innan en växling har utlösts, vilket är användbart för analys- och rapporteringsarbetsbelastningar när den primära regionen ligger nere.

Azure Functions är tillståndslösa som standard, vilket gör dem enkla att distribuera på nytt. För DR distribuerar du samma funktionsapp till en sekundär region och använder Traffic Manager för att dirigera HTTP-triggers mellan regionerna. För icke-HTTP-triggers (Service Bus och Event Grid) konfigurerar du meddelandekällan så att den skickar till båda regionerna, eller låter den sekundära regionen läsa från samma källa. Tillståndet för funktioner i Durable Functions lagras i Azure Storage — säkerställ att lagringen använder GRS.

Använd aktiv geo-replikering när Ni behöver detaljerad kontroll — till exempel för att dirigera lästrafik till en sekundär instans för bättre prestanda eller hantera flera sekundära instanser i olika regioner oberoende av varandra. Använd grupper för automatisk redundansväxling när Ni vill ha enkelhet: en enda lyssnarändpunkt, automatisk redundansväxling enligt en timer och inbyggd orkestrering av processen utan manuella åtgärder.

DR med PaaS är ofta billigare än DR baserad på virtuella datorer av flera skäl. Geo-replikering i SQL Database debiteras endast för den sekundära instansens lagring och beräkning; Ni betalar inte för en fullständig licens för operativsystemet i en virtuell dator. Azure Cosmos DB debiteras utifrån de allokerade RU:erna i varje region. Azure Storage GRS innebär ungefär dubbla lagringskostnaden. I motsats till detta kräver virtuella datorer som replikeras med ASR fullständiga kostnader för beräkning, lagring och licenser i den sekundära regionen.

I den här lektionen har Ni lärt Er att: PaaS DR fokuserar på datalagret i stället för replikering av virtuella datorer; Azure SQL-grupper för automatisk redundansväxling tillhandahåller en enda lyssnarändpunkt med automatisk redundansväxling; och skrivningar i flera regioner i Cosmos DB ger nästan noll i RTO och RPO för globala program. Nästa avsnitt handlar om Azure-ramverk för efterlevnad och modellen för delat ansvar.