In molte realtà aziendali i database SQL Server sono ancora installati su server on-premises oppure su infrastrutture IaaS ormai datate. Spesso sono ambienti stabili, che funzionano da anni, ma che iniziano a creare qualche limite quando si parla di aggiornamenti, sicurezza, continuità operativa e scalabilità.
Con la fine del supporto di SQL Server 2016, molte aziende stanno iniziando a valutare un percorso di aggiornamento. In questi casi può essere il momento giusto per non limitarsi a sostituire semplicemente il server, ma iniziare a ragionare anche su una migrazione verso Azure.
Il passaggio al cloud non significa per forza adottare subito servizi PaaS come Azure SQL Database o Azure SQL Managed Instance. In molti scenari, soprattutto quando ci sono applicazioni legacy, dipendenze particolari o configurazioni SQL molto specifiche, una soluzione intermedia molto concreta è SQL Server su Azure Virtual Machine.
Questa scelta permette di mantenere un modello molto simile all’on-premises, con pieno controllo dell’istanza SQL Server e del sistema operativo, ma con i vantaggi dell’infrastruttura Azure.
In questo articolo vediamo come eseguire una migrazione online di database SQL Server verso una SQL Server VM su Azure utilizzando Azure Database Migration Service, mantenendo il database sorgente operativo durante la fase di sincronizzazione e riducendo il downtime al solo momento finale di cutover.
Perché scegliere una migrazione Online con Azure DMS
Quando si affronta una migrazione SQL Server verso Azure, una delle prime decisioni da prendere è la modalità di migrazione: Offline oppure Online.
La differenza tra le due è fondamentale, soprattutto in ambienti di produzione.
Con una migrazione offline, il database viene fermato, viene eseguito un backup e poi ripristinato sulla destinazione. Questo approccio è semplice da gestire, ma comporta un downtime che può diventare importante, soprattutto su database di grandi dimensioni.
Con una migrazione online, invece, il database sorgente rimane attivo durante tutto il processo. Azure Database Migration Service utilizza un meccanismo basato su backup FULL iniziale e successivi backup dei log transazionali, mantenendo il database di destinazione continuamente sincronizzato.
Questo significa che:
- le applicazioni continuano a lavorare sul database sorgente
- le modifiche vengono replicate sulla destinazione tramite i log
- il downtime è limitato solo alla fase finale di cutover
È proprio questo il motivo per cui la modalità online è quella consigliata nella maggior parte degli scenari reali, soprattutto quando si lavora su ambienti produttivi dove fermare il database non è un’opzione.
C’è però un requisito fondamentale da rispettare: tutti i database coinvolti devono essere configurati con Recovery Model FULL. Senza questo requisito non è possibile eseguire i backup dei log, e quindi la sincronizzazione continua non può funzionare.
Nel mio caso, quando lavoro su migrazioni di questo tipo, la scelta è quasi sempre orientata verso la modalità online: richiede qualche passaggio in più in fase di configurazione, ma permette di gestire la migrazione in modo molto più controllato e con un impatto minimo sugli utenti.
Architettura della migrazione con Azure DMS
Per capire bene come funziona la migrazione online, è importante avere chiaro il flusso dei dati e i componenti coinvolti.
A differenza di altre soluzioni di migrazione “dirette”, Azure Database Migration Service non si collega semplicemente al database sorgente per copiarne i dati, ma si basa su un approccio più strutturato e sicuro, utilizzando i backup SQL Server.
Nel mio lab ho utilizzato una configurazione abbastanza classica, che poi è quella che ritrovo spesso anche nei progetti reali.
Il flusso è questo:
- il server SQL sorgente esegue un backup FULL iniziale
- i file di backup vengono salvati su Azure Blob Storage
- successivamente vengono eseguiti backup dei log transazionali a intervalli regolari
- Azure DMS legge questi file dal Blob Storage
- il database viene ripristinato sulla SQL Server VM di destinazione
- i log vengono applicati in continuo per mantenere i due ambienti sincronizzati
In questo scenario entrano in gioco tre componenti fondamentali.
Il primo è lo Storage Account Azure, che viene utilizzato come area di staging per i backup. Qui vengono salvati sia il backup FULL che tutti i file di log.
Il secondo è il Self-Hosted Integration Runtime (SHIR), un agente leggero che viene installato sul server SQL sorgente. Questo componente serve per stabilire una comunicazione sicura con Azure senza dover esporre direttamente il server su Internet.
Il terzo è ovviamente Azure Database Migration Service, che si occupa di orchestrare tutta la migrazione, leggendo i backup dal Blob Storage e applicandoli sulla macchina di destinazione.
Una cosa importante da sottolineare è che il database di destinazione, durante la sincronizzazione, rimane nello stato RESTORING. Questo è normale: significa che sta ricevendo continuamente i log dal sistema sorgente.
Solo al momento del cutover finale il database verrà portato online e diventerà operativo sulla nuova VM.
Questo approccio può sembrare più articolato rispetto a una semplice copia dati, ma è proprio quello che permette di ottenere una migrazione con downtime minimo e con un controllo molto più preciso di tutto il processo.
