Tillgänglighet via lokal redundans och zonredundans – Azure SQL Managed Instance

gäller för:Azure SQL Managed Instance

Den här artikeln beskriver arkitekturen för Azure SQL Managed Instance som uppnår tillgänglighet via lokal redundans och hög tillgänglighet via zonredundans.

Överblick

SQL Managed Instance körs på den senaste stabila versionen av SQL Server-databasmotorn i Windows-operativsystemet med alla tillämpliga korrigeringar. SQL Managed Instance hanterar automatiskt viktiga underhållsaktiviteter, till exempel korrigeringar, säkerhetskopieringar, Uppgraderingar av Windows- och SQL-databasmotorn och oplanerade händelser, till exempel underliggande maskinvaru-, programvaru- eller nätverksfel. När en instans korrigeras eller redundansväxlar påverkas inte driftstoppet om du använda omprövningslogik i appen. SQL Managed Instance kan snabbt återställas även under de mest kritiska omständigheterna, vilket säkerställer att dina data alltid är tillgängliga. De flesta användare märker inte att uppgraderingar utförs kontinuerligt.

Som standard uppnår Azure SQL Managed Instance tillgänglighet genom lokal redundans, vilket gör din instans tillgänglig under:

• Kundinitierade hanteringsåtgärder som resulterar i ett kort driftstopp
• Serviceunderhållsåtgärder
• Problem och avbrott i datacenter med:
  • Rack där datorerna som driver din tjänst körs.
  • Fysisk dator som är värd för den virtuella dator som kör SQL-databasmotorn.
  • Virtuell dator som kör SQL-databasmotorn
• Andra problem med SQL-databasmotorn
• Andra potentiella oplanerade lokala avbrott

Standardtillgänglighetslösningen är utformad för att säkerställa att incheckade data aldrig går förlorade på grund av fel, att underhållsåtgärder inte påverkar din arbetsbelastning och att instansen inte är en enda felpunkt i din programvaruarkitektur.

Men för att minimera påverkan på dina data i händelse av ett avbrott i en hel zon kan du uppnå hög tillgänglighet genom att aktivera zonredundans. Utan zonredundans sker felövergångar lokalt i samma datacenter, vilket kan leda till att din instans inte är tillgänglig tills avbrottet är löst. Det enda sättet att återställa är genom en katastrofåterställningslösning, till exempel genom en redundansgruppeller en geo-återställning av en geo-redundant säkerhetskopia. Mer information finns i översikt över affärskontinuitet.

Hög tillgänglighet ökar tjänstens tillförlitlighet genom att skydda dig från påverkan på:

• Tillgänglighetszon som utgör datacentret

Det finns två olika arkitekturmodeller för tillgänglighet baserat på tjänstnivån:

• fjärrlagringsmodell baseras på en uppdelning av beräkning och lagring i tjänstnivåerna Generell användning och Nästa generations allmänna användning tjänst som förlitar sig på tillgängligheten och tillförlitligheten för fjärrlagring och tillgängligheten för beräkningskluster som hanteras av Azure Service Fabric. Den här tillgänglighetsmodellen riktar sig till budgetorienterade affärsprogram som kan tolerera viss prestandaförsämring under underhållsaktiviteter.
• Den lokala lagringsmodellen baseras på ett kluster av databasmotorprocesser som förlitar sig på ett kvorum med tillgängliga databasmotornoder på tjänstnivån Affärskritisk som har lokal lagring. Den här lokala lagringsmodellen riktar sig till verksamhetskritiska program som har en hög transaktionshastighet och kräver höga I/O-prestanda. Arkitekturen med hög tillgänglighet garanterar minimal prestandapåverkan på arbetsbelastningen under underhållsaktiviteter.

Mer information om specifika serviceavtal för olika tjänstnivåer finns i serviceavtal för Azure SQL Managed Instance.

Tillgänglighet via lokal redundans

Lokalt redundant tillgänglighet baseras på lagring av beräkningsnoder och data i ett enda datacenter i den primära regionen och skyddar dina data i händelse av lokala fel, till exempel ett småskaligt nätverk eller strömavbrott. Om en storskalig katastrof som brand eller översvämning inträffar i en region kan alla repliker av ett lagringskonto eller data på beräkningsnoderna gå förlorade eller oåterkalleliga. För att ytterligare skydda dina data när du använder det lokalt redundanta tillgänglighetsalternativet bör du överväga att använda ett mer motståndskraftigt lagringsalternativ för dina databassäkerhetskopior.

Tjänstnivå för generell användning

