Panoramica dei pool elastici Hyperscale nel database SQL di Azure

  • Articolo

Si applica a:Database SQL di Azure

Questo articolo offre una panoramica dei pool elastici Hyperscale nel database SQL di Azure.

Un pool elastico nel database SQL di Azure consente agli sviluppatori di SaaS di ottimizzare il rapporto prezzo-prestazioni per un gruppo di database all'interno di un budget definito, garantendo allo stesso tempo elasticità di prestazioni per ogni database. I pool elastici Hyperscale del database SQL di Azure introducono un modello di risorse condiviso per i database Hyperscale.

Per esempi su creare, ridimensionare o spostare database in un pool elastico Hyperscale usando l'interfaccia della riga di comando di Azure o PowerShell, vedere Uso dei pool elastici Hyperscale con utilità da riga di comando

Nota

I pool elastici per Hyperscale sono attualmente disponibili in anteprima.

Panoramica

Implementare il database Hyperscale in un pool elastico per condividere le risorse tra i database all'interno del pool e ottimizzare il costo dell'avere più database con modelli di utilizzo diversi.

Scenari per l'uso di un pool elastico con i database Hyperscale:

  • Quando è necessario aumentare o ridurre le risorse di calcolo assegnate al pool elastico in un periodo di tempo prevedibile, indipendentemente dalla quantità di spazio di archiviazione assegnato.
  • Quando si vuole aumentare le istanze delle risorse di calcolo assegnate al pool elastico aggiungendo una o più repliche con scalabilità in lettura.
  • Se si vuole usare una velocità effettiva elevata del log delle transazioni per carichi di lavoro a elevato utilizzo di scrittura, anche con risorse di calcolo inferiori.

La migrazione di database non Hyperscale a un pool elastico Hyperscale aggiorna i database al livello di servizio Hyperscale.

Architettura

Tradizionalmente, l'architettura di un database Hyperscale autonomo è costituita da tre componenti indipendenti principali: Calcolo, Archiviazione ("Server di pagina") e il log ("Servizio di log"). Quando si crea un pool elastico per i database Hyperscale, i database all'interno del pool condividono risorse di calcolo e log. Inoltre, se si sceglie di configurare la disponibilità elevata, ogni pool di disponibilità elevata viene creato con un set equivalente e indipendente di risorse di calcolo e log.

Di seguito viene descritta l'architettura di un pool elastico per i database Hyperscale:

  • Un pool elastico Hyperscale è costituito da un pool primario che ospita i database Hyperscale primari e, se configurato, fino a quattro pool di disponibilità elevata aggiuntivi.
  • I database Hyperscale primari ospitati nel pool elastico primario condividono il processo di calcolo del motore del database di SQL Server (sqlservr.exe), i vCore, la memoria e la cache SSD.
  • La configurazione della disponibilità elevata per il pool primario crea pool di disponibilità elevata aggiuntivi che contengono repliche di database di sola lettura per i database nel pool primario. Ogni pool primario può avere un massimo di quattro pool di repliche a disponibilità elevata. Ogni pool a disponibilità elevata condivide le risorse di calcolo, cache SSD e memoria per tutti i database secondari di sola lettura nel pool.
  • I database Hyperscale nel pool elastico primario condividono tutti lo stesso servizio di log. Poiché i database nei pool a disponibilità elevata non hanno un carico di lavoro di scrittura, non usano il servizio di log.
  • Ogni database Hyperscale ha un proprio set di server di pagina e questi server di pagina vengono condivisi tra il database primario nel pool primario e tutti i database di replica secondaria nel pool a disponibilità elevata.
  • I database Hyperscale secondari con replica geografica possono essere inseriti all'interno di un altro pool elastico.
  • Specificando ApplicationIntent=ReadOnly nella stringa di connessione del database si viene indirizzati a un database di replica di sola lettura in uno dei pool a disponibilità elevata.

Il diagramma seguente illustra l'architettura di un pool elastico per i database Hyperscale:

Diagramma che mostra l'architettura del pool elastico Hyperscale.

Gestire i database del pool elastico Hyperscale

È possibile usare gli stessi comandi per gestire i database Hyperscale in pool come database in pool negli altri livelli di servizio. Assicurarsi di specificare Hyperscale l'edizione quando si crea il pool elastico Hyperscale.

