Considerazioni sulla migrazione

Completato

Un sistema aziendale che viene eseguito in locale può avere un'architettura associata ad altri servizi che operano nello stesso ambiente. È importante conoscere le relazioni esistenti tra un sistema di cui si vuole eseguire la migrazione e le altre applicazioni e servizi attualmente in uso nell'organizzazione.

Nella startup tecnologica dell'esempio, il database dei fornitori viene usato per assicurarsi che i componenti siano sempre in magazzino e siano disponibili just-in-time per essere usati nel processo di produzione. I responsabili del magazzino usano i dispositivi mobili per aggiornare questo database man mano che arrivano le consegne, mentre gli acquirenti usano un sito Web per monitorare i livelli delle scorte e identificare il momento migliore per effettuare l'ordine. I manager utilizzano un set di report cruciali per monitorare il processo e aumentare l'efficienza. Si vuole essere certi che il lavoro di nessuno di questi utenti sia penalizzato dalla migrazione ad Azure.

In questa unità verrà illustrato come pianificare ed eseguire una migrazione di database nel cloud senza problemi.

Analizzare le dipendenze

In un sistema complesso, di rado un componente è del tutto indipendente. Esegue invece chiamate ad altri processi e componenti. I database, ad esempio, possono dipendere da servizi directory che ospitano gli account utente. Quando si sposta un database nel cloud, è possibile accedere a un servizio directory? Se non è possibile, come faranno gli utenti a effettuare l'accesso? Quando si trascura una dipendenza di questo tipo, potrebbe verificarsi un errore generale del database.

Per mitigare i rischi, controllare se il database dipende da servizi quali:

• Servizi directory, ad esempio Active Directory.
• Altri archivi di entità di sicurezza.
• Altri database.
• API Web o altri servizi di rete.

Tenere inoltre presente che dal database potrebbero dipendere anche altri componenti. Se si sposta il database senza riconfigurare i componenti dipendenti, quali sono le conseguenze? Se ad esempio si sposta un database del catalogo prodotti, da cui dipende il sito Web pubblico per determinare quali prodotti presentare agli utenti, si causa un'interruzione del servizio?

Verificare se uno di questi tipi di componenti dipende dal database:

• Siti Web e API Web.
• App client, ad esempio app per dispositivi mobili e software desktop.
• Altri database.
• Report.
• Data warehouse.

Per eseguire queste verifiche, rivolgersi agli stakeholder, agli amministratori e agli sviluppatori coinvolti in ogni database e componente di sistema. Consultare la documentazione e, se non si è certi di capire il comportamento dei sistemi, provare a eseguire alcuni test, ad esempio acquisizioni di rete, per osservare il comportamento.

Prepararsi a eseguire il fallback

In qualsiasi progetto di migrazione, è necessario essere sempre pronti ad affrontare un problema. In un progetto di migrazione di un database al cloud, la peggiore eventualità è che il nuovo database risulti non più disponibile e che gli utenti non possano quindi svolgere le proprie attività. Per limitare le conseguenze di questo rischio, che può incidere notevolmente sulla redditività della società, si pianifica in genere di eseguire il rollback al database originale locale, non modificato.

Per il piano di fallback, prendere in considerazione gli aspetti seguenti:

• Come avere la certezza che sia possibile eseguire il fallback a un database non coinvolto nella migrazione non riuscita? È consigliabile, ad esempio, effettuare un backup completo del database appena prima di iniziare la migrazione.
• Per quanto tempo è accettabile che il database resti offline, se è necessario eseguire il fallback?
• A quanto ammonta il budget stanziato per il piano di fallback? Ci si può permettere, ad esempio, di replicare il database in un server di fallback dedicato? Se sì, è possibile disattivare il server immediatamente prima della migrazione e, per eseguire il fallback, avviare il nuovo server. Si avrà immediatamente un database non interessato dalla migrazione, senza che sia necessario ripristinarlo dal backup.

Migrazioni offline e online

Per eseguire la migrazione di un database, sono disponibili almeno due opzioni:

Nota

L'opzione online non è attualmente disponibile per i database MySQL nel servizio di migrazione dei dati.

