Beheer van hulpbronnen in intensieve elastische clusters

Van toepassing op:Azure SQL Database

Elastische pools van Azure SQL Database is een rendabele oplossing voor het beheren van veel databases met verschillende resourcegebruik. Alle databases in een elastische pool delen dezelfde toewijzing van resources, zoals CPU, geheugen, werkthreads, opslagruimte, tempdbwaarbij wordt aangenomen dat op elk gewenst moment slechts een subset van databases in de pool rekenresources gebruikt. Met deze aanname kunnen elastische pools rendabel zijn. In plaats van te betalen voor alle resources die elke afzonderlijke database mogelijk nodig heeft, 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 effect 'lawaaierige buren' te minimaliseren, waarbij een database met een hoog resourceverbruik van invloed is op andere databases in dezelfde elastische pool. Azure SQL Database bereikt deze doelen door resourcebeheer te implementeren. Tegelijkertijd moet het systeem voldoende middelen bieden voor functies zoals hoge beschikbaarheid en noodherstel (HADR), back-up en herstel, bewaking, Query Store, Automatische optimalisatie, enzovoort.

Het primaire ontwerpdoel van elastische pools is rendabel. Om deze reden stelt het systeem klanten bewust in staat dichte pools te creëren, dat wil zeggen pools met het aantal databases dat het maximum nadert of heeft bereikt, maar met een matige toewijzing van computercapaciteit. Om dezelfde reden reserveert het systeem niet alle mogelijk benodigde resources voor de interne processen, maar staat het delen van resources tussen interne processen en gebruikersworkloads toe.

Met deze aanpak kunnen klanten dichte elastische pools gebruiken om adequate prestaties en grote kostenbesparingen te bereiken. Als de workload voor veel databases in een dichte pool echter voldoende intensief is, wordt resourceconflict aanzienlijk. Resourceconflicten verminderen de prestaties van gebruikersworkloads en kunnen negatieve gevolgen hebben voor interne processen.

Wanneer resourceconflicten 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 loop van de tijd te verdelen.
• Verminder de pooldichtheid door sommige databases naar een andere pool te verplaatsen of door ze zelfstandige databases te maken.
• Schaal de pool omhoog om meer resources te krijgen.

Zie Operationele aanbevelingen verderop in dit artikel voor suggesties over het implementeren van de laatste twee acties. Het verminderen van bronnenconcurrentie komt zowel gebruikersbelastingen als interne processen ten goede en zorgt ervoor dat het systeem het verwachte serviceniveau betrouwbaar behoudt.

Resourceverbruik bewaken

Om prestatievermindering als gevolg van conflicten tussen resources te voorkomen, moeten klanten die dichte elastische pools gebruiken proactief het resourceverbruik bewaken en tijdig actie ondernemen als het toenemen van resourceconflicten van invloed is op workloads. Continue bewaking is belangrijk omdat het resourcegebruik in een pool na verloop van tijd verandert, vanwege wijzigingen in de gebruikersworkload, wijzigingen in gegevensvolumes en distributie, wijzigingen in 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 metriek geeft aan dat er resourceconflicten in de pool zijn en moet worden aangepakt met behulp van een van de eerder genoemde acties.

Als u een waarschuwing wilt verzenden wanneer het resourcegebruik van de pool (CPU, gegevens-IO, logboek-IO, werkrollen, enzovoort) een drempelwaarde overschrijdt, maakt u waarschuwingen voor Azure SQL Database met behulp van Azure Portal of gebruikt u de PowerShell-cmdlet Add-AzMetricAlertRulev2 . Overweeg bij het bewaken van elastische pools ook waarschuwingen te maken voor afzonderlijke databases in de pool, indien nodig in uw scenario.

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

Deze weergaven kunnen worden gebruikt om resourcegebruik te bewaken en problemen met resourceconflicten 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 SloSharedPool1 resourcepool en UserPrimaryGroup.DBId[N] workloadgroep, waar N staat voor de waarde van de database-ID.

