Recentemente un cliente ci ha contattato per capirci qualcosa tra le differenze nelle varie offerte di dimensionamento per Azure SQL. Siccome non è la prima volta che un cliente si perde in questa giungla, ho pensato ad un piccolo vademecum.
Una piccola premessa
Questa guida parla specificamente di Azure SQL Database e Azure SQL Managed Instance, le due risorse PaaS in Azure basate su motore SQL Server.
Per entrambe queste risorse, al di là della quantità di opzioni a disposizione nella sezione di dimensionamento dal portale Azure, è importante avere chiaro che un dimensionamento “sbagliato” può sempre essere corretto, al costo di un breve disservizio necessario per riallocare la componente computazionale dietro il gateway. Quindi, regola numero uno:
Inoltre, siccome parliamo di utilizzi effettivi di business, tralasciamo il livello di servizio Basic, fondamentalmente inutile in quell’ambito.
Questo vademecum infine non parlerà di networking, repliche, backup, etc. Perché? Perché, tra le varie declinazioni dei servizi, non ci sono differenze rispetto a quelle caratteristiche.
Ed ora, si comincia.
Modelli di fatturazione
Partiamo subito dalle cose facili. Azure SQL SaaS viene fornito in due modelli di fatturazione, per vCore e per DTU.
- Nel modello per vCore è possibile scegliere con un certo grado di precisione la quantità di core, memoria e storage per ogni database, all’interno dei limiti del servizio specifici (vCore purchasing model per dettagli). Questo modello è disponibile per entrambe le declinazioni, Databases e Managed Instances.
- Nel modello per DTU, invece, cpu memoria e storage sono preallocati in rapporti predefiniti, tarati sull’unità di misura della Database Transaction Unit, e con diversi limiti del servizio. Questo modello è disponibile solo per Azure SQL Databases.
Trattandosi di modelli di fatturazione, non ci sono differenze a livello di tecnologia di backend, quanto di opzioni legate ai costi. In particolare, il modello per vCore, oltre ad avere limiti meno stretti per il servizio, permette anche di risparmiare facendo leva sugli Azure Hybrid Benefit (AHB) e sui benefici delle Reserved Instance (RI), cosa impossibile sul modello per DTU.
Livelli di servizio
All’interno dei modelli di fatturazione ci sono poi i livelli di servizio, ed è lì che si arriva alla ciccia. In particolare, abbiamo due livelli comuni alle offerte in esame:
- Premium o Business Critical – È un livello ad elevate prestazioni, fatto per workload OLTP che richiedono un’altissima disponibilità ed una bassa latenza a livello di storage. È sostenuto dalla tecnologia AlwaysOn Availability Group, ed ogni database viene fornito da un nodo primario e da tre secondari, ognuno con storage indipendente posizionato su dischi SSD locali. Comprende, compresa nel prezzo, una copia secondaria di sola lettura per attività analitiche e di reportistica.
- Standard o General Purpose – È il livello di servizio orientato al budget. In questo caso la parte computazionale e quella storage sono disaccoppiati, e lo storage è fornito da blob sotto storage account. La resilienza è data dalle caratteristiche del blob storage, e dalla presenza di altri sistemi computazionali spare in gradi di essere riassegnati dal Service Fabric se il sistema primario non dovesse più funzionare.
Oltre a questi, se scelgo Azure SQL Database ho a disposizione una chicca per scenari di alto profilo.
- Hyperscale – Si tratta di un livello di servizio specifico per i Database del modello di fatturazione per vCore e, come facile intuire dal nome, si tratta del massimo in termini di scala, sia per volumi che per prestazioni. Giusto per riferimento, ecco le caratteristiche salienti presentate da Microsoft (per cui perdonerete l’italiano traballante):
- 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à 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.
- 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.
È finita? Quasi! Se il mio modello di fatturazione è per vCore, ho probabilmente un’ultima scelta da fare, e cioè quale hardware usare per supportare il mio servizio Azure SQL.
Livelli computazionali
Qui la faccenda si complica un po’, ma non troppo, perché le offerte sono diversificate tra servizi.
Azure SQL Database
Se ho adottato questo tipo di servizio, avrò a disposizione due opzioni:
- Provisioned – In questo caso decido a priori il numero di core ed il rapporto tra vCore e RAM, secondo numerose e complicate tabelle che non trovo utile proporre in questa sede ma che potete trovare qui. La cosa importante da tenere presente è che vado a preallocare una certa quantità di risorse, con la conseguenza di avere un costo fisso e ben prevedibile a prescindere dall’utilizzo effettivo della mia risorsa.
- Serverless – Sgombriamo subito il campo dagli equivoci, il server c’è eccome. Ma non devo scegliere un numero fisso di core, quanto piuttosto un limite minimo ed un limite massimo; Service Fabric provvederà ad allocare core sulla base delle metriche di funzionamento effettive. Inoltre, posso scegliere di mettere in pausa il server dopo un certo tempo di inattività, ottimizzandone i costi computazionali. Va da sé che la mia applicazione dovrà poter gestire i tempi di warm up del mio servizio, al riavvio del database.
Azure SQL Managed Instance
Se invece ho optato per questo tipo di servizio, indipendentemente dal service tier avrò a disposizione 3 tipi di hardware:
- Standard-series (Gen5) – la nostra istanza sarà sostenuta da processori Intel® E5-2673 v4 (Broadwell) a 2.3 GHz, Intel® SP-8160 (Skylake), o Intel® 8272CL (Cascade Lake) a 2.5 GHz, con 5.1 GB RAM per ogni vCore.
- Premium-series – la nostra istanza sarà sostenuta da processori Intel® 8370C (Ice Lake) a 2.8 GHz, con 7 GB di RAM per ogni vCore.
- Memory optimized premium-series – la nostra istanza sarà sempre sostenuta da processori Intel® 8370C (Ice Lake) a 2.8 GHz, ma con ben 13.6 GB di RAM per ogni vCore.
Conclusioni
Diamo per acquisito che si sia già operata la selezione a monte di quale servizio PaaS scegliere, se Database o Managed Instance. A questo punto, cosa scegliere, dando per acquisito che ogni scelta comporterà un maggiore o minore costo finale della risorsa?
Se avete selezionato il Database, in prima istanza sceglierò il modello di fatturazione più adatto tra la semplicità gestionale del modello per DTU ed i benefici in termini di risparmio del modello per vCore. Se avete selezionato la Managed Instance, la scelta non si pone, esiste solo il modello per vCore!
Dopodiché sceglierò il livello di servizio, sulla base degli effettivi requisiti del workload. Va da sé che, per dimensionare correttamente il mio servizio dovrò avere a disposizione delle metriche su cui basarmi. E se non le ho, perché si tratta di un workload nuovo, poco importa; di nuovo, ridimensionare un servizio Azure SQL è questione di un click.
Infine, se il processo di selezione mi ha portato nel campo del vCore, dovrò scegliere anche il livello computazionale, e qui ancora dovrò basarmi sulle mie metriche esistenti, o basarmi su assunzioni e tarare il tutto con l’effettivo uso.
Facile, vero?
Come già detto, questo articolo non ha la pretesa di esplorare tutte le specifiche caratteristiche dei servizi PaaS Azure SQL. L’obiettivo è piuttosto di chiarire un po’ le idee a voi che vi avventurate per la prima volta nell’esplorazione di queste offerte, aiutandovi ad orientarvi meglio ed a fare almeno le scelte di base in maniera più consapevole.
Spero di esserci riuscito, ma se così non fosse stato vi ringrazio in anticipo per i feedback che avrete voglia di condividere.
Hear ya next time!