• Arrestare il sistema, trasferire il database e quindi riconfigurare e riavviare il sistema per usare il nuovo database. Questa è una migrazione offline.
• Mantenere in esecuzione il sistema mentre si sposta il database nella nuova posizione, eseguire il roll forward delle transazioni dal database originale al nuovo database durante la migrazione e quindi passare alle applicazioni per la connessione al nuovo database. Questa è una migrazione online.

È più semplice eseguire una migrazione offline perché gli utenti non possono modificare i dati mentre viene eseguita la migrazione. Se il database è occupato o di importanza critica per l'operatività aziendale, questo tipo di migrazione potrebbe tuttavia non essere possibile.

Migrazioni offline

Si supponga che il database supporti un team di analisti che lavorano in uno stesso fuso orario nelle normali ore di ufficio e quindi non nei fine settimana. Tra le 18:00 di venerdì e le 9:00 di domenica, il database non viene quasi mai usato.

In questa situazione è possibile eseguire una migrazione offline nel fine settimana, seguendo questa procedura:

1. Il venerdì sera, dopo che saranno state completate tutte le transazioni, impostare il database offline.
2. Eseguire un'esportazione o un backup completo del database.
3. Arrestare il server locale e tenerlo a disposizione nel caso in cui sia necessario eseguire il fallback.
4. Ripristinare il database nel sistema cloud di destinazione.
5. Portare online il sistema di destinazione.
6. Riconfigurare i client per la connessione al database cloud.

In questo caso, è possibile eseguire una migrazione offline perché il tempo a disposizione è molto e l'interruzione del servizio ha un effetto limitato sugli utenti. Durante questo intervallo di tempo, è possibile eseguire un backup e un ripristino completo del database, nella certezza che non si perderà alcuna modifica.

Migrazioni online

Si consideri ora un altro database che supporta un'app di vendita. Il personale di vendita è dislocato in tutto il mondo e lavora anche nei fine settimana. Non esiste quindi un periodo di bassa attività, il database è sempre occupato e, se il database viene portato offline per un periodo di tempo significativo, avrà un impatto significativo sugli utenti. Inoltre, l'attività di vendita è cruciale per l'azienda e un'interruzione del servizio avrà quindi un effetto diretto sui profitti dell'organizzazione.

In casi come questo, è opportuno valutare la possibilità di eseguire una migrazione online. In una migrazione online, il tempo di inattività è limitato al tempo necessario per passare al nuovo database. Usare uno strumento come il servizio di migrazione dei dati di Azure per eseguire una migrazione online. Rispetto alle migrazioni offline, le migrazioni online si contraddistinguono per gli aspetti seguenti:

• Non è possibile spostare il database originale offline prima di eseguire un backup o un'esportazione.
• Mentre è in corso la migrazione, le modifiche si applicano al database originale.
• Lo strumento di migrazione garantisce che queste modifiche vengano copiate nel nuovo database prima del passaggio. A questo scopo, è spesso necessario riconfigurare il database originale in modo che replichi le modifiche nel nuovo database.

Migrazione delle applicazioni

Dopo aver eseguito la migrazione di un database, come (e quando) è necessario passare al nuovo sistema e aggiornare le applicazioni in modo che usino il nuovo database? È possibile:

• Spostare le applicazioni nel nuovo database una alla volta.
• Spostare subset di utenti.
• Adottare una combinazione di entrambi gli approcci.

Lo scopo è quello di eseguire la migrazione dell'applicazione in piccole fasi, di cui è possibile eseguire facilmente il rollback in caso di problemi. Indipendentemente dalla modalità di migrazione del database prescelta, online o offline, è comunque necessario che nel server di origine sia presente una configurazione funzionante. In questo modo, sarebbe teoricamente possibile tornare rapidamente al server di origine. I dati, tuttavia, cambiano continuamente, ed è necessario avere presente la posizione in cui sono state apportate le modifiche.

