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

  • Artikel

Gäller för:Azure SQL Managed Instance

I den här artikeln beskrivs hög tillgänglighet i Azure SQL Managed Instance.

Viktigt!

Zonredundant konfiguration finns i offentlig förhandsversion för tjänstnivån Generell användning och allmänt tillgänglig för tjänstnivån Affärskritisk.

Översikt

Målet med arkitekturen för hög tillgänglighet i Azure SQL Managed Instance är att minimera påverkan på kundarbetsbelastningar från kundinitierade hanteringsåtgärder som resulterar i en kort stilleståndstid, serviceunderhållsåtgärder och oplanerade avbrott. Mer information om specifika serviceavtal för olika tjänstnivåer finns i Azure SQL Managed Instance. Hög tillgänglighet är det begrepp som skyddar dig från påverkan som är begränsad till

  • tillgänglighetszon som utgör datacentret (i händelse av region med flera zoner),
  • rack där noder som driver tjänsten körs,
  • själva noden,
  • programnivå.

För att minimera påverkan vid regionala eller större avbrott kan du använda någon av de tillgängliga tekniker som omfattas av vår översikt över affärskontinuitet.

SQL Managed Instance körs på den senaste stabila versionen av SQL Server Database Engine i Windows-operativsystemet med alla tillämpliga korrigeringar. SQL Managed Instance hanterar automatiskt kritiska underhållsaktiviteter, till exempel korrigeringar, säkerhetskopieringar, Uppgraderingar av Windows- och SQL-motorn och oplanerade händelser som underliggande maskinvara, programvara eller nätverksfel. När en instans korrigeras eller redundansväxlar påverkas inte stilleståndstiden om du använder logik för återförsök i din app. 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.

Lösningen med hög tillgänglighet ä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.

Det finns två olika arkitekturmodeller med hög tillgänglighet baserat på tjänstnivån:

  • Fjärrlagringsmodellen baseras på en separation av beräkning och lagring på tjänstnivån Generell användning som förlitar sig på hög tillgänglighet och tillförlitlighet för fjärrlagring och hög tillgänglighet för beräkningskluster som hanteras av Azure Service Fabric. Den här modellen med hög tillgänglighet riktar sig till budgetorienterade affärsprogram som kan tolerera viss prestandaförsämring under underhållsaktiviteter.
  • Den lokala lagringsmodellen baseras på ett kluster med databasmotorprocesser som förlitar sig på ett kvorum med tillgängliga databasmotornoder på den Affärskritisk tjänstnivå 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.

Lokalt redundant tillgänglighet

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 skikten för beräkning och lagring.

Diagram showing separation of compute and storage.

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 databaserna och model på den anslutna SSD:en, samt plancache, 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 redundans 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.

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.

Diagram of a cluster of database engine nodes.

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. Redundans 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 redundansväxlingen är klar omdirigeras Azure SQL-anslutningar automatiskt till den nya primära repliken (eller läsbar sekundär replik baserat på anslutningssträng).

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 Läs utskalning. Den 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.

Zonredundant tillgänglighet

Zonredundant tillgänglighet baseras på att placera beräkningsnoder och lagringsrepliker i tre Azure-tillgänglighetszoner i den primära regionen. Varje tillgänglighetszon är en separat fysisk plats med fristående strömförsörjning, nedkylning och nätverk.

Som standard skapas klustret med noder för den lokala lagringstillgänglighetsmodellen i samma datacenter. Med introduktionen av Azure Tillgänglighetszoner kan SQL Managed Instance placera olika repliker av en Affärskritisk instans i olika tillgänglighetszoner i samma region. På samma sätt placeras de tillståndslösa beräkningsnoderna på en tjänstnivå för generell användning i en annan tillgänglighetszon, medan tillståndskänslig lagring använder zonredundant lagringskonfiguration (ZRS).

För att eliminera en enskild felpunkt dupliceras även kontrollringen över flera zoner som tre gatewayringar (GW). Routningen till en specifik gatewayring styrs av Azure Traffic Manager (ATM). Genom att välja en zonredundant konfiguration kan du göra dina Affärskritisk- eller generell användning-instanser motståndskraftiga mot en mycket större uppsättning fel, inklusive oåterkalleliga datacenterfel, utan några ändringar i programlogik. Du kan också konvertera befintliga Affärskritisk- eller generell användningsinstanser till zonredundant konfiguration.

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.

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

Diagram of the zone-redundant high availability architecture.

Tänk på följande när du använder zonredundans:

Regioner som stöds för Affärskritisk instanser

Zonredundans för Affärskritisk SQL Managed Instance stöds i följande regioner:

Nord- och Sydamerika Europa Mellanöstern Afrika Asien och stillahavsområdet
Brasilien, södra Frankrike, centrala Qatar, centrala Sydafrika, norra Australien, östra
Kanada, centrala Italien, norra Israel, centrala Indien, centrala
Central US Tyskland, västra centrala Japan, östra
East US Norge, östra Sydkorea, centrala
USA, östra 2 Europa, norra Sydostasien
USA, södra centrala Södra Storbritannien Asien, östra
USA, västra 2 Sverige, centrala
USA, västra 3 Schweiz, norra
Polen, centrala

Regioner som stöds för generell användning-instanser

Kommentar

Zonredundant konfiguration finns i offentlig förhandsversion för tjänstnivån Generell användning.

Nord- och Sydamerika Europa Mellanöstern Afrika Asien och stillahavsområdet
Brasilien, södra Frankrike, centrala Qatar, centrala Sydafrika, norra Australien, östra
East US Italien, norra Israel, centrala Indien, centrala
USA, östra 2 Tyskland, västra centrala Japan, östra
USA, södra centrala Norge, östra Sydkorea, centrala
USA, västra 2 Europa, norra Sydostasien
USA, västra 3 Södra Storbritannien Asien, östra
Sverige, centrala
Schweiz, norra
Polen, centrala

Testa programfelåterhämtning

Hög 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 redundansväxling manuellt genom att anropa ett särskilt API för att starta om en hanterad instans. När det gäller en zonredundant instans skulle API-anropet leda till 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 det ändrar prestanda från slutpunkt till slutpunkt på grund av ändringar i nätverksfördröjningen. 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.

En redundansväxling kan initieras med Hjälp av PowerShell, REST API eller Azure CLI:

PowerShell REST-API Azure CLI
Invoke-AzSqlInstanceFailover SQL Managed Instance – redundans az sql mi failover kan användas för att anropa ett REST API-anrop från 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