Architettura delle funzioni distribuite Hyperscale

  • Articolo

Si applica a:Database SQL di Azure

Il livello di servizio Hyperscale usa un'architettura con livelli di archiviazione e calcolo separati e altamente scalabili. Questo articolo descrive i componenti che consentono di dimensionare rapidamente i database Hyperscale sfruttando al contempo l'immediatezza dei backup e una registrazione delle transazioni altamente scalabile.

Suggerimento

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

Panoramica dell'architettura Hyperscale

I motori di database tradizionali centralizzano le funzioni di gestione dei dati in un unico processo: anche i cosiddetti database distribuiti attualmente disponibili hanno più copie di un motore di dati monolitico.

I database Hyperscale seguono una logica differente. Hyperscale separa il motore di elaborazione delle query, in cui la semantica dei vari motori di dati diverge, dai componenti che forniscono l'archiviazione e la durabilità a lungo termine dei dati. In questo modo la capacità di archiviazione può essere facilmente aumentata in base alle esigenze. Il limite di archiviazione supportato inizialmente è 100 TB.

Tutte le comunicazioni di rete tra i componenti Hyperscale usano l'infrastruttura di rete di Azure con ridondanza predefinita.

Le repliche secondarie a disponibilità elevata e le repliche denominate sono nodi di calcolo facoltativi che possono essere aggiunti su richiesta. Entrambi condividono gli stessi componenti di archiviazione, quindi non è necessaria alcuna copia dei dati per avviare una nuova replica. Su richiesta, è possibile aggiungere una replica geografica secondaria nella stessa area di Azure o in una diversa. Per la protezione dei dati e la ridondanza, le repliche geografiche secondarie hanno componenti di archiviazione separati da quelli usati dalla replica primaria.

Il diagramma seguente illustra l'architettura funzionale di Hyperscale:

Diagram showing Hyperscale's compute tier.

Un database Hyperscale contiene i tipi di componenti seguenti: nodi di calcolo, server di pagina, servizio di log e archiviazione di Azure.

Calcolo

Il nodo di calcolo è dove si trova il motore relazionale e dove si verifica l'elaborazione di tutti i linguaggi, le query e le transazioni. Tutte le interazioni dell'utente con un database Hyperscale vengono eseguite tramite nodi di calcolo. I nodi di calcolo possono essere configurati per l'uso del calcolo serverless o con provisioning.

I nodi di calcolo hanno cache locali basate su unità SSD denominate estensione resiliente del pool di buffer (cache di dati RBPEX). La cache di dati RBPEX è una cache di dati intelligente a bassa latenza che riduce al minimo la necessità di recuperare i dati dai server di pagine remoti.

I database Hyperscale hanno un nodo di calcolo primario in cui vengono elaborati i carichi di lavoro di lettura/scrittura e le transazioni. È possibile aggiungere su richiesta fino a quattro nodi di calcolo secondari a disponibilità elevata, che fungono da nodi hot standby a scopo di failover e possono servire da nodi di calcolo di sola lettura per eseguire l'offload dei carichi di lavoro di lettura al bisogno. Le repliche denominate sono nodi di calcolo secondari progettati per abilitare diversi scenari aggiuntivi con scalabilità in lettura OLTP e per supportare al meglio i carichi di lavoro di elaborazione transazionale ibrida e analitica (HTAP). È possibile aggiungere un nodo di calcolo secondario geografico a scopo di ripristino di emergenza e con funzione di sola lettura per eseguire l'offload dei carichi di lavoro di lettura in un'area di Azure diversa.

In modalità serverless, si verifica la scalabilità automatica indipendente della replica primaria e di tutte le repliche a disponibilità elevata o denominate in base all'utilizzo. Gli intervalli di scalabilità automatica di calcolo per la replica primaria e le repliche denominate vengono configurati in maniera indipendente. L'intervallo di scalabilità automatica di tutte le repliche a disponibilità elevata viene ereditato dalla configurazione di scalabilità automatica specificata dalla replica primaria o denominata associata.

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

Server di pagina

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 e ha anche una replica mantenuta per ragioni di ridondanza e 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 pagina vengono tenuti aggiornati riproducendo i record di log dal servizio di log.

I server di pagina gestiscono anche le cache basate su unità SSD per migliorare le prestazioni. L'archiviazione a lungo termine delle pagine di dati viene mantenuta in Archiviazione di Azure per garantire durabilità.

Servizio di log

Il servizio di log accetta i record del log delle transazioni che corrispondono alle modifiche dei dati dalla replica di calcolo primaria. I server di pagina ricevono quindi i record di log dal servizio di log e applicano le modifiche alle rispettive sezioni di dati. Inoltre, le repliche di calcolo secondarie ricevono record di log dal servizio di log e riproducono solo le modifiche alle pagine già presenti nel pool di buffer o nella cache RBPEX locale. Tutte le modifiche ai dati dalla replica di calcolo primaria vengono propagate tramite il servizio di registrazione a tutte le repliche di calcolo secondarie e a tutti i server di pagine.

Infine, i record dei log delle transazioni vengono inviati all'archiviazione a lungo termine in Archiviazione di Azure, ovvero un repository di archiviazione infinito. Questo meccanismo elimina la necessità di troncamento frequente dei log. I motivi comunemente associati alla crescita dei log, ad esempio i backup del log non riusciti o la replica lenta dei dati nelle repliche secondarie, non si applicano a Hyperscale. Il servizio di log dispone di cache di memoria e SSD locali per velocizzare l'accesso ai record di log.

Archiviazione di Azure

Archiviazione di Azure contiene tutti i file di dati di un database. I server di pagina mantengono aggiornati i file di dati in Archiviazione di Azure. Questa risorsa di archiviazione viene usata anche a scopo di backup e può essere replicata tra le diverse aree in base alla scelta della ridondanza di archiviazione.

I backup vengono implementati usando gli snapshot di archiviazione dei file di dati. Le operazioni di ripristino che usano gli snapshot sono rapide a prescindere dalle dimensioni dei dati. Un database può essere ripristinato a qualsiasi punto nel tempo entro il periodo di conservazione del backup.

Hyperscale supporta la configurazione della ridondanza di archiviazione. Quando si crea un database Hyperscale, è possibile scegliere tra i tipi di archiviazione standard di Azure seguenti:

  • Archiviazione con ridondanza locale (LRS)
  • Archiviazione con ridondanza della zona (ZRS)
  • Archiviazione con ridondanza geografica e accesso in lettura (RA-GRS)
  • Archiviazione con ridondanza geografica della zona e accesso in lettura (RA-GZRS)

Le opzioni di archiviazione con ridondanza della zona sono disponibili nelle aree di Azure con zone di disponibilità.

L'opzione di ridondanza di archiviazione selezionata è usata per tutta la durata del database, sia per la ridondanza di archiviazione dei dati che per la ridondanza dell'archivio di backup.

Contenuto correlato