Eseguire la migrazione dei carichi di lavoro a soluzione Azure VMware

Questo articolo fornisce indicazioni per aiutare i decision maker a definire la strategia di migrazione per soluzione Azure VMware, incluse le fasi di pianificazione, esecuzione e rimozione delle autorizzazioni.

Diagramma che mostra il processo di microsoft Cloud Adoption Framework per l'adozione di soluzione Azure VMware.

soluzione Azure VMware fornisce un percorso strutturato per la migrazione di carichi di lavoro basati su VMware a Azure con modifiche minime dell'applicazione. Il successo dipende da più che dallo spostamento di macchine virtuali. Le organizzazioni necessitano di criteri di migrazione chiari, criteri di valutazione del carico di lavoro, standard di convalida e controlli di esecuzione che riducono i rischi, mantengono la continuità operativa e supportano gli obiettivi della piattaforma a lungo termine.

Raccomandazione: Definire la strategia di migrazione, l'approccio di valutazione del carico di lavoro, la sequenza di migrazione e i requisiti di convalida prima di eseguire la migrazione dei carichi di lavoro a soluzione Azure VMware.

1. Pianificazione della migrazione

Prima di iniziare a progettare qualsiasi cosa, crea un'idea chiara di ciò che devi migrare, in quale ordine e perché. Usare la metodologia del piano di Cloud Adoption Framework per valutare il patrimonio. soluzione Azure VMware adatta al meglio un approccio di rehosting, in cui sono necessarie interruzioni minime e nessuna modernizzazione a breve termine. Non è l'ambiente adatto per ogni applicazione, ed è nella fase di pianificazione che si decide.

1.1 Individuazione e inventario

Azure Migrate analizza l'ambiente vSphere locale e crea un inventario delle macchine virtuali, il relativo uso delle risorse e le relative dipendenze. Questi dati servono a definire sia il dimensionamento (quanti host sono necessari e quale tipo di host scegliere) sia la pianificazione delle ondate (quali carichi di lavoro vengono spostati insieme). Azure Migrate non effettua lo spostamento in soluzione Azure VMware. Fornisce l'evidenza per ridimensionare e sequenziare il progetto.

1.2 Strategia di migrazione

soluzione Azure VMware supporta principalmente l'approccio rehost. Le applicazioni che necessitano di un trattamento di refactoring o riprogettazione potrebbero essere meglio gestite dal calcolo nativo Azure. Registrare queste decisioni in modo che il piano rifletta le scelte intenzionali anziché quelle predefinite. Vedere Selezionare una strategia di migrazione cloud.

1.3 Valutazione del carico di lavoro

Non tutti i carichi di lavoro sono un candidato altrettanto adatto per soluzione Azure VMware. Prima di assegnare carichi di lavoro alle onde di migrazione, valutare i requisiti tecnici, le dipendenze operative e l'adattamento della piattaforma. Una valutazione strutturata consente di identificare i rischi in anticipo, convalidare l'idoneità e assicurarsi che i piani di migrazione riflettano le priorità aziendali anziché i presupposti.

1.3.1 Requisiti

Prima di assegnare un carico di lavoro a un'ondata di migrazione, valutare i requisiti tecnici, operativi e aziendali che ne influenzano il successo soluzione Azure VMware. Questa valutazione consente di determinare l'idoneità della piattaforma, identificare potenziali problemi di migrazione e fornire le informazioni necessarie per le decisioni relative al dimensionamento, alla sequenziazione e all'idoneità. Quando si valuta ogni carico di lavoro, concentrarsi su:

  • Requisiti di prestazioni: Comprendere le richieste di CPU, memoria, operazioni di I/O al secondo di archiviazione e velocità effettiva di rete. Associare questi requisiti agli SKU host di soluzione Azure VMware e ai criteri di archiviazione di vSAN, incluse la configurazione RAID e le impostazioni Failures to Tolerate (FTT).

  • Dipendenze dell'applicazione: Identificare i sistemi con cui ogni carico di lavoro comunica. Le dipendenze determinano la pianificazione dell'ondata di migrazione e se i sistemi dipendenti devono spostarsi insieme.

  • Requisiti di compatibilità: Verificare che i sistemi operativi guest e il software di terze parti siano supportati in soluzione Azure VMware. La maggior parte dei carichi di lavoro eseguiti in vSphere locale viene eseguita in soluzione Azure VMware senza modifiche, ma convalidare anziché presupporre e assicurarsi di testare l'approccio di rollback per le migrazioni problematiche.

  • Requisiti di rete: Documentare i segmenti di rete, gli indirizzi IP, le configurazioni DNS e le regole del firewall necessari per ogni carico di lavoro. Identificare i carichi di lavoro sensibili alla latenza e assicurarsi che l'architettura di rete sia ottimizzata per supportare le proprie esigenze.

1.3.2 Trattamento del carico di lavoro

La valutazione del carico di lavoro identifica le esigenze di un carico di lavoro. La gestione del carico di lavoro determina l'azione da intraprendere. I decision maker devono valutare se ogni applicazione appartiene a soluzione Azure VMware, se deve rimanere in locale o se le parti dell'applicazione sono meglio gestite da servizi nativi di Azure. Per ogni carico di lavoro, determinare:

  • Se il carico di lavoro appartiene lì. I carichi di lavoro già eseguiti correttamente in vSphere sono candidati naturali, in particolare quelli senza un piano di modernizzazione a breve termine. Per un carico di lavoro prossimo al ritiro o alla sostituzione con una soluzione SaaS, valuta se la migrazione apporta valore o se debba rimanere dov'è fino al termine del suo ciclo di vita.

  • Se ogni livello appartiene a esso. Un carico di lavoro ha spesso più di un livello, ad esempio un front-end Web e un database. È possibile eseguire le macchine virtuali dell'applicazione in soluzione Azure VMware e connetterle a servizi dati nativi Azure, ad esempio database SQL di Azure. Questa configurazione offre vantaggi del database gestito insieme ai carichi di lavoro VMware e riduce i costi dell'host e delle licenze VMware.

1.4 Preparazione della migrazione

Definire i requisiti minimi operativi, di prestazioni, sicurezza e governance che ogni carico di lavoro deve soddisfare prima di approvarlo per l'uso in produzione.

Applicare un framework di convalida coerente a ogni ondata di migrazione. Il quadro di riferimento deve definire i controlli obbligatori, i criteri di approvazione e le evidenze che i team devono fornire prima dell'approvazione della messa in esercizio. Convalidare almeno:

  • Stato della replicazione HCX

  • Instradabilità del segmento NSX

  • Stato di integrità dell'host ESXi

  • Raggiungibilità dell'identità e dell'autenticazione dal segmento di destinazione

  • Integrità dei servizi di supporto, ad esempio backup e monitoraggio

Decidere se i team devono acquisire le metriche delle prestazioni di base dall'ambiente di origine prima della migrazione. Queste misurazioni forniscono un punto di riferimento per la convalida delle prestazioni post-migrazione e l'identificazione delle regressioni.

Prima del cutover, richiedere ai team di determinare se i record DNS esterni, le configurazioni del servizio di bilanciamento del carico, gli endpoint dell'applicazione o altre dipendenze di connettività richiedono aggiornamenti. Includere tutte le modifiche necessarie nel piano di cutover delle onde per ridurre il rischio di interruzioni del servizio.

1.5 soluzione Azure VMware sequenza di migrazione

La sequenziazione di migrazione determina i carichi di lavoro che passano a soluzione Azure VMware primo, secondo e così via. Una buona pianificazione delle onde riduce il rischio ed evita interruzioni non necessarie.

  • Raggruppa per dipendenza: Usa i dati sulle dipendenze individuati durante il rilevamento per trovare gruppi di macchine virtuali che funzionano in stretta collaborazione, ad esempio un server applicativo e il relativo database. Spostarli nello stesso ciclo in modo che il traffico non attraversi la rete per ogni richiesta quando una parte attende ancora in locale.

  • Mappare le regole esistenti: Documentare eventuali regole di affinità o anti-affinità presenti nell'ambiente on-premises e pianificare come riprodurle. soluzione Azure VMware criteri di posizionamento applicano l'affinità tra macchine virtuali e host, che è importante per i vincoli di licenza, ad esempio SQL Server e per esigenze di prestazioni rigorose.

  • Sequenza per rischio: Iniziare con carichi di lavoro a basso rischio, ad esempio sistemi non di produzione o applicazioni con poche dipendenze. Il team acquisisce fiducia nel processo prima di affrontare applicazioni mission-critical. Passare a carichi di lavoro con maggiore complessità man mano che aumenta l'esperienza.

  • Allineati ai piani di estensione della rete: Basa la sequenza sulla topologia della rete locale. Quando diverse applicazioni condividono un segmento di rete, eseguirne la migrazione nella stessa onda o in onde consecutive. È quindi possibile spostare rapidamente il segmento a una rete nativa di soluzione Azure VMware e rimuovere l'estensione temporanea.

1.6 Strumenti di migrazione

Usare VMware HCX per spostare i carichi di lavoro in soluzione Azure VMware con interruzioni minime. HCX Enterprise è incluso senza costi aggiuntivi e viene installato per impostazione predefinita, che sblocca opzioni come Replication Assisted vMotion e Mobility Optimized Networking. Non è necessario usare HCX ed è anche possibile inserire carichi di lavoro fisici usando una soluzione di migrazione partner.

