Pianificazione della migrazione delle risorse IaaS dal modello di distribuzione classica ad Azure Resource Manager

  • Articolo

Si applica a: ✔️ Macchine virtuali ✔️ Linux Windows

Importante

Oggigiorno, circa il 90% delle macchine virtuali IaaS usa Azure Resource Manager. A partire dal 28 febbraio 2020, le macchine virtuali classiche sono state deprecate e verranno ritirate completamente il 6 settembre 2023. Altre informazioni su questa deprecazione e sui relativi effetti sull'utente.

Anche se Azure Resource Manager offre numerose funzionalità straordinarie, è fondamentale pianificare il percorso di migrazione per assicurarsi che le cose vadano senza problemi. Dedicare tempo alla pianificazione garantisce che non si verifichino problemi durante l'esecuzione delle attività di migrazione.

Nota

Alle linee guida seguenti hanno fornito un importante contributo il team Azure Customer Advisory e gli architetti delle soluzioni cloud che lavorano con i clienti per la migrazione di ambienti di grandi dimensioni. È consigliabile controllare questo documento di tanto in tanto perché verrà aggiornato mano a mano che emergeranno nuovi modelli di successo.

Il percorso di migrazione include quattro fasi generali:

Fasi di migrazione

Piano

Considerazioni tecniche e compromessi

