Valutare l'idoneità dei carichi di lavoro

Questo articolo è incentrato su come valutare l'idoneità di un carico di lavoro per la migrazione al cloud.

Quando si vuole eseguire la migrazione di un carico di lavoro, il team di adozione del cloud garantisce che tutti gli asset e le dipendenze associate siano compatibili con il modello di distribuzione e il provider di servizi cloud. Il team documenta tutti gli sforzi necessari per correggere i problemi di compatibilità.

Presupposti di valutazione

La maggior parte del contenuto che illustra i principi in Cloud Adoption Framework per Azure è indipendente dal cloud. Tuttavia, il processo di valutazione dell'idoneità deve essere specifico per ogni piattaforma cloud e per gli strumenti di migrazione selezionati nella fase di preparazione .

Gli strumenti di valutazione selezionati devono fornire informazioni sui blocchi per la migrazione. I blocchi comuni includono il supporto del sistema operativo, le dimensioni del server e le frequenze di modifica dei dati che potrebbero influire sulla replica.

Alcune organizzazioni riscontrano anche problemi con le configurazioni delle macchine virtuali (VM) che sfruttano la piattaforma hypervisor di origine. Queste configurazioni includono sicurezza basata su virtualizzazione, dischi dinamici, licenze di applicazioni non Microsoft, configurazioni dell'origine dati e certificati.

Questo articolo non acquisisce tutte le possibili attività di valutazione perché ogni ambiente e risultato aziendale determina requisiti specifici. Per determinare quali requisiti sono disponibili, ecco alcune attività di valutazione comuni correlate a infrastruttura, database e reti.

Valutare le dipendenze tra data center

Se si esegue la migrazione di carichi di lavoro da più data center, è necessario valutare eventuali dipendenze tra tali data center.

Considerare le funzionalità seguenti per valutare le dipendenze tra data center:

• Visualizzare le dipendenze: usare la funzionalità di visualizzazione delle dipendenze in Azure Migrate e Modernizzare per individuare le dipendenze.
• Dipendenze di gruppo: usare il raggruppamento delle dipendenze quando si ha a che fare con la complessità globale. Questa funzionalità consente di identificare gli indirizzi IP e le porte di tutti gli asset necessari per supportare il carico di lavoro.

Importante

• Per identificare gli asset che risiedono in un data center secondario, è necessario un esperto di materia che comprenda il posizionamento degli asset e gli schemi degli indirizzi IP.
• È necessario valutare le dipendenze downstream e i client nella visualizzazione per comprendere le dipendenze bidirezionali.

Scenari di esempio

Le sezioni seguenti forniscono indicazioni per valutare l'idoneità per la migrazione di carichi di lavoro e database nel cloud.

Attività di valutazione comuni per Azure Migrate e Modernizzazione

Le indicazioni seguenti presuppongono che si intenda eseguire la migrazione di un carico di lavoro ad Azure. Si presuppone anche di usare Azure Migrate e Modernizzare per le attività di replica.

È possibile usare il progetto Azure Migrate e Modernizzare per valutare i carichi di lavoro e calcolare il costo di funzionamento in Azure. Per altre informazioni, vedere Valutazioni delle macchine virtuali di Azure in Azure Migrate e Modernizzazione.

È anche possibile usare azure Migrate e modernizzare il progetto per valutare l'idoneità per la migrazione, convertire le dimensioni del server in sottoscrizioni di Azure in base all'uso effettivo e calcolare i costi. Perfezionare ulteriormente i calcoli dei costi creando un business case.

Assicurarsi di documentare eventuali discrepanze nella configurazione host, nella configurazione delle macchine virtuali replicate, nei requisiti di archiviazione o nella configurazione di rete. Usare queste informazioni per stimare le considerazioni sulla larghezza di banda per la migrazione. I componenti comuni della stima della larghezza di banda includono:

