Considerazioni sulla migrazione

Completato

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

Nell'azienda di start-up tecnologiche, il database fornitore viene usato per garantire che i componenti siano sempre in magazzino e arrivino just-in-time per il loro uso nel processo di produzione. I titolari delle scorte usano i dispositivi mobili per aggiornare questo database man mano che arrivano le spedizioni e gli acquirenti utilizzano un sito Web per monitorare i livelli delle scorte e identificare il momento migliore per l'ordine. I manager usano un set di report critici per il business per monitorare il processo e migliorare l'efficienza. Si vuole assicurarsi che nessuno di questi utenti sia interessato negativamente dalla migrazione ad Azure.

In questa unità si apprenderà come pianificare ed eseguire una migrazione uniforme del database nel cloud.

Analizzare le dipendenze

In un sistema complesso, un componente funziona raramente completamente indipendentemente. Esegue invece chiamate ad altri processi e componenti. I database, ad esempio, possono dipendere dai servizi directory che ospitano gli account utente. Quando si sposta un database nel cloud, è possibile accedere al servizio directory? In caso contrario, in che modo gli utenti accedono? Quando si ignora una dipendenza come questa, potrebbe verificarsi un errore totale del database.

Per attenuare i rischi, verificare se il database dipende da servizi come i seguenti:

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

Tenere presente anche che altri componenti possono dipendere dal database. Se si sposta il database senza riconfigurare i componenti dipendenti, quali sono le conseguenze? Ad esempio, se si sposta un database del catalogo prodotti e il sito Web pubblico dipende da esso per determinare quali prodotti presentare agli utenti, lo spostamento causerà un'interruzione del servizio?

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

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

Per eseguire questi controlli, rivolgersi agli stakeholder, agli amministratori e agli sviluppatori coinvolti in ogni database e componente di sistema. Consultare quindi la documentazione, se non si è certi di comprendere il comportamento dei sistemi, prendere in considerazione l'esecuzione di test, ad esempio acquisizioni di rete per osservare il comportamento.

Prepararsi a eseguire il fallback

In qualsiasi progetto di migrazione, è consigliabile essere sempre preparati per un errore. In un progetto di migrazione del database nel cloud, la peggiore eventualità è che il nuovo database diventa non disponibile e gli utenti non possono svolgere i propri lavori. È comune attenuare questo rischio, che potrebbe avere un grande impatto sulla redditività dell'azienda, pianificando di eseguire il rollback al database originale e non modificato in locale.

Per il piano di riserva, prendere in considerazione:

• Come assicurarsi di poter eseguire il fallback a un database non modificato dalla migrazione non riuscita? Ad esempio, è consigliabile eseguire un backup completo del database, subito prima di iniziare la migrazione.
• Quanto tempo è accettabile che il database sia offline, se è necessario eseguire il fallback?
• Qual è il budget disponibile per il piano di emergenza? Ad esempio, è possibile permettersi di replicare il database in un server di fallback dedicato? In questo caso, è possibile disattivare questo server subito prima della migrazione. Per ripristinare la situazione, si avvia un server. Si avrà immediatamente un database che non è interessato dalla migrazione, senza doverlo ripristinare dal backup.

Migrazione offline e online

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

Annotazioni

L'opzione online non è attualmente disponibile per i database MySQL nel Servizio Migrazione dati.

• Arrestare il sistema, trasferire il database, quindi riconfigurare e riavviare il sistema per usare il nuovo database. Si tratta di una migrazione offline.
• Mantenere il sistema in esecuzione durante lo spostamento del database nella nuova posizione, eseguire il roll forward delle transazioni sul database originale nel nuovo database mentre la migrazione sta procedendo e quindi cambiare le applicazioni per connettersi al nuovo database. Si tratta di una migrazione online.

È più semplice eseguire una migrazione offline, in cui gli utenti non possono modificare i dati durante la migrazione. Tuttavia, se il database è occupato o critico per il successo dell'organizzazione, ciò potrebbe non essere possibile.

Migrazioni offline

Si supponga che il database supporti un team di analisti che lavorano in un singolo fuso orario durante le normali ore lavorative. Il team in genere non lavora nei fine settimana. Tra le 18:00 di venerdì e le 9:00 di domenica, il database non viene spesso usato.

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