In base alla quantità di requisiti tecnici, alle aree geografiche e alle procedure operative, è necessario considerare quanto segue:

  1. Perché si vuole usare Azure Resource Manager per l'organizzazione? Quali sono i motivi aziendali della scelta della migrazione?
  2. Quali sono i motivi tecnici della scelta di Azure Resource Manager? Che cosa si vuole usare (se presenti) altri servizi di Azure?
  3. Quale applicazione (o set di macchine virtuali) è inclusa nella migrazione?
  4. Quali scenari sono supportati con l'API di migrazione? Esaminare le funzionalità e configurazioni non supportate.
  5. I team operativi supporteranno le applicazioni/macchine virtuali sia nel modello di distribuzione classica che in Azure Resource Manager?
  6. Come cambieranno eventualmente i processi di distribuzione, gestione, monitoraggio e report delle VM con Azure Resource Manager? Gli script di distribuzione devono essere aggiornati?
  7. Qual è il piano di comunicazione per avvisare gli stakeholder (utenti finali, proprietari di applicazioni e proprietari dell'infrastruttura)?
  8. A seconda della complessità dell'ambiente, è previsto un periodo di manutenzione in cui l'applicazione non sarà disponibile per gli utenti finali e i proprietari dell'applicazione? In questo caso, per quanto tempo?
  9. Come è organizzato il piano di formazione per l'addestramento e la conoscenza di Azure Resource Manager per gli stakeholder?
  10. Come è organizzato il piano di gestione del progetto o del programma per la migrazione?
  11. Quali sono le sequenze temporali della migrazione di Azure Resource Manager e gli altri piani d'azione correlati alla tecnologia? Sono allineati in modo ottimale?

Modelli di successo

I clienti di successo hanno piani dettagliati in cui le domande precedenti sono discusse, documentate e organizzate. Assicurarsi che i piani di migrazione vengano dettagliatamente comunicati agli sponsor e agli stakeholder. Acquisire familiarità con le opzioni di migrazione; è consigliabile leggere i documenti sulla migrazione qui di seguito.

Errori da evitare

  • Errori di pianificazione. I passaggi tecnici della migrazione sono collaudati e il risultato è prevedibile.
  • Si presuppone che l'API per la migrazione supportata dalla piattaforma terrà in considerazione tutti gli scenari. Leggere la sezione funzionalità e configurazioni non supportate per comprendere quali sono gli scenari supportati.
  • Nessuna pianificazione di potenziali interruzioni delle applicazioni per gli utenti finali. Pianificare un buffer sufficiente per informare adeguatamente gli utenti finali della potenziale non disponibilità delle applicazioni.

Test di laboratorio

Replicare l'ambiente ed eseguire una migrazione di test

Nota

La replica esatta dell'ambiente esistente viene eseguita tramite uno strumento creato dalla community che non è ufficialmente supportato dal supporto tecnico Microsoft. È pertanto un passaggio facoltativo ma è il modo migliore per individuare i problemi senza modificare gli ambienti di produzione. Se non è possibile usare uno strumento creato dalla community, leggere le raccomandazioni su convalida/preparazione/interruzione di prova qui di seguito.

L'esecuzione di un test di laboratorio dello scenario esatto ossia calcolo, rete e archiviazione è il modo migliore per garantire una migrazione senza problemi. In modo da garantire:

  • Un laboratorio completamente separato o un ambiente non di produzione esistente su cui eseguire test. È consigliabile un laboratorio totalmente separato che possa essere migrato ripetutamente e modificato in modo distruttivo. Gli script per raccogliere/idratare i metadati delle sottoscrizioni reali sono elencati di seguito.

  • È consigliabile creare il laboratorio in una sottoscrizione separata. Il motivo è che il lab verrà ripetutamente rimosso e avere una sottoscrizione separata riduce il rischio di eliminare accidentalmente componenti reali.

    Questa operazione si può fare usando lo strumento AsmMetadataParser. Per altre informazioni su questo strumento vedere qui

Modelli di successo

Di seguito sono elencati i problemi rilevati in molte migrazioni di grandi dimensioni. Questo non è un elenco completo e per altri dettagli è consigliabile fare riferimento alle funzionalità e alle configurazioni non supportate . Questi problemi tecnici potrebbero anche non verificarsi, ma se vengono risolti prima della migrazione, questa sarà più semplice.

  • Eseguire una convalida/preparazione/interruzione dell'esecuzione: questo è forse il passaggio più importante per garantire il successo della migrazione da versione classica ad Azure Resource Manager. L'API di migrazione prevede tre passaggi principali: Convalida, Preparazione e Commit. La convalida leggerà lo stato dell'ambiente di distribuzione classica e restituirà come risultato tutti i problemi. Tuttavia, poiché alcuni problemi potrebbero esistere nello stack di Resource Manager di Azure, Validate non intercetta tutti gli elementi. Il passaggio successivo nel processo di migrazione, la preparazione, consente di rilevare questi problemi. La preparazione sposta i metadati dalla versione classica ad Azure Resource Manager, ma non eseguirà il commit dello spostamento e non rimuoverà o modificherà alcun elemento sul lato classico. L'esecuzione a secco comporta la preparazione della migrazione, quindi l'interruzione (non il commit) delle migrazioni viene preparata. L'obiettivo di convalida/preparazione/interruzione di prova è visualizzare tutti i metadati nello stack Azure Resource Manager, esaminarli (a livello di codice o nel portale), verificare che la migrazione avvenga correttamente e risolvere i problemi tecnici. Inoltre si avrà un'idea della durata della migrazione in modo che sia possibile pianificare di conseguenza i tempi di inattività. Una convalida/preparazione/interruzione non causa tempi di inattività dell'utente; pertanto, è non indipendente dall'utilizzo dell'applicazione.

    • Gli elementi seguenti dovranno essere risolti prima dell'esecuzione secca, ma anche un test di esecuzione a secco scarica questi passaggi di preparazione in modo sicuro se non sono stati superati. Durante la migrazione al livello enterprise, è stato rilevato che la prova è un modo sicuro e prezioso per semplificare la migrazione.
    • Nella fase di preparazione il piano di controllo, ossia le operazioni di gestione di Azure, verrà bloccato per tutta la rete virtuale e pertanto non sarà possibile apportare modifiche ai metadati delle macchine virtuali durante la convalida/preparazione/interruzione. A parte questo, tutte le funzioni delle applicazioni, ad esempio l'uso del desktop remoto, le macchine virtuali e così via, non saranno interessate. Gli utenti delle macchine virtuali non sapranno che viene eseguita l'esecuzione a secco.

  • Circuiti ExpressRoute e VPN. Attualmente i gateway ExpressRoute con collegamenti di autorizzazione non possono essere migrati senza tempi di inattività. Per una soluzione vedere Eseguire la migrazione di circuiti ExpressRoute e delle reti virtuali associate dalla distribuzione classica al modello di distribuzione Resource Manager.

  • Estensioni VM - Le estensioni macchina virtuale sono potenzialmente uno degli ostacoli principali della migrazione di macchine virtuali in esecuzione. Pianificare tenendo conto che la correzione delle estensioni VM potrebbe richiedere fino a 1-2 giorni. È necessario un agente Azure funzionante per segnalare lo stato delle estensioni VM delle VM in esecuzione. Se per una VM in esecuzione viene restituito uno stato non valido, la migrazione si arresta. L'agente stesso non deve essere in grado di funzionare per abilitare la migrazione, ma se le estensioni esistono nella macchina virtuale, sarà necessario che sia un agente funzionante che la connettività Internet in uscita (con DNS) sia per la migrazione andare avanti.

    • Se la connettività a un server DNS viene persa durante la migrazione, tutte le estensioni della macchina virtuale ad eccezione di BGInfo v1.* devono essere rimosse prima della preparazione della migrazione e successivamente aggiunte nuovamente alla macchina virtuale dopo la migrazione di Azure Resource Manager. Questo vale solo per le VM in esecuzione. Se le macchine virtuali vengono arrestate deallocate, non è necessario rimuovere le estensioni della macchina virtuale. Nota: Molte estensioni come diagnostica di Azure e il monitoraggio di Defender for Cloud si reinstalleranno dopo la migrazione, quindi la loro rimozione non è un problema.

    • Assicurarsi inoltre che i gruppi di sicurezza di rete non limitino l'accesso Internet in uscita. Questa situazione può verificarsi con alcune configurazioni di Gruppi di sicurezza di rete. Per la migrazione delle estensioni VM ad Azure Resource Manager è necessario l'accesso a Internet in uscita e DNS.

    • Esistono due versioni dell'estensione BGInfo: v1 e v2. Se la macchina virtuale è stata creata utilizzando il portale di Azure o PowerShell, è probabile che abbia l'estensione v1. Questa estensione non deve essere rimossa e verrà ignorata (non eseguita la migrazione) dall'API di migrazione. Tuttavia, se la macchina virtuale classica è stata creata con il nuovo portale di Azure, probabilmente avrà la versione v2 basata su JSON di BGInfo, che è possibile migrare ad Azure Resource Manager se l'agente funziona e ha accesso a Internet in uscita e DNS.

    • Opzione di correzione 1. Se si conosce che le macchine virtuali non avranno accesso a Internet in uscita, un servizio DNS funzionante e gli agenti di Azure in uso nelle macchine virtuali, quindi disinstallare tutte le estensioni della macchina virtuale come parte della migrazione prima di Preparare, quindi reinstallare le estensioni della macchina virtuale dopo la migrazione.

    • Opzione di correzione 2. Se le estensioni VM sono un ostacolo troppo grande, un'altra opzione è quella di arrestare/deallocare tutte le macchine virtuali prima della migrazione. Eseguire la migrazione delle VM deallocate, quindi riavviarle in Azure Resource Manager. Il vantaggio è che le estensioni VM verranno migrate. Lo svantaggio è che tutti gli indirizzi IP virtuali pubblici andranno persi con esito potenzialmente negativo e ovviamente le VM si arresteranno causando un impatto maggiore sulle applicazioni in funzione.

      Nota

      Se un Microsoft Defender per i criteri cloud viene configurato in base alle macchine virtuali in esecuzione di cui viene eseguita la migrazione, i criteri di sicurezza devono essere arrestati prima di rimuovere le estensioni, altrimenti l'estensione di monitoraggio della sicurezza verrà reinstallata automaticamente nella macchina virtuale dopo la rimozione.

  • Set di disponibilità. Per una rete virtuale (vNet) da migrare ad Azure Resource Manager, è necessario che le macchine virtuali contenute nel modello di distribuzione classica, ossia il servizio cloud, siano tutte in un set di disponibilità oppure che nessuna di esse sia in un set di disponibilità. La presenza di più set di disponibilità nel servizio cloud non è compatibile con Azure Resource Manager e interromperà la migrazione. Inoltre, non è possibile usare alcune macchine virtuali in un set di disponibilità e alcune macchine virtuali non in un set di disponibilità. Per risolvere questo problema, è necessario correggere o rimezionare il servizio cloud. Pianificare di conseguenza, in quanto questa operazione potrebbe richiedere molto tempo.

  • Distribuzioni di ruoli web/ruolo di lavoro: Servizi cloud contenenti ruoli web e di lavoro non possono eseguire la migrazione ad Azure Resource Manager. I ruoli Web/di lavoro devono essere rimossi dalla rete virtuale prima di avviare la migrazione. Una soluzione tipica è quella di spostare le istanze del ruolo Web/di lavoro in una rete virtuale classica separata che è collegata anche a un circuito ExpressRoute o di migrare il codice a servizi app PaaS più recenti (questa discussione va oltre l'ambito di questo documento). Nel primo caso di ridistribuzione, creare una nuova rete virtuale classica, spostare/ridistribuire i ruoli Web/di lavoro nella nuova rete virtuale, quindi eliminare le distribuzioni dalla rete virtuale da spostare. Non è necessaria alcuna modifica nel codice. La nuova funzionalità Peering reti virtuali può essere usata per eseguire il peering della rete virtuale classica contenente i ruoli Web/di lavoro e di altre reti virtuali nella stessa area di Azure, ad esempio la rete virtuale che si sta migrando, dopo il completamento della migrazione della rete virtuale poiché le reti virtuali sottoposte a peering non possono essere migrate, garantendo le stesse funzionalità senza perdita di prestazioni e senza problemi di larghezza di banda/latenza. Con l'aggiunta del Peering reti virtuali le distribuzioni del ruolo Web/di lavoro ora possono essere facilmente ridotte e non bloccano la migrazione ad Azure Resource Manager.

  • Le quote di Azure Resource Manager - Le aree di Azure hanno di quote/limiti separati per il modello di distribuzione classica e per Azure Resource Manager. Anche se in uno scenario di migrazione non è usato nuovo hardware in quanto si stanno scambiando macchine virtuali esistenti dalla distribuzione classica ad Azure Resource Manager, le quote di Azure Resource Manager devono comunque avere una capacità sufficiente prima di avviare la migrazione. Di seguito sono elencati i principali limiti che causano problemi. Aprire un ticket di supporto di quota per aumentare i limiti.

    Nota

    Questi limiti devono essere aumentati nella stessa area dell'ambiente di cui eseguire la migrazione.

    • Interfacce di rete

    • Servizi di bilanciamento del carico

    • Indirizzi IP pubblici

    • Indirizzi IP pubblici statici

    • Core

    • Gruppi di sicurezza di rete

    • Tabelle di route

      È possibile controllare le quote correnti Azure Resource Manager usando i seguenti comandi con la versione più recente dell'interfaccia della riga di comando di Azure.

      Calcolo(memoria centrale, set di disponibilità)

      az vm list-usage -l <azure-region> -o jsonc

      Rete(reti virtuali, indirizzi IP statici, indirizzi IP pubblici, gruppi di sicurezza di rete, interfacce di rete, bilanciamenti del carico, tabelle route)

      az network list-usages -l <azure-region> -o jsonc

      Archiviazione(account di archiviazione)

      az storage account show-usage

  • Limiti di limitazione delle API di Azure Resource Manager: se si dispone di un ambiente sufficiente (ad esempio > 400 macchine virtuali in una rete virtuale), è possibile raggiungere i limiti di limitazione delle API predefiniti per le scritture (attualmente 1200 scritture/ora) in Azure Resource Manager. Prima di iniziare la migrazione, è necessario generare un ticket di supporto per aumentare questo limite per la sottoscrizione.

  • Il provisioning ha raggiunto il timeout dello stato della VM: se lo stato di qualsiasi VM è Timeout provisioning, questo problema deve essere risolto prima della migrazione. L'unico modo per eseguire questa operazione è con il tempo di inattività mediante il deprovisioning/nuovo provisioning della macchina virtuale: eliminarla, mantenere il disco e ricreare la macchina virtuale.

  • Stato macchina virtuale RoleStateUnknown : se la migrazione si arresta a causa di un messaggio di errore sconosciuto dello stato del ruolo , controllare la macchina virtuale usando il portale e assicurarsi che sia in esecuzione. Questo errore in genere scompare da solo (nessuna correzione necessaria) dopo alcuni minuti, è spesso temporaneo e si verifica durante un'operazione di avvio, arresto o riavvio di una macchina virtuale. Procedura consigliata: ritentare nuovamente la migrazione dopo alcuni minuti.

  • Cluster di infrastruttura non esiste : in alcuni casi, alcune macchine virtuali non possono essere migrate per vari motivi dispari. Uno di questi casi noti è se la macchina virtuale è stata creata di recente (entro l'ultima settimana) ed è successo di atterrare un cluster di Azure che non è ancora dotato per i carichi di lavoro di Azure Resource Manager. Verrà visualizzato un errore che indica che il cluster di infrastruttura non esiste e la macchina virtuale non può essere migrata. Di solito è sufficiente attendere un paio di giorni per risolvere il problema in quanto il cluster verrà abilitato per Azure Resource Manager. Una soluzione immediata è stop-deallocate la VM, quindi proseguire con la migrazione e riavviare la VM in Azure Resource Manager dopo la migrazione.

Errori da evitare

  • Non prendere collegamenti e omettere le migrazioni di esecuzione asciutta convalida/preparazione/interruzione.
  • La maggior parte, se non tutti i potenziali problemi, verrà rilevata durante i passaggi di convalida/preparare/interruzione.

Migrazione

Considerazioni tecniche e compromessi

Ora si è pronti perché sono stati elaborati i problemi noti con l'ambiente.

Per le migrazioni reali, considerare quanto segue:

  1. Pianificare la rete virtuale, la più piccola unità di migrazione, con priorità crescente. Iniziare con le reti virtuali semplici e proseguire con le reti virtuali più complesse.
  2. La maggior parte dei clienti avrà ambienti non di produzione e di produzione. Pianificare per ultimo l'ambiente di produzione.
  3. (FACOLTATIVO) Pianificare un tempo di inattività di manutenzione con molto buffer nel caso in cui si verifichino problemi imprevisti.
  4. Comunicare e allinearsi con i team di supporto nel caso in cui si verifichino problemi.

Modelli di successo

Le indicazioni tecniche fornite dalla sezione Test Lab in precedenza devono essere considerate e risolte prima della migrazione reale. Grazie a test adeguati, la migrazione non è un avvenimento eccezionale. Per gli ambienti di produzione, potrebbe essere utile disporre di ulteriore supporto, ad esempio un partner Microsoft attendibile o i servizi Microsoft Premier.

Errori da evitare

Test incompleti possono causare problemi e ritardare la migrazione.

Oltre la migrazione

Considerazioni tecniche e compromessi

Ora che si è in Azure Resource Manager, ottimizzare la piattaforma. Leggere la sezione Panoramica di Gestione risorse di Microsoft Azure per scoprire i vantaggi aggiuntivi.

Ecco alcuni aspetti da considerare:

  • Unire la migrazione ad altre attività. La maggior parte dei clienti opta per una finestra di manutenzione dell'applicazione. In questo caso, si potrebbe usare questo periodo di inattività per abilitare altre funzionalità di Azure Resource Manager come la crittografia e la migrazione a Managed Disks.
  • Rivedere i motivi tecnici e aziendali per Azure Resource Manager; abilitare i servizi aggiuntivi disponibili solo in Azure Resource Manager che si applica all'ambiente.
  • Aggiornare l'ambiente con servizi PaaS.

Modelli di successo

Decidere quali servizi si desidera abilitare ora in Azure Resource Manager. Molti clienti ritengono efficace quanto segue per i propri ambienti Azure:

Errori da evitare

Tenere a mente il motivo per cui è stata eseguita la migrazione dalla distribuzione classica ad Azure Resource Manager. Quali sono i motivi aziendali originali? Sono stati raggiunti i motivi aziendali?

Passaggi successivi