Individuazione dell'ambiente Windows

Con le tecnologie oggi disponibili, come Application Migration Service, spostare Windows Server, Linux e altri sistemi operativi basati su x86 e i relativi carichi di lavoro su AWS è abbastanza semplice. Tuttavia, far funzionare correttamente questi carichi di lavoro e farlo su larga scala presenta una serie di sfide diverse. Questa sezione ha lo scopo di identificare le considerazioni sulla migrazione che possono consentire di migrare i carichi di lavoro Microsoft in modo rapido, sicuro e senza problemi.

Valutare

Sebbene sia possibile «forzare» migrazioni più piccole (come quelle che coinvolgono 100 server) con una pianificazione e un'automazione minime, non è possibile spostare 500 o più server utilizzando questa metodologia. Le seguenti considerazioni contribuiscono in modo determinante a una migrazione su larga scala di successo ed è possibile utilizzareValutazione della preparazione alla migrazione (MRA)per identificare le aree di considerazione su cui concentrarti.

Architettura aziendale

Maggiore è il debito tecnologico nell'ambiente, più è difficile migrare. Le organizzazioni che dispongono di programmi di architettura aziendale sani si sforzano di limitare il proprio ambiente alle versioni attuali e recenti di software e sistemi (spesso chiamate versioni N e N -1 delle principali release). Questo non solo riduce il numero di scenari da tenere in considerazione, ma sfrutta anche i progressi delle versioni più recenti. Ad esempio, Windows Server 2012, Windows Server 2008 e le versioni precedenti di Windows Server sono progressivamente molto più difficili da automatizzare nell'ambiente Windows Server rispetto alle versioni più recenti. La concessione di licenze è anche più difficile per le versioni precedenti e non supportate.

Gestione della standardizzazione e della configurazione

La standardizzazione dell'ambiente è un altro fattore da considerare. Le organizzazioni che dispongono di ambienti costruiti a mano e mantenuti sono considerate più simili agli animali domestici. Ogni sistema è unico e ci sono molte più combinazioni di configurazione possibili rispetto a quelle realizzate utilizzando immagini standardizzate, Infrastructure as code (IaC) o pipeline di integrazione continua e distribuzione continua (CI/CD).

Ad esempio, è consigliabile ricostruire un tipico server Web utilizzando IaC o CI/CD durante la migrazione, anziché migrare manualmente il singolo server. È inoltre consigliabile archiviare tutti i dati persistenti in un datastore come un database, una condivisione di file o un repository. Se i sistemi non vengono ricostruiti utilizzando IaC o CI/CD, dovrebbero almeno utilizzare strumenti di gestione della configurazione (come Puppet, Chef o Ansible) per standardizzare i server di cui dispongono.

Buoni dati

La qualità dei dati è anche un fattore chiave per il successo delle migrazioni. Dati accurati sui server attuali e sui relativi metadati sono essenziali per l'automazione e la pianificazione. La mancanza di dati validi aumenta la difficoltà nella pianificazione di una migrazione. Esempi di dati validi includono un inventario accurato di server, applicazioni sui server, software sui server con versioni, numero di CPU, quantità di memoria e numero di dischi. Ti consigliamo di acquisire tutti i dati necessari ai pianificatori delle ondate per la pianificazione o tutti i dati che intendi utilizzare come parte dell'automazione del processo di migrazione.

Automazione di

L'automazione è essenziale per le migrazioni su larga scala. Esempi di automazione includono l'installazione dell'agente, l'aggiornamento delle versioni software delle utilità necessarie per l'automazione, ad esempio .NET oPowerShell, caricamento o aggiornamento di software per AWS come AWS Systems Manager Agent (SSM Agent), AmazonCloudWatchagente o altro software di backup o gestione necessario per l'esecuzione in AWS.

Pianificazione dettagliata

Lo sviluppo e la gestione di un piano dettagliato sono essenziali anche per le migrazioni su larga scala. È necessario disporre di un piano ben definito per migrare 50 server a settimana per molte settimane. Un piano efficace include quanto segue:

• Usopianificazione delle ondateper organizzare i server in ondate in base alle tue dipendenze e priorità.

• Usopianificazione settimanale(fino al cutover) per comunicare con i team applicativi e identificare rete, DNS, firewall e altri dettagli che devono essere affrontati durante il cutover.

• Uso dettagliato, hour-to-hourpianificazione(intorno al cutover effettivo) per descrivere la finestra di manutenzione del cutover.

• Usocriteri go/no-goper descrivere in quali circostanze un'applicazione sarà considerata tagliata ad AWS o dovrà essere restituita alla posizione di origine.

• Usoattività di puliziacome attività di follow-up che devono essere completate. Queste attività possono avvenire al di fuori della finestra di manutenzione del cutover o dopo il completamento diipercura. Le attività di pulizia comprendono la verifica dei backup e dei vari agenti, la rimozione dell'agente dell'Application Migration Service da un server o la rimozione del server di origine e delle risorse associate.

Mobilitare

Durante la fase di mobilitazione, è importante scoprire quante più complessità e variazioni possibili dell'organizzazione in modo che possano essere prese in considerazione durante la pianificazione della migrazione. Idealmente, è possibile evitare di affrontare tali complessità e variazioni durante la finestra di manutenzione del cutover e prevenire eventuali guasti.

Sfide delle migrazioni su larga scala

Gli errori di migrazione si verificano quando una o più applicazioni vengono trasferite nei nuovi ambienti e i requisiti prestazionali o funzionali non possono essere soddisfatti entro la finestra di manutenzione della migrazione. In questo modo l'applicazione o le applicazioni vengono ripristinate nella posizione originale. Inoltre, è necessario eseguire il failback anche per tutte le altre applicazioni che dipendono da tale applicazione o applicazioni. Le migrazioni fallite tendono a influire non solo sull'ondata attuale ma anche sulle ondate future, poiché le applicazioni devono essere riprogrammate.

