Che cos'è un pool di istanze (anteprima)? - Istanza gestita di SQL di Azure
Si applica a: 
Istanza gestita di SQL di Azure SQL
Questo articolo offre una panoramica dell'opzione di distribuzione del pool di istanze per Istanza gestita di SQL di Azure.
I pool di istanze consentono di distribuire più istanze con risorse condivise, che offre un'infrastruttura conveniente e conveniente per eseguire la migrazione di più database da istanze di SQL Server senza dover consolidare carichi di lavoro più piccoli e meno a elevato utilizzo di calcolo in un’Istanza gestita di SQL più grande.
Per iniziare, vedere Creare un pool di istanze.
Nota
I pool di istanze per l’istanza gestita di SQL di Azure è attualmente in anteprima.
Panoramica
I pool di istanze in Istanza gestita di SQL di Azure consentono di distribuire più istanze con risorse condivise in una singola macchina virtuale sottostante all'interno di un cluster virtuale.
I pool di istanze offrono i seguenti vantaggi principali:
- Possibilità di ospitare istanze 2-vCore, disponibili solo all'interno dei pool di istanze
- Tempo di distribuzione dell'istanza prevedibile e veloce (fino a 5 minuti).
- Infrastruttura con risparmio di costi durante la migrazione di più istanze di SQL Server.
La figura seguente illustra un pool di istanze con più istanze gestite distribuite in un cluster virtuale all’interno di una subnet della rete virtuale:
Novità
L'aggiornamento dell'anteprima 2024 dei pool di istanze offre le nuove funzionalità seguenti:
- La configurazione del pool, ad esempio le dimensioni di calcolo, la licenza, le proprietà, può essere aggiornata usando PowerShell o l'interfaccia della riga di comando di Azure.
- L'hardware della serie Premium è ora supportato.
- È possibile spostare un'istanza all'interno e all'esterno del pool usando PowerShell o l'interfaccia della riga di comando di Azure.
Architettura
I pool di istanze hanno un'architettura simile a quella delle istanze gestite singole. Per supportare le distribuzioni all'interno delle reti virtuali di Azure e garantire l'isolamento e la sicurezza per i clienti, i pool di istanze si basano anche su cluster virtuali. I cluster virtuali rappresentano un set dedicato di macchine virtuali isolate distribuite all'interno della subnet della rete virtuale del cliente. Tutte le istanze singole e i pool di istanze appartengono allo stesso cluster virtuale. Le istanze in un pool e le istanze singole distribuite nella stessa subnet non condividono le risorse di calcolo allocate ai processi di SQL Server e ai componenti del gateway, garantendo in questo modo la prevedibilità delle prestazioni. Dopo la distribuzione iniziale del pool, le operazioni di gestione sulle istanze in un pool sono più veloci perché il cluster virtuale è già stato esteso al momento del provisioning del pool.
Le dimensioni di calcolo della macchina virtuale si basano sul numero totale di vCore allocati al pool, che vengono distribuiti tra istanze nel pool. Questa architettura consente il partizionamento della macchina virtuale in più istanze, che possono essere di qualsiasi dimensione supportata, incluse le istanze di 2 vCore (disponibili solo per le istanze nei pool). Ad esempio, quando si distribuisce un pool di istanze 8-vCore, è possibile distribuire due 2-vCore e un'istanza 4-vCore. È quindi possibile eseguire la migrazione dei database di SQL Server alle istanze all'interno del pool. Siccome i pool di istanze supportano l'integrazione nativa della rete virtuale, in modo da poter distribuire più pool di istanze e più istanze singole nella stessa subnet.
La differenza principale tra i due modelli di distribuzione consiste nel fatto che è possibile creare più processi di SQL Server all'interno della stessa macchina virtuale quando si usa un pool di istanze, che sono risorse regolate usando gli oggetti del processo di Windows. Le istanze singole hanno solo un singolo processo di SQL Server nel nodo della macchina virtuale.
Il diagramma seguente illustra la differenza architetturale principale tra i due modelli di distribuzione:
Scenari applicativi
Prendere in considerazione l'uso di pool di istanze per gli scenari seguenti:
- Migrazione simultanea di un gruppo di istanze di SQL Server, in cui la maggior parte delle istanze è di dimensioni ridotte, ad esempio 2 o 4 vCore.
- È necessario poter creare o ridimensionare le istanze in modo rapido e prevedibile. Ad esempio, la distribuzione di un nuovo tenant in un ambiente multi-tenant con applicazioni SaaS che richiede funzionalità a livello di istanza.
- Avere costi fissi o limiti di spesa è importante. Ad esempio, l'esecuzione di ambienti demo o di sviluppo/test condivisi di dimensioni fisse (o modificate raramente), in cui si distribuiscono periodicamente istanze gestite quando necessario.
I pool di istanze sono particolarmente adatti per la migrazione di più istanze di SQL Server, poiché il pre-provisioning delle risorse di calcolo condivise in base ai requisiti di migrazione totali riduce il costo complessivo della proprietà dopo la migrazione. Si consideri, ad esempio, uno scenario per eseguire la migrazione di quattro istanze di SQL Server locali di piccole dimensioni a Istanza gestita di SQL di Azure. Senza un pool di istanze, è possibile effettuare il provisioning di quattro istanze gestite di SQL separate con almeno 4 vCore ognuna con le proprie risorse dedicate. Un pool di istanze riduce questo costo perché è possibile distribuire tutte le istanze con 2 vCore ognuna nel pool in cui le risorse sono condivise dal pool.
Proprietà dell'istanza e del pool
Le proprietà seguenti sono configurate a livello di pool per tutte le istanze del pool:
- Livelli hardware
- Licenza di SQL Server, ad esempio il Vantaggio Azure Hybrid
- Finestra di manutenzione
Valutare anche gli aspetti seguenti:
- Le istanze gestite create nei pool supportano gli stessi livelli di compatibilità e le stesse funzionalità supportate nelle singole istanze gestite.
- Le funzionalità facoltative o le funzionalità che richiedono la scelta di valori specifici, ad esempio regole di confronto a livello di istanza, fuso orario, endpoint pubblico per il traffico dati, gruppi di failover, vengono configurate a livello di istanza e possono essere diverse per ogni istanza in un pool.
- Poiché le istanze distribuite in un pool condividono la stessa macchina virtuale, è opportuno considerare la possibilità di disabilitare le funzionalità che comportano rischi di sicurezza più elevati o controllare costantemente le autorizzazioni di accesso a queste funzionalità, come l’integrazione CLR, il backup e ripristino nativi, l’email del database, ecc.
- È possibile configurare l’Istanza gestita di SQL per l'uso dell'autenticazione di Microsoft Entra prima o dopo l'aggiunta al pool.
- Ogni istanza gestita distribuita in un pool dispone di un'istanza separata di SQL Agent.
Limiti delle risorse
Quando si distribuisce un'istanza in un pool, sono previsti limiti per ogni singola istanza in pool e limiti alle risorse usate dal pool complessivo.
La tabella seguente illustra in dettaglio i limiti per le istanze in pool e per il pool:
| Limiti pool | Limiti delle istanze in pool | |
|---|---|---|
| Livello di servizio | Utilizzo generico | Utilizzo generico |
| Livello hardware | Serie standard (Gen5) Serie Premium |
Serie standard (Gen5) Serie Premium |
| Numero di vCore1 | 8-16-24-32-40-64-80 | 2-4-8-16-24-32-40-64-80 |
| Spazio di archiviazione massimo | 32 TB2 | - 640 GB per 2 vCore - 2 TB per 4 vCore - 8 TB per 8 vCore - 16 TB per 16+ vCore |
| Nr. massimo di database | 500 | - 50 TB per 2 vCore - 100 per 4+ vCore |
| Numero massimo di istanze | 40 | N/D |
1 Le opzioni vCore per le istanze in pool dipendono anche dal numero di vCore disponibili nel pool di istanza.
2 Il limite di archiviazione del pool è determinato dalla somma dello spazio di archiviazione per tutte le istanze nel pool.
Per tutti gli altri limiti a livello di istanza, vedere Limiti delle risorse.
Considerazioni sulle prestazioni
Sebbene le istanze gestite all'interno dei pool dispongano di vCore e RAM dedicati, condividono il disco locale (per tempdb) e le risorse di rete. Non è probabile, ma è possibile sperimentare l'effetto noisy neighbor se più istanze nel pool hanno un consumo di risorse elevato allo stesso tempo.
Se si verifica questo comportamento, valutare la possibilità di aumentare le dimensioni del pool o ridistribuire le risorse che consumano molto in modo elevato come singola istanza esterna al pool.
Fatturazione dei pool di istanze
I pool di istanze consentono di dimensionare le risorse di calcolo e archiviazione in modo indipendente. Si paga per:
- Calcolo allocato al pool, misurato in vCore
- Archiviazione associati a ogni istanza misurata in gigabyte (i primi 32 GB sono gratuiti per ogni istanza).
Il prezzo dei vCore per un pool viene addebitato indipendentemente dal numero di istanze distribuite nel pool. Non è possibile impostare opzioni di prezzo diverse per le singole istanze in un pool. Tutte le istanze nel pool devono usare lo stesso modello di licenza. Il modello di licenza per il pool può essere modificato dopo la creazione del pool.
Il prezzo di calcolo (misurato in vCore), dipende dal fatto che si stia pagando o meno il prezzo di licenza completo di SQL Server. Sono disponibili le seguenti due opzioni di prezzo:
- Licenza inclusa: il prezzo delle licenze di SQL Server è incluso.
- Vantaggio Azure Hybrid: un prezzo ridotto che include Vantaggio Azure Hybrid per SQL Server. I clienti possono scegliere questo prezzo usando le licenze di SQL Server esistenti con Software Assurance.
Per informazioni dettagliate sui prezzi dei pool di istanze, vedere la sezione pool di istanze nella pagina relativa ai prezzi delle istanze gestite di SQL.
Nota
I pool di istanze creati in sottoscrizioni idonee per il vantaggio sviluppo/test ricevono automaticamente tariffe scontate fino al 55% per l'istanza gestita di SQL di Azure.
Limiti
Per altre informazioni, vedere limitazioni del pool di istanze.