Hyperskalatjänstnivå

  • Artikel
  • 14 minuter för att läsa

GÄLLER FÖR: Azure SQL Database

Azure SQL Database baseras på SQL Server Database Engine-arkitekturen som justeras för molnmiljön för att säkerställa 99,99 % tillgänglighet även i fall av infrastrukturfel. Det finns tre arkitekturmodeller som används i Azure SQL Database:

  • Generell användning/Standard
  • Hyperskala
  • Affärskritisk/Premium

Tjänstnivån Hyperskala i Azure SQL Database är den senaste tjänstnivån i köpmodellen baserad på vCore. Den här tjänstnivån är en mycket skalbar lagrings- och beräkningsprestandanivå som utnyttjar Azure-arkitekturen för att skala ut lagrings- och beräkningsresurserna för en Azure SQL Database betydligt utöver de gränser som är tillgängliga för Generell användning- och Affärskritisk-tjänstnivåer.

Anteckning

  • Mer information om Generell användning och Affärskritisk-tjänstnivåer i köpmodellen baserad på vCore finns i Generell användning och Affärskritisk tjänstnivåer. En jämförelse av köpmodellen baserad på vCore med köpmodellen baserad på DTU finns i Azure SQL Database köpmodeller och resurser.
  • Tjänstnivån Hyperskala är för närvarande endast tillgänglig för Azure SQL Database och inte Azure SQL Managed Instance.

Undersökning för att förbättra Azure SQL!

Vilka är funktionerna i Hyperskala?

Tjänstnivån Hyperskala i Azure SQL Database ger följande ytterligare funktioner:

  • Stöd för upp till 100 TB databasstorlek
  • Nästan omedelbara databassäkerhetskopior (baserat på filögonblicksbilder som lagras i Azure Blob Storage) oavsett storlek utan att I/H påverkar beräkningsresurser
  • Snabba databasåterställningar (baserat på filögonblicksbilder) i minuter i stället för timmar eller dagar (inte en storlek på dataåtgärden)
  • Högre övergripande prestanda på grund av högre transaktionsloggdataflöde och snabbare transaktionsgenomströmning oavsett datavolymer
  • Snabb utskalning – du kan etablera en eller flera skrivskyddade repliker för avlastning av läsarbetsbelastningen och för användning i hett vänteläge
  • Snabb uppskalning – du kan i konstant tid skala upp dina beräkningsresurser för att hantera tunga arbetsbelastningar när det behövs och sedan skala ned beräkningsresurserna igen när det inte behövs.

Tjänstnivån Hyperskala tar bort många av de praktiska gränser som traditionellt sett finns i molndatabaser. Om de flesta andra databaser begränsas av resurserna som är tillgängliga i en enda nod har databaser på tjänstnivån Hyperskala inga sådana begränsningar. Med den flexibla lagringsarkitekturen växer lagringsutrymmet efter behov. I själva verket skapas inte databaser i hyperskala med en definierad maxstorlek. En hyperskaladatabas växer efter behov och du debiteras bara för den kapacitet som du använder. För läsintensiva arbetsbelastningar ger tjänstnivån Hyperskala snabb utskalning genom att etablera ytterligare repliker efter behov för avlastning av läsarbetsbelastningar.

Dessutom är den tid som krävs för att skapa säkerhetskopior av databasen eller för att skala upp eller ned inte längre knuten till datavolymen i databasen. Databaser i hyperskala kan säkerhetskopieras praktiskt taget omedelbart. Du kan också skala en databas med tiotals terabyte uppåt eller nedåt på några minuter. Den här funktionen gör att du inte behöver oroa dig för att bli inrutad i dina första konfigurationsalternativ.

Mer information om beräkningsstorlekarna för tjänstnivån Hyperskala finns i Egenskaper för tjänstnivå.

Vem bör överväga tjänstnivån Hyperskala

Tjänstnivån Hyperskala är avsedd för de flesta företagsarbetsbelastningar eftersom den ger stor flexibilitet och höga prestanda med oberoende skalbara beräknings- och lagringsresurser. Med möjlighet att autoskala lagring upp till 100 TB är det ett bra alternativ för kunder som:

  • Ha stora databaser lokalt och vill modernisera sina program genom att flytta till molnet
  • Finns redan i molnet och begränsas av de maximala storleksbegränsningarna för databaser på andra tjänstnivåer (1–4 TB)
  • Ha mindre databaser, men kräver snabb vertikal och horisontell beräkningsskalning, höga prestanda, omedelbar säkerhetskopiering och snabb databasåterställning.

