Condividi tramite

Livello di servizio Hyperscale

  • Articolo

Si applica a:database SQL di Azure

Il Database SQL di Azure si basa sull'architettura del motore di database di SQL Server che viene regolata per l'ambiente cloud per garantire alta disponibilità anche in caso di errori dell'infrastruttura. Esistono tre opzioni di livello di servizio nel modello di acquisto vCore per database SQL di Azure:

  • Utilizzo generico
  • Business Critical
  • Hyperscale

Il livello di servizio Hyperscale è adatto a tutti i tipi di carico di lavoro. L'architettura nativa del cloud offre risorse di calcolo e archiviazione scalabili in modo indipendente per supportare la più ampia gamma di applicazioni tradizionali e moderne. Le risorse di calcolo e archiviazione in Hyperscale superano sostanzialmente le risorse disponibili nei livelli Per utilizzo generico e Business Critical.

Per informazioni dettagliate sui livelli di servizio Utilizzo generico e Business critical nel modello di acquisto basato su vCore, vedere i livelli di servizio Utilizzo generico e Business critical. Per un confronto tra il modello di acquisto basato su vCore e il modello di acquisto basato su vCore, vedi Confrontare i modelli di acquisto basati su vCore e DTU del database SQL di Azure.

Il livello di servizio Hyperscale è attualmente disponibile per il database SQL di Azure, ma non per Istanza gestita di SQL di Azure.

Funzionalità del livello di servizio Hyperscale

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

  • 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.
  • Scale-out rapidoe: è 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.
  • Scalabilità verticale e orizzontale e fatturazione automatiche per il calcolo in base all'utilizzo con elaborazione serverless.
  • Prezzo/prestazioni ottimizzato per un gruppo di database Hyperscale con esigenze di risorse variabili con pool elastici.
  • Archiviazione con scalabilità automatica con supporto per un massimo di 128 TB di dimensioni del pool elastico di database o 100 TB.
  • 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.
  • Backup dei database rapidi (basati su snapshot di file) indipendentemente dalle dimensioni senza alcun impatto delle operazioni di I/O sulle risorse di calcolo.
  • Ripristino database o copie (basati su snapshot di file) in pochi minuti anziché in ore o giorni.

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à di archiviazione assegnata. Per i carichi di lavoro con intense attività di lettura, il livello di servizio Hyperscale consente un rapido scale-out effettuando il provisioning di repliche in lettura aggiuntive in base alle necessità 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. Il backup dei database Hyperscale viene eseguito in maniera praticamente istantanea. È anche possibile dimensionare un database in decine di terabyte verso l'alto o verso il basso entro pochi minuti nel livello di calcolo di cui è stato effettuato il provisioning o usare serverless per dimensionare automaticamente il calcolo. 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à più elevate, backup e ripristino rapidi e/o scalabilità di calcolo e archiviazione veloci. Sono inclusi i clienti che stanno passando al cloud per modernizzare le loro applicazioni e i clienti che usano già altri livelli di servizio nel database SQL di Azure. Il livello di servizio Hyperscale supporta un'ampia gamma di carichi di lavoro di database, da OLTP pulito ad analisi pulita. È ottimizzato per carichi di lavoro OLTP e di elaborazione analitica e transazioni ibride (HTAP).

Modello di prezzi del livello di servizio Hyperscale

Nota

Sono arrivati i prezzi semplificati per Hyperscale di database SQL di Azure! Leggi l'annuncio del nuovo piano tariffario per Hyperscale di database SQL di Azure, mentre per informazioni dettagliate sulle modifiche ai prezzi, vedi Azure SQL Database Hyperscale – lower, simplified pricing!.

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:

  • Calcolo con provisioning:

    Il prezzo dell'unità di calcolo del livello di servizio Hyperscale è per replica. 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 vari carichi di lavoro con aumento delle istanze in lettura.

  • Calcolo serverless:

    La fatturazione delle risorse di elaborazione serverless si basa sull'utilizzo. Per ulteriori informazioni, vedi Livello di calcolo serverless per il database SQL di Azure.

  • 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. L'archiviazione viene allocata automaticamente tra 10 GB e 128 TB e aumenta in incrementi di 10 GB in base alle esigenze.

