Delen via


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

Van toepassing op: Azure SQL Database

Elastische pools van Azure SQL Database zijn een eenvoudige, rendabele oplossing voor het beheren en schalen van meerdere databases met verschillende en onvoorspelbare gebruiksvereisten. De databases in een elastische pool bevinden zich op één server en delen een vast aantal resources tegen een vaste prijs. Elastische pools in SQL Database stellen SaaS-ontwikkelaars (Software-as-a-Service) in staat om de prijsprestaties voor een groep databases binnen een voorgeschreven budget te optimaliseren en tegelijkertijd prestatie-elasticiteit voor elke database te leveren.

Wat zijn elastische SQL-pools?

SaaS-ontwikkelaars bouwen toepassingen boven op grootschalige gegevenslagen met meerdere databases. Een typisch toepassingspatroon is het inrichten van één database voor elke klant. Verschillende klanten hebben echter vaak verschillende en onvoorspelbare gebruikspatronen en het is moeilijk om de resourcevereisten van elke databasegebruiker te voorspellen. Traditioneel had u twee opties:

  • Overprovision resources op basis van piekgebruik en overbetalen.
  • Onderbebouwing 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 ze nodig hebben. Ze bieden een eenvoudig mechanisme voor het toewijzen van resources binnen een voorspelbaar budget. Zie Ontwerppatronen voor multitenant SaaS-toepassingen met SQL Database voor meer informatie over ontwerppatronen voor SaaS-toepassingen met elastische pools.

Belangrijk

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

Met elastische pools kunt u resources aanschaffen voor een pool die wordt gedeeld door meerdere databases om onvoorspelbare gebruiksperioden 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. Het geaggregeerde gebruik van de databases bepaalt de resourcevereiste voor een pool.

De hoeveelheid resources die beschikbaar zijn voor de pool, wordt bepaald door uw budget. U hoeft alleen maar te doen:

  • Voeg databases toe aan de pool.
  • U kunt desgewenst de minimale en maximale resources voor de databases instellen. Deze resources zijn een minimum- en maximum aantal DTU's of een minimum- of maximum aantal vCores, afhankelijk van uw keuze voor het bronmodel.
  • Stel de resources van de pool in op basis van uw budget.

U kunt pools gebruiken om uw service naadloos te laten groeien van een lean startup tot een volwassen bedrijf op een steeds grotere schaal.

Binnen de pool hebben afzonderlijke databases de flexibiliteit om resources te gebruiken binnen ingestelde parameters. Bij zware belasting kan een database meer resources verbruiken om aan de vraag te voldoen. Databases onder lichte belastingen 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.

Er kunnen meer resources worden toegevoegd aan een bestaande pool met minimale downtime. Als er geen extra resources meer nodig zijn, kunnen ze op elk gewenst moment uit een bestaande pool worden verwijderd. U kunt ook databases toevoegen aan of verwijderen uit de pool. Als een database voorspelbaar onderbenutting van resources is, kunt u deze verplaatsen.

Notitie

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

Wanneer moet u een elastische SQL Database-pool overwegen?

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

Hoe meer databases u aan een pool kunt toevoegen, hoe groter uw besparingen. Afhankelijk van uw toepassingsgebruikspatroon 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 worden Standard-pools gebruikt, maar dezelfde principes zijn van toepassing op elastische pools in andere servicelagen.

Patronen voor databasegebruik beoordelen

In de volgende afbeelding ziet u een voorbeeld van een database die veel van de niet-actieve tijd doorbrengt, maar periodiek piekt met activiteit. Dit gebruikspatroon is geschikt voor een pool.

Chart that shows a single database suitable for a pool.

De grafiek illustreert het DTU-gebruik van meer dan één uur van 12:00 tot 1:00, waarbij elk gegevenspunt granulariteit van één minuut heeft. Om 12:10 piekt DB1 tot 90 DTU's, maar het totale gemiddelde gebruik is minder dan vijf DTU's. Er is een S3-rekenkracht vereist voor het uitvoeren van deze workload in één database, maar deze grootte laat de meeste resources ongebruikt tijdens perioden met een lage activiteit.

Met een pool kunnen deze ongebruikte DTU's worden gedeeld tussen meerdere databases. Een pool vermindert de benodigde DTU's en de totale kosten.

Stel dat andere databases vergelijkbare gebruikspatronen hebben als DB1 op basis van het vorige voorbeeld. In de volgende twee cijfers wordt het gebruik van 4 databases en 20 databases gelaagd in dezelfde grafiek om de niet-overlapping van hun gebruik in de loop van de tijd te illustreren met behulp van het aankoopmodel op basis van DTU:

Chart that shows four databases with a utilization pattern suitable for a pool.

Chart that shows 20 databases with a utilization pattern suitable for a pool.

De zwarte lijn in de voorgaande grafiek illustreert het cumulatieve DTU-gebruik voor alle 20 databases. Deze regel laat zien dat het cumulatieve DTU-gebruik nooit meer dan 100 DTU's overschrijdt en aangeeft dat de 20 databases gedurende deze periode 100 eDTU's kunnen delen. Het resultaat is een vermindering van 20 tijd in DTU's en een prijsvermindering van 13 keer ten opzichte van het plaatsen van elke database in S3-rekengrootten voor individuele databases.

