Resourcebeheer in dichte elastische pools

VAN TOEPASSING OP: Azure SQL Database

Azure SQL Database elastische pools is een rendabele oplossing voor het beheren van veel databases met verschillend resourcegebruik. Alle databases in een elastische pool delen dezelfde toewijzing van resources, zoals CPU, geheugen, werkthreads, opslagruimte, tempdb, ervan uitgegaan dat slechts een subset van databases in de pool op een bepaald moment rekenbronnen gebruikt. Met deze veronderstelling kunnen elastische pools rendabel zijn. In plaats van te betalen voor alle resources die elke afzonderlijke database mogelijk nodig kan hebben, betalen klanten voor een veel kleinere set resources, die worden gedeeld met alle databases in de pool.

Resourcebeheer

Voor het delen van resources moet het systeem het resourcegebruik zorgvuldig beheren om het 'ruiseffect' te minimaliseren, waarbij een database met een hoog resourceverbruik van invloed is op andere databases in dezelfde elastische pool. Tegelijkertijd moet het systeem voldoende resources bieden voor functies zoals hoge beschikbaarheid en herstel na noodherstel (HADR), back-up en herstel, bewaking, Query Store, Automatisch afstemmen, enzovoort om betrouwbaar te kunnen werken.

Azure SQL Database bereikt deze doelstellingen met behulp van meerdere mechanismen voor resourcebeheer, waaronder Windows-taakobjecten voor resourcebeheer op procesniveau, Windows Bestandsserver Resource Manager (FSRM) voor opslagquotumbeheer en een gewijzigde en uitgebreide versie van SQL Server Resource Governor om te implementeren resourcebeheer binnen SQL Database.

Het primaire ontwerpdoel van elastische pools is kosteneffectief te zijn. Daarom stelt het systeem klanten opzettelijk in staat om compacte pools te maken, dat wil zeggen pools met het aantal databases dat bijna of maximaal is toegestaan, maar met een matige toewijzing van rekenbronnen. Om dezelfde reden reserveert het systeem niet alle mogelijk benodigde resources voor de interne processen, maar staat het delen van resources toe tussen interne processen en gebruikersworkloads.

Met deze aanpak kunnen klanten compacte elastische pools gebruiken om voldoende prestaties en grote kostenbesparingen te realiseren. Als de werkbelasting voor veel databases in een compacte pool echter voldoende intensief is, wordt het aantal resource-verschillen aanzienlijk. Resource-inhoud vermindert de prestaties van de werkbelasting van gebruikers en kan een negatieve invloed hebben op interne processen.

Wanneer er resource-problemen optreden in een dicht verpakte pool, kunnen klanten een of meer van de volgende acties kiezen om deze te beperken:

• Werkbelasting van query's afstemmen om het resourceverbruik te verminderen of het resourceverbruik over meerdere databases in de tijd te spreiden.
• Verminder de pooldichtheid door sommige databases naar een andere pool te verplaatsen of door zelfstandige databases te maken.
• Schaal de pool omhoog om meer resources te krijgen.

Zie Operationele aanbevelingen verder in dit artikel voor suggesties over het implementeren van de laatste twee acties. Het verminderen van resource-problemen heeft voordelen voor zowel gebruikersworkloads als interne processen, en zorgt ervoor dat het systeem het verwachte serviceniveau betrouwbaar kan handhaven.

Resourceverbruik bewaken

Om prestatievermindering als gevolg van resource-problemen te voorkomen, moeten klanten die gebruikmaken van compacte elastische pools het resourceverbruik proactief bewaken en tijdig actie ondernemen als toenemende resource-problemen van invloed zijn op workloads. Continue bewaking is belangrijk omdat het resourcegebruik in een pool na een bepaalde periode verandert als gevolg van wijzigingen in de werkbelasting van de gebruiker, wijzigingen in gegevensvolumes en distributie, wijzigingen in de pooldichtheid en wijzigingen in de Azure SQL Database service.

