Correggere gli asset prima della migrazione

Articolo
04/11/2024

Durante il processo di valutazione della migrazione, il team identifica le eventuali configurazioni che possono determinare l'incompatibilità di un asset con il provider di servizi cloud selezionato. La correzione è un checkpoint nel processo di migrazione che è possibile usare per risolvere eventuali incompatibilità.

Questo articolo descrive alcune attività comuni di correzione e consente di decidere se la correzione è un investimento saggio.

Tipi di correzione

Esistono due tipi principali di attività di correzione che è necessario pianificare per tutta la distribuzione.

In base ai risultati delle attività di valutazione
- Attività di correzione che devono essere completate per consentire la replica e la distribuzione.
- Queste attività di correzione sono state determinate nella valutazione del carico di lavoro durante la fase di valutazione. È necessario eseguire queste attività per assicurarsi che sia possibile replicare e preparare correttamente il carico di lavoro nel cloud.
- Questa operazione è incentrata principalmente sui server di origine di cui viene eseguita la migrazione.
In base ai risultati delle attività di test
- Ciò deriva dalle attività di migrazione di test e dall'esecuzione di test aziendali.
- Queste attività di correzione sono incentrate sulla configurazione dei server di destinazione replicati e su qualsiasi servizio di assistenza, ad esempio servizi di bilanciamento del carico, reti virtuali e account di archiviazione.
- Queste attività sono probabilmente più iterative. Test e correzione in diversi cicli fino a quando non è previsto il superamento di tutti i test case.

Tenere traccia delle attività di correzione

Durante l'iterazione, è possibile identificare le attività di correzione per i carichi di lavoro tramite valutazione o test. È necessario tenere traccia di queste attività come attività di progetto per assicurarsi che siano state completate.

Mentre le piccole onde di migrazione possono usare fogli di calcolo per tenere traccia degli elementi, onde più grandi con molte attività di correzione generano più elementi. È possibile usare strumenti come Azure DevOps per creare e classificare in ordine di priorità gli elementi di lavoro e spostarsi in fasi specifiche per aumentare il numero di istanze. Anche se non si usa Azure DevOps per altre attività, è possibile usarlo per valutare i problemi di correzione e organizzare le attività per il processo di migrazione.

Quando si creano queste attività, è necessario assicurarsi di riconnetterle al carico di lavoro che influiscono. In questo modo è possibile valutare quali carichi di lavoro potrebbero essere ritardati dalle attività di correzione. È quindi possibile classificare in ordine di priorità il lavoro in base alla priorità del carico di lavoro.

Alcuni problemi possono influire su più carichi di lavoro. Si tratta in genere di elementi con l'host, una configurazione ampia o problemi con la zona di destinazione nel suo complesso. Questi problemi devono essere quelli prioritari per la correzione.

Attività di correzione comuni

Il debito tecnico è una parte sana e prevista dell'ambiente aziendale. Le decisioni relative all'architettura adatte a un ambiente locale potrebbero non essere appropriate per una piattaforma cloud. In ogni caso, per preparare gli asset per la migrazione può essere necessario eseguire attività di correzione comuni. Di seguito sono riportati alcuni esempi:

Aggiornamenti dell'host secondari: occasionalmente è necessario aggiornare un host obsoleto prima della replica.
Aggiornamenti secondari del sistema operativo guest: probabilmente è necessario applicare patch o aggiornare il sistema operativo prima della replica.
Modifiche del contratto di servizio: i processi di backup e ripristino cambiano in modo significativo in una piattaforma cloud. I processi di backup per gli asset migrati potrebbero dover essere modificati per assicurarsi che continuino a raggiungere i contratti di servizio necessari nel cloud.
Modifiche alla configurazione dell'applicazione: le applicazioni di cui è stata eseguita la migrazione potrebbero richiedere modifiche alle variabili, ad esempio percorsi di rete per asset dipendenti, modifiche dell'account del servizio o aggiornamenti agli indirizzi IP dipendenti.
Modifiche secondarie ai percorsi di rete: i modelli di routing devono essere modificati per indirizzare correttamente il traffico utente ai nuovi asset. Questo non è il routing di produzione ai nuovi asset, ma la configurazione consente il routing appropriato agli asset in generale.