• In una migrazione offline, l'origine e le destinazioni sono indipendenti l'una dall'altra. Gli utenti e le applicazioni non hanno più una visione coerente dei dati. E in un sistema transazionale, questa situazione è probabilmente inaccettabile. In questo caso, è necessario mantenere una qualche forma di replica bidirezionale tra i database mentre sono entrambi ancora attivi. Se tuttavia lo scopo di un'applicazione è quello di generare report mensili o settimanali, generare proiezioni di vendita o eseguire altre operazioni statistiche, la mancanza di coerenza potrebbe non essere così preoccupante. Queste applicazioni usano infatti una "visualizzazione estesa" dei dati, anziché dipendere strettamente dai dati aggiornati. In quest'ultimo caso, le applicazioni transazionali vengono spostate subito sul nuovo database, mentre le applicazioni per la creazione di report possono essere spostate più lentamente.
• In una migrazione online, il nuovo database viene mantenuto sincronizzato con quello precedente, generalmente da una forma di replica. Il processo di replica potrebbe essere asincrono e potrebbe quindi verificarsi un ritardo. Tuttavia, le modifiche apportate ai dati nel nuovo database non verranno propagate in quello originale, causando possibili conflitti. Un'applicazione in esecuzione sul database precedente potrebbe apportare una modifica in conflitto con i dati modificati nel nuovo database. La replica sovrascriverà automaticamente la modifica nel nuovo database, ottenendo un "aggiornamento perso".

Approcci all'esecuzione dei test

Se il database svolge un ruolo critico per le attività aziendali, le conseguenze di un errore potrebbero essere significative. Per aumentare la fiducia che questa situazione non si verifichi, valutare l'opportunità di eseguire test delle prestazioni sul database di cui è stata eseguita la migrazione per assicurarsi che possa far fronte al carico che gli utenti potrebbero aggiungere e rispondere in tempi rapidi. Tenere presente che potrebbero verificarsi picchi di attività, in cui la richiesta è molto più alta del normale. È necessario assicurarsi quindi che il sistema di cui è stata eseguita la migrazione riesca a gestire il carico di lavoro previsto.

Eseguire sempre un test di regressione sul nuovo database prima di consentirne l'accesso agli utenti. Questi test verificheranno che il comportamento e le funzionalità del sistema siano corretti.

È consigliabile eseguire anche un "soak test", ovvero un test di carico progettato per verificare il funzionamento dell'intero sistema sotto pressione. Generando un sovraccarico sul nuovo database, questo test determina se è stabile anche in condizioni di picco di attività. Il "soak test" viene eseguito su un periodo di tempo piuttosto lungo per poter valutare le prestazioni del database in caso di situazione di picco prolungata.

Una volta verificata la stabilità del nuovo sistema, è possibile iniziare la migrazione degli utenti. Potrebbe tuttavia essere necessaria un'ulteriore garanzia che gli utenti giudicheranno accettabile il nuovo sistema. In questo caso, è possibile valutare l'opportunità di eseguire un "canary testing", che indirizza in modo trasparente al nuovo sistema un piccolo subset di utenti, i quali non sanno di avere questa possibilità di accesso. Si tratta di una sorta di test cieco, progettato per consentire di individuare eventuali problemi con il nuovo sistema. Monitorare le risposte di questi utenti e apportare le eventuali modifiche necessarie.

Gestione di sistemi paralleli

Esistono diversi motivi per cui è possibile scegliere di eseguire il database locale precedente in parallelo con il nuovo database cloud:

• Periodi di test. Come illustrato nell'argomento precedente, è consigliabile eseguire "canary test" sul database di cui è stata eseguita la migrazione per valutarne la funzionalità, la stabilità e la capacità prima di consentirne l'accesso agli utenti. Mantenere in parallelo il sistema locale offre un modo rapido per riportare gli utenti al sistema precedente in caso di problemi con il nuovo sistema.

• Migrazioni in più fasi. Un modo per attenuare l'effetto di errori imprevisti nell'ambiente di produzione consiste nello spostare prima un piccolo numero di utenti nel nuovo sistema e monitorarne i risultati. Se tutto procede regolarmente, è possibile spostare nuovi gruppi di utenti man mano che si acquista fiducia nel nuovo database. È possibile spostare gli utenti in ordine alfabetico, per reparto, per località o per ruolo, fino a quando non sarà stata completata la migrazione di tutti gli utenti al nuovo database.

