Rete spoke-to-spoke

I modelli di progettazione di rete più comuni in Azure comportano la creazione di topologie di rete virtuale hub-spoke in una o più aree di Azure, facoltativamente connesse alle reti locali tramite Azure ExpressRoute o tunnel VPN (Site-to-Site Virtual Private Network) tramite la rete Internet pubblica.

La maggior parte delle guide di progettazione si concentra sul traffico delle applicazioni verso tali reti virtuali dagli utenti nelle reti interne, locali o da Internet (che in genere il settore designa il traffico nord-sud, perché è spesso rappresentato da linee verticali nei diagrammi di rete). Questo articolo è incentrato su vari modelli disponibili per il traffico est-ovest. Ovvero, i flussi di comunicazione tra i carichi di lavoro distribuiti nelle reti virtuali di Azure, all'interno di un'area o in aree diverse.

Assicurarsi che la progettazione di rete soddisfi i requisiti per il traffico east-west è fondamentale per fornire prestazioni, scalabilità e resilienza alle applicazioni in esecuzione in Azure.

Potenziali casi d'uso

Il traffico spoke-to-spoke può essere importante in diversi scenari:

• Diversi livelli di una singola applicazione si trovano in reti virtuali separate. Ad esempio, i server di rete perimetrale (noti anche come server di rete perimetrale) in una rete virtuale perimetrale comunicano con i servizi dell'applicazione in una rete virtuale interna.
• I carichi di lavoro delle applicazioni in ambienti diversi (sviluppo, gestione temporanea, produzione) devono replicare i dati tra loro.
• Applicazioni o microservizi diversi devono comunicare tra loro.
• I database devono replicare i dati tra aree per garantire la continuità aziendale in caso di emergenza.
• Gli utenti si trovano all'interno di reti virtuali di Azure. Ad esempio, usano Desktop virtuale Azure.

Modelli e topologie per la comunicazione tra spoke

Esistono due topologie principali che è possibile usare nelle progettazioni di Azure che intersecano più reti virtuali: hub tradizionale e spoke e Azure rete WAN virtuale. In un ambiente rete WAN virtuale, Microsoft gestisce la rete virtuale hub e tutti gli elementi all'interno di esso. In un ambiente hub-spoke tradizionale si gestisce la rete virtuale hub.

rete WAN virtuale e topologie hub-spoke sono entrambi esempi di architetture in cui i carichi di lavoro vengono eseguiti in reti virtuali spoke e la connettività all'ambiente locale è centralizzata in una rete virtuale hub. Molti dei concetti illustrati in questo articolo si applicano sia alle progettazioni hub-spoke che a rete WAN virtuale.

Esistono due modelli principali per connettere le reti virtuali spoke tra loro:

• Gli spoke si connettono direttamente l'uno all'altro. I peering di rete virtuale o i tunnel VPN vengono creati tra le reti virtuali spoke per fornire connettività diretta senza attraversare la rete virtuale hub.
• Gli spoke comunicano tramite un'appliance di rete. Ogni rete virtuale spoke ha un peering per rete WAN virtuale o per una rete virtuale hub. Un'appliance instrada il traffico dallo spoke allo spoke. L'appliance può essere gestita da Microsoft (come con rete WAN virtuale) o dall'utente.

Modello 1: spoke direttamente connessi tra loro

Le connessioni dirette tra spoke offrono in genere una velocità effettiva, una latenza e una scalabilità migliori rispetto alle connessioni che passano attraverso un'appliance virtuale di rete (NVA) in un hub. L'invio del traffico tramite appliance virtuali di rete può aggiungere latenza al traffico se le appliance virtuali di rete si trovano in una zona di disponibilità diversa e almeno due peering di rete virtuale devono essere incrociati quando il traffico viene inviato tramite l'hub. Sono disponibili diverse opzioni per la connessione diretta di due reti virtuali spoke: peering di rete virtuale, Azure Rete virtuale Manager e tunnel VPN.

• Peering di rete virtuale. I vantaggi dei peering di rete virtuale diretta su spoke sono:

  • Costo inferiore, perché sono necessari meno hop di peering di rete virtuale.
  • Prestazioni migliori, perché il traffico non deve attraversare alcuna appliance di rete che introduce latenza o potenziali colli di bottiglia.

  Altri scenari includono la connettività tra tenant. Potrebbe tuttavia essere necessario esaminare il traffico tra reti virtuali spoke, che potrebbero richiedere l'invio del traffico tramite dispositivi di rete centralizzati nella rete virtuale hub.

