Rehost con Azure Migrate (Lift and Shift)

Rehost — comunemente chiamato Lift and Shift — è la strategia di migrazione che consiste nello spostare una VM dall'ambiente locale ad Azure senza apportare modifiche al sistema operativo, ai file binari dell'applicazione o ai dati. Lo strumento Migration and Modernisation di Azure Migrate (in precedenza Server Migration) automatizza questo processo replicando i dati dei dischi in Azure e completando quindi il passaggio con tempi di inattività minimi. Lift and Shift è ideale per le applicazioni che non possono essere sottoposte facilmente a refactoring o che devono essere migrate entro scadenze ravvicinate.

Prima di avviare la replica è necessario: completare il rilevamento e la valutazione per disporre dei consigli sullo SKU della VM di destinazione, creare le risorse Azure di destinazione (gruppo di risorse, rete virtuale e subnet) e verificare che l'appliance Azure Migrate sia integra. Per le origini VMware, l'appliance deve disporre delle autorizzazioni di lettura per vCenter e la VM guest deve essere raggiungibile via rete dall'appliance. Scarichi e registri il software Replication Provider se sta eseguendo la migrazione da Hyper-V o da server fisici.

La replica copia tutti i dati dei dischi dalla VM di origine a un account di archiviazione della cache gestito da Azure, quindi prepara i dati in modo asincrono in Azure. Nel portale Azure Migrate, acceda a Replicate, selezioni le VM di origine, esegua il mapping con lo SKU della VM Azure consigliato e scelga la rete virtuale di destinazione. Il tempo della replica iniziale dipende dalle dimensioni del disco e dalla larghezza di banda: un disco da 100 GB su una connessione da 100 Mbps richiede circa 2 ore per la sincronizzazione iniziale.

Dopo la copia dell'immagine iniziale del disco, Azure Migrate passa alla replica delta: vengono inviati solo i blocchi del disco modificati, mantenendo la copia in Azure sincronizzata quasi in tempo reale con l'origine locale. Durante questa fase la VM continua a essere eseguita nell'ambiente locale. Nel portale è possibile monitorare lo stato della replica, il ritardo RPO e le velocità di trasferimento dei dati. In genere, entro 24 ore dal completamento della sincronizzazione iniziale, la replica delta si stabilizza su un ritardo di appena pochi minuti.

Prima di trasferire il traffico di produzione, esegua sempre una migrazione di test. Questa operazione avvia la VM replicata in Azure in una rete virtuale di test isolata, priva di connettività ai sistemi di produzione. È possibile verificare che il sistema operativo si avvii, che i servizi vengano avviati e che le funzionalità dell'applicazione funzionino come previsto. Le migrazioni di test non interrompono la replica locale: la VM di origine continua a essere eseguita. Al termine del test, elimini le risorse di test dal portale per evitare addebiti non necessari.

Il passaggio è il passaggio finale che trasferisce il traffico di produzione dall'ambiente locale ad Azure. Durante il passaggio, la VM di origine viene resa inattiva (oppure arrestata manualmente), le eventuali modifiche delta rimanenti vengono applicate alla replica Azure e la nuova VM Azure viene avviata. Poiché si tratta di una migrazione a livello di archiviazione, il passaggio è in genere molto rapido: per la maggior parte delle VM richiede meno di 10 minuti. Pianifichi il passaggio durante una finestra di manutenzione e ne informi anticipatamente i responsabili delle applicazioni.

Nel portale Azure Migrate, faccia clic su Migrate per il server selezionato. Le verrà chiesto se desidera arrestare la VM locale prima della migrazione (operazione consigliata per evitare la perdita di dati). Azure applica il delta finale, crea la VM Azure e contrassegna la migrazione come completata. È quindi necessario aggiornare i record DNS, i backend del bilanciatore del carico o le stringhe di connessione dell'applicazione affinché puntino al nuovo indirizzo IP privato o FQDN Azure, in modo che i client inizino a usare la VM Azure.

Dopo il passaggio, esegua questi controlli post-migrazione: integrità dell'applicazione (carichi tutte le pagine dell'applicazione ed esegua i test di base), connettività (verifichi che la VM Azure possa raggiungere i database e i servizi dipendenti), monitoraggio (installi l'agente Azure Monitor e abiliti la diagnostica) e backup (iscriva la VM ad Azure Backup). Se vengono rilevati problemi, è possibile riavviare la VM di origine locale: rimane intatta finché non viene esplicitamente dismessa.

Quando la VM migrata è stabile in Azure e gli stakeholder hanno approvato il risultato, è possibile dismettere la VM di origine locale. In Azure Migrate, selezioni Complete Migration per chiudere la replica. Questa operazione non arresta automaticamente la VM locale: è necessario spegnerla e recuperare l'hardware seguendo il normale processo di gestione degli asset IT. La dismissione riduce i costi dell'infrastruttura locale e avvicina l'organizzazione a un modello operativo interamente cloud.

Per le migrazioni di grandi dimensioni che coinvolgono centinaia di VM, Azure Migrate supporta le operazioni in blocco tramite importazione da CSV. È necessario preparare un CSV contenente ogni VM di origine, lo SKU di destinazione, il gruppo di risorse di destinazione e la rete virtuale, quindi caricarlo per avviare simultaneamente la replica di tutte le VM. I gruppi di migrazione consentono di stabilire la sequenza della replica e del passaggio, in modo che i livelli applicativi dipendenti (database, applicazione, Web) vengano migrati nell'ordine corretto all'interno della stessa finestra di manutenzione.

Presti attenzione a questi problemi comuni di Lift and Shift: la crittografia del disco di avvio nelle VM Linux potrebbe impedire l'avvio in Azure (utilizzi Azure Disk Encryption dopo la migrazione); gli indirizzi IP statici codificati nelle configurazioni delle app devono essere aggiornati con gli IP privati o i nomi DNS di Azure; le regole del firewall locale che fanno riferimento all'IP del server potrebbero dover essere replicate in un NSG Azure; infine, le impostazioni del fuso orario nelle VM Windows potrebbero causare cambiamenti nel comportamento delle applicazioni nell'ambiente UTC di Azure.

Verifichi la Sua comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) trattati in questa lezione.

In questa lezione ha imparato che: il flusso di migrazione Rehost comprende la replica, la sincronizzazione delta, la migrazione di test e il passaggio; la migrazione di test convalida la VM in una rete isolata prima della messa in produzione; infine, i passaggi post-migrazione (monitoraggio, backup, aggiornamento DNS) sono essenziali prima di dismettere le risorse locali. Nel prossimo argomento esamineremo le procedure consigliate per la migrazione dei database in Azure.