I pool elastici consentono di gestire e dimensionare più database nel database SQL di Azure

SI APPLICA A: Database SQL di Azure

database SQL di Azure pool elastici sono 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 sono in un singolo server e condividono un certo numero di risorse a un prezzo impostato. I pool elastici nel database SQL di Azure consentono agli sviluppatori di SaaS di ottimizzare i costi per un gruppo di database all'interno di un budget definito, garantendo allo stesso tempo prestazioni elastiche per ogni database.

Definizione di pool elastici SQL

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

  • Effettuare il provisioning di risorse eccessivo in base all'utilizzo massimo e pagare più del necessario, o
  • Ricorrere al provisioning insufficiente per risparmiare sui costi, a scapito delle prestazioni e della soddisfazione del cliente 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 applicazioni SaaS con pool elastici, vedere l'articolo relativo ai modelli di progettazione per applicazioni SaaS multi-tenant con database SQL di Azure.

Importante

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

I pool elastici consentono agli sviluppatori di acquistare risorse per un pool condiviso da più database, in modo da supportare periodi di utilizzo imprevisti da parte dei 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 dipende dal budget dello sviluppatore. Lo sviluppatore aggiunge semplicemente database al pool, imposta facoltativamente le risorse minime e massime per i database (DTO minime e massime o vCore minimi o massimi a seconda del modello di risorse scelto) e quindi imposta le risorse del pool in base al budget. Utilizzando i pool, lo sviluppatore può aumentare con facilità i servizi offerti da una piccola nuova impresa fino a un'azienda matura in continua crescita.

All'interno del pool i singoli database sono sufficientemente flessibili da assicurare una scalabilità automatica nell'ambito di parametri prefissati. 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 risorse aggiuntive a un pool esistente con tempo di inattività minimo. Analogamente, se le risorse aggiuntive non sono più necessarie, è possibile rimuoverle da un pool esistente in qualsiasi momento. Ed è possibile aggiungere o rimuovere database dal pool. Se si prevede che un database sottoutilizzerà le proprie risorse, è possibile rimuoverlo.

Nota