Azure SQL Database biedt verschillende metrische gegevens die relevant zijn voor dit type bewaking. Het overschrijden van de aanbevolen gemiddelde waarde voor elke metrische waarde duidt op resource-problemen in de pool en moet worden verholpen met behulp van een van de eerder genoemde acties.

Naast deze metrische gegevens biedt Azure SQL Database een weergave die werkelijke limieten voor resourcebeheer retourneert, evenals aanvullende weergaven die statistieken over resourcegebruik retourneren op het niveau van de resourcegroep en op het niveau van de werkbelastinggroep.

Deze weergaven kunnen worden gebruikt om het resourcegebruik te bewaken en problemen met resourceproblemen in bijna realtime op te lossen. De werkbelasting van de gebruiker op de primaire en leesbare secundaire replica's, inclusief geo-replica's, wordt geclassificeerd in de resourcegroep en werkbelastinggroep, waarbij staat voor de SloSharedPool1 UserPrimaryGroup.DBId[N] N database-id-waarde.

Naast het bewaken van het huidige resourcegebruik, kunnen klanten die gebruikmaken van compacte pools, historische gegevens over resourcegebruik in een afzonderlijk gegevensopslag bewaren. Deze gegevens kunnen worden gebruikt in voorspellende analyses om het resourcegebruik proactief te beheren op basis van historische en seizoensgebonden trends.

Operationele aanbevelingen

Laat voldoende ruimte over voor resources. Als er sprake is van resource- en prestatievermindering, kan het nodig zijn om een aantal databases uit de betreffende elastische pool te verplaatsen of de pool omhoog te schalen, zoals eerder is aangegeven. Voor deze acties zijn echter extra rekenbronnen nodig. Met name voor Premium- en Bedrijfskritiek-pools moeten voor deze acties alle gegevens worden overgebracht voor de databases die worden verplaatst, of voor alle databases in de elastische pool als de pool wordt opgeschaald. Gegevensoverdracht is een langdurige en resource-intensieve bewerking. Als de pool al onder hoge resourcedruk staat, zal de middelbewerking zelf de prestaties nog verder verslechteren. In uitzonderlijke gevallen is het mogelijk niet mogelijk om resourceproblemen op te lossen via het verplaatsen van de database of het omhoog schalen van de pool, omdat de vereiste resources niet beschikbaar zijn. In dit geval is het tijdelijk verminderen van de querywerkbelasting voor de betreffende elastische pool mogelijk de enige oplossing.

Klanten die compacte pools gebruiken, moeten de trends in resourcegebruik nauwkeurig bewaken, zoals eerder beschreven, en een metrische actie ondernemen terwijl metrische gegevens binnen de aanbevolen bereiken blijven en er nog steeds voldoende resources in de elastische pool zijn.

Het resourcegebruik is afhankelijk van meerdere factoren die in de tijd veranderen voor elke database en elke elastische pool. Voor het bereiken van een optimale prijs-prestatieverhouding in compacte pools is continue bewaking en herverbalancering vereist, waardoor databases worden verplaatst van meer gebruikte pools naar minder gebruikte pools en indien nodig nieuwe pools moeten worden gemaakt om een verhoogde workload mogelijk te maken.

Verplaats 'hot' databases niet. Als resource-problemen op groepsniveau voornamelijk worden veroorzaakt door een klein aantal zeer gebruikte databases, kan het verleidelijk zijn om deze databases naar een minder gebruikte pool te verplaatsen of zelfstandige databases te maken. Als u dit doet terwijl een database zeer veel wordt gebruikt, wordt dit echter niet aanbevolen, omdat de verplaatsbewerking de prestaties verder verslechtert, zowel voor de database die wordt verplaatst als voor de hele pool. Wacht in plaats daarvan tot een hoog gebruik af is of verplaats minder gebruikte databases om resourcedruk op poolniveau te verminderen. Het verplaatsen van databases met een zeer laag gebruik biedt in dit geval echter geen voordeel, omdat het resourcegebruik op poolniveau hierdoor niet aanzienlijk wordt beperkt.

Maak nieuwe databases in een quarantainepool. In scenario's waarin vaak nieuwe databases worden gemaakt, zoals toepassingen die gebruikmaken van het model tenant-per-database, bestaat het risico dat een nieuwe database die in een bestaande elastische pool wordt geplaatst, onverwacht aanzienlijke resources verbruikt en van invloed is op andere databases en interne processen in de pool. Om dit risico te beperken, maakt u een afzonderlijke quarantainepool met uitgebreide toewijzing van resources. Gebruik deze pool voor nieuwe databases met nog onbekende patronen voor resourceverbruik. Zodra een database in deze pool is gebleven voor een bedrijfscyclus, zoals een week of een maand, en het resourceverbruik bekend is, kan deze worden verplaatst naar een pool met voldoende capaciteit om dit extra resourcegebruik mogelijk te maken.

Controleer zowel de gebruikte als de toegewezen ruimte. Wanneer de toegewezen poolruimte (totale grootte van alle databasebestanden in opslag voor alle databases in een pool) de maximale poolgrootte bereikt, kunnen er fouten optreden als er geen ruimte meer is. Als toegewezen ruimtetrends hoog zijn en op schema zijn om de maximale poolgrootte te bereiken, zijn de risicobeperkingsopties onder andere:

• Enkele databases uit de pool verplaatsen om de totale toegewezen ruimte te verminderen
• Databasebestanden verkleinen om lege toegewezen ruimte in bestanden te verminderen
• De pool omhoog schalen naar een servicedoelstelling met een grotere maximale poolgrootte

Als de gebruikte poolruimte (totale grootte van gegevens in alle databases in een pool, met inbegrip van lege ruimte in bestanden) hoog is en op schema ligt om de maximale poolgrootte te bereiken, zijn de risicobeperkingsopties onder andere:

• Enkele databases uit de pool verplaatsen om de totale gebruikte ruimte te verminderen
• Gegevens buiten de database verplaatsen (archiveren) of niet langer benodigde gegevens verwijderen
• Gegevenscompressie implementeren
• De pool omhoog schalen naar een servicedoelstelling met een grotere maximale poolgrootte

Vermijd te compacte servers. Azure SQL Database ondersteunt maximaal 5000 databases per server. Klanten die elastische pools met duizenden databases gebruiken, kunnen overwegen meerdere elastische pools op één server te plaatsen, met het totale aantal databases tot de ondersteunde limiet. Servers met vele duizenden databases zorgen echter voor operationele uitdagingen. Bewerkingen waarvoor het opsnoemen van alle databases op een server is vereist, bijvoorbeeld het weergeven van databases in de portal, zullen langzamer zijn. Operationele fouten, zoals onjuiste wijzigingen van aanmeldingen op serverniveau of firewallregels, zijn van invloed op een groter aantal databases. Voor het onbedoeld verwijderen van de server is hulp Microsoft-ondersteuning om databases op de verwijderde server te herstellen. Dit zal leiden tot langdurige uitval voor alle betrokken databases.

Het wordt aanbevolen om het aantal databases per server te beperken tot een lager aantal dan het maximum dat wordt ondersteund. In veel scenario's is het optimaal om maximaal 1000-2000 databases per server te gebruiken. Plaats een verwijderingsvergrendeling op de server of de resourcegroep om de kans op onbedoeld verwijderen van de server te verminderen.

Voorbeelden

Geheugengebruik bewaken

Met deze query worden de oom_per_second metrische gegevens voor elke resourcegroep berekend in de afgelopen 32 minuten. Deze query kan worden uitgevoerd in elke database in een elastische pool.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Het gebruik tempdb van logboekruimte bewaken

Deze query retourneert de huidige waarde van de metrische waarde, met het relatieve gebruik van het transactielogboek ten opzichte van de tempdb_log_used_percent tempdb maximaal toegestane grootte. Deze query kan worden uitgevoerd in elke database in een elastische pool.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Volgende stappen

• Zie Elastische pools helpen u bij het beheren en schalen van meerdere databases in Azure SQL Database voor een inleiding tot elastische pools.
• Zie Bewaking en afstemming en Bewaking en prestatieafstemming voor meer informatie over het afstemmen van querywerkbelastingen om het resourcegebruik te verminderen.