1. Portare offline il database, dopo che tutte le transazioni sono state completate venerdì sera.
2. Eseguire un backup completo o un'esportazione del database.
3. Arrestare il server locale e tenerlo disponibile nel caso in cui sia necessario ritornare alla configurazione precedente.
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é si verifica un lungo periodo in cui un'interruzione del servizio ha un effetto minimo sugli utenti. Durante questo periodo, è possibile eseguire un backup completo e il ripristino del database, sapendo che non si perderanno modifiche.

Migrazioni online

Si consideri ora un altro database che supporta un'app di vendita. Il personale addetto alle vendite viene distribuito in tutto il mondo e lavora anche nei fine settimana. Non esiste un periodo di attività bassa, il database è sempre occupato e, se si porta offline il database per un periodo significativo, avrà un impatto sugli utenti. L'attività di vendita è critica per l'azienda, quindi un'interruzione del servizio avrà un effetto diretto sulla linea di fondo dell'organizzazione.

In casi simili, prendere in considerazione l'esecuzione di 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 Migrazione dati di Azure per eseguire una migrazione online. Le migrazioni online presentano le differenze seguenti per le migrazioni offline:

• Non spostare il database originale offline prima di eseguire un backup o un'esportazione.
• Mentre la migrazione è in corso, le modifiche si applicano al database precedente.
• Lo strumento di migrazione garantisce che queste modifiche vengano copiate nel nuovo database prima del passaggio. Questa operazione viene spesso ottenuta riconfigurando il database precedente per replicare le modifiche apportate a quella nuova.

Migrazione delle applicazioni

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

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

L'intenzione è che si deve eseguire la migrazione dell'applicazione in piccole fasi che possono essere facilmente annullate se qualcosa va storto. Indipendentemente dal fatto che sia stato seguito un approccio offline o online alla migrazione del database, è comunque necessario disporre di una configurazione funzionante disponibile nell'origine originale. In teoria, sarà possibile tornare rapidamente all'origine originale. Tuttavia, se i dati cambiano costantemente, è necessario prendere in considerazione la posizione in cui sono state apportate queste modifiche.

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

Approcci alle metodologie di test

Se il database svolge un ruolo fondamentale nell'azienda, le conseguenze di un errore potrebbero essere estese. Per aumentare la tua sicurezza che ciò non accada, prendi in considerazione l'esecuzione di test delle prestazioni sul database migrato per assicurarti che possa gestire il carico degli utenti e rispondere rapidamente. Tenere presente che potrebbero esserci periodi di attività di picco, quando la domanda è molto superiore al normale. È necessario assicurarsi che il sistema migrato gestisca il carico di lavoro previsto.

Eseguire sempre alcuni tipi di test di regressione sul nuovo database prima di consentire l'accesso agli utenti. Questi test verificheranno che il comportamento e la funzionalità del sistema siano corretti.

Inoltre, è consigliabile eseguire un "test di immersione". Un test di immersione è un test di carico progettato per verificare il funzionamento del sistema nel suo complesso sotto pressione. Generando un sovraccarico sul nuovo database, questo test determina se è stabile anche in condizioni di picco di attività. Un test di immersione viene eseguito in un periodo di tempo significativo per vedere cosa accade quando la domanda elevata persiste.

Dopo aver stabilito che il nuovo sistema è stabile, è possibile iniziare a eseguire la migrazione degli utenti. Tuttavia, potrebbe essere necessaria un'ulteriore garanzia che gli utenti troveranno il nuovo sistema accettabile. 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 forma di test cieco, che consente di individuare eventuali problemi o problemi con il nuovo sistema. Monitorare le risposte di questi utenti e apportare 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 test canary sul database migrato per valutarne le funzionalità, la stabilità e la capacità prima di usarla per supportare le persone. La gestione del sistema locale in parallelo consente di ripristinare rapidamente gli utenti al sistema precedente in caso di problemi con il nuovo sistema.

• Migrazioni in più fasi. Un modo per attenuare l'impatto degli errori imprevisti nell'ambiente di produzione consiste nello spostare prima un numero ridotto di utenti nel nuovo sistema e monitorare i risultati. Se tutto viene eseguito senza problemi, è possibile spostare altri gruppi di utenti man mano che si ottiene fiducia nel nuovo database. È possibile spostare gli utenti in ordine alfabetico, in base al reparto, alla posizione o al ruolo, fino a quando non si trovano tutti nel nuovo database.

• Migrazioni a fasi. Un altro approccio consiste nel segmentare la migrazione non per utente, ma per carico di lavoro. Ad esempio, è possibile eseguire la migrazione delle tabelle di database che supportano le risorse umane, prima di quelle che supportano le vendite.