1.6.1 Approccio alla migrazione

vMotion sposta un carico di lavoro in esecuzione senza tempi di inattività e in genere la generazione 2 esegue prestazioni più veloci rispetto ai metodi bulk. La migrazione in blocco e quella assistita dalla replica possono essere più lente su Generation 2 oggi, quindi prevedi finestre temporali più ampie e pianifica di conseguenza le ondate di migrazione. Vedere soluzione Azure VMware considerazioni sulla progettazione del cloud privato di seconda generazione.

1.6.2 Governance delle estensioni di rete

Alcuni team considerano l'estensione di rete come progettazione permanente. Non lo è. Mantenere aperte le estensioni solo per la finestra di migrazione. L'estensione di rete HCX estende una rete locale in soluzione Azure VMware al livello 2, che consente ai carichi di lavoro di mantenere gli indirizzi esistenti durante lo spostamento. Questa progettazione evita di riconfigurare le applicazioni in anticipo e comporta compromessi che un decision maker deve gestire.

  • Dipendenza locale. Una rete estesa mantiene in genere il gateway in locale, quindi il carico di lavoro dipende comunque dal sito di origine dopo lo spostamento.

  • Instradamento inefficiente. Il traffico può tornare all'infrastruttura locale e poi rientrare, secondo uno schema chiamato "tromboning", che aggiunge latenza e punti di guasto.

Impostare un criterio aziendale. Estendere una rete solo quando un carico di lavoro non può modificarne l'indirizzo e rimuovere ogni estensione dopo lo spostamento dei carichi di lavoro. Valutare prima la rete locale in modo da sapere quali segmenti necessitano di estensione e per quanto tempo. Tale valutazione contribuisce a definire sia il piano delle ondate sia la tempistica dell'estensione. Il networking ottimizzato per la mobilità può ridurre i percorsi trombonati in casi specifici; pertanto, verificare le configurazioni supportate prima di abilitarlo. Vedere Configurare l'estensione di rete HCX.

2. Preparazione della migrazione

La sequenza di distribuzione seguente riflette le dipendenze tra le fasi. Ogni passaggio presuppone che il passaggio precedente sia completo e convalidato.

  1. Zona di destinazione della piattaforma: Assicurarsi che tutti i servizi di rete, identità, sicurezza e monitoraggio centralizzati necessari siano pronti per l'integrazione con i carichi di lavoro VMware Azure. Applicare le baseline di governance e sicurezza tramite Criteri di Azure alla gerarchia dei gruppi di gestione che consentono di soddisfare i requisiti di conformità. La generazione 2 viene distribuita nella tua rete virtuale, pertanto una baseline dei criteri che applica regole rigorose per i gruppi di sicurezza di rete o le tabelle di routing può impedire la distribuzione. Rimuovere questi criteri specifici dalla rete virtuale del cloud privato prima della distribuzione, quindi riapplicarli in seguito. Pianificare questa eccezione nella baseline in modo che la governance non blocchi l'implementazione.

  2. Zone di destinazione del carico di lavoro: Posizionare le zone di destinazione del carico di lavoro (sottoscrizioni) nel gruppo di gestione corretto, online o interno ("Corp").

  3. Intervalli di indirizzi IP: Riservare un blocco di indirizzi minimo /22 per il cloud privato. Nella generazione 2, riserva anche due blocchi /24 aggiuntivi per la gestione HCX e l'uplink. Verificare che nessuno di questi intervalli di indirizzi si sovrapponga allo spazio di indirizzi locale, di Azure o di altri cloud. Non è possibile correggere facilmente questa condizione dopo la distribuzione. Vedere Considerazioni sulla progettazione di seconda generazione.

  4. Richiesta di quota: Richiedere la quota in anticipo, perché l'allocazione può richiedere fino a cinque giorni lavorativi. Prevedi risorse sufficienti per la crescita e il disaster recovery, ad esempio la ridondanza N+1, ovvero un host in più rispetto a quelli necessari per il carico di lavoro. Verificare la licenza Portable VMware Cloud Foundation necessaria per le nuove distribuzioni. Vedere Richiedere la quota dell'host.

  5. Distribuzione del cloud privato di soluzione Azure VMware: Eseguire il provisioning del cloud privato di seconda generazione nella rete virtuale di Azure. Vedere Creare un cloud privato di seconda generazione.

  6. Configurazione di rete e identità: Eseguire il peering della rete cloud privato all'hub e stabilire la connettività locale. Connetti il server vCenter a un'origine di identità esterna in modo che gli amministratori accedano con account gestiti anziché con credenziali integrate condivise.

  7. Monitoraggio e gestione: Inoltrare i log alla soluzione di gestione dei log e configurare gli avvisi di integrità dei servizi. Eseguire l'onboarding di macchine virtuali guest tramite Azure Arc in modo da poterle gestire con gli stessi strumenti di Azure usati altrove.

  8. Installazione di HCX: Installare HCX e testare la connettività da sito a sito prima di avviare la prima fase.

