Architettura di rete hub e spoke

Questo documento presenta tre opzioni architetturali per configurare una topologia di rete hub-and-spoke in Google Cloud. La prima opzione utilizza Network Connectivity Center, la seconda utilizza il peering di rete VPC e la terza utilizza Cloud VPN.

Un'azienda può separare i carichi di lavoro in singole reti VPC a fini di fatturazione, isolamento dell'ambiente e altre considerazioni. Tuttavia, l'azienda potrebbe anche dover condividere risorse specifiche tra queste reti, come un servizio condiviso o una connessione on-premise. In questi casi, può essere utile inserire la risorsa condivisa in una rete hub (denominata rete di routing nel resto di questo documento) e collegare le altre reti VPC come reti spoke (denominate reti workload nel resto di questo documento). Il seguente diagramma mostra una rete hub-and-spoke con due VPC del carico di lavoro, anche se è possibile aggiungere altri VPC del carico di lavoro.

Schema di rete hub and spoke.

In questo esempio, vengono utilizzate reti VPC di carichi di lavoro separate per i carichi di lavoro delle singole unità aziendali all'interno di una grande impresa. Ogni rete VPC del workload è connessa a una rete VPC di routing centrale che contiene servizi condivisi e può fungere da unico punto di ingresso al cloud dalla rete on-premise dell'azienda.

Riepilogo delle opzioni

Quando scegli una delle architetture descritte in questo documento, considera i meriti relativi di Network Connectivity Center, peering di rete VPC e Cloud VPN:

  • Network Connectivity Center fornisce la larghezza di banda completa tra i VPC dei workload e la transitività tra i VPC dei workload.
  • Il peering di rete VPC fornisce una larghezza di banda completa tra i VPC dei carichi di lavoro e il VPC di routing. Non fornisce la transitività tra i VPC dei carichi di lavoro. Il peering di rete VPC supporta il routing alle NVA in altri VPC.
  • Cloud VPN consente il routing transitivo, ma la larghezza di banda totale (ingresso più uscita) tra le reti è limitata alle larghezze di banda dei tunnel. È possibile aggiungere altri tunnel per aumentare la larghezza di banda.

Architettura che utilizza Network Connectivity Center

Il seguente diagramma mostra una rete hub-and-spoke che utilizza Network Connectivity Center.

Architettura hub e spoke utilizzando Network Connectivity Center.

Network Connectivity Center ha una risorsa hub che fornisce la gestione del piano di controllo, ma non è una rete hub per il piano dati.

  • Network Connectivity Center può connettere le reti utilizzando una topologia a stella (hub e spoke) o mesh. L'utilizzo di una topologia a stella impedisce la comunicazione tra gli spoke VPC (VPC del workload), mentre la topologia mesh non lo fa.
  • La rete VPC di routing (hub) ha una connessione on-premise tramite connessioni Cloud VPN o Cloud Interconnect.
  • Le route dinamiche possono essere propagate tra le reti VPC.
  • Le route Private Service Connect sono transitive tra i VPC dei carichi di lavoro.
  • Le route di accesso privato ai servizi sono transitive tra i VPC dei workload tramite l'utilizzo di spoke producer per molti servizi forniti da Google. Per i servizi in cui le route non sono transitive, una soluzione alternativa consiste nel connettere la rete VPC consumer alla rete VPC di routing utilizzando Cloud VPN anziché Network Connectivity Center.
  • Tutte le VM nelle reti in peering possono comunicare alla larghezza di banda completa delle VM.
  • Ogni VPC del workload e la rete VPC di routing hanno un gateway Cloud NAT per la comunicazione in uscita con internet.
  • Il peering e l'inoltro DNS sono configurati in modo che i carichi di lavoro nei VPC del carico di lavoro siano raggiungibili dall'ambiente on-premise.

Architettura che utilizza il peering di rete VPC