• Azure Rete virtuale Manager. Oltre ai vantaggi offerti dal peering di rete virtuale, Azure Rete virtuale Manager offre un servizio di gestione che consente di gestire gli ambienti di rete virtuale e di creare connettività su larga scala. Usando Azure Rete virtuale Manager, è possibile creare tre tipi di topologie tra sottoscrizioni, sia per le reti virtuali esistenti che per le nuove reti virtuali:

  • Hub e spoke con spoke che non sono connessi tra loro.

  • Hub e spoke con spoke direttamente connessi tra loro, senza alcun hop al centro.

  • Un gruppo mesh di reti virtuali interconnesse.

    

    Scaricare tutti i diagrammi di Visio in questo articolo.

    Quando si crea una topologia hub-spoke con Azure Rete virtuale Manager in cui gli spoke sono connessi tra loro, la connettività diretta tra reti virtuali spoke nello stesso gruppo di rete viene creata automaticamente in modo bidirezionale. Usando Azure Rete virtuale Manager, è possibile creare reti virtuali spoke in modo statico o dinamico membri di un gruppo di rete specifico, che crea automaticamente la connettività per qualsiasi rete virtuale.

    È possibile creare più gruppi di rete per isolare i cluster di reti virtuali spoke dalla connettività diretta. Ogni gruppo di rete fornisce la stessa area e supporto in più aree per la connettività spoke-to-spoke. Assicurarsi di rimanere al di sotto dei limiti massimi per Azure Rete virtuale Manager descritti nelle domande frequenti su Azure Rete virtuale Manager.

• Tunnel VPN che connettono reti virtuali. È possibile configurare i servizi VPN per connettere direttamente le reti virtuali spoke usando gateway VPN Microsoft o appliance virtuali di rete VPN di terze parti. Il vantaggio di questa opzione è che le reti virtuali spoke si connettono tra cloud commerciali e sovrani all'interno dello stesso provider di servizi cloud o connettività tra cloud. Inoltre, se in ogni rete virtuale spoke sono presenti appliance di rete WAN (SD-WAN) definite dal software, questa configurazione può facilitare l'uso del piano di controllo e della funzionalità del provider di terze parti per gestire la connettività di rete virtuale.

  Questa opzione consente anche di soddisfare i requisiti di conformità per la crittografia del traffico tra reti virtuali in un singolo data center di Azure non già fornito dalla crittografia MACsec. Questa opzione presenta tuttavia un proprio set di problemi a causa dei limiti di larghezza di banda dei tunnel IPsec (1,25 Gbps per tunnel) e dei vincoli di progettazione di avere gateway di rete virtuale in reti virtuali hub e spoke: se la rete virtuale spoke ha un gateway di rete virtuale, non può essere connessa a rete WAN virtuale o usare un gateway di rete virtuale dell'hub per connettersi alle reti locali.

Modello 1: Singola area

Indipendentemente dalla tecnologia usata per connettere le reti virtuali spoke tra loro, le topologie di rete sono simili a questa per una singola area:

Modello 1: più aree

Le progettazioni che connettono tutte le reti virtuali spoke tra loro possono anche essere estese a più aree. In questa topologia, Azure Rete virtuale Manager è ancora più critico, per ridurre il sovraccarico amministrativo della gestione del numero elevato di connessioni richiesto.

Quando si connettono direttamente reti virtuali spoke tra loro in una topologia completamente con mesh, è necessario considerare il numero potenzialmente elevato di peering di rete virtuale necessari. Il diagramma seguente illustra questo problema. In questo scenario, Azure Rete virtuale Manager è fortemente consigliato in modo da poter creare automaticamente connessioni di rete virtuale.

Modello 2: Spoke che comunicano tramite un'appliance di rete

Invece di connettere le reti virtuali spoke direttamente tra loro, è possibile usare appliance di rete per inoltrare il traffico tra spoke. Le appliance di rete forniscono servizi di rete aggiuntivi come l'ispezione approfondita dei pacchetti e la segmentazione o il monitoraggio del traffico, ma possono introdurre colli di bottiglia di latenza e prestazioni se non sono dimensionati correttamente. Queste appliance si trovano in genere in una rete virtuale hub a cui si connettono gli spoke. Sono disponibili più opzioni per l'uso di un'appliance di rete per inoltrare il traffico tra spoke:

• rete WAN virtuale router hub. Completamente gestito da Microsoft, rete WAN virtuale contiene un router virtuale che attira il traffico dagli spoke e lo instrada a un'altra rete virtuale connessa a rete WAN virtuale o alle reti locali tramite ExpressRoute o tunnel VPN da sito a sito o da punto a sito. Il router rete WAN virtuale aumenta e riduce automaticamente le prestazioni, quindi è sufficiente assicurarsi che il volume di traffico tra gli spoke rimanga entro i limiti rete WAN virtuale.

• Firewall di Azure. Firewall di Azure è un'appliance di rete gestita da Microsoft e può essere distribuita nelle reti virtuali hub gestite o in hub di rete WAN virtuale. Può inoltrare pacchetti IP e può anche esaminarli e applicare regole di segmentazione del traffico definite nei criteri. Fornisce la scalabilità automatica fino ai limiti Firewall di Azure in modo che non diventi un collo di bottiglia. Si noti che Firewall di Azure offre funzionalità predefinite per più aree solo se usate con rete WAN virtuale. Senza rete WAN virtuale, è necessario implementare route definite dall'utente per ottenere la comunicazione spoke-to-spoke tra aree.

• Appliance virtuali di rete di terze parti. Se si preferisce usare un'appliance virtuale di rete di un partner Microsoft per eseguire il routing e la segmentazione di rete, è possibile distribuire appliance virtuali di rete in una topologia hub-spoke o rete WAN virtuale. Per altre informazioni, vedere Distribuire appliance virtuali di rete a disponibilità elevata o appliance virtuali di rete in un hub di rete WAN virtuale. È necessario assicurarsi che l'appliance virtuale di rete supporti la larghezza di banda generata dalle comunicazioni inter-spoke.

• Azure Gateway VPN. È possibile usare un gateway VPN di Azure come tipo hop successivo di route definita dall'utente, ma Microsoft non consiglia l'uso di gateway di rete virtuale VPN per instradare il traffico spoke-spoke. Sono progettati per crittografare il traffico verso siti locali o utenti VPN. Ad esempio, non esiste alcuna garanzia della larghezza di banda tra spoke che un gateway VPN può instradare.

• ExpressRoute. In determinate configurazioni, un gateway ExpressRoute può annunciare le route che attirano la comunicazione spoke-to-spoke, inviando traffico al router perimetrale Microsoft, in cui viene instradato allo spoke di destinazione. Microsoft sconsiglia vivamente questo scenario perché introduce la latenza inviando traffico alla rete perimetrale e al back-end Microsoft. Oltre a questo, Microsoft non consiglia questo approccio, a causa del singolo punto di guasto e del grande raggio di esplosione. Questo scenario presenta anche più problemi causati dall'utilizzo eccessivo dell'infrastruttura ExpressRoute (il gateway e i router fisici). Questa pressione aggiuntiva può causare gocce di pacchetti.

Nelle progettazioni di rete hub-spoke con appliance virtuali di rete centralizzate, l'appliance viene in genere inserita nell'hub. I peering di rete virtuale tra reti virtuali hub-spoke devono essere creati manualmente o automaticamente con Azure Rete virtuale Manager:

• Peering di rete virtuale manuali. Questo approccio è sufficiente quando si dispone di un numero ridotto di reti virtuali spoke, ma crea un sovraccarico di gestione su larga scala.

• Azure Rete virtuale Manager. Come indicato in precedenza, Azure Rete virtuale Manager offre funzionalità per gestire gli ambienti di rete virtuale e i peering su larga scala. Le configurazioni di peering tra reti virtuali hub-spoke vengono configurate automaticamente in modo bidirezionale per i gruppi di rete.

  Azure Rete virtuale Manager consente di aggiungere in modo statico o dinamico appartenenze alla rete virtuale spoke a un gruppo di rete specifico, che crea automaticamente la connessione di peering per i nuovi membri. Le reti virtuali spoke nei gruppi di rete possono usare la VPN hub o i gateway ExpressRoute per la connettività. Assicurarsi di rimanere al di sotto dei limiti massimi per Azure Rete virtuale Manager.

Modello 2: Area singola

Il diagramma seguente illustra una topologia hub-spoke a singola area che invia il traffico tra spoke attraverso un firewall di Azure distribuito nella rete virtuale hub. Il traffico viene inoltrato all'appliance centralizzata nell'hub tramite route definite dall'utente applicate alle subnet spoke.

In determinate circostanze, può essere utile separare le appliance virtuali di rete che gestiscono il traffico spoke-to-spoke e Internet per la scalabilità. Per ottenere questa separazione, è possibile:

