I pool elastici consentono di gestire e ridimensionare più database in Azure SQL Database

Si applica a: Database SQL di Azure

I pool elastici di Database SQL di Azure offrono una soluzione semplice e conveniente per la gestione e il ridimensionamento di più database con esigenze di utilizzo variabili e imprevedibili. I database in un pool elastico si trovano in un singolo server e condividono un numero di risorse impostato a un prezzo impostato. I pool elastici in database SQL consentono agli sviluppatori di software come servizio (SaaS) di ottimizzare le prestazioni dei prezzi per un gruppo di database all'interno di un budget previsto, offrendo elasticità delle prestazioni per ogni database.

Che cosa sono i pool elastici SQL?

Gli sviluppatori SaaS creano applicazioni su più livelli di dati su larga scala costituiti da più database. Un modello di applicazione comune è il provisioning di un database singolo per ogni cliente. Ma i clienti diversi hanno spesso modelli di utilizzo variabili e imprevedibili e è difficile stimare i requisiti delle risorse di ogni singolo utente del database. In genere, le opzioni erano due:

  • Sovraprovisionare le risorse in base all'utilizzo massimo e al pagamento eccessivo.
  • Sottoprovision per risparmiare sui costi, a spese delle prestazioni e della soddisfazione dei clienti durante i picchi.

I pool elastici risolvono il problema assicurando ai database l'ottenimento delle risorse di prestazioni necessarie, quando richieste. Forniscono un meccanismo semplice di allocazione delle risorse che rientra in un budget prevedibile. Per altre informazioni sui modelli di progettazione per le applicazioni SaaS usando pool elastici, vedere Modelli di progettazione per applicazioni SaaS multi-tenant con database SQL.

Importante

Non è previsto alcun addebito per database per pool elastici. Viene fatturata ogni ora in cui esiste un pool al massimo di eDTU o vCore, indipendentemente dall'utilizzo o dal fatto che il pool sia attivo per meno di un'ora.

I pool elastici consentono di acquistare risorse per un pool condiviso da più database per soddisfare periodi imprevedibili di utilizzo da singoli database. È possibile configurare le risorse per il pool in base al modello di acquisto basato su DTU o al modello di acquisto basato su vCore. Il requisito di risorse per un pool è determinato dall'utilizzo aggregato dei relativi database.

La quantità di risorse disponibili per il pool è controllata dal budget. Tutto quello che devi fare è:

  • Aggiungere database al pool.
  • Facoltativamente, impostare le risorse minime e massime per i database. Queste risorse sono minime e massime DTU o vCore minime o massime a seconda della scelta del modello di resourcing.
  • Impostare le risorse del pool in base al budget.

È possibile usare i pool per aumentare facilmente il servizio da una startup snella a un business maturo su scala sempre crescente.

All'interno del pool, i singoli database hanno la flessibilità di usare le risorse all'interno di parametri set. Se il carico di lavoro è importante, un database può utilizzare più risorse per soddisfare la domanda. Se invece il carico di lavoro è più leggero, i database in assenza di carico non utilizzano risorse. La possibilità di effettuare il provisioning delle risorse per l'intero pool e non per i singoli database semplifica le attività di gestione. È inoltre disponibile un budget per il pool prevedibile.

È possibile aggiungere altre risorse a un pool esistente con tempi di inattività minimi. Se le risorse aggiuntive non sono più necessarie, possono essere rimosse da un pool esistente in qualsiasi momento. È anche possibile aggiungere o rimuovere database dal pool. Se un database è prevedibilmente sottoutilizzato le risorse, è possibile spostarlo fuori.

Nota

