Percorso di progettazione della rete lift-and-shift

Questa guida fornisce un percorso di lettura sequenziato tramite Azure Guida alla progettazione della rete per i clienti che eseguono la migrazione di carichi di lavoro locali a Azure Infrastructure as a Service (IaaS) senza riprogettare le applicazioni. Seguire i passaggi numerati per creare la rete da zero, prendendo le decisioni giuste in ogni fase.

Overview

Una migrazione lift-and-shift migra i carichi di lavoro locali esistenti nelle macchine virtuali (VM) di Azure con modifiche minime all'architettura dell'applicazione. Le applicazioni mantengono i modelli di comunicazione, le dipendenze e le configurazioni esistenti. La rete compilata in Azure deve supportare questi modelli esistenti sfruttando al tempo stesso i servizi di connettività e sicurezza nativi di Azure.

L'architettura di destinazione è una topologia hub-spoke con servizi condivisi centralizzati. Una singola rete virtuale hub ospita la connessione Gateway VPN o ExpressRoute all'ambiente locale, Azure Bastion per l'accesso sicuro alle macchine virtuali, Firewall di Azure per l'ispezione centralizzata del traffico e l'inoltro DNS. Le reti virtuali spoke ospitano le macchine virtuali del carico di lavoro di cui è stata eseguita la migrazione, isolate l'una dall'altra per impostazione predefinita e connesse tramite l'hub per la comunicazione tra carichi di lavoro.

Questo percorso di lettura illustra 10 articoli essenziali in cinque fasi. Ogni articolo si basa sulle decisioni prese nel passaggio precedente. Al termine, è disponibile una progettazione di rete pronta per la produzione che supporta i carichi di lavoro migrati con sicurezza e connettività avanzate per la difesa.

Prerequisiti

  • Leggere la panoramica del piano di rete e della progettazione Azure per l'orientamento sui servizi e la struttura di guida disponibili.
  • Completare un inventario della rete locale esistente: intervalli IP, subnet, regole del firewall, zone DNS e flussi di traffico tra applicazioni (si farà riferimento a questo inventario negli articoli fondamentali: reti virtuali e subnet, pianificazione degli indirizzi IP e configurazione del gruppo di sicurezza di rete).
  • Identifica quali carichi di lavoro prevedi di migrare per primi. Iniziare con un gruppo pilota prima di eseguire la migrazione dell'intero patrimonio.
  • Documentare i requisiti di connettività locali: larghezza di banda per Azure, sensibilità alla latenza e aspettative di failover.

Percorso di lettura

Eseguire queste fasi in ordine. Ogni fase si basa sulle decisioni della precedente.

Fase 1: Fondamenti

Iniziare con i tre articoli fondamentali. Queste decisioni modellano tutto ciò che segue.

1. Reti virtuali e subnet

Creare la rete virtuale che ospita le macchine virtuali di cui è stata eseguita la migrazione. Eseguire il mapping dei segmenti di rete esistenti in subnet Azure. Concentrarsi sui limiti di isolamento della subnet: i carichi di lavoro che condividono una subnet, che necessitano di un proprio e il numero di indirizzi IP necessari per ogni subnet in base al numero di macchine virtuali.

2. Pianificazione degli indirizzi IP

Evitare sovrapposizioni IP con l'ambiente locale. Usare un pool CIDR (Classless Inter-Domain Routing) per ogni rete virtuale per lasciare spazio per la crescita. Se i tuoi intervalli on-premises si sovrappongono agli indirizzi riservati di Azure o a quelli di altre sottoscrizioni Azure, pianifica una strategia di riassegnazione degli indirizzi prima di eseguire la migrazione.

3. Gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni

Eseguire il mirroring delle regole del firewall esistenti come gruppi di sicurezza di rete (NSG). Converti gli elenchi di controllo di accesso (ACL) locali in regole NSG con un criterio deny-by-default. Usare i gruppi di sicurezza delle applicazioni per raggruppare le macchine virtuali in base al ruolo anziché gestire singoli indirizzi IP.

Fase 2: Topologia

4. Topologia hub-and-spoke

Hub-and-spoke è la topologia predefinita per le migrazioni lift-and-shift di più carichi di lavoro. Posizionare i servizi condivisi nella rete virtuale dell'hub: Gateway VPN, Azure Bastion, Firewall di Azure e server d'inoltro DNS. Ogni carico di lavoro ha una propria rete virtuale spoke connessa tramite peering all'hub. Gli spoke comunicano tramite il firewall dell'hub, consentendoti un controllo centralizzato del traffico.

Fase 3: Connettività

5. Connettività ibrida

Gateway VPN o Azure ExpressRoute verso l'ambiente locale rappresentano la dipendenza più critica per la migrazione. Senza questa connessione, le macchine virtuali migrate non possono raggiungere i servizi locali da cui dipendono e gli utenti non possono raggiungere le applicazioni migrate. Ridimensionare la larghezza di banda del gateway in base ai modelli di traffico documentati nell'inventario.

6. Accesso per sviluppatori e amministratori

Azure Bastion fornisce l'accesso SECURE REMOTE DESKTOP Protocol (RDP) e Secure Shell (SSH) alle macchine virtuali di cui è stata eseguita la migrazione senza esporle alla rete Internet pubblica. Distribuisci Bastion nella VNet dell'hub in modo che tutti gli spoke condividano un unico punto di accesso. Sostituisci la tua infrastruttura jump-box esistente con questo servizio gestito.

Fase 4: Sicurezza

7. Sicurezza DNS e risoluzione dei nomi privati

Mantieni lo schema di denominazione DNS precedente durante la migrazione. Le macchine virtuali di cui è stata eseguita la migrazione devono risolvere i nomi host locali e i sistemi locali devono risolvere i nomi ospitati Azure. Configurare DNS di Azure sistema di risoluzione privato per l'inoltro bidirezionale. Mantenere le convenzioni di denominazione DNS esistenti per evitare la riconfigurazione dell'applicazione.

8. Accesso a Internet in uscita

Centralizzare tutto il traffico Internet in uscita attraverso il firewall hub. Disattivare l'accesso in uscita predefinito sulle macchine virtuali spoke e instradare il traffico in uscita tramite Firewall di Azure usando route definite dall'utente (UDR). Questo approccio rispecchia il modello locale esistente in cui un firewall perimetrale controlla tutto il traffico associato a Internet.

9. Firewall di Azure

Distribuisci Firewall di Azure nella VNet hub per il controllo centralizzato del traffico est-ovest (tra le spoke) e nord-sud (in uscita). Convertire i criteri firewall locali in regole di Firewall di Azure. Usare le regole di rete per il traffico non HTTP e le regole dell'applicazione per il filtro HTTP/HTTPS con destinazioni FQDN (Fully Qualified Domain Name).

Fase 5: Operazioni

10. Monitoraggio e osservabilità della rete

Configurare Azure Network Watcher e Monitoraggio connessione per convalidare la baseline di migrazione. Verificare che i percorsi di connettività funzionino come previsto. Misurare la latenza tra Azure macchine virtuali e sistemi locali e stabilire benchmark delle prestazioni prima di eseguire la migrazione dei carichi di lavoro di produzione.

Articoli condizionali

Non tutte le migrazioni in modalità lift-and-shift hanno bisogno dello stesso set di articoli. Includere questi articoli in base ai requisiti specifici:

Condition Articolo Quando includere
Applicazione con connessione Internet Internet in ingresso L'applicazione migrata deve essere raggiungibile da Internet
Necessario il bilanciamento del carico di livello 7 (L7) Recapito e prestazioni delle applicazioni Il carico di lavoro richiede gateway applicazione di Azure o Frontdoor di Azure
Applicazione Web pubblica Web application firewall L'applicazione migrata gestisce il traffico HTTP/HTTPS pubblico
Esposizione dell’IP pubblico Protezione DDoS Hai requisiti di disponibilità per le risorse con endpoint pubblici
Multi-area necessaria Rete multiregionale È necessario il disaster recovery o la distribuzione in modalità attiva-attiva
Connettività tra aree Connettività tra aree e multicloud Altre regioni o altri cloud sono inclusi nell'ambito.
Transito su scala di filiale Rete WAN virtuale di Azure Sono presenti molti archi di connettività o filiali
Componenti PaaS Accesso privato PaaS Alcuni componenti del carico di lavoro passano ai servizi PaaS Azure
Ambiente VNet di grandi dimensioni Gestione centralizzata della rete La migrazione crea un ecosistema multi-VNet che richiede una governance centralizzata

Sommario

Seguendo questo percorso di lettura, si è progettata una rete hub-and-spoke con servizi condivisi centralizzati, si è stabilita la connettività VPN o ExpressRoute verso l'ambiente on-premises, si è distribuito Firewall di Azure per l'ispezione centralizzata del traffico, si è configurato l'inoltro DNS per la risoluzione dei nomi, si è protetto l'accesso alle macchine virtuali tramite Azure Bastion e si è impostato il monitoraggio per convalidare la migrazione. Questa architettura supporta i carichi di lavoro migrati, offrendoti al contempo sicurezza e visibilità operativa centralizzate.

Passaggi successivi

  • Last updated on