Eseguire la migrazione di un carico di lavoro cloud a un'altra area
Il passaggio Di migrazione della rilocazione è la posizione in cui si sposta il carico di lavoro nella nuova area. A seconda del carico di lavoro, potrebbero essere necessari alcuni requisiti tecnici da preparare, ma la strategia di rilocazione per il carico di lavoro deve essere chiara. Si dovrebbe essere pronti per eseguire la rilocazione.
Preparazione
Prima di avviare la rilocazione del carico di lavoro, è necessario preparare l'area di destinazione. Se necessario, seguire questa procedura per preparare l'ambiente del carico di lavoro prima della rilocazione. In questo modo si garantisce che sia disponibile una rete regionale di base, ad esempio un hub regionale e, se necessario, la connettività cross-premise.
Stabilire una zona di destinazione. Quando si pianifica lo spostamento, valutare se espande l'ambito della zona di destinazione di Azure. Se è necessaria l'espansione, consultare le linee guida per la zona di destinazione di Azure come passaggio fondamentale. Questo passaggio garantisce che l'approccio sia allineato alle procedure consigliate stabilite. Per altre informazioni, vedere Aggiungere una nuova area a una zona di destinazione di Azure esistente. Le considerazioni importanti per la configurazione della nuova zona di destinazione includono:
- Rete: valutare la struttura di rete, i percorsi di routing e i requisiti di connettività per la zona di destinazione nella nuova area.
- Integrazione: determinare se è necessario integrare la nuova zona di destinazione con quella nell'area di origine.
- Rilocazione selettiva delle risorse: decidere se tutte le risorse vengono spostate nella nuova area. Se alcune risorse rimangono nella posizione originale, pianificare una topologia di rete cross-region sostenibile per gestire queste risorse distribuite in modo efficace.
Creare nuove sottoscrizioni solo se necessario. Creare nuove sottoscrizioni solo se è necessario ristrutturare i servizi e le risorse coinvolti. Provare a mantenere il carico di lavoro nella sottoscrizione esistente, se possibile, perché la creazione di una nuova sottoscrizione aggiunge complessità. Le sottoscrizioni fungono da limiti per budget, criteri e controlli degli accessi in base al ruolo . Per qualsiasi nuova sottoscrizione, è necessario convalidare budget, criteri e RBAC. Se non si spostano tutte le risorse in una sottoscrizione, è necessario modificare l'ambito dei criteri di identità e sicurezza in modo che corrispondano al raggruppamento più piccolo di risorse. Per creare una nuova sottoscrizione, è necessario creare, definire l'ambito e implementare i criteri di Azure necessari e i ruoli controllo degli accessi in base al ruolo nella sottoscrizione di destinazione. L'obiettivo è mantenere la governance e il comportamento di sicurezza.
Se necessario, configurare un nuovo nome di dominio. Quando si verifica una modifica nel dominio personalizzato del carico di lavoro, è necessario configurare un nuovo nome di dominio. Creare il nuovo nome host, assegnarlo all'applicazione o al servizio e quindi convalidare la risoluzione dei nomi. È anche possibile pianificare una riduzione e configurare la durata (TTL) e impostarla nella fase di cutover per la scadenza automatica. Per altre informazioni, vedere Aggiungere il dominio personalizzato e Eseguire il mapping del nome DNS al piano di servizio app.
Creare nuovi certificati SSL/TLS, se necessario. È necessario creare nuovi certificati SSL/TLS (X.509) per qualsiasi nuovo nome di dominio. Questi certificati abilitano la crittografia della chiave pubblica-privata e la comunicazione di rete sicura (HTTPS). Usare Azure Key Vault per creare o importare certificati X.509. Per altre informazioni, vedere Certificati e metodi di creazione dei certificati di Azure Key Vault
Rilocare Azure Key Vault. È consigliabile spostare Azure Key Vault prima di spostare il carico di lavoro. È necessario disporre di un insieme di credenziali delle chiavi per ogni ambiente dell'applicazione e l'insieme di credenziali delle chiavi non deve condividere segreti tra aree per garantire la riservatezza. Potrebbe essere necessario creare un nuovo insieme di credenziali delle chiavi nella nuova area di destinazione per allinearsi a queste linee guida.
Creare una nuova area di lavoro Log Analytics. È necessario disporre di un'area di lavoro Log Analytics separata per ogni area. Creare una nuova area di lavoro nell'area di destinazione. Poiché non è possibile spostare un'area di lavoro Log Analytics in un'altra area, è necessario creare una nuova area di lavoro Log Analytics nell'area di destinazione. Sono disponibili due opzioni per conservare i dati nell'area di lavoro originale. È possibile mantenere l'area di lavoro corrente fino a quando non sono necessari i dati, trattando i dati come di sola lettura. È anche possibile esportare i dati dell'area di lavoro in un account di archiviazione nella nuova area di Azure di destinazione.
Eseguire la migrazione dei servizi
È possibile iniziare a eseguire la migrazione dei servizi nel carico di lavoro. Per l'esecuzione, seguire le indicazioni disponibili per l'automazione della rilocazione selezionata. Azure Resource Mover e Azure Site Recovery hanno esercitazioni dettagliate da seguire per la rilocazione del servizio. Per altre informazioni, vedi:
È possibile creare modelli di infrastruttura come codice o script per le risorse che non è possibile spostare. È anche possibile eseguire le distribuzioni manualmente nel portale di Azure. I passaggi specifici da seguire dipendono dai servizi di Azure usati e dalla relativa configurazione. Per altre informazioni, vedere Panoramica dell'infrastruttura come codice.
Eseguire la migrazione dei dati
Questa fase è rilevante solo quando il carico di lavoro richiede la migrazione dei dati. Eseguire la migrazione dei dati con l'automazione scelta. Prima del cutover al carico di lavoro nell'area di destinazione, è necessario assicurarsi che i dati correlati siano sincronizzati con l'area di origine. La coerenza dei dati è un aspetto importante che richiede attenzione. Ecco le linee guida per la migrazione dei dati del carico di lavoro.
Eseguire la migrazione dei dati dell'area di origine. L'approccio alla migrazione dei dati dell'area di origine deve seguire il metodo di rilocazione per il servizio del carico di lavoro. I metodi ad accesso frequente, sporadico e ad accesso frequente hanno processi diversi per la gestione dei dati nell'area di origine.
Sincronizzare i dati. La tecnica di sincronizzazione dipende dall'architettura del carico di lavoro e dalla domanda dell'applicazione. Ad esempio, in una sincronizzazione su richiesta, le modifiche vengono estratte quando si accede ai dati per la prima volta. Il pull e l'unione delle modifiche si verificano solo nei casi in cui esiste una differenza tra l'ultimo e l'accesso all'applicazione corrente.
Risolvere i conflitti di sincronizzazione. Assicurarsi che i dati nel percorso di origine e di destinazione siano sincronizzati e risolvere eventuali conflitti di dati. Si vuole che gli utenti tentino solo di accedere ai dati disponibili. Ad esempio, Azure Cosmos DB può serializzare scritture simultanee per garantire la coerenza dei dati.
Aggiornare le stringhe di connessione
La configurazione stringa di connessione dipende dal servizio a cui si connette l'applicazione. È possibile cercare "stringa di connessione" nella pagina della documentazione per trovare le linee guida specifiche del servizio e usare tali linee guida per aggiornare il stringa di connessione. Per altre informazioni, vedere la documentazione tecnica.
Identità gestite
Le identità gestite assegnate dal sistema hanno un ciclo di vita associato alla risorsa di Azure. La strategia di rilocazione della risorsa di Azure determina quindi come viene gestita l'identità gestita assegnata dal sistema. Se nella destinazione viene creata una nuova istanza della risorsa, è necessario concedere alla nuova identità gestita assegnata dal sistema le stesse autorizzazioni dell'identità gestita assegnata dal sistema nell'area di origine.
D'altra parte, l'identità gestita assegnata dall'utente ha un ciclo di vita indipendente ed è possibile eseguire il mapping dell'identità gestita assegnata dall'utente alla nuova risorsa nell'area di destinazione. Per altre informazioni, vedere Panoramica dell'identità gestita.
Passaggi successivi
È stata eseguita la migrazione dei servizi e dei dati del carico di lavoro. Ora è necessario completare la rilocazione con un cutover.