Attività di correzione su larga scala

Quando un data center viene gestito correttamente, con patch e aggiornato, è necessario eseguire la correzione. Gli ambienti avanzati di correzione tendono a essere comuni all'interno di aziende di grandi dimensioni. Ciò può includere organizzazioni con un ridimensionamento it di grandi dimensioni, un servizio gestito legacy e ambienti avanzati per l'acquisizione. In ognuno di questi ambienti, la correzione è costituita da una grande parte del lavoro di migrazione. Le attività di correzione seguenti possono verificarsi spesso o influire negativamente sulla velocità o la coerenza della migrazione. In questo caso, separare la correzione in un lavoro parallelo e un team simile all'adozione del cloud e alla governance del cloud.

Aggiornamenti frequenti dell'host: l'aggiornamento di più host per completare la migrazione di un carico di lavoro può ritardare il team di migrazione. Isolare le applicazioni interessate e risolvere i passaggi di correzione prima di includere le applicazioni interessate in tutte le versioni pianificate.
Aggiornamento frequente del sistema operativo guest: le aziende di grandi dimensioni in genere dispongono di server in esecuzione in versioni obsolete di Linux o Windows. Oltre ai rischi per la sicurezza del funzionamento di un sistema operativo obsoleto, esistono anche problemi di incompatibilità che impediscono la migrazione dei carichi di lavoro interessati. Quando più macchine virtuali richiedono la correzione del sistema operativo, provare a separare queste attività in un'iterazione parallela. Alcuni aggiornamenti possono essere completati tramite gli strumenti di migrazione come parte del processo di migrazione, ad esempio la funzionalità di aggiornamento di Windows Server in Azure Migrate e modernizzare.

Risolvere le correzioni su larga scala

Poiché la correzione per carichi di lavoro più piccoli può essere semplice, scegliere carichi di lavoro più piccoli per le onde di migrazione iniziali. Con il progressivo avanzamento delle attività di migrazione, le dimensioni dei carichi di lavoro da gestire aumentano e le attività di correzione possono richiedere molto tempo e denaro. Ad esempio, le attività di correzione per una migrazione di Windows Server 2003 che coinvolgono un pool di asset con più di 5.000 macchine virtuali possono ritardare una migrazione per mesi. Quando è necessaria una correzione su larga scala, potrebbe essere necessario modificare i piani per la migrazione dei carichi di lavoro interessati. In questi casi, le attività di modernizzazione per ottimizzare il valore delle attività di correzione potrebbero essere più efficienti e produttive.

È possibile usare le domande seguenti per facilitare le decisioni:

Tutti i carichi di lavoro interessati dalle attività di correzione sono stati identificati e annotati nel backlog della migrazione?
Per i carichi di lavoro che non sono interessati, una migrazione produce un ritorno simile sugli investimenti (ROI)?
Gli asset interessati possono essere corretti in conformità alla tempistica originale della migrazione? Quali effetti hanno le modifiche della sequenza temporale sul ROI?
È economicamente fattibile correggere gli asset in parallelo con le attività di migrazione?

Se le domande precedenti non vengono risposte, prendere in considerazione questi approcci di modernizzazione:

Containerizzazione: alcuni asset possono essere ospitati in un ambiente in contenitori senza correzione. Ciò potrebbe produrre prestazioni meno favorevoli e non risolve i problemi di sicurezza o conformità.
Automazione: a seconda dei requisiti di carico di lavoro e correzione, lo scripting della distribuzione in nuovi asset con un approccio DevOps potrebbe essere più redditizio.
Ricompilazione: quando i costi di correzione e il valore aziendale sono ugualmente elevati, un carico di lavoro è ideale per la ricompilazione o la riprogettazione.

Passaggio successivo

Replicare gli asset

Share via