Architettura di rete hub e spoke

Last reviewed 2025-04-30 UTC

Questo documento presenta tre opzioni di architettura 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 ai fini della fatturazione, dell'isolamento dell'ambiente e di altre considerazioni. Tuttavia, l'azienda potrebbe anche dover condividere risorse specifiche su queste reti, come un servizio condiviso o una connessione on-premise. In questi casi, può essere utile posizionare la risorsa condivisa in una rete hub (indicata come rete di routing nel resto di questo documento) e collegare le altre reti VPC come reti spoke (indicate come reti di carico di lavoro nel resto di questo documento). Il seguente diagramma mostra una rete hub and spoke con due VPC del carico di lavoro, anche se è possibile aggiungerne altri.

Schema di rete hub and spoke.

In questo esempio, vengono utilizzate reti VPC separate per i carichi di lavoro di singoli reparti aziendali all'interno di una grande azienda. Ogni rete VPC del carico di lavoro è collegata a una rete VPC di routing centrale che contiene servizi condivisi e può fungere da unico punto di contatto con il cloud dalla rete on-premise dell'azienda.

Riepilogo delle opzioni

Quando scegli una delle architetture discusse in questo documento, valuta i vantaggi relativi di Network Connectivity Center, VPC Network Peering e Cloud VPN:

  • Network Connectivity Center fornisce la larghezza di banda completa tra le VPC dei workload e garantisce la transitività tra le VPC dei workload.
  • Il peering di reti VPC fornisce la larghezza di banda completa tra le VPC dei carichi di lavoro e la VPC di routing. Non fornisce transitività tra le VPC dei carichi di lavoro. Il peering di rete VPC supporta l'instradamento alle NVA in altri VPC.
  • Cloud VPN consente il routing transitivo, ma la larghezza di banda totale (in entrata più in uscita) tra le reti è limitata alle larghezze di banda dei tunnel. Puoi 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 che utilizza 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 spoke VPC (VPC del carico di lavoro), mentre la topologia mesh no.
  • 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 di Private Service Connect sono transitive tra le VPC del carico di lavoro.
  • Le route di accesso ai servizi privati sono transitive tra le VPC dei carichi di lavoro tramite l'utilizzo di spoke dei producer per molti servizi forniti da Google. Per i servizi in cui le route non sono transitive, una soluzione alternativa è connettere la rete VPC del consumatore 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 carico di lavoro e la rete VPC di instradamento hanno un gateway Cloud NAT per la comunicazione in uscita con internet.
  • Il peering DNS e l'inoltro sono configurati in modo che i carichi di lavoro nei VPC del carico di lavoro possano essere raggiunti 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 utilizzando indirizzi IP interni tra le risorse in reti VPC separate. Il traffico rimane nella 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 tramite 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 di loro. Per fornire servizi condivisi, inseriscili nella rete di routing o connettili alla rete di routing utilizzando Cloud VPN.
  • Ogni VPC del carico di lavoro e la rete VPC di instradamento hanno un gateway Cloud NAT per la comunicazione in uscita con internet.
  • Il peering DNS e il reindirizzamento sono configurati in modo che i workload nei VPC del carico di lavoro possano essere raggiunti dall'ambiente on-premise.

Architettura che utilizza Cloud VPN

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

Architettura hub-and-spoke che utilizza Cloud VPN

  • I tunnel VPN IPsec connettono ogni rete VPC del carico di lavoro (spoke) a una rete VPC di routing (hub).
  • In ogni rete del carico di lavoro esistono una zona DNS privata nella rete di routing, una zona DNS peering e una zona privata.
  • Le connessioni sono transitive. Le reti VPC on-premise e spoke possono comunicare tra loro tramite la rete di routing, anche se questa può essere limitata.
  • La larghezza di banda tra le reti è limitata dalle larghezze di banda totali dei tunnel.
  • Ogni VPC del carico di lavoro (spoke) e la rete VPC di instradamento 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 DNS e l'inoltro sono configurati in modo che i carichi di lavoro nei VPC del carico di lavoro possano essere raggiunti dall'ambiente on-premise.

Alternative di design

Valuta le seguenti alternative di architettura per interconnettere le risorse messe in produzione 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 spoke-to-spoke.

Più reti VPC condivise

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

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

Passaggi successivi