Per altre informazioni sui prezzi di Hyperscale, si veda Prezzi di Database SQL di Azure.

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 senza problemi la capacità di archiviazione per quanto necessario (fino a 128 TB) e la possibilità di ridimensionare rapidamente le risorse di calcolo.

Il diagramma seguente illustra l'architettura funzionale di Hyperscale:

Diagramma che mostra l'architettura Hyperscale.

Ulteriori informazioni sull'architettura funzionale distribuita di 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. I nodi di calcolo di sola lettura in Hyperscale sono disponibili anche nel livello di elaborazione serverless, che dimensiona automaticamente le risorse di calcolo in base alla domanda del carico di lavoro.

Disponibilità elevata del database in Hyperscale

Come in tutti gli altri livelli di servizio, Hyperscale garantisce la durabilità dei dati per le transazioni di cui è stato eseguito il commit indipendentemente dalla disponibilità della replica di calcolo. L'entità del tempo inattivo dovuto alla mancata disponibilità della replica primaria dipende dal tipo di failover (pianificato o non pianificato), dall'eventuale configurazione della ridondanza della zona e dalla 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 presente, o crea una nuova replica primaria dal pool di capacità di calcolo disponibile. In quest'ultimo caso, la durata del tempo inattivo è maggiore a causa di passaggi aggiuntivi necessari per creare la nuova replica primaria.

È possibile scegliere una finestra di manutenzione che consente di rendere prevedibili e meno problematici gli eventi di manutenzione con impatto sul carico di lavoro.

Per il contratto di servizio Hyperscale, vedi Contratto di servizio per database SQL di Azure.

Pool di buffer, estensione del pool di buffer resiliente e priming continuo

In Hyperscale di Database di Azure esiste una separazione distinta tra calcolo e archiviazione. L'archiviazione contiene tutte le pagine del database in un database e può essere allocata su più computer man mano che aumenta il database. Il nodo di calcolo, tuttavia, memorizza nella cache solo gli elementi usati di recente. Le pagine più calde nel calcolo vengono mantenute in memoria in una struttura denominata pool di buffer (BP). Viene archiviato anche nell'unità SSD locale, l'estensione del pool di buffer resiliente (RBPEX), in modo che i dati possano essere recuperati più velocemente nel caso in cui il processo di calcolo venga riavviato.

In un sistema cloud, il calcolo può passare a computer diversi in base alle esigenze. Il livello di calcolo può avere più repliche. Uno è primario e riceve tutti gli aggiornamenti, mentre altri sono repliche secondarie. In caso di errore primario, una delle repliche secondarie a disponibilità elevata può essere rapidamente promossa a primaria in un processo denominato failover. La replica secondaria potrebbe non avere una cache nel relativo BP e RBPEX ottimizzata per il carico di lavoro primario.

Il priming continuo è un processo che raccoglie informazioni sulle pagine più interessanti in tutte le repliche di calcolo. Tali informazioni vengono aggregate e le repliche secondarie a disponibilità elevata usano l'elenco di pagine più calde che corrispondono al carico di lavoro tipico del cliente. In questo modo vengono riempiti sia bp che RBPEX con le pagine più calde, in modo continuo, per tenere il passo con le modifiche nel carico di lavoro del cliente.

Senza priming continuo, sia BP che RBPEX non vengono ereditati da nuove repliche a disponibilità elevata e vengono ricostruite solo durante il carico di lavoro dell'utente. Il priming continuo consente di risparmiare tempo e impedisce prestazioni incoerenti, poiché non vi è alcuna attesa prima che le cache vengano nuovamente completamente idratate. Con il priming continuo, le nuove repliche secondarie a disponibilità elevata inizieranno immediatamente a eseguire il priming di BP e RBPEX. Ciò consentirà di mantenere le prestazioni in modo più coerente man mano che si verificano i failover.

