Illustrare le opzioni PaaS per la distribuzione di SQL Server in Azure
La piattaforma distribuita come servizio (PaaS) fornisce un ambiente di sviluppo e distribuzione completo nel cloud, utilizzabile per semplici applicazioni basate sul cloud, nonché per applicazioni aziendali avanzate.
Il database SQL di Azure e Istanza gestita di SQL di Azure sono parte dell'offerta PaaS per Azure SQL.
Database SQL di Azure: parte di una famiglia di prodotti basata sul motore di SQL Server, nel cloud. Offre agli sviluppatori una grande flessibilità nella creazione di nuovi servizi dell'applicazione e opzioni di distribuzione granulari su larga scala. Il database SQL offre una soluzione di manutenzione ridotta che può essere un'ottima opzione per determinati carichi di lavoro.
Istanza gestita di SQL di Azure: è consigliabile per la maggior parte degli scenari di migrazione nel cloud perché offre servizi e funzionalità completamente gestiti.
Come illustrato nell'immagine precedente, ogni offerta fornisce un determinato livello di amministrazione dell'infrastruttura, in base al grado di efficienza dei costi.
Modelli di distribuzione
Il database SQL di Azure è disponibile in due diversi modelli di distribuzione:
Database singolo, ovvero un database singolo fatturato e gestito a livello di database. Ognuno dei database viene gestito singolarmente dal punto di vista della scalabilità e della dimensione dei dati. Tutti i database presenti in questo modello hanno risorse dedicate, anche se distribuite nello stesso server logico.
Pool elastici: un gruppo di database gestiti insieme che condividono un insieme comune di risorse. I pool elastici offrono una soluzione economicamente vantaggiosa per il modello applicativo di software come un servizio, poiché le risorse vengono condivise tra tutti i database. È possibile configurare le risorse in base al modello di acquisto basato su DTU o al modello di acquisto basato su vCore.
Modello di acquisto
In Azure tutti i servizi sono supportati da hardware fisico ed è possibile scegliere due modelli di acquisto diversi:
Unità di transazione di database (DTU)
Le DTU vengono calcolate in base a una formula che combina risorse di calcolo, archiviazione e I/O. È una scelta ottimale per i clienti che desiderano opzioni di risorse semplici e preconfigurate.
Il modello di acquisto DTU è disponibile in diversi livelli di servizio, ad esempio Basic, Standard e Premium. Ogni livello ha funzionalità variabili, che offrono un'ampia gamma di opzioni quando si sceglie questa piattaforma.
In termini di prestazioni, il livello Basic viene usato per carichi di lavoro meno impegnativi, mentre il livello Premium viene usato per i requisiti di carico di lavoro intensivi.
Le risorse di calcolo e di archiviazione dipendono dal livello di DTU e offrono una gamma di funzionalità per le prestazioni in base a un limite di archiviazione fisso, all'intervallo di conservazione dei backup e al costo.
Nota
Il modello di acquisto DTU è supportato solo dal database SQL di Azure.
Per altre informazioni sul modello di acquisto DTU, vedere Panoramica del modello di acquisto basato su DTU.
vCore
Il modello vCore consente di acquistare un numero specificato di vCore in base ai carichi di lavoro specificati. vCore è il modello di acquisto predefinito quando si acquistano risorse del database SQL di Azure. i database vCore hanno una relazione specifica tra il numero di core e la quantità di memoria e di archiviazione fornita al database. Il modello di acquisto vCore è supportato sia dal database SQL di Azure sia da Istanza gestita di SQL di Azure.
È possibile acquistare database vCore anche in tre livelli di servizio diversi:
Utilizzo generico: livello per i carichi di lavoro di utilizzo generico. È supportato dall’archiviazione Premium di Azure. La latenza rispetto a Business Critical è maggiore. Fornisce anche i livelli di calcolo seguenti:
- Con provisioning: le risorse di calcolo sono pre-allocate. Fatturazione oraria in base ai vCore configurati.
- Serverless: le risorse di calcolo sono dimensionate in modo automatico. Fatturazione al secondo in base ai vCore usati.
Business Critical: questo livello si applica ai carichi di lavoro ad alte prestazioni che offrono la latenza minore di uno dei livelli di servizio. Questo livello è supportato da unità SSD locali invece che dall'archiviazione BLOB di Azure. Offre inoltre la massima resilienza agli errori oltre a una replica di database di sola lettura incorporata che può essere usata per caricare i carichi di lavoro di reporting.
Hyperscale: i database con iperscalabilità sono dimensionabili oltre il limite di 4 TB per le altre offerte del database SQL di Azure e hanno un'architettura univoca che supporta database fino a 100 TB.
Senza server
Il nome "serverless" può provocare confusione quando si distribuisce il database SQL di Azure in un server logico a cui ci si connette. Il database SQL di Azure serverless è un livello di calcolo che dimensiona automaticamente le risorse per un database specifico in base alla richiesta del carico di lavoro. Se per il carico di lavoro le risorse di calcolo non sono più necessarie, il database viene "sospeso" e non verrà addebitato alcun costo nel periodo di tempo in cui il database è inattivo. Quando viene effettuato un tentativo di connessione, il database verrà ripreso e reso disponibile.
L'impostazione per il controllo della sospensione è detta ritardo di sospensione automatica e ha un valore minimo di 60 minuti e un valore massimo di sette giorni. Se il database è rimasto inattivo per il periodo di tempo specificato, verrà sospeso.
Una volta che il database è rimasto inattivo per il periodo di tempo specificato, verrà sospeso fino a quando non viene tentata una connessione successiva. La configurazione di un intervallo di scalabilità automatica di calcolo e un ritardo di sospensione automatica influiscono sulle prestazioni e sui costi correlati al calcolo del database.
Tutte le applicazioni che utilizzano l’opzione serverless devono essere configurate per gestire gli errori di connessione e includere la logica di ripetizione dei tentativi, perché la connessione a un database sospeso genererà un errore di connessione.
Un'altra differenza tra l’opzione serverless e il normale modello vCore del database SQL di Azure consiste nel fatto che con l’opzione serverless è possibile specificare un numero minimo e massimo di vCore. I limiti di memoria e I/O sono proporzionali all'intervallo specificato.
L'immagine precedente mostra la schermata di configurazione per un database serverless nel portale di Azure. È possibile selezionare un valore minimo fino alla metà di un vCore e a un massimo di 16 vCore.
Il livello serverless non è completamente compatibile con tutte le funzionalità del database SQL di Azure perché alcune richiedono l'esecuzione di processi in background in qualsiasi momento, ad esempio:
- Replica geografica
- Conservazione del backup a lungo termine
- Un database dei processi in processi elastici
- Il database di sincronizzazione in sincronizzazione dati SQL (la sincronizzazione dati è un servizio che replica i dati tra un gruppo di database)
Nota
Il database SQL serverless è attualmente supportato solo nel livello per utilizzo generico nel modello di acquisto vCore.
Backup
Una delle funzionalità più importanti della piattaforma distribuita come servizio è costituita dai backup. In questo caso, i backup vengono eseguiti automaticamente senza alcun intervento da parte dell'utente. I backup vengono archiviati con ridondanza geografica nei BLOB di Azure e per impostazione predefinita vengono conservati per un periodo compreso tra 7 e 35 giorni, in base al livello di servizio del database. I database Basic e vCore per impostazione predefinita includono sette giorni di conservazione e nei database vCore questo valore può essere modificato dall'amministratore. Il periodo di conservazione può essere esteso configurando la conservazione a lungo termine (LTR), per un massimo di 10 anni.
Per garantire la ridondanza, è anche possibile usare l'archiviazione BLOB con ridondanza geografica e accesso in lettura. Questa risorsa di archiviazione replica i backup del database in un'area secondaria desiderata. Se necessario, sarà anche possibile leggere da tale area secondaria. I backup manuali dei database non sono supportati e la piattaforma negherà qualsiasi richiesta di eseguire questa operazione.
I backup del database vengono eseguiti in base a una pianificazione specifica:
- Completo: una volta alla settimana
- Differenziale: ogni 12 ore
- Log: ogni 5-10 minuti a seconda dell'uso del log delle transazioni
La pianificazione del backup deve soddisfare le esigenze della maggior parte degli obiettivi del punto o dell'ora di ripristino (RPO/RTO), ma ogni cliente deve valutare se sono soddisfatti anche i requisiti aziendali.
Per il ripristino di un database, sono disponibili numerose opzioni. A causa della natura della piattaforma distribuita come servizio, non è possibile ripristinare manualmente un database usando metodi convenzionali, ad esempio l'invio del comando T-SQL RESTORE DATABASE.
Indipendentemente dal metodo di ripristino implementato, non è possibile eseguire il ripristino su un database esistente. Se è necessario ripristinare un database, il database esistente deve essere eliminato o rinominato prima di avviare il ripristino. Tenere anche presente che, in base al livello di servizio della piattaforma, i tempi di ripristino non sono garantiti e possono variare. È consigliabile testare il processo di ripristino per ottenere una metrica di base sulla durata di un ripristino.
Le opzioni disponibili per il ripristino sono:
Ripristino nel portale di Azure: nel portale di Azure è possibile ripristinare un database nello stesso server di database SQL di Azure oppure è possibile eseguire il ripristino per creare un nuovo database in un nuovo server in qualsiasi area di Azure.
Ripristino con i linguaggi di script: è possibile usare sia PowerShell sia l'interfaccia della riga di comando di Azure per ripristinare un database.
Nota
Il backup di sola copia in Archiviazione BLOB di Azure è disponibile per Istanza gestita di SQL. Il database SQL non supporta questa funzionalità.
Per altre informazioni sui backup automatizzati, vedere Backup automatizzati - database SQL di Azure e Istanza gestita di SQL di Azure.
Replica geografica attiva
La replica geografica è una funzionalità di continuità aziendale che replica in modo asincrono un database fino a quattro repliche secondarie. Quando si esegue il commit delle transazioni nel database primario (e nelle relative repliche all'interno della stessa area), le transazioni vengono inviate ai database secondari per la riproduzione. Poiché questa comunicazione viene eseguita in modo asincrono, l'applicazione chiamante non deve attendere che la replica secondaria esegua il commit della transazione prima che SQL Server restituisca il controllo al chiamante.
I database secondari sono leggibili e possono essere usati per l'offload dei carichi di lavoro di sola lettura, liberando così risorse per carichi di lavoro transazionali nel database primario o avvicinando i dati agli utenti finali. Inoltre, i database secondari possono trovarsi nella stessa area del database primario o in un'altra area di Azure.
Con la replica geografica è possibile avviare un failover manualmente dall'utente o dall'applicazione. In caso si failover, può essere necessario aggiornare le stringhe di connessione dell'applicazione in modo da riflettere il nuovo endpoint del database primario.
Gruppi di failover
I gruppi di failover sono basati sulla tecnologia usata per la replica geografica, ma forniscono un singolo endpoint per la connessione. Il motivo principale per cui si usano i gruppi di failover è che la tecnologia fornisce endpoint che possono essere usati per instradare il traffico alla replica appropriata. L'applicazione può quindi connettersi dopo un failover senza modifiche alla stringa di connessione.