Progettare l'architettura del carico di lavoro prima della migrazione

Questo articolo descrive il processo e le considerazioni per progettare lo stato di migrazione previsto di un carico di lavoro nel cloud. L'articolo esamina le attività che fanno parte della definizione dell'architettura di un carico di lavoro all'interno di un'iterazione.

L'articolo sulla razionalizzazione incrementale indica che alcuni presupposti architetturali fanno parte di qualsiasi trasformazione aziendale che include una migrazione. Questo articolo chiarisce i presupposti tipici. Indica anche alcuni ostacoli che è possibile evitare e identifica le opportunità per accelerare il valore aziendale sfidando i presupposti dell'architettura. Questo modello incrementale per la progettazione dell'architettura consente ai team di spostarsi più rapidamente e ottenere risultati aziendali.

Progettazione dell'architettura di base su presupposti comuni

I presupposti seguenti sono tipici per le operazioni di migrazione:

• Si supponga che un carico di lavoro IaaS (Infrastructure as a Service). La migrazione dei carichi di lavoro comporta principalmente lo spostamento di server da un data center fisico a un data center cloud tramite una migrazione IaaS. Il processo richiede in genere una riconfigurazione o una riconfigurazione minima. Questo approccio è noto come migrazione lift-and-shift .
• Mantenere coerente l'architettura. Le modifiche apportate all'architettura principale durante una migrazione aumentano notevolmente la complessità. Il debug di un sistema modificato in una nuova piattaforma introduce molte variabili che possono risultare difficili da isolare. I carichi di lavoro devono subire solo modifiche minime durante la migrazione e tutte le modifiche devono essere testate accuratamente.
• Pianificare il ridimensionamento degli asset. Si supponga che pochi asset locali usino completamente qualsiasi risorsa. Prima o durante la migrazione, gli asset vengono ridimensionati in base ai requisiti di utilizzo effettivi. Gli strumenti come Azure Migrate e Modernize forniscono il dimensionamento in base all'uso effettivo.
• Acquisire i requisiti di continuità aziendale e ripristino di emergenza.Capture business continuity and disaster recovery (BCDR). Se si dispone di un contratto di servizio concordato per il carico di lavoro già negoziato con l'azienda, continuare a usare il contratto di servizio dopo la migrazione ad Azure. Se un contratto di servizio non è già impostato, definirne uno prima di progettare il carico di lavoro nel cloud per assicurarsi di progettare in modo appropriato.
• Pianificare il tempo di inattività della migrazione. Analogamente al mancato rispetto dei requisiti del contratto di servizio, il tempo di inattività che si verifica quando si alza di livello un carico di lavoro all'ambiente di produzione può avere un effetto negativo sull'azienda. A volte le soluzioni che devono eseguire la transizione con tempi di inattività minimi richiedono modifiche all'architettura. Prima di iniziare la pianificazione del rilascio, si supponga che venga stabilita una conoscenza generale dei requisiti di tempo di inattività.
• Definire i modelli di traffico dell'utente e dell'applicazione. Le soluzioni esistenti possono dipendere da modelli e soluzioni di routing di rete esistenti. Identificare le risorse necessarie per supportare l'utilizzo corrente della rete.
• Pianificare l'evitare conflitti di rete. Quando si consolidano i data center in un singolo provider di servizi cloud, è probabile che si creino conflitti in Domain Name System (DNS) o in altre strutture di rete. Durante la migrazione, è importante progettare per evitare questi conflitti per evitare interruzioni dei sistemi di produzione ospitati nel cloud.
• Pianificare le tabelle di routing. Assicurarsi che il progetto includa un piano per la modifica delle tabelle di routing se si consolidano reti o data center. Prendere in considerazione i requisiti di routing tra data center.

Architettura di progettazione per una zona di destinazione

Nella fase Ready di Cloud Adoption Framework, l'organizzazione ha distribuito servizi della piattaforma condivisa nell'ambito dell'adozione delle zone di destinazione di Azure. In Pronto la zona di destinazione per la migrazione è stata preparata la zona di destinazione per ricevere i carichi di lavoro migrati.

In base a questa pianificazione, è possibile presupporre che siano presenti i componenti di migrazione seguenti:

• La connettività ibrida connette le reti di Azure alle reti locali.
• Le appliance di sicurezza di rete come Firewall di Azure gestiscono l'ispezione del traffico all'esterno del carico di lavoro.
• I criteri di Azure per applicare procedure di governance come i requisiti di registrazione, le aree consentite, i servizi non consentiti e altri controlli sono attivi.
• Un'area di lavoro Log di Monitoraggio di Azure per la registrazione condivisa è configurata in Monitoraggio di Azure.
• Vengono stabilite risorse di identità condivise per supportare server aggiunti a un dominio o altre esigenze di identità.

