Nel precedente articolo “SQL Server: viaggio verso il cloud”, abbiamo introdotto il tema della migrazione SQL Server da on-premises verso Azure, accennando ai principali vantaggi derivanti dalla scelta di un servizio gestito in Platform-as-a-Service (PaaS) piuttosto che ad un’implementazione in Infrastructure-as-a-Service (IaaS). Ma quando è effettivamente necessario implementare una virtual machine (VM) con a bordo SQL Server on Azure?
perche’ una vm piuttosto che un servizio gestito?
La piattaforma PaaS di Azure offre tutta una serie di validissimi servizi gestiti per SQL Server, declinati nelle diverse varianti di Azure SQL Database. Questi servizi consentono di ridurre la Total Cost of Ownership della nostra soluzione, semplificando la vita ai nostri DBA e più in generale agli amministratori di sistema, a scapito di una serie di compromessi da accettare, come l’impossibilità di controllare la versione di SQL Server su cui andiamo ad installare le nostre applicazioni.
Dall’altra parte, creare una macchina in Iaas è sicuramente più impegnativo; tuttavia, ci permette di rispondere a certe esigenze che non possiamo soddisfare in PaaS. Ecco alcuni driver che ci posso instradare verso un’implementazione in IaaS:
- gestione app legacy: Anche se la retrocompatibilità della piattaforma è oggigiorno molto elevata, può sempre capitare di dover gestire un’applicazione legacy che il fornitore non ci supporta in PaaS o per la quale richiede una specifica versione di SQL Server. Per ovviare questi ostacoli, possiamo creare una virtual machine (VM) dedicata a SQL Server. Questo ci permette di avere il controllo completo della nostra istanza, disporre di tutte le feature applicative tipiche di SQL Server e di avere un ambiente del tutto paragonabile a quanto potremmo ottenere on-premises, al netto delle differenze architetturali introdotte dal deployment in cloud.
- scenari ibridi: il poter disporre di tutte le feature di prodotto ci abilita alla creazione di scenari ibridi che coinvolgono il nostro datacenter on-premises ed Azure, utili ad esempio per finalità di business continuity e disaster recovery (BCDR).
- performance: una VM è la soluzione ideale anche quando la piattaforma PaaS non riesce a garantire il livello di performance richiesto dalla propria applicazione. Per quanto scalabili, infatti, i servizi gestiti non riescono ancora ad eguagliare il numero di core o il quantitativo di RAM disponibile sulle VM di capacità più grande.
Quelle esposte sopra sono ottime ragioni per decidere di muoversi nell’ambito IaaS. Ma creare una VM dedicata è semplice come distribuire un DB in PaaS? Non proprio. E per questo ora andiamo a vedere quali sono alcuni dei punti da tenere a mente, a partire dal dimensionamento della stessa.
come dimensionare una vm?
Dimensionare correttamente una virtual machine SQL Server, per massimizzarne le performance e contenerne i costi, è un’arte che richiede una profonda conoscenza dei meccanismi che regolano l’infrastruttura di Azure. Di seguito cercherò di riepilogare i principali criteri da osservare.
Normalmente, le performance di un’istanza SQL Server installata a bordo di una VM ad essa dedicata sono determinate da:
- il quantitativo di virtual core assegnati alla macchina e le performance dei processori installati sull’host che la ospita;
- la quantità di RAM disponibile sul sistema;
- le performance dello storage;
- le prestazioni lato networking, soprattutto in caso di implementazione di soluzioni di alta disponibilità (HA) che prevedono la replica dei dati tra i nodi del sistema.
I prerequisiti di configurazione della virtual machine possono derivare da specifiche del fornitore software, così come possono essere determinati in base all’analisi delle prestazioni registrate sul sistema on-premises oggetto di migrazione.
Una volta determinati i dati di targa della VM da creare in Azure, è necessario individuare la famiglia e la taglia di virtual machine che più si avvicina ai nostri desiderata.
Esistono svariate famiglie di VM – quelle ottimizzate per il calcolo, per la memoria, per lo storage, per il GPU computing e così via – ognuna dotata di peculiarità specifiche, determinati rapporti tra core disponibili e RAM assegnata, e caratteristiche diverse lato storage e networking.
Qualora più di una famiglia sia in grado di soddisfare i prerequisiti applicativi, conviene selezionare la famiglia con la CPU più performante. La componente di costo più alta nel contesto di una VM SQL Server è rappresentata dalla licenza, pagata per ogni core assegnato alla macchina. È nostro primario interesse disporre di core performanti per ridurre al minimo indispensabile il numero degli stessi.
Si può determinare quale famiglia abbia la CPU più performante analizzando i valori di Azure Compute Unit (ACU): a valore maggiore solitamente corrispondono performance più elevate, le quali ci interessano particolarmente nel contesto di SQL Server.
Salvo casi specifici, la scelta ricade solitamente tra le famiglie appartenenti alla categoria Memory-Optimized abilitate per lo storage premium (DS_v2, ES_v3, etc.), che presentano un rapporto tra numero di core e quantitativo di RAM assegnata particolarmente favorevole per i nostri scopi. Tendenzialmente preferisco le VM della famiglia DS_v2, ma verranno presto soppiantate dalla famiglia Easv4, basata su cpu AMD EPYC e rilasciata in General Availability qualche settimana fa, durante Ignite 2019.
Determinata la famiglia, occorre valutare la taglia della VM: a dimensione più grande corrisponde un maggior numero di core assegnati, più RAM allocata e maggiore capacità sul fronte storage e network.
Questi ultimi due aspetti sono spesso sottovalutati durante la fase di dimensionamento, ma hanno un’importanza strategica.
Un sistema SQL Server di produzione distribuito in Azure deve tendenzialmente poter fare affidamento su dischi Premium SSD o Ultra Disk, in grado di erogare i livelli di performance necessari per un workload top tier. Oltre a dover predisporre un’adeguata architettura di dischi in grado di erogare le prestazioni richieste in termini di IOPS e throughput, dovremo sincerarci che la taglia di VM individuata abbia un’adeguata capacità lato storage: non è insolito trovarsi davanti sistemi sottodimensionati dove, a fronte della disponibilità di dischi molto costosi e performanti, la virtual machine non è in grado di sfruttare quanto predisposto.
Lato networking, invece, è importante disporre di ampiezza di banda sufficiente e bassa latenza, specialmente nei contesti di alta disponibilità che andremo ad analizzare nel prossimo articolo della serie. Su questo fronte è importante che la VM possa disporre della funzionalità di Accelerated Networking che, in accoppiata alla funzionalità di Proximity Placement Groups, può migliorare notevolmente gli aspetti di latenza e bandwidth.
Una volta trovata e distribuita la VM corretta, occorre applicare una serie di configurazioni a livello di sistema operativo e di SQL Server per massimizzare la resa della macchina. Sull’argomento ci sarebbe da scrivere un libro, ma per ragioni di brevità mi fermo qui. Potete approfondire questa tematica sulla documentazione ufficiale.
sembra complesso, vero?
In realtà, una volta capito il meccanismo, vi assicuro che non è poi difficile come sembra. Inoltre, possiamo avvalerci di tecniche di automazione come ARM templates e PowerShell DSC: grazie a questi strumenti, potremo standardizzare e semplificare i processi di deployment e configurazione delle nostre VM, arrivando ad ottenere ambienti pronti all’uso in pochi minuti.
Nel prossimo articolo tratteremo anche gli aspetti di alta disponibilità e i costi della soluzione, così da delineare un quadro completo. Stay tuned!
→ Vai all’articolo “SQL Server: viaggio verso il cloud”
→ Vai all’articolo “SQL Server on Azure: alta disponibilità e riduzione dei costi in Iaas“