Naast het bewaken van het huidige resourcegebruik kunnen klanten die dichte pools gebruiken historische resourcegebruiksgegevens onderhouden in een afzonderlijk gegevensarchief. 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 conflicten met resources en prestatievermindering, kan een beperking betrekking hebben op het verplaatsen van sommige databases uit de betrokken elastische pool of het omhoog schalen van de pool, zoals eerder is aangegeven. Voor deze acties zijn echter extra rekenkracht nodig om te voltooien. Met name voor Premium- en Bedrijfskritieke pools moeten voor deze acties alle gegevens worden overgedragen voor de databases die worden verplaatst, of voor alle databases in de elastische pool als de pool omhoog wordt geschaald. Gegevensoverdracht is een langdurige en resource-intensieve bewerking. Als de pool al onder hoge resourcedruk staat, zal de beperkende bewerking zelf de prestaties nog verder verlagen. In extreme gevallen is het misschien niet mogelijk om resourceconflicten te verhelpen via databaseverplaatsing of opschaling van de pool, omdat de vereiste resources niet beschikbaar zijn. In dit geval is het tijdelijk verminderen van de queryworkload voor de betrokken elastische pool mogelijk de enige oplossing.

Klanten die dichte pools gebruiken, moeten de trends in het gebruik van resources nauwkeurig controleren zoals eerder beschreven, en maatregelen nemen zolang de metrics binnen de aanbevolen waarden blijven en er voldoende middelen in de elastische pool beschikbaar zijn.

Resourcegebruik is afhankelijk van meerdere factoren die in de loop van de tijd veranderen voor elke database en elke elastische pool. Het bereiken van een optimale prijs-/prestatieverhouding in dichte pools vereist continue bewaking en herverdeling, waardoor databases van meer gebruikte pools naar minder gebruikte pools worden verplaatst en nieuwe pools worden gemaakt als dat nodig is om een verhoogde werkbelasting mogelijk te maken.

Verplaats 'dynamische' databases niet. Als resourceconflicten op poolniveau voornamelijk worden veroorzaakt door een klein aantal maximaal gebruikte databases, kan het verleidelijk zijn om deze databases te verplaatsen naar een minder gebruikte pool of om zelfstandige databases te maken. Het wordt echter afgeraden om dit te doen terwijl de database intensief wordt gebruikt, omdat de verplaatsing de prestaties verder zal verslechteren, zowel voor de verplaatste database als voor de gehele pool. Wacht in plaats daarvan totdat het hoge gebruik afgaat of verplaats minder gebruikte databases in plaats daarvan om de resourcedruk op poolniveau te verlichten. Maar het verplaatsen van databases met een zeer laag gebruik biedt in dit geval geen voordeel, omdat het resourcegebruik op poolniveau niet wezenlijk vermindert.

Maak nieuwe databases in een 'quarantaine' pool. In scenario's waarin nieuwe databases vaak worden gemaakt, zoals toepassingen die gebruikmaken van het tenant-per-databasemodel, bestaat het risico dat een nieuwe database in een bestaande elastische pool onverwacht aanzienlijke resources verbruikt en invloed heeft op andere databases en interne processen in de pool. Maak een afzonderlijke quarantainegroep met voldoende toewijzing van resources om dit risico te beperken. 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 ervan bekend is, kan deze worden verplaatst naar een pool met voldoende capaciteit om aan dit extra resourcegebruik te voldoen.

Bewaak zowel gebruikte als toegewezen ruimte. Wanneer toegewezen poolruimte (totale grootte van alle databasebestanden in opslag voor alle databases in een pool) de maximale poolgrootte bereikt, kunnen er out-of-space-fouten optreden. Als de toegewezen ruimtetrend hoog is en op schema ligt om de maximale poolgrootte te bereiken, omvatten de mitigatiemogelijkheden:

• Verplaats sommige databases uit de pool om de totale toegewezen ruimte te verminderen.
• Beheer de bestandsruimte in databases om lege toegewezen ruimte in bestanden te verminderen.
• Schaal de pool omhoog naar een servicedoelstelling met een grotere maximale poolgrootte.

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

