Gestione risorse in pool elastici densi

SI APPLICA A: Database SQL di Azure

database SQL di Azure pool elastici è una soluzione conveniente per la gestione di molti database con un utilizzo variabile delle risorse. Tutti i database in un pool elastico condividono la stessa allocazione di risorse, ad esempio CPU, memoria, thread di lavoro, spazio di archiviazione, tempdb, presupponendo che solo un subset di database nel pool userà le risorse di calcolo in un determinato momento. Questo presupposto consente ai pool elastici di essere conveniente. Invece di pagare tutte le risorse potenzialmente necessarie per ogni singolo database, i clienti pagano per un set molto più piccolo di risorse, condivise tra tutti i database nel pool.

Governance delle risorse

La condivisione delle risorse richiede al sistema di controllare con attenzione l'utilizzo delle risorse per ridurre al minimo l'effetto "vicino rumoroso", in cui un database con un consumo elevato di risorse influisce sugli altri database nello stesso pool elastico. Allo stesso tempo, il sistema deve fornire risorse sufficienti per funzionalità quali disponibilità elevata e ripristino di emergenza (HADR), backup e ripristino, monitoraggio, Query Store, ottimizzazione automatica e così via per funzionare in modo affidabile.

database SQL di Azure raggiunge questi obiettivi usando più meccanismi di governance delle risorse, tra cui oggetti processo Windows per la governance delle risorse a livello di processo, Windows File Server Resource Manager (FSRM) per la gestione delle quote di archiviazione e una versione modificata ed estesa di SQL Server Resource Governor per implementare la governance delle risorse all'interno di database SQL.

L'obiettivo principale della progettazione dei pool elastici è quello di essere conveniente. Per questo motivo, il sistema consente intenzionalmente ai clienti di creare pool densi, cio' pool con il numero di database che si avvicinano o al massimo consentito, ma con un'allocazione moderata delle risorse di calcolo. Per lo stesso motivo, il sistema non riserva tutte le risorse potenzialmente necessarie per i processi interni, ma consente la condivisione delle risorse tra processi interni e carichi di lavoro utente.

Questo approccio consente ai clienti di usare pool elastici densi per ottenere prestazioni adeguate e risparmi importanti sui costi. Tuttavia, se il carico di lavoro su molti database in un pool denso è sufficientemente intenso, la lotta alle risorse diventa significativa. I problemi di risorse riducono le prestazioni del carico di lavoro degli utenti e possono influire negativamente sui processi interni.

Importante

Nei pool ad alta densità con molti database attivi potrebbe non essere possibile aumentare il numero di database nel pool fino ai valori massimi documentati per i pool elastici DTU e vCore.

Il numero di database che possono essere inseriti in pool densi senza causare problemi di prestazioni e di risorse dipende dal numero di database attivi contemporaneamente e dall'utilizzo delle risorse da parte dei carichi di lavoro degli utenti in ogni database. Questo numero può cambiare nel tempo quando cambiano i carichi di lavoro degli utenti.

Quando si verifica una conflitto di risorse in un pool densamente pieno, i clienti possono scegliere una o più delle azioni seguenti per attenuarlo:

  • Ottimizzare il carico di lavoro delle query per ridurre l'utilizzo delle risorse o distribuire l'utilizzo delle risorse tra più database nel tempo.
  • Ridurre la densità dei pool spostando alcuni database in un altro pool o rendendoli database autonomi.
  • Aumentare le dimensioni del pool per ottenere più risorse.

Per suggerimenti su come implementare le ultime due azioni, vedere Raccomandazioni operative più avanti in questo articolo. La riduzione dei carichi di lavoro e dei processi interni dei carichi di lavoro degli utenti consente al sistema di mantenere in modo affidabile il livello di servizio previsto.

Monitoraggio dell'utilizzo delle risorse

Per evitare una riduzione delle prestazioni a causa di conflitti di risorse, i clienti che usano pool elastici ad alta densità devono monitorare in modo proattivo l'utilizzo delle risorse e intraprendere azioni in tempo reale se l'aumento della conflitti di risorse inizia a influire sui carichi di lavoro. Il monitoraggio continuo è importante perché l'utilizzo delle risorse in un pool cambia nel tempo, a causa delle modifiche nel carico di lavoro degli utenti, delle modifiche nei volumi e della distribuzione dei dati, delle variazioni nella densità del pool e delle modifiche nel servizio database SQL di Azure dati.

database SQL di Azure fornisce diverse metriche rilevanti per questo tipo di monitoraggio. Il superamento del valore medio consigliato per ogni metrica indica la presenza di un'incoerzione delle risorse nel pool e deve essere affrontata usando una delle azioni indicate in precedenza.

