Se stavi pensando di spostare il tuo ambiente SQL Server in Azure, hai solo un paio di opzioni. Innanzitutto è possibile utilizzare la soluzione PaaS del database SQL di Azure e spostare un singolo database o utilizzare un pool elastico. L'altra opzione è stata una soluzione IaaS che usa macchine virtuali di Azure che eseguono Microsoft SQL Server. Presto avremo una terza opzione chiamata Istanza gestita di database SQL.
Le istanze gestite colmano il divario tra SQL Server locale e Azure Database SQL
Le istanze gestite sono state presentate per la prima volta alla conferenza Microsoft Build nella primavera del 2017 e finora l'anteprima è stata limitata a un numero limitato di clienti e consulenti. Le istanze gestite possono essere considerate un ibrido tra una versione completa di SQL Server e il database SQL di Azure. I database singoli ed elastici sono basati su un modello di programmazione con ambito database e le istanze gestite sono basate su un modello di programmazione con ambito istanza. Ciò rende le istanze gestite più compatibili con SQL Server locale.
Le istanze gestite offrono una sensazione molto maggiore di un SQL Server locale, ma sono basate sulla stessa infrastruttura del database SQL di Azure. Ciò che lo distingue dal database SQL di Azure è che presenta al cliente un'intera istanza di SQL Server. Nel database SQL di Azure, configuri un server, che in realtà è un contenitore, e quindi puoi avere più database in quel server, ma non possono comunicare facilmente tra loro. Con le istanze gestite, tutti i database all'interno dell'istanza si trovano sullo stesso SQL Server effettivo, quindi hai il pieno supporto per le query tra database. Questa è un'enorme funzionalità per molte applicazioni che altrimenti non sarebbero adatte al database SQL di Azure e penso che consentirà a molte più applicazioni SQL Server di spostarsi nel cloud.
La funzionalità a livello di istanza è ora supportata. Ciò include cose come tabelle temporanee globali, SQL Server Agent, Service Broker, replica, SQL Audit e Common Language Runtime (CLR). Le istanze gestite possono anche supportare database di dimensioni fino a 35 TB. Attualmente la capacità maggiore per un database SQL di Azure è di 4 TB nel livello superiore. Sospetto che questo possa cambiare presto e, di nuovo, aprirà il cloud per più applicazioni.
Le istanze gestite possono anche sfruttare tutte le funzionalità della piattaforma PaaS, per includere backup automatici, rilevamento delle minacce, valutazioni delle vulnerabilità, alta disponibilità, replica geografica, consulente del database e molto altro. Ho visto una presentazione che discuteva di come funziona il processo di failover automatico e ho appreso che gli oggetti a livello di server vengono replicati nell'istanza di failover. Ciò significa che cose come accessi e lavori, punti deboli per molti dei nostri ambienti oggi, vengono gestite per te.
Nell'ultimo anno ho aiutato numerosi clienti a migrare al database SQL di Azure e una delle sfide principali è la migrazione dei dati. Non puoi semplicemente eseguire un backup di SQL Server e ripristinarlo nel database SQL di Azure. Sono stato molto lieto di apprendere che con le istanze gestite di database SQL possiamo utilizzare backup nativi di SQL Server e ripristinare le istanze gestite, tuttavia è necessario utilizzare il meccanismo di backup su URL. Ciò renderà molto più semplici le migrazioni alle istanze gestite, tuttavia, poiché le istanze gestite sono basate sul database SQL di Azure, si tratta di un ticket unidirezionale:non è possibile eseguire il backup dei database delle istanze gestite e ripristinarli in locale. Se hai mai deciso di riportare il tuo database in locale o fuori dalle istanze gestite, dovrai esportare i tuoi dati.
I database su istanze gestite sono molto più pronti per la migrazione ad Azure SQL Banca dati
D'altra parte, poiché sono basati sulla piattaforma del database SQL di Azure, i singoli database inseriti in un'istanza gestita possono essere migrati nei rispettivi database SQL di Azure. Ciò rende un'istanza gestita un perfetto trampolino di lancio, in cui puoi elaborare le complicazioni di isolamento che ti impediscono di migrare direttamente a PaaS.
Sono curioso di sapere che la replica è supportata. Non sono ancora stato in grado di scoprire se un database di Istanza gestita può essere un editore o se può essere solo un abbonato, come un database SQL di Azure. Se può essere un editore, potrebbe essere un modo efficace per tornare in locale. Spero davvero che nel prossimo futuro avremo la possibilità di ripristinare anche i backup nativi di SQL Server su database SQL di Azure singleton. Sembra che la tecnologia sia presente, deve solo essere ampliata per l'ambiente PaaS esistente.
Un'altra osservazione interessante sulle istanze gestite è che poiché la tecnologia è basata sul modello del database SQL di Azure, la versione di SQL Server seguirà quella del database SQL di Azure. Questo potrebbe complicare le cose con il supporto del fornitore. Molti fornitori dichiareranno di certificare il proprio prodotto su SQL Server versione X. Anche se le istanze gestite supporteranno quasi tutte le funzionalità di SQL Server 2017, non utilizzerà la stessa versione build, quindi i controlli della versione a livello di codice saranno complicati. La tua migliore linea d'azione in questo caso è respingere il fornitore, dal momento che è improbabile che Microsoft vacilli su questa posizione e non ho dubbi che alcune di queste conversazioni saranno difficili.
I fornitori si impegneranno a certificare i loro prodotti su istanze gestite o questo diventerà un problema come quello che abbiamo riscontrato con la virtualizzazione? All'inizio della virtualizzazione, molti fornitori hanno dichiarato di non supportare i loro prodotti in esecuzione virtualizzata, tuttavia Microsoft supportava completamente Windows X e SQL Server X virtualizzati. Speriamo di vedere i fornitori salire a bordo e certificare i loro prodotti su istanze gestite. Vedo sicuramente alcuni pionieri di SQL Server là fuori che passeranno alle istanze gestite dopo i loro test.
Ogni volta che un cliente sta cercando di migrare al cloud, la sicurezza è una grande preoccupazione. Le istanze gestite offrono supporto VNET con indirizzi IP privati e VPN per reti locali. Ciò può consentire a un client di proteggere il proprio ambiente dalla rete Internet pubblica e di avere il completo isolamento.
Sono entusiasta delle istanze gestite e non vedo l'ora che sia più ampiamente disponibile. Per i clienti che desiderano un ambiente gestito, ma necessitano di una soluzione più ricca di funzionalità rispetto a un database SQL di Azure singleton o elastico, ritengo che le istanze gestite siano la soluzione perfetta. C'è stato un divario tra il database SQL di Azure e SQL Server su una macchina virtuale di Azure, poiché molti clienti hanno bisogno di più delle offerte del database SQL di Azure, ma SQL Server su una macchina virtuale di Azure è ancora più manutenzione e responsabilità di quanto desiderassero. Le istanze gestite colmano davvero questo divario. Supportano database molto più grandi, consentono migrazioni dei dati più semplici, consentono query tra database e non dovrebbero richiedere modifiche al codice poiché la piattaforma è così altamente compatibile con SQL Server locale.
In sintesi, se la tua organizzazione sta valutando il passaggio a un ambiente ospitato all'interno della piattaforma del database SQL di Azure, potrai scegliere tra singoli database SQL di Azure, pool elastici o istanze gestite. A seconda delle esigenze dell'applicazione, una di queste soluzioni dovrebbe adattarsi perfettamente. In caso contrario, hai anche la possibilità di eseguire un'istanza SQL Server tradizionale su una macchina virtuale di Azure, che offre funzionalità interessanti come backup gestiti, replica geografica, Azure Site Recovery e molto altro ancora. Microsoft continua a investire nella piattaforma Azure offrendo nuovi prodotti e funzionalità di cui i clienti hanno bisogno e l'imminente rilascio di istanze gestite è una prova continua di tale attenzione. Resta sintonizzato, poiché ci è stata promessa un'anteprima pubblica nel prossimo futuro.