Il seguente diagramma mostra una rete hub-and-spoke che utilizza il peering di rete VPC. Il peering di rete VPC consente la comunicazione tramite indirizzi IP interni tra risorse in reti VPC separate. Il traffico rimane sulla rete interna di Google e non attraversa la rete internet pubblica.

Architettura hub-and-spoke che utilizza il peering di rete VPC

  • Ogni rete VPC del carico di lavoro (spoke) in questa architettura ha una relazione di peering con una rete VPC di routing centrale (hub).
  • La rete VPC di routing ha una connessione on-premise utilizzando connessioni Cloud VPN o Cloud Interconnect.
  • Tutte le VM nelle reti in peering possono comunicare alla larghezza di banda completa delle VM.
  • Le connessioni di peering di rete VPC non sono transitive. In questa architettura, le reti VPC on-premise e dei carichi di lavoro possono scambiare traffico con la rete di routing, ma non tra loro. Per fornire servizi condivisi, inseriscili nella rete di routing o connettili alla rete di routing utilizzando Cloud VPN.
  • Ogni VPC del workload e la rete VPC di routing hanno un gateway Cloud NAT per la comunicazione in uscita con internet.
  • Il peering e l'inoltro DNS sono configurati in modo che i carichi di lavoro nei VPC dei carichi di lavoro siano raggiungibili dall'ambiente on-premise.

Architettura che utilizza Cloud VPN

La scalabilità di una topologia hub e spoke che utilizza il peering di rete VPC è soggetta ai limiti di peering di rete VPC. Come indicato in precedenza, le connessioni di peering di rete VPC non consentono il traffico transitivo oltre le due reti VPC che si trovano in una relazione di peering. Il seguente diagramma mostra un'architettura di rete hub-and-spoke alternativa che utilizza Cloud VPN per superare i limiti del peering di reti VPC.

Architettura hub-and-spoke utilizzando Cloud VPN

  • I tunnel VPN IPsec connettono ogni rete VPC del workload (spoke) a una rete VPC di routing (hub).
  • Una zona DNS privata nella rete di routing e una zona di peering DNS e una zona privata esistono in ogni rete del carico di lavoro.
  • Le connessioni sono transitive. Le reti VPC on-premise e spoke possono raggiungersi a vicenda tramite la rete di routing, anche se ciò può essere limitato.
  • La larghezza di banda tra le reti è limitata dalle larghezze di banda totali dei tunnel.
  • Ogni VPC del workload (spoke) e la rete VPC di routing hanno un gateway Cloud NAT per la comunicazione in uscita con internet.
  • Il peering di rete VPC non prevede annunci di route transitivi.
  • Il peering e l'inoltro DNS sono configurati in modo che i carichi di lavoro nei VPC del carico di lavoro siano raggiungibili dall'ambiente on-premise.

Alternative di progettazione

Prendi in considerazione le seguenti alternative architetturali per interconnettere le risorse di cui è stato eseguito il deployment in reti VPC separate in Google Cloud:

Connettività tra spoke utilizzando un gateway nella rete VPC di routing

Per abilitare la comunicazione tra spoke, puoi implementare un'appliance virtuale di rete (NVA) o un firewall di nuova generazione (NGFW) sulla rete VPC di routing, in modo che funga da gateway per il traffico da spoke a spoke.

Più reti VPC condivise

Crea una rete VPC condiviso per ogni gruppo di risorse che vuoi isolare a livello di rete. Ad esempio, per separare le risorse utilizzate per gli ambienti di produzione e sviluppo, crea una rete VPC condiviso per la produzione e un'altra rete VPC condiviso per lo sviluppo. Quindi, esegui il peering delle due reti VPC per attivare la comunicazione tra le reti VPC. Le risorse nei singoli progetti per ogni applicazione o reparto possono utilizzare i servizi della rete VPC condiviso appropriata.

Per la connettività tra le reti VPC e la rete on-premise, puoi utilizzare tunnel VPN separati per ogni rete VPC o collegamenti VLAN separati sulla stessa connessione Dedicated Interconnect.

Passaggi successivi