Meerdere databases in Azure SQL Database beheren en schalen met elastische pools

VAN TOEPASSING OP: Azure SQL Database

Azure SQL Database elastische pools zijn een eenvoudige, rendabele oplossing voor het beheren en schalen van meerdere databases met verschillende en onvoorspelbare gebruikseisen. De databases in een elastische pool staan op één server en delen een vast aantal resources tegen een vast prijs. Met elastische groepen in Azure SQL Database kunnen SaaS-ontwikkelaars de prijsprestaties voor een groep databases binnen een voorgeschreven budget optimaliseren en flexibele prestaties voor elke database leveren.

Wat zijn SQL elastische pools?

SaaS-ontwikkelaars ontwikkelen toepassingen boven op grootschalige gegevenslagen die uit meerdere databases bestaan. Een algemeen patroon is de inrichting van een individuele database voor elke klant. Maar verschillende klanten hebben vaak verschillende en onvoorspelbare gebruikspatronen en het is moeilijk om de resourcevereisten van elke afzonderlijke databasegebruiker te voorspellen. Van oudsher had u twee opties:

  • Resources te ruim inrichten op basis van piekgebruik en meer dan betalen, of
  • Te lage inrichting om kosten te besparen, ten koste van prestaties en klanttevredenheid tijdens pieken.

Elastische pools lossen dit probleem op door ervoor te zorgen dat databases de prestatiebronnen krijgen die ze nodig hebben wanneer ze het nodig hebben. Ze bieden een eenvoudig mechanisme voor het toewijzen van resources binnen een voorspelbaar budget. Zie Ontwerppatronen voor SaaS-toepassingen met meerdere tenants met behulp van Azure SQL Database voor meer informatie over ontwerppatronen voor SaaS-toepassingen met elastische pools.

Belangrijk

Er worden geen kosten per database in rekening brengen voor elastische pools. U wordt gefactureerd voor elk uur dat een pool bestaat met de hoogste eDTU of vCores, ongeacht het gebruik of of de pool minder dan een uur actief was.

Met elastische pools kan de ontwikkelaar resources aanschaffen voor een pool die wordt gedeeld door meerdere databases om onvoorspelbare perioden van gebruik door afzonderlijke databases mogelijk te maken. U kunt resources voor de pool configureren op basis van het aankoopmodel op basis van DTU of het aankoopmodel op basis van vCore. De resourcevereiste voor een pool wordt bepaald door het cumulatief gebruik van de databases. De hoeveelheid resources die beschikbaar is voor de pool wordt bepaald door het budget van de ontwikkelaar. De ontwikkelaar voegt gewoon databases toe aan de pool, stelt desgewenst de minimale en maximale resources voor de databases in (minimaal en maximaal aantal DTUs of minimum- of maximum-vCores, afhankelijk van uw keuze van het resourcing-model), en stelt vervolgens de resources van de pool in op basis van het budget. Met groepen kan een ontwikkelaar services naadloos met een alsmaar groeiende schaal uitbreiden van een kleine startende ondernemer tot een volwassen bedrijf.

Binnen de pool hebben afzonderlijke databases de flexibiliteit om de schaal automatisch aan te passen binnen ingestelde parameters. Bij zware belasting kan een database meer resources verbruiken om aan de vraag te voldoen. Databases bij lichte belasting verbruiken minder en databases zonder belasting verbruiken geen resources. De inrichting van resources voor de hele pool in plaats van afzonderlijke databases vereenvoudigt uw beheertaken. Bovendien hebt u een voorspelbaar budget voor de pool. Extra resources kunnen worden toegevoegd aan een bestaande pool met minimale downtime. En als er geen extra resources meer nodig zijn, kunnen ze op elk gewenst moment uit een bestaande pool worden verwijderd. En u kunt databases toevoegen aan of verwijderen uit de pool. Als een database naar verwachting minder resources nodig heeft, kunt u deze verwijderen.

Notitie

Wanneer u databases naar of uit een elastische pool verplaatst, is er geen downtime, met uitzondering van een korte periode (in volgorde van seconden) aan het einde van de bewerking wanneer databaseverbindingen worden verwijderd.

Wanneer moet u een elastische SQL Database overwegen

Pools zijn geschikt voor een groot aantal databases met specifieke gebruikspatronen. Voor een bepaalde database wordt dit patroon gekenmerkt door een laag gemiddeld gebruik met relatief incidentele gebruikspieken. Daarentegen mogen meerdere databases met een permanent gemiddeld hoog gebruik niet in dezelfde elastische pool worden geplaatst.

Hoe meer databases u aan een groep kunt toevoegen, des te groter worden de besparingen. Afhankelijk van het gebruikspatroon van uw toepassing is het mogelijk om besparingen te zien met slechts twee S3-databases.

In de volgende secties ziet u hoe u kunt bepalen of het voor uw specifieke verzameling databases voordelig is om deel uit te maken van een groep. In de voorbeelden wordt gebruik gemaakt van Standard-groepen, maar dezelfde principes gelden ook voor Basic- en Premium-groepen.

