Individuazione dell'ambiente Windows

Con le tecnologie attualmente disponibili, ad esempio AWS Application Migration Service, trasferire Windows Server, Linux e altri sistemi operativi basati su x86 e i relativi carichi di lavoro AWS è abbastanza semplice. Far funzionare correttamente questi carichi di lavoro e farlo su larga scala, tuttavia, presenta una serie di sfide diverse. Questa sezione ha lo scopo di identificare le considerazioni sulla migrazione che possono consentirti di migrare in modo rapido, sicuro e senza intoppi i tuoi carichi di lavoro Microsoft.

Valutazione

Sebbene sia possibile «forzare» le migrazioni più piccole (ad esempio 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 al successo di una migrazione su larga scala ed è possibile utilizzare il Migration Readiness Assessment (MRA) per identificare le aree da considerare su cui concentrarsi.

Architettura aziendale

Maggiore è il debito tecnologico nell'ambiente, più è difficile migrare. Organizations con programmi di architettura aziendale funzionanti 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). Ciò 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 è inoltre più difficile per le versioni precedenti e non supportate.

Standardizzazione e gestione della configurazione

La standardizzazione dell'ambiente è un altro fattore da considerare. Organizations che dispongono di ambienti costruiti a mano e mantenuti sono considerate più simili agli animali domestici. Ogni sistema è unico e le combinazioni di configurazione possibili sono molte più numerose rispetto a quelle che sarebbero possibili utilizzando immagini standardizzate, infrastrutture come codice (IaC) o pipeline di integrazione continua e distribuzione continua (CI/CD).

Ad esempio, è consigliabile ricostruire un tipico server Web utilizzando IaC o almeno utilizzare strumenti di gestione della configurazione (come PuppetCI/CD when migrating, as opposed to manually migrating the individual server. It's also a best practice to store all persistent data in a datastore such as a database, file share, or repository. If systems aren't rebuilt using IaC or CI/CD, Chef o Ansible) per standardizzare i server di cui dispongono.

Dati validi

I buoni dati sono anche un fattore chiave per migrazioni di successo. I dati accurati relativi ai server attuali e ai relativi metadati sono essenziali per l'automazione e la pianificazione. La mancanza di dati affidabili aumenta la difficoltà nella pianificazione di una migrazione. Esempi di dati validi includono un inventario accurato dei server, delle applicazioni sui server, del software sui server con le versioni, il numeroCPUs, la quantità di memoria e il numero di dischi. Si consiglia di acquisire tutti i dati necessari ai pianificatori onerosi per la pianificazione o tutti i dati che si prevede di utilizzare come parte dell'automazione del processo di migrazione.

Automazione

L'automazione è essenziale per le migrazioni su larga scala. Esempi di automazione includono l'installazione dell'agente e l'aggiornamento delle versioni software delle utilità necessarie per l'automazione, ad esempio. NEToppure PowerShell, caricando o aggiornando software AWS come l' AWS Systems Manager agente (SSMagente), CloudWatch l'agente Amazon o altro software di backup o gestione necessario per l'esecuzione 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:

• Utilizzate la pianificazione a ondate per organizzare i server in ondate in base alle vostre dipendenze e priorità.

• Utilizzate la pianificazione settimanale (fino al cutover) per comunicare con i team addetti alle applicazioni e identificare la reteDNS, il firewall e altri dettagli da risolvere durante il cutover.

• Utilizzate una hour-to-hourpianificazione dettagliata (intorno al limite effettivo) per descrivere la finestra di manutenzione massima.

• Utilizzate i criteri go/no-go per descrivere in quali circostanze un'applicazione verrà considerata interrotta AWS o dovrà essere reindirizzata alla posizione di origine.

• Utilizzate le attività di pulizia come attività successive che devono essere completate. Queste attività possono svolgersi al di fuori della finestra di manutenzione ordinaria o dopo il completamento di hypercare. Le attività di pulizia includono la verifica dei backup e di vari agenti, la rimozione dell'agente Application Migration Service da un server o la rimozione del server di origine e delle risorse associate.

Mobilitazione

Durante la fase di mobilitazione, è importante scoprire il maggior numero possibile di complessità e variazioni dell'organizzazione in modo da poterne tenere conto durante la pianificazione della migrazione. Idealmente, è possibile evitare di affrontare tali complessità e variazioni durante la finestra limite di manutenzione e prevenire eventuali guasti.

Sfide delle migrazioni su larga scala

Gli errori di migrazione si verificano quando una o più applicazioni sono state trasferite ai nuovi ambienti e i requisiti prestazionali o funzionali non possono essere soddisfatti entro la finestra di manutenzione della migrazione. Questo costringe l'applicazione o le applicazioni a tornare nella loro posizione originale. Inoltre, è necessario eseguire il failback anche per tutte le altre applicazioni che dipendono dall'applicazione o dalle applicazioni in questione. Le migrazioni non riuscite 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 comportano tempi di risposta o 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 tempi di risposta inferiori al millisecondo 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. Ciò vale anche per le applicazioni che dipendono fortemente l'una dall'altra e che devono trovarsi nello stesso data center per funzionare in modo adeguato.

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 da poter essere migrati insieme.

Servizi IT condivisi

Dopo che un carico di lavoro è nel cloud, necessita di una varietà di servizi per funzionare e essere mantenuto in modo corretto e sicuro. Ciò include una landing zone, una rete e un perimetro 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 loro posizione originale.

Aggiornamenti della configurazione

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

• Regole del firewall

• Elenchi consentiti

• DNSrecord

• stringhe di connessione

Se non apporti gli aggiornamenti di configurazione corretti, 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 record di modifiche che non possono essere soddisfatti 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 automatizzato da eseguire durante la finestra di manutenzione intermedia per verificare che l'applicazione sia perfettamente funzionante con prestazioni accettabili. Per ridurre al minimo la finestra di manutenzione, il test dovrebbe poter 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 il rilevamento delle dipendenze sensibili alla latenza che per gli elementi di configurazione della connettività. Sul mercato sono disponibili diversi strumenti per scoprire le dipendenze, ad esempio (strumento con agente e senza agente AWS Application Discovery Service) e Cloudamize (strumento basato su agenti).

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

• Durata: si consiglia di utilizzare gli strumenti di rilevamento per un periodo di tempo sufficiente a rilevare eventi specifici dell'applicazione, ad esempio 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 agente): gli strumenti di rilevamento passivo delle dipendenze sono molto più economici e veloci da implementare, ma rischiano di perdere alcune connessioni meno utilizzate.

• Conoscenza istituzionale: sebbene gli strumenti di scoperta 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 a conoscenza delle 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 degli elenchi di autorizzazioni forniti da un partner. Puoi utilizzare le conoscenze istituzionali per migliorare l'individuazione delle dipendenze delle applicazioni, ma ti consigliamo anche di considerare e mitigare i rischi connessi. Ad esempio, c'è il rischio di perdere elementi di configurazione della connettività o dipendenze sensibili alla latenza se ci si affida solo alle conoscenze dei team applicativi. Ciò potrebbe causare interruzioni o migrazioni non riuscite. Per mitigare questo rischio, si consiglia di eseguire test funzionali dettagliati delle applicazioni.