Dit voorbeeld is ideaal omdat:

  • 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 eDTU-eenheidsprijs voor een pool 1,5 keer groter is dan de DTU-eenheidsprijs voor een individuele database, kunnen eDTU's worden gedeeld door veel databases en zijn er 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 aankoopmodel van vCore is de prijs van vCore-eenheden voor elastische pools hetzelfde als de prijs voor vCore-eenheden voor individuele databases.

Hoe kan ik de juiste poolgrootte kiezen?

De beste grootte voor een pool is afhankelijk van de geaggregeerde resources die nodig zijn voor alle databases in de pool. U moet het volgende bepalen:

  • Maximale rekenresources die worden gebruikt door alle databases in de pool. Rekenresources worden geïndexeerd door eDTU's of vCores, afhankelijk van uw keuze voor 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.

Notitie

Elastische pools voor Hyperscale zijn momenteel beschikbaar als preview-versie.

Met de volgende stappen kunt u inschatten of een pool rendabeler is dan individuele databases:

  1. Maak een schatting van de eDTU's of vCores die nodig zijn voor de pool:

    1. Voor het aankoopmodel op basis van DTU:
      1. MAX(<Totaal aantal DB's × gemiddeld DTU-gebruik per DB>,< aantal gelijktijdig piekende DB's × piekgebruik per DB>)
    2. Voor het aankoopmodel op basis van vCore:
      1. MAX(<Totaal aantal DB's × Gemiddeld vCore-gebruik per DB>,< aantal gelijktijdig piekende DB's × Piek in vCore-gebruik per DB>)
  2. Schat hoeveel totale opslagruimte de groep nodig heeft door de gegevensgrootte op te tellen dat nodig is voor alle databases in de groep. Bepaal voor het DTU-aankoopmodel de grootte van de eDTU-pool die deze hoeveelheid opslagruimte biedt.

  3. Neem voor het aankoopmodel op basis van DTU de grootste eDTU-schattingen uit stap 1 en stap 2.

    1. Voor het aankoopmodel op basis van vCore neem je de vCore-schatting uit stap 1.
  4. Zie de pagina met prijzen voor SQL Database.

    1. Zoek de kleinste poolgrootte die groter is dan de schatting uit stap 3.
  5. Vergelijk de poolprijs van stap 4 met behulp van de juiste rekengrootten voor individuele databases.

Belangrijk

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

Eigenschappen per database

U kunt desgewenst eigenschappen per database 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 SQL Database-functies gebruiken met elastische pools

U kunt andere SQL Database-functies gebruiken met elastische pools.

Elastische taken en elastische pools

Met een groep worden beheertaken vereenvoudigd door scripts in elastische taken uit te voeren. Een elastische taak elimineert het grootste deel van het tedium dat is gekoppeld aan grote aantallen databases.

Zie Uitschalen met 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

Gegroepeerde databases ondersteunen over het algemeen dezelfde functies voor bedrijfscontinuïteit die beschikbaar zijn voor individuele databases:

  • Herstel naar een bepaald 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 standaardhersteloptie wanneer een database niet beschikbaar is vanwege een incident in de regio waar de database wordt gehost. Zie Geo-herstel.
  • Actieve geo-replicatie: Voor toepassingen met agressievere herstelvereisten dan geo-herstel kan bieden, configureert u actieve geo-replicatie of een failovergroep.

Zie de richtlijnen voor herstel na noodgevallen van Azure SQL Database voor meer informatie over de bovenstaande strategieën.

Een nieuwe elastische SQL Database-pool maken met behulp van Azure Portal

U kunt op twee manieren een elastische pool maken in Azure Portal:

  • Maak een elastische pool en selecteer een bestaande of nieuwe server.
  • Maak een elastische pool van een bestaande server.

Een elastische pool maken en een bestaande of nieuwe server selecteren:

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

  2. Selecteer Maken om het deelvenster Sql-implementatie selecteren te openen. Als u meer informatie over elastische pools wilt weergeven, selecteert u op de tegel Databases de optie Details weergeven.

  3. Selecteer Elastische pool in de vervolgkeuzelijst Resourcetype op de tegel Databases. Selecteer vervolgens Maken.

    Screenshot that shows creating an elastic pool.

Een elastische pool maken op een bestaande server:

  • Ga naar een bestaande server en selecteer Nieuwe pool om rechtstreeks op die server een pool te maken.

Notitie

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

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

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

Nadat u de pool hebt geconfigureerd, selecteert u Toepassen, noemt u de pool en selecteert u OK om de pool te maken.

Een elastische pool en de bijbehorende databases bewaken

In 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 waarschuwingen gebruiken in combinatie met prestatieclassificaties. SQL Database kan ook metrische gegevens en resourcelogboeken verzenden voor eenvoudigere bewaking.

Casestudy's van klanten

`- SnelStart: SnelStart heeft elastische pools met SQL Database gebruikt om de bedrijfsservices snel uit te breiden met een snelheid van 1000 nieuwe SQL-databases per maand.

  • Umbraco: Umbraco maakt gebruik van elastische pools met SQL Database om snel services in te richten en te schalen voor duizenden tenants in de cloud.
  • Daxko/CSI: Daxko/CSI maakt gebruik van elastische pools met SQL Database om de ontwikkelingscyclus te versnellen en de klantenservice en prestaties te verbeteren.