Il priming continuo funziona in entrambi i modi: le repliche secondarie a disponibilità elevata memorizzano nella cache le pagine usate nella replica primaria e la replica primaria memorizza nella cache le pagine con il carico di lavoro dalle repliche secondarie.

Nota

Il priming continuo è attualmente in un'anteprima controllata e non è disponibile per i database serverless. Per altre informazioni e per acconsentire esplicitamente al priming continuo, vedere blog: miglioramenti di Hyperscale di novembre 2024.

Backup e ripristino

Le operazioni di backup e ripristino per i database Hyperscale sono basate su snapshot di file. In questo modo, queste operazioni possono essere quasi istantanee. Poiché l'architettura Hyperscale usa il livello di archiviazione per backup e ripristino, il carico di elaborazione e l'impatto sulle prestazioni per le repliche di calcolo sono ridotti. Ulteriori informazioni sono disponibili in Backup Hyperscale e ridondanza dell'archiviazione.

Ripristino di emergenza per i database Hyperscale

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

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

Confrontare i limiti delle risorse

I livelli di servizio basati su vCore si distinguono per tipo di disponibilità e di archiviazione, prestazioni e dimensioni di archiviazione massime. Le differenze sono descritte nella tabella seguente:

ㅤ Utilizzo generico Business Critical Hyperscale
Ideale per Offre opzioni di calcolo e archiviazione bilanciate a prezzi convenienti. Applicazioni OLTP con frequenza di transazioni elevata e bassi livelli di latenza di I/O. Offre grande resilienza agli errori e failover rapidi tramite più repliche hot standby. La più ampia gamma di carichi di lavoro. Ridimensionamento automatico delle dimensioni di archiviazione fino a 128 TB, scalabilità verticale veloce e orizzontale del calcolo, ripristino rapido del database.
Dimensioni di calcolo Da 2 a 128 vCore Da 2 a 128 vCore Da 2 a 128 vCore
Tipo di archiviazione Archiviazione remota Premium (per istanza) Archiviazione SSD locale estremamente veloce (per istanza) Archiviazione disaccoppiata con cache SSD locale (per replica di calcolo)
Dimensioni archiviazione Da 1 GB a 4 TB Da 1 GB a 4 TB 10 GB - 128 TB
IOPS 320 operazioni di I/O al secondo per vCore fino a un massimo di 16.000 4.000 operazioni di I/O al secondo per vCore fino a un massimo di 327.680 327.680 operazioni di I/O al secondo con SSD locale massimo
Hyperscale è un'architettura multilivello con memorizzazione nella cache a più livelli. Le operazioni di I/O al secondo effettive dipendono dal carico di lavoro.
Memoria e vCore 5,1 GB 5,1 GB 5.1 GB o 10.2 GB
Disponibilità Una replica, nessuna per scalabilità in lettura, disponibilità elevata con ridondanza della zona Tre repliche, una per scalabilità in lettura, disponibilità elevata con ridondanza della zona Più repliche, fino a quattro con scalabilità in lettura, disponibilità elevata con ridondanza della zona
Backup Scelta tra archiviazione con ridondanza locale (LRS), con ridondanza della zona (ZRS) o con ridondanza geografica (GRS)
Conservazione di 1-35 giorni (sette giorni per impostazione predefinita), con un massimo di 10 anni di conservazione a lungo termine disponibile		 Scelta tra archiviazione con ridondanza locale (LRS), con ridondanza della zona (ZRS) o con ridondanza geografica (GRS)
Conservazione di 1-35 giorni (sette giorni per impostazione predefinita), con un massimo di 10 anni di conservazione a lungo termine disponibile		 Scelta tra archiviazione con ridondanza locale (LRS), con ridondanza della zona (ZRS) o con ridondanza geografica (GRS)
Conservazione di 1-35 giorni (sette giorni per impostazione predefinita), con un massimo di 10 anni di conservazione a lungo termine disponibile
Prezzi e fatturazione Vengono addebitati i costi per vCore, spazio di archiviazione e archivio di backup.
Le operazioni di I/O al secondo non vengono addebitate.		 Vengono addebitati i costi per vCore, spazio di archiviazione e archivio di backup.
Le operazioni di I/O al secondo non vengono addebitate.		 Vengono addebitati i costi vCore per ogni replica, archiviazione dei dati assegnata e archivio di backup.
Le operazioni di I/O al secondo non vengono addebitate.
Modelli di sconto1 Istanze riservate
Vantaggio Azure Hybrid2
Sottoscrizioni di sviluppo/test enterprise e offerte Sviluppo/test con pagamento in base al consumo		 Istanze riservate
Vantaggio Azure Hybrid2
Sottoscrizioni di sviluppo/test enterprise e offerte Sviluppo/test con pagamento in base al consumo		 Istanze riservate
Vantaggio Azure Hybrid2
Sottoscrizioni di sviluppo/test enterprise e offerte Sviluppo/test con pagamento in base al consumo

