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 een beschikbaarheid van 99,99% te garanderen, zelfs in het geval van infrastructuurfouten. Er zijn drie architectuurmodellen die worden gebruikt in Azure SQL Database:

  • Algemeen/Standard
  • Hyperscale
  • Bedrijfskritiek/Premium

De Hyperscale-servicelaag in Azure SQL Database is de nieuwste servicelaag in het aankoopmodel op basis van vCore. Deze servicelaag is een zeer schaalbare opslag- en rekenprestatielaag die gebruik maakt van de Azure-architectuur om de opslag- en rekenresources voor een Azure SQL Database aanzienlijk uit te schalen buiten de limieten die beschikbaar zijn voor de Algemeen- en Bedrijfskritiek-servicelagen.

Notitie

  • Zie Servicelagen voor Algemeen en Bedrijfskritiek in het aankoopmodel op basis van vCore voor meer informatie over Algemeen- en Bedrijfskritiek-servicelagen. Zie aankoopmodellen en resources voor een vergelijking van het aankoopmodel op basis van vCore met het aankoopmodel op basis van DTU Azure SQL Database aankoopmodellen en -resources.
  • 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 extra mogelijkheden:

  • Ondersteuning voor maximaal 100 TB aan databasegrootte
  • Bijna onmiddellijk back-ups van databases (op basis van momentopnamen van bestanden die zijn opgeslagen in Azure Blob Storage), ongeacht de grootte zonder I/O-impact op rekenbronnen
  • Snelle databaseherstelbewerkingen (op basis van momentopnamen van bestanden) in minuten in plaats van uren of dagen (geen gegevensbewerking)
  • Hogere algemene prestaties vanwege een hogere logboekdoorvoer en snellere doorvoertijden voor transacties, ongeacht gegevensvolumes
  • Snel uitschalen: u kunt een of meer alleen-lezen replica's inrichten voor het offloaden van uw leesworkload en voor gebruik als hot-stand-by
  • Snel omhoog schalen: u kunt uw rekenbronnen in constante tijd omhoog schalen voor zware werkbelastingen wanneer dat nodig is. Vervolgens kunt u de rekenbronnen weer omlaag schalen wanneer dat niet nodig is.

De servicelaag Hyperscale verwijdert veel van de praktische limieten die traditioneel in clouddatabases worden gezien. Waar de meeste andere databases worden beperkt door de resources die beschikbaar zijn in één knooppunt, gelden dergelijke limieten niet voor databases in de Hyperscale-servicelaag. Dankzij de flexibele opslagarchitectuur groeit de opslag naar behoefte. Hyperscale-databases worden in feite niet gemaakt met een gedefinieerde maximale grootte. Een Hyperscale-database groeit naar behoefte en u wordt alleen gefactureerd voor de capaciteit die u gebruikt. Voor leesintensieve werkbelastingen biedt de Hyperscale-servicelaag snelle uitschaaling door zo nodig extra replica's in terichten voor het offloaden van leesworkloads.

Daarnaast is de tijd die nodig is om databaseback-ups te maken of omhoog of omlaag te schalen niet langer gekoppeld aan de hoeveelheid gegevens in de database. Hyperscale-databases kunnen vrijwel onmiddellijk worden geback-upt. U kunt een database in enkele minuten ook in tientallen terabytes omhoog of omlaag schalen. Met deze mogelijkheid bent u niet meer bezorgd als u zich zorgen maakt over uw eerste configuratiekeuzes.

Zie Kenmerken van servicelagen voor meer informatie over de rekengrootten voor de Hyperscale-servicelaag.

Wie moet rekening houden met de Hyperscale-servicelaag

De Hyperscale-servicelaag is bedoeld voor de meeste zakelijke workloads, omdat deze grote flexibiliteit en hoge prestaties biedt met onafhankelijk schaalbare reken- en opslagresources. Met de mogelijkheid om de opslag automatisch te schalen tot 100 TB, is het een uitstekende keuze voor klanten die:

  • Grote databases on-premises hebben en hun toepassingen willen moderniseren door over te gaan naar de cloud
  • Zijn al in de cloud en worden beperkt door de maximale databasegroottebeperkingen van andere servicelagen (1-4 TB)
  • Kleinere databases hebben, maar snelle verticale en horizontale schaalbaarheid van rekenkracht, hoge prestaties, directe back-up en snel databaseherstel vereisen.

De servicelaag Hyperscale ondersteunt een breed scala aan SQL Server-workloads, van pure OLTP tot pure analyse, maar is voornamelijk geoptimaliseerd voor OLTP- en HTAP-workloads (hybride transactie en analytische verwerking).

Belangrijk

Elastische pools bieden geen ondersteuning voor de Hyperscale-servicelaag.

Hyperscale-prijsmodel

De Hyperscale-servicelaag is alleen beschikbaar in het vCore-model. In lijn met de nieuwe architectuur verschilt het prijsmodel enigszins van Algemeen of Bedrijfskritiek servicelagen:

  • Compute:

    De prijs van de Hyperscale-rekeneenheid is per replica. De Azure Hybrid Benefit wordt automatisch toegepast op hoge beschikbaarheid en benoemde replica's. Standaard maken we een primaire replica en één secundaire replica met hoge beschikbaarheid per Hyperscale-database. Gebruikers kunnen het totale aantal replica's met hoge beschikbaarheid aanpassen van 0-4, afhankelijk van de benodigde SLA.

  • Storage:

    U hoeft niet de maximale gegevensgrootte op te geven bij het configureren van een Hyperscale-database. In de hyperscale-laag worden opslag voor uw database in rekening gebracht op basis van de werkelijke toewijzing. Storage wordt automatisch toegewezen tussen 40 GB en 100 TB, in stappen van 10 GB. Indien nodig kunnen er meerdere gegevensbestanden tegelijk groeien. Een Hyperscale-database wordt gemaakt met een begingrootte van 10 GB en begint elke 10 minuten met 10 GB te groeien totdat deze de grootte van 40 GB bereikt.

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

Architectuur van gedistribueerde functies

In tegenstelling tot traditionele database-engines die alle functies voor gegevensbeheer op één locatie/proces hebben gecentraliseerd (zelfs als gedistribueerde databases in productie tegenwoordig meerdere kopieën van een monolithische gegevensen engine hebben), scheidt een Hyperscale-database de engine voor het verwerken van query's, waarbij de semantiek van verschillende gegevensent engines afwijkt van de onderdelen die langetermijnopslag en duurzaamheid voor de gegevens bieden. Op deze manier kan de opslagcapaciteit naar behoefte soepel worden geschaald (de eerste doel is 100 TB). Hoge beschikbaarheid en benoemde replica's delen dezelfde opslagonderdelen, zodat er geen gegevenskopie hoeft te worden gemaakt om een nieuwe replica te maken.

In het volgende diagram ziet u de verschillende typen knooppunten in een Hyperscale-database:

architectuur

Een Hyperscale-database bevat de volgende verschillende typen onderdelen:

Compute

Het reken-knooppunt is de plek waar de relationele engine zich bebouwt. Hier vinden taal-, query- en transactieverwerking plaats. Alle gebruikersinteracties met een Hyperscale-database vinden via deze rekenknooppunten plaatsvinden. Rekenknooppunten hebben ssd-caches (in het voorgaande diagram gelabeld als RBPEX - Resilient Buffer Pool Extension) om het aantal netwerkritten te minimaliseren dat nodig is om een pagina met gegevens op te halen. Er is één primair rekenpunt waar alle lees-/schrijfworkloads en transacties worden verwerkt. Er zijn een of meer secundaire rekenknooppunten die fungeren als hot stand-byknooppunten voor failoverdoeleinden, en die ook fungeren als alleen-lezen rekenknooppunten voor het offloaden van leesworkloads (als deze functionaliteit gewenst is).

De database-engine die wordt uitgevoerd op Hyperscale-rekenknooppunten is hetzelfde als in andere Azure SQL Database-servicelagen. Wanneer gebruikers communiceren met de database-engine op Hyperscale-rekenknooppunten, zijn de ondersteunde surface area en engine hetzelfde als in andere servicelagen, met uitzondering van bekende beperkingen.

Paginaserver

Paginaservers zijn systemen die een geschaalde opslagen engine vertegenwoordigen. Elke paginaserver is verantwoordelijk voor een subset van de pagina's in de database. Nominaal bepaalt elke paginaserver maximaal 128 GB of maximaal 1 TB aan gegevens. Er worden geen gegevens gedeeld op meer dan één paginaserver (buiten paginaserverreplica's die worden bewaard voor redundantie en beschikbaarheid). De taak van een paginaserver is om databasepagina's op aanvraag naar de rekenknooppunten te versturen en de pagina's bij te werken wanneer transacties gegevens bijwerken. Paginaservers worden up-to-date gehouden door logboekrecords uit de logboekservice af te spelen. Paginaservers behouden ook de dekking van caches op basis van SSD om de prestaties te verbeteren. Langetermijnopslag van gegevenspagina's wordt opgeslagen in Azure Storage voor extra betrouwbaarheid.

Logboekservice

De logboekservice accepteert logboekrecords van de primaire rekenreplica, zet ze op in een duurzame cache en zet de logboekrecords door naar de rest van de rekenreplica's (zodat ze hun caches kunnen bijwerken), evenals de relevante paginaserver(s), zodat de gegevens daar kunnen worden bijgewerkt. Op deze manier worden alle gegevenswijzigingen van de primaire rekenreplica via de logboekservice doorgegeven aan alle secundaire rekenreplica's en paginaservers. Ten slotte worden de logboekrecords naar langetermijnopslag in Azure Storage, een vrijwel oneindige opslagopslagplaats. Met dit mechanisme is het niet meer nodig om logboeken regelmatig af te trekken. De logboekservice heeft ook lokaal geheugen en SSD-caches om de toegang tot logboekrecords te versnellen.

Azure Storage

Azure Storage bevat alle gegevensbestanden in een database. Paginaservers houden gegevensbestanden in Azure Storage up-to-date. Deze opslag wordt gebruikt voor back-updoeleinden en voor replicatie tussen Azure-regio's. Back-ups worden geïmplementeerd met opslagmomentopnamen van gegevensbestanden. Herstelbewerkingen met behulp van momentopnamen zijn snel, ongeacht de gegevensgrootte. Gegevens kunnen worden hersteld naar elk tijdstip binnen de bewaarperiode van de back-up van de database.

Back-ups en herstellen

Back-ups zijn gebaseerd op momentopnamen van bestanden en zijn daarom vrijwel onmiddellijk. Storage en rekenscheiding kunt u de back-up-/herstelbewerking naar de opslaglaag pushen om de verwerkingsbelasting van de primaire rekenreplica te verminderen. Als gevolg hiervan heeft databaseback-up geen invloed op de prestaties van het primaire reken knooppunt. Herstel naar een bepaald tijdstip wordt op dezelfde manier uitgevoerd door terug te keren naar momentopnamen van bestanden en is dus geen grootte van de gegevensbewerking. Het herstellen van een Hyperscale-database in dezelfde Azure-regio is een constante bewerking en zelfs databases met meerdere terabytes kunnen in minuten worden hersteld in plaats van uren of dagen. Het maken van nieuwe databases door een bestaande back-up te herstellen, maakt ook gebruik van deze functie: het maken van databasekopieen voor ontwikkelings- of testdoeleinden, zelfs van databases van meerdere terabytes, kan in enkele minuten worden uitgevoerd.

Zie Een Hyperscale-database herstellen naar een andere regio voor geo-herstel van Hyperscale-databases.

Schaal- en prestatievoordelen

Dankzij de mogelijkheid om snel extra alleen-lezen rekenknooppunten op te zetten of omlaag te halen, biedt de Hyperscale-architectuur aanzienlijke leesmogelijkheden en kan het primaire rekenknooppunt ook worden vrijgediend voor het verwerken van meer schrijfaanvragen. Daarnaast kunnen de rekenknooppunten snel omhoog/omlaag worden geschaald vanwege de architectuur voor gedeelde opslag van de Hyperscale-architectuur.

Een Hyperscale-database maken

Een Hyperscale-database kan worden gemaakt met de Azure Portal, T-SQL, PowerShellof CLI. Hyperscale-databases zijn alleen beschikbaar met behulp van het aankoopmodel op basis van vCore.

Met de volgende T-SQL maakt u een Hyperscale-database. U moet zowel de editie als de servicedoelstelling opgeven in de CREATE DATABASE instructie . Raadpleeg de resourcelimieten voor een lijst met geldige servicedoelstellingen.

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

Hiermee maakt u een Hyperscale-database op Gen5-hardware met vier kernen.

Bestaande database upgraden naar Hyperscale

U kunt uw bestaande databases in Azure SQL Database verplaatsen naar Hyperscale met behulp van Azure Portal, T-SQL, PowerShellof CLI. Op dit moment is dit een een way migration. U kunt databases niet verplaatsen van Hyperscale naar een andere servicelaag, anders dan door gegevens te exporteren en te importeren. Voor proofs of concept (POC's) raden we u aan een kopie van uw productiedatabases te maken en de kopie te migreren naar Hyperscale. Het migreren van een bestaande database in Azure SQL Database naar de Hyperscale-laag is een grootte van de gegevensbewerking.

Met de volgende T-SQL verplaatst u een database naar de Hyperscale-servicelaag. U moet zowel de editie als de servicedoelstelling opgeven in de ALTER DATABASE instructie .

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

Notitie

Als u een database die deel uitmaakt van een geo-replicatierelatie, als primaire of secundaire database, wilt verplaatsen naar Hyperscale, moet u de replicatie stoppen. Databases in een failovergroep moeten eerst uit de groep worden verwijderd.

Zodra een database is verplaatst naar Hyperscale, kunt u een nieuwe geo-replica van Hyperscale voor die database maken. Geo-replicatie voor Hyperscale is in preview met bepaalde beperkingen.

Hoge beschikbaarheid van databases in Hyperscale

Net als bij alle andere servicelagen garandeert Hyperscale duurzaamheid van gegevens voor vastgelegde 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) en van de aanwezigheid van ten minste één replica met hoge beschikbaarheid. Bij een geplande failover (dat wil zeggen een onderhoudsgebeurtenis) maakt het systeem de nieuwe primaire replica voordat een failover wordt geïnitieerd, of gebruikt het een bestaande replica met hoge beschikbaarheid als failoverdoel. In een niet-geplande failover (dat wil zeggen een hardwarefout op de primaire replica), gebruikt het systeem een replica met hoge beschikbaarheid als failoverdoel, indien aanwezig, of maakt het een nieuwe primaire replica vanuit de pool met beschikbare rekencapaciteit. In het laatste geval is de duur van de downtime langer vanwege de extra stappen die nodig zijn om de nieuwe primaire replica te maken.

Zie SLA voor Hyperscale SLA voor Azure SQL Database.

Herstel na noodherstel voor Hyperscale-databases

Een Hyperscale-database herstellen naar een andere regio

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, een oefening, herlocatie of een andere reden, is de primaire methode om een geo-herstel van de database uit te voeren. Dit omvat exact dezelfde stappen als wat u zou gebruiken om een andere database in SQL Database te herstellen naar een andere regio:

  1. Maak een server in de doelregio als u daar nog geen geschikte server hebt. Deze server moet eigendom zijn van hetzelfde abonnement als de oorspronkelijke (bron)server.
  2. Volg de instructies in het onderwerp geo-herstel van de pagina over het herstellen van een database in Azure SQL Database automatische back-ups.

Notitie

Omdat de bron en het doel zich in afzonderlijke regio's hebben, kan de database geen momentopnameopslag delen met de brondatabase, zoals in niet-geo-herstel, die snel worden voltooid, ongeacht de grootte van de database. In het geval van een geo-herstel van een Hyperscale-database is dit een gegevensbewerking met een grootte, zelfs als het doel zich in de gekoppelde regio van de geo-gerepliceerde opslag. Daarom duurt geo-herstel in verhouding tot de grootte van de database die wordt hersteld. Als het doel zich in de gekoppelde regio, gegevensoverdracht binnen een regio, die aanzienlijk sneller dan een gegevensoverdracht tussen regio's, maar het nog steeds een grootte van de gegevens bewerking.

Beschikbare regio's

De Azure SQL Database Hyperscale-laag is beschikbaar in alle regio's, maar standaard ingeschakeld in de volgende regio's die hieronder worden vermeld. Als u een Hyperscale-database wilt maken in een regio waarin Hyperscale niet standaard is ingeschakeld, kunt u een aanvraag voor onboarding verzenden via Azure Portal. Zie Verhogingen van quotum aanvragen voor Azure SQL Database voor instructies. Gebruik de volgende richtlijnen wanneer u uw aanvraag indient:

  • Gebruik het toegangstype Regio SQL Database quotumtype.
  • Voeg in de beschrijving de reken-SKU/totale kernen toe, inclusief hoge beschikbaarheid en benoemde replica's, en geef aan dat u Hyperscale-capaciteit aanvraagt.
  • Geef ook een projectie op van de totale grootte van alle databases gedurende een periode in TB.

Ingeschakelde regio's:

  • Australië - oost
  • Australië - zuidoost
  • Australië - centraal
  • Brazilië - zuid
  • Canada - midden
  • Canada - oost
  • Central US
  • China - oost 2
  • China - noord 2
  • Azië - oost
  • VS - oost
  • VS - oost 2
  • Frankrijk - centraal
  • Duitsland - west-centraal
  • Japan - oost
  • Japan - west
  • Korea - centraal
  • Korea - zuid
  • VS - noord-centraal
  • Europa - noord
  • Noorwegen - oost
  • Noorwegen - west
  • Zuid-Afrika - noord
  • VS - zuid-centraal
  • Azië - zuidoost
  • Zwitserland - west
  • Verenigd Koninkrijk Zuid
  • Verenigd Koninkrijk West
  • US DoD Central
  • US DoD East
  • Us Govt Arizona
  • US Govt Texas
  • VS - west-centraal
  • Europa -west
  • VS - west
  • VS - west 2

Bekende beperkingen

Dit zijn de huidige beperkingen voor de Hyperscale-servicelaag vanaf ga. Er wordt actief aan gewerkt om zoveel mogelijk van deze beperkingen te verwijderen.

Probleem Beschrijving
In het deelvenster Back-ups beheren voor een server worden geen Hyperscale-databases weergegeven. Deze worden gefilterd vanuit de weergave. Hyperscale heeft een afzonderlijke methode voor het beheren van back-ups, dus de Long-Term Retentie- en Point-in-Time-instellingen voor back-ups zijn niet van toepassing. Hyperscale-databases worden daarom niet weergegeven in het deelvenster Back-up beheren.

Voor databases die vanuit andere Azure SQL Database-servicelagen naar Hyperscale worden gemigreerd, worden back-ups vóór de migratie bewaard voor de duur van de bewaarperiode voor back-ups van de brondatabase. Deze back-ups kunnen worden gebruikt om de brondatabase te herstellen naar een tijdstip vóór de migratie.
Terugzetten naar eerder tijdstip 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 een niet-Hyperscale-database die is gemigreerd naar Hyperscale door de servicelaag te wijzigen, herstelt u naar een bepaald tijdstip vóór de migratie en binnen de bewaarperiode voor back-ups van de database wordt programmatisch ondersteund. De herstelde database is niet Hyperscale.
Wanneer u Azure SQL Database servicelaag in Hyperscale verandert, mislukt de bewerking als de database gegevensbestanden bevat die groter zijn dan 1 TB In sommige gevallen is het mogelijk om dit probleem op te lossen door de grote bestanden te verkleinen tot minder dan 1 TB voordat u de servicelaag wijzigt in Hyperscale. Gebruik de volgende query om de huidige grootte van databasebestanden te bepalen. SELECT file_id, name AS file_name, size * 8. / 1024 / 1024 AS file_size_GB FROM sys.database_files WHERE type_desc = 'ROWS';
SQL Managed Instance Azure SQL Managed Instance wordt momenteel niet ondersteund met Hyperscale-databases.
Elastische pools Elastische pools worden momenteel niet ondersteund met Hyperscale.
Migratie naar Hyperscale is momenteel een een way-bewerking Zodra een database is gemigreerd naar Hyperscale, kan deze niet rechtstreeks worden gemigreerd naar een niet-Hyperscale-servicelaag. Op dit moment is de enige manier om een database te migreren van Hyperscale naar niet-Hyperscale, te exporteren/importeren met behulp van een BACPAC-bestand of andere technologieën voor gegevensver movement (bulksgewijs kopiëren, Azure Data Factory, Azure Databricks, SSIS, enzovoort) Bacpac exporteren/importeren vanuit Azure Portal, vanuit PowerShell met New-AzSqlDatabaseExport of New-AzSqlDatabaseImport,vanuit Azure CLI met az sql db export en az sql db importen vanuit REST API wordt niet ondersteund. Bacpac importeren/exporteren voor kleinere Hyperscale-databases (maximaal 200 GB) wordt ondersteund met SSMS en SqlPackage versie 18.4 en hoger. Voor grotere databases kan het exporteren/importeren van BACPAC lang duren en kan het om verschillende redenen mislukken.
Migratie van databases met In-Memory OLTP-objecten Hyperscale ondersteunt een subset van In-Memory OLTP-objecten, waaronder tabeltypen die zijn geoptimaliseerd voor geheugen, tabelvariabelen en systeemeigen gecompileerde modules. Wanneer er echter een soort OLTPIn-Memory objecten aanwezig is 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 In-Memory OLTP-objecten en hun afhankelijkheden worden verwijderd. Nadat de database is gemigreerd, kunnen deze objecten opnieuw worden gemaakt. Duurzame en niet-duurzame, voor geheugen geoptimaliseerde tabellen worden momenteel niet ondersteund in Hyperscale en moeten worden gewijzigd in schijftabellen.
Geo-replicatie Geo-replicatie in Hyperscale is nu beschikbaar als openbare preview.
Intelligente databasefuncties Met uitzondering van de optie Plan forceer, worden alle andere opties voor Automatisch afstemmen nog niet ondersteund op Hyperscale: opties lijken mogelijk ingeschakeld te zijn, maar er worden geen aanbevelingen of acties gedaan.
Inzicht in queryprestaties Query Performance Insights wordt momenteel niet ondersteund voor Hyperscale-databases.
Database verkleinen DBCC SHRINKDATABASE of DBCC SHRINKFILE wordt momenteel niet ondersteund voor Hyperscale-databases.
Database-integriteitscontrole DBCC CHECKDB wordt momenteel niet ondersteund voor Hyperscale-databases. DBCC CHECKFILEGROUP en DBCC CHECKTABLE kunnen 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 als taakdatabase wordt niet ondersteund. Elastische taken kunnen echter op dezelfde manier worden gericht op Hyperscale-databases als andere Azure SQL database.

Volgende stappen