L'unica differenza è la possibilità di modificare il numero di repliche H/A (a disponibilità elevata) per un pool elastico Hyperscale esistente. A questo scopo:

È possibile usare gli strumenti client seguenti per gestire i database Hyperscale in un pool elastico:

Eseguire la migrazione di database non Hyperscale verso pool elastici Hyperscale

Quando si esegue la migrazione di un database a Hyperscale, è possibile aggiungere il database a un pool elastico Hyperscale esistente. Per queste migrazioni, il pool elastico Hyperscale deve esistere nello stesso server logico del database di origine.

Quando si esegue la migrazione di database a pool elastici Hyperscale, tenere presente il numero massimo di database per ogni pool elastico Hyperscale.

Eseguire la migrazione di database non Hyperscale verso pool elastici Hyperscale usando T-SQL

È possibile usare i comandi T-SQL per eseguire la migrazione di più database General Purpose e aggiungerli a un pool elastico Hyperscale esistente denominato hsep1:

ALTER DATABASE gpepdb1 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb2 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb3 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))
ALTER DATABASE gpepdb4 MODIFY (SERVICE_OBJECTIVE = ELASTIC_POOL(NAME = [hsep1]))

In questo esempio si richiede implicitamente una migrazione da General Purpose a Hyperscale, specificando che la destinazione SERVICE_OBJECTIVE è un pool elastico Hyperscale. Ognuno dei comandi precedenti avvia la migrazione del rispettivo database General Purpose verso Hyperscale. La restituzione di questi ALTER DATABASE comandi è rapida e non attendono il completamento della migrazione. Nell'esempio illustrato si avranno quattro migrazioni di questo tipo da General Purpose a Hyperscale in esecuzione in parallelo.

È possibile eseguire una query sulla vista a gestione dinamica sys.dm_operation_status per monitorare lo stato di queste operazioni di migrazione in background.

Eseguire la migrazione di database non Hyperscale verso pool elastici Hyperscale usando PowerShell

È possibile usare i comandi di PowerShell per eseguire la migrazione di più database General Purpose e aggiungerli a un pool elastico Hyperscale esistente denominato hsep1. Il seguente script di esempio esegue questi passaggi:

  1. Usare il cmdlet Get-AzSqlElasticPoolDatabase per elencare tutti i database nel pool elastico General Purpose denominato gpep1.
  2. Il Where-Object cmdlet filtra l'elenco solo per i nomi di database che iniziano con gpepdb.
  3. Per ogni database, il cmdlet Set-AzSqlDatabase avvia una migrazione. In questo caso, si richiede implicitamente una migrazione al livello di servizio Hyperscale specificando il pool elastico Hyperscale di destinazione denominato hsep1.
    • Il parametro -AsJob consente l'esecuzione in parallelo di ognuna delle richieste Set-AzSqlDatabase. Se si preferisce eseguire le migrazioni una alla volta, è possibile rimuovere il parametro -AsJob.
$dbs = Get-AzSqlElasticPoolDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -ElasticPoolName "gpep1"
$dbs | Where-Object { $_.DatabaseName -like "gpepdb*" } | % { Set-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "mylogicalserver" -DatabaseName ($_.DatabaseName) -ElasticPoolName "hsep1" -AsJob }

Oltre alla vista a gestione dinamica sys.dm_operation_status, è possibile usare il cmdlet di PowerShell Get-AzSqlDatabaseActivity per monitorare lo stato di queste operazioni di migrazione in background.

Limiti delle risorse

Di seguito sono elencati i limiti supportati per l'uso dei database Hyperscale all'interno dei pool elastici:

  • Generazione di hardware supportata: serie Standard (Gen5), serie Premium e Premium ottimizzata per la memoria.
  • vCore massimo per pool: 80 o 128 vCore, a seconda dell'obiettivo del livello di servizio.
  • Dimensioni massime dei dati supportate per database: 100 TB.
  • Dimensioni massime dei dati totali supportate tra database nel pool: 100 TB.
  • Velocità effettiva massima supportata del log delle transazioni per database: 100 MB.
  • Velocità effettiva totale massima supportata del log delle transazioni tra database nel pool: 131,25 MB al secondo.
  • Ogni pool elastico Hyperscale può avere fino a 25 database.

