Condividi tramite

Topologia di rete hub-spoke in Azure

Azure Bastion
Firewall di Azure
Azure Network Watcher
Rete virtuale di Azure
Gateway VPN di Azure

Questa architettura di riferimento implementa un modello di rete hub-spoke con i componenti dell'infrastruttura dell'hub gestito dal cliente. Il modello di rete hub-spoke, noto anche come hub e spoke, è la topologia di rete consigliata dal Cloud Adoption Framework per Azure. Vedere Define una topologia di rete Azure per comprendere perché questa topologia è considerata una procedura consigliata per molte organizzazioni.

Per una soluzione di infrastruttura dell'hub gestita da Microsoft, vedere topologia di rete Hub-spoke con rete WAN virtuale di Azure.

Architecture

Diagramma che mostra l'architettura della topologia della rete virtuale hub-spoke.

Scaricare un file Visio di questa architettura.

Concetti relativi a Hub-spoke

Le topologie di rete hub-spoke includono in genere molti dei concetti architetturali seguenti:

  • Hub virtual network: La rete virtuale hub ospita servizi di rete condivisi Azure. I carichi di lavoro ospitati nelle reti virtuali spoke possono usare questi servizi. La rete virtuale hub è il punto centrale di connettività per le reti cross-premise. L'hub contiene il punto principale di accesso e offre un modo per connettere uno spoke a un altro per il traffico tra reti virtuali quando necessario.

    Un hub è una risorsa a livello di area. Se i carichi di lavoro si trovano in più aree, posizionare un hub in ogni area. L'hub offre le funzionalità e le opzioni seguenti:

    • Gateway Cross-premises: Possibilità di connettersi e integrare ambienti di rete diversi. Questo gateway è in genere una VPN o un circuito Azure ExpressRoute.

    • Controllo in uscita: Gestione e regolamentazione del traffico in uscita originato nelle reti virtuali in peering spoke.

    • Controllo in ingresso: Gestione e regolamentazione facoltativa del traffico in ingresso verso gli endpoint esistenti nelle reti virtuali spoke connesse tramite peering.

    • Accesso remoto: Il modo in cui si accede ai singoli carichi di lavoro nelle reti spoke da posizioni di rete esterne alla rete dello spoke. Questo accesso potrebbe avere come destinazione i dati o il piano di controllo del carico di lavoro.

    • Accesso spoke remoto per le macchine virtuali (VM): Una soluzione di connettività remota inter-organizzazioni per Desktop remoto Protocol (RDP) e Secure Shell Protocol (SSH) alle macchine virtuali distribuite in reti spoke.

    • Routing: Gestione del traffico tra l'hub e gli spoke connessi. Il routing supporta comunicazioni sicure ed efficienti.

  • Reti virtuali spoke: Le reti virtuali spoke isolano e gestiscono i carichi di lavoro separatamente in ogni spoke. Ogni carico di lavoro può includere più livelli, con più subnet connesse tramite Azure servizi di bilanciamento del carico. Gli spoke possono esistere in sottoscrizioni diverse e rappresentano ambienti diversi, ad esempio produzione e non produzione. Un carico di lavoro può essere distribuito tra più "spoke".

    Nella maggior parte degli scenari, si dovrebbe collegare ogni spoke a una singola rete hub nella stessa regione.

    Le reti spoke seguono le regole per l'accesso in uscita predefinito. Uno scopo principale della topologia di rete hub-spoke è indirizzare il traffico Internet in uscita attraverso i meccanismi di controllo nell'hub.

  • Connettività tra reti virtuali: La connettività di rete virtuale facilita la comunicazione tra reti virtuali isolate. Un meccanismo di controllo applica le autorizzazioni e determina la direzione consentita delle comunicazioni tra reti. Un hub offre un'opzione per supportare le connessioni tra reti selezionate per il flusso attraverso la rete centralizzata.

  • DNS: Le soluzioni hub-spoke offrono spesso una soluzione DNS (Domain Name System) usata da tutti gli spoke con peering, soprattutto per il routing cross-premise e i record DNS degli endpoint privati.

