Hyperscale-servicelaag

Van toepassing op: Azure SQL Database

Azure SQL Database is gebaseerd op sql Server Database Engine-architectuur die is aangepast voor de cloudomgeving om hoge beschikbaarheid te garanderen, zelfs in geval van infrastructuurfouten. Er zijn drie opties voor de servicelaag in het vCore-aankoopmodel voor Azure SQL Database:

• Algemeen gebruik
• Bedrijfskritiek
• Hyperscale

De Hyperscale-servicelaag is geschikt voor alle workloadtypen. De cloudeigen architectuur biedt onafhankelijk schaalbare compute en opslag ter ondersteuning van de breedste verscheidenheid aan traditionele en moderne toepassingen. Reken- en opslagresources in Hyperscale overschrijden aanzienlijk de resources die beschikbaar zijn in de lagen Algemeen gebruik en Bedrijfskritiek.

Notitie

• Zie Algemeen gebruik en Bedrijfskritiek servicelagen voor meer informatie over de servicelagen Algemeen gebruik en Bedrijfskritiek servicelagen in het aankoopmodel op basis van vCore. Voor een vergelijking van het aankoopmodel op basis van vCore met het aankoopmodel op basis van DTU, raadpleegt u VCore- en DTU-aankoopmodellen van Azure SQL Database vergelijken.
• De Hyperscale-servicelaag is momenteel alleen beschikbaar voor Azure SQL Database en niet voor Azure SQL Managed Instance.

Wat zijn de Hyperscale-mogelijkheden?

De Hyperscale-servicelaag in Azure SQL Database biedt de volgende aanvullende mogelijkheden:

• Snel omhoog schalen: u kunt, in constante tijd, uw rekenresources omhoog schalen om zo nodig zware werkbelastingen te verwerken en vervolgens de rekenresources weer omlaag te schalen wanneer dat niet nodig is.
• Snelle uitschalen: u kunt een of meer alleen-lezen replica's inrichten voor het offloaden van uw leesworkload en voor gebruik als hot-stand-bys.
• Automatisch omhoog schalen, omlaag schalen en facturering voor rekenkracht op basis van gebruik met serverloze rekenkracht.
• Geoptimaliseerde prijs/prestaties voor een groep Hyperscale-databases met verschillende resourcevereisten met elastische pools (in preview).
• Automatisch schalen van opslag met ondersteuning voor maximaal 100 TB aan database- of elastische poolgrootte.
• Hogere algehele prestaties vanwege een hogere doorvoer van transactielogboeken en snellere doorvoer van transacties, ongeacht gegevensvolumes.
• Snelle databaseback-ups (op basis van momentopnamen van bestanden) ongeacht de grootte zonder I/O-invloed op rekenresources.
• Snelle database herstelt of kopieert (op basis van momentopnamen van bestanden) in minuten in plaats van uren of dagen.

De Hyperscale-servicelaag verwijdert veel van de praktische limieten die traditioneel worden gezien in clouddatabases. Wanneer de meeste andere databases worden beperkt door de resources die beschikbaar zijn in één knooppunt, hebben databases in de Hyperscale-servicelaag dergelijke limieten niet. Met de flexibele opslagarchitectuur groeit de opslag naar behoefte. Hyperscale-databases worden zelfs niet gemaakt met een gedefinieerde maximale grootte. Een Hyperscale-database groeit naar behoefte en u wordt alleen gefactureerd voor de toegewezen opslagcapaciteit. Voor leesintensieve workloads biedt de Hyperscale-servicelaag snelle uitschaling door extra replica's in te richten indien nodig voor het offloaden van leesworkloads.

Daarnaast is de tijd die nodig is om databaseback-ups te maken of omhoog of omlaag te schalen niet meer gekoppeld aan het volume aan gegevens in de database. Er wordt vrijwel onmiddellijk een back-up gemaakt van Hyperscale-databases. U kunt een database in de tientallen terabytes ook binnen enkele minuten omhoog of omlaag schalen in de ingerichte rekenlaag of serverloos gebruiken om de berekening automatisch te schalen. Deze mogelijkheid zorgt ervoor dat u zich geen zorgen hoeft te maken over het gebruik van uw eerste configuratiekeuzes.

Zie Servicelaagkenmerken voor meer informatie over de rekengrootten voor de Hyperscale-servicelaag.

Wie moet rekening houden met de Hyperscale-servicelaag