Tjänstnivån Hyperskala stöder ett brett utbud av SQL Server-arbetsbelastningar, från ren OLTP till ren analys, men den är främst optimerad för OLTP- och HTAP-arbetsbelastningar (hybrid transaction and analytical processing).

Viktigt

Elastiska pooler stöder inte tjänstnivån Hyperskala.

Prismodell för hyperskala

Tjänstnivån Hyperskala är endast tillgänglig i vCore-modellen. För att passa den nya arkitekturen skiljer sig prismodellen något från Generell användning eller Affärskritisk tjänstnivåer:

  • Beräkna:

    Enhetspriset för beräkning i Hyperskala är per replik. Priset Azure Hybrid-förmån tillämpas automatiskt på hög tillgänglighet och namngivna repliker. Vi skapar en primär replik och en sekundär replik med hög tillgänglighet per databas i hyperskala som standard. Användare kan justera det totala antalet repliker med hög tillgänglighet från 0 till 4, beroende på vilket serviceavtal som krävs.

  • Storage:

    Du behöver inte ange den maximala datastorleken när du konfigurerar en databas i hyperskala. På hyperskalanivån debiteras du för lagringen för databasen baserat på den faktiska allokeringen. Storage allokeras automatiskt mellan 40 GB och 100 TB i steg om 10 GB. Flera datafiler kan växa samtidigt om det behövs. En hyperskaladatabas skapas med en startstorlek på 10 GB och börjar växa med 10 GB var 10:e minut tills den når storleken 40 GB.

Mer information om priser för Hyperskala finns i Azure SQL Database prissättning

Arkitektur för distribuerade funktioner

Till skillnad från traditionella databasmotorer som har centraliserat alla datahanteringsfunktioner på en plats/process (även så kallade distribuerade databaser i produktion idag har flera kopior av en monolitisk datamotor), separerar en databas i hyperskala frågebearbetningsmotorn, där semantiken för olika datamotorer skiljer sig från de komponenter som tillhandahåller långsiktig lagring och hållbarhet för data. På så sätt kan lagringskapaciteten skalas ut så långt det behövs (det första målet är 100 TB). Hög tillgänglighet och namngivna repliker delar samma lagringskomponenter så ingen datakopiering krävs för att skapa en ny replik.

Följande diagram illustrerar de olika typerna av noder i en databas i hyperskala:

Arkitektur

En databas i hyperskala innehåller följande olika typer av komponenter:

Compute

Beräkningsnoden är den plats där relationsmotorn finns. Det är här som språk-, fråge- och transaktionsbearbetning sker. Alla användarinteraktioner med en hyperskala-databas sker via dessa beräkningsnoder. Beräkningsnoder har SSD-baserade cacheminnen (märkta RBPEX – Resilient Buffer Pool Extension i föregående diagram) för att minimera antalet nätverksresor som krävs för att hämta en sida med data. Det finns en primär beräkningsnod där alla skrivskyddade arbetsbelastningar och transaktioner bearbetas. Det finns en eller flera sekundära beräkningsnoder som fungerar som noder i hett vänteläge för redundans, samt fungerar som skrivskyddade beräkningsnoder för avlastning av läsarbetsbelastningar (om den här funktionen önskas).

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

Sidserver

Sidservrar är system som representerar en utskalade lagringsmotor. Varje sidserver ansvarar för en delmängd av sidorna i databasen. Varje sidserver styr nominellt antingen upp till 128 GB eller upp till 1 TB data. Inga data delas på mer än en sidserver (utanför sidserverrepliker som behålls för redundans och tillgänglighet). En sidservers uppgift är att servera databassidor till beräkningsnoderna på begäran och hålla sidorna uppdaterade när transaktioner uppdaterar data. Sidservrar hålls uppdaterade genom att spela upp transaktionsloggposter från loggtjänsten. Sidservrar upprätthåller även SSD-baserade cacheminnen för att förbättra prestandan. Långsiktig lagring av datasidor sparas i en Azure Storage för ytterligare tillförlitlighet.

Loggtjänst

