Arkitektur för distribuerade funktioner i hyperskala

Gäller för:Azure SQL Database

Tjänstnivån Hyperskala använder en arkitektur med mycket skalbara och separata lagrings- och beräkningsnivåer. Den här artikeln beskriver de komponenter som gör det möjligt för kunder att snabbt skala Hyperskala-databaser samtidigt som de drar nytta av nästan omedelbara säkerhetskopior och mycket skalbar transaktionsloggning.

Dricks

Förenklade priser för SQL Database Hyperscale kommer snart. Mer information finns i prissättningsbloggen för Hyperskala.

Översikt över hyperskalaarkitektur

Traditionella databasmotorer centraliserar datahanteringsfunktioner i en enda process: även så kallade distribuerade databaser i produktion har idag flera kopior av en monolitisk datamotor.

Hyperskala-databaser följer en annan metod. Hyperskala separerar frågebearbetningsmotorn, där semantiken för olika datamotorer skiljer sig från de komponenter som ger långsiktig lagring och hållbarhet för data. På så sätt kan lagringskapaciteten skalas ut smidigt så långt det behövs. Lagringsgränsen som ursprungligen stöds är 100 TB.

All nätverkskommunikation mellan Hyperskala-komponenter använder Azure-nätverksinfrastruktur med inbyggd redundans.

Sekundära repliker med hög tillgänglighet och namngivna repliker är valfria beräkningsnoder som kan läggas till på begäran. Båda delar samma lagringskomponenter, så ingen datakopiering krävs för att starta en ny replik. En geo-sekundär replik kan läggas till på begäran i samma eller en annan Azure-region. För dataskydd och redundans har geo-sekundära repliker lagringskomponenter som är separata från de som används av den primära repliken.

Följande diagram illustrerar den funktionella Hyperskala-arkitekturen:

Diagram som visar att Hyperskalas beräkningsnivå består av en primär beräkningsanteckning och sekundära beräkningsnoder, var och en med RBPEX-datacachen. Loggtjänsten kommunicerar både med beräkningsanteckningar och sidservrar. Sidservrar finns på sin egen nivå och har även RBPEX-datacache.

En Hyperskala-databas innehåller följande typer av komponenter: beräkningsnoder, sidservrar, loggtjänsten och Azure Storage.

Compute

Beräkningsnoden är där relationsmotorn finns. Beräkningsnoden är den där språk-, fråge- och transaktionsbearbetningen sker. Alla användarinteraktioner med en Hyperskala-databas sker via beräkningsnoder. Beräkningsnoder kan antingen konfigureras för att använda serverlös eller etablerad beräkning.

Beräkningsnoder har lokala SSD-baserade cacheminnen som kallas Resilient Buffer Pool Extension (RBPEX Data Cache). RBPEX Data Cache är en intelligent datacache med låg svarstid som minimerar behovet av att hämta data från fjärrsideservrar.

Hyperskala-databaser har en primär beräkningsnod där läs-skriv-arbetsbelastningen och transaktioner bearbetas. Upp till fyra sekundära beräkningsnoder med hög tillgänglighet kan läggas till på begäran. De fungerar som frekventa väntelägesnoder i redundanssyfte och kan fungera som skrivskyddade beräkningsnoder för att avlasta läsarbetsbelastningar när så önskas. Namngivna repliker är sekundära beräkningsnoder som är utformade för att möjliggöra olika ytterligare OLTP-utskalningsscenarier och för att bättre stödja HTAP-arbetsbelastningar (Hybrid Transactional and Analytical Processing). En geo-sekundär beräkningsnod kan läggas till i haveriberedskapssyfte och fungera som en skrivskyddad beräkningsnod för att avlasta läsarbetsbelastningar i en annan Azure-region.