Quando si spostano i database in o fuori da un pool elastico, non è previsto alcun tempo di inattività, ad eccezione di un breve periodo (in base all'ordine di secondi) alla fine dell'operazione quando vengono eliminate le connessioni al database.

Quando considerare un pool elastico del database SQL

I pool sono adatti per un numero elevato di database con modelli di utilizzo specifici. Per un determinato database, questo modello è caratterizzato da un utilizzo medio basso con picchi di utilizzo non frequenti. Al contrario, più database con utilizzo medio elevato persistente non devono essere inseriti nello stesso pool elastico.

Più database è possibile aggiungere a un pool, maggiori diventano i risparmi. A seconda del modello di utilizzo dell'applicazione, è possibile visualizzare i risparmi con un numero minimo di due database S3.

Le sezioni seguenti aiutano a comprendere se l'insieme specifico di database può trarre vantaggio dall'uso di un pool. Gli esempi usano pool Standard, ma gli stessi principi si applicano anche ai pool Basic e Premium.

Valutare i modelli di utilizzo del database

La figura seguente mostra un esempio di database che impiega gran parte del tempo inattivo, ma anche picchi periodici con l'attività. Questo modello di utilizzo è adatto per un pool.

Grafico che mostra un singolo database adatto per un pool.

Il grafico illustra l'utilizzo di DTU oltre un'ora dalle 12:00 alle 1:00 in cui ogni punto dati ha una granularità di un minuto. Alle 12:10, DB1 supera fino a 90 DTU, ma l'utilizzo medio complessivo è minore di cinque DTU. Per eseguire questo carico di lavoro in un singolo database è necessaria una dimensione di calcolo S3, ma questa dimensione lascia la maggior parte delle risorse inutilizzate durante periodi di attività ridotta.

Un pool consente di condividere queste DTU inutilizzate tra più database. Un pool riduce le DTU necessarie e il costo complessivo.

In base all'esempio precedente, si supponga che siano presenti altri database con modelli di utilizzo simili come DB1. Nelle due figure successive, l'utilizzo di quattro database e 20 database vengono sovrapposti allo stesso grafico per illustrare la natura non dioverlapping dell'utilizzo nel tempo usando il modello di acquisto basato su DTU:

Grafico che mostra quattro database con un modello di utilizzo adatto per un pool.

Grafico che mostra 20 database con un modello di utilizzo adatto per un pool.

L'utilizzo DTU aggregato in tutti i 20 database è illustrato dalla linea nera del grafico precedente. Questa riga mostra che l'utilizzo DTU aggregato non supera mai 100 DTU e indica che i 20 database possono condividere 100 eDTU in questo periodo di tempo. Il risultato è una riduzione di 20 volte delle DTU e una riduzione del prezzo di 13 ore rispetto all'inserimento di ognuno dei database in dimensioni di calcolo S3 per i singoli database.

Questo esempio è ideale perché:

  • Esistono grandi differenze tra i picchi di utilizzo e l'utilizzo medio per ogni database.
  • Il picco di utilizzo per ogni database si verifica in diversi momenti nel tempo.
  • Le eDTU vengono condivise tra più database.

Nel modello di acquisto DTU il prezzo di un pool è una funzione delle eDTU del pool. Sebbene il prezzo dell'unità eDTU per un pool sia 1,5 volte maggiore del prezzo di unità DTU per un singolo database, è possibile condividere eDTU da molti database e un minor numero di eDTU totali sono necessari. Queste distinzioni nella determinazione dei prezzi e nella condivisione di eDTU costituiscono la base del potenziale risparmio sul prezzo che il pool è in grado di fornire.

Nel modello di acquisto vCore il prezzo di unità vCore per i pool elastici corrisponde al prezzo di unità vCore per i singoli database.

Come scegliere le dimensioni più adatte del pool

La dimensione ottimale per un pool dipende dalle risorse di aggregazione e dalle risorse di archiviazione necessarie per tutti i database nel pool. È necessario determinare:

  • Risorse di calcolo massime usate da tutti i database nel pool. Le risorse di calcolo vengono indicizzate da eDTU o vCore a seconda del modello di acquisto scelto.
  • Byte di archiviazione massima utilizzati da tutti i database nel pool.

Per i livelli di servizio e i limiti delle risorse in ogni modello di acquisto, vedere il modello di acquisto basato su DTU o il modello di acquisto basato su vCore.

La procedura seguente consente di stimare se un pool è più conveniente rispetto ai singoli database:

  1. Stimare le eDTU o le vCore necessarie per il pool:
    • Per il modello di acquisto basato su DTU:
      • MAX(<Numero totale di database × utilizzo medio DTU per database, <numero di BBS contemporaneamente in picco × utilizzo DTU picco per database>>)
    • Per il modello di acquisto basato su vCore:
      • MAX(<Numero totale di database × utilizzo medio vCore per database, <numero di database con picco simultaneo × utilizzo vCore di picco per database>>)
  2. Stimare lo spazio di archiviazione totale necessario per il pool aggiungendo le dimensioni dei dati necessarie per tutti i database nel pool. Per il modello di acquisto DTU, determinare le dimensioni del pool eDTU che forniscono questa quantità di archiviazione.
  3. Per il modello di acquisto basato su DTU, prendere le dimensioni maggiori delle stime eDTU dal passaggio 1 e dal passaggio 2. Per il modello di acquisto basato su vCore, prendere la stima vCore dal passaggio 1.
  4. Vedere la pagina dei prezzi database SQL e trovare le dimensioni più piccole del pool maggiore della stima del passaggio 3.
  5. Confrontare il prezzo del pool dal passaggio 4 al prezzo dell'uso delle dimensioni di calcolo appropriate per i singoli database.

Importante

Se il numero di database in un pool si avvicina al massimo supportato, assicurarsi di considerare la gestione delle risorse in pool elastici densi.

Proprietà per database

Facoltativamente, è possibile impostare le proprietà per database per modificare i modelli di consumo delle risorse nei pool elastici. Per altre informazioni, vedere la documentazione sui limiti delle risorse per i pool elastici DTU e vCore .

Usare altre funzionalità di database SQL con pool elastici

È possibile usare altre funzionalità di database SQL con pool elastici.

Processi e pool elastici

L'uso di un pool permette di semplificare le attività di gestione con l'esecuzione di script in processi elastici. Un processo elastico elimina la maggior parte del tedium associato a un numero elevato di database.

Per altre informazioni sugli altri strumenti di database per l'uso di più database, vedere Scalabilità orizzontale con database SQL.

Opzioni di continuità aziendale per i database in un pool elastico

I database in pool supportano in genere le stesse funzionalità di continuità aziendale disponibili per i singoli database:

Creare un nuovo pool elastico di database SQL usando il portale di Azure

È possibile creare un pool elastico nel portale di Azure in due modi:

  • Creare un pool elastico e selezionare un server esistente o nuovo.
  • Creare un pool elastico da un server esistente.

Per creare un pool elastico e selezionare un server esistente o nuovo:

  1. Passare alla portale di Azure per creare un pool elastico. Cercare e selezionare Azure SQL.

  2. Selezionare Crea per aprire il riquadro Selezionare l'opzione Di distribuzione SQL . Per visualizzare altre informazioni sui pool elastici, nel riquadro Database selezionare Mostra dettagli.

  3. Nel riquadro Database selezionare Pool elastico nell'elenco a discesa Tipo di risorsa. Quindi selezionare Crea.

    Screenshot che mostra la creazione di un pool elastico.

Per creare un pool elastico da un server esistente:

  • Passare a un server esistente e selezionare Nuovo pool per creare un pool direttamente in tale server.

Nota

È possibile creare più pool in un server, ma non aggiungere database da diversi server nello stesso pool.

Il livello di servizio del pool determina le funzionalità disponibili per i database elastici nel pool e la quantità massima di risorse disponibili per ogni database. Per altre informazioni, vedere Limiti delle risorse per i pool elastici nel modello DTU. Per i limiti delle risorse basate su vCore per i pool elastici, vedere Limiti di risorse basate su vCore - pool elastici.

Per configurare le risorse e i prezzi del pool, selezionare Configura pool. Selezionare quindi un livello di servizio, aggiungere database al pool e configurare i limiti delle risorse per il pool e i relativi database.

Dopo aver configurato il pool, selezionare Applica, denominare il pool e selezionare OK per creare il pool.

Monitorare un pool elastico e i relativi database

Dal portale di Azure è possibile monitorare l'uso di un pool elastico e dei database al suo interno. È anche possibile apportare un set di modifiche al pool elastico e inviare tutte le modifiche contemporaneamente. Le modifiche includono l'aggiunta o la rimozione di database, la modifica delle impostazioni del pool elastico o la modifica delle impostazioni del database.

È possibile usare gli strumenti predefiniti di monitoraggio delle prestazioni e avvisi combinati con le classificazioni delle prestazioni. database SQL può anche generare metriche e log delle risorse per semplificare il monitoraggio.

Case study dei clienti

  • SnelStart: SnelStart ha usato pool elastici con database SQL per espandere rapidamente i propri servizi aziendali a un tasso di 1.000 nuovi database SQL al mese.
  • Umbraco: Umbraco usa pool elastici con database SQL per effettuare rapidamente il provisioning e la scalabilità dei servizi per migliaia di tenant nel cloud.
  • Daxko/CSI: Daxko/CSI usa pool elastici con database SQL per accelerare il ciclo di sviluppo e migliorare i servizi e le prestazioni dei clienti.

Passaggi successivi