Delen via

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 Instancebeoordeeld.

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:

  • Serviceniveau
  • Hardwareconfiguratie
  • Rekenresources (het aantal vCores en de hoeveelheid geheugen)
  • Gereserveerde databaseopslag
  • Werkelijke reservekopieopslag

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 Reserved Instance (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.

Berekenen

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 voor meer informatie.

Gegevens- en logboekopslag

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

  • In de servicelaag Algemeen gebruik maakt tempdb gebruik van lokale SSD-opslag. Deze opslagkosten zijn inbegrepen in de vCore-prijs.
  • In de servicelaag Bedrijfskritiek deelt tempdb lokale SSD-opslag met gegevens en logboekbestanden en tempdb opslagkosten zijn opgenomen in de prijs van vCore.
  • 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 gebruikte opslagruimte van exemplaren voor SQL Managed Instance wilt bewaken, gebruikt u de metriek 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 FILEPROPERTY(... , 'SpaceUsed') functie.

backup-opslag

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): de opslagconsumptie is afhankelijk van de wijzigingssnelheid van de database en de ingestelde retentieperiode 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.

Serviceniveaus

De servicelaag definieert doorgaans de opslagarchitectuur, ruimte- en I/O-limieten en opties voor bedrijfscontinuïteit met betrekking tot beschikbaarheid en herstel na noodgevallen.

Azure SQL Managed Instance heeft twee servicelagen:

Raadpleeg resourcelimietenvoor een gedetailleerde vergelijking tussen servicelagen, maar gebruik de volgende tabel voor een kort overzicht:

Categorie algemeen gebruik Volgende generatie Universeel Gebruik Bedrijfskritieke
Beste voor De meeste zakelijke workloads. Biedt budgetgerichte, evenwichtige en schaalbare reken- en opslagopties. Budgetgerichte zakelijke workloads die meer capaciteit, verbeterde doorvoer en flexibiliteit van resources nodig hebben. Biedt zakelijke toepassingen de hoogste tolerantie voor storingen met behulp van verschillende geïsoleerde replica's en biedt de hoogste I/O-prestaties.
Maximaal aantal vCores 80 128 128
maximale opslaggrootte van instanties 16 TB 32 TB 16 TB
Maximum aantal databases per exemplaar 100 500 100
replica's in alleen-lezenmodus 0 0 1
replica's voor beschikbaarheid Stand-byknooppunten voor hoge beschikbaarheid Stand-byknooppunten voor hoge beschikbaarheid Drie replica's met hoge beschikbaarheid, één is ook een replica op leesschaal
Prijzen en facturering vCore, gereserveerde opslag en back-upopslag worden in rekening gebracht.
Er worden geen kosten in rekening gebracht voor IOPS		 Er worden kosten in rekening gebracht voor vCore, gereserveerde opslag, back-upopslag en IOPS (via het gratis quotum). vCore, gereserveerde opslag en back-upopslag wordt in rekening gebracht.
IOPS wordt niet in rekening gebracht.

Notitie

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

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.

diagram met de scheiding van rekenkracht en opslag.

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

  • Een staatloze rekenlaag waarop het sqlservr.exe proces wordt uitgevoerd en alleen tijdelijke en in de cache opgeslagen gegevens bevat (bijvoorbeeld plancache, bufferpool, columnstore-pool). 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 in het sqlservr.exe proces, verplaatst Azure Service Fabric het staatloze proces 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 99,99% beschikbaarheid. Er kunnen 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.

Volgende generatie Algemeen gebruik

Notitie

De upgrade van de servicelaag Voor algemeen gebruik van de volgende generatie is momenteel beschikbaar als preview-versie. Om aan de slag te gaan, de servicelaag Next-gen Algemeen gebruik gebruiken voor in aanmerking komende nieuwe en bestaande exemplaren.