Loggtjänsten accepterar transaktionsloggposter från den primära beräkningsrepliken, bevarar dem i ett beständigt cacheminne och vidarebefordrar loggposterna till resten av beräkningsreplikerna (så att de kan uppdatera sina cacheminnen) samt relevanta sidservrar, så att data kan uppdateras där. På så sätt sprids alla dataändringar från den primära beräkningsrepliken genom loggtjänsten till alla sekundära beräkningsrepliker och sidservrar. Slutligen skickas transaktionsloggposter ut till långsiktig lagring i Azure Storage, vilket är en praktiskt taget oändlig lagringsplats. Den här mekanismen tar bort behovet av frekvent logg trunkering. Loggtjänsten har också lokalt minne och SSD-cacheminnen för att påskynda åtkomsten till loggposter. Loggen på hyperskala är praktiskt taget oändlig med begränsningen att en enskild transaktion inte kan generera mer än 1 TB logg.

Azure-lagring

Azure Storage innehåller alla datafiler i en databas. Sidservrar håller datafilerna Azure Storage uppdaterade. Den här lagringen används för säkerhetskopiering, samt för replikering mellan Azure-regioner. Säkerhetskopior implementeras med hjälp av ögonblicksbilder av datafiler. Återställningsåtgärder som använder ögonblicksbilder är snabba oavsett datastorlek. Data kan återställas till valfri tidpunkt inom databasens kvarhållningsperiod för säkerhetskopior.

Säkerhetskopiering och återställning

Säkerhetskopior baseras på filögonblicksbilder och är därför nästan omedelbart. Storage och beräkningsseparation gör det möjligt att push-sänka säkerhetskopierings-/återställningsåtgärden till lagringslagret för att minska bearbetningsbelastningen på den primära beräkningsrepliken. Därför påverkar inte databassäkerhetskopiering den primära beräkningsnodens prestanda. Återställning till tidpunkt (PITR) görs på samma sätt genom att återgå till ögonblicksbilder av filer och därför inte är en storlek på dataåtgärden. Återställning av en hyperskaladatabas i samma Azure-region är en konstant tidsåtgärd, och databaser med flera terabyte kan återställas på några minuter i stället för timmar eller dagar. Att skapa nya databaser genom att återställa en befintlig säkerhetskopia drar också nytta av den här funktionen: det går att skapa databaskopior för utveckling eller testning, även för databaser med flera terabyte, på några minuter.

Geo-återställning av hyperskaladatabaser finns i Återställa en databas i hyperskala till en annan region.

Fördelar med skalning och prestanda

Med möjligheten att snabbt skapa ytterligare skrivskyddade beräkningsnoder möjliggör arkitekturen i Hyperskala betydande lässkalningsfunktioner och kan även frigöra den primära beräkningsnoden för att hantera fler skrivbegäranden. Beräkningsnoderna kan dessutom skalas upp/ned snabbt på grund av arkitekturen för delad lagring i arkitekturen för hyperskala.

Skapa en databas i hyperskala

En hyperskaladatabas kan skapas med hjälp Azure Portal, T-SQL, PowerShelleller CLI. Hyperskala-databaser är endast tillgängliga med köpmodellen baserad på vCore.

Följande T-SQL skapar en databas i hyperskala. Du måste ange både utgåvan och tjänstmålet i CREATE DATABASE -instruktionen. Se resursbegränsningarna för en lista över giltiga tjänstmål.