Nome metrica Descrizione Valore medio consigliato
avg_instance_cpu_percent Utilizzo della CPU del SQL processo associato a un pool elastico, misurato dal sistema operativo sottostante. Disponibile nella vista sys.dm_db_resource_stats in ogni database e nella vista sys.elastic_pool_resource_stats nel master database. Questa metrica viene emessa anche Monitoraggio di Azure, dove è denominata , e può sqlserver_process_core_percent essere visualizzata in portale di Azure. Questo valore è lo stesso per ogni database nello stesso pool elastico. Inferiore al 70%. Occasionali picchi brevi fino al 90% possono essere accettabili.
max_worker_percent Utilizzo del thread di lavoro. Fornito per ogni database nel pool, nonché per il pool stesso. Esistono limiti diversi per il numero di thread di lavoro a livello di database e a livello di pool, pertanto è consigliabile monitorare questa metrica a entrambi i livelli. Disponibile nella vista sys.dm_db_resource_stats in ogni database e nella vista sys.elastic_pool_resource_stats nel master database. Questa metrica viene emessa anche Monitoraggio di Azure, dove è denominata , e può workers_percent essere visualizzata in portale di Azure. Inferiore all'80%. Picchi fino al 100% causeranno l'esito negativo dei tentativi di connessione e delle query.
avg_data_io_percent Utilizzo delle operazioni di I/O al secondo per operazioni di I/O fisiche in lettura e scrittura. Fornito per ogni database nel pool, nonché per il pool stesso. Esistono limiti diversi per il numero di operazioni di I/O al secondo a livello di database e a livello di pool, pertanto è consigliabile monitorare questa metrica a entrambi i livelli. Disponibile nella vista sys.dm_db_resource_stats in ogni database e nella vista sys.elastic_pool_resource_stats nel master database. Questa metrica viene emessa anche Monitoraggio di Azure, dove è denominata , e può physical_data_read_percent essere visualizzata in portale di Azure. Inferiore all'80%. Occasionali picchi brevi fino al 100% possono essere accettabili.
avg_log_write_percent Utilizzo della velocità effettiva per le operazioni di I/O di scrittura del log delle transazioni. Fornito per ogni database nel pool, nonché per il pool stesso. Esistono limiti diversi per la velocità effettiva del log a livello di database e a livello di pool, pertanto è consigliabile monitorare questa metrica a entrambi i livelli. Disponibile nella vista sys.dm_db_resource_stats in ogni database e nella vista sys.elastic_pool_resource_stats nel master database. Questa metrica viene emessa anche Monitoraggio di Azure, dove è denominata , e può log_write_percent essere visualizzata in portale di Azure. Quando questa metrica è vicina al 100%, tutte le modifiche al database (INSERT, UPDATE, DELETE, ISTRUZIONI MERGE, SELECT ... INTO, BULK INSERT e così via) sarà più lento. Inferiore al 90%. Occasionali picchi brevi fino al 100% possono essere accettabili.
oom_per_second Frequenza degli errori di memoria insufficiente (OOM) in un pool elastico, che è un indicatore della pressione della memoria. Disponibile nella visualizzazione sys.dm_resource_governor_resource_pools_history_ex dati. Vedere Esempi per una query di esempio per calcolare questa metrica. 0
avg_storage_percent Spazio di archiviazione totale usato dai dati in tutti i database all'interno di un pool elastico. Non include spazio vuoto nei file di database. Disponibile nella sys.elastic_pool_resource_stats nel master database. Questa metrica viene emessa anche Monitoraggio di Azure, dove è denominata , e può storage_percent essere visualizzata in portale di Azure. Inferiore all'80%. Può essere avvicinato al 100% per i pool senza crescita dei dati.
avg_allocated_storage_percent Spazio di archiviazione totale usato dai file di database nell'archiviazione in tutti i database all'interno di un pool elastico. Include lo spazio vuoto nei file di database. Disponibile nella sys.elastic_pool_resource_stats nel master database. Questa metrica viene emessa anche Monitoraggio di Azure, dove è denominata , e può allocated_data_storage_percent essere visualizzata in portale di Azure. Inferiore al 90%. Può essere avvicinato al 100% per i pool senza crescita dei dati.
tempdb_log_used_percent Utilizzo dello spazio del log delle transazioni nel tempdb database. Anche se gli oggetti temporanei creati in un database non sono visibili in altri database nello stesso pool elastico, è una risorsa condivisa per tutti i database tempdb nello stesso pool. Una transazione a esecuzione lunga o orfana in avviata da un database nel pool può utilizzare una grande parte del log delle transazioni e causare errori per le query in altri database tempdb nello stesso pool. Derivato da sys.dm_db_log_space_usage e sys.database_files viste. Questa metrica viene anche generata per Monitoraggio di Azure e può essere visualizzata in portale di Azure. Vedere Esempi per una query di esempio per restituire il valore corrente di questa metrica. Inferiore al 50%. Sono accettabili picchi occasionali fino all'80%.