3. Esecuzione della migrazione

Definire cosa si intende per "completato" prima di ogni fase. Un'ondata si considera completata quando il carico di lavoro è validato, l'estensione di rete viene rimossa e l'applicazione è in uno stato operativo stabile nel suo stato permanente.

Definire i criteri di rollback prima di ogni ondata e testare la procedura di rollback prima di migrare i sistemi di produzione. HCX supporta la migrazione inversa e l'approccio esatto dipende dal tipo di migrazione usato. I criteri di successo delle onde includono:

  1. Ogni macchina virtuale nell’ondata è in esecuzione in soluzione Azure VMware e non dipende più dall’estensione di rete per gestire il traffico di produzione.

  2. Ogni applicazione è raggiungibile dagli utenti e dai sistemi dipendenti.

  3. Ogni macchina virtuale viene visualizzata negli strumenti di monitoraggio senza avvisi o errori.

  4. Il rollback non è più necessario e quindi puoi chiuderlo ufficialmente.

  5. Le prestazioni dell'applicazione corrispondono o superano la linea di base.

  6. I carichi di lavoro soddisfano i requisiti di sicurezza e conformità.

  7. Il carico di lavoro è stato caricato correttamente nelle soluzioni di backup e ripristino di emergenza.

4. Valutazione della migrazione e dismissione

La migrazione non termina quando i carichi di lavoro sono attivati in soluzione Azure VMware. Verificare che i carichi di lavoro funzionino correttamente nel nuovo ambiente, confermare che le misure temporanee adottate per la migrazione siano state rimosse e dismettere formalmente l'infrastruttura di origine. Mantenere in essere la propria infrastruttura on-premises può comportare dipendenze non rilevate e non documentate. Un processo disciplinato di valutazione e rimozione delle autorizzazioni garantisce che l'organizzazione si renda conto dei vantaggi previsti della migrazione senza comportare costi operativi o rischi non necessari.

4.1 Prontezza operativa per la produzione successiva al cutover

Definire criteri successivi al cutover per confermare che il carico di lavoro si comporti come previsto. Controllare la raggiungibilità della rete e la risoluzione dei nomi. Controllare la funzione dell'applicazione e la comunicazione con i sistemi dipendenti. Dopo ogni spostamento di una macchina virtuale, verificare che si avvii, che le sue risorse siano conformi al piano e che si applichi il criterio di archiviazione corretto. Confrontare le prestazioni con la baseline di pre-migrazione.

Decidere i criteri di parità. La decisione chiave è se un carico di lavoro migrato deve raggiungere la parità completa con lo stato locale prima di chiamarlo pronto per la produzione o se si consentono deviazioni temporanee. Molte organizzazioni richiedono parità immediata delle prestazioni per i sistemi rivolti ai clienti, ma concedere alle applicazioni interne un breve periodo di stabilizzazione con una scadenza di correzione fissa.

4.2 Convalida della connettività

Convalidare la connettività end-to-end tra soluzione Azure VMware, Azure, locale, Internet e risoluzione dei nomi. Esegui gli smoke test dell'applicazione per verificare che il carico di lavoro svolga la funzione prevista. Confermare se i record di nome esterni o le impostazioni del bilanciatore del carico richiedono aggiornamenti nell'ambito del cutover.

Se è stata creata un'istanza secondaria di soluzione Azure VMware per il ripristino di emergenza, assicurarsi che sia raggiungibile sia dall'istanza primaria sia da eventuali client o servizi di supporto che devono connettersi a tale istanza nel caso venga attivata.

4.3 Dissoluzione dell'estensione di rete

Quando ogni carico di lavoro in un segmento esteso viene spostato, rimuovere l'estensione HCX Layer 2 e verificare che il gateway nativo soluzione Azure VMware venga instradato correttamente. Non lasciare un'estensione installata più a lungo del necessario per la migrazione.

4.4 Dismettere l'ambiente di origine

La dismissione libera formalmente la capacità della sorgente, le licenze e la copertura operativa. Trattalo come un passaggio di consegne governato anziché come una semplice attività di pulizia. Se si salta la dismissione, si finisce per pagare infrastrutture inutilizzate e per mantenere un'esposizione ai rischi per la sicurezza. Usare Disattivare i carichi di lavoro di origine dopo la migrazione al cloud per impostare l'ordine delle operazioni, il periodo di conservazione dei backup di origine, le approvazioni necessarie per spegnere i sistemi di origine e i criteri per recuperare licenze e hardware.

Passaggi successivi

Progettazione del carico di lavoro:

  • Last updated on