I serverlös skalas den primära repliken och eventuella repliker med hög tillgänglighet eller namngivna repliker var och en oberoende autoskalning baserat på deras användning. Beräkningsintervallet för automatisk skalning för den primära repliken och eventuella namngivna repliker konfigureras oberoende av varandra. Autoskalningsintervallet för alla repliker med hög tillgänglighet ärvs från konfigurationen för automatisk skalning som anges av deras associerade primära replik eller namngivna replik.

Databasmotorn som körs på Hyperskala-beräkningsnoder är densamma som i andra Azure SQL Database-tjänstnivåer. När användare interagerar med databasmotorn på Hyperskala-beräkningsnoder är det ytområdes- och motorbeteende som stöds samma som i andra tjänstnivåer, förutom kända begränsningar.

Sidserver

Sidservrar är system som representerar en utskalad lagringsmotor. Varje sidserver ansvarar för en delmängd av sidorna i databasen. Varje sidserver har också en replik som behålls för redundans och tillgänglighet.

Jobbet för en sidserver är att hantera databassidor till beräkningsnoderna på begäran och att hålla sidorna uppdaterade när transaktionerna uppdaterar data. Sidservrar hålls uppdaterade genom att transaktionsloggposter spelas upp från loggtjänsten.

Sidservrar underhåller även omfattar SSD-baserade cacheminnen för att förbättra prestandan. Långsiktig lagring av datasidor sparas i Azure Storage för hållbarhet.

Loggtjänst

Loggtjänsten accepterar transaktionsloggposter som motsvarar dataändringar från den primära beräkningsrepliken. Sidservrar tar sedan emot loggposterna från loggtjänsten och tillämpar ändringarna på sina respektive datasektorer. Dessutom tar beräkningsrepliker emot loggposter från loggtjänsten och spelar bara upp ändringarna på sidor som redan finns i buffertpoolen eller den lokala RBPEX-cachen. Alla dataändringar från den primära beräkningsrepliken sprids via loggtjänsten till alla sekundära beräkningsrepliker och sidservrar.

Slutligen skickas transaktionsloggposter ut till långsiktig lagring i Azure Storage, som är en praktiskt taget oändlig lagringsplats. Den här mekanismen tar bort behovet av frekvent loggtrunkering. Vanliga orsaker till loggtillväxt, till exempel missade loggsäkerhetskopior eller långsam datareplikering till sekundära repliker, gäller inte för Hyperskala. Loggtjänsten har lokalt minne och SSD-cacheminnen för att påskynda åtkomsten till loggposter.

Azure Storage

Azure Storage innehåller alla datafiler i en databas. Sidservrar håller datafiler i Azure Storage uppdaterade. Den här lagringen används också för säkerhetskopiering och kan replikeras mellan regioner baserat på val av lagringsredundans.

Säkerhetskopior implementeras med hjälp av lagringsögonblicksbilder av datafiler. Återställningsåtgärder med ögonblicksbilder är snabba oavsett datastorlek. En databas kan återställas till valfri tidpunkt inom kvarhållningsperioden för säkerhetskopior.

Hyperskala stöder konfigurerbar lagringsredundans. När du skapar en Hyperskala-databas kan du välja mellan följande typer av Azure-standardlagring:

• Lokalt redundant lagring (LRS)
• Zonredundant lagring (ZRS)
• Geo-redundant lagring med läsbehörighet (RA-GRS)
• Skrivskyddad geozonredundant lagring (RA-GZRS)

Zonredundanta lagringsalternativ är tillgängliga i Azure-regioner med tillgänglighetszoner.

Det valda alternativet för lagringsredundans används under databasens livslängd för både redundans för datalagring och redundans för lagring av säkerhetskopior.

Relaterat innehåll

• Hyperskala tjänstnivå
• Azure SQL Database Vanliga frågor och svar om hyperskala
• Snabbstart: Skapa en Hyperskala-databas i Azure SQL Database
• Vanliga frågor och svar om Azure SQL Database Hyperskala med namnet replicas