Oltre a queste metriche, database SQL di Azure una vista che restituisce i limiti effettivi di governance delle risorse, nonché visualizzazioni aggiuntive che restituiscono statistiche sull'utilizzo delle risorse a livello di pool di risorse e a livello di gruppo di carico di lavoro.

Nome della vista Descrizione
sys.dm_user_db_resource_governance Restituisce le impostazioni di configurazione e capacità effettive usate dai meccanismi di governance delle risorse nel database o nel pool elastico corrente.
sys.dm_resource_governor_resource_pools Restituisce informazioni sullo stato corrente del pool di risorse, sulla configurazione corrente dei pool di risorse e sulle statistiche cumulative del pool di risorse.
sys.dm_resource_governor_workload_groups Restituisce le statistiche del gruppo di carico di lavoro cumulativo e la configurazione corrente del gruppo di carico di lavoro. Questa vista può essere unita con sys.dm_resource_governor_resource_pools nella pool_id colonna per ottenere informazioni sul pool di risorse.
sys.dm_resource_governor_resource_pools_history_ex Restituisce le statistiche di utilizzo del pool di risorse per gli ultimi 32 minuti. Ogni riga rappresenta un intervallo di 20 secondi. Le delta_ colonne restituiscono la modifica in ogni statistica durante l'intervallo.
sys.dm_resource_governor_workload_groups_history_ex Restituisce le statistiche di utilizzo del gruppo di carico di lavoro per gli ultimi 32 minuti. Ogni riga rappresenta un intervallo di 20 secondi. Le delta_ colonne restituiscono la modifica in ogni statistica durante l'intervallo.

Queste visualizzazioni possono essere usate per monitorare l'utilizzo delle risorse e risolvere i problemi relativi alla near real-time. Il carico di lavoro utente nelle repliche secondarie primarie e leggibili, incluse le repliche geografiche, viene classificato nel pool di risorse e nel gruppo di carico di lavoro, dove sta per il valore SloSharedPool1 UserPrimaryGroup.DBId[N] id N database.

Oltre a monitorare l'utilizzo corrente delle risorse, i clienti che usano pool dense possono mantenere i dati cronologici sull'utilizzo delle risorse in un archivio dati separato. Questi dati possono essere usati nell'analisi predittiva per gestire in modo proattivo l'utilizzo delle risorse in base alle tendenze cronologiche e stagionali.

Raccomandazioni operative

Lasciare spazio sufficiente per le risorse. In caso di conflitto di risorse e riduzione delle prestazioni, la mitigazione può comportare lo spostamento di alcuni database dal pool elastico interessato o il ridimensionamento del pool, come illustrato in precedenza. Tuttavia, queste azioni richiedono risorse di calcolo aggiuntive per il completamento. In particolare, per i pool Premium e business critical, queste azioni richiedono il trasferimento di tutti i dati per i database da spostare o per tutti i database nel pool elastico se il pool viene ridimensionato. Il trasferimento dei dati è un'operazione a esecuzione intensiva e a esecuzione intensiva di risorse. Se il pool è già sotto un elevato utilizzo di risorse, l'operazione di mitigazione stessa ridurrà ulteriormente le prestazioni. In casi estremi, potrebbe non essere possibile risolvere i problemi di risorse tramite lo spostamento del database o la scalabilità verticale del pool perché le risorse necessarie non sono disponibili. In questo caso, la riduzione temporanea del carico di lavoro delle query nel pool elastico interessato può essere l'unica soluzione.

I clienti che usano pool ad alta densità devono monitorare attentamente le tendenze di utilizzo delle risorse come descritto in precedenza e intraprendere azioni di mitigazione mentre le metriche rimangono entro gli intervalli consigliati e nel pool elastico sono ancora presenti risorse sufficienti.

L'utilizzo delle risorse dipende da più fattori che cambiano nel tempo per ogni database e ogni pool elastico. Per ottenere un rapporto ottimale tra prezzo e prestazioni in pool densi è necessario il monitoraggio e il ribilanciamento continui, che sposta i database da pool più utilizzati a pool meno utilizzati e crea nuovi pool in base alle esigenze per supportare un aumento del carico di lavoro.

