Aankoopmodellen, servicelagen en hardwareopties

Voltooid

Nadat u een idee hebt gekregen over welke implementatieoptie het beste bij uw vereisten past, Moet u bepalen welk aankoopmodel en welk servicelaag en hardware u wilt gebruiken. In deze les vindt u een overzicht van de aankoopopties en wanneer u deze kunt kiezen.

Aankoopmodel

Het aankoopmodel van Azure SQL biedt twee opties:

  • Kopen op basis van virtuele kernen (op basis van vCore)
  • Aanschaffen op basis van databasetransactie-eenheden (op basis van DTU)

Het DTU-model is niet beschikbaar in Azure SQL Managed Instance.

We raden het vCore-model aan, omdat u hiermee onafhankelijk reken- en opslagresources kunt selecteren. Het DTU-model is een gebundelde meting van reken-, opslag- en I/O-resources.

In het vCore-model betaalt u voor:

  • Rekenresources: de servicelaag plus het aantal vCores en de hoeveelheid geheugen plus de generatie van hardware.
  • Gegevens- en logboekopslag: het type en de hoeveelheid gegevens en logboekopslag.
  • Locatie van back-upopslag: geografisch redundante opslag met leestoegang (RA-GRS), zone-redundante opslag (ZRS) of lokaal redundante opslag (LRS).

Met het vCore-model kunt u ook Azure Hybrid Benefit voor SQL Server en/of gereserveerde capaciteit (vooraf betalen) gebruiken om geld te besparen. Geen van beide opties zijn beschikbaar in het DTU-model.

Deze module is gericht op het vCore-aankoopmodel.

Servicelaag

Vervolgens moet u een servicelaag kiezen voor prestaties en beschikbaarheid. U wordt aangeraden om te beginnen met de laag Algemeen en deze zo nodig aan te passen. Er zijn drie lagen beschikbaar in het vCore-model:

  • Algemeen gebruik: geschikt voor de meeste zakelijke workloads. Biedt budgetgerichte, gebalanceerde en schaalbare reken- en opslagopties.
  • Bedrijfskritiek: Geschikt voor zakelijke toepassingen met responsvereisten met lage latentie. Biedt de hoogste flexibiliteit bij storingen door gebruik te maken van verschillende geïsoleerde replica's. Deze laag is de enige die OLTP (online transactionele verwerking) in het geheugen kan gebruiken om de prestaties te verbeteren.
  • Hyperscale: Geschikt voor zakelijke workloads met zeer schaalbare opslag (100 TB+) en vereisten voor leesschaal. Vanuit het oogpunt van prestaties en kosten valt deze laag tussen Algemeen en Bedrijfskritiek. Hyperscale is momenteel alleen beschikbaar voor individuele databases in Azure SQL Database.

Compute-laag

Als u de laag Algemeen gebruik en het vCore-model kiest, moet u nog een beslissing nemen met betrekking tot de rekenlaag waarvoor u betaalt:

  • Ingerichte rekenkracht is bedoeld voor meer reguliere gebruikspatronen met na verloop van tijd een hoger gemiddelde rekengebruik of meerdere databases die gebruikmaken van elastische pools. Ingerichte rekenkracht biedt een vaste hoeveelheid resources in de loop van de tijd om optimale prestaties te garanderen en wordt gefactureerd voor deze resources, ongeacht het gebruik. Bij ingerichte berekeningen moet u de grootte van rekenresources voor uw workload beheren.
  • Serverloze rekenkracht is bedoeld voor onregelmatig, onvoorspelbaar gebruik met na verloop van tijd een lager gemiddeld rekengebruik. Serverloos biedt automatisch schalen van rekenkracht om prestatiebeheer te vereenvoudigen en wordt alleen gefactureerd voor de hoeveelheid gebruikte rekenkracht. Serverloos biedt ook ondersteuning voor automatisch onderbreken en hervatten om verdere prijsoptimalisatie te helpen. Als uw database wordt onderbroken, betaalt u alleen voor opslag.

Hardware

De standaardhardwaregeneratie op dit moment wordt standaardhardware genoemd, voorheen Gen5 genoemd. Premium-serie hardware biedt de nieuwste en beste premium opslag- en rekenhardware.

Als u Algemeen in SQL Database kiest en de serverloze rekenlaag wilt gebruiken, is Gen5-hardware momenteel de enige optie. Deze kan momenteel worden opgeschaald naar 40 vCores.

Het aankoopmodel, de servicelaag en de hardwareselecties die u maakt, hebben een aanzienlijke invloed op de prestaties, beschikbaarheid en kosten van uw implementatie.

Kenniscontrole

1.

U verplaatst een toepassing en database naar Azure, maar uw database is momenteel 62 TB en blijft groeien. U maakt momenteel geen gebruik van functies binnen het bereik van het exemplaar. Welke implementatieoptie voor Azure SQL is het makkelijkst te gebruiken?

2.

Stel dat u Azure SQL Database hebt waarop een database met de serverloze rekenlaag is geïmplementeerd en dat er een vertraging voor automatisch onderbreken van twee uur is. Wat gebeurt er na twee uur zonder activiteit met uw database en in rekening gebrachte kosten?