• Ottimizzazione delle tabelle di route negli spoke per inviare indirizzi privati (quelli che hanno una route per i prefissi RFC 1918) a un'appliance virtuale di rete responsabile del traffico da Azure ad Azure e da Azure a locale (detto anche traffico est-ovest).
• Ottimizzazione del traffico Internet (con una route 0.0.0.0/0) a una seconda appliance virtuale di rete. Questa appliance virtuale di rete è responsabile del traffico da Azure a Internet (noto anche come traffico nord-sud).

Il diagramma seguente mostra questa configurazione:

Modello 2: più aree

È possibile estendere la stessa configurazione a più aree. Ad esempio, in una progettazione hub-spoke che usa Firewall di Azure, è necessario applicare tabelle di route aggiuntive alle subnet Firewall di Azure in ogni hub per gli spoke nell'area remota. Questa configurazione garantisce che il traffico tra aree possa essere inoltrato tra i firewall di Azure in ogni rete virtuale hub. Il traffico tra aree tra reti virtuali spoke attraversa quindi entrambi i firewall di Azure. Per altre informazioni, vedere Firewall di Azure per instradare una topologia a più hub e spoke:

La variante di progettazione con firewall di Azure o appliance virtuali di rete separate per il traffico nord-sud e est-ovest è anche possibile in una topologia hub-spoke in più aree:

rete WAN virtuale crea una topologia simile e assume la complessità del routing. Lo fa sia negli hub (gestiti da Microsoft) che negli spoke (in cui le route possono essere inserite e non devono essere definite manualmente nelle tabelle di route). L'amministratore di rete deve quindi connettere solo le reti virtuali spoke a un hub rete WAN virtuale e non deve preoccuparsi dell'inoltro del traffico tra aree.

Modelli ibridi

Molte situazioni richiedono un approccio ibrido che combina i due modelli descritti in precedenza. In questo approccio, il traffico tra determinati spoke deve superare le connessioni dirette, ma il resto degli spoke comunica tramite un'appliance di rete centrale. Ad esempio, in un ambiente rete WAN virtuale, è possibile connettere direttamente due spoke specifici con larghezza di banda elevata e requisiti di bassa latenza. Un altro scenario prevede reti virtuali spoke che fanno parte di un singolo ambiente. Ad esempio, è possibile consentire a una rete virtuale di sviluppo spoke di connettersi direttamente a un'altra rete virtuale di sviluppo spoke, ma forzare la comunicazione tra i carichi di lavoro Sviluppo e produzione tramite l'appliance centrale.

Un altro modello comune prevede la connessione di spoke in un'area tramite peering di rete virtuale diretta o gruppi connessi di Azure Rete virtuale Manager, ma consentendo il traffico tra aree tra più appliance virtuali di rete. La motivazione principale per questo modello è in genere ridurre il numero di peering di rete virtuale nell'architettura. Tuttavia, rispetto al primo modello (connettività diretta tra spoke), uno svantaggio introdotto in questo modello è più peering di rete virtuale spera per il traffico tra aree. Questi hop aumentano i costi a causa dei più peering di rete virtuale incrociati. Un altro svantaggio è il carico aggiuntivo per le appliance virtuali di rete dell'hub per far fronte a tutto il traffico tra aree.

Le stesse progettazioni sono applicabili per rete WAN virtuale. Tuttavia, una considerazione è che la connettività diretta tra reti virtuali spoke deve essere configurata manualmente tra le reti virtuali e non tramite la risorsa rete WAN virtuale. Azure Rete virtuale Manager attualmente non supporta le architetture basate su rete WAN virtuale. Ad esempio:

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• Jay Li | Senior Product Manager
• Jose Moreno | Principal Customer Engineer
• Alejandra): | Senior Azure Infrastructure Customer Engineer

Altri contributori:

• Mick Alberts | Writer tecnico
• Mohammed Hassan | Principal PM Manager
• Andrea Michael | Program Manager
• Yasokuni Morishima | Customer Engineer II
• Jithin PP | Customer Engineer

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

Passaggi successivi

• Cloud Adoption Framework: topologia di rete e connettività della zona di destinazione
• Peering di rete virtuale
• Azure Rete virtuale Manager
• Rete WAN virtuale
• Firewall di Azure
• Proteggere la connettività di rete in Azure
• Introduzione ad Azure Rete virtuale

Risorse correlate

• Topologia di rete hub-spoke in Azure
• Topologia di rete hub-spoke con Rete WAN virtuale di Azure
• Topologia di rete di Azure tradizionale