Databasegebruikspatronen beoordelen

De volgende afbeelding toont een voorbeeld van een database die doorgaans weinig wordt gebruikt, maar bij soms ook extreem actief is. Dit is een gebruikspatroon dat geschikt is voor een groep:

een individuele database die geschikt is voor een groep

De grafiek illustreert het DTU-gebruik gedurende een periode van 1 uur van 12:00 tot 1:00, waarbij elk gegevenspunt een granulariteit van 1 minuut heeft. Om 12:10 piekt DB1 tot 90 DTUs, maar het totale gemiddelde gebruik is minder dan vijf DTUs. Een S3-rekenkracht is vereist om deze workload in één database uit te voeren, maar hierdoor worden de meeste resources ongebruikt tijdens perioden van weinig activiteit.

Met een groep kunnen deze ongebruikte DTU’s worden gedeeld met meerdere databases, wat de benodigde DTU's en de totale kosten vermindert.

Stel dat er in het vorige voorbeeld meer databases zijn die een soortgelijk gebruikspatroon hebben als DB1. In de volgende twee onderstaande afbeeldingen wordt het gebruik van vier databases en 20 databases in dezelfde grafiek gelaagd om de niet-overlappende aard van hun gebruik gedurende een periode te illustreren met behulp van het aankoopmodel op basis van DTU:

vier databases met een gebruikspatroon dat geschikt is voor een groep

twintig databases met een gebruikspatroon dat geschikt is voor een groep

Het gezamenlijke DTU-gebruik van alle 20 databases wordt aangegeven door de zwarte lijn in voorgaande afbeelding. U ziet dat het totale DTU-gebruik nooit hoger is dan honderd DTU’s en dat de twintig databases gedurende deze periode honderd eDTU's kunnen delen. Dit resulteert in een 20x-reductie in DTUs en een prijsvermindering van 13x in vergelijking met het plaatsen van elk van de databases in S3-rekengrootten voor individuele databases.

Dit voorbeeld is om de volgende redenen ideaal:

  • Er zijn grote verschillen tussen piekgebruik en gemiddeld gebruik per database.
  • Het piekgebruik voor elke database vindt plaats op verschillende momenten.
  • eDTU‘s worden gedeeld tussen meerdere databases.

In het DTU-aankoopmodel is de prijs van een pool een functie van de eDTU's van de pool. Hoewel de prijs per eDTU voor een groep 1,5 x groter is dan de prijs per DTU voor een individuele database, kunnen eDTU's in een groep door veel databases worden gedeeld en zijn er dus minder eDTU's nodig. Deze verschillen in prijsbepaling en het delen van eDTU's vormen de basis van de mogelijke prijsbesparing die groepen kunnen bieden.

In het vCore-aankoopmodel is de prijs van de vCore-eenheid voor elastische pools gelijk aan de prijs van de vCore-eenheid voor individuele databases.

Hoe kan ik juiste poolgrootte kiezen

De beste grootte voor een pool is afhankelijk van de cumulatief benodigde resources voor alle databases in de pool. Dit omvat het bepalen van het volgende:

  • Het maximale aantal rekenbronnen dat door alle databases in de pool wordt gebruikt. Rekenbronnen worden geïndexeerd door eDTUs of vCores, afhankelijk van uw keuze van het aankoopmodel.
  • De maximum opslag in bytes die door alle databases in de groep wordt gebruikt.

Zie het aankoopmodel op basis van DTU of het aankoopmodel op basis van vCore voor servicelagen en resourcelimieten in elk aankoopmodel.

De volgende stappen kunnen u helpen bij het schatten of een pool rendabeler is dan individuele databases:

  1. Schat als volgt de eDTUs of vCores die nodig zijn voor de pool:
    • Voor het aankoopmodel op basis van DTU:
      • MAX(<Totaal aantal DB's Gemiddeld DTU-gebruik per DB->, <Aantal gelijktijdig piekende DB's Piek × DTU-gebruik per × DB->)
    • Voor het aankoopmodel op basis van vCore:
      • MAX(<Totaal aantal DB's Gemiddeld × vCore-gebruik per DB->, <Aantal gelijktijdig piekende DB's Piek × vCore-gebruik per DB->)
  2. Schat de totale opslagruimte die nodig is voor de pool door de gegevensgrootte toe te voegen die nodig is voor alle databases in de pool. Bepaal voor het DTU-aankoopmodel vervolgens de eDTU-poolgrootte die deze hoeveelheid opslag biedt.
  3. Voor het aankoopmodel op basis van DTU neemt u het grootste deel van de eDTU-schattingen uit stap 1 en stap 2. Voor het aankoopmodel op basis van vCore gebruikt u de vCore-schatting uit stap 1.
  4. Zie de SQL Database pagina met prijzen en zoek de kleinste poolgrootte die groter is dan de schatting uit stap 3.
  5. Vergelijk de poolprijs uit stap 4 met de prijs van het gebruik van de juiste rekenkracht voor individuele databases.