De servicelaag Next-gen Algemeen gebruik is een architectuurupgrade van de bestaande servicelaag Algemeen gebruik die de volgende belangrijke kenmerken biedt:

  • Ontworpen voor bedrijven met hogere prestatievereisten, terwijl ze dezelfde basislijnkosten bieden als de servicecategorie Algemeen Gebruik.
  • Belangrijke upgrades voor prestaties, schaalbaarheid en flexibiliteit van resources ten opzichte van de servicelaag Algemeen gebruik
  • Maakt gebruik van beheerde schijven in plaats van pagina-blobs, waardoor de metrische gegevens over de opslagprestaties drastisch worden verbeterd
  • 3 gratis IOPS voor elke GB gereserveerde opslag
  • Ondersteuning van maximaal 500 databases per exemplaar en een maximale opslaggrootte van 32 TB

Omdat de servicelaag Next-gen Algemeen gebruik een upgrade naar de bestaande servicelaag Algemeen gebruik is, ongeacht welke servicelaag uw exemplaar gebruikt, weerspiegelt uw factureringsoverzicht de Servicelaag Algemeen gebruik servicelaag.

Architectuurmodel

De servicelaag Next-gen Algemeen gebruik is een upgrade naar de bestaande servicelaag Algemeen gebruik die gebruikmaakt van een bijgewerkte externe opslaglaag voor het opslaan van exemplaargegevens en logboekbestanden op beheerde schijven in plaats van pagina-blobs. Dit betekent dat de Next-gen servicelaag Algemeen gebruik snellere opslaglatentie, IOPS en doorvoer biedt dan de bestaande servicelaag Algemeen gebruik, met verhoogde prestatiegrenzen voor opslag, het aantal vCores en het maximale aantal databases. Aangezien de prestatiequota door het hele exemplaar worden gedeeld, hoeft u de grootte van afzonderlijke bestanden niet meer te wijzigen om de prestaties te verbeteren. De basiskosten van de Next-gen Algemeen Gebruik-laag zijn hetzelfde als die van de Algemeen Gebruik-laag, maar u kunt schuifbalken gebruiken om de IO-prestaties te verbeteren, waarvoor vervolgens apart wordt gefactureerd.

De servicelaag Next-gen Algemeen gebruik helpt de kosten te verlagen door gratis IOPS aan te bieden op drie IOPS voor elke GB gereserveerde opslag. De prijs van de opslag omvat de minimale IOPS. Als u boven het minimum gaat, worden er als volgt kosten in rekening gebracht: 1 IOPS = opslagprijs (per regio) gedeeld door drie.

Bijvoorbeeld:

  • Als 1 GB opslagruimte 0,115 kost, is 1 IOPS = 0,115/3 = 0,038 per IOPS.
  • Een exemplaar van 1024 GB ontvangt gratis 3072 IOPS. U kunt ervoor kiezen om uw IOPS te verhogen tot aan de VM-limiet voor extra kosten.

Wanneer u deze servicelaag kiest

Kies deze servicelaag als uw bedrijf budgetgericht is, maar de metrische prestatiegegevens en limieten van de servicelaag Algemeen gebruik onvoldoende zijn.

De belangrijkste redenen waarom u de servicelaag Next-gen Algemeen gebruik zou moeten kiezen in plaats van de servicelaag Algemeen gebruik, zijn:

  • Betere prestaties voor dezelfde basislijnkosten
  • Verbeterde latentie, doorvoer en IOPS
  • Grotere opslagcapaciteit
  • Meer flexibiliteit voor uw rekenproces
  • U hebt meer dan 100 databases nodig voor één exemplaar
  • U hebt meer dan 16 TB gereserveerde opslag nodig

Bedrijfskritisch

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

In het bedrijfskritieke model worden berekeningen 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.

diagram met het cluster van database-engineknooppunten.

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.

Daarnaast beschikt de bedrijfskritieke cluster over een ingebouwde lees-schaalvergroting die een gratis alleen-lezen replica biedt dat wordt gebruikt om alleen-lezenquery's (zoals rapporten) uit te voeren, die geen invloed hebben op de prestaties van de workload op uw primaire replica.

