Architettura di rete hub e spoke

Last reviewed 2023-07-12 UTC

Questo documento presenta due opzioni di architettura per la configurazione di una topologia di rete hub e spoke in Google Cloud. Un'opzione utilizza la funzionalità di peering di rete di Virtual Private Cloud (VPC), mentre l'altra utilizza Cloud VPN.

Le aziende possono separare i carichi di lavoro in singole reti VPC ai fini della fatturazione, dell'isolamento dell'ambiente e per altre considerazioni. Tuttavia, l'azienda potrebbe anche dover condividere risorse specifiche su queste reti, ad esempio un servizio condiviso o una connessione on-premise. In questi casi, può essere utile posizionare la risorsa condivisa in una rete hub e collegare le altre reti VPC come spoke. Il seguente diagramma mostra un esempio della rete hub e spoke risultante, a volte chiamata topologia a stella.

Schema di rete hub e spoke.

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

Architettura che utilizza il peering di rete VPC

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

Architettura hub e spoke con il peering di rete VPC
  • In questa architettura, le risorse che richiedono l'isolamento a livello di rete utilizzano reti VPC spoke separate. Ad esempio, l'architettura mostra una VM di Compute Engine nella rete VPC spoke-1. La rete VPC spoke-2 include una VM Compute Engine e un cluster Google Kubernetes Engine (GKE).
  • Ogni rete VPC spoke in questa architettura ha una relazione di peering con una rete VPC hub centrale.
  • Il peering di rete VPC non limita la larghezza di banda delle VM. Ogni VM può inviare il traffico all'intera larghezza di banda della singola VM.
  • Ogni rete VPC spoke ha un gateway Cloud NAT per la comunicazione in uscita con internet.
  • Il peering di rete VPC non fornisce annunci di route transitive. A meno che non venga utilizzato un meccanismo aggiuntivo, la VM nella rete spoke-1 non può inviare traffico alla VM nella rete spoke-2. Per ovviare a questo vincolo di non transito, l'architettura mostra la possibilità di utilizzare Cloud VPN per inoltrare le route tra le reti. In questo esempio, i tunnel VPN tra la rete VPC spoke-2 e la rete VPC dell'hub consentono la connettività alla rete VPC spoke-2 dagli altri spoke. Se hai bisogno di connettività solo tra alcuni spoke specifici, puoi eseguire il peering di queste coppie di rete VPC direttamente.

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 transitorio oltre le due reti VPC che sono in una relazione di peering. Il seguente diagramma mostra un'architettura di rete hub e spoke alternativa che utilizza Cloud VPN per superare le limitazioni del peering di rete VPC.

Architettura hub e spoke con Cloud VPN
  • Le risorse che richiedono l'isolamento a livello di rete utilizzano reti VPC spoke separate.
  • I tunnel VPN IPSec connettono ogni rete VPC spoke a una rete VPC hub.
  • Nella rete hub sono presenti una zona privata DNS, nonché una zona di peering DNS e una zona privata in ogni rete spoke.
  • La larghezza di banda tra le reti è limitata dalle larghezza di banda dei tunnel totali.

Quando scegli tra le due architetture discusse finora, considera i vantaggi relativi del peering di rete VPC e Cloud VPN:

  • Il peering di rete VPC ha un vincolo di non transizione, ma supporta l'intera larghezza di banda definita dal tipo di macchina delle VM e da altri fattori che determinano la larghezza di banda di rete. Tuttavia, puoi aggiungere il routing transitivo aggiungendo tunnel VPN.
  • Cloud VPN consente il routing transitivo, ma la larghezza di banda totale (in entrata più il traffico in uscita) è limitata alle larghezze di banda dei tunnel.

Alternative di progettazione

Considera le seguenti alternative all'architettura per l'interconnessione di risorse di cui viene eseguito il deployment in reti VPC separate in Google Cloud:

Connettività tra spoke tramite gateway nella rete VPC hub
Per abilitare la comunicazione tra spoke, puoi eseguire il deployment di un'appliance virtuale di rete (NVA) o di un firewall di nuova generazione (NGFW) sulla rete VPC dell'hub, che funga da gateway per il traffico spoke-to-spoke. Consulta appliance di rete centralizzate su Google Cloud.
Peering di rete VPC senza hub
Se non hai bisogno di un controllo centralizzato sulla connettività on-premise o sui servizi di condivisione tra le reti VPC, una rete VPC hub non è necessaria. Puoi configurare il peering per le coppie di rete VPC che richiedono connettività e gestire le interconnessioni singolarmente. Considera i limiti al numero di relazioni di peering per rete VPC.
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 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 abilitare le comunicazioni di rete tra 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