Non spostare i database "ad caldo". Se i problemi di risorse a livello di pool sono causati principalmente da un numero ridotto di database a utilizzo elevato, può essere consigliabile spostare questi database in un pool meno utilizzato o renderli database autonomi. Tuttavia, questa operazione mentre un database rimane molto utilizzato non è consigliabile, perché l'operazione di spostamento peggiorerà ulteriormente le prestazioni, sia per il database da spostare che per l'intero pool. Attendere invece che l'utilizzo elevato diminuisca o spostare database meno utilizzati per attenuare la pressione delle risorse a livello di pool. Tuttavia, lo spostamento di database con un utilizzo molto basso non offre alcun vantaggio in questo caso, perché non riduce materialmente l'utilizzo delle risorse a livello di pool.

Creare nuovi database in un pool di "quarantena". Negli scenari in cui i nuovi database vengono creati di frequente, ad esempio le applicazioni che usano il modello tenant per database, esiste il rischio che un nuovo database inserito in un pool elastico esistente utilizzi in modo imprevisto risorse significative e influisca su altri database e processi interni nel pool. Per attenuare questo rischio, creare un pool di "quarantena" separato con un'allocazione di risorse molto grande. Usare questo pool per i nuovi database con modelli di utilizzo delle risorse ancora sconosciuti. Dopo che un database è rimasto in questo pool per un ciclo aziendale, ad esempio una settimana o un mese, ed è noto l'utilizzo delle risorse, può essere spostato in un pool con capacità sufficiente per supportare l'utilizzo aggiuntivo delle risorse.

Monitorare sia lo spazio usato che lo spazio allocato. Quando lo spazio allocato del pool (dimensioni totali di tutti i file di database nell'archiviazione per tutti i database in un pool) raggiunge le dimensioni massime del pool, possono verificarsi errori di spazio insufficiente. Se lo spazio allocato è trend elevato ed è in grado di raggiungere le dimensioni massime del pool, le opzioni di mitigazione includono:

  • Spostare alcuni database dal pool per ridurre lo spazio totale allocato
  • Compattare i file di database per ridurre lo spazio allocato vuoto nei file
  • Aumentare le dimensioni del pool a un obiettivo di servizio con dimensioni massime del pool maggiori

Se lo spazio del pool usato (dimensioni totali dei dati in tutti i database di un pool, senza includere spazio vuoto nei file) è elevato ed è in grado di raggiungere le dimensioni massime del pool, le opzioni di mitigazione includono:

  • Spostare alcuni database dal pool per ridurre lo spazio totale usato
  • Spostare (archiviare) i dati all'esterno del database o eliminare i dati non più necessari
  • Implementare la compressione dei dati
  • Aumentare le dimensioni del pool a un obiettivo di servizio con dimensioni massime del pool maggiori

Evitare server troppo densi. database SQL di Azure supporta fino a 5000 database per server. I clienti che usano pool elastici con migliaia di database possono prendere in considerazione l'inserimento di più pool elastici in un singolo server, con il numero totale di database fino al limite supportato. Tuttavia, i server con molte migliaia di database creano problemi operativi. Le operazioni che richiedono l'enumerazione di tutti i database in un server, ad esempio la visualizzazione dei database nel portale, saranno più lente. Gli errori operativi, ad esempio la modifica non corretta degli account di accesso a livello di server o delle regole del firewall, influiranno su un numero maggiore di database. L'eliminazione accidentale del server richiederà assistenza Supporto tecnico Microsoft per ripristinare i database nel server eliminato e causerà un'interruzione prolungata per tutti i database interessati.

È consigliabile limitare il numero di database per server a un numero inferiore al massimo supportato. In molti scenari è ottimale usare fino a 1000-2000 database per server. Per ridurre la probabilità di eliminazione accidentale del server, è consigliabile inserire un blocco di eliminazione sul server o sul relativo gruppo di risorse.

In passato, alcuni scenari che comportavano lo spostamento di database in, in uscita o tra pool elastici nello stesso server erano più veloci rispetto allo spostamento di database tra server. Attualmente, tutti gli spostamenti del database vengono eseguiti alla stessa velocità indipendentemente dal server di origine e di destinazione.

Esempio

Monitoraggio dell'utilizzo della memoria

Questa query calcola la oom_per_second metrica per ogni pool di risorse negli ultimi 32 minuti. Questa query può essere eseguita in qualsiasi database in un pool elastico.

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;

Monitoraggio tempdb dell'utilizzo dello spazio dei log

Questa query restituisce il valore corrente della metrica, che mostra l'utilizzo relativo del log delle transazioni tempdb_log_used_percent tempdb rispetto alle dimensioni massime consentite. Questa query può essere eseguita in qualsiasi database in un pool elastico.

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
;

Passaggi successivi