1 A dicembre 2023 sono arrivati i prezzi semplificati per Hyperscale di database SQL. Per informazioni dettagliate, vedere il blog sui prezzi di Hyperscale.

2 A partire da dicembre 2023, il vantaggio Azure Hybrid non è disponibile per i nuovi database Hyperscale o nelle sottoscrizioni di sviluppo/test. I database singoli Hyperscale esistenti con calcolo con provisioning possono continuare a usare Vantaggio Azure Hybrid per risparmiare sui costi di calcolo fino a dicembre 2026. Per ulteriori informazioni, vedi il blog sui prezzi di Hyperscale.

Risorse di calcolo

Configurazione hardware CPU Memoria
Serie standard (Gen5) Calcolo con provisioning
- Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, processori AMD EPYC 7763v (Milan)
- Provisioning di un massimo di 80 vCore (con hyperthreading)

Calcolo serverless
- Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, processori AMD EPYC 7763v (Milan)
- Scalabilità automatica fino a 80 vCore (con hyperthreading)
- Il rapporto da memoria a vCore si adatta dinamicamente all'utilizzo della memoria e della CPU in base alla domanda del carico di lavoro e può essere pari a 24 GB per vCore. Ad esempio, in un determinato momento, un carico di lavoro può usare ed essere fatturato per 240 GB di memoria e solo 10 vCore.		 Calcolo con provisioning
- 5,1 GB per vCore
- Provisioning di un massimo di 625 GB

Calcolo serverless
- Scalabilità automatica fino a 24 GB per vCore
- Scalabilità automatica fino a 240 GB
Serie Premium - Processori Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan)
- Provisioning di un massimo di 128 vCore (con hyperthreading)		 - 5,1 GB per vCore
Serie Premium ottimizzata per la memoria - Processori Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan)
- Provisioning di un massimo di 80 vCore (con hyperthreading)		 - 10,2 GB per vCore

1 Nella DMV sys.dm_user_db_resource_governance , la generazione hardware per i database che usano processori Intel® SP-8160 (Skylake) viene visualizzata come Gen6, la generazione hardware per i database che usano Intel® 8272CL (Cascade Lake) viene visualizzata come Gen7 e la generazione hardware per i database che usano Intel® Xeon® Platinum 8370C (Ice Lake) o AMD® EPYC® 7763v (Milano) viene visualizzata come Gen8. Per una determinata configurazione hardware e determinate dimensioni di calcolo, i limiti delle risorse sono uguali indipendentemente dal tipo di CPU. Per ulteriori informazioni, vedere i limiti delle risorse per database singoli e pool elastici.

Serverless è supportato solo nell'hardware della serie Standard (Gen5).

Creare e gestire database Hyperscale

