Topologia di rete hub-spoke
Hub-spoke è un modello di rete per la gestione efficiente dei comuni requisiti di comunicazione o sicurezza. Consente anche di evitare le limitazioni delle sottoscrizioni di Azure. Questo modello consente di risolvere i problemi seguenti:
Risparmio sui costi e gestione efficiente: centralizzare i servizi che possono essere condivisi da più carichi di lavoro, ad esempio le appliance virtuali di rete e i server DNS. La centralizzazione dei servizi permette all'IT di ridurre al minimo le risorse e le attività di gestione ridondanti.
Superamento dei limiti delle sottoscrizioni: i carichi di lavoro di grandi dimensioni basati su cloud possono richiedere più risorse di quante siano contenute in una singola sottoscrizione di Azure. Il peering delle reti virtuali dei carichi di lavoro da sottoscrizioni diverse a un hub centrale consente di superare tali limiti. Per altre informazioni, vedere Limiti delle sottoscrizioni di Azure.
Implementazione di una separazione delle problematiche: è possibile distribuire singoli carichi di lavoro tra i team IT centrali e i team del carico di lavoro.
Gli ambienti cloud di dimensioni più piccole potrebbero non trarre vantaggio dalla struttura e dalle funzionalità aggiuntive offerte da questo modello. Tuttavia, per la maggior parte delle attività di adozione del cloud dovrebbe essere presa in considerazione l'implementazione di un'architettura di rete hub-spoke se vengono riscontrati alcuni dei problemi elencati in precedenza.
Nota
Il sito Architetture di riferimento di Azure contiene modelli di esempio che è possibile usare come base per implementare reti hub-spoke:
Panoramica
Figura 1: esempio di una topologia di rete hub-spoke.
Come illustrato nel diagramma, Azure supporta due tipi di progettazione hub-spoke. Il primo tipo supporta la comunicazione, le risorse condivise e i criteri di sicurezza centralizzati. Nel diagramma questo tipo è etichettato come hub di rete virtuale. Il secondo tipo è basato sulla rete WAN virtuale di Azure, etichettata come Rete WAN virtuale nel diagramma. Questo tipo è adatto alle comunicazioni da ramo a ramo e da ramo ad Azure su larga scala.
L'hub è una zona della rete centrale che controlla e ispeziona il traffico in ingresso o in uscita tra zone: Internet, locale e spoke. La topologia hub-spoke consente al reparto IT di applicare in modo efficace i criteri di sicurezza in una posizione centrale, riducendo al contempo il rischio di configurazione non corretta ed esposizione.
L'hub contiene spesso i componenti dei servizi comuni utilizzati dagli spoke. Ecco alcuni esempi di servizi centrali comuni.
- Il servizio DNS risolve la denominazione del carico di lavoro negli spoke per accedere alle risorse in locale e in Internet se non viene usato DNS di Azure.
- Un'infrastruttura a chiave pubblica implementa l'autenticazione Single Sign-On per i carichi di lavoro.
- Il flusso del traffico TCP e UDP viene controllato tra le zone di rete dello spoke e Internet.
- Il flusso viene controllato tra gli spoke e le risorse locali.
- Il flusso viene controllato tra uno spoke e un altro, se necessario.
È possibile ridurre al minimo la ridondanza, semplificare la gestione e ridurre i costi complessivi usando l'infrastruttura dell'hub condiviso per supportare più spoke.
Il ruolo di ogni spoke può essere quello di ospitare tipi diversi di carichi di lavoro. Gli spoke consentono anche un approccio modulare per le distribuzioni ripetibili degli stessi carichi di lavoro. Alcuni esempi includono sviluppo/test, test di accettazione utente, staging e produzione.
Gli spoke possono anche essere usati per isolare e consentire gruppi diversi all'interno dell'organizzazione, ad esempio gruppi Azure DevOps. In uno spoke è possibile distribuire un carico di lavoro di base o carichi di lavoro complessi multilivello con il controllo del traffico tra i livelli.
Il gateway applicazione illustrato nel diagramma precedente può risiedere nello spoke con l'applicazione che sta servendo, a vantaggio di una gestione e una scalabilità migliori. I criteri aziendali potrebbero tuttavia imporre la collocazione del gateway applicazione nell'hub per ottenere una gestione centralizzata e la separazione dei compiti.
Limiti della sottoscrizione e hub multipli
In Azure, ogni tipo di componente viene distribuito in una sottoscrizione di Azure. L'isolamento dei componenti di Azure in diverse sottoscrizioni di Azure può soddisfare i requisiti di diverse line-of-business, come la configurazione di livelli differenziati di accesso e autorizzazione.
Una singola implementazione hub-spoke è ridimensionabile fino a un numero elevato di spoke, ma, come per ogni sistema IT, esistono limiti per la piattaforma. La distribuzione dell'hub è associata a una specifica sottoscrizione di Azure, che ha restrizioni e limiti, ad esempio un numero massimo di peering di reti virtuali. Per altre informazioni, vedere Limiti dei servizi e della sottoscrizione di Azure.
Quando i limiti possono essere un problema, è possibile aumentare le prestazioni dell'architettura estendendo il modello a un cluster di hub e spoke. È possibile connettere più hub in una o più aree di Azure usando:
- Peering di rete virtuale
- Azure ExpressRoute
- Rete WAN virtuale di Azure
- VPN da sito a sito
Figura 2: cluster di hub e spoke.
L'introduzione di più hub aumenta il costo e l'impegno di gestione del sistema. Questo aumento è giustificato solo da:
- Scalabilità
- Limiti di sistema
- Ridondanza e replica a livello di area per le prestazioni utente o il ripristino di emergenza
Negli scenari in cui sono necessari più hub, è consigliabile che tutti gli hub offrano lo stesso set di servizi per facilitare le operazioni.
Interconnessione tra spoke
È possibile implementare carichi di lavoro complessi multilivello in un singolo spoke. È possibile implementare configurazioni a più livelli usando subnet (una per ogni livello) nella stessa rete virtuale e usando gruppi di sicurezza di rete per filtrare i flussi.
Un architetto potrebbe voler distribuire un carico di lavoro multilivello su più reti virtuali. Usando il peering di rete virtuale, gli spoke possono connettersi ad altri spoke nello stesso hub o in hub diversi.
Un esempio tipico di questo scenario è quello in cui i server di elaborazione delle applicazioni sono in uno spoke o rete virtuale, mentre il database viene distribuito in un altro spoke o rete virtuale. In questo caso, è facile interconnettere gli spoke con il peering di rete virtuale ed evitare in tal modo il transito dall'hub. È consigliabile eseguire un'attenta revisione dell'architettura e della sicurezza per assicurarsi che il bypass dell'hub non comporti il bypass di importanti punti di sicurezza e di controllo presenti solo nell'hub.
Figura 3: esempio di spoke connessi reciprocamente e a un hub.
Gli spoke possono anche essere interconnessi a uno spoke che funge da hub. Questo approccio crea una gerarchia a due livelli: lo spoke nel livello superiore (livello 0) diventa l'hub degli spoke inferiori (o del livello 1) nella gerarchia. Gli spoke sono necessari per inoltrare il traffico all'hub centrale. Ciò consente al traffico di transitare verso la propria destinazione nella rete locale o nella rete Internet pubblica. Un'architettura con due livelli di hub crea un routing complesso che elimina i vantaggi di una relazione hub-spoke semplice.
Nota
È possibile usare Azure Rete virtuale Manager (AVNM) per creare topologie di rete virtuale hub e spoke nuove o di onboarding esistenti per la gestione centralizzata dei controlli di connettività e sicurezza.
Una configurazione di connettività consente di creare una topologia di rete mesh o hub-spoke, inclusa la connettività diretta tra reti virtuali spoke.
Una configurazione di sicurezza consente di definire una raccolta di regole che è possibile applicare a uno o più gruppi di rete a livello globale.
Passaggi successivi
Dopo aver esplorato le procedure consigliate per la rete, è possibile apprendere come implementare i controlli di accesso e delle identità.