Hög tillgänglighet för Azure SQL Database och SQL Managed Instance

GÄLLER FÖR: Azure SQL Database Azure SQL Managed Instance

Målet med arkitekturen för hög tillgänglighet i Azure SQL Database och SQL Managed Instance är att garantera att databasen är igång och körs minst 99,99 % av tiden utan att behöva bekymra sig om effekten av underhållsåtgärder och avbrott. Mer information om specifika serviceavtal för olika nivåer finns i SLA för Azure SQL Database och serviceavtal för Azure SQL Managed Instance.

Azure hanterar automatiskt kritiska underhållsaktiviteter, till exempel korrigeringar, säkerhetskopieringar, Windows- och Azure SQL-uppgraderingar, samt oplanerade händelser som underliggande maskinvara, programvara eller nätverksfel. När den underliggande databasen i Azure SQL Database korrigeras eller misslyckas är driftstoppet inte märkbart om du använder logik för återförsök i din app. SQL Database och SQL Managed Instance kan snabbt återställas även under de mest kritiska omständigheter som säkerställer att dina data alltid är tillgängliga.

Lösningen för hög tillgänglighet är utformad för att säkerställa att interna data aldrig går förlorade på grund av fel, att underhållsåtgärder inte påverkar din arbetsbelastning och att databasen inte kommer att vara en felpunkt i programvaruarkitekturen. Det finns inga underhållstider eller driftstopp som kräver att du stoppar arbetsbelastningen när databasen uppgraderas eller underhålls.

Det finns två arkitekturmodeller med hög tillgänglighet:

• Standardtillgänglighetsmodell som baseras på en separation av beräkning och lagring. Den förlitar sig på hög tillgänglighet och tillförlitlighet på fjärrlagringsnivån. Den här arkitekturen riktar sig till budgetorienterade affärsprogram som kan tolerera viss prestandaförsämring under underhållsaktiviteter.
• Premium tillgänglighetsmodell som baseras på ett kluster med databasmotorprocesser. Den förlitar sig på det faktum att det alltid finns ett kvorum med tillgängliga databasmotornoder. Den här arkitekturen riktar in sig på verksamhetskritiska program med höga I/O-prestanda, hög transaktionsfrekvens och garanterar minimal prestandapåverkan på din arbetsbelastning under underhållsaktiviteter.

SQL Database och SQL Managed Instance körs båda på den senaste stabila versionen av SQL Server-databasmotorn och Windows-operativsystemet, och de flesta användare märker inte att uppgraderingar utförs kontinuerligt.

Lokal redundant tjänstnivå för Basic, Standard Generell användning och tjänstnivå

Tjänstnivån Basic, Standard och Generell användning använder standardtillgänglighetsarkitekturen för både serverlös och etablerad beräkning. Följande bild visar fyra olika noder med de avgränsade beräknings- och lagringsskikten.

Standardtillgänglighetsmodellen innehåller två lager:

• Ett tillståndslöst beräkningslager som kör processen och endast innehåller tillfälliga och cachelagrade data, till exempel TempDB, modelldatabaser på den anslutna sqlservr.exe SSD:n och planera cache, buffertpool och kolumnlagringspool i minnet. Den här tillståndslösa noden drivs av Azure Service Fabric som initierar , kontrollerar nodens hälsotillstånd och utför redundans till en annan nod sqlservr.exe vid behov.
• Ett tillståndsfult datalager med databasfilerna (.mdf/.ldf) som lagras i Azure Blob Storage. Azure Blob Storage har inbyggd funktion för datatillgänglighet och redundans. Det garanterar att varje post i loggfilen eller sidan i datafilen bevaras även om sqlservr.exe processen kraschar.

När databasmotorn eller operativsystemet uppgraderas eller ett fel upptäcks flyttar Azure Service Fabric den tillståndslösa processen till en annan tillståndslös beräkningsnod med tillräckligt sqlservr.exe med ledigt utrymme. Data i Azure Blob Storage påverkas inte av flytten och data/loggfilerna kopplas till den nyligen initierade sqlservr.exe processen. Den här processen garanterar 99,99 % tillgänglighet, men en tung arbetsbelastning kan uppleva viss prestandaförsämring under övergången eftersom den nya sqlservr.exe processen börjar med kall cache.

Generell användning zonredundant tillgänglighet på tjänstnivå (förhandsversion)

Zonredundant konfiguration för tjänstnivån generell användning erbjuds för både serverlös och etablerad beräkning. Den här konfigurationen använder Azure-tillgänglighetszoner replikera databaser över flera fysiska platser inom   en Azure-region.Genom att välja zonredundans kan du göra dina nya och befintliga serverlösa och etablerade enkla databaser och elastiska pooler för generell användning motståndskraftiga mot en mycket större uppsättning fel, inklusive oåterkalleliga datacenteravbrott, utan ändringar i programlogiken.

Zonredundant konfiguration för nivån generell användning har två lager:

• Ett tillståndsfult datalager med databasfilerna (.mdf/.ldf) som lagras i ZRS (zonredundant lagring). Med ZRS kopieras data och loggfiler synkront över tre fysiskt isolerade Azure-tillgänglighetszoner.
• Ett tillståndslöst beräkningslager som kör sqlservr.exe-processen och som endast innehåller tillfälliga och cachelagrade data, till exempel TempDB, modelldatabaser på den anslutna SSD:n och plancache, buffertpool och kolumnlagringspool i minnet. Den här tillståndslösa noden drivs av Azure Service Fabric som initierar sqlservr.exe, kontrollerar nodens hälsotillstånd och utför redundans till en annan nod vid behov. För zonredundant serverlösa och etablerade databaser för generell användning är noder med reservkapacitet lättillgängliga i andra Tillgänglighetszoner för redundans.

Den zonredundanta versionen av arkitekturen för hög tillgänglighet för tjänstnivån generell användning illustreras med följande diagram:

Premium och Affärskritisk lokalt redundant tillgänglighet

Premium och Affärskritisk-tjänstnivåer utnyttjar Premium-tillgänglighetsmodellen, som integrerar beräkningsresurser (process) och lagring (lokalt ansluten SSD) på sqlservr.exe en enda nod. Hög tillgänglighet uppnås genom replikering av både beräkning och lagring till ytterligare noder, vilket skapar ett kluster med tre till fyra noder.

De underliggande databasfilerna (.mdf/.ldf) placeras på den anslutna SSD-lagringen för att ge IO med mycket kort svarstid till din arbetsbelastning. Hög tillgänglighet implementeras med hjälp av en teknik som liknar SQL Server Always On-tillgänglighetsgrupper. Klustret innehåller en enda primär replik som är tillgänglig för skrivskyddade kundarbetsbelastningar och upp till tre sekundära repliker (beräkning och lagring) som innehåller kopior av data. Den primära noden pushar ständigt ändringar till de sekundära noderna i ordning och ser till att data synkroniseras till minst en sekundär replik innan varje transaktion genomförs. Den här processen garanterar att om den primära noden kraschar av någon anledning finns det alltid en helt synkroniserad nod att redundansa till. Redundansen initieras av Azure Service Fabric. När den sekundära repliken blir den nya primära noden skapas en annan sekundär replik för att se till att klustret har tillräckligt med noder (kvorumuppsättning). När redundansen är klar omdirigeras Azure SQL-anslutningar automatiskt till den nya primära noden.

Som en extra fördel inkluderar Premium-tillgänglighetsmodellen möjligheten att omdirigera skrivskyddade Azure SQL-anslutningar till en av de sekundära replikerna. Den här funktionen kallas lässkalning. Det ger 100 % ytterligare beräkningskapacitet utan extra kostnad för skrivskyddade åtgärder som inte läses in, till exempel analytiska arbetsbelastningar, från den primära repliken.

Premium och Affärskritisk zonredundant tillgänglighet på tjänstnivå

Som standard skapas nodklustret för premiumtillgänglighetsmodellen i samma datacenter. Med introduktionen av Azure-tillgänglighetszonerkan SQL Database placera olika repliker av Affärskritisk-databasen till olika tillgänglighetszoner i samma region. För att eliminera en felpunkt dupliceras även kontrollringen över flera zoner som tre gatewayringar (GW). Routningen till en specifik gatewayring styrs av Azure Traffic Manager (ATM). Eftersom den zonredundanta konfigurationen i Premium eller Affärskritisk inte skapar ytterligare databasredundans kan du aktivera den utan extra kostnad. Genom att välja en zonredundant konfiguration kan du göra dina Premium- eller Affärskritisk-databaser motståndskraftiga mot en mycket större uppsättning fel, inklusive oåterkalleliga datacenteravbrott, utan ändringar i programlogiken. Du kan också konvertera alla befintliga Premium eller Affärskritisk databaser eller pooler till zonredundant konfiguration.

Eftersom zonredundant databaserna har repliker i olika datacenter med ett visst avstånd mellan dem, kan den ökade nätverksfördröjningen öka genomförandetiden och därmed påverka prestandan för vissa OLTP-arbetsbelastningar. Du kan alltid återgå till konfigurationen med en zon genom att inaktivera inställningen för zonredundans. Den här processen är en onlineåtgärd som liknar den vanliga uppgraderingen av tjänstnivån. I slutet av processen migreras databasen eller poolen från en zonredundant ring till en enskild zonring eller vice versa.

Den zonredundanta versionen av arkitekturen för hög tillgänglighet illustreras med följande diagram:

Tillgänglighet för tjänstnivå i hyperskala

Arkitekturen på tjänstnivå hyperskala beskrivs i arkitekturen för distribuerade funktioner och är för närvarande endast tillgänglig för SQL Database, inte SQL Managed Instance.

Tillgänglighetsmodellen i Hyperskala innehåller fyra lager:

• Ett tillståndslöst beräkningslager som kör processerna och endast innehåller tillfälliga och cachelagrade data, till exempel sqlservr.exe icke-heltäckande RBPEX-cache, TempDB, modelldatabas osv. på den anslutna SSD:n och planera cacheminne, buffertpool och kolumnlagringspool i minnet. Det här tillståndslösa lagret innehåller den primära beräkningsrepliken och eventuellt ett antal sekundära beräkningsrepliker som kan fungera som redundansmål.
• Ett tillståndslöst lagringslager som bildas av sidservrar. Det här lagret är den distribuerade lagringsmotorn för sqlservr.exe de processer som körs på beräkningsreplikerna. Varje sidserver innehåller endast tillfälliga och cachelagrade data, till exempel täcker RBPEX-cache på den anslutna SSD:n och datasidor som cachelagras i minnet. Varje sidserver har en länkad sidserver i en aktiv-aktiv-konfiguration för att tillhandahålla belastningsutjämning, redundans och hög tillgänglighet.
• Ett tillståndsful transaction log storage-lager som bildas av beräkningsnoden som kör loggtjänstprocessen, landningszonen för transaktionsloggen och långsiktig lagring av transaktionsloggen. Landningszon och långsiktig lagring använder Azure Storage, vilket ger tillgänglighet och redundans för transaktionsloggen, vilket säkerställer databeständighet för indelade transaktioner.
• Ett tillståndsfult datalagringslager med databasfilerna (.mdf/.ndf) som lagras i Azure Storage och uppdateras av sidservrar. Det här lagret använder funktioner för datatillgänglighet och redundans i Azure Storage. Det garanterar att varje sida i en datafil bevaras även om processer i andra lager i arkitekturen i Hyperskala kraschar, eller om beräkningsnoder misslyckas.

Beräkningsnoder i alla hyperskalalager körs på Azure Service Fabric, som styr hälsotillståndet för varje nod och utför redundans till tillgängliga felfria noder efter behov.

Mer information om hög tillgänglighet i Hyperskala finns i Hög tillgänglighet för databaser i Hyperskala.

Accelererad databasåterställning (ADR)

Accelererad databasåterställning (ADR) är en ny databasmotorfunktion som avsevärt förbättrar databasens tillgänglighet, särskilt i närvaro av långvariga transaktioner. ADR är för närvarande tillgängligt för Azure SQL Database, Azure SQL Managed Instance och Azure Synapse Analytics.

Testa programmets återhämtning vid fel

Hög tillgänglighet är en grundläggande del av SQL Database- och SQL Managed Instance-plattformen som fungerar transparent för ditt databasprogram. Vi förstår dock att du kan vilja testa hur de automatiska redundansväxlingar som initieras under planerade eller oplanerade händelser skulle påverka ett program innan du distribuerar det till produktion. Du kan utlösa en redundans manuellt genom att anropa ett särskilt API för att starta om en databas, en elastisk pool eller en hanterad instans. Om en zonredundant serverlös eller etablerad Generell användning-databas eller elastisk pool skulle API-anropet resultera i att klientanslutningar omdirigeras till den nya primära i en tillgänglighetszon som skiljer sig från tillgänglighetszonen för den gamla primära. Förutom att testa hur redundans påverkar befintliga databassessioner kan du även kontrollera om prestandan för hela databasen ändras på grund av ändringar i nätverksfördröjningen. Eftersom omstartsåtgärden är påfrestande och ett stort antal av dem kan stressa plattformen tillåts bara ett redundansanrop var 15:e minut för varje databas, elastisk pool eller hanterad instans.

En redundans kan initieras med PowerShell, REST API eller Azure CLI:

Slutsats

Azure SQL Database och Azure SQL Managed Instance är en inbyggd lösning för hög tillgänglighet som är djupt integrerad med Azure-plattformen. Den är beroende av Service Fabric för felidentifiering och återställning, Azure Blob Storage för dataskydd och på Tillgänglighetszoner för högre feltolerans (som nämnts tidigare i dokumentet gäller inte för Azure SQL Managed Instance ännu). Dessutom kan SQL Database och SQL Managed Instance utnyttja Always On-tillgänglighetsgruppens teknik från SQL Server instansen för replikering och redundans. Kombinationen av dessa tekniker gör det möjligt för program att fullt ut dra nytta av fördelarna med en blandad lagringsmodell och stödja de mest krävande serviceavtalen.

Nästa steg

• Läs mer om Azure-tillgänglighetszoner
• Läs mer om Service Fabric
• Läs mer om Azure Traffic Manager
• Lär dig hur du initierar en manuell redundans på SQL Managed Instance
• Fler alternativ för hög tillgänglighet och haveriberedskap finns i Affärskontinunivå