• Spazio di archiviazione totale: calcolare lo spazio di archiviazione totale necessario per le macchine virtuali replicate durante le iterazioni che portano a una versione.
• Velocità di deriva o modifica: calcolare la velocità di deviazione o modifica dell'archiviazione necessaria per le macchine virtuali replicate durante le iterazioni che portano a una versione.
• Requisiti di larghezza di banda: calcolare i requisiti di larghezza di banda necessari per ogni iterazione sommando l'archiviazione totale e la deriva.
• Larghezza di banda inutilizzata: calcolare la larghezza di banda inutilizzata disponibile nella rete corrente per convalidare l'allineamento per iterazione.
• Larghezza di banda della velocità di migrazione: documentare la larghezza di banda necessaria per raggiungere la velocità di migrazione prevista. Se è necessaria una correzione per fornire la larghezza di banda necessaria, inviare una notifica al team responsabile delle attività di correzione.

Nota

L'archiviazione totale influisce direttamente sui requisiti di larghezza di banda durante la replica iniziale. Tuttavia la deviazione di archiviazione continua dal punto di replica fino al rilascio. Questo significa che la deviazione ha un effetto cumulativo sulla larghezza di banda disponibile.

Per indicazioni sulla valutazione dei requisiti di larghezza di banda, vedere Domande comuni per gli strumenti di migrazione e modernizzazione.

Attività comuni di valutazione dei database

Come parte della migrazione del server, è anche possibile esaminare la migrazione di istanze di SQL Server o di altri server di database.

• RPO e RTO del documento: documentare gli obiettivi del punto di ripristino (RPO) e gli obiettivi del tempo di ripristino (RTO) della distribuzione del database corrente. Usare queste informazioni per prendere decisioni durante le attività di architettura.
• Documentare i requisiti di disponibilità elevata: documentare i requisiti di configurazione a disponibilità elevata. Per altre informazioni sui requisiti di SQL Server, vedere la guida alle soluzioni a disponibilità elevata di SQL Server.
• Valutare la compatibilità PaaS: valutare la compatibilità paaS (Platform as a Service). Le guide Servizio Migrazione del database di Azure mappano i database locali alle soluzioni PaaS di Azure compatibili, ad esempio Azure Cosmos DB, database SQL di Azure, Database di Azure per MySQL Database di Azure per PostgreSQL o Database di Azure per MariaDB.
  • Compatibilità PaaS senza correzione: quando la compatibilità PaaS è un'opzione senza la necessità di alcuna correzione, consultare il team responsabile delle attività di architettura. Le migrazioni PaaS possono risparmiare tempo e ridurre il costo totale di proprietà (TCO) della maggior parte delle soluzioni cloud.
  • Compatibilità PaaS quando è necessaria la correzione: consultare i team responsabili dell'architettura e delle attività di correzione . In molti scenari, i vantaggi delle migrazioni PaaS per le soluzioni di database superano l'aumento del tempo di correzione.
• Dimensioni e frequenza di modifica del documento: documentare le dimensioni e la frequenza di modifica per ogni database di cui si intende eseguire la migrazione.
• Documentare le dipendenze dell'applicazione e del database: quando possibile, documentare tutte le applicazioni o altri asset che effettuano chiamate a ogni database.

Nota

Per la sincronizzazione di un asset viene usata la larghezza di banda durante i processi di replica. Un problema comune consiste nell'ignorare la larghezza di banda necessaria per mantenere sincronizzati gli asset tra i punti di replica e il rilascio. I database usano in genere la larghezza di banda durante i cicli di rilascio e i database con footprint di archiviazione di grandi dimensioni o una frequenza di modifica elevata richiedono particolare attenzione.

Valutare la possibilità di replicare la struttura dei dati con aggiornamenti controllati prima del test di accettazione utente (UAT) e del rilascio. In questi scenari, le alternative ad Azure Site Recovery potrebbero essere più appropriate. Per altre informazioni, vedere guide Servizio Migrazione del database di Azure.

Passaggio successivo

Dopo aver valutato un sistema, gli output generano il feed dello sviluppo di una nuova architettura cloud.

Progettare i carichi di lavoro prima della migrazione