De Hyperscale-servicelaag is bedoeld voor alle klanten die hogere prestaties en beschikbaarheid nodig hebben, snelle back-up en herstel, en/of snelle opslag- en rekenschaalbaarheid. Dit omvat klanten die overstappen naar de cloud om hun toepassingen te moderniseren en klanten die al andere servicelagen gebruiken in Azure SQL Database. De Hyperscale-servicelaag ondersteunt een breed scala aan databaseworkloads, van pure OLTP tot pure analyse. Het is geoptimaliseerd voor OLTP- en HTAP-workloads (Hybrid Transaction and Analytical Processing).

Notitie

Elastische pools voor Hyperscale zijn momenteel beschikbaar als preview-versie.

Prijsmodel voor Hyperscale

Notitie

Er zijn vereenvoudigde prijzen voor Azure SQL Database Hyperscale aangekomen. Bekijk de nieuwe prijscategorie voor de aankondiging van Azure SQL Database Hyperscale en zie Azure SQL Database Hyperscale – lagere, vereenvoudigde prijzen! voor meer informatie over prijswijziging.

De Hyperscale-servicelaag is alleen beschikbaar in het vCore-model. Als u zich wilt aansluiten bij de nieuwe architectuur, verschilt het prijsmodel enigszins van algemeen gebruik of Bedrijfskritiek servicelagen:

• Ingerichte rekenkracht:

  De prijs van de Hyperscale-rekeneenheid is per replica. Gebruikers kunnen het totale aantal secundaire replica's met hoge beschikbaarheid aanpassen van 0 tot 4, afhankelijk van de beschikbaarheids- en schaalbaarheidsvereisten, en maximaal 30 benoemde replica's maken ter ondersteuning van een verscheidenheid aan workloads voor opschaling voor leesbewerking.

• Serverloze berekening:

  Serverloze compute-facturering is gebaseerd op gebruik. Zie de serverloze rekenlaag voor Azure SQL Database voor meer informatie.

• Opslag:

  U hoeft de maximale gegevensgrootte niet op te geven bij het configureren van een Hyperscale-database. In de Hyperscale-laag worden kosten in rekening gebracht voor opslag voor uw database op basis van de werkelijke toewijzing. Opslag wordt automatisch toegewezen tussen 10 GB en 100 TB en neemt indien nodig toe in stappen van 10 GB.

Zie Prijzen van Azure SQL Database voor meer informatie over prijzen voor Hyperscale

Resourcelimieten vergelijken

De servicelagen op basis van vCore zijn gedifferentieerd op basis van databasebeschikbaarheid, opslagtype, prestaties en maximale opslaggrootte. Deze verschillen worden beschreven in de volgende tabel:

ㅤ	Algemeen doel	Bedrijfskritiek	Hyperscale
Het beste voor	Biedt budgetgerichte, evenwichtige reken- en opslagopties.	OLTP-toepassingen met een hoge transactiesnelheid en lage I/O-latentie. Biedt een hoge tolerantie voor storingen en snelle failovers met behulp van meerdere hot standby-replica's.	De meest uiteenlopende workloads. Automatisch schalen van opslaggrootte tot 100 TB, snel verticaal en horizontaal schalen van rekenkracht, snel databaseherstel.
Rekenkracht	2 tot 128 vCores	2 tot 128 vCores	2 tot 128 vCores 1
Opslagtype	Premium externe opslag (per exemplaar)	Super snelle lokale SSD-opslag (per exemplaar)	Losgekoppelde opslag met lokale SSD-cache (per rekenreplica)
Opslaggrootte1	1 GB – 4 TB	1 GB – 4 TB	10 GB – 100 TB
IOPS	320 IOPS per vCore met maximaal 16.000 IOPS	4.000 IOPS per vCore met maximaal 327.680 IOPS	327.680 IOPS met maximale lokale SSD Hyperscale is een architectuur met meerdere lagen met caching op meerdere niveaus. Effectieve IOPS is afhankelijk van de workload.
Geheugen/vCore	5,1 GB	5,1 GB	5,1 GB of 10,2 GB
Beschikbaarheid	Eén replica, geen uitschaling van leesbewerkingen, zone-redundante hoge beschikbaarheid	Drie replica's, één uitgeschaalde, zone-redundante hoge beschikbaarheid	Meerdere replica's, maximaal vier uitschalen van leesbewerkingen, zone-redundante hoge beschikbaarheid
Back-ups	Een keuze uit lokaal redundante opslag (LRS), zone-redundant (ZRS) of geografisch redundante opslag (GRS) Retentie van 1-35 dagen (standaard zeven dagen), met maximaal 10 jaar langetermijnretentie beschikbaar	Een keuze uit lokaal redundante opslag (LRS), zone-redundant (ZRS) of geografisch redundante opslag (GRS) Retentie van 1-35 dagen (standaard zeven dagen), met maximaal 10 jaar langetermijnretentie beschikbaar	Een keuze uit lokaal redundante opslag (LRS), zone-redundant (ZRS) of geografisch redundante opslag (GRS) Retentie van 1-35 dagen (standaard zeven dagen), met maximaal 10 jaar langetermijnretentie beschikbaar
Prijzen/facturering	Er worden kosten in rekening gebracht voor vCore, gereserveerde opslag en back-upopslag . IOPS worden niet in rekening gebracht.	Er worden kosten in rekening gebracht voor vCore, gereserveerde opslag en back-upopslag . IOPS worden niet in rekening gebracht.	vCore voor elke replica, toegewezen gegevensopslag en back-upopslag worden in rekening gebracht. IOPS worden niet in rekening gebracht.
Kortingsmodellen	Gereserveerde exemplaren Azure Hybrid Benefit (niet beschikbaar voor dev/test-abonnementen) Enterprise - en Pay-As-You-Go Dev/Test-abonnementen	Gereserveerde exemplaren Azure Hybrid Benefit (niet beschikbaar voor dev/test-abonnementen) Enterprise - en Pay-As-You-Go Dev/Test-abonnementen	Gereserveerde exemplaren Azure Hybrid Benefit (niet beschikbaar voor dev/test-abonnementen) 2 Enterprise - en Pay-As-You-Go Dev/Test-abonnementen

¹Overzicht van elastische Hyperscale-pools in Azure SQL Database is momenteel beschikbaar als preview-versie.
² Vereenvoudigde prijzen voor SQL Database Hyperscale binnenkort beschikbaar. Raadpleeg de blog over prijzen van Hyperscale voor meer informatie.

Rekenresources

Hardwareconfiguratie	CPU	Geheugen
Standard-serie (Gen5)	Ingerichte rekenkracht - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milaan) processors - Maximaal 80 vCores inrichten (hyperthreaded) Serverloze compute - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milaan) processors - Automatisch schalen tot 80 vCores (hyperthreaded) - De verhouding tussen geheugen en vCore past zich dynamisch aan het geheugen- en CPU-gebruik aan op basis van de vraag naar werkbelasting en kan zo hoog zijn als 24 GB per vCore. Op een bepaald moment kan een workload bijvoorbeeld worden gebruikt en gefactureerd voor 240 GB geheugen en slechts 10 vCores.	Ingerichte rekenkracht - 5,1 GB per vCore - Maximaal 625 GB inrichten Serverloze compute - Automatisch schalen tot 24 GB per vCore - Automatisch schalen tot maximaal 240 GB
Premium-series	- Intel® Xeon Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milaan) processors - Maximaal 128 vCores inrichten (hyperthreaded)	- 5,1 GB per vCore
Geoptimaliseerd geheugen uit de Premium-serie	- Intel® Xeon Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milaan) processors - Maximaal 80 vCores inrichten (hyperthreaded)	- 10,2 GB per vCore

¹ In de sys.dm_user_db_resource_governance dynamische beheerweergave wordt hardwaregeneratie voor databases met Intel® SP-8160 -processors (Skylake) weergegeven als Gen6, hardwaregeneratie voor databases met Intel® 8272CL (Cascade Lake) wordt weergegeven als Gen7 en hardwaregeneratie voor databases met Intel Xeon® Platinum 8370C (Ice Lake) of AMD® EPYC® 7763v (Milaan) als Gen8. Voor een bepaalde rekenkracht en hardwareconfiguratie zijn resourcelimieten hetzelfde, ongeacht het CPU-type. Zie resourcelimieten voor individuele databases en elastische pools voor meer informatie.

Serverloos wordt alleen ondersteund op Standard-serie (Gen5) hardware.

Architectuur voor gedistribueerde functies

Hyperscale scheidt de queryverwerkingsengine van de onderdelen die langetermijnopslag en duurzaamheid bieden voor de gegevens. Met deze architectuur kunt u de opslagcapaciteit zo veel mogelijk schalen (het eerste doel is 100 TB) en de mogelijkheid om rekenresources snel te schalen.

In het volgende diagram ziet u de functionele Hyperscale-architectuur:

Meer informatie over de architectuur van gedistribueerde Hyperscale-functies.

Voordelen van schaal en prestaties

Met de mogelijkheid om snel extra alleen-lezen rekenknooppunten op te zetten, biedt de Hyperscale-architectuur aanzienlijke mogelijkheden voor leesschaal en kan het primaire rekenknooppunt ook vrijmaken voor meer schrijfaanvragen. Bovendien kunnen de rekenknooppunten snel omhoog/omlaag worden geschaald vanwege de architectuur voor gedeelde opslag van de Hyperscale-architectuur. Alleen-lezen rekenknooppunten in Hyperscale zijn ook beschikbaar in de serverloze rekenlaag, waarmee berekeningen automatisch worden geschaald op basis van de vraag naar workloads.

Hyperscale-databases maken en beheren

U kunt Hyperscale-databases maken en beheren met behulp van Azure Portal, Transact-SQL, PowerShell en de Azure CLI. Zie Quickstart: Een Hyperscale-database maken voor meer informatie.

Bewerking	DETAILS	Meer informatie
Een Hyperscale-database maken	Hyperscale-databases zijn alleen beschikbaar met behulp van het aankoopmodel op basis van vCore.	Voorbeelden voor het maken van een Hyperscale-database vindt u in quickstart: Een Hyperscale-database maken in Azure SQL Database.
Een bestaande database upgraden naar Hyperscale	Het migreren van een bestaande database in Azure SQL Database naar de Hyperscale-laag is een grootte van de gegevensbewerking.	Meer informatie over het migreren van een bestaande database naar Hyperscale.
Een Hyperscale-database omkeren naar de servicelaag Algemeen gebruik	Als u eerder een bestaande Azure SQL Database naar de Hyperscale-servicelaag hebt gemigreerd, kunt u de database binnen 45 dagen na de oorspronkelijke migratie naar Hyperscale omkeren naar de servicelaag Algemeen gebruik. Als u de database wilt migreren naar een andere servicelaag, zoals Bedrijfskritiek, moet u eerst omkeren naar de servicelaag Algemeen gebruik en vervolgens de servicelaag wijzigen.	Meer informatie over het omkeren van hyperscale, inclusief de beperkingen voor omgekeerde migratie.

Hoge beschikbaarheid van databases in Hyperscale

Net als in alle andere servicelagen garandeert Hyperscale de duurzaamheid van gegevens voor doorgevoerde transacties, ongeacht de beschikbaarheid van rekenreplica's. De mate van downtime omdat de primaire replica niet beschikbaar is, is afhankelijk van het type failover (gepland versus ongepland), of zoneredundantie is geconfigureerd en op de aanwezigheid van ten minste één replica met hoge beschikbaarheid. In een geplande failover (zoals een onderhoudsgebeurtenis) maakt het systeem de nieuwe primaire replica voordat een failover wordt gestart of gebruikt een bestaande replica met hoge beschikbaarheid als failoverdoel. In een niet-geplande failover (zoals een hardwarefout op de primaire replica), gebruikt het systeem een replica met hoge beschikbaarheid als failoverdoel als er een bestaat of maakt een nieuwe primaire replica uit de pool met beschikbare rekencapaciteit. In het laatste geval duurt de downtime langer vanwege extra stappen die nodig zijn om de nieuwe primaire replica te maken.

U kunt een onderhoudsvenster kiezen waarmee u impactvolle onderhoudsevenementen voorspelbaar en minder verstorend kunt maken voor uw workload.

Zie SLA voor Azure SQL Database voor Hyperscale SLA.

Back-up maken en herstellen

Back-up- en herstelbewerkingen voor Hyperscale-databases zijn gebaseerd op bestandsmomentopnamen. Hierdoor kunnen deze bewerkingen bijna onmiddellijk worden uitgevoerd. Omdat de Hyperscale-architectuur gebruikmaakt van de opslaglaag voor back-up en herstel, worden de verwerkingsbelasting en prestatie-impact op rekenreplica's aanzienlijk verminderd. Meer informatie over Hyperscale-back-ups en opslagredundantie.

Herstel na noodgevallen voor Hyperscale-databases

Als u een Hyperscale-database in Azure SQL Database wilt herstellen naar een andere regio dan de regio waarin deze momenteel wordt gehost, als onderdeel van een noodherstelbewerking of drill, relocatie of een andere reden, is de primaire methode het uitvoeren van een geo-herstel van de database. Geo-herstel is alleen beschikbaar wanneer geografisch redundante opslag (RA-GRS) is gekozen voor opslagredundantie.

Meer informatie over het herstellen van een Hyperscale-database naar een andere regio.

Bekende beperkingen

Dit zijn de huidige beperkingen van de Hyperscale-servicelaag. We werken er actief aan om zoveel mogelijk van deze beperkingen te verwijderen.

Probleem	Beschrijving
Database herstellen vanuit andere servicelagen	Een niet-Hyperscale-database kan niet worden hersteld als een Hyperscale-database en een Hyperscale-database kan niet worden hersteld als een niet-Hyperscale-database. Voor databases die vanuit andere Azure SQL Database-servicelagen naar Hyperscale zijn gemigreerd, worden back-ups vóór de migratie bewaard voor de duur van de bewaarperiode voor back-ups van de brondatabase, inclusief langetermijnretentiebeleid. Het herstellen van een back-up vóór de migratie binnen de bewaarperiode van de back-up van de database wordt ondersteund via de opdrachtregel. U kunt deze back-ups herstellen naar een servicelaag die niet van Hyperscale is.
Elastische pools	Elastische pools zijn nu beschikbaar als preview-versie.
Migratie van databases met OLTP-objecten in het geheugen	Hyperscale ondersteunt een subset van OLTP-objecten in het geheugen, waaronder tabeltypen, tabelvariabelen en systeemeigen gecompileerde modules. Wanneer er echter OLTP-objecten in het geheugen aanwezig zijn in de database die wordt gemigreerd, wordt migratie van Premium- en Bedrijfskritiek-servicelagen naar Hyperscale niet ondersteund. Als u een dergelijke database wilt migreren naar Hyperscale, moeten alle OLTP-objecten in het geheugen en de bijbehorende afhankelijkheden worden verwijderd. Nadat de database is gemigreerd, kunnen deze objecten opnieuw worden gemaakt. Duurzame en niet-duurzame tabellen die zijn geoptimaliseerd voor geheugen worden momenteel niet ondersteund in Hyperscale en moeten worden gewijzigd in schijftabellen.
Database verkleinen	DBCC SHRINKDATABASE, DBCC SHRINKFILE of het instellen van AUTO_SHRINK op databaseniveau, worden momenteel niet ondersteund voor Hyperscale-databases.
Controle van databaseintegriteit	DBCC CHECKDB wordt momenteel niet ondersteund voor Hyperscale-databases. DBCC CHECKTABLE ('TableName') MET TABLOCK en DBCC CHECKFILEGROUP WITH TABLOCK kan worden gebruikt als tijdelijke oplossing. Zie Gegevensintegriteit in Azure SQL Database voor meer informatie over gegevensintegriteitsbeheer in Azure SQL Database.
Elastische taken	Het gebruik van een Hyperscale-database omdat de taakdatabase niet wordt ondersteund. Elastische taken kunnen hyperscale-databases echter op dezelfde manier richten als elke andere database in Azure SQL Database.
Gegevens synchroniseren	Het gebruik van een Hyperscale-database als hub- of synchronisatiemetagegevensdatabase wordt niet ondersteund. Een Hyperscale-database kan een liddatabase zijn in een Data Sync-topologie.
Hardware van de Hyperscale-servicelaag premium-serie	Hardware uit de Premium-serie en voor geheugen geoptimaliseerde premium-serie biedt momenteel geen ondersteuning voor: - Zoneredundantie - Serverloze rekenlaag.
Regionale beschikbaarheid	Hyperscale-servicelaag premium-serie en premium-serie geoptimaliseerde hardware is beschikbaar in beperkte Azure-regio's. Zie de beschikbaarheid van de Hyperscale Premium-serie voor een lijst.

Gerelateerde inhoud

• Veelgestelde vragen over Hyperscale
• Aankoopmodellen op basis van vCore en DTU van Azure SQL Database vergelijken
• Resourcebeheer in Azure SQL Database
• Resourcelimieten voor individuele databases met gebruikmaking van het vCore-aankoopmodel
• Vergelijking van functies: Azure SQL Database en Azure SQL Managed Instance
• Architectuur van gedistribueerde Hyperscale-functies
• Een Hyperscale-database beheren