Se queste informazioni di base sulla migrazione non sono definite, l'organizzazione deve rivedere immediatamente la fase Pronto per soddisfare queste esigenze. Senza questi componenti, è probabile che la migrazione abbia ritardi e setback e abbia meno esito positivo.

Il carico di lavoro che si sta progettando ha una sottoscrizione assegnata, idealmente tramite un processo di vendita di abbonamenti. La sottoscrizione può contenere diversi carichi di lavoro o un solo carico di lavoro, a seconda del modo in cui l'organizzazione ha completato l'organizzazione delle risorse per i carichi di lavoro. Se si esegue la migrazione di un carico di lavoro con molti ambienti applicazione, potrebbero essere presenti anche più sottoscrizioni in base alle indicazioni per gli ambienti dell'applicazione.

Progettare l'architettura di rete del carico di lavoro

Pianificare la distribuzione di risorse specifiche dell'applicazione in una sottoscrizione specifica e pianificare la progettazione di una rete virtuale dedicata per il carico di lavoro. Per altre informazioni, vedere linee guida per la progettazione dell'architettura di rete. È consigliabile concentrarsi soprattutto sulla segmentazione delle reti virtuali.

La rete richiede probabilmente risorse come i servizi di bilanciamento del carico e altre risorse per il recapito delle applicazioni. È possibile usare la guida all'architettura a più livelli per pianificare queste risorse in Azure.

Progettare le dipendenze del carico di lavoro

Gli strumenti di valutazione della migrazione devono offrire un modo per eseguire l'analisi delle dipendenze, ad esempio l'analisi delle dipendenze in Azure Migrate e modernizzare. Lo strumento consente di identificare le interdipendenze tra i server.

Oltre alla pianificazione dell'architettura per il carico di lavoro stesso, potrebbe essere necessario prendere in considerazione le dipendenze da carico di lavoro a carico di lavoro. Ad esempio, alcuni carichi di lavoro potrebbero richiedere comunicazioni frequenti. In tal caso, la pianificazione delle onde e delle dipendenze della migrazione per tenere conto di questo requisito consente di ottenere risultati positivi per la migrazione.

È possibile usare linee guida nel Centro architetture di Azure, ad esempio per la rete spoke-to-spoke , per progettare il funzionamento dei carichi di lavoro interconnessi dopo la migrazione.

Prepararsi per l'adozione del confidential computing

Un subset dei carichi di lavoro con requisiti di sovranità potrebbe causare l'uso del confidential computing. Come parte della distribuzione di una zona di destinazione sovrana, vengono creati i gruppi di gestione per il confidential computing.

All'interno di un contesto di sovranità, l'uso del confidential computing richiede Azure Key Vault e chiavi gestite dal cliente come servizio di supporto. Per altre informazioni, vedere Crittografia con chiavi gestite dal cliente in Microsoft Cloud for Sovranità.

Aggiornare la stima cloud iniziale

Al termine della progettazione dell'architettura, rivedere la stima del cloud per assicurarsi di essere ancora entro il budget pianificato. Quando si aggiungono servizi di supporto come i servizi di bilanciamento del carico o i backup, i costi possono cambiare. Sebbene sia possibile usare strumenti come i casi aziendali in Azure Migrate e Modernizzare per eseguire esercizi dettagliati sulla gestione dei costi, è consigliabile rivedere periodicamente le stime durante la modifica della progettazione dell'architettura.

Se si ha familiarità con i processi di approvvigionamento IT tradizionali, la stima delle risorse nel cloud potrebbe sembrare esterna. Quando si adottano tecnologie cloud, l'acquisizione passa da un modello rigido e strutturato di spese in conto capitale a un modello di spesa operativa fluido. La pianificazione di una migrazione al cloud è spesso la prima volta che un'organizzazione o un team IT rileva questa modifica.

Nel modello tradizionale di spese in conto capitale, un team IT tenta di combinare il potere di acquisto per più carichi di lavoro in vari programmi. Questo approccio centralizza un pool di asset IT condivisi che possono supportare ognuna di queste soluzioni. Nel modello cloud spese operative i costi possono essere attribuiti direttamente alle esigenze di supporto di singoli carichi di lavoro, team o business unit. Offre a un'organizzazione un'attribuzione più diretta dei costi ai clienti interni e agli obiettivi aziendali supportati. Questo approccio più dinamico alla gestione finanziaria è spesso definito operazioni finanziarie (FinOps). Anche se FinOps non è una considerazione specifica di Azure, può essere utile avere una conoscenza approfondita di FinOps. Per altre informazioni, vedere Che cos'è FinOps?.