• Migrazioni a fasi. Un altro approccio consiste nel suddividere il processo migrazione non in base alla tipologia di utenti, ma in base al carico di lavoro. È ad esempio possibile eseguire la migrazione delle tabelle del database che supportano le risorse umane prima di quelle su cui si basano le vendite.

In tutti questi casi, si crea un intervallo di tempo in cui il database locale precedente viene eseguito in parallelo con il nuovo database cloud. È necessario quindi assicurarsi che le modifiche apportate al database precedente vengano applicate anche al nuovo database e che vengano propagate anche nella direzione opposta. È possibile creare uno script per questa sincronizzazione oppure usare uno strumento come il servizio di migrazione dei dati di Azure.

Se si decide di mantenere i database paralleli e sincronizzare le modifiche, porsi le domande seguenti:

• Risoluzione dei conflitti. Quante probabilità esistono che una modifica apportata a una riga in locale sia pressoché contemporanea a un'altra modifica apportata alla stessa riga nel cloud? Si creerebbe un conflitto, in cui non sarebbe chiaro quale modifica dovrebbe essere mantenuta. Come possono essere risolti questi conflitti?

• Traffico di rete. Quanto traffico di rete verrà generato durante la sincronizzazione delle modifiche tra i database? La capacità di rete disponibile è sufficiente per questo traffico?

• Latenza. Se viene apportata una modifica in uno dei database, qual è il ritardo eventualmente accettabile prima che la modifica raggiunga l'altro database? In un catalogo di prodotti, ad esempio, potrebbe essere possibile attendere fino a un giorno prima che i nuovi prodotti siano visibili a tutti gli utenti. Se tuttavia il database include informazioni transazionali critiche, ad esempio tassi di cambio di valuta, i dati devono essere sincronizzati con maggiore frequenza, se non immediatamente.

Migrazione a fasi

In una migrazione a fasi si divide un sistema completo in carichi di lavoro e si esegue la migrazione di un carico di lavoro alla volta.

Multiple databases (Più database)

In un sistema complesso possono essere contenuti più database che supportano più carichi di lavoro. Il reparto risorse umane, ad esempio, può usare il database StaffDB, mentre il team di vendita potrebbe avere app per dispositivi mobili che eseguono query sul database ProductCatalogDB e sul database OrdersDB.

Naturalmente, è possibile scegliere di eseguire la migrazione dell'intero sistema di database nel cloud in un unico passaggio. Questa soluzione potrebbe essere più semplice perché non è necessario eseguire database sia in locale che nel cloud. Non sarebbe inoltre necessario tenere conto delle modalità di comunicazione dei due database durante la migrazione. I rischi di errore sarebbero tuttavia maggiori. Un singolo problema potrebbe compromettere l'attività sia del reparto risorse umane sia del team di vendita.

Valutare quindi l'opportunità di attenuare questi rischi per i sistemi di database di medie e grandi dimensioni eseguendo una migrazione a fasi, in cui viene spostato un carico di lavoro alla volta. In questo esempio, è possibile decidere di eseguire prima la migrazione del database StaffDB perché i problemi associati a un errore sarebbero limitati per il team delle risorse umane e non impedirebbero l'evasione degli ordini. Risolvendo tutti i problemi che si verificano con la migrazione di StaffDB, si acquisirebbero competenze applicabili anche alla migrazione degli altri carichi di lavoro.

Si potrebbe quindi pensare di migrare nel cloud il carico di lavoro Catalogo prodotti. In questo caso, porsi le domande seguenti:

• Come garantire che i prodotti appena aggiunti al catalogo siano disponibili per l'ordinazione?
• È necessario sincronizzare i dati con il database OrdersDB che rimane in locale?
• Quale latenza è accettabile affinché i nuovi prodotti passino dal catalogo prodotti al database OrdersDB?

Migrazioni a fasi di database singoli

Anche se si ha un database singolo su cui si basano tutti i carichi di lavoro, è comunque possibile prendere in considerazione una migrazione a fasi. È ad esempio possibile dividere il database in parti come descritto di seguito:

• Tabelle che supportano le operazioni delle risorse umane.
• Tabelle che supportano le attività di vendita.
• Tabelle che supportano le attività di analisi e creazione di report.