Components

  • Rete virtuale di Azure è il blocco predefinito fondamentale per le reti private in Azure. Rete virtuale fornisce comunicazioni sicure tra le risorse Azure, ad esempio le macchine virtuali e le reti cross-premise, Internet e tra loro.

    In questa architettura le reti virtuali si connettono all'hub usando connessioni Rete virtuale peering, che sono connessioni nontransitive e a bassa latenza tra reti virtuali. Le reti virtuali con peering possono scambiare traffico tramite il backbone Azure senza un router. In un'architettura hub-spoke usare il peering diretto tra reti virtuali solo in circostanze particolari.

  • Azure Bastion è un servizio completamente gestito che fornisce l'accesso RDP e SSH alle macchine virtuali senza esporre gli indirizzi IP pubblici. In questa architettura, Azure Bastion viene usata come offerta gestita per supportare l'accesso diretto alle macchine virtuali tra spoke connessi.

  • Firewall di Azure è un servizio di sicurezza di rete gestito basato sul cloud che protegge le risorse Rete virtuale. Questo servizio firewall a stato offre una disponibilità elevata integrata e una scalabilità cloud illimitata per aiutarti a creare, applicare e registrare le politiche di connettività delle applicazioni e delle reti tra sottoscrizioni e reti virtuali.

    In questa architettura Firewall di Azure ha più ruoli potenziali. Il firewall è il punto di uscita principale per il traffico da reti virtuali spoke con peering a Internet. Il firewall può anche esaminare il traffico in ingresso usando regole idps (network intrusion detection and prevention system). Il firewall può anche funzionare come server proxy DNS per supportare le regole di traffico FQDN (Fully Qualified Domain Name).

  • Gateway VPN di Azure è un gateway di rete virtuale che invia traffico crittografato tra una rete virtuale in Azure e reti diverse tramite Internet pubblico. È anche possibile usare Gateway VPN per inviare traffico crittografato tra altre reti virtuali sulla rete Microsoft.

    In questa architettura, il Gateway VPN può connettere gli hub alla rete remota. Gli spoke in genere non distribuiscono il proprio gateway VPN. Usano la soluzione centralizzata fornita dall'hub. Per gestire questa connettività, è necessario stabilire la configurazione del routing.

  • Un gateway ExpressRoute scambia route IP e instrada il traffico di rete tra la rete locale e la rete virtuale Azure. In questa architettura ExpressRoute può fungere da alternativa al Gateway VPN per connettere gli spokes a una rete remota. Gli spoke non distribuiscono un proprio gateway ExpressRoute. Usano la soluzione centralizzata fornita dall'hub. Per gestire questa connettività, è necessario stabilire la configurazione del routing.

  • Monitoraggio di Azure può raccogliere, analizzare e agire sui dati di telemetria da ambienti cross-premise, tra cui Azure e in locale. Monitoraggio di Azure consente di ottimizzare le prestazioni e la disponibilità delle applicazioni e di identificare rapidamente i problemi. In questa architettura, Monitoraggio di Azure è la destinazione di log e metriche per le risorse dell'hub e per le metriche di rete. Monitoraggio di Azure può anche funzionare come sink di registrazione per le risorse nelle reti spoke. Ogni carico di lavoro spoke determina la propria configurazione di registrazione dei log, e questa architettura non richiede l'invio dei log spoke ad Monitoraggio di Azure.

Alternatives

Questa architettura implica la creazione, la configurazione e la manutenzione di virtualNetworkPeerings, routeTablese subnets. gestione rete virtuale di Azure è un servizio di gestione che consente di raggruppare, configurare, distribuire e gestire reti virtuali su larga scala tra sottoscrizioni, aree e Microsoft Entra directory di Azure.

Con programma di traduzione è possibile definire gruppi di network per identificare e segmentare logicamente le reti virtuali. È anche possibile usare i gruppi connessi per fornire la comunicazione tra gruppi di reti virtuali come se fossero connessi manualmente. Questo approccio aggiunge un livello di astrazione per descrivere la topologia di rete desiderata senza modificarne l'implementazione.

È consigliabile valutare se è consigliabile usare programma di traduzione per ottimizzare le operazioni di gestione della rete. Per determinare se programma di traduzione fornisce valore netto per le dimensioni e la complessità della rete, confrontare il costo del servizio con i vantaggi operativi e di risparmio di tempo.

rete WAN virtuale di Azure

