Livello di servizio Hyperscale

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 rettificata per l'ambiente cloud per garantire la disponibilità del 99,99% anche in caso 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 altamente scalabile per le prestazioni di archiviazione e calcolo, e sfrutta l'architettura di Azure per scalare orizzontalmente le risorse di archiviazione e di calcolo per un database SQL di Azure sostanzialmente oltre i limiti disponibili per i livelli di utilizzo generico e business critical.

Nota

  • Per informazioni dettagliate sui livelli per utilizzo generico e business critical nel modello di acquisto basato su vCore, vedere livelli di servizio per utilizzo generico e business critical di servizio. Per un confronto tra il modello di acquisto basato su vCore e quello basato su DTU, vedere Modelli di acquisto e risorse del database SQL di Azure.
  • Il livello di servizio Hyperscale è attualmente disponibile solo per database SQL di Azure e non per Azure SQL Istanza gestita.

Funzionalità del livello di servizio Hyperscale

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

  • Supporto per database di dimensioni massime di 100 TB
  • Backup di database quasi istantanei (basati su 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 è un'operazione di dimensionamento dei dati)
  • Prestazioni complessive più elevate grazie alla maggiore velocità effettiva dei log e ai tempi di esecuzione di commit delle transazioni più veloci, indipendentemente dai volumi di dati
  • Scalabilità orizzontale 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
  • Scalabilità verticale rapida: è possibile aumentare le risorse di calcolo in tempo costante per supportare carichi di lavoro pesanti quando necessario e quindi ridimensionare le risorse di calcolo 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. In realtà, i database Hyperscale non vengono creati con una dimensione massima definita. Un database Hyperscale aumenta in base alle esigenze e viene addebitata solo la capacità in uso. Per i carichi di lavoro a elevato utilizzo di lettura, il livello di servizio Hyperscale offre scalabilità orizzontale rapida tramite 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 alla maggior parte dei carichi di lavoro aziendali perché offre flessibilità e prestazioni elevate con risorse di calcolo e archiviazione scalabili in modo indipendente. Con la possibilità di ridimensionare automaticamente l'archiviazione fino a 100 TB, è un'ottima scelta per i clienti che:

  • Avere database di grandi dimensioni in locale e voler modernizzare le applicazioni passando al cloud
  • Sono già nel cloud e sono limitate dalle restrizioni massime per le dimensioni del database di altri livelli di servizio (1-4 TB)
  • Avere database più piccoli, ma richiede scalabilità di calcolo verticale e orizzontale veloce, prestazioni elevate, backup istantaneo e ripristino rapido del database.

Il livello di servizio Hyperscale supporta un'ampia gamma di carichi di lavoro di SQL Server, da OLTP puro ad analisi pura, ma è ottimizzato principalmente per OLTP e carichi di lavoro Ibridi di elaborazione analitica e transazione (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 Vantaggio Azure Hybrid viene applicato automaticamente alle repliche con disponibilità elevata e denominate. Per impostazione predefinita, vengono create una replica primaria e una replica secondaria a disponibilità elevata per ogni database Hyperscale. Gli utenti possono modificare il numero totale di repliche a disponibilità elevata da 0 a 4, a seconda del contratto di servizio necessario.

  • Spazio di archiviazione:

    Non è necessario specificare le dimensioni massime dei dati durante la configurazione di un database Hyperscale. Nel livello di iperscalabilità viene addebitato lo spazio di archiviazione per il database in base all'allocazione effettiva. Archiviazione viene allocato automaticamente tra 40 GB e 100 TB, con incrementi di 10 GB. Se necessario, è possibile aumentare le dimensioni di più file di dati contemporaneamente. Un database Hyperscale viene creato con una dimensione iniziale di 10 GB e inizia a crescere di 10 GB ogni 10 minuti, fino a raggiungere le dimensioni di 40 GB.

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

Architettura con funzioni distribuite

A differenza dei motori di database tradizionali che centralizzano tutte le funzioni di gestione dati in un unico percorso o processo (perfino i cosiddetti database distribuiti per la produzione dispongono attualmente di più copie di un motore dati monolitico), un database Hyperscale separa il motore di elaborazione query, in cui far divergere la semantica dei vari motori di dati, dai componenti che offrono archiviazione a lungo termine e la durabilità dei dati. In questo modo, la capacità di archiviazione può essere facilmente aumentata secondo necessità (l'obiettivo iniziale è 100 TB). Le repliche denominate e a disponibilità elevata condividono gli stessi componenti di archiviazione, quindi non è necessaria alcuna copia dei dati per creare una nuova replica.

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

architettura

Un database Hyperscale contiene i diversi tipi di componenti seguenti:

Calcolo

Il nodo di calcolo è il punto in cui risiede il motore relazionale. Si tratta della posizione in cui si verifica l'elaborazione di linguaggio, query ed transazioni. Tutte le interazioni dell'utente con un database Hyperscale vengono eseguite tramite questi nodi di calcolo. I nodi di calcolo presentano cache basae su SSD (con etichetta RBPEX - estensione del pool di buffer resiliente nel diagramma precedente) per ridurre al minimo il numero di round trip di rete necessari per recuperare una pagina di dati. È presente un nodo di calcolo primario in cui vengono elaborati tutti i carichi di lavoro di lettura/scrittura e le transazioni. Sono presenti uno o più nodi di calcolo secondari che fungono da nodi di hot standby per finalità di failover, oltre a fungere da nodi di calcolo di sola lettura per l'offload di carichi di lavoro di lettura (se si desidera questa funzionalità).

Il motore di database in esecuzione nei nodi di calcolo Hyperscale è uguale a quello di altri database SQL di Azure di servizio. Quando gli utenti interagiscono con il motore di database nei nodi di calcolo Hyperscale, la superficie di attacco e il comportamento del motore supportati sono gli stessi di altri livelli di servizio, ad eccezione delle limitazioni note.

Server di pagine

I servers di pagina sono sistemi che rappresentano un motore di archiviazione con scalabilità orizzontale. Ogni server di pagina è responsabile di un subset delle pagine nel database. Nominalmente, ogni server di pagina controlla fino a 128 GB o fino a 1 TB di dati. Nessun dato viene condiviso in più di un server di pagina (all'esterno delle repliche del server di pagina mantenute per la ridondanza e la disponibilità). Il compito di un server di pagina consiste nel fornire su richiesta le pagine del database ai nodi di calcolo e nel mantenere le pagine aggiornate man mano che le transazioni aggiornano i dati. I server di pagine vengono mantenuti aggiornati riproducendo i record di log dal servizio di log. I server di pagine gestiscono anche cache basate su SSD per migliorare le prestazioni. L'archiviazione a lungo termine delle pagine di dati viene mantenuta in Archiviazione di Azure per garantire maggiore affidabilità.

Servizio di log

Il servizio di log accetta i record di log dalla replica di calcolo primaria, li rende persistenti in una cache durevole e inoltra i record di log al resto delle repliche di calcolo (in modo che possano aggiornare le cache) e ai server di pagina pertinenti, in modo che i dati possano essere aggiornati in tale replica. In questo modo, tutte le modifiche ai dati dalla replica di calcolo primaria vengono propagate tramite il servizio di log a tutte le repliche di calcolo secondarie e i server di pagine. Infine, i record di log vengono inviati all'archiviazione a lungo termine in Archiviazione di Azure, che è un repository di archiviazione praticamente infinito. Questo meccanismo elimina la necessità di un troncamento frequente del log. Il servizio di log dispone anche di memoria locale e cache SSD per velocizzare l'accesso ai record di log.

Archiviazione di Azure

Archiviazione di Azure contiene tutti i file di dati in un database. I server di pagine mantengono aggiornati Archiviazione di Azure dati. Questa archiviazione viene usata a scopo di backup e per la replica tra aree di Azure. I backup vengono implementati usando snapshot di archiviazione di file di dati. Le operazioni di ripristino che usano gli snapshot sono veloci indipendentemente dalle dimensioni dei dati. I dati possono essere ripristinati in qualsiasi momento all'interno del periodo di conservazione dei backup del database.

Backup e ripristino

I backup sono basati su snapshot di file e quindi sono quasi istantanei. Archiviazione separazione delle risorse di calcolo consente di eseguire il push dell'operazione di backup/ripristino al livello di archiviazione per ridurre il carico di elaborazione sulla replica di calcolo primaria. Di conseguenza, il backup del database non influisce sulle prestazioni del nodo di calcolo primario. Analogamente, il ripristino temporato viene eseguito ripristinando gli snapshot di file e di conseguenza non è una dimensione dell'operazione sui dati. Il ripristino di un database Hyperscale nella stessa area di Azure è un'operazione a tempo costante e anche i database di più terabyte possono essere ripristinati in minuti anziché in ore o giorni. La creazione di nuovi database tramite il ripristino di un backup esistente sfrutta anche questa funzionalità: la creazione di copie di database a scopo di sviluppo o test, anche di database multi-terabyte, è possibile in pochi minuti.

Per il ripristino geografico dei database Hyperscale, vedere Ripristino di un database Hyperscale in un'area diversa.

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 un database Hyperscale

È possibile creare un database Hyperscale usando il portale di Azure , T-SQL, PowerShello l'interfaccia della riga di comando. I database Hyperscale sono disponibili solo usando il modello di acquisto basato su vCore.

Il comando T-SQL seguente crea un database Hyperscale. Nell'istruzione CREATE DATABASE è necessario specificare sia l'edizione che l'obiettivo del servizio. Fare riferimento ai limiti delle risorse per un elenco di obiettivi di servizio validi.

-- Create a Hyperscale Database
CREATE DATABASE [HyperscaleDB1] (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_4');
GO

Verrà creato un database Hyperscale nell'hardware gen5 con quattro core.

Aggiornare il database esistente a Hyperscale

È possibile spostare i database esistenti in database SQL di Azure in Hyperscale usando il portale di Azure , T-SQL, PowerShello l'interfaccia della riga di comando. Al momento, si tratta di una migrazione unidirese. Non è possibile spostare i database da Hyperscale a un altro livello di servizio, a parte l'esportazione e l'importazione dei dati. Per i modello di verifica (POC), è consigliabile creare una copia dei database di produzione ed eseguire la migrazione della copia a Hyperscale. La migrazione di un database esistente in database SQL di Azure al livello Hyperscale è un'operazione di dimensioni dei dati.

Il comando T-SQL seguente sposta un database nel livello di servizio Hyperscale. Nell'istruzione ALTER DATABASE è necessario specificare sia l'edizione che l'obiettivo del servizio.

-- Alter a database to make it a Hyperscale Database
ALTER DATABASE [DB2] MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_4');
GO

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 di inattività dovuto alla non disponibilità della replica primaria dipende dal tipo di failover (pianificato o non pianificato) 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 o usa una replica a disponibilità elevata esistente come destinazione del 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, oppure crea una nuova replica primaria dal pool di capacità di calcolo disponibile. Nel secondo caso, la durata del tempo di inattività è più lunga a causa dei passaggi aggiuntivi necessari per creare la nuova replica primaria.

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

Ripristino di emergenza per i database Hyperscale

Ripristino di un database Hyperscale in un'area diversa

Se è necessario ripristinare un database Hyperscale in database SQL di Azure in un'area diversa da quella in cui è attualmente ospitato, come parte di un'operazione di ripristino di emergenza o di un'esercitazione, una rilocazione o qualsiasi altro motivo, il metodo principale è eseguire un ripristino geografico del database. Ciò comporta esattamente gli stessi passaggi di quello che si userebbe per ripristinare qualsiasi altro database in database SQL in un'area diversa:

  1. Creare un server nell'area di destinazione se non è già presente un server appropriato. Questo server deve essere di proprietà della stessa sottoscrizione del server originale (di origine).
  2. Seguire le istruzioni nell'argomento relativo al ripristino geografico della pagina sul ripristino di un database in database SQL di Azure backup automatici.

Nota

Poiché l'origine e la destinazione sono in aree separate, il database non può condividere l'archiviazione snapshot con il database di origine come nei ripristini non geografici, che vengono completati rapidamente indipendentemente dalle dimensioni del database. Nel caso di un ripristino geografico di un database Hyperscale, si tratta di un'operazione di dimensione dei dati, anche se la destinazione si trova nell'area abbinata dell'archiviazione con replica geografica. Pertanto, un ripristino geografico richiederà tempo proporzionalmente alle dimensioni del database da ripristinare. Se la destinazione si trova nell'area abbinata, il trasferimento dei dati sarà all'interno di un'area, che sarà notevolmente più veloce di un trasferimento di dati tra aree, ma sarà comunque un'operazione di dimensione dei dati.

Aree disponibili

Il database SQL di Azure Hyperscale è disponibile in tutte le aree, ma è abilitato per impostazione predefinita nelle aree seguenti elencate di seguito. Se si vuole creare un database Hyperscale in un'area in cui Hyperscale non è abilitato per impostazione predefinita, è possibile inviare una richiesta di onboarding tramite portale di Azure. Per istruzioni, vedere Richiedere aumenti della quota database SQL di Azure per istruzioni. Quando si invia la richiesta, usare le linee guida seguenti:

  • Usare il tipo di quota Database SQL area.
  • Nella descrizione aggiungere lo SKU di calcolo/core totali, incluse le repliche denominate e a disponibilità elevata, e indicare che si sta richiedendo capacità Hyperscale.
  • Specificare anche una proiezione delle dimensioni totali di tutti i database nel tempo, in TB.

Aree abilitate:

  • Australia orientale
  • Australia sud-orientale
  • Australia centrale
  • Brasile meridionale
  • Canada centrale
  • Canada orientale
  • Stati Uniti centrali
  • Cina orientale 2
  • Cina settentrionale 2
  • Asia orientale
  • Stati Uniti orientali
  • Stati Uniti orientali 2
  • Francia centrale
  • Germania centro-occidentale
  • Giappone orientale
  • Giappone occidentale
  • Corea centrale
  • Corea meridionale
  • Stati Uniti centro-settentrionali
  • Europa settentrionale
  • Norvegia orientale
  • Norvegia occidentale
  • Sudafrica settentrionale
  • Stati Uniti centro-meridionali
  • Asia sud-orientale
  • Svizzera occidentale
  • Regno Unito meridionale
  • Regno Unito occidentale
  • US DoD (area centrale)
  • US DoD (area orientale)
  • Us Govt Arizona
  • US Govt Texas
  • Stati Uniti centro-occidentali
  • Europa occidentale
  • Stati Uniti occidentali
  • Stati Uniti occidentali 2

Limitazioni note

Queste sono le limitazioni correnti per il livello di servizio Hyperscale a livello di ga. Microsoft sta lavorando attivamente per rimuovere il maggior numero possibile di queste limitazioni.

Problema Descrizione
Il riquadro Gestisci backup per un server non mostra i database Hyperscale. Questi verranno filtrati dalla visualizzazione. Hyperscale ha un metodo separato per la gestione dei backup, quindi le impostazioni di conservazione Long-Term e conservazione dei backup temporizzazione non sono applicabili. Di conseguenza, i database Hyperscale non vengono visualizzati nel riquadro Gestisci backup.

Per i database migrati a Hyperscale da altri livelli di servizio database SQL di Azure, i backup pre-migrazione vengono conservati per la durata del periodo di conservazione dei backup del database di origine. Questi backup possono essere usati per ripristinare il database di origine a un momento precedente alla migrazione.
Ripristino temporizzato Un database non Hyperscale non può essere ripristinato come database Hyperscale e un database Hyperscale non può essere ripristinato come database non Hyperscale. Per un database non Hyperscale di cui è stata eseguita la migrazione a Hyperscale modificandone il livello di servizio, il ripristino a un punto nel tempo precedente alla migrazione e all'interno del periodo di conservazione dei backup del database è supportato a livello di codice. Il database ripristinato non sarà Hyperscale.
Quando si modifica database SQL di Azure livello di servizio in Hyperscale, l'operazione ha esito negativo se il database contiene file di dati di dimensioni superiori a 1 TB In alcuni casi, è possibile risolvere questo problema compattando i file di grandi dimensioni in modo che siano inferiori a 1 TB prima di provare a modificare il livello di servizio in Hyperscale. Utilizzare la query seguente per determinare le dimensioni correnti dei file di database. SELECT file_id, name AS file_name, size * 8. / 1024 / 1024 AS file_size_GB FROM sys.database_files WHERE type_desc = 'ROWS';
Istanza gestita di SQL Azure SQL Istanza gestita non è attualmente supportato con i database Hyperscale.
Pool elastici I pool elastici non sono attualmente supportati con Hyperscale.
La migrazione al livello di servizio Hyperscale è attualmente un'operazione unidirezionale Dopo aver eseguito la migrazione di un database a Hyperscale, non è possibile eseguirne direttamente la migrazione a un livello di servizio non Hyperscale. Attualmente, l'unico modo per eseguire la migrazione di un database da Hyperscale a non Hyperscale è esportare/importare usando un file bacpac o altre tecnologie di spostamento dei dati (copia bulk, Azure Data Factory, Azure Databricks, SSIS e così via). L'esportazione/importazione Bacpac da portale di Azure, da PowerShell con New-AzSqlDatabaseExport o New-AzSqlDatabaseImport, dall'interfaccia della riga di comando di Azure con az sql db export e az sql db importe dall'API REST non è supportata. L'importazione/esportazione Bacpac per database Hyperscale più piccoli (fino a 200 GB) è supportata con SSMS e SqlPackage versione 18.4 e successive. Per i database di dimensioni maggiori, l'esportazione/importazione bacpac può richiedere molto tempo e potrebbe non riuscire per vari motivi.
Migrazione di database con In-Memory OLTP Hyperscale supporta un subset di In-Memory oggetti OLTP, inclusi tipi di tabella ottimizzati per la memoria, variabili di tabella e moduli compilati in modo nativo. Tuttavia, quando qualsiasi tipo di In-Memory oggetti OLTP è presente 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 un database di questo tipo a Hyperscale, è necessario eliminare In-Memory oggetti OLTP e le relative dipendenze. Dopo la migrazione del database, questi oggetti possono essere ricreati. Le tabelle durevoli e non durevoli ottimizzate per la memoria non sono attualmente supportate in Hyperscale e devono essere modificate in tabelle su disco.
Replica geografica La replica geografica su Hyperscale è ora disponibile in anteprima pubblica.
Copia del database La copia del database in Hyperscale è ora disponibile in anteprima pubblica.
Funzionalità del database intelligente Ad eccezione dell'opzione "Force Plan", tutte le altre opzioni di ottimizzazione automatica non sono ancora supportate in Hyperscale: le opzioni possono sembrare abilitate, ma non verranno eseguite raccomandazioni o azioni.
Analisi delle prestazioni della query Le prestazioni Insights query non sono attualmente supportate per i database Hyperscale.
Compatta database DBCC SHRINKDATABASE o DBCC SHRINKFILE non è attualmente supportato per i database Hyperscale.
Controllo dell'integrità del database DBCC CHECKDB non è attualmente supportato per i database Hyperscale. È possibile usare DBCC CHECKFILEGROUP e DBCC CHECKTABLE come soluzione alternativa. Vedere Integrità dei dati in database SQL di Azure per informazioni dettagliate sulla gestione dell'integrità dei dati in database SQL di Azure.

Passaggi successivi