Wanneer u deze servicelaag kiest

De servicelaag Bedrijfskritiek is ontworpen voor toepassingen die reacties met lage latentie van de onderliggende SSD-opslag (gemiddeld 1-2 ms) vereisen, sneller herstel willen bij uitval van de onderliggende infrastructuur, of rapporten, analyses en alleen-lezen query's kunnen uitbesteden aan de gratis leesbare secundaire replica van de primaire database.

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

  • lage I/O-latentievereisten: werkbelastingen die een snelle reactie van de opslaglaag (gemiddeld 1-2 milliseconden) nodig hebben, moeten de laag Bedrijfskritiek gebruiken.
  • Workload voor rapportage- en analysequeries die kunnen worden omgeleid naar de kosteloze secundaire alleen-lezen replica.
  • 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 Gegevenscorruptiebescherming. Omdat de bedrijfskritieke laag achter de schermen gebruikmaakt van databasesreplica's, maakt de service gebruik van automatisch paginaherstel dat beschikbaar is met spiegelings- en beschikbaarheidsgroepen om gegevensbeschadiging 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 bedrijfskritieke laag in een configuratie met meerdere beschikbaarheidszones biedt tolerantie voor zonefouten en een SLA voor hogere beschikbaarheid.
  • Fast geo-herstel: als een failovergroep is geconfigureerd, heeft de laag Bedrijfskritiek een gegarandeerdE RPO (Recovery Point Objective) van 5 seconden en RTO (Recovery Time Objective) van 30 seconden gedurende 100% 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:

Apparatuur Naam
Algemeen gebruik AlgemeneDoeleinden
Bedrijfskritiek BusinessCritical

Hoge beschikbaarheid

Azure SQL Managed Instance bereikt standaard beschikbaarheid via lokale redundantie, waardoor uw exemplaar beschikbaar is tijdens onderhoudsbewerkingen, problemen met storingen in het datacenter en andere problemen met de SQL-database-engine. Als u echter een mogelijke storing in een hele zone wilt minimaliseren die van invloed is op uw gegevens, kunt u hoge beschikbaarheid bereiken door zoneredundantie in te schakelen. Zonder zoneredundantie worden failovers lokaal uitgevoerd binnen hetzelfde datacenter, wat ertoe kan leiden dat uw exemplaar niet beschikbaar is totdat de storing is opgelost. De enige manier om te herstellen is via een oplossing voor herstel na noodgevallen, zoals via een failovergroep, of een geo-herstel van een geografisch redundante back-up.

Hardwareconfiguraties

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

Zie Hardwareconfiguratiekenmerkenvoor meer informatie over de specifieke hardwareconfiguratie 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)-processors die worden gebruikt door de premium-serie en de premium-serie met geoptimaliseerd geheugen 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 sql Managed Instance-

Zie Een sql Managed Instance makenvoor gedetailleerde informatie.

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

schermopname van Azure Portal waarin wordt weergegeven waar u SQL Managed Instance kunt configureren.

Hardware van een bestaand sql Managed Instance- wijzigen

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

Schermopname van de Azure-portal met de pagina Compute + opslag voor 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:

Apparatuur Naam
Standard-series (Gen5) Gen5
Premium-serie G8IM
Geheugen-geoptimaliseerde premium-serie G8IH

SKU-namen

Notitie

Wanneer u hardware- en servicelaag opgeeft 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-serie
GP_G8IH Algemeen gebruik Geoptimaliseerd voor geheugen uit de Premium-serie
BC_Gen5 Bedrijfskritisch Standaardserie
BC_G8IM Bedrijfskritisch Premium-serie
BC_G8IH Bedrijfskritisch Geoptimaliseerd voor geheugen uit de Premium-serie

Beschikbaarheid van hardware

Standard-series (Gen5) en premium-series

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 van Azure SQL Managed Instancevoor meer informatie.

Verwante inhoud