In tutti questi casi, si verifica un periodo in cui il database locale precedente viene eseguito in parallelo con il nuovo database cloud. È necessario assicurarsi che le modifiche apportate al database precedente vengano applicate anche al nuovo database e che vengano propagate nella direzione opposta. È possibile creare script per questa sincronizzazione o usare uno strumento come Servizio Migrazione dati di Azure.

Se si decide di gestire i database paralleli e sincronizzare le modifiche, porre le domande seguenti:

• Risoluzione dei conflitti. È probabile che una modifica a una riga in locale si verifichi in un momento simile a una modifica diversa alla stessa riga nel cloud? Ciò creerebbe un conflitto, in cui non è chiaro quale modifica deve essere mantenuta. Come risolvere questi conflitti?

• Traffico di rete. Quanto traffico di rete verrà generato mentre le modifiche vengono sincronizzate tra i database? È disponibile una capacità di rete sufficiente per questo traffico?

• Latenza. Quando si verifica una modifica in uno dei database, quale ritardo (se presente) è accettabile prima che tale modifica raggiunga l'altro database? Ad esempio, in un catalogo di prodotti potrebbe essere possibile attendere fino a un giorno prima che i nuovi prodotti siano visibili a tutti gli utenti. Tuttavia, se il database include informazioni transazionali critiche, ad esempio i tassi di cambio di valuta, tali dati devono essere sincronizzati molto più frequentemente, se non istantaneamente.

Migrazione a fasi

Una migrazione a fasi consente di dividere un sistema completo in carichi di lavoro ed eseguire la migrazione di un carico di lavoro alla volta.

Multiple databases (Più database)

Un sistema complesso può includere più database che supportano diversi carichi di lavoro. Ad esempio, le risorse umane potrebbero usare il database StaffDB , mentre il team di vendita potrebbe avere app per dispositivi mobili che eseguono query sia sul database ProductCatalogDB che sul database OrdersDB .

Naturalmente, è possibile scegliere di eseguire la migrazione dell'intero sistema di database al cloud in un'unica operazione. Questo potrebbe essere più semplice, perché non è necessario eseguire database sia in locale che nel cloud. Non è necessario considerare il modo in cui tali database comunicano durante la migrazione. Tuttavia, i rischi di errore sono più elevati. Un singolo problema può influire sia sul team delle risorse umane che sul team di vendita.

Valutare la possibilità di attenuare questi rischi per i sistemi di database di medie e grandi dimensioni eseguendo una migrazione a fasi, in cui si sposta un carico di lavoro alla volta. In questo esempio, è consigliabile innanzitutto eseguire la migrazione del database StaffDB , perché i problemi associati a un errore sarebbero limitati al team delle risorse umane e non impedirebbero di prendere ordini. Risolvendo eventuali problemi che si verificano con la migrazione di StaffDB , si apprenderanno le lezioni che si applicano ad altre migrazioni dei carichi di lavoro.

Successivamente, è possibile considerare la migrazione del carico di lavoro catalogo prodotti al cloud. In tal caso, prendere in considerazione domande come:

• Come si garantisce che i prodotti appena aggiunti al catalogo siano disponibili per l'ordine?
• È necessario sincronizzare i dati con il database OrdersDB , che rimane in locale?
• Quale latenza è accettabile per i nuovi prodotti per raggiungere il database OrdersDB dal catalogo prodotti?

Migrazioni a fasi del database singolo

Anche se si dispone solo di un database singolo che supporta tutti i carichi di lavoro, è comunque possibile prendere in considerazione una migrazione a fasi. Ad esempio, è possibile dividere il database in parti come segue:

• Tabelle che supportano le operazioni HR.
• Tabelle che supportano le vendite.
• Tabelle che supportano l'analisi e la creazione di report.

Se si esegue prima la migrazione delle tabelle delle operazioni HR, qualsiasi problema che si verifica influisce solo sul personale HR. Gli analisti delle vendite e dei dati continuano a lavorare sul database precedente senza interruzioni.

Prima di eseguire una migrazione a fasi, è necessario comprendere appieno i database e come vengono usati dalle applicazioni. Ad esempio, alcune tabelle nel database potrebbero supportare sia vendite che report. Ciò significa che non è possibile dividere in modo pulito i carichi di lavoro. È necessario sincronizzare queste tabelle tra database locali e cloud, fino a quando non viene eseguita la migrazione di tutti i carichi di lavoro.

Problemi di sicurezza