È possibile creare e gestire database Hyperscale con il portale di Azure, Transact-SQL, PowerShell e l'interfaccia della riga di comando di Azure. Per ulteriori informazioni, vedi Guida introduttiva: Creare un database Hyperscale.

Operazione Dettagli Ulteriori informazioni
Creare un database Hyperscale I database Hyperscale sono disponibili solo con il modello di acquisto basato su vCore. Trova esempi per creare un database Hyperscale in Guida introduttiva: Creare un database Hyperscale in database SQL di Azure.
Aggiornare un database esistente a Hyperscale La migrazione di un database esistente in database SQL di Azure al livello Hyperscale è una dimensione delle operazioni dei dati. Informazioni su come eseguire la migrazione di un database esistente a Hyperscale.
Invertire la migrazione di un database Hyperscale al livello di servizio Per utilizzo generico Se in precedenza è stata eseguita la migrazione di un database SQL di Azure 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, bisogna prima invertire la migrazione al livello di servizioPper utilizzo generico e poi modificare il livello di servizio.		 Informazioni su come invertire la migrazione da Hyperscale e limitazioni per l'inversione della migrazione.

Compatta

Le operazioni di compattazione di database e file sono attualmente in anteprima per database SQL di Azure Hyperscale. Per altre informazioni sull’anteprima, vedere Compattazione per Database SQL di Azure Hyperscale.

Limitazioni note

Queste sono le limitazioni correnti del livello di servizio Hyperscale. Stiamo lavorando attivamente per rimuovere il maggior numero possibile di queste limitazioni.

Problema Descrizione
La compattazione viene bloccata quando TDE è disabilitato Attualmente, le operazioni di compattazione di database e file non sono supportate quando Transparent Data Encryption (TDE) è disabilitato in database SQL di Azure Hyperscale.
Ripristinare il database da altri livelli di servizio Non è possibile ripristinare un database non Hyperscale come database Hyperscale né un database Hyperscale come database non Hyperscale.

Per i database migrati a Hyperscale da altri livelli di servizio database SQL di Azure, 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 dei backup del database è supportato tramite la riga di comando. È possibile ripristinare questi backup in qualsiasi livello di servizio non Hyperscale.
Migrazione di database con oggetti OLTP in memoria Hyperscale supporta un sottoinsieme di oggetti OLTP in memoria, inclusi i tipi di tabella ottimizzata per la memoria, le variabili di tabella e i moduli compilati in modo nativo. Tuttavia, quando tutti gli oggetti OLTP in memoria sono presenti nel database di cui viene eseguita la migrazione, la migrazione dai 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 memoria 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 in tabelle del disco.
Controllo integrità del database DBCC CHECKDB non è attualmente supportato per i database Hyperscale. È possibile usare DBCC CHECKTABLE ('TableName') WITH TABLOCK e DBCC CHECKFILEGROUP WITH TABLOCK come soluzione alternativa. Per ulteriori informazioni sulla gestione dell'integrità dei dati nel database SQL di Azure, vedi Data Integrity in Azure SQL Database (Integrità dei dati nel database SQL di Azure).
Processi elastici L'uso di un database Hyperscale come database di lavoro non è supportato. Tuttavia, i lavori elastici possono avere come destinazione i database Hyperscale come qualsiasi altro database SQL di Azure.
Sincronizzazione dei dati L'uso di un database Hyperscale come database dei metadati di sincronizzazione o dell'hub non è supportato. Tuttavia, un database Hyperscale può essere un database membro in una topologia di sincronizzazione dati.
Hardware della serie Premium del livello di servizio Hyperscale L'hardware della serie Premium e della serie Premium ottimizzata per la memoria attualmente non supporta il livello di elaborazione serverless.
Disponibilità a livello di area L'hardware ottimizzato per la memoria e la serie Premium del livello di servizio Hyperscale sono disponibili in aree di Azure limitate. Per un elenco, vedi Disponibilità della serie Premium Hyperscale.

Contenuto correlato