Questa architettura descrive un modello di rete che include i componenti dell'infrastruttura dell'hub gestito dal cliente. Per una soluzione di infrastruttura dell'hub gestita da Microsoft, vedere topologia di rete Hub-spoke che usa rete WAN virtuale di Azure.

I vantaggi dell'uso di una configurazione hub-spoke gestita dal cliente includono:

  • Risparmio sui costi
  • Superamento dei limiti delle sottoscrizioni
  • Isolamento dei carichi di lavoro
  • Flexibility
    • Maggiore controllo sulla modalità di distribuzione delle appliance virtuali di rete, ad esempio il numero di schede di interfaccia di rete, il numero di istanze o le dimensioni di calcolo
    • Utilizzo di appliance virtuali di rete (NVA) non supportate da rete WAN virtuale

Dettagli dello scenario

Questa architettura di riferimento implementa un modello di rete hub-spoke in cui la rete virtuale hub funge da punto centrale di connettività a molte reti virtuali spoke. Le reti virtuali spoke si connettono all'hub e possono isolare i carichi di lavoro. È anche possibile supportare scenari cross-premise usando l'hub per connettersi alle reti locali.

Per altre informazioni, vedere Topologia di rete Hub-spoke.

Scenari avanzati

La tua architettura potrebbe differire dalla semplice architettura hub-spoke descritta in questo articolo. L'elenco seguente descrive le linee guida per gli scenari avanzati:

Potenziali casi d'uso

Gli usi tipici per un'architettura hub-spoke includono carichi di lavoro che:

  • Avere diversi ambienti che richiedono servizi condivisi. Ad esempio, un carico di lavoro potrebbe avere ambienti di sviluppo, test e produzione. I servizi condivisi possono includere ID DNS, NTP (Network Time Protocol) o Active Directory Domain Services (AD DS). I servizi condivisi vengono inseriti nella rete virtuale dell'hub e ogni ambiente viene distribuito in uno spoke diverso al fine di mantenere l'isolamento.

  • Non richiedono la connettività tra loro, ma richiedono l'accesso ai servizi condivisi.

  • Richiedere il controllo centrale sulla sicurezza, come un firewall nella rete perimetrale (nota anche come DMZ, zona demilitarizzata e subnet schermata) nel hub e una gestione segregata dei carichi di lavoro in ogni *spoke*.

  • Richiedere il controllo centrale sulla connettività, ad esempio connettività selettiva o isolamento tra spoke di ambienti o carichi di lavoro specifici.

Recommendations

È possibile applicare le raccomandazioni seguenti alla maggior parte degli scenari. Seguire queste indicazioni, a meno che non si disponga di un requisito specifico che le escluda.

Gruppi di risorse, sottoscrizioni e aree

Questa soluzione di esempio usa un singolo gruppo di risorse Azure. È anche possibile implementare l'hub e ogni spoke in gruppi di risorse e sottoscrizioni diversi.

Quando si esegue il peering di reti virtuali in sottoscrizioni diverse, è possibile associare le sottoscrizioni a tenant di Microsoft Entra uguali o differenti. Questa flessibilità offre una gestione decentralizzata di ogni carico di lavoro e gestisce i servizi condivisi nell'hub. Per ulteriori informazioni, vedere Creare un peering di rete virtuale tra sottoscrizioni diverse e tenant Microsoft Entra.

Azure zone di destinazione

L'architettura della zona di destinazione Azure si basa sulla topologia hub-spoke. In tale architettura, un team centralizzato della piattaforma gestisce le risorse e la rete condivise dell'hub, mentre gli spoke condividono un modello di coproprietà con il team della piattaforma e il team responsabile del carico di lavoro che utilizza la rete spoke. Tutti gli hub si trovano in una sottoscrizione di connettività per la gestione centralizzata. Le reti virtuali spoke esistono in molte sottoscrizioni di carico di lavoro singole, denominate sottoscrizioni dell'area di destinazione dell'applicazione.

Subnet della rete virtuale

Le raccomandazioni seguenti illustrano come configurare le subnet nella rete virtuale.

GatewaySubnet

Il gateway di rete virtuale richiede questa subnet. È anche possibile usare una topologia hub-spoke senza un gateway se non è necessaria la connettività di rete cross-premise.

Creare una subnet del gateway con un intervallo di indirizzi IP di almeno /26 o superiore denominato GatewaySubnet. L'intervallo di indirizzi /26 offre scalabilità sufficiente per evitare limitazioni delle dimensioni del gateway e supportare circuiti ExpressRoute aggiuntivi in futuro. Per altre informazioni sulla configurazione del gateway, vedere Configurare connessioni coesistenti da sito a sito e ExpressRoute tramite PowerShell.

AzureFirewallSubnet

Creare una subnet denominata AzureFirewallSubnet con un intervallo di indirizzi di almeno /26. È consigliabile /26 usare le dimensioni minime per coprire le limitazioni future delle dimensioni. Questa subnet non supporta i gruppi di sicurezza di rete.This subnet doesn't support network security groups (NSG).

Firewall di Azure richiede questa subnet. Se usi un'appliance virtuale di rete partner, segui le sue richieste di rete.

Connettività di rete spoke

Il peering di rete virtuale o i gruppi connessi sono relazioni nontransitive tra reti virtuali. Se sono necessarie reti virtuali spoke per connettersi tra loro, aggiungere una connessione di peering tra questi spoke o inserirle nello stesso gruppo di rete.

Connessioni spoke tramite Firewall di Azure o un'appliance di rete virtuale

Il numero di peering di rete virtuale per ciascuna rete virtuale è limitato. Se sono presenti molti spoke che devono connettersi tra loro, è possibile che non si disponga di connessioni di peering sufficienti. I gruppi connessi presentano anche limitazioni. Per altre informazioni, vedere Limiti di rete e Limiti dei gruppi connessi.

In questo scenario è consigliabile usare route definite dall'utente per forzare l'invio del traffico spoke a Firewall di Azure o un'altra appliance virtuale di rete che funge da router nell'hub. Questa modifica consente agli spoke di connettersi tra loro. Per supportare questa configurazione, implementare Firewall di Azure con la configurazione del tunnel forzata attivata. Per altre informazioni, vedere Firewall di Azure tunneling forzato.

La topologia in questa progettazione architettonica facilita i flussi in uscita. Anche se Firewall di Azure è principalmente per la sicurezza in uscita, può anche essere un punto di ingresso. Per altre considerazioni sul routing di ingresso dell'NVA dell'hub, vedere Firewall di Azure e gateway applicazione di Azure per le reti virtuali.

Connessioni spoke a reti remote tramite un gateway hub

Per configurare gli spoke per comunicare con reti remote tramite un gateway hub, è possibile usare peering di rete virtuale o gruppi di rete connessi. Per usare i peering di rete virtuale, aprire la configurazione del peering di rete virtuale e completare le azioni seguenti:

  • Configurare la connessione di peering nell'hub per Consentire il transito del gateway.
  • Configurare la connessione di peering in ogni braccio per usare il gateway della rete virtuale remota.
  • Configurare tutte le connessioni di peering per Consenti traffico inoltrato.

Per ulteriori dettagli, consultare Crea un peering di rete virtuale.

Per usare i gruppi di rete connessi:

  1. In programma di traduzione creare un gruppo di rete e aggiungere reti virtuali membro.
  2. Creare una configurazione di connettività hub-spoke.
  3. Per i gruppi di rete spoke selezionare Hub come gateway.

Per altre informazioni, vedere Creare una topologia hub-spoke usando programma di traduzione.

Comunicazioni di rete spoke

Le reti virtuali spoke possono comunicare tra loro in due modi principali:

  • Comunicazione tramite un'appliance virtuale di rete, ad esempio un firewall e un router. Questo metodo aggiunge un hop tra i due spoke.

  • Comunicazione tramite peering di rete virtuale o connettività diretta di programma di traduzione tra i spoke. Questo approccio non aggiunge un hop tra i due raggi ed è consigliato per ridurre al minimo la latenza.

collegamento privato di Azure può esporre in modo selettivo singole risorse ad altre reti virtuali. Ad esempio, è possibile usare collegamento privato per esporre un servizio di bilanciamento del carico interno a una rete virtuale diversa senza la necessità di formare o gestire relazioni di peering o routing.

Per altre informazioni sui modelli di rete spoke-to-spoke, vedere Opzioni di connettività della rete virtuale e comunicazione spoke-to-spoke.

Comunicazione tramite un NVA (appliance virtuale di rete)

Se è necessaria la connettività tra spoke, è consigliabile distribuire Firewall di Azure o un'altra appliance virtuale di rete nell'hub. Creare quindi route per inoltrare il traffico da uno spoke al firewall o all'appliance di rete virtuale (NVA), che può quindi instradare al secondo spoke. In questo scenario è necessario configurare le connessioni di peering per accettare il traffico inoltrato.

Diagramma che mostra il routing tra spoke che usano Firewall di Azure.

È anche possibile usare un gateway VPN per instradare il traffico tra spoke, anche se questa scelta influisce sulla latenza e sulla velocità effettiva. Per altre informazioni, vedere Configurare il transito tramite gateway VPN per il peering di reti virtuali.

Valutare i servizi condivisi nell'hub per garantire che l'hub sia in grado di ridimensionarsi per un numero maggiore di raggi. Ad esempio, se l'hub fornisce servizi firewall, prendere in considerazione i limiti di larghezza di banda della soluzione firewall quando si aggiungono più spoke. È possibile spostare alcuni di questi servizi condivisi in un secondo livello di hub.

Comunicazione diretta tra reti spoke

Per connettersi direttamente tra reti virtuali spoke senza instradare il traffico attraverso la rete virtuale hub, è possibile creare connessioni di peering tra spoke o attivare la connettività diretta per il gruppo di rete. È consigliabile limitare il peering o la connettività diretta alle reti virtuali spoke che fanno parte dello stesso ambiente e dello stesso carico di lavoro.

Quando si usa programma di traduzione, è possibile aggiungere manualmente reti virtuali spoke ai gruppi di rete o aggiungere automaticamente reti in base alle condizioni definite dall'utente.

Il seguente diagramma illustra come utilizzare programma di traduzione per la connettività diretta tra spoke.

Diagramma che mostra l'uso di programma di traduzione per la connettività diretta tra spokes.

Considerations

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che è possibile usare per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Reliability

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'affidabilità.

Usare zone di disponibilità per i servizi Azure nell'hub che li supportano.

È consigliabile usare almeno un hub per area e connettere solo gli spoke dalla stessa area a tali hub. Questa configurazione consente alle regioni di paratia di evitare guasti nell'hub di un'area, i quali potrebbero causare guasti diffusi di instradamento della rete in regioni non correlate.

Per una disponibilità più elevata, è possibile usare ExpressRoute e una VPN per il failover. Per altre informazioni, vedere Connettere una rete locale ad Azure usando ExpressRoute con failover VPN e Progettare ExpressRoute per l'alta disponibilità.

A causa del modo in cui Firewall di Azure implementa le regole dell'applicazione FQDN, assicurarsi che tutte le risorse in uscita attraverso il firewall usino lo stesso provider DNS del firewall stesso. In caso contrario, Firewall di Azure potrebbe bloccare il traffico legittimo perché la risoluzione IP del firewall per l'FQDN differisce dalla risoluzione IP dell'origine del traffico per lo stesso FQDN. È possibile includere il proxy di Firewall di Azure nella risoluzione DNS dello spoke per mantenere sincronizzati i FQDN con l'origine del traffico e con Firewall di Azure.

Security

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per la sicurezza.

Per proteggersi dagli attacchi DDoS, attivare Azure Protezione DDoS in qualsiasi rete virtuale perimetrale. Qualsiasi risorsa con un indirizzo IP pubblico è soggetta a un attacco DDoS. Gli indirizzi IP pubblici seguenti devono essere protetti anche se i carichi di lavoro non sono esposti pubblicamente:

  • Firewall di Azure indirizzi IP pubblici
  • Indirizzi IP pubblici del gateway VPN
  • Indirizzo IP pubblico del piano di controllo ExpressRoute

Per ridurre al minimo il rischio di accesso non autorizzato e applicare criteri di sicurezza rigorosi, impostare sempre regole esplicite deny nei gruppi di sicurezza di rete.

Usare la versione Firewall di Azure Premium per attivare l'ispezione, l'IDPS e il filtro URL di Transport Layer Security (TLS).

sicurezza del gestore di rete virtuale

Per garantire un set di base di regole di sicurezza, associare le regole di amministratore della sicurezza alle reti virtuali nei gruppi di rete. Le regole di amministrazione della sicurezza hanno la precedenza e vengono valutate prima delle regole del gruppo di sicurezza di rete. Le regole di amministrazione della sicurezza supportano la definizione delle priorità, i tag del servizio e i protocolli di livello di rete (L3) e il livello di trasporto (L4).

Usare programma di traduzione deployments per facilitare l'implementazione controllata delle modifiche potenzialmente importanti alle regole di sicurezza del gruppo di rete.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Ottimizzazione costi.

Quando distribuisci e gestisci reti hub-spoke, considera i seguenti fattori correlati ai costi. Per altre informazioni, vedere Prezzi della rete virtuale.

Costi di Firewall di Azure

Questa architettura distribuisce un'istanza di Firewall di Azure nella rete hub. L'uso di una distribuzione Firewall di Azure come soluzione condivisa usata da più carichi di lavoro può ridurre significativamente i costi del cloud rispetto ad altre appliance virtuali di rete. Per altre informazioni, vedere Firewall di Azure e NVA.

Per usare le risorse distribuite in modo efficace, scegliere le dimensioni Firewall di Azure appropriate. Decidere le funzionalità necessarie e il livello più adatto al set corrente di carichi di lavoro. Per altre informazioni sugli SKU di Firewall di Azure disponibili, vedere Che è Firewall di Azure?

Peering diretto

Per ridurre o eliminare i costi di elaborazione Firewall di Azure, usare in modo selettivo il peering diretto o altre comunicazioni spoke-to-spoke che ignorano l'hub. I risparmi possono essere significativi per le reti che hanno carichi di lavoro con alto throughput e comunicazioni a rischio ridotto tra gli spokes, come la sincronizzazione del database o le operazioni di trasferimento di file di grandi dimensioni.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e lo mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'eccellenza operativa.

Attivare le impostazioni di diagnostica per tutti i servizi, ad esempio Azure Bastion, Firewall di Azure e il gateway cross-premise. Per ridurre i costi, disattivare le impostazioni non correlate alle operazioni. Le risorse come Firewall di Azure possono generare volumi di log di grandi dimensioni e possono comportare costi di monitoraggio elevati.

Usare Monitoraggio connessione per il monitoraggio end-to-end, al fine di rilevare le anomalie e identificare e risolvere i problemi di rete.

Usare Azure Network Watcher per monitorare e risolvere i problemi dei componenti di rete, incluso l'uso di analisi traffic per mostrare i sistemi nelle reti virtuali che generano la maggior parte del traffico. È possibile usare l'analisi del traffico per identificare potenziali strozzature.

Se si usa ExpressRoute, usare Azure Traffic Collector per analizzare i flussi di log per il traffico di rete inviato sui circuiti ExpressRoute. Traffic Collector offre visibilità sul traffico che passa su router perimetrali aziendali di Microsoft.

Usare le regole basate su FQDN in Firewall di Azure per i protocolli non HTTP(S) o per quando si configura SQL Server. L'uso di FQDN riduce il carico di gestione rispetto alla gestione dei singoli indirizzi IP.

Pianificare l'indirizzamento IP in base ai requisiti di peering. Assicurarsi che lo spazio indirizzi non si sovrapponga a posizioni in sedi ibride e posizioni Azure.

Automazione con programma di traduzione

Per gestire centralmente la connettività e i controlli di sicurezza, usare programma di traduzione per creare nuove topologie di rete virtuale hub-spoke o eseguire l'onboarding di topologie esistenti. Usare programma di traduzione per preparare le topologie di rete hub-spoke per una crescita futura su larga scala tra più sottoscrizioni, gruppi di gestione e aree.

Gli scenari di esempio d'uso di programma di traduzione includono:

  • Democratizzazione della gestione della rete virtuale spoke a gruppi come unità aziendali o team applicativi. La democratizzazione può comportare un numero elevato di requisiti di connettività da rete virtuale a rete virtuale e regole di sicurezza di rete.

  • Standardizzazione di più architetture di replica in più aree Azure per garantire un footprint globale per le applicazioni.

Per garantire la connettività uniforme e le regole di sicurezza di rete, è possibile usare gruppi di rete per raggruppare le reti virtuali in qualsiasi sottoscrizione, gruppo di gestione o area nello stesso tenant Microsoft Entra. È possibile eseguire automaticamente o manualmente l'onboarding delle reti virtuali nei gruppi di rete tramite assegnazioni di appartenenza dinamiche o statiche.

