Pianificare una migrazione dei dati

Completato

Un progetto di modernizzazione della piattaforma dati prevede cinque fasi, che in genere vengono completate in ordine.

Presso il rivenditore globale, il Consiglio di amministrazione ha approvato il progetto di modernizzazione e si sta iniziando a organizzare il personale e altre risorse. Per predisporre e assegnare le attività in modo ottimale, è necessario comprendere in modo approfondito le fasi del progetto.

In questa unità, ognuna delle cinque fasi verrà esaminata in dettaglio.

Avvio e individuazione

I progetti di modernizzazione della piattaforma dati vengono in genere avviati per soddisfare i requisiti aziendali o legali. Pertanto, è fondamentale tenere conto di queste esigenze e ottenere supporto dai dirigenti senior. Il primo passaggio consiste nel completare un esercizio di individuazione che include le considerazioni seguenti:

• Valutare un ambiente corrente

  Molte infrastrutture IT si evolvono nel corso degli anni, persino dei decenni. Nel tempo, l'azienda e il personale possono cambiare immensamente fino al punto che potrebbero non essere più presenti esperti nei sistemi di cui l'organizzazione dispone. In rari casi, le organizzazioni possono addirittura dimenticare di avere ancora alcuni sistemi.

• Controllare le dipendenze tra le applicazioni e i database esistenti

  Occorre dedicare del tempo a comprendere il modo in cui le applicazioni interagiscono con i database presenti nella rete. Inoltre, è necessario comprendere le eventuali dipendenze tra database, in modo che sia possibile raggruppare collettivamente i database in raggruppamenti logici. Eseguendo questa procedura, si useranno i raggruppamenti logici dei database come base per eseguirne la migrazione ad Azure come un'unica unità.

• Elencare i tipi di carico di lavoro dei sistemi

  L'elenco dei tipi di carico di lavoro nei server di database identificati fornisce informazioni dettagliate sull'utilizzo. I carichi di lavoro possono essere classificati come analitici (OLAP) o OLTP (transactional) in base al fatto che si tratti di operazioni di lettura o scrittura intensive. Ciò consente di decidere la tecnologia della piattaforma dati a cui eseguire la migrazione. Un'ulteriore categorizzazione può includere carichi di lavoro di supporto batch o decisionale.

Valutazione

Durante la fase di valutazione, le informazioni raccolte durante la fase di individuazione vengono usate per eseguire una valutazione completa dei carichi di lavoro identificati per stabilire quanto segue:

• Eventuali blocchi di migrazione potenziali
• Eventuali modifiche di rilievo che richiedano correzioni post-migrazione
• Funzionalità di Azure che i carichi di lavoro possono usare

A tale scopo, completare una valutazione del carico di lavoro corrente e una valutazione dei criteri del carico di lavoro:

• Valutazione del carico di lavoro corrente

  I server di database e le applicazioni identificati sono classificati e confermati per stabilire quanto segue: volume di dati e tassi di crescita previsti, utilizzo medio delle risorse e criticità per l'azienda. Questa fase offre anche l'opportunità di combinare o rimuovere le autorizzazioni dei database locali per ridurre il numero di database di cui eseguire la migrazione e ridurre il costo totale di proprietà.

• Valutazione dei criteri del carico di lavoro

  Nella valutazione dei criteri del carico di lavoro si usano i risultati della valutazione del carico di lavoro corrente e si definiscono i criteri post-migrazione per l'esecuzione dei carichi di lavoro identificati.

  Si supponga di aver identificato un server di database transazionale molto usato durante le ore di punta, ma con un utilizzo ridotto durante le ore di minore attività. Nella valutazione dei criteri del carico di lavoro si definiscono criteri post-migrazione, ad esempio la migrazione a un database di Azure SQL con scalabilità automatica per gestire i carichi di picco.

Pianificazione

La fase di pianificazione di un progetto di modernizzazione della piattaforma dati prevede la determinazione della piattaforma di destinazione, dell'approccio alla migrazione e dei piani di mitigazione per eventuali interruzioni pianificate o non pianificate.

