Modifica

Condividi tramite

Spostare le risorse di Azure tra aree

Microsoft Entra
Azure ExpressRoute
Azure Load Balancer
Gateway VPN di Azure

Questa soluzione sposta le risorse di Azure tra aree in modo efficiente, sicuro e senza problemi. Vedere i passaggi principali, le considerazioni e le strategie per la pianificazione e l'esecuzione di uno spostamento.

Architettura

Diagramma che mostra il flusso di dati dello spostamento delle risorse di Azure tra le diverse aree.

Scaricare un file di Visio di questa architettura.

Flusso di dati

  • Rete del data center locale: una rete locale privata in esecuzione all'interno di un'organizzazione per supportare le risorse locali.

  • Circuito ExpressRoute: le connessioni ExpressRoute usano una connessione privata dedicata tramite un provider di connettività di terze parti. La connessione privata estende una rete locale in Azure.

  • Router perimetrali locali: router che connettono la rete locale al circuito gestito dal provider di terze parti. A seconda di come è stato effettuato il provisioning della connessione, potrebbe essere necessario fornire gli indirizzi IP pubblici usati dai router.

  • Router perimetrali Microsoft: due router in una configurazione a disponibilità elevata attiva-attiva. Questi router consentono a un provider di connettività di terze parti di connettere i circuiti direttamente al data center. A seconda di come è stato effettuato il provisioning della connessione, potrebbe essere necessario fornire gli indirizzi IP pubblici usati dai router.

  • Gateway VPN: usando il servizio gateway VPN, è possibile connettere la rete virtuale alla rete locale.

  • Subnet di Active Directory: la maggior parte delle organizzazioni aziendali ha un ambiente Dominio di Active Directory Services (AD DS) nel data center locale. Per facilitare la gestione degli asset spostati in Azure dalla rete locale che dipende da Servizi di dominio Active Directory, è consigliabile ospitare controller di dominio di Active Directory Domain Services in Azure in un hub di Rete virtuale centrale (VNET) a cui possono accedere i carichi di lavoro dipendenti.

  • Peering reti virtuali: più reti virtuali con peering tra di essi. Il peering reti virtuali consente di raggruppare le applicazioni nelle rispettive reti virtuali e fornisce una connessione a larghezza di banda elevata a bassa latenza.

  • Applicazioni Web multilitiere in esecuzione nell'ambiente cloud: questa architettura di esempio è applicabile a molti settori che devono distribuire applicazioni multilitiere resilienti nel cloud. In questo scenario, l'applicazione è costituita da tre livelli:

    • Livello Web: il livello superiore, inclusa l'interfaccia utente. Questo livello analizza le interazioni utente e passa le azioni al livello successivo per l'elaborazione.
    • Livello business o app: elabora le interazioni dell'utente e prende decisioni logiche sui passaggi successivi. Questo livello connette il livello Web al livello dati.
    • Livello dati: archivia i dati dell'applicazione. In questo caso, un database SQL archivia i dati.

  • Servizio di bilanciamento del carico interno: il traffico di rete dal gateway VPN viene instradato all'applicazione cloud tramite un endpoint del servizio di bilanciamento del carico interno (ILB) che si trova nella subnet dei livelli applicazione.

  • Risorse PaaS (Platform as a Service): in questo ambiente di esempio sono disponibili alcuni servizi PaaS, ad esempio l'hub IoT di Azure, Azure Key Vault e il servizio app Azure.

Componenti

L'architettura di esempio usa i componenti seguenti:

Dettagli dello scenario

Con la crescita di Microsoft Azure e il suo set di aree in continua evoluzione in tutto il mondo, i clienti hanno la necessità di spostare le distribuzioni da un'area a un'altra. Lo spostamento delle applicazioni tra aree è un'attività che richiede un piano ben ponderato, per garantire che tutte le risorse vengano spostate senza problemi e che le applicazioni siano in esecuzione nella nuova area con tempi di inattività minimi.

Le raccomandazioni e l'architettura di questo esempio forniscono indicazioni su risorse di Azure in modo efficiente, sicuro e senza problemi di spostamento tra aree.

Potenziali casi d'uso

Alcuni dei motivi principali per spostare le risorse in un'area diversa includono i casi seguenti:

  • Allinea all'avvio di un'area: spostare le risorse in un'area di Azure appena introdotta che non era disponibile in precedenza.
  • Allinea per servizi o funzionalità: spostare le risorse per sfruttare i servizi o le funzionalità disponibili in un'area specifica.
  • Rispondere a sviluppi aziendali: spostare le risorse in un'area in risposta a modifiche aziendali, ad esempio fusioni o acquisizioni.
  • Allinearsi per prossimità: spostare le risorse in un'area in cui si trova l'azienda.

Passaggi per spostare le risorse tra aree