Belangrijk

Als het aantal databases in een pool het maximaal ondersteunde aantal nadert, moet u Resourcebeheer overwegen in compacte elastische pools.

Eigenschappen per database

U kunt eventueel 'per database'-eigenschappen instellen om patronen voor resourceverbruik in elastische pools te wijzigen. Zie de documentatie over resourcelimieten voor elastische DTU- en vCore-pools voor meer informatie.

Andere functies SQL Database elastische pools gebruiken

Elastische taken en elastische pools

Met een groep worden beheertaken vereenvoudigd door scripts in elastische taken uit te voeren. Een elastische taak elimineert de meeste saaie handelingen die komen kijken bij grote aantallen databases.

Zie Scaling out with Azure SQL Database (Uitbreiden met Azure SQL Database) voor meer informatie over andere databasehulpprogramma's voor het werken met meerdere databases.

Opties voor bedrijfscontinuïteit voor databases in een elastische pool

Pooldatabases ondersteunen in het algemeen dezelfde bedrijfscontinuïteitsfuncties die beschikbaar zijn voor individuele databases.

  • Terugzetten naar eerder tijdstip

    Herstel naar een bepaald tijdstip maakt gebruik van automatische databaseback-ups om een database in een pool te herstellen naar een bepaald tijdstip. Zie Herstel naar een bepaald tijdstip

  • Geo-herstel

    Geo-herstel biedt de standaardoptie voor herstel wanneer een database niet beschikbaar is vanwege een incident in de regio waar de database wordt gehost. Zie Een Azure SQL Database of failover herstellen naar een secundaire

  • Actieve geo-replicatie

    Voor toepassingen met agressievere herstelvereisten dan geo-herstel kan bieden, configureert u Actieve geo-replicatie of een groep voor automatische failover.

Een nieuwe elastische SQL Database maken met behulp van de Azure Portal

Er zijn twee manieren waarop u een elastische pool in de Azure Portal.

  1. Ga naar de Azure Portal een elastische pool te maken. Zoek en selecteer Azure SQL.

  2. Selecteer +Toevoegen om de pagina SQL-implementatieoptie selecteren te openen. U kunt aanvullende informatie over elastische pools weergeven door Details weergeven te selecteren op de tegel Databases.

  3. Selecteer op de tegel Databases de optie Elastische pool in de vervolgkeuzekeuzebank Resourcetype en selecteer vervolgens Maken:

    Een elastische pool maken

  4. U kunt ook een elastische pool maken door naar een bestaande server te navigeren en op + Nieuwe pool te klikken om een pool rechtstreeks op die server te maken.

Notitie

U kunt meerdere pools op een server maken, maar u kunt geen databases van verschillende servers toevoegen aan dezelfde groep.

De servicelaag van de pool bepaalt de functies die beschikbaar zijn voor de elastics in de pool en de maximale hoeveelheid resources die beschikbaar is voor elke database. Zie Resourcelimieten voor elastische pools in het DTU-model voor meer informatie. Zie vCore-resourcelimieten - elastischepools voor resourcelimieten op basis van vCore voor resourcelimieten voor elastische pools.

Als u de resources en prijzen van de pool wilt configureren, klikt u op Groep configureren. Selecteer vervolgens een servicelaag, voeg databases toe aan de pool en configureer de resourcelimieten voor de pool en de databases ervan.

Wanneer u klaar bent met het configureren van de pool, kunt u op Toepassen klikken, de pool een naam geven en op OK klikken om de pool te maken.

Een elastische pool en de databases ervan bewaken

In de Azure Portal kunt u het gebruik van een elastische pool en de databases in die pool bewaken. U kunt ook een set wijzigingen aanbrengen in uw elastische pool en alle wijzigingen tegelijk verzenden. Deze wijzigingen omvatten het toevoegen of verwijderen van databases, het wijzigen van de instellingen van uw elastische pool of het wijzigen van uw database-instellingen.

U kunt de ingebouwde hulpprogramma's voor prestatiebewaking en waarschuwingengebruiken in combinatie met prestatiebeoordelingen. Daarnaast kan SQL Database metrische gegevens en resourcelogboeken verzenden die bewaking eenvoudiger maken.

Casestudy's van klanten

  • SnelStart

    SnelStart gebruikte elastische pools met Azure SQL Database om de bedrijfsservices snel uit te breiden met een snelheid van 1000 nieuwe Azure SQL-databases per maand.

  • Umbraco

    Umbraco maakt gebruik van elastische pools Azure SQL Database om snel services in terichten en te schalen voor duizenden tenants in de cloud.

  • Daxko/CSI

    Daxko/CSI maakt gebruik van elastische pools met Azure SQL Database om de ontwikkelingscyclus te versnellen en de services en prestaties van de klant te verbeteren.

Volgende stappen