Nella fase di pianificazione del processo di modernizzazione della piattaforma dati, sette termini descrivono in che modo è possibile gestire la transizione di applicazioni e dati da un ambiente locale esistente a un nuovo ambiente basato sul cloud (pubblico o privato). Questi approcci sono indicati anche con l'espressione "le 7 R", per via delle iniziali dei termini in inglese (Remain, Rehost, Refactor, Rearchitect, Rebuild, Replace, Retire):

#	Fase	Azione	Descrizione
1.	Conservazione	Non eseguire alcuna operazione	Modernizzazione continua considerando le opzioni a lungo termine per i servizi locali rimanenti.
2.	Rehosting	Eseguire la migrazione a IaaS	Questo approccio elimina la necessità di gestire il data center e offre un ritorno sugli investimenti (ROI) superiore, grazie alla riduzione del costo totale di proprietà (TCO).
3.	Refactoring	Eseguire la migrazione a IaaS o PaaS con modifiche minime alle applicazioni	Questo approccio elimina la necessità di gestire il data center e offre un ritorno sugli investimenti (ROI) superiore, grazie alla riduzione del costo totale di proprietà (TCO). Offre inoltre una riduzione del sovraccarico di gestione grazie al consolidamento dei database.
4.	Riprogettazione	Riscrittura degli aspetti principali dell'applicazione per l'uso delle tecnologie cloud	Consente l'uso di componenti moderni, riduce la distribuzione del codice e facilita la distribuzione devOps di infrastruttura e servizi.
5.	Ricostruzione	Ricostruire l'applicazione per l'uso di tecnologie PaaS o serverless	La ricompilazione di piattaforme dati e applicazioni con tecnologie più recenti consente l'uso della disponibilità elevata predefinita di Azure, aumenta la portabilità e la scalabilità delle applicazioni e riduce al minimo potenziali lacune di competenze tra la tecnologia usata e il personale che supporta/sviluppa l'applicazione.
6.	Sostituzione	Modificare l'applicazione in un'applicazione o in una soluzione SaaS più recente	Si consideri l'approccio di sostituzione quando un'applicazione presenta dipendenze dai dispositivi fisici collegati al server o quando si integra strettamente con l'infrastruttura locale.
7.	Ritira	Dismettere le applicazioni che non sono più necessarie	L'approccio del ritiro va considerato quando applicazioni e database legacy non vengono più usati perché non esistono requisiti aziendali o legali per mantenerli.

Il grafico seguente mostra il livello di lavoro richiesto da ogni strategia rispetto al valore che l'azienda ottiene dalla migrazione.

• Opzioni per la piattaforma di destinazione

  Per la scelta della piattaforma di destinazione sono disponibili due opzioni principali.

  • Infrastruttura distribuita come servizio (IaaS): in questo approccio si eseguirà la migrazione dei dati in una macchina virtuale in cui è installato SQL Server.

  • Piattaforma distribuita come servizio (PaaS): in questo approccio si eseguirà la migrazione dei dati in un servizio di piattaforma dati idoneo per il carico di lavoro. Per i carichi di lavoro transazionali, ciò implica il database di Azure SQL o Istanza gestita di SQL di Azure. Per i carichi di lavoro di tipo OLAP (Online Analytical Processing), si tratterà di Azure Synapse Analytics.