Se si esegue prima la migrazione delle tabelle delle operazioni delle risorse umane, i problemi che potrebbero verificarsi riguarderebbero solo il personale delle risorse umane, mentre gli addetti alle vendite e gli analisti di dati continuerebbero a lavorare sul database precedente senza interruzioni.

Prima di eseguire una migrazione a fasi, è necessario capire interamente il funzionamento dei database e il modo in cui vengono usati dalle applicazioni. È ad esempio possibile che alcune tabelle di un database vengano usate sia per le attività di vendita che per la creazione di report. Questo significa che non sarebbe possibile dividere chiaramente i carichi di lavoro e sarebbe necessario sincronizzare le tabelle tra il database locale e il database cloud fino a quando non fossero stati migrati tutti i carichi di lavoro.

Problemi di sicurezza

I database possono contenere dati sensibili, tra cui dettagli di prodotti, informazioni personali e dettagli di pagamento e quindi la sicurezza assume sempre la massima priorità. È necessario decidere come proteggere i dati durante la migrazione e nel nuovo database.

Protezione con firewall

In un'applicazione connessa a Internet, i server di database vengono generalmente protetti da almeno due firewall. Il primo firewall separa Internet dai server front-end, se ad esempio questi ospitano siti Web o API Web. Solo la porta TCP 80 deve essere aperta per il firewall esterno ma, in realtà, questa porta deve essere aperta per tutti gli indirizzi IP di origine, a eccezione degli indirizzi bloccati.

Il secondo firewall separa invece i server front-end dai server di database. È consigliabile pubblicare il servizio di database su un numero di porta privata, non nota al mondo esterno. Nel secondo firewall è opportuno quindi aprire questo numero di porta solo per gli indirizzi IP dei server front-end. Questa precauzione impedisce la comunicazione diretta tra un utente Internet dannoso e i server di database.

Se si prevede di eseguire la migrazione dei server di database alle macchine virtuali di Azure, usare una rete virtuale con gruppi di sicurezza di rete (NSG) per replicare le regole del firewall. Se si usa Database di Azure per MySQL, Database di Azure per MariaDB o Database di Azure per PostgreSQL, è possibile creare regole del firewall per proteggere il database usando la pagina Sicurezza delle connessioni per il server nel portale di Azure.

Autenticazione e autorizzazione

Nella maggior parte dei database, è necessario controllare attentamente chi accede ai dati e li modifica. Questo controllo richiede che gli utenti vengano identificati in modo positivo quando si connettono al database. Questo processo è chiamato autenticazione e viene in genere eseguito con un nome utente e una password. I sistemi di database come MySQL, MariaDB e PostgreSQL hanno i propri meccanismi di autenticazione. Quando si esegue la migrazione dei sistemi al cloud, è necessario assicurarsi di continuare ad autenticare gli utenti in modo sicuro.

Nota

I servizi Database di Azure per MySQL, Database di Azure per MariaDB e Database di Azure per PostgreSQL emulano l'autenticazione tradizionale di MySQL, MariaDB e PostgreSQL.

Quando si conosce l'identità dell'utente, è necessario assegnargli le autorizzazioni richieste per completare le attività che fanno parte del processo. Questo processo prende il nome di autorizzazione.

Per un progetto di migrazione del database, è necessario assicurarsi che gli utenti vengano autorizzati correttamente nel database cloud:

1. Trovare il percorso di archiviazione degli account utente nel sistema locale. In MySQL gli account utente vengono in genere archiviati nella tabella user del database mysql, ma è possibile, ad esempio, integrarli con gli account utente archiviati in Active Directory.

2. Ottenere un elenco di tutti gli account utente. In MySQL, ad esempio, è possibile usare questo comando:

   SELECT host, user FROM mysql.user;
   

3. Per ogni account utente, determinare il tipo di accesso al database. In MySQL, ad esempio, è possibile usare questo comando per l'account utente dbadmin@on-premises-host:

   SHOW GRANTS FOR 'dbadmin'@'on-premises-host';
   

4. Ricreare ogni account utente nel database cloud. In MySQL, ad esempio, è possibile usare questo comando per creare un nuovo account:

   CREATE USER 'dbadmin'@'cloud-host'
   