Definire l'individuabilità delle reti virtuali in programma di traduzione usando scopes. Gli ambiti rendono flessibili le istanze di Network Manager in modo da poter distribuire le responsabilità di gestione tra gruppi di rete virtuale.

Per connettere tra loro le reti virtuali spoke nello stesso gruppo di rete, usare programma di traduzione per implementare il peering di rete virtuale o la connettività diretta. Usare l'opzione mesh globale per estendere la connettività diretta mesh alle reti spoke in regioni differenti. Il diagramma seguente mostra la connettività mesh globale tra aree.

Diagramma che mostra la connettività diretta globale mesh spoke tra le regioni.

È possibile associare reti virtuali all'interno di un gruppo di rete a un set di base di regole di amministrazione della sicurezza. Le regole di amministrazione della sicurezza dei gruppi di sicurezza di rete impediscono ai proprietari della rete virtuale spoke di sovrascrivere le regole di sicurezza di base, ma possono aggiungere proprie regole di sicurezza e NSG. Per un esempio di come usare le regole di amministrazione della sicurezza nelle topologie hub-spoke, vedere Creare una rete hub-spoke protetta.

Per facilitare un'implementazione controllata di gruppi di rete, connettività e regole di sicurezza, le distribuzioni di configurazione di programma di traduzione consentono di rilasciare in modo sicuro le modifiche di configurazione negli ambienti hub-spoke.

Per semplificare il processo di creazione e gestione delle configurazioni di rotte, è possibile usare la gestione automatica delle UDR (route definite dall'utente) in programma di traduzione.

Per centralizzare la gestione degli indirizzi IP, è possibile utilizzare IP address management (IPAM) nel programma di traduzione. IPAM (La gestione degli indirizzi IP) impedisce conflitti nello spazio degli indirizzi IP tra le reti virtuali locali e cloud.

Per iniziare a usare programma di traduzione, vedere Creare una topologia hub-spoke usando programma di traduzione.

Efficienza delle prestazioni

L'efficienza delle prestazioni si riferisce alla capacità del carico di lavoro di ridimensionarsi per soddisfare in modo efficiente le esigenze degli utenti. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per l'efficienza delle prestazioni.

Per i carichi di lavoro che comunicano dall'ambiente locale alle macchine virtuali in una rete virtuale Azure che richiedono bassa latenza e larghezza di banda elevata, è consigliabile usare ExpressRoute FastPath. Migliorare le prestazioni usando FastPath per inviare il traffico direttamente da locale a macchine virtuali nella rete virtuale e ignorare il gateway di rete virtuale ExpressRoute.

Per le comunicazioni spoke-to-spoke che richiedono una bassa latenza, è possibile configurare la rete spoke-spoke.For spoke to-spoke communications that require low-latency, you can set up spoke-to-spoke networking.

Scegliere uno SKU del gateway che soddisfi i requisiti, ad esempio il numero di connessioni da punto a sito o da sito a sito, i pacchetti necessari al secondo, i requisiti di larghezza di banda o i flussi TCP.

Per i flussi sensibili alla latenza, ad esempio SAP o l'accesso all'archiviazione, è possibile ignorare Firewall di Azure o il routing dell'hub. Per decidere l'approccio migliore, è possibile testare la latenza introdotta da Firewall di Azure. È possibile usare funzionalità come peering di rete virtuale, che connette due o più reti oppure è possibile usare collegamento privato per connettersi a un servizio tramite un endpoint privato nella rete virtuale.

È possibile ridurre la velocità effettiva usando Firewall di Azure funzionalità come IDPS. Per altre informazioni, vedere prestazioni di Firewall di Azure.

Implementare questo scenario

Questa implementazione include una rete virtuale hub e due satelliti connessi e distribuisce un'istanza di Firewall di Azure e un host di Azure Bastion. Facoltativamente, la distribuzione può includere macchine virtuali nella prima rete spoke e in un gateway VPN. Per creare connessioni di rete, è possibile scegliere tra il peering della rete virtuale o i gruppi connessi di programma di traduzione. Ogni metodo include diverse opzioni di distribuzione.

Contributors

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autori principali:

Altri collaboratori:

Per visualizzare i profili di LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi