Aankoopmodel voor vCore - Azure SQL Managed Instance

  • Artikel

Van toepassing op: Azure SQL Managed Instance

In dit artikel wordt het vCore-aankoopmodel voor Azure SQL Managed Instance beoordeeld.

Overzicht

Een virtuele kern (vCore) vertegenwoordigt een logische CPU en biedt u de mogelijkheid om de fysieke kenmerken van de hardware te kiezen (bijvoorbeeld het aantal kernen, het geheugen en de opslaggrootte). Het aankoopmodel op basis van vCore biedt u flexibiliteit, controle, transparantie van het individuele resourceverbruik en een eenvoudige manier om on-premises workloadvereisten te vertalen naar de cloud. Dit model optimaliseert de prijs en stelt u in staat om reken-, geheugen- en opslagresources te kiezen op basis van uw workloadbehoeften.

In het aankoopmodel op basis van vCore zijn uw kosten afhankelijk van de keuze en het gebruik van:

  • Servicelaag
  • Hardwareconfiguratie
  • Rekenresources (het aantal vCores en de hoeveelheid geheugen)
  • Gereserveerde databaseopslag
  • Werkelijke back-upopslag

Het aankoopmodel voor virtuele kernen (vCore) dat wordt gebruikt door Azure SQL Managed Instance biedt de volgende voordelen:

  • Beheer over de hardwareconfiguratie om beter te voldoen aan de reken- en geheugenvereisten van de workload.
  • Prijskortingen voor Azure Hybrid Benefit (AHB) en gereserveerde instantie (RI).
  • Meer transparantie in de hardwaredetails die rekenkracht bieden, waardoor het plannen van migraties vanuit on-premises implementaties wordt vereenvoudigd.
  • Hogere schaalgranulariteit met meerdere rekengrootten beschikbaar.

Compute

Sql Managed Instance-rekenkracht biedt een specifieke hoeveelheid rekenresources die continu worden ingericht, onafhankelijk van de workloadactiviteit, en factureert voor de hoeveelheid rekenkracht die is ingericht tegen een vaste prijs per uur.

Omdat drie extra replica's automatisch worden toegewezen in de servicelaag Bedrijfskritiek, is de prijs ongeveer 2,7 keer hoger dan in de servicelaag Algemeen gebruik. Op dezelfde manier weerspiegelt de hogere opslagprijs per GB in de servicelaag Bedrijfskritiek de hogere I/O-limieten en lagere latentie van de lokale SSD-opslag.

Voor exemplaren in de servicelaag Algemeen gebruik is het mogelijk om te besparen op reken- en licentiekosten door uw exemplaar te stoppen wanneer u deze niet gebruikt. Bekijk Stop en start een exemplaar (preview) voor meer informatie.

Gegevens- en logboekopslag

De volgende factoren zijn van invloed op de hoeveelheid opslagruimte die wordt gebruikt voor gegevens- en logboekbestanden, en zijn van toepassing op de lagen Algemeen gebruik en Bedrijfskritiek.

  • In de servicelaag tempdb Algemeen gebruik maakt u gebruik van lokale SSD-opslag en zijn deze opslagkosten inbegrepen in de vCore-prijs.
  • In de servicelaag Bedrijfskritiek deelt tempdb u lokale SSD-opslag met gegevens- en logboekbestanden, en tempdb de opslagkosten zijn inbegrepen in de vCore-prijs.
  • De maximale opslaggrootte voor een SQL Managed Instance moet worden opgegeven in veelvouden van 32 GB.

Belangrijk

In beide servicelagen worden kosten in rekening gebracht voor de maximale opslaggrootte die is geconfigureerd voor een beheerd exemplaar.

Als u de totale opslaggrootte van verbruikte exemplaren voor SQL Managed Instance wilt bewaken, gebruikt u de metrische gegevens van storage_space_used_mb. Als u de huidige toegewezen en gebruikte opslaggrootte van afzonderlijke gegevens en logboekbestanden in een database wilt bewaken met behulp van T-SQL, gebruikt u de sys.database_files-weergave en de functie FILEPROPERTY(... , 'SpaceUsed').

Back-upopslag

Opslag voor databaseback-ups wordt toegewezen ter ondersteuning van de mogelijkheden van SQL Managed Instance. Deze opslag is gescheiden van de opslag van gegevens- en logboekbestanden en wordt afzonderlijk gefactureerd.

  • Herstel naar een bepaald tijdstip (PITR): het opslagverbruik is afhankelijk van de snelheid van de wijziging van de database en de retentieperiode die is geconfigureerd voor back-ups. U kunt een afzonderlijke bewaarperiode configureren voor elke database tussen 1 en 35 dagen voor SQL Managed Instance. Er wordt geen extra kosten in rekening gebracht voor de hoeveelheid back-upopslag die gelijk is aan de geconfigureerde maximale gegevensgrootte.
  • Langetermijnretentie (LTR): u hebt de mogelijkheid om langetermijnretentie van volledige back-ups tot 10 jaar te configureren. De configuratie die u kiest, bepaalt hoeveel opslagruimte wordt gebruikt voor LTR-back-ups.

Servicelagen

Opties voor de servicelaag in het vCore-aankoopmodel omvatten Algemeen gebruik en Bedrijfskritiek. De servicelaag definieert doorgaans de opslagarchitectuur, ruimte- en I/O-limieten en opties voor bedrijfscontinuïteit met betrekking tot beschikbaarheid en herstel na noodgevallen.

Categorie Algemeen doel Bedrijfskritiek
Het beste voor De meeste zakelijke workloads. Biedt budgetgerichte, gebalanceerde en schaalbare reken- en opslagopties. Biedt zakelijke toepassingen de hoogste tolerantie voor storingen met behulp van verschillende geïsoleerde replica's en biedt de hoogste I/O-prestaties.
Alleen-lezen replica's 0 1
Replica's voor beschikbaarheid Eén replica voor hoge beschikbaarheid Drie replica's met hoge beschikbaarheid, 1 is ook een replica met leesschaal
Alleen-lezen replica's waarvoor failovergroepen zijn ingeschakeld Een extra alleen-lezen replica. Twee totaal leesbare replica's, waaronder de primaire replica. Twee extra alleen-lezen replica's, drie totaal alleen-lezen replica's. Vier totaal leesbare replica's, waaronder de primaire replica.
Prijzen/facturering Er worden kosten in rekening gebracht voor vCore, gereserveerde opslag en back-upopslag .
Er worden geen kosten in rekening gebracht voor IOPS		 Er worden kosten in rekening gebracht voor vCore, gereserveerde opslag en back-upopslag .
IOPS wordt 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

Raadpleeg de resourcelimieten voor meer informatie.

Notitie

Zie SLA voor Azure SQL Managed Instance voor meer informatie over de Sla (Service Level Agreement).

Algemeen gebruik

Het architectuurmodel voor de servicelaag Algemeen gebruik is gebaseerd op een scheiding van rekenkracht en opslag. Dit architectuurmodel is afhankelijk van de hoge beschikbaarheid en betrouwbaarheid van Azure Blob-opslag die op transparante wijze databasebestanden repliceert en garandeert geen gegevensverlies als de onderliggende infrastructuur mislukt.

In de volgende afbeelding ziet u vier knooppunten in het standaardarchitectuurmodel met de gescheiden reken- en opslaglagen.

Separation of compute and storage

In het architectuurmodel voor de servicelaag Algemeen gebruik zijn er twee lagen:

  • Een staatloze rekenlaag die het sqlservr.exe proces uitvoert en alleen tijdelijke en in de cache opgeslagen gegevens bevat (bijvoorbeeld plancache, buffergroep, kolomopslaggroep). Dit staatloze knooppunt wordt beheerd door Azure Service Fabric waarmee het proces wordt geïnitialiseerd, de status van het knooppunt wordt beheerd en indien nodig een failover naar een andere locatie wordt uitgevoerd.
  • Een stateful gegevenslaag met databasebestanden (.mdf/.ldf) die zijn opgeslagen in Azure Blob Storage. Azure Blob Storage garandeert dat er geen gegevens verloren gaan van records die in een databasebestand worden geplaatst. Azure Storage heeft ingebouwde beschikbaarheid/redundantie van gegevens die ervoor zorgen dat elke record in het logboekbestand of elke pagina in het gegevensbestand behouden blijft, zelfs als het proces vastloopt.

Wanneer de database-engine of het besturingssysteem wordt bijgewerkt, mislukt een deel van de onderliggende infrastructuur of als er een kritiek probleem wordt gedetecteerd tijdens het sqlservr.exe proces, wordt het staatloze proces verplaatst naar een ander staatloos rekenknooppunt. Er is een set reserveknooppunten die wachten om een nieuwe rekenservice uit te voeren als er een failover van het primaire knooppunt plaatsvindt om de failovertijd te minimaliseren. Gegevens in de Azure-opslaglaag worden niet beïnvloed en gegevens/logboekbestanden worden gekoppeld aan het zojuist geïnitialiseerde proces. Dit proces garandeert standaard een beschikbaarheid van 99,99%. Er kunnen enkele prestatie-gevolgen zijn voor zware workloads die in de vlucht zijn vanwege de overgangstijd en het feit dat het nieuwe knooppunt begint met koude cache.

Wanneer u deze servicelaag kiest

De servicelaag Algemeen gebruik is de standaardservicelaag in Azure SQL Managed Instance die is ontworpen voor de meeste algemene workloads. Als u een volledig beheerde database-engine nodig hebt met een standaard-SLA en opslaglatentie tussen 5 en 10 ms, is de laag Algemeen gebruik de optie voor u.

Bedrijfskritiek

Het Bedrijfskritiek servicelaagmodel is gebaseerd op een cluster van database-engineprocessen. Dit architectuurmodel is afhankelijk van een quorum van altijd beschikbare database-engineknooppunten om de prestaties van uw workload te minimaliseren, zelfs tijdens onderhoudsactiviteiten. Azure werkt het onderliggende besturingssysteem, de stuurprogramma's en de SQL Server-database-engine transparant bij, met minimale uitlooptijd voor eindgebruikers.

In het Bedrijfskritiek model worden rekenkracht en opslag op elk knooppunt geïntegreerd. Replicatie van gegevens tussen database-engineprocessen op elk knooppunt van een cluster met vier knooppunten bereikt hoge beschikbaarheid, waarbij elk knooppunt lokaal gekoppelde SSD gebruikt als gegevensopslag.

Cluster of database engine nodes

Zowel het SQL Server-database-engineproces als de onderliggende .mdf/.ldf-bestanden worden op hetzelfde knooppunt geplaatst met lokaal gekoppelde SSD-opslag, waardoor uw workload weinig latentie biedt. Hoge beschikbaarheid wordt geïmplementeerd met behulp van technologie die vergelijkbaar is met SQL Server AlwaysOn-beschikbaarheidsgroepen.

Elk exemplaar is een cluster van database-engineknooppunten die kopieën van alle databases op een exemplaar bevatten, met een primaire database die toegankelijk is voor workloads van klanten en drie secundaire databases die kopieën van de gegevens bevatten, klaar voor failover. Het primaire knooppunt pusht voortdurend wijzigingen naar de secundaire knooppunten om ervoor te zorgen dat de gegevens beschikbaar zijn op secundaire replica's als het primaire knooppunt om welke reden dan ook mislukt.

Failover wordt verwerkt door de SQL Server-database-engine: één secundaire replica wordt het primaire knooppunt en er wordt een nieuwe secundaire replica gemaakt om ervoor te zorgen dat er voldoende knooppunten in het cluster zijn. De workload wordt automatisch omgeleid naar het nieuwe primaire knooppunt.

Bovendien heeft het Bedrijfskritiek-cluster een ingebouwde uitschaalfunctie voor lezen die een gratis alleen-lezenreplica biedt die wordt gebruikt voor het uitvoeren van alleen-lezenquery's (zoals rapporten) die geen invloed hebben op de prestaties van de werkbelasting op uw primaire replica.

Wanneer u deze servicelaag kiest

De servicelaag Bedrijfskritiek is ontworpen voor toepassingen waarvoor reacties met lage latentie van de onderliggende SSD-opslag (gemiddeld 1-2 ms) nodig zijn, sneller herstel als de onderliggende infrastructuur uitvalt of rapporten, analyses en alleen-lezen query's naar de gratis leesbare secundaire replica van de primaire database moet worden uitgeschakeld.

De belangrijkste redenen waarom u Bedrijfskritiek servicelaag moet kiezen in plaats van de laag Algemeen gebruik, zijn:

  • Lage I/O-latentievereisten: workloads die een snelle reactie van de opslaglaag (gemiddeld 1-2 milliseconden) nodig hebben, moeten Bedrijfskritiek laag gebruiken.
  • Workload met rapportage- en analysequery's die kunnen worden omgeleid naar de gratis secundaire replica met het kenmerk Alleen-lezen.
  • Hogere tolerantie en sneller herstel na fouten. Als er systeemfouten optreden, worden de databases op het primaire exemplaar offline gehaald en wordt een van de secundaire replica's onmiddellijk het nieuwe primaire exemplaar voor lezen/schrijven, klaar om query's te verwerken. Het is niet nodig dat de database-engine transacties vanuit het logboekbestand analyseert en opnieuw uitvoert of gegevens in geheugenbuffers laadt.
  • Geavanceerde bescherming tegen beschadiging van gegevens. Omdat de Bedrijfskritiek-laag achter de schermen gebruikmaakt van databasesreplica's, maakt de service gebruik van automatisch paginaherstel dat beschikbaar is met spiegeling en beschikbaarheidsgroepen om beschadiging van gegevens te beperken. Als een replica een pagina niet kan lezen vanwege een probleem met gegevensintegriteit, wordt een nieuwe kopie van de pagina opgehaald uit een andere replica, waardoor de onleesbare pagina wordt vervangen zonder gegevensverlies of uitvaltijd van de klant. Deze functionaliteit is beschikbaar in de laag Algemeen gebruik als het beheerde exemplaar een geo-secundaire replica heeft.
  • Hogere beschikbaarheid: de Bedrijfskritiek-laag in een configuratie met meerdere beschikbaarheidszones biedt tolerantie voor zonefouten en een SLA met een hogere beschikbaarheid.
  • Snel geo-herstel: als een failovergroep is geconfigureerd, heeft de Bedrijfskritiek-laag een gegarandeerdE RPO (Recovery Point Objective) van 5 seconden en RTO (Recovery Time Objective) van 30 seconden voor 100% van de geïmplementeerde uren.

Bij het opgeven van de servicelaag in sjablonen of scripts wordt de laag geleverd met behulp van de naam. De volgende tabel is van toepassing:

Hardware Naam
Algemeen gebruik GeneralPurpose
Bedrijfskritiek BusinessCritical

Hardwareconfiguraties

Hardwareconfiguratieopties in het vCore-model omvatten standard-series (Gen5), premium-serie en geoptimaliseerd voor geheugen. Hardwareconfiguratie definieert doorgaans de reken- en geheugenlimieten en andere kenmerken die van invloed zijn op de prestaties van de werkbelasting.

Zie Hardwareconfiguratiekenmerken voor meer informatie over de specifieke hardwareconfiguraties en -beperkingen.

In de sys.dm_user_db_resource_governance dynamische beheerweergave wordt hardwaregeneratie voor exemplaren met Intel® SP-8160-processors (Skylake) weergegeven als Gen6, terwijl hardwaregeneratie voor exemplaren met Intel® 8272CL (Cascade Lake) wordt weergegeven als Gen7. De Intel® 8370C (Ice Lake) CPU's die worden gebruikt door premium-serie en geoptimaliseerd voor geheugen geoptimaliseerde hardwaregeneraties worden weergegeven als Gen8. Resourcelimieten voor alle Gen5-exemplaren (Standard Series) zijn hetzelfde, ongeacht het processortype (Broadwell, Skylake of Cascade Lake).

Een hardwareconfiguratie selecteren

U kunt de hardwareconfiguratie selecteren op het moment dat het exemplaar is gemaakt of u kunt de hardware van een bestaand exemplaar wijzigen.

Hardwareconfiguratie selecteren bij het maken van een met SQL beheerd exemplaar

Zie Een met SQL beheerd exemplaar maken voor gedetailleerde informatie.

Selecteer op het tabblad Basisinformatie de koppeling Database configureren in de sectie Compute en opslag en selecteer vervolgens de gewenste hardware:

configure SQL Managed InstanceHardware van een bestaand met SQL beheerd exemplaar wijzigen

Selecteer Compute en opslag onder Instellingen op de pagina SQL Managed Instance:

Screenshot shows Compute + storage page for SQL managed instance.

Op de pagina Compute + Storage kunt u uw hardware wijzigen onder Hardwaregeneratie met behulp van de schuifregelaars voor vCores en Storage.

Bij het opgeven van de hardwareparameter in sjablonen of scripts wordt hardware geleverd met behulp van de naam. De volgende tabel is van toepassing:

Hardware Naam
Standard-serie (Gen5) Gen5
Premium-series G8IM
Geoptimaliseerd voor geheugen premium-serie G8IH

SKU-namen

Notitie

Wanneer u hardware- en servicelaag specyfeert in sjablonen of scripts, kunt u deze onafhankelijk opgeven of kunt u een SKU-naam opgeven. Wanneer u de SKU-naam opgeeft, is de volgende tabel van toepassing:

SKU Servicelaag Hardware
GP_Gen5 Algemeen gebruik Standaardserie
GP_G8IM Algemeen gebruik Premium-series
GP_G8IH Algemeen gebruik Geoptimaliseerd voor geheugen uit de Premium-serie
BC_Gen5 Bedrijfskritiek Standaardserie
BC_G8IM Bedrijfskritiek Premium-series
BC_G8IH Bedrijfskritiek Geoptimaliseerd voor geheugen uit de Premium-serie

Beschikbaarheid van hardware

Standard-serie (Gen5) en premium-serie

Hardware uit de Standard-serie (Gen5) en premium-serie is beschikbaar in alle openbare regio's wereldwijd.

Hardware uit de Premium-serie geoptimaliseerd voor geheugen is in preview en heeft beperkte regionale beschikbaarheid. Zie Resourcelimieten voor Azure SQL Managed Instance voor meer informatie.

Volgende stappen