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

Per altre informazioni sulla disponibilità generale dei pool elastici per Hyperscale, vedere Blog: Pool elastici Hyperscale disponibili a livello generale.

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.

L'aggiunta di database non Hyperscale a un pool elastico Hyperscale converte 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:

Convertire i database non Hyperscale verso pool elastici Hyperscale

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

Quando si converte un database a pool elastici Hyperscale, tenere presente il numero massimo di database per ogni pool elastico Hyperscale.

Convertire database non Hyperscale verso pool elastici Hyperscale usando T-SQL

È possibile usare i comandi T-SQL per convertire più database per utilizzo generico 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 conversione da utilizzo generico a Hyperscale, specificando che la destinazione SERVICE_OBJECTIVE è un pool elastico Hyperscale. Ognuno dei comandi precedenti avvia conversione del rispettivo database per utilizzo generico verso Hyperscale. La restituzione di questi ALTER DATABASE comandi è rapida e non attendono il completamento della conversione. Nell'esempio illustrato si avranno quattro conversioni di questo tipo da utilizzo generico 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 conversione in background.

Convertire database non Hyperscale verso pool elastici Hyperscale usando PowerShell

È possibile usare i comandi di PowerShell per convertire più database per utilizzo generico 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 conversione. In questo caso, si richiede implicitamente una conversione 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 conversioni 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 conversione 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 singolo database Hyperscale: 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/s.
    • La frequenza di generazione dei log di 150 MB/s è disponibile come funzionalità di anteprima del consenso esplicito. Per altre informazioni e per acconsentire esplicitamente a 150 MB/s, vedere Blog: Miglioramenti di Hyperscale di novembre 2024.
  • 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.

Limiti

Tenere presente le limitazioni seguenti:

  • La modifica di un pool elastico non Hyperscale esistente nell'edizione Hyperscale non è supportata. La sezione relativa alla conversione 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 per utilizzo generico 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

Ecco alcune considerazioni per i 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 convertire 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
L'aggiunta di un database da un pool elastico Hyperscale con ridondanza della zona a un gruppo di failover con un pool elastico Hyperscale con ridondanza non di zona in un'altra area avrà esito negativo, ma l'operazione potrebbe sembrare in esecuzione senza alcun progresso. È possibile che il database secondario geografico venga visualizzato quando si usano strumenti come SSMS, ma non è possibile connettersi e usare il database secondario geografico. Il gruppo di failover può mostrare lo stato "Seeding 0%" per il database secondario geografico. Questo errore non si verifica se il secondo pool elastico Hyperscale è con ridondanza della zona. Per risolvere questo problema, configurare la replica geografica all'esterno del gruppo di failover usando Azure PowerShell, specificando in modo esplicito la ridondanza non di zona nella riga di comando New-AzSqlDatabaseSecondary -ResourceGroupName "primary-rg" -ServerName "primary-server" -DatabaseName "hsdb1" -PartnerResourceGroupName "secondary-rg" -PartnerServerName "secondary-server" -AllowConnections "All" -SecondaryElasticPoolName "secondary-nonzr-pool" -BackupStorageRedundancy Local -ZoneRedundant:$false. Quindi, è possibile aggiungere il database al gruppo di failover.
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