Dipendenze sensibili alla latenza

Uno dei motivi principali delle migrazioni fallite sono le dipendenze sensibili alla latenza. La mancata identificazione delle dipendenze sensibili alla latenza può introdurre problemi di prestazioni che si traducono in tempi di risposta o tempi di transazione inaccettabili. Ad esempio, in genere un'applicazione sposta il database e i server delle applicazioni nel cloud contemporaneamente perché comunicano tra loro frequentemente e richiedono un tempo di risposta inferiore al millisecondo che hanno quando entrambi si trovano nello stesso data center. È probabile che lo spostamento del solo database nel cloud introduca molti secondi di latenza in tali transazioni, con un impatto significativo sulle prestazioni dell'applicazione. Questo vale anche per le applicazioni che dipendono fortemente l'una dall'altra e devono trovarsi nello stesso data center per funzionare adeguatamente.

Comprendere e risolvere le dipendenze delle applicazioni è quindi di primaria importanza nella pianificazione delle migrazioni. Le applicazioni e i servizi che dipendono l'uno dall'altro devono essere identificati in modo che possano essere migrati insieme.

Servizi IT condivisi

Dopo che un carico di lavoro è nel cloud, ha bisogno di una varietà di servizi per funzionare ed essere mantenuto in modo corretto e sicuro. Ciò include una zona di atterraggio, un perimetro di rete e di sicurezza, autenticazione, patch, scanner di sicurezza, strumenti di gestione dei servizi IT, backup, host bastion e altre risorse. Senza questi servizi, i carichi di lavoro potrebbero non funzionare correttamente e sarebbero costretti a tornare alla posizione originale.

Aggiornamenti della configurazione

Nella maggior parte dei casi, è necessario apportare diverse modifiche alla configurazione affinché un carico di lavoro funzioni correttamente dopo che il carico di lavoro è stato spostato nel cloud. Queste modifiche alla configurazione sono spesso associate alle seguenti dipendenze del carico di lavoro:

• Regole del firewall

• Consenti elenchi

• Record DNS

• Stringhe di connessione

Se non si effettuano gli aggiornamenti di configurazione appropriati, il carico di lavoro, i relativi utenti e i sistemi dipendenti potrebbero non riuscire a comunicare tra loro. Potrebbe essere possibile risolvere questi problemi entro la finestra di interruzione, ma le modifiche in questo momento possono richiedere molto tempo o richiedere registrazioni di modifiche che non possono essere soddisfatte in tempo.

Test funzionali delle applicazioni

Un'altra sfida per le migrazioni su larga scala è la necessità di test funzionali delle applicazioni. Ciò è di particolare importanza poiché molte organizzazioni si affidano ai team applicativi per identificare dipendenze sensibili alla latenza, servizi IT condivisi o aggiornamenti di configurazione necessari. Idealmente, un team applicativo fornisce un piano di test scritto o automatico da eseguire durante la finestra di manutenzione del cutover per verificare che l'applicazione sia completamente funzionante con prestazioni accettabili. Per ridurre al minimo la finestra di manutenzione del cutover, il test dovrebbe essere completato entro 30 minuti.

Strumenti per l'individuazione delle dipendenze delle applicazioni

La determinazione delle dipendenze tra le applicazioni è fondamentale per il successo delle migrazioni, sia per rilevare le dipendenze sensibili alla latenza che gli elementi di configurazione della connettività. Nel marketplace sono disponibili diversi strumenti per scoprire le dipendenze, comeServizio di individuazione delle applicazioni(agente e strumento senza agenti) eRidimensiona il cloud(strumento basato su agenti).

Quando scegli uno strumento per l'individuazione delle dipendenze delle applicazioni, considera quanto segue:

• Durata— Ti consigliamo di utilizzare gli strumenti di rilevamento per un periodo di tempo sufficiente a registrare eventi specifici dell'applicazione, come picchi noti, fine mese e altri eventi. Il minimo consigliato è di 30 giorni.

• Attivo (basato su agenti)— Gli strumenti di rilevamento attivo delle dipendenze sono spesso incorporati nel kernel del sistema operativo e acquisiscono tutte le transazioni. Tuttavia, questo è in genere il metodo più costoso e dispendioso in termini di tempo.

• Passivo (senza agenti)— Gli strumenti di rilevamento passivo delle dipendenze sono molto più economici e veloci da implementare, ma rischiano di perdere alcune connessioni meno utilizzate.

• Conoscenze istituzionali— Sebbene gli strumenti di rilevamento delle applicazioni forniscano informazioni più dettagliate e accurate, la maggior parte delle organizzazioni si affida ai propri team applicativi e alle proprie conoscenze istituzionali per scoprire le dipendenze delle applicazioni. I team applicativi sono spesso ben informati sulle dipendenze sensibili alla latenza, ma non è raro che trascurino alcuni dettagli come le impostazioni di configurazione della connettività, le regole del firewall o i requisiti relativi agli elenchi consentiti da un partner. È possibile utilizzare le conoscenze istituzionali per migliorare l'individuazione delle dipendenze delle applicazioni, ma si consiglia di considerare e mitigare anche i rischi connessi. Ad esempio, esiste il rischio di perdere elementi di configurazione della connettività o dipendenze sensibili alla latenza se ci si affida solo alla conoscenza dei team applicativi. Ciò potrebbe causare interruzioni o migrazioni non riuscite. Per mitigare questo rischio, si consiglia di eseguire test funzionali dettagliati dell'applicazione.