Quando si progetta l'architettura del carico di lavoro per la migrazione, è possibile usare il calcolatore prezzi con le informazioni di valutazione per comprendere il prezzo dell'intero carico di lavoro.

Inoltre, dopo la migrazione del carico di lavoro, è necessario continuare a lavorare per ottimizzare i costi del carico di lavoro. Per altre informazioni su come le organizzazioni possono maturare le proprie competenze di gestione dei costi, vedere Migliorare la disciplina di gestione dei costi.

Sapere quando modificare l'architettura

Le migrazioni tendono a concentrarsi sulla gestione di un'architettura esistente e sulla transizione alla piattaforma cloud. Tuttavia, in alcuni casi potrebbe essere necessario riprogettare il carico di lavoro, anche per la migrazione. Questo elenco fornisce esempi di quando potrebbe essere necessario apportare modifiche all'architettura prima di eseguire la migrazione:

• Pagamento del debito tecnico. Alcuni carichi di lavoro invecchiati comportano un elevato debito tecnico. Il debito tecnico può causare problemi a lungo termine con l'aumento dei costi di hosting con qualsiasi provider di servizi cloud. Quando il debito tecnico aumenta in natura i costi di hosting, è consigliabile valutare architetture alternative.
• Miglioramento dell'affidabilità. Le baseline di operazioni standard offrono un grado di affidabilità e ripristino nel cloud. Alcuni team del carico di lavoro potrebbero richiedere contratti di servizio più elevati, che potrebbero causare modifiche dell'architettura.
• Carichi di lavoro a costi elevati. Durante la migrazione, è consigliabile ottimizzare tutti gli asset per allineare il ridimensionamento con l'utilizzo effettivo. Alcuni carichi di lavoro potrebbero richiedere modifiche dell'architettura per risolvere problemi di costo specifici.
• Requisiti di prestazioni. Quando le prestazioni del carico di lavoro influiscono direttamente sull'azienda, potrebbe essere necessario considerare un'architettura aggiuntiva.
• Proteggere le applicazioni. I requisiti di sicurezza tendono a essere implementati centralmente e vengono in genere applicati a tutti i carichi di lavoro in un portfolio. Alcuni carichi di lavoro potrebbero avere requisiti di sicurezza specifici che possono causare modifiche dell'architettura.

Ognuno di questi criteri funge da indicatore di un potenziale ostacolo alla migrazione. Nella maggior parte dei casi, è possibile risolvere il criterio dopo la migrazione del carico di lavoro tramite il ridimensionamento corretto dei server, l'aggiunta di nuovi server o l'esecuzione di altre modifiche. Tuttavia, se uno di questi criteri è necessario prima di eseguire la migrazione di un carico di lavoro, rimuovere il carico di lavoro dall'ondata di migrazione e valutarlo singolarmente.

Azure Well-Architected Framework e Azure Well-Architected Review possono aiutare a guidare le conversazioni con il proprietario tecnico di un carico di lavoro specifico per aiutarli a prendere in considerazione opzioni alternative per la distribuzione del carico di lavoro.

Il carico di lavoro viene quindi classificato come attività di riprogettazione o modernizzazione nel piano di adozione del cloud. A causa del tempo aggiuntivo necessario per riprogettare un carico di lavoro, considerare questi percorsi di adozione alternativi del carico di lavoro come separati dal processo di migrazione.

Elenco di controllo dell'architettura

È possibile usare l'elenco di controllo seguente per assicurarsi di tenere conto delle considerazioni critiche sull'architettura:

• Verificare che l'architettura soddisfi i contratti di servizio per la disponibilità, il ripristino di emergenza e il ripristino dei dati.
• Verificare di aver applicato le procedure di segmentazione di rete alla progettazione della rete.
• Verificare che sia stato pianificato il monitoraggio e l'acquisizione dei log.
• Verificare che le macchine virtuali siano ridimensionate in modo appropriato per il tempo di calcolo effettivo necessario.
• Verificare che i dischi siano ridimensionati in modo appropriato per le dimensioni e le prestazioni effettive necessarie.
• Verificare che siano stati pianificati per i servizi di bilanciamento del carico, se necessari. I servizi possono includere istanze di Azure Load Balancer, gateway di app Azure lication, Frontdoor di Azure o Gestione traffico di Azure.
• Verificare di aver pianificato i requisiti di sovranità e confidential computing, se necessario.

Passaggio successivo

Distribuire carichi di lavoro di migrazione