5. Autorizzare per ogni account utente il corretto livello di accesso nel database cloud. In MySQL, ad esempio, è possibile usare questo comando per consentire a un utente di accedere al database completo:

   GRANT USAGE ON *.* TO 'dbadmin'@'cloud-host'
   

Crittografia

Se i dati vengono inviati attraverso la rete, possono essere intercettati da un cosiddetto attacco "man-in-the-middle". Per evitare il problema, Database di Azure per MySQL, Database di Azure per MariaDB e Database di Azure per PostgreSQL supportano SSL (Secure Sockets Layer) per crittografare le comunicazioni. SSL viene applicato per impostazione predefinita ed è consigliabile non modificare questa impostazione.

Potrebbe essere necessario modificare le impostazioni di connessione delle applicazioni client per poter usare la crittografia SSL. Affrontare questo argomento con gli sviluppatori per determinare le modifiche eventualmente necessarie.

Monitoraggio e gestione

Nella pianificazione della migrazione di un database è necessario prevedere anche il modo in cui gli amministratori di database continueranno a eseguire le proprie attività dopo la migrazione.

Monitoraggio

Gli amministratori di database locali sono soliti eseguire un monitoraggio continuo per individuare rapidamente problemi quali colli di bottiglia dell'hardware o la contesa per l'accesso in rete. In questo modo, possono risolvere eventuali problemi prima che venga compromessa la produttività. Un database che non viene monitorato con regolarità potrebbe invece iniziare a causare problemi prima o poi.

È consigliabile adottare esattamente lo stesso approccio per i database cloud. Potrebbe essere più facile risolvere eventuali problemi in un sistema PaaS come Azure perché consente di aggiungere risorse senza dover acquistare e configurare nuovi componenti hardware. Sarebbe comunque necessario individuare gli eventuali problemi di sviluppo e il monitoraggio rimarrebbe quindi un'attività di importanza prioritaria.

Prima di eseguire la migrazione dei database nel cloud, determinare quali strumenti di monitoraggio vengono attualmente usati dagli amministratori. Se questi strumenti sono compatibili con la soluzione basata sul cloud proposta, potrebbe essere necessario riconnetterli solo ai database di cui è stata eseguita la migrazione. In caso contrario, è necessario analizzare le alternative.

Tenere presente che Azure viene fornito con un set di strumenti per il monitoraggio delle prestazioni e che raccoglie un'ampia gamma di contatori delle prestazioni e dati di log. Per visualizzare questi dati, si usano dashboard e grafici nel portale di Azure, dopo aver configurato Monitoraggio di Azure. È possibile creare grafici, tabelle e report personalizzati, progettati appositamente per le esigenze degli amministratori.

Gestione

Gli amministratori dei database usano i propri strumenti preferiti per modificare lo schema e il contenuto dei database locali. Se usano gli stessi strumenti dopo la migrazione, è possibile continuare a trarre vantaggio dalla loro competenza. In primo luogo, quindi, è necessario capire se il set di strumenti esistente è compatibile con il database ospitato nel cloud proposto. Molti strumenti saranno compatibili perché sono basati su standard adottati su vasta scala, ad esempio SQL, ma è importante verificare tale compatibilità. Se gli strumenti di gestione correnti non funzionano più dopo la migrazione, provare a individuare le alternative con gli amministratori.

Azure include diversi strumenti che è possibile usare per amministrare i database MySQL, MariaDB e PostgreSQL:

• Portale di Azure. Questo sito Web offre funzionalità avanzate per la configurazione, il monitoraggio e la gestione dei database, oltre che di qualsiasi altra risorsa che è possibile creare nel cloud di Azure.

• Azure PowerShell. Si tratta di un ambiente e un linguaggio di esecuzione di script con un'ampia gamma di comandi. Se si usa PowerShell, disponibile per gli ambienti Windows e Linux, è possibile automatizzare le complesse attività amministrative dei database.

• Interfaccia della riga di comando di Azure. Si tratta di un'interfaccia della riga di comando di Azure, da cui è possibile gestire i servizi e le risorse in Azure. È possibile usare l'interfaccia della riga di comando dagli ambienti shell Windows e Linux e dagli script Bash.