-- Create a Hyperscale Database
CREATE DATABASE [HyperscaleDB1] (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_4');
GO

Detta skapar en Hyperskala-databas på Gen5-maskinvara med fyra kärnor.

Uppgradera en befintlig databas till Hyperskala

Du kan flytta dina befintliga databaser Azure SQL Database till Hyperskala med hjälp av Azure Portal, T-SQL, PowerShelleller CLI. Just nu är detta en envägsmigrering. Du kan inte flytta databaser från Hyperskala till en annan tjänstnivå, förutom genom att exportera och importera data. För konceptbevis rekommenderar vi att du gör en kopia av dina produktionsdatabaser och migrerar kopian till Hyperskala. Migrering av en befintlig databas i Azure SQL Database till hyperskalenivån är en storlek på dataåtgärden.

Följande T-SQL flyttar en databas till tjänstnivån Hyperskala. Du måste ange både utgåvan och tjänstmålet i ALTER DATABASE -instruktionen.

-- Alter a database to make it a Hyperscale Database
ALTER DATABASE [DB2] MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_4');
GO

Anteckning

Om du vill flytta en databas som är en del av en geo-replikeringsrelation, antingen som primär eller sekundär, till Hyperskala, måste du stoppa replikeringen. Databaser i en redundansgrupp måste först tas bort från gruppen.

När en databas har flyttats till Hyperskala kan du skapa en ny geo-replik i Hyperskala för databasen. Geo-replikering för Hyperskala är en förhandsversion med vissa begränsningar.

Hög tillgänglighet för databaser i Hyperskala

Precis som på alla andra tjänstnivåer garanterar Hyperskala datatillförlitlighet för de intjänade transaktionerna oavsett tillgängligheten för beräkningsrepliker. Stilleståndstiden på grund av att den primära repliken blir otillgänglig beror på typen av redundans (planerad kontra oplanerad) och på förekomsten av minst en replik med hög tillgänglighet. I en planerad redundans (dvs. en underhållshändelse) skapar systemet antingen den nya primära repliken innan en redundans initieras eller använder en befintlig replik med hög tillgänglighet som redundansmål. I en oplanerad redundans (dvs. ett maskinvarufel på den primära repliken) använder systemet en replik med hög tillgänglighet som ett redundansmål om det finns en sådan, eller skapar en ny primär replik från poolen med tillgänglig beräkningskapacitet. I det senare fallet är stilleståndstiden längre på grund av de extra steg som krävs för att skapa den nya primära repliken.

För Serviceavtal för hyperskala, se SLA för Azure SQL Database.

Haveriberedskap för hyperskaladatabaser

Återställa en hyperskala-databas till en annan region

Om du behöver återställa en databas i hyperskala i Azure SQL Database till en annan region än den som den för närvarande finns i, som en del av en katastrofåterställningsåtgärd eller ett program för återställning, flytt eller någon annan orsak, är den primära metoden att göra en geo-återställning av databasen. Detta omfattar exakt samma steg som du använder för att återställa andra databaser i SQL Database till en annan region:

  1. Skapa en server i målregionen om du inte redan har en lämplig server där. Den här servern ska ägas av samma prenumeration som den ursprungliga servern (källa).
  2. Följ anvisningarna i avsnittet geo-återställning på sidan om hur du återställer en databas i Azure SQL Database från automatiska säkerhetskopior.

Anteckning

Eftersom källan och målet finns i separata regioner kan databasen inte dela ögonblicksbildlagring med källdatabasen som i icke-geo-återställningar, som slutförs snabbt oavsett databasstorlek. När det gäller geo-återställning av en databas i hyperskala är det en storlek på dataåtgärden, även om målet finns i den parkopplade regionen för den geo-replikerade lagringen. Därför tar en geo-återställning tid i proportion till storleken på databasen som återställs. Om målet finns i den parkopplade regionen kommer dataöverföringen att ske inom en region, vilket är betydligt snabbare än en dataöverföring mellan regioner, men det kommer fortfarande att vara en storlek på dataåtgärden.

Tillgängliga regioner

Nivån Azure SQL Database Hyperskala är aktiverad i de allra flesta Azure-regioner. Om du vill skapa en databas i hyperskala i en region där Hyperskala inte är aktiverat som standard kan du skicka en registrering-begäran via Azure Portal. Instruktioner finns i Begär kvotökningar för Azure SQL Database anvisningar. Använd följande riktlinjer när du skickar din begäran:

  • Använd typen Regionsåtkomst SQL Database kvottyp.
  • I beskrivningen lägger du till beräknings-SKU/totalt antal kärnor, inklusive hög tillgänglighet och namngivna repliker, och anger att du begär hyperskalakapacitet.
  • Ange också en projektion av den totala storleken för alla databaser över tid i TB.

Kända begränsningar

Det här är de aktuella begränsningarna för tjänstnivån Hyperskala från och med GA. Vi arbetar aktivt med att ta bort så många av dessa begränsningar som möjligt.

Problem Beskrivning
Fönstret Hantera säkerhetskopieringar för en server visar inte hyperskaladatabaser. Dessa filtreras från vyn. Hyperskala har en separat metod för att hantera säkerhetskopior, så Long-Term kvarhållning av säkerhetskopior och kvarhållning av säkerhetskopior från tidpunkt gäller inte. Därför visas inte hyperskaladatabaser i fönstret Hantera säkerhetskopiering.

För databaser som migrerats till Hyperskala från Azure SQL Database andra tjänstnivåer sparas säkerhetskopior före migreringen under kvarhållningsperioden för säkerhetskopior av källdatabasen. Dessa säkerhetskopior kan användas för att återställa källdatabasen till en tidpunkt före migreringen.
Återställning från tidpunkt En databas som inte är hyperskala kan inte återställas som en databas i hyperskala och en databas i hyperskala kan inte återställas som en icke-hyperskaladatabas. För en icke-Hyperskala-databas som har migrerats till Hyperskala genom att ändra dess tjänstnivå, kan du återställa till en tidpunkt innan migreringen och inom kvarhållningsperioden för säkerhetskopior för databasen stöds programmatiskt. Den återställda databasen kommer inte att vara hyperskala.
När du Azure SQL Database en tjänstnivå till Hyperskala misslyckas åtgärden om databasen har datafiler som är större än 1 TB I vissa fall kan det vara möjligt att lösa det här problemet genom att minska de stora filerna till mindre än 1 TB innan du försöker ändra tjänstnivån till Hyperskala. Använd följande fråga för att fastställa den aktuella storleken på databasfilerna. SELECT file_id, name AS file_name, size * 8. / 1024 / 1024 AS file_size_GB FROM sys.database_files WHERE type_desc = 'ROWS';
SQL-hanterad instans Azure SQL Managed Instance stöds inte för närvarande med hyperskaladatabaser.
Elastiska pooler Elastiska pooler stöds för närvarande inte med Hyperskala.
Migrering till Hyperskala är för närvarande en envägsåtgärd När en databas har migrerats till Hyperskala kan den inte migreras direkt till en tjänstnivå som inte är hyperskala. För närvarande är det enda sättet att migrera en databas från Hyperskala till icke-Hyperskala att exportera/importera med hjälp av en bacpac-fil eller andra dataflyttningstekniker (masskopiering, Azure Data Factory, Azure Databricks, SSIS osv.) Bacpac-export/-import från Azure Portal, från PowerShell med hjälp av New-AzSqlDatabaseExport eller New-AzSqlDatabaseImport, från Azure CLI med az sql db export och az sql db importoch från REST API stöds inte. Bacpac-import/-export för mindre Hyperskala-databaser (upp till 200 GB) stöds med SSMS och SqlPackage version 18.4 och senare. För större databaser kan bacpac-export/-import ta lång tid och kan misslyckas av olika orsaker.
Migrering av databaser med In-Memory OLTP-objekt Hyperskala stöder en delmängd In-Memory OLTP-objekt, inklusive minnesoptimerade tabelltyper, tabellvariabler och inbyggda kompilerade moduler. Men om det finns In-Memory OLTP-objekt i databasen som migreras, stöds inte migrering från Premium och Affärskritisk-tjänstnivåer till Hyperskala. För att migrera en sådan databas till Hyperskala måste alla In-Memory OLTP-objekt och deras beroenden tas bort. När databasen har migrerats kan dessa objekt återskapas. Varaktiga och icke-varaktiga minnesoptimerade tabeller stöds inte för närvarande i Hyperskala och måste ändras till disktabeller.
Geo-replikering Geo-replikering i Hyperskala är nu i offentlig förhandsversion.
Intelligenta databasfunktioner Med undantag för alternativet "Force Plan" stöds inte alla andra alternativ för automatisk justering i Hyperskala än: alternativ kan verka vara aktiverade, men det görs inga rekommendationer eller åtgärder.
Information om frågeprestanda Frågeprestanda Insights stöds för närvarande inte för hyperskaladatabaser.
Krymp databas DBCC SHRINKDATABASE eller DBCC SHRINKFILE stöds för närvarande inte för hyperskaladatabaser.
Databasintegritetskontroll DBCC CHECKDB stöds för närvarande inte för hyperskaladatabaser. DBCC CHECKTABLE (Tabellnamn) MED TABLOCK och DBCC CHECKFILEGROUP MED TABLOCK kan användas som en lösning. Se Dataintegritet i Azure SQL Database för information om hantering av dataintegritet i Azure SQL Database.
Elastiska jobb Användning av en hyperskaladatabas som jobbdatabas stöds inte. Elastiska jobb kan dock rikta in sig på Hyperskala-databaser på samma sätt som andra Azure SQL databaser.

Nästa steg