• Verplaats sommige databases uit de pool om de totale gebruikte ruimte te verminderen.
• Verplaats (archief) gegevens buiten de database of verwijder geen gegevens meer.
• Gegevenscompressie implementeren.
• Schaal de pool omhoog naar een servicedoelstelling met een grotere maximale poolgrootte.

Vermijd te veel dichte servers. Azure SQL Database ondersteunt maximaal 5000 databases per server. Klanten die elastische pools met duizenden databases gebruiken, kunnen overwegen om meerdere elastische pools op één server te plaatsen, met het totale aantal databases tot aan de ondersteunde limiet. Servers met vele duizenden databases zorgen echter voor operationele uitdagingen. Bewerkingen waarvoor alle databases op een server moeten worden opgesomd, bijvoorbeeld het weergeven van databases in de portal, zijn langzamer. Operationele fouten, zoals een onjuiste wijziging van aanmeldingen op serverniveau of firewallregels, zijn van invloed op een groter aantal databases. Onbedoeld verwijderen van de server vereist hulp van Microsoft Ondersteuning om databases op de verwijderde server te herstellen en veroorzaakt een langdurige storing voor alle betrokken databases.

Beperk het aantal databases per server tot een lager aantal dan het maximum dat wordt ondersteund. In veel scenario's is het gebruik van maximaal 1000-2000 databases per server optimaal. Als u de kans op onbedoeld verwijderen van de server wilt verminderen, plaatst u een verwijderingsvergrendeling op de server of de bijbehorende resourcegroep.

Voorbeelden

Instellingen voor de capaciteit van afzonderlijke databases weergeven

Gebruik de sys.dm_user_db_resource_governance dynamische beheerweergave om de werkelijke configuratie- en capaciteitsinstellingen weer te geven die worden gebruikt door resourcebeheer in de huidige database of elastische pool. Zie sys.dm_user_db_resource_governance voor meer informatie.

Voer deze query uit in een database in een elastische pool. Alle databases in de pool hebben dezelfde instellingen voor resourcebeheer.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Het totale resourceverbruik van elastische pools bewaken

Gebruik de sys.elastic_pool_resource_stats systeemcatalogusweergave om het resourceverbruik van de hele pool te bewaken. Zie sys.elastic_pool_resource_stats voor meer informatie.

Deze voorbeeldquery om de afgelopen tien minuten weer te geven, moet worden uitgevoerd in de master database van de logische Azure SQL-server die de gewenste elastische pool bevat.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Verbruik van afzonderlijke databaseresources bewaken

Gebruik de sys.dm_db_resource_stats weergave dynamisch beheer om het resourceverbruik van afzonderlijke databases te bewaken. Zie sys.dm_db_resource_stats voor meer informatie. Er bestaat één rij voor elke 15 seconden, zelfs als er geen activiteit is. Historische gegevens worden ongeveer één uur bijgehouden.

Deze voorbeeldquery om de laatste 10 minuten aan gegevens weer te geven, moet worden uitgevoerd in de gewenste database.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Voor langere bewaartijd met minder frequentie kunt u de volgende query uitvoeren sys.resource_statsin de master database van de logische Azure SQL-server. Zie sys.resource_stats (Azure SQL Database) voor meer informatie. Er bestaat om de vijf minuten één rij en historische gegevens worden twee weken bewaard.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Geheugengebruik bewaken

Deze query berekent de oom_per_second metrische gegevens voor elke resourcegroep voor de recente geschiedenis, op basis van het aantal beschikbare momentopnamen. Deze voorbeeldquery helpt bij het identificeren van het recente gemiddelde aantal mislukte geheugentoewijzingen in de pool. 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;

Tempdb-logboekruimtegebruik bewaken

Deze query retourneert de huidige waarde van de tempdb_log_used_percent metrische waarde, met het relatieve gebruik van het transactielogboek ten opzichte van de tempdb maximale 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
;

Verwante inhoud

• Elastische pools helpen u bij het beheren en schalen van meerdere databases in Azure SQL Database
• Bewaking en afstemming
• Monitoren en prestaties optimaliseren in Azure SQL Database en Azure SQL Managed Instance