Poiché i requisiti potrebbero differire dall'architettura di esempio, usare le raccomandazioni seguenti come punto di partenza:

  1. Verificare i prerequisiti per lo spostamento.

    • Tempo di inattività pianificato: pianificare lo spostamento dell'area come attività di manutenzione con tempi di inattività pianificati per ridurre al minimo l'impatto sui clienti.

    • Limiti e quota della sottoscrizione di Azure: assicurarsi che la sottoscrizione disponga di risorse sufficienti per supportare il tipo di risorsa specifico. Ad esempio, assicurarsi che l'area di destinazione supporti le macchine virtuali con dimensioni corrispondenti alle macchine virtuali nell'area di origine. Contattare il supporto tecnico per abilitare la quota necessaria, se necessario. Per altre informazioni, vedere Sottoscrizione di Azure e limiti, quote e vincoli del servizio.

    • Autorizzazioni dell'account: se è stato creato un account Azure gratuito, si è l'amministratore della sottoscrizione. Se non si è l'amministratore della sottoscrizione, rivolgersi all'amministratore per assegnare le autorizzazioni necessarie per spostare le risorse. Verificare che la sottoscrizione di Azure consenta di creare la risorsa necessaria nell'area di destinazione.

    • Identificazione delle risorse: identificare e classificare le risorse in base al tipo di risorsa necessaria per esportare un modello di Azure Resource Manager o avviare la replica usando varie tecnologie. Per ognuno dei tipi di risorse da spostare, i passaggi possono essere diversi. Fare riferimento a Spostamento di risorse di Azure tra aree per identificare i passaggi corrispondenti per ognuno dei tipi di risorse.

  2. Spostare i componenti di rete.

    • Gruppi di sicurezza di rete: non è possibile spostare i gruppi di sicurezza di rete da un'area a un'altra. Tuttavia, è possibile usare un modello di Resource Manager per esportare la configurazione esistente e le regole di sicurezza di un gruppo di sicurezza di rete. È quindi possibile preparare la risorsa in un'altra area esportando il gruppo in un modello, modificando i parametri in modo che corrispondano all'area di destinazione e quindi distribuendo il modello nella nuova area.

    • Rete virtuale: è possibile usare un modello di Azure Resource Manager per completare lo spostamento della rete virtuale in un'altra area. Esportare la rete virtuale in un modello, modificare i parametri in modo che corrispondano all'area di destinazione e quindi distribuire il modello nella nuova area.

    • Peering di rete virtuale: il peering reti virtuali non verrà ricreato e i peer della rete virtuale avranno esito negativo se sono ancora presenti nel modello. Prima di esportare il modello, rimuovere eventuali peer di rete virtuale. È possibile ristabilire le operazioni dopo lo spostamento della rete virtuale.

    • Indirizzi IP pubblici: poiché gli indirizzi IP pubblici di Azure sono specifici dell'area, non è possibile spostarli da un'area a un'altra. Tuttavia, è possibile usare un modello di Resource Manager per esportare la configurazione esistente e le regole di sicurezza di un gruppo di sicurezza di rete. È quindi possibile preparare la risorsa in un'altra area esportando il gruppo in un modello, modificando i parametri in modo che corrispondano all'area di destinazione e quindi distribuendo il modello nella nuova area.

  3. Spostare i componenti dell'app.

  4. Spostare i servizi PaaS: i servizi PaaS hanno i propri passaggi specifici per orchestrare lo spostamento. Per trovare le informazioni più recenti sull'elenco dei servizi supportati, vedere Supporto per lo spostamento delle risorse di Azure tra aree.

  5. Spostare l'infrastruttura locale: per assicurarsi che l'area di origine completa venga ricreata nell'area di destinazione, ristabilire e configurare i componenti locali come prima e connetterli alla rete di Azure.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Quando si effettua uno spostamento tra aree, tenere presente quanto segue:

  • Il piano per la migrazione tra aree deve tenere conto di un'infrastruttura complessa. Gli ambienti dell'infrastruttura moderna si estendono spesso nell'infrastruttura locale al cloud. Alcuni hanno anche un livello aggiuntivo di complessità, con una strategia multicloud contenente distribuzioni private o pubbliche.

  • Spostare i tipi di risorse insieme. Combinando lo spostamento di tipi di risorse simili (ad esempio, 50 macchine virtuali o 20 database SQL), è possibile pianificare il passaggio di preparazione dello spostamento più facilmente e assicurarsi che le operazioni a esecuzione prolungata vengano completate insieme, riducendo così il tempo di inattività.

  • Spostare tutte le risorse all'interno di un'applicazione insieme. È possibile selezionare le risorse di un'applicazione e provare a spostarle insieme in un set per assicurarsi di poter visualizzare l'app nell'area di destinazione in modo orchestrato.

  • Assicurarsi di soddisfare le esigenze di capacità. La possibilità di verificare la capacità o la quota è disponibile nell'area di destinazione per supportare la crescita aziendale corrente e potenziale prima dello spostamento effettivo.

  • Quando lo spostamento è in corso, non dovrebbe avere alcun impatto sulle applicazioni o sull'infrastruttura business critical correnti nell'area di origine.

  • Per garantire la continuità aziendale, è necessario disporre di un ambiente funzionale operativo in esecuzione nell'area di destinazione con il minor tempo di inattività possibile.

  • La possibilità di convalidare la migrazione prima del commit finale sul lato di destinazione è fondamentale, soprattutto se si supporta il livello 0, i carichi di lavoro di livello 1 nel settore dei servizi finanziari (FSI) o nei verticali dell'assistenza sanitaria.

  • Assicurarsi di eseguire due diligence testando e convalidando le configurazioni originali, la connettività, la configurazione di sicurezza appropriata, i criteri, la replica dei dati e le connessioni di database prima di eseguire il commit dello spostamento nell'area di destinazione.

  • Dopo aver spostato le risorse nella destinazione, assicurarsi che la configurazione finale sia attiva e in esecuzione apportando modifiche finali come:

    • Modificare la configurazione DNS in modo che punti a un nuovo INDIRIZZO IP.
    • Eliminare le risorse nell'area di origine per evitare la doppia fatturazione e per evitare problemi dovuti all'esistenza di due set di dati separati che si sovrappongono nell'ambito e nella configurazione.
    • Eliminare tutte le risorse ausiliarie create per lo spostamento. Ad esempio, eliminare tutti gli account di archiviazione usati per il trasferimento intermedio.

Passaggi successivi