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 aktiv geo-replikering eller automatiska redundansgrupper för att ge motståndskraft mot regionala avbrott och oåterkalleliga fel. Med samma funktion kan du skapa globalt distribuerade program som är optimerade för lokal åtkomst till data. Den här artikeln beskriver vanliga programmönster, inklusive fördelar och avvägningar för varje alternativ.

Scenario 1: Använda två Azure-regioner för affärskontinuhet med minimal avbrottstid

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ån och datanivån måste vara samplacerade för att minska svarstider och trafikkostnader
• Stilleståndstiden är i grunden en högre affärsrisk för dessa program än dataförlust

I det här fallet är programdistributionstopologin optimerad för att hantera regionala katastrofer när alla programkomponenter behöver redundans redundans. Diagrammet nedan visar den här topologin. Vid 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 databasanslutningar, replikering och redundans. Webbtjänsten i båda regionerna har konfigurerats för åtkomst till databasen via den skrivskyddade lyssnaren < failover-group-name > .database.windows.net (1). Azure Traffic Manager har ställts in för att använda prioritetsroutningsmetoden (2).

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

Efter ett avbrott i den primära regionen SQL Database att den primära databasen inte är tillgänglig och utlöser redundans till den sekundära regionen baserat på parametrarna för den automatiska redundansprincipen (1). Beroende på programmets serviceavtal kan du konfigurera en respitperiod som styr tiden mellan identifieringen av avbrottet och själva redundansen. Det är möjligt Azure Traffic Manager initierar redundansen av slutpunkten innan redundansgruppen utlöser redundans för databasen. I så fall kan webbappen inte omedelbart återansluta till databasen. Men återanslutningarna lyckas automatiskt så fort databasens redundans har slutförts. När den misslyckade regionen återställs och är online igen återansluter den gamla primära automatiskt som en ny sekundär. Diagrammet nedan illustrerar konfigurationen efter redundans.

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 slutpunktens webbapp 2 som degraderad (2). Programmets prestanda påverkas inte i det här fallet, men databasen exponeras och därmed med högre risk för dataförlust om region A misslyckas i följd.

När avbrottet har åtgärdats synkroniseras den sekundära databasen automatiskt om med den primära. Under synkroniseringen kan den primära primära prestandan påverkas. Den specifika påverkan beror på mängden data som den nya primära har fått sedan redundansen.

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

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

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

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

Scenario 2: Azure-regioner för affärskontinuering med maximalt bevarande av data

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

• All dataförlust är en hög affärsrisk. Redundansen av databasen kan bara användas som en sista utväg om avbrottet orsakas av ett oåterkalleligt fel.
• Programmet stöder skrivskyddade och skrivskyddade driftlägen och kan användas i "skrivskyddade läge" under en viss tidsperiod.

I det här mönstret växlar programmet till skrivskyddad läge när läs-/skriv-anslutningarna börjar få time out-fel. Webbprogrammet distribueras till båda regionerna och innehåller en anslutning till slutpunkten för läs- och skrivskyddad lyssnare och en annan anslutning till den skrivskyddade lyssnarslutpunkten (1). Profilen Traffic Manager bör använda prioritetsdirigering. Slutpunktsövervakning ska aktiveras för programslutpunkten i varje region (2).

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

