Hög tillgänglighet per servicenivå
Om du ska kunna förstå vilka tillgänglighetsalternativ och funktioner du har tillgång till i Azure SQL måste du förstå tjänstnivåerna. Den servicenivå du väljer avgör hur den underliggande arkitekturen ser ut för den databas eller hanterade instans som du distribuerar.
Det finns två köpmodeller att tänka på: DTU och virtuell kärna. I den här lektionen ligger fokus på vCore-tjänstnivåerna och arkitekturer för hög tillgänglighet. Du kan likna nivåerna Basic och Standard i DTU-modellen med Generell användning och nivån Premium med Affärskritisk.
Generell användning
Databaser och hanterade instanser på servicenivån Generell användning har samma tillgänglighetsarkitektur. Använd figuren nedan som guide och överväg program och kontrolltestgrupp. Programmet ansluter till servernamnet, som sedan ansluter till en gateway (GW), som pekar programmets anslutning till rätt server och körs på en virtuell dator. Med Generell användning använder den primära repliken lokalt ansluten SSD för tempdb. Data- och loggfilerna lagras i Azure Premium Storage, som är lokalt redundant lagring (flera kopior i en region). Säkerhetskopierade filer lagras sedan i Azure Standard Storage, som är RA-GRS som standard. RA-GRS är globalt redundant lagring med kopior i flera regioner.
Som vi gick igenom i en tidigare modul i inlärningsvägen bygger hela Azure SQL på Azure Service Fabric, som fungerar som stamnät i Azure. Om Azure Service Fabric fastställer att det måste ske en redundansväxling så sker den ungefär som för en instans i ett redundanskluster (FCI). Service Fabric letar efter en nod med reservkapacitet och startar en ny SQL Server-instans. Databasfilerna kopplas sedan, återställningen körs och gatewayerna uppdateras för att peka program till den nya noden. Det krävs varken virtuellt nätverk, lyssnare eller uppdateringar. Den här funktionen är inbyggd.
Affärskritisk
Nästa tjänstnivå att överväga är Affärskritisk, som normalt ger bästa möjliga prestanda och tillgänglighet av alla tjänstnivåer (Generell användning, Hyperskala och Affärskritisk). Nivån Affärskritisk är avsedd för affärskritiska program som behöver korta svarstider och minimal stilleståndstid.
Nivån Affärskritisk är som att distribuera en AlwaysOn-tillgänglighetsgrupp i bakgrunden. Till skillnad från på nivån Generell användning körs alla data och loggfiler i Affärskritisk på en direktansluten SSD, vilket avsevärt minskar nätverksfördröjningen. (Generell användning använder fjärrlagring.) I den här tillgänglighetsgruppen finns det tre sekundära repliker. Du kan använda en av dem som en skrivskyddad slutpunkt (utan extra kostnad). En transaktion kan slutföra en incheckning när minst en av de sekundära replikerna har fastslagit ändringen för sin transaktionslogg.
Läs utskalning med en av de sekundära replikerna stöder konsekvens på sessionsnivå, så om den skrivskyddade sessionen återansluts efter ett anslutningsfel som orsakas av att repliken inte är tillgänglig kan den omdirigeras till en replik som inte är 100 % uppdaterad med skrivskyddad replik. På samma sätt gäller att om ett program skriver data via en skrivbar session och sedan läser den direkt via en skrivskyddad session så kanske de senaste uppdateringarna inte visas på repliken omedelbart. Svarstiden orsakas av en åtgärd för att göra om en asynkron transaktionslogg.
Om någon typ av fel inträffar och Service Fabric fastställer att en redundansväxling krävs, är redundansväxlingen till en sekundär replik snabb eftersom repliken redan finns och har de data som är kopplade till den. Du behöver ingen lyssnare vid en redundansväxling. Gatewayen omdirigerar anslutningen till den primära även efter en redundansväxling. Den här växeln sker snabbt och sedan tar Service Fabric hand om att snurra upp en annan sekundär replik.
Hyperskala
Tjänstnivån Hyperskala är endast tillgänglig i Azure SQL Database. Den här tjänstnivån har en unik arkitektur eftersom den använder ett nivåindelat lager med cacheminnen och sidservrar för att utöka möjligheten att snabbt komma åt databassidor utan att behöva komma åt datafilen direkt.
Eftersom arkitekturen använder kopplade sidservrar kan du skala horisontellt och placera alla data i cachelagringslager. Den här nya arkitekturen gör även att Hyperskala har stöd för databasstorlekar upp till 100 TB. Eftersom ögonblicksbilder används går det att ta nästan omedelbara säkerhetskopior oavsett storlek. Databasåterställningar tar också några minuter snarare än flera timmar eller dagar. Du kan även skala upp eller ned konstant för att anpassa dig efter dina arbetsbelastningar.
En annan intressant sak i den här arkitekturen är hur loggtjänsten dragits ut. Loggtjänsten används till att mata repliker och sidservrar. Transaktioner kan checkas in när loggtjänsten hårdnar till landningszonen, så förbrukningen av ändringarna av en sekundär beräkningsreplik krävs inte för en incheckning. Till skillnad från andra tjänstnivåer kan du själv avgöra om du vill använda sekundära repliker. Du kan konfigurera noll till fyra sekundära repliker, som du kan använda för lässkalning.
Precis som i de andra tjänstnivåerna sker en automatisk redundansväxling om Service Fabric fastställer att den behöver det, men återställningstiden beror på förekomsten av sekundära repliker. Om du till exempel inte har några repliker vid redundansväxlingen liknar scenariot nivån Generell användning, på så sätt att Service Fabric först måste hitta reservkapacitet. Om du har en eller flera repliker sker återställningen snabbare, och den liknar mer tjänstnivån Affärskritisk.
Affärskritisk har högsta prestanda och tillgänglighet för arbetsbelastningar med små loggskrivningar som behöver låg svarstid, men med tjänstnivån Hyperskala kan du få ett högre loggdataflöde när det gäller MB/sekund, ger de största databasstorlekarna och tillhandahåller upp till fyra sekundära repliker för högre lässkalningsnivåer. Därför måste du överväga din arbetsbelastning när du väljer mellan de två.