I database possono contenere dati sensibili, ad esempio i dettagli del prodotto, le informazioni personali del personale e i dettagli di pagamento, quindi la sicurezza è sempre una priorità elevata. È necessario decidere come proteggere questi dati durante la migrazione e nel nuovo database.

Protezione del firewall

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

Il secondo firewall separa i server front-end dai server di database. È consigliabile pubblicare il servizio di database in un numero di porta privato non noto al mondo esterno. Nel secondo firewall aprire questo numero di porta solo per gli indirizzi IP dei server front-end. Questa disposizione impedisce la comunicazione diretta da un utente internet malintenzionato ai 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 connessione per il server nel portale di Azure.

Autenticazione e autorizzazione

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

Annotazioni

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 chi è un utente, è necessario assegnargli le autorizzazioni per completare le attività che fanno parte del suo lavoro. Questo processo è detto autorizzazione.

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

1. Scoprire dove vengono archiviati gli account utente nel sistema locale. In MySQL gli account utente vengono in genere archiviati nella user tabella del mysql database, ma è possibile, ad esempio, integrarsi 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, scoprire quale accesso hanno al database. In MySQL, ad esempio, è possibile usare questo comando per l'account dbadmin@on-premises-host utente:

   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 ogni account utente al livello di accesso corretto 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

Poiché i dati vengono inviati attraverso la rete, potrebbero essere intercettati da un cosiddetto attacco "man-in-the-middle". Per evitare questo problema, Database di Azure per MySQL, Database di Azure per MariaDB e Database di Azure per PostgreSQL supporta secure Sockets Layer (SSL) 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 usare la crittografia SSL. Discutere questo argomento con gli sviluppatori per determinare le modifiche, se presenti, necessarie.

Monitoraggio e gestione

Parte della pianificazione della migrazione di un database consiste nel considerare il modo in cui gli amministratori di database continueranno a eseguire le 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. Monitorano per assicurarsi che possano risolvere eventuali problemi prima che la produttività sia interessata. È possibile prevedere che qualsiasi database non monitorato regolarmente inizi a causare problemi prima o poi.

È consigliabile adottare esattamente lo stesso approccio ai database cloud. Potrebbe essere più semplice risolvere i problemi in un sistema PaaS come Azure, perché è possibile aggiungere risorse senza acquistare, configurare e configurare qualsiasi hardware. Tuttavia, è comunque necessario individuare i problemi di sviluppo, quindi il monitoraggio è una priorità elevata tra le attività quotidiane.

Prima di eseguire la migrazione dei database nel cloud, scoprire quali strumenti di monitoraggio usano attualmente gli amministratori. Se questi strumenti sono compatibili con la soluzione proposta basata sul cloud, potrebbe essere necessario riconnetterli solo ai database migrati. In caso contrario, è necessario esaminare le alternative.

Tenere presente che Azure include un set di strumenti di monitoraggio delle prestazioni e raccoglie un'ampia gamma di contatori delle prestazioni e dati di log. Questi dati vengono visualizzati usando dashboard e grafici nel portale di Azure configurando Monitoraggio di Azure. È possibile creare grafici, tabelle e report personalizzati, progettati in modo specifico per le esigenze degli amministratori.

Gestione

Gli amministratori del database usano gli strumenti preferiti per modificare lo schema e il contenuto del database in locale. Se usano gli stessi strumenti dopo la migrazione, è possibile continuare a trarre vantaggio dalle proprie competenze. Per iniziare, valutare se il set di strumenti esistente è compatibile con il database ospitato nel cloud proposto. Molti strumenti saranno compatibili perché sono basati su standard ampiamente adottati, ad esempio SQL, ma è importante verificare la compatibilità. Se gli strumenti di gestione correnti non funzioneranno dopo la migrazione, provare a identificare le alternative con gli amministratori.

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

• Portale di Azure. Questo sito Web offre potenti funzionalità usate per configurare, monitorare e gestire i database e tutte le altre risorse che è possibile creare nel cloud di Azure.

• Azure PowerShell. Si tratta di un ambiente di esecuzione di script e un linguaggio con un'ampia gamma di comandi. Usare PowerShell, disponibile per gli ambienti Windows e Linux, per automatizzare attività amministrative complesse del database.

• Interfaccia della riga di comando di Azure. Si tratta di un'interfaccia della riga di comando in Azure. Usarlo per gestire servizi e risorse in Azure. È possibile usare l'interfaccia della riga di comando dagli ambienti della shell Windows e Linux e dall'interno degli script Bash.