När Traffic Manager upptäcker ett anslutningsfel till region A växlar det automatiskt användartrafik till programinstansen i region B. Med det här mönstret är det viktigt att du ställer in 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 avbrottet minimeras inom den tiden. När webbappen i region B aktiveras börjar läs-/skrivåtgärderna att misslyckas. Då bör den växla till det skrivskyddade läget (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 troligen inte åtgärdas inom respitperioden. När den upphör att gälla utlöser redundansgruppen redundansen. Efter det blir lyssnaren för läsning och skrivning tillgänglig och anslutningarna till den slutar att misslyckas (2). Följande diagram illustrerar de två stegen i återställningsprocessen.

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

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 förhindrar dataförlust under tillfälliga avbrott.
• Stilleståndstiden beror bara på hur Traffic Manager identifierar anslutningsfelet, vilket kan konfigureras.

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

Scenario 3: Programflytt till ett annat geografiskt område utan dataförlust och nära noll driftstopp

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

• Slutanvändarna kommer åt programmet från olika geografiska områden
• Programmet innehåller skrivskyddade arbetsbelastningar som inte är beroende av fullständig synkronisering med de senaste uppdateringarna
• Skrivåtkomst till data ska stödjas i samma geografiska område för de flesta användare
• Läsfördröjning är kritiskt för slutanvändarens upplevelse

För att uppfylla dessa krav måste du garantera att användarenhet alltid ansluter till programmet som distribuerats i samma geografiska område för skrivskyddade åtgärder, till exempel webbdata, analys osv. OLTP-åtgärderna bearbetas i samma geografiska område större delen av tiden. Till exempel bearbetas OLTP-åtgärder på dagtid i samma geografiska område, men när de inte används kan de bearbetas i ett annat geografiskt område. Om slutanvändaraktiviteten huvudsakligen sker under arbetstid kan du garantera optimala prestanda för de flesta användare större delen av tiden. Följande diagram visar den här topologin.

Programmets resurser ska distribueras i varje geografiskt område där du har betydande användningsefterfrågan. Om ditt program till exempel aktivt används i USA, EU och Asien, sydöstra ska programmet distribueras till alla dessa geografiska områden. Den primära databasen bör dynamiskt växlas från ett geografiskt område till nästa i slutet av arbetstiden. Den här metoden kallas "följ sun". OLTP-arbetsbelastningen ansluter alltid till databasen via den skrivskyddade lyssnaren < failover-group-name > .database.windows.net (1). Den skrivskyddade arbetsbelastningen ansluter till den lokala databasen direkt med hjälp av databasserverns < > slutpunktsservernamn .database.windows.net (2). Traffic Manager konfigureras med prestandaroutningsmetoden. Det säkerställer att slutanvändarens enhet är ansluten till webbtjänsten i den närmaste regionen. Traffic Manager ska konfigureras med slutpunktsövervakning aktiverat för varje webbtjänstslutpunkt (3).

I slutet av dagen, till exempel kl. 23:00 lokal tid, bör de aktiva databaserna växlas till nästa region (Europa, norra). Den här uppgiften kan automatiseras helt med hjälp av Azure Logic Apps. Uppgiften omfattar följande steg:

• Växla primär server i redundansgruppen till Europa, norra med användarvänlig redundans (1)
• Ta bort redundansgruppen mellan USA, östra och Europa, norra
• Skapa en ny redundansgrupp med samma namn men mellan Europa, norra och Asien, östra (2).
• Lägg till den primära i Europa, norra och den sekundära Asien, östra till den här redundansgruppen (3).

Följande diagram illustrerar den nya konfigurationen efter den planerade redundansen:

Om ett avbrott inträffar i till exempel Europa, norra initieras den automatiska databas redundansen av redundansgruppen, vilket i praktiken resulterar i att programmet flyttas till nästa region i förväg (1). I så fall är USA, östra den enda återstående sekundära regionen tills Europa, norra är online igen. De återstående två regionerna betjänar kunderna i alla tre geografiska områden genom att byta roller. Azure Logic Apps måste justeras i enlighet med detta. Eftersom de återstående regionerna får ytterligare användartrafik från Europa påverkas programmets prestanda inte bara av ytterligare svarstid utan även av ett ökat antal slutanvändaranslutningar. När avbrottet har åtgärdats i Europa, norra synkroniseras den sekundära databasen omedelbart med den aktuella primära databasen. Följande diagram illustrerar ett avbrott i Europa, norra:

De viktigaste fördelarna med den här designen är:

• Den skrivskyddade programarbetsbelastningen har alltid åtkomst till data i closets-regionen.
• Arbetsbelastningen för läs- och skrivskyddade program har åtkomst till data i den närmaste regionen under perioden för den högsta aktiviteten i varje geografiskt område
• Eftersom programmet distribueras till flera regioner kan det klara en förlust av en av regionerna utan betydande driftstopp.

Men det finns vissa kompromisser:

• Ett regionalt avbrott resulterar i att geografin påverkas av längre svarstider. Både skrivskyddade och skrivskyddade arbetsbelastningar betjänas av programmet i ett annat geografiskt område.
• De skrivskyddade arbetsbelastningarna måste ansluta till en annan slutpunkt i varje region.

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

Din specifika strategi för haveriberedskap i molnet kan kombinera eller utöka dessa designmönster så att de bäst uppfyller behoven i ditt program. Som tidigare nämnts baseras den strategi du väljer på det serviceavtal som du vill erbjuda dina kunder och programdistributionstopologin. Som hjälp för ditt beslut jämför följande tabell alternativen baserat på mål för återställningspunkt (RPO) och beräknad återställningstid (ERT).

Nästa steg

• En översikt över och scenarier för affärskontinuier finns i Översikt över affärskontinuhet
• Mer information om aktiv geo-replikering finns i Aktiv geo-replikering.
• Mer information om automatiska redundansgrupper finns i Automatiska redundansgrupper.
• Information om aktiv geo-replikering med elastiska pooler finns i Haveriberedskapsstrategier för elastiska pooler.