Le aziende che vogliono intraprendere la migrazione di workload SQL Server da on-premises verso Azure spesso incontrano delle difficoltà nell’identificare il servizio giusto, nel definire le dipendenze tra le diverse applicazioni e nella fase di pianificazione. In questo articolo iniziamo a capire insieme come scegliere il servizio più adatto alle diverse esigenze aziendali.
Se vuoi saperne di più, ti consiglio di dare uno sguardo all’assessment ad hoc di 7 giorni che SoftJam mette a disposizione dei suoi clienti per agevolare il più possibile questo viaggio verso il cloud.
iaas o paas?
In Azure, SQL Server è disponibile sia in modalità Infrastructure as a Service, con istanze installate a bordo di virtual machine, che in modalità Platform as a Service, la quale, a fronte di un numero di limitazioni sempre più esiguo, ci offre una piattaforma gestita che “toglie parecchie castagne dal fuoco” al reparto IT.
Come si evince facilmente dall’immagine a lato, la riduzione delle nostre responsabilità nella gestione della piattaforma ci lascia più tempo da dedicare alla gestione dei dati, e riduce il Total Cost of Ownership del nostro sistema.
Questo è il primo di una serie di articoli che tratteranno di migrazioni SQL Server da on-premises verso Azure, in cui andremo via via ad analizzare i dettagli dei diversi servizi disponibili in cloud. In questa introduzione, scopriremo quali sono i driver che ci guidano verso Paas piuttosto che Iaas, a seconda che noi si abbia spazio per una reingegnerizzazione della nostra soluzione piuttosto che invece si debba affrontare un cosiddetto Lift & Shift – ossia una migrazione rapida che introduce il numero minimo di variazioni rispetto all’on-premises.
come si è evoluta la questione nel corso del tempo
Partiamo col dire che, fino a qualche anno fa, di fronte ad un sistema da migrare la scelta era piuttosto immediata. Se si aveva buon margine di manovra sui database e si poteva sottostare ai limiti di funzionalità o di architettura che la modalità PaaS implicava, si poteva decidere di effettuare una reingegnerizzazione del sistema affinché potesse girare su Azure SQL Database. In questo caso, l’effort sarebbe stato ricompensato da tutta una serie di vantaggi in termini di gestione, come backup automatizzati e alta disponibilità della soluzione integrata nella piattaforma, ideali per abbassare i costi totali della soluzione.
Per contro, se ci si trovava di fronte ad un sistema più o meno legacy che necessitava di una specifica versione di SQL Server o che faceva uso di funzionalità irrinunciabili non supportate da Azure SQL Database, la strada era pressoché obbligata, e conduceva verso il mondo delle virtual machine (VM) e quindi alla modalità Infrastructure-as-a-Service.
Banalmente, la presenza di job schedulati mediante SQL Server Agent non facilmente portabili su altra tecnologia, o linked server verso sistemi esterni, o ancora la necessità di eseguire query cross-database, erano elementi che richiedevano necessariamente l’installazione di un’istanza SQL Server a bordo di una VM. Con questa soluzione si hanno a disposizione tutte le feature disponibili on-premises, al netto delle leggere variazioni architetturali che l’essere ospitati in un datacenter in cloud impone; ma si sottostà anche a tutti quegli oneri di gestione tipici di un sistema Enterprise, che deve garantire sicurezza, alta disponibilità della soluzione, performance e così via.
Nel corso del tempo, il servizio PaaS Azure SQL Database si è evoluto tantissimo, raggiungendo un livello di feature parity molto elevato ed introducendo novità infrastrutturali che permettono la sua integrazione in scenari più complessi.
Contestualmente, anche il database engine di SQL Server ha fatto passi da gigante in termini di retrocompatibilità, andando a vincolare al compatibility level – o ad altre opzioni gestibili a livello di singolo database, anziché sull’intera istanza – la possibilità di attivare le innovazioni legate alle nuove versioni di engine che, potenzialmente, possono portare a regressioni sul fronte delle performance durante le migrazioni, come modifiche al cardinality estimator, al query optimizer e simili. Il vero punto di svolta in questo processo di allineamento e ammodernamento, che ha aperto definitivamente le porte del mondo PaaS ai processi di Lift & Shift, è costituito dall’introduzione delle Managed Instance.
Queste istanze su piattaforma gestita offrono diversi vantaggi:
- riducono l’effort di gestione a carico del DBA, che non si dovrà preoccupare della disponibilità del servizio, dei backup e di altre amenità simili;
- offrono una feature parity prossima al 100% rispetto alla versione on-premises di SQL Server, e rappresentano quindi il miglior compromesso per chi vuole migrare, con effort ridotto, sistemi che possono partire da SQL Server 2005;
- pur essendo un servizio Paas, sono posizionate all’interno della nostra rete virtuale per darci un maggior controllo dal punto di vista sicurezza.
Di sicuro, ora come ora, costituiscono uno degli scenari più interessanti per chi si sposta in cloud e deve predisporre un sistema in grado di gestire servizi critici per il proprio business.
quindi, managed instance per tutti?
Questo significa che le Managed Instance sono la panacea di tutti i mali, e che le VM ed altre implentazioni SQL Server in PaaS sono morte? Assolutamente no!
Le VM sono ancora la scelta più corretta a fronte di vincoli applicativi forti, o qualora si desideri implementare una soluzione di disaster recovery ibrida per il proprio data center on-premises. Azure SQL Database, con i suoi DB singoli, in pool, Hyperscale o Serverless rappresenta invece la scelta ideale per nuove implementazioni che ad esempio hanno necessità della scalabilità del cloud per contenere i costi della soluzione.
Come anticipato in precedenza, nel corso dei prossimi articoli andremo ad approfondire le caratteristiche tecniche dei diversi servizi, e vedremo quali sono i punti di forza di ognuno ed in quali contesti danno il meglio. Ma prima, vediamo come affrontare la fase di raccolta dati che precede l’attività di migrazione.
ok, ma da dove si parte?
Per capire che strada imboccare, bisogna prima di tutto conoscere bene da dove si parte. Pertanto, si rende necessaria un’attività di intervista con il cliente per conoscere quale o quali isole applicative insistono sulla nostra istanza e quali servizi attingono ai dati su di essa ospitati. É, infatti, indispensabile capire se quanto rilevato dovrà seguire l’istanza in cloud, o se potrà tollerare la latenza nell’accesso al dato che risiederà in cloud.
Oltre a raccogliere informazioni – che possono essere più o meno precise – si può anche pensare di implementare un semplice sistema di monitoraggio: ad esempio, si potrebbe schedulare l’esecuzione cadenzata della stored procedure SP_WhoIsActive di Adam Machanic, archiviandone l’output su una tabella, per scoprire chi si collega al nostro sistema.
In caso si disponga già di una sottoscrizione Azure, un’alternativa più sofisticata potrebbe essere quella di distribuire il Monitoring Agent di Azure Monitor a bordo del sistema on-premises, per poi sfruttare Service Map e disegnare una mappa delle dipendenze dal nostro sistema SQL Server.
Questa attività dovrà essere accompagnata da un attento assessment, per valutare l’attuale dimensionamento del sistema e poi definire i requisiti minimi del sistema cloud-based. Dovranno essere rilevati eventuali vincoli che impongano l’adozione di una soluzione IaaS piuttosto che PaaS, come l’utilizzo di feature specifiche piuttosto che elementi bloccanti nella progettazione del database. In quest’ultima analisi, risulta di grande utilità il tool ufficiale Data Migration Assistant che, tra le altre cose, ci permette di verificare se i nostri database sono pronti per essere migrati di versione ed eventualmente essere ospitati in PaaS. L’analisi ci dirà se le funzionalità che abbiamo utilizzato hanno subito delle variazioni di comportamento al cambio di versione, o se non sono più disponibili nelle versioni più recenti, indicandoci i punti in cui il problema si presenta e dando indicazioni su come risolvere il tutto.
Sarà altresì importantissimo recepire tutti quei requisiti architetturali di raggiungibilità e sicurezza del dato che, a parità di supportabilità lato piattaforma SQL, potrebbero guidare la scelta verso un servizio piuttosto che un altro.
Una volta raccolte tutte queste informazioni, bisognerà conoscere le peculiarità dei diversi server SQL Server su Azure per andare a costruire l’architettura più adeguata alle nostre esigenze. Ma di questo parleremo alla prossima occasione!
database engine, database engine, sempre database engine… mica esiste solo lui! e gli altri servizi sql server?
Finora la discussione è rimasta incentrata sulle basi dati e sul database engine. Ma se il nostro sistema prevedesse l’utilizzo di Reporting Services, Analysis Services o Integration Services, cosa potremmo fare?
Ebbene, esistono implementazioni in PaaS per l’esecuzione di package di Integration Services tramite Azure Data Factory e la gestione di modelli Tabular di Analysis Services. Per i report di Reporting Services si potrà valutare la migrazione verso Power BI, che nelle capacità Premium supporta report paginati.
In tutti gli altri casi, o qualora il PaaS per questi componenti non sia la soluzione migliore, possiamo sempre valutare l’installazione di questi su una VM, andando a completare la nostra soluzione IaaS o realizzando un’infrastruttura ibrida IaaS – PaaS.
→ Vai all’articolo “SQL Server on Azure: quando realizzare una Virtual Machine?”
→ Vai all’articolo “SQL Server on Azure: alta disponibilità e riduzione dei costi in Iaas“