Quando si spostano database all'interno o all'esterno di un pool elastico, non si verifica alcun tempo di inattività, ad eccezione di un breve periodo (nell'ordine di secondi) alla fine dell'operazione, quando vengono rilasciate 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 ridotto con picchi di utilizzo relativamente poco 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 massimo 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 utilizzano pool Standard, ma gli stessi principi si applicano anche ai pool Basic e Premium.

Valutazione dei modelli di utilizzo di database

Nella figura seguente viene illustrato un esempio di un database che trascorre il tempo di inattività, ma anche periodicamente picchi di attività. Si tratta di un modello di utilizzo adatto per un pool:

un database singolo adatto per un pool

Il grafico illustra l'utilizzo di DTU in un periodo di tempo di 1 ora dalle 12:00 alle 1:00 in cui ogni punto dati ha granularità di 1 minuto. Alle 12:10 DB1 raggiunge un picco fino a 90 DTO, ma l'utilizzo medio complessivo è inferiore a cinque DTO. L'esecuzione di questo carico di lavoro in un database singolo richiede dimensioni di calcolo S3, ma in questo modo la maggior parte delle risorse rimane inutilizzata durante i periodi di minore attività.

Un pool consente la condivisione tra più database di queste DTU inutilizzate e quindi riduce le DTU richieste e i costi complessivi.

Compila l'esempio precedente, si supponga che vi sono altri database con i modelli di utilizzo simili come DB1. Nelle due figure seguenti vengono presentati in parallelo l'utilizzo di quattro database e quello di 20 database all'interno di uno stesso grafico per mostrare l'assenza di sovrapposizione degli elementi che rappresentano l'utilizzo dei database nel tempo quando viene usato il modello di acquisto basato su DTU:

quattro database con un modello di utilizzo adatto per un pool

venti database con un modello di utilizzo adatto per un pool

Dalla riga di colore nera nella figura precedente viene illustrato l'utilizzo di DTU di aggregazione in tutti i database di 20. Viene illustrato che l'utilizzo di DTU aggregato non mai supera le 100 DTU, ciò indica che i 20 database possono condividere 100 eDTU nel corso di tale periodo di tempo. Questo comporta una riduzione di 20 volte delle DTU e di 13 volte del prezzo rispetto all'inserimento di ogni database in dimensioni di calcolo S3 per singoli database.

In questo esempio è ideale per i motivi seguenti:

  • 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. Mentre il prezzo unitario delle eDTU di un pool è 1,5 volte maggiore del prezzo unitario delle DTU per un database singolo, le eDTU del pool possono essere condivise da molti database ed è necessario un minor numero totale di eDTU. 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 unitario vCore per i pool elastici è lo stesso del prezzo unitario vCore per i database singoli.

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. È quindi necessario stabilire quanto segue:

  • Numero massimo di risorse di calcolo utilizzate da tutti i database nel pool. Le risorse di calcolo vengono indicizzate in base a eDDKU 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.

I passaggi seguenti consentono di stimare se un pool è più conveniente rispetto ai singoli database:

  1. Stimare le eDTU o i vCore necessari per il pool come segue:
    • Per il modello di acquisto basato su DTU:
      • MAX(<Numero totale di DTU medi di database per>, <Numero di picchi simultanei di utilizzo DTU di picco per database per database × × >)
    • Per il modello di acquisto basato su vCore:
      • MAX( database, <Numero di picchi simultanei di utilizzo di × vCore per database 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, considerare la stima di eDTU maggiore tra il Passaggio 1 e il Passaggio 2. Per il modello di acquisto basato su vCore, considerare la stima di vCore del Passaggio 1.
  4. Vedere la pagina sui prezzi del database SQL e trovare la dimensione di pool più piccola, che sia maggiore della stima del Passaggio 3.
  5. Confrontare il prezzo del pool del passaggio 4 con il 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 prendere in considerazione la gestione delle risorse in pool elastici ad alta densità.

Proprietà per database

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

Uso di altre funzionalità del database SQL con i 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 delle attività ripetitive associate a un elevato numero di database.

Per altre informazioni sugli altri strumenti di database per usare più database, vedere Aumentare il numero di istanze con il database SQL di Azure.

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 del database SQL tramite il portale di Azure

Esistono due modi per creare un pool elastico nel portale di Azure.

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

  2. Selezionare +Aggiungi per aprire la pagina Selezionare l'opzione di distribuzione SQL. È possibile visualizzare informazioni aggiuntive sui pool elastici selezionando Mostra dettagli nel riquadro Database.

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

    Creare un pool elastico

  4. Oppure è possibile creare un pool elastico passando a un server esistente e facendo clic su + 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 informazioni dettagliate, vedere i limiti delle risorse per i pool elastici nel modello basato su 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, fare clic su 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.

Al termine della configurazione del pool, è possibile fare clic su Applica, assegnare un nome al pool e fare clic su 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 e avviso delle prestazioni, combinati con le classificazioni delle prestazioni. Inoltre, Database SQL può generare log di metriche e di risorse per semplificare il monitoraggio.

Case study dei clienti

  • SnelStart

    SnelStart ha usato pool elastici con database SQL di Azure per espandere rapidamente i servizi aziendali a una velocità di 1.000 nuovi database SQL Azure al mese.

  • Umbraco

    Umbraco usa pool elastici con database SQL di Azure per effettuare rapidamente il provisioning e il ridimensionamento dei servizi per migliaia di tenant nel cloud.

  • Daxko/CSI

    Daxko/CSI usa pool elastici con database SQL di Azure per accelerare il ciclo di sviluppo e migliorare i servizi e le prestazioni dei clienti.

Passaggi successivi