Utforma globalt tillgängliga tjänster med Hjälp av Azure SQL Database

Gäller för:Azure SQL Database

När du skapar och distribuerar molntjänster med Azure SQL Database använder du aktiva geo-replikerings- eller redundansgrupper för att ge motståndskraft mot regionala avbrott och katastrofala fel. Med samma funktion kan du skapa globalt distribuerade program som är optimerade för lokal åtkomst till data. I den här artikeln beskrivs vanliga programmönster, inklusive fördelar och kompromisser för varje alternativ.

Kommentar

Om du använder Premium eller Affärskritisk databaser och elastiska pooler kan du göra dem motståndskraftiga mot regionala avbrott genom att konvertera dem till zonredundant distributionskonfiguration. Se Zonredundanta databaser.

Scenario 1: Använda två Azure-regioner för affärskontinuitet med minimal stilleståndstid

I det här scenariot har programmen följande egenskaper:

  • Programmet är aktivt i en Azure-region
  • Alla databassessioner kräver läs- och skrivåtkomst (RW) till data
  • Webbnivå och datanivå måste vara indelade för att minska svarstiden och trafikkostnaden
  • I grund och botten är driftstopp en högre affärsrisk för dessa program än dataförlust

I det här fallet optimeras topologin för programdistribution för hantering av regionala katastrofer när alla programkomponenter behöver redundansväxla tillsammans. Diagrammet nedan visar den här topologin. För geografisk redundans distribueras programmets resurser till region A och B. Resurserna i region B används dock inte förrän region A misslyckas. En redundansgrupp konfigureras mellan de två regionerna för att hantera databasanslutning, replikering och redundans. Webbtjänsten i båda regionerna har konfigurerats för att komma åt databasen via redundansväxling för läs-skriv-lyssnare-gruppnamn.database.windows.net <> (1). Azure Traffic Manager har konfigurerats för att använda prioritetsroutningsmetod (2).  

Kommentar

Azure Traffic Manager används endast i den här artikeln i illustrationssyfte. Du kan använda valfri belastningsutjämningslösning som stöder prioritetsroutningsmetod.

Följande diagram visar den här konfigurationen före ett avbrott:

Scenario 1. Configuration before the outage.

Efter ett avbrott i den primära regionen identifierar SQL Database att den primära databasen inte är tillgänglig och utlöser redundansväxling till den sekundära regionen baserat på parametrarna för principen för automatisk redundans (1). Beroende på ditt program-SLA kan du konfigurera en respitperiod som styr tiden mellan identifieringen av avbrottet och själva redundansväxlingen. Det är möjligt att Azure Traffic Manager initierar slutpunktens redundans innan redundansgruppen utlöser redundansväxlingen av databasen. I så fall kan webbprogrammet inte omedelbart återansluta till databasen. Men återanslutningarna lyckas automatiskt så snart databasredundansen har slutförts. När den misslyckade regionen återställs och är online igen återansluts den gamla primära automatiskt som en ny sekundär. Diagrammet nedan visar konfigurationen efter redundansväxlingen.

Kommentar

Alla transaktioner som har checkats in efter redundansväxlingen går förlorade under återanslutningen. När redundansväxlingen är klar kan programmet i region B återansluta och starta om bearbetningen av användarbegäranden. Både webbprogrammet och den primära databasen finns nu i region B och förblir samlokala.

Scenario 1. Configuration after failover

Om ett avbrott inträffar i region B pausas replikeringsprocessen mellan den primära och den sekundära databasen, men länken mellan de två förblir intakt (1). Traffic Manager upptäcker att anslutningen till region B är bruten och markerar slutpunktswebbappen 2 som Degraderad (2). Programmets prestanda påverkas inte i det här fallet, men databasen blir exponerad och därmed med högre risk för dataförlust om region A misslyckas i följd.

Kommentar

För haveriberedskap rekommenderar vi konfigurationen med programdistribution begränsad till två regioner. Det beror på att de flesta av Azures geografiska områden bara har två regioner. Den här konfigurationen skyddar inte ditt program från ett samtidigt oåterkalleligt fel i båda regionerna. I en osannolik händelse av ett sådant fel kan du återställa dina databaser i en tredje region med hjälp av geo-återställningsåtgärden. Mer information finns i Vägledning för haveriberedskap i Azure SQL Database.

När avbrotten har åtgärdats synkroniseras den sekundära databasen automatiskt med den primära databasen. Under synkroniseringen kan prestanda för den primära effekten påverkas. Den specifika effekten beror på mängden data som den nya primära datamängden har hämtat sedan redundansväxlingen.

Kommentar

När avbrotten har åtgärdats börjar Traffic Manager dirigera anslutningarna till programmet i region A som en slutpunkt med högre prioritet. Om du tänker behålla den primära i region B ett tag bör du ändra prioritetstabellen i Traffic Manager-profilen i enlighet med detta.

Följande diagram illustrerar ett avbrott i den sekundära regionen:

Scenario 1. Configuration after an outage in the secondary region.

De viktigaste fördelarna med det här designmönstret är:

  • Samma webbprogram distribueras till båda regionerna utan någon regionspecifik konfiguration och kräver inte ytterligare logik för att hantera redundans.
  • Programprestanda påverkas inte av redundans eftersom webbprogrammet och databasen alltid finns tillsammans.

Den största kompromissen är att programresurserna i region B för det mesta är underutnytttagna.

Scenario 2: Azure-regioner för affärskontinuitet med maximal databevarande

Det här alternativet passar bäst för program med följande egenskaper:

  • Dataförluster är hög affärsrisk. Databasredundansväxlingen kan bara användas som en sista utväg om driftstoppet orsakas av ett oåterkalleligt fel.
  • Programmet stöder skrivskyddade och skrivskyddade driftlägen och kan köras i skrivskyddat läge under en viss tidsperiod.

I det här mönstret växlar programmet till skrivskyddat läge när skrivskyddade anslutningar börjar få timeout-fel. Webbprogrammet distribueras till båda regionerna och innehåller en anslutning till läs-och-skriv-lyssnarens slutpunkt och en annan anslutning till den skrivskyddade lyssnarens slutpunkt (1). Traffic Manager-profilen bör använda prioritetsroutning. Slutpunktsövervakning ska aktiveras för programslutpunkten i varje region (2).

Följande diagram illustrerar den här konfigurationen före ett avbrott:

Scenario 2. Configuration before the outage.

När Traffic Manager upptäcker ett anslutningsfel till region A växlar den automatiskt användartrafik till programinstansen i region B. Med det här mönstret är det viktigt att du anger respitperioden med dataförlust till ett tillräckligt högt värde, till exempel 24 timmar. Det säkerställer att dataförlust förhindras om avbrotten minimeras inom den tiden. När webbprogrammet i region B aktiveras börjar läs- och skrivåtgärderna misslyckas. Då bör den växla till skrivskyddat läge (1). I det här läget dirigeras begäranden automatiskt till den sekundära databasen. Om avbrottet orsakas av ett oåterkalleligt fel kan det troligtvis inte åtgärdas inom respitperioden. När den upphör att gälla utlöser redundansgruppen redundansväxlingen. Därefter blir läs- och skrivlyssnaren tillgänglig och anslutningarna till den slutar misslyckas (2). Följande diagram illustrerar de två stegen i återställningsprocessen.

Kommentar

Om driftstoppet i den primära regionen minimeras inom respitperioden identifierar Traffic Manager återställningen av anslutningen i den primära regionen och växlar tillbaka användartrafiken till programinstansen i region A. Programinstansen återupptas och fungerar i läs- och skrivläge med hjälp av den primära databasen i region A enligt föregående diagram.

Scenario 2. Disaster recovery stages.

Om ett avbrott inträffar i region B identifierar Traffic Manager felet för slutpunkten web-app-2 i region B och markerar den degraderad (1). Under tiden växlar redundansgruppen den skrivskyddade lyssnaren till region A (2). Det här avbrottet påverkar inte slutanvändarupplevelsen, men den primära databasen exponeras under driftstoppet. Följande diagram illustrerar ett fel i den sekundära regionen:

Scenario 2. Outage of the secondary region.

När avbrottet har åtgärdats synkroniseras den sekundära databasen omedelbart med den primära och den skrivskyddade lyssnaren växlas tillbaka till den sekundära databasen i region B. Under synkroniseringsprestanda för den primära kan påverkas något beroende på mängden data som behöver synkroniseras.

Det här designmönstret har flera fördelar:

  • Det undviker dataförlust vid tillfälliga avbrott.
  • Stilleståndstiden beror bara på hur snabbt Traffic Manager identifierar anslutningsfelet, som kan konfigureras.

Kompromissen är att programmet måste kunna fungera i skrivskyddat läge.

Planering av affärskontinuitet: Välj en programdesign för haveriberedskap i molnet

Din specifika strategi för haveriberedskap i molnet kan kombinera eller utöka de här designmönstren så att de bäst uppfyller programmets behov. Som tidigare nämnts baseras den strategi du väljer på det serviceavtal som du vill erbjuda dina kunder och topologin för programdistribution. För att hjälpa dig att vägleda ditt beslut jämför följande tabell alternativen baserat på mål för återställningspunkter (RPO) och beräknad återställningstid (ERT).

Mönster RPO ERT
Aktiv-passiv distribution för haveriberedskap med samlokal databasåtkomst Läs- och skrivåtkomst < 5 s Felidentifieringstid + DNS TTL
Aktiv-aktiv distribution för programbelastningsutjämning Läs- och skrivåtkomst < 5 s Felidentifieringstid + DNS TTL
Aktiv-passiv distribution för databevarande Skrivskyddad åtkomst < 5 s Skrivskyddad åtkomst = 0
Läs- och skrivåtkomst = noll Läs- och skrivåtkomst = Felidentifieringstid + respitperiod med dataförlust

Nästa steg