Per altri dettagli, vedere i limiti delle risorse dei pool elastici Hyperscale per le serie Standard, le serie Premium e Premium ottimizzate per la memoria.

Nota

I profili di prestazioni, le capacità supportate e i limiti pubblicati sono soggetti a modifiche mentre la funzionalità è in anteprima. Di conseguenza, è consigliabile convalidare il caso d'uso con normali test funzionali, prestazioni e dimensionamento dei carichi di lavoro.

Limiti

Tenere presente le limitazioni seguenti:

  • La modifica di un pool elastico non Hyperscale esistente nell'edizione Hyperscale non è supportata. La sezione relativa alla migrazione offre alcune alternative che è possibile usare.
  • La modifica dell'edizione di un pool elastico Hyperscale in un'edizione non Hyperscale non è supportata.
  • Per invertire la migrazione di un database idoneo, che si trova in un pool elastico Hyperscale, è necessario prima rimuoverlo dal pool elastico Hyperscale. È quindi possibile invertire la migrazione del database Hyperscale autonomo a un database General Purpose autonomo.
  • Per il livello di servizio Hyperscale, il supporto della ridondanza della zona può essere specificato solo durante la creazione del database o del pool elastico e non può essere modificato dopo il provisioning della risorsa. Per maggiori informazioni, vedere Migrazione del database SQL di Azure al supporto della zona di disponibilità.
  • L'aggiunta di una replica denominata in un pool elastico Hyperscale non è supportata. Il tentativo di aggiungere una replica denominata di un database Hyperscale a un pool elastico Hyperscale genera un UnsupportedReplicationOperation errore. Creare invece la replica denominata come singolo database Hyperscale.

Considerazioni relative ai pool elastici con ridondanza della zona

Per i pool elastici con ridondanza della zona, tenere presente quanto segue:

Nota

I pool elastici Hyperscale con ridondanza della zona sono attualmente disponibili in anteprima. Per maggiori informazioni, vedere il post di blog: Pool elastici Hyperscale con ridondanza della zona.

  • Solo i database con ridondanza dell'archiviazione con ridondanza della zona (ZRS o GZRS) possono essere aggiunti ai pool elastici Hyperscale con ridondanza della zona.
  • È necessario creare un database Hyperscale autonomo con ridondanza della zona e archiviazione di backup con ridondanza della zona (ZRS o GZRS) per aggiungerlo a un pool elastico Hyperscale con ridondanza della zona. Per i database Hyperscale senza ridondanza della zona, eseguire un trasferimento dei dati in un nuovo database Hyperscale con l'opzione di ridondanza della zona abilitata. È necessario creare un clone usando la copia del database, il ripristino temporizzato o la replica geografica. Per maggiori informazioni, vedere Ridistribuzione (Hyperscale).
  • Per spostare un database Hyperscale da un pool elastico a un altro, le impostazioni di ridondanza della zona e archiviazione di backup con ridondanza della zona devono corrispondere.
  • Per eseguire la migrazione di un database da un altro livello di servizio non Hyperscale in un pool elastico Hyperscale con ridondanza della zona:
    • Tramite il portale di Azure, abilitare prima sia la ridondanza della zona che l'archiviazione di backup con ridondanza della zona. È quindi possibile aggiungere il database al pool elastico Hyperscale con ridondanza della zona.
    • Tramite PowerShell abilitare prima la ridondanza della zona. Successivamente, con Set-AzSqlDatabase, assicurarsi che il parametro -BackupStorageRedundancy venga usato per specificare l'archiviazione di backup con ridondanza della zona (ZRS o GZRS).

Problemi noti

Problema Elemento consigliato
In rari casi, è possibile che venga visualizzato l'errore 45122 - This Hyperscale database cannot be added into an elastic pool at this time. In case of any questions, please contact Microsoft support, quando si tenta di spostare/ripristinare/copiare un database Hyperscale in un pool elastico. Questa limitazione è dovuta ai dettagli specifici dell'implementazione. Se questo errore blocca l'utente, segnalare un evento imprevisto di supporto e richiedere assistenza.

Contenuto correlato