Tjänstnivån Generell användning använder arkitekturen för fjärrlagringstillgänglighet. Följande bild visar fyra olika noder med de avgränsade beräknings- och lagringsskikten.

Tillgänglighetsmodellen för fjärrlagring innehåller två lager:

• Ett tillståndslöst beräkningslager som kör databasmotorprocessen och som endast innehåller tillfälliga och cachelagrade data, till exempel tempdb- och model-databaser på den anslutna SSD:en och planera cacheminne, buffertpool och kolumnlagringspool i minnet. Den här tillståndslösa noden drivs av Azure Service Fabric- som initierar databasmotorn, kontrollerar nodens hälsotillstånd och utför redundansväxling till en annan nod om det behövs.
• Ett tillståndskänsligt datalager med databasfilerna (.mdf och .ldf) som lagras i Azure Blob Storage. Azure Blob Storage har inbyggda funktioner för datatillgänglighet och redundans. Lokalt redundant tillgänglighet baseras på lagring av data på lokalt redundant lagring (LRS) som kopierar dina data tre gånger inom ett enda datacenter i den primära regionen. Det garanterar att varje post i loggfilen eller sidan i datafilen bevaras även om databasmotorprocessen kraschar.

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

Nästa generations tjänstnivå för generell användning

Nästa generations generell användning är en arkitekturuppgradering till den befintliga tjänstnivån Generell användning som använder ett uppgraderat fjärrlagringslager som lagrar instansdata och loggfiler på hanterade diskar i stället för sidblobar och underhåller dem lokalt.

Affärskritisk tjänstnivå

Tjänstnivån Affärskritisk använder den lokala lagringstillgänglighetsmodellen, som integrerar beräkningsresurser (databasmotorprocess) och lagring (lokalt ansluten SSD) på en enda nod. Hög tillgänglighet uppnås genom att replikera både beräkning och lagring till ytterligare noder.

De underliggande databasfilerna (.mdf/.ldf) placeras på den anslutna SSD-lagringen för att ge mycket låg svarstids-I/O för din arbetsbelastning. Hög tillgänglighet implementeras med hjälp av en teknik som liknar SQL Server AlwaysOn-tillgänglighetsgrupper. Klustret innehåller en enda primär replik som är tillgänglig för kundarbetsbelastningar med läs- och skrivbehörighet och upp till tre sekundära repliker (beräkning och lagring) som innehåller kopior av data. Den primära repliken skickar ständigt ändringar till de sekundära replikerna sekventiellt för att säkerställa att data sparas på ett tillräckligt antal sekundära repliker innan de genomför varje transaktion. Den här processen garanterar att en fullständigt synkroniserad replik alltid är tillgänglig för redundansväxling om den primära repliken eller en läsbar sekundär replik blir otillgänglig av någon anledning. Failöver initieras av Azure Service Fabric. När en sekundär replik blir den nya primära repliken skapas en annan sekundär replik för att säkerställa att klustret har tillräckligt många repliker för att upprätthålla kvorum. När överföringen är klar omdirigeras Azure SQL-anslutningar automatiskt till den nya primära repliken eller till en läsbar sekundär replik, beroende på anslutningssträngen.

Som en extra fördel omfattar den lokala lagringstillgänglighetsmodellen möjligheten att omdirigera skrivskyddade Azure SQL-anslutningar till en av de sekundära replikerna. Den här funktionen kallas Read Scale-Out. Den ger 100% ytterligare beräkningskapacitet utan extra kostnad för att avlasta skrivskyddade operationer, såsom analytiska arbetsbelastningar, från den primära repliken.

Hög tillgänglighet via zonredundans

Zonredundant tillgänglighet baseras på att placera repliker i tre Azure-tillgänglighetszoner i den primära regionen. Varje tillgänglighetszon är en separat fysisk plats med oberoende ström, kylning och nätverk.

Som standard skapas klustret med noder för den lokala lagringstillgänglighetsmodellen i samma datacenter. Med introduktionen av Azure-tillgänglighetszonerplacerar SQL Managed Instance olika repliker i olika tillgänglighetszoner i samma region. För att eliminera en enskild felpunkt dupliceras även kontrollringen över flera zoner. Kontrollplanstrafiken dirigeras sedan till en lastbalanserare som också distribueras över tillgänglighetszoner. Trafikroutning från kontrollplanet till lastbalanseraren styrs av Azure Traffic Manager.

Genom att använda en zonredundant konfiguration kan du göra dina affärskritiska eller allmänna instanser motståndskraftiga mot en mycket större uppsättning fel, inklusive oåterkalleliga datacenterfel, utan några ändringar i programlogik. Du kan konvertera alla befintliga affärskritiska eller allmänna instanser till den zonredundanta konfigurationen.

Eftersom zonredundanta instanser har repliker i olika datacenter med ett visst avstånd mellan dem kan den ökade nätverksfördröjningen öka transaktionsincheckningstiden 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 zonredundans. Den här processen är en onlineåtgärd som liknar den vanliga uppgraderingen av servicenivån. I slutet av processen migreras instansen från en zonredundant ring till en ring med en zon eller vice versa.

Kom igång med zonredundans för din SQL-hanterade instans genom att läsa Konfigurera zonredundans.

Tjänstnivå för generell användning

På den allmänna användningsnivån uppnås zonredundans genom att placera tillståndslösa beräkningsnoder i olika tillgänglighetszoner och förlitar sig sedan på en tillståndskänslig zonredundant lagring (ZRS) som är kopplad till den nod som för tillfället kör den aktiva processen för SQL Database Engine. I händelse av ett avbrott blir SQL Database Engine-processen aktiv på en av de tillståndslösa noderna, som sedan kommer åt data i den tillståndskänsliga lagringen.

Följande diagram visar zonredundansarkitekturen för tjänstnivån Generell användning:

Affärskritisk tjänstenivå

På tjänstnivån Affärskritisk uppnås zonredundans genom att placera beräknings- och lagringsrepliker i olika tillgänglighetszoner och sedan använda underliggande AlwaysOn-tillgänglighetsgruppsteknik för att replikera dataändringar från den primära instansen till väntelägesrepliker i andra tillgänglighetszoner. I händelse av ett avbrott finns det en automatisk redundansväxling som sömlöst övergår en av standby-replikerna till primär.

Följande diagram visar zonredundansarkitekturen för tjänstnivån Affärskritisk:

Testa applikationens motståndskraft mot fel

Tillgänglighet är en grundläggande del av SQL Managed Instance-plattformen som fungerar transparent för ditt databasprogram. Vi inser dock att du kanske vill testa hur de automatiska redundansåtgärder som initierades under planerade eller oplanerade händelser skulle påverka ett program innan du distribuerar det till produktion. Du kan utlösa en felövergång manuellt genom att anropa ett särskilt API för att starta om en hanterad instans. Eftersom omstartsåtgärden är påträngande och ett stort antal av dem kan stressa plattformen tillåts endast ett redundansanrop var 15:e minut för varje hanterad instans.

Vid en äkta failover bryts anslutningar till instansen när SQL-tjänsten blir primär på en annan nod. Om du vill simulera en redundansväxling anropar du kommandot som startar om SQL-processen för att simulera start av tjänsten som om det fanns en redundansväxling. Anslutningar kan dock misslyckas under en längre period under en verklig redundansväxling jämfört med en simulerad redundans, eftersom SQL-processen under en verklig redundansväxling blir den primära på en annan virtuell dator i klustret (antingen lokalt eller i en annan zon om zonredundans är aktiverat) och under en simulerad redundansväxling startas SQL-processen om på den befintliga virtuella datorn.

Det manuella redundanskommandot i det här avsnittet fungerar vanligtvis på samma sätt i både lokalt redundanta och zonredundanta konfigurationer – den startar bara om SQL-processen lokalt och initierar inte en redundansväxling till en annan nod, men några undantag gäller. Den här lokala redundansväxlingen skiljer sig från en redundansväxling som inträffar för en redundansgrupp.

En lokal failöver kan initieras med hjälp av PowerShell, REST API eller Azure CLI:

Slutsats

Azure SQL Managed Instance har en inbyggd lösning med hög tillgänglighet som är djupt integrerad med Azure-plattformen. Tjänsten är beroende av Service Fabric för att identifiera fel och återställning, Azure Blob Storage för att skydda data och på tillgänglighetszoner för högre feltolerans. Och för tjänstnivån Affärskritisk använder SQL Managed Instance SQL Server AlwaysOn-tillgänglighetsgruppteknik för databasreplikering och redundans. Kombinationen av dessa tekniker gör det möjligt för program att fullt ut utnyttja fördelarna med en modell för blandad lagring och har stöd för de mest krävande serviceavtalen.

Nästa steg

• Aktivera zonredundans för Azure SQL Managed Instance.
• 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 failover på SQL Managed Instance
• Fler alternativ för hög tillgänglighet och haveriberedskap finns i Business Continuity