• Scelta della piattaforma di destinazione in base alle funzionalità

  • Database di Azure SQL: usare se l'area di attacco dell'applicazione è con ambito database. Il database SQL offre una soluzione di manutenzione ridotta che può essere un'ottima opzione per determinati carichi di lavoro.

  • Pool elastici del database di Azure SQL: I pool elastici consentono di allocare le risorse di archiviazione e calcolo a un gruppo di database, anziché dover gestire le risorse singolarmente per ogni database. Inoltre, i pool elastici sono più facili da ridimensionare rispetto ai singoli database, per i quali il ridimensionamento non è più necessario a causa delle modifiche apportate al pool elastico.

  • Serverless del database di Azure SQL: è efficace per ridurre i costi negli ambienti di sviluppo e test. La funzionalità di ritardo della sospensione automatica consente di impostare il periodo di inattività prima che il database venga sospeso automaticamente. È possibile scegliere tra 1 ora e 7 giorni o disabilitarla. Quando si accede di nuovo al database, viene ripreso e vengono addebitati solo i costi di archiviazione durante la pausa.

  • Istanza gestita di SQL di Azure: è appropriata se la superficie di attacco dell'applicazione è con ambito istanza e richiede funzionalità non disponibili nel database di Azure SQL, ad esempio:

    • SQL Agent
    • MSDTC
    • DQS
    • MDS
    • Posta elettronica database
    • PolyBase
    • Supporto dei server collegati
    • Supporto dei nuovi servizi cloud di Azure, ad esempio il rilevamento delle minacce

  • SQL Server nella macchina virtuale di Azure : usare se l'ambito dell'area di attacco dell'applicazione è limitato e richiede funzionalità non disponibili in Istanza gestita di SQL di Azure, ad esempio SQL Server Reporting Services (SSRS), SQL Server Analysis Services (SSAS) e SQL Server Integration Services (SSIS).

  • Azure Synapse Analytics: da usare se sono presenti applicazioni che eseguono query complesse su petabyte di dati che possono sfruttare l'elaborazione MPP (Massively Parallel Processing) per ridurre i tempi di elaborazione delle query da ore a minuti.

Per visualizzare l'elenco delle funzionalità supportate in ogni offerta PaaS per SQL, vedere Confronto delle funzionalità: database di Azure SQL e Istanza gestita di SQL di Azure.

• Scelta della piattaforma di destinazione in base al costo

  • database di Azure SQL: la natura di piattaforma distribuita come servizio del database di Azure SQL riduce notevolmente i costi di amministrazione e gestione rispetto alla topologia più tradizionale di SQL Server in Azure, poiché la maggior parte del lavoro viene completata automaticamente in background da Microsoft Operations. Su larga scala, è possibile risparmiare molto tempo e fatica.

  • Pool elastici del database di SQL di Azure: i pool elastici del database di Azure SQL offrono risparmi significativi per più database con esigenze di utilizzo imprevedibili. Le risorse di calcolo vengono condivise, evitando il provisioning eccessivo e riducendo i costi per la manutenzione e l'amministrazione del server.

  • Istanza gestita di SQL di Azure: le istanze gestite sono offerte ai clienti che desiderano un'offerta di servizio completamente gestita, in cui possono trasferire in modalità lift-and-shift l'ambiente locale facilmente, con modifiche minime alla configurazione. L'ambiente offre un minimo di 8 core e fino a 8 TB di spazio di archiviazione e si trova in una rete virtuale isolata. Questa offerta è ideale per i clienti che vogliono passare rapidamente al cloud ed evitare i costi delle macchine virtuali.

  • SQL Server in una macchina virtuale di Azure: rispetto alle offerte PaaS, SQL Server in esecuzione in macchine virtuali di Azure offre costi di calcolo, archiviazione e gestione più elevati, ma offrono un maggiore controllo sull'infrastruttura e su SQL Server.

  • Azure Synapse Analytics: Azure Synapse Analytics può ridurre i costi sfruttando l'architettura MPP per elaborare query complesse in pochi minuti anziché in ore.

• Migrazioni offline e online

  Nella fase di pianificazione è opportuno considerare se eseguire una migrazione offline oppure online. Con le migrazioni offline, il tempo di inattività delle applicazioni inizia quando inizia la migrazione. Per limitare il tempo di inattività al tempo di cutover al nuovo ambiente al termine della migrazione, scegliere una migrazione online. È consigliabile testare una migrazione offline per determinare se il tempo di inattività è accettabile. In caso contrario, eseguire una migrazione online. Inoltre, la scelta fra online e offline potrebbe non essere disponibile a seconda dell'offerta di servizio di Azure.

Trasformazione e ottimizzazione

Nella fasi di valutazione e pianificazione sono stati identificati gli aspetti delle applicazioni e del database che richiederanno operazioni post-migrazione per trasformare oppure ottimizzare una funzionalità allo scopo di garantire una migrazione corretta. La trasformazione implica in genere operazioni di correzione o modifica di un aspetto di un database.

L'ottimizzazione implica in genere una modifica al database di cui è stata eseguita la migrazione, allo scopo di usufruire di una funzionalità o di ottimizzarne l'uso in Azure.

Ad esempio, una trasformazione potrebbe comportare la modifica di una stored procedure o di una query SQL che contiene la sintassi non supportata nel database di destinazione. Ciò richiederebbe la modifica della sintassi per garantire la compatibilità con la nuova piattaforma di database, assicurando che la stored procedure o la query venga eseguita senza problemi nell'ambiente di destinazione.

• Transform

  Per garantire un'esperienza di post-migrazione corretta, potrebbe essere necessario apportare una o più delle modifiche seguenti a un database.

  • Installare aggiornamenti della versione pre-migrazione

  • Correggere gli errori identificati dagli strumenti di valutazione della migrazione

  • Implementare modifiche dello schema del database

  • Eseguire la migrazione di servizi di database integrati esistenti in Azure

  • Gestire i carichi di lavoro SSIS nel cloud

• Optimize (Ottimizza)

  Per assicurarsi che l'organizzazione ottenga il massimo dal suo investimento in Azure, durante la migrazione può essere utile seguire una o più delle linee guida per l'ottimizzazione seguenti.

  • Valutare le nuove funzionalità che possono essere disponibili nella piattaforma di destinazione

  • Ristrutturare i carichi di lavoro in set più efficienti in termini di costi o prestazioni

  • Scegliere il livello di servizio e le prestazioni più elevato durante la migrazione e ridurre le prestazioni al termine della migrazione

  • Verificare che i carichi di lavoro siano dimensionati in modo corretto

  • Ridurre al minimo la distanza tra il file BACPAC e il data center di destinazione

  • Disabilitare le statistiche automatiche durante la migrazione.

  • Partizionare tabelle e indici

  • Eliminare le viste indicizzate e ricrearle al termine della migrazione

Migrazione, convalida e correzione

Questa fase riguarda la migrazione stessa e, soprattutto, le procedure di convalida e correzione necessarie per confermare la riuscita della migrazione. Le fasi precedenti di pianificazione, valutazione e trasformazione sono servite per avere la certezza che tutto sia pronto per la migrazione e che funzionerà correttamente una volta spostato in Azure. Tutto ciò che resta da fare è preparare gli strumenti di migrazione necessari, completare la migrazione ed eseguire le convalide funzionali e delle prestazioni post-migrazione per garantire la coerenza dei dati con il database di origine.

Considerazioni sulla migrazione, la convalida e la correzione

È disponibile una vasta gamma di strumenti che possono essere usati per eseguire la migrazione alla piattaforma di destinazione scelta. Questi strumenti verranno illustrati nei moduli successivi. Nel frattempo, è importante considerare quanto segue quando si completa la migrazione:

• Comprendere i requisiti del carico di lavoro come punto di partenza
• Inizialmente, selezionare per la migrazione i carichi di lavoro non critici o i database con priorità bassa
• Eseguire una migrazione di test
• Testare il database per identificare eventuali problemi
• Testare il piano per mitigare i rischi associati a tempo di inattività e problemi di compatibilità
• Valutare gli strumenti di migrazione in base alle interruzioni, per ridurre il rischio di tempo di inattività del database
• Eseguire l'iterazione continua nel processo di migrazione
• Considerare le finestre di manutenzione disponibili per l'applicazione e il database di destinazione per la migrazione
• Portare offline applicazioni e database obsoleti
• Testare le applicazione di terze parti
• Creare nuovi piani di ripristino di emergenza e di manutenzione