Livello di servizio Hyperscale

Si applica a: Database SQL di Azure

Azure SQL database si basa sull'architettura del motore di database SQL Server modificata per l'ambiente cloud per garantire la disponibilità elevata anche nei casi di errori dell'infrastruttura. Esistono tre modelli architetturali usati nel database SQL di Azure:

  • Utilizzo generico/Standard
  • Hyperscale
  • Business critical/Premium

Il livello di servizio Hyperscale nel database SQL di Azure è il livello di servizio più recente nel modello di acquisto basato su vCore. Questo livello di servizio è un livello di prestazioni di archiviazione e calcolo altamente scalabile che usa l'architettura di Azure per aumentare l'archiviazione e le risorse di calcolo per un database Azure SQL sostanzialmente oltre i limiti disponibili per i livelli di servizio per utilizzo generico e business critical.

Nota

Funzionalità del livello di servizio Hyperscale

Il livello di servizio Hyperscale nel database SQL di Azure offre le seguenti funzionalità aggiuntive:

  • Supporto per un massimo di 100 TB di dimensioni del database.
  • Backup rapidi del database (in base agli snapshot di file archiviati nell'archiviazione BLOB di Azure) indipendentemente dalle dimensioni senza alcun impatto sulle risorse di calcolo.
  • Ripristino dei database (basati su snapshot di file) in pochi minuti anziché in ore o giorni (non si tratta di un'operazione di dimensionamento dei dati).
  • Prestazioni complessive più elevate grazie alla maggiore velocità effettiva dei log e ai tempi di commit delle transazioni più veloci, indipendentemente dai volumi di dati.
  • Scalabilità rapida: è possibile effettuare il provisioning di una o più repliche di sola lettura per l'offload del carico di lavoro di lettura e per l'uso come hot-standby.
  • Rapida scalabilità verticale: in un tempo costante è possibile aumentare le risorse di calcolo per supportare ingenti carichi di lavoro in base alle esigenze e quindi ridurle nuovamente quando non sono necessarie.

Il livello di servizio Hyperscale elimina molti dei limiti pratici che generalmente caratterizzano i database cloud. Se la maggior parte dei database sono limitati dalle risorse disponibili in un singolo nodo, i database nel livello di servizio Hyperscale non presentano limiti di questo tipo. Grazie all'architettura di archiviazione flessibile, lo spazio di archiviazione aumenta in base alle esigenze. I database Hyperscale, infatti, non vengono creati con una dimensione massima definita. Un database Hyperscale può espandersi in base alle esigenze e la fatturazione viene applicata solo in base alla capacità in uso. Per i carichi di lavoro a elevato utilizzo di lettura, il livello di servizio Hyperscale offre scalabilità orizzontale rapida eseguendo il provisioning di repliche aggiuntive in base alle esigenze per l'offload dei carichi di lavoro di lettura.

Inoltre, il tempo necessario per creare i backup dei database oppure aumentare o diminuire le prestazioni non è più associato al volume dei dati presenti nel database. È possibile eseguire il backup dei database Hyperscale praticamente istantaneamente. È anche possibile ridimensionare un database aumentando o diminuendo la capacità di decine di terabyte in pochi minuti. Questa funzionalità consente di non essere vincolati alle scelte di configurazione iniziali.

Per altre informazioni sulle dimensioni di calcolo per il livello di servizio Hyperscale, vedere Caratteristiche del livello di servizio.

Destinazione d'uso del livello di servizio Hyperscale

Il livello di servizio Hyperscale è destinato a tutti i clienti che richiedono prestazioni e disponibilità superiori, backup e ripristino rapido e/o scalabilità rapida e di calcolo. Ciò include i clienti che passano al cloud per modernizzare le applicazioni e i clienti che usano già altri livelli di servizio in Azure SQL Database. Il livello di servizio Hyperscale supporta un'ampia gamma di carichi di lavoro del database, da OLTP puro a analisi pura. È ottimizzato per i carichi di lavoro OLTP e di elaborazione ibrida e di elaborazione analitica (HTAP).

Importante

I pool elastici non supportano il livello di servizio Hyperscale.

Modello di prezzi del livello di servizio Hyperscale

Il livello di servizio Hyperscale è disponibile solo nel modello vCore. Per allinearsi alla nuova architettura, il modello di prezzi è leggermente diverso da quello del livello di servizio Utilizzo generico o Business critical:

  • Compute:

    Il prezzo dell'unità di calcolo del livello di servizio Hyperscale è per replica. Il prezzo Vantaggio Azure Hybrid viene applicato automaticamente a repliche condisponibilità elevata e denominate automaticamente. Gli utenti possono modificare da 0 a 4 il numero totale di repliche secondarie con disponibilità elevata a seconda dei requisiti di disponibilità e scalabilità e creare fino a 30 repliche denominate per supportare un'ampia gamma di carichi di lavoro con aumento delle istanze in lettura.

  • Spazio di archiviazione:

    Non è necessario specificare le dimensioni massime dei dati durante la configurazione di un database Hyperscale. Nel livello Hyperscale viene addebitato il costo dell'archiviazione per il database in base all'allocazione effettiva. Lo spazio di archiviazione viene allocato automaticamente tra 10 GB e 100 TB e aumenta in base alle esigenze.

Per altre informazioni sui prezzi di Hyperscale, vedere Prezzi di Database SQL di Azure

Confrontare i limiti delle risorse

I livelli di servizio basati su vCore sono differenziati in base alla disponibilità del database e al tipo di archiviazione, alle prestazioni e alle dimensioni massime di archiviazione, come descritto nella tabella seguente:

Utilizzo generico Hyperscale Business Critical
Ideale per Offre opzioni di calcolo e archiviazione bilanciate a prezzi convenienti. La maggior parte dei carichi di lavoro aziendali. Scalabilità automatica delle dimensioni di archiviazione fino a 100 TB, ridimensionamento rapido verticale e orizzontale dell'ambiente di calcolo, ripristino rapido del database. Applicazioni OLTP con frequenza di transazioni elevata e bassi livelli di latenza di I/O. Offre la massima resilienza agli errori e failover rapidi tramite più repliche aggiornate in modo sincrono.
Dimensioni di calcolo Da 1 a 80 vCore Da 1 a 80 vCore1 Da 1 a 80 vCore
Tipo di archiviazione Archiviazione remota Premium (per istanza) Archiviazione disaccoppiata con cache SSD locale (per istanza) Archiviazione SSD locale estremamente veloce (per istanza)
Dimensioni di archiviazione1 5 GB - 4 TB Fino a 100 TB 5 GB - 4 TB
IOPS 500 operazioni di I/O al secondo per vCore con 7.000 operazioni di I/O al secondo massime Hyperscale è un'architettura multilivello con memorizzazione nella cache a più livelli. Le operazioni di I/O al secondo effettive dipenderanno dal carico di lavoro. 5.000 operazioni di I/O al secondo con 200.000 operazioni di I/O al secondo massime
Disponibilità 1 replica, senza scalabilità di lettura, disponibilità elevata con ridondanza della zona (anteprima), nessuna cache locale Più repliche, fino a 4 scalabilità di lettura, disponibilità elevata con ridondanza della zona, cache locale parziale 3 repliche, 1 replica con scalabilità in lettura, disponibilità elevata con ridondanza della zona, risorsa di archiviazione locale completa
Backup Scelta di archiviazione di backup con ridondanza geografica, ridondanza della zona o backup con ridondanza locale, conservazione di 1-35 giorni (predefinito 7 giorni) Scelta di archiviazione di backup con ridondanza geografica, ridondanza della zona o backup con ridondanza locale, conservazione di 1-35 giorni (predefinito 7 giorni) Scelta di archiviazione di backup con ridondanza geografica, ridondanza della zona o backup con ridondanza locale, conservazione di 1-35 giorni (predefinito 7 giorni)

1 I pool elastici non sono supportati nel livello di servizio Hyperscale.

Nota

La conservazione dei backup a breve termine per 1-35 giorni per i database Hyperscale è ora in anteprima.

Architettura con funzioni distribuite

Hyperscale separa il motore di elaborazione delle query dai componenti che forniscono archiviazione e durabilità a lungo termine per i dati. Questa architettura consente di ridimensionare in modo uniforme la capacità di archiviazione per quanto necessario (l'obiettivo iniziale è 100 TB) e di ridimensionare rapidamente le risorse di calcolo.

Il diagramma seguente illustra i diversi tipi di nodi in un database Hyperscale:

Architettura

Altre informazioni sull'architettura delle funzioni distribuite hyperscale.

Vantaggi di scalabilità e prestazioni

Con la possibilità di accelerare/diminuore la velocità dei nodi di calcolo di sola lettura aggiuntivi, l'architettura Hyperscale offre significative funzionalità di scalabilità di lettura e consente inoltre di liberare il nodo di calcolo primario per la gestione di più richieste di scrittura. Inoltre, i nodi di calcolo possono essere aumentati o diminuiti rapidamente grazie all'architettura di archiviazione condivisa dell'architettura Hyperscale.

Creare e gestire i database Hyperscale

È possibile creare e gestire database Hyperscale usando la portale di Azure, Transact-SQL, PowerShell e l'interfaccia della riga di comando di Azure. Guida introduttiva: Creare un database Hyperscale.

Operazione Dettagli Scopri di più
Creare un database Hyperscale I database Hyperscale sono disponibili solo usando il modello di acquisto basato su vCore. Trovare esempi per creare un database Hyperscale in Avvio rapido: Creare un database Hyperscale in Azure SQL Database.
Aggiornare un database esistente a Hyperscale La migrazione di un database esistente in Azure SQL Database al livello Hyperscale è una dimensione dell'operazione di dati. Informazioni su come eseguire la migrazione di un database esistente a Hyperscale.
Eseguire la migrazione inversa di un database Hyperscale al livello di servizio per utilizzo generico Se in precedenza è stata eseguita la migrazione di un database Azure SQL esistente al livello di servizio Hyperscale, è possibile invertire la migrazione del database al livello di servizio per utilizzo generico entro 45 giorni dalla migrazione originale a Hyperscale.

Se si vuole eseguire la migrazione del database a un altro livello di servizio, ad esempio business critical, eseguire prima la migrazione inversa al livello di servizio per utilizzo generico, quindi modificare il livello di servizio.
Informazioni su come invertire la migrazione da Hyperscale, incluse le limitazioni per la migrazione inversa.

Disponibilità elevata del database in Hyperscale

Come in tutti gli altri livelli di servizio, Hyperscale garantisce la durabilità dei dati per le transazioni di commit indipendentemente dalla disponibilità della replica di calcolo. L'entità del tempo di inattività dovuto alla replica primaria non disponibile dipende dal tipo di failover (pianificato e non pianificato), se la ridondanza della zona è configurata e sulla presenza di almeno una replica a disponibilità elevata. In un failover pianificato ,ad esempio un evento di manutenzione, il sistema crea la nuova replica primaria prima di avviare un failover oppure usa una replica a disponibilità elevata esistente come destinazione di failover. In un failover non pianificato ,ad esempio un errore hardware nella replica primaria, il sistema usa una replica a disponibilità elevata come destinazione di failover se esiste o crea una nuova replica primaria dal pool di capacità di calcolo disponibile. In quest'ultimo caso, la durata del tempo di inattività è più lunga a causa di passaggi aggiuntivi necessari per creare la nuova replica primaria.

Per il contratto di servizio Hyperscale, vedere Contratto di servizio per Azure SQL Database.

Backup e ripristino

Le operazioni di backup e ripristino per i database Hyperscale sono basate su snapshot di file. Ciò consente a queste operazioni di essere quasi istantanee. Poiché l'architettura hyperscale usa il livello di archiviazione per il backup e il ripristino, l'impatto sull'elaborazione e sulle prestazioni per le repliche di calcolo è notevolmente ridotto. Altre informazioni in Backup e ridondanza dell'archiviazione di Hyperscale.

Ripristino di emergenza per i database Hyperscale

Se è necessario ripristinare un database Hyperscale in Azure SQL Database in un'area diversa da quella attualmente ospitata, come parte di un'operazione di ripristino di emergenza o un'operazione di ripristino di emergenza, la rilocazione o qualsiasi altro motivo, il metodo primario consiste nell'eseguire un ripristino geografico del database. Il ripristino geografico è disponibile solo quando l'archiviazione con ridondanza geografica (RA-GRS) è stata scelta per la ridondanza dell'archiviazione.

Altre informazioni sul ripristino di un database Hyperscale in un'area diversa.

Limitazioni note

Si tratta delle limitazioni correnti del livello di servizio Hyperscale. Stiamo lavorando attivamente per rimuovere il maggior numero possibile di queste limitazioni.

Problema Descrizione
Conservazione dei backup a breve termine La conservazione dei backup a breve termine per 1-35 giorni per i database Hyperscale è ora in anteprima. Non è possibile ripristinare un database non Hyperscale come database Hyperscale e non è possibile ripristinare un database Hyperscale come database non Hyperscale.

Per i database migrati a Hyperscale da altri livelli di servizio del database Azure SQL, i backup di pre-migrazione vengono mantenuti per la durata del periodo di conservazione dei backup del database di origine, inclusi i criteri di conservazione a lungo termine. Il ripristino di un backup di pre-migrazione entro il periodo di conservazione del backup del database è supportato tramite la riga di comando. È possibile ripristinare questi backup in qualsiasi livello di servizio non Hyperscale.
Conservazione del backup a lungo termine La conservazione dei backup a lungo termine per i database Hyperscale è ora disponibile in anteprima.
Il passaggio del livello di servizio da Hyperscale a per utilizzo generico livello è supportato direttamente in scenari limitati La migrazione inversa da Hyperscale consente ai clienti che hanno recentemente eseguito la migrazione di un database di Azure SQL esistente al livello di servizio Hyperscale per passare al livello per utilizzo generico, se Hyperscale non soddisfa le proprie esigenze. Anche se la migrazione inversa viene avviata da una modifica al livello di servizio, si tratta essenzialmente di uno spostamento di dimensioni dei dati tra architetture diverse. I database creati nel livello di servizio Hyperscale non sono idonei alla migrazione inversa. Informazioni sulle limitazioni per la migrazione inversa.

Per i database che non sono idonei per la migrazione inversa, l'unico modo per eseguire la migrazione da Hyperscale a un livello di servizio non Hyperscale consiste nell'esportare/importare usando un file bacpac o altre tecnologie di spostamento dei dati (copia bulk, Azure Data Factory, Azure Databricks, SSIS e così via) Esportazione/importazione bacpac da portale di Azure, da PowerShell usando New-AzSqlDatabaseExport o New-AzSqlDatabaseImport, dall'interfaccia della riga di comando di Azure usando az sql db export e az sql db import e dall'API REST non è supportata. L'importazione e l'esportazione di file BACPAC per database Hyperscale di dimensioni inferiori (fino a 200 GB) sono supportate tramite SSMS e SqlPackage versione 18.4 e successive. Per i database di dimensioni superiori, l'esportazione o l'importazione di file BACPAC potrebbe richiedere tempo e potrebbe avere esito negativo per diversi motivi.
Pool elastici I pool elastici non sono attualmente supportati con Hyperscale.
Migrazione dei database con oggetti OLTP In-Memory Hyperscale supporta un subset di oggetti OLTP In-Memory, inclusi i tipi di tabella ottimizzati per la memoria, le variabili di tabella e i moduli compilati in modo nativo. Tuttavia, quando tutti gli oggetti OLTP In-Memory sono presenti nel database in fase di migrazione, la migrazione da livelli di servizio Premium e business critical a Hyperscale non è supportata. Per eseguire la migrazione di tale database a Hyperscale, è necessario eliminare tutti gli oggetti OLTP In-Memory e le relative dipendenze. Dopo la migrazione del database, questi oggetti possono essere ricreati. Le tabelle ottimizzate per la memoria durevoli e non durevoli non sono attualmente supportate in Hyperscale e devono essere modificate nelle tabelle su disco.
Compatta database DBCC SHRINKDATABASE, DBCC SHRINKFILE o impostazione AUTO_SHRINK su ON a livello di database, non sono attualmente supportati per i database Hyperscale.
Controllo dell'integrità del database DBCC CHECKDB non è attualmente supportato per i database Hyperscale. DBCC CHECKTABLE ('TableName') WITH TABLOCK e DBCC CHECKFILEGROUP WITH TABLOCK possono essere usati come soluzione alternativa. Vedere Integrità dei dati in Azure SQL Database per informazioni dettagliate sulla gestione dell'integrità dei dati in Azure SQL Database.
Processi elastici L'uso di un database Hyperscale come database processo non è supportato. I processi elastici possono tuttavia essere destinati a database Hyperscale nello stesso modo di qualsiasi altro database in Azure SQL Database.
Sincronizzazione dei dati L'uso di un database Hyperscale come database hub o metadati di sincronizzazione non è supportato. Tuttavia, un database Hyperscale può essere un database membro in una topologia di sincronizzazione dati.

Passaggi successivi

Altre informazioni su Hyperscale in Azure SQL Database negli articoli seguenti: