Architettura di rete hub e spoke

Last reviewed 2024-07-29 UTC

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

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

Schema di rete hub e spoke.

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

Architettura che utilizza il peering di rete VPC

Il seguente diagramma mostra una rete hub e spoke utilizzando Peering di rete VPC. Il peering di rete VPC consente la comunicazione utilizzando indirizzi IP interni tra risorse in reti VPC separate. Il traffico rimane attivo rete interna di Google e non attraversa la rete internet pubblica.

Architettura hub e spoke utilizzando il peering di rete VPC
  • In questa architettura, le risorse che necessitano dell'isolamento a livello di rete usano reti VPC spoke separate. Ad esempio, mostra una VM di Compute Engine nel VPC spoke-1 in ogni rete. La rete VPC spoke-2 ha una VM Compute Engine e un cluster Google Kubernetes Engine (GKE).
  • Ogni rete VPC spoke in questa architettura ha un con una rete VPC dell'hub centrale.
  • Il peering di rete VPC non limita la larghezza di banda della VM. Ogni VM può inviare il traffico alla larghezza di banda completa di quella singola VM.
  • Ogni rete VPC spoke ha un gateway Cloud NAT le comunicazioni 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 verso la VM nella rete spoke-2. Per aggirare questa mancata transizione, un vincolo di rete, l'architettura mostra la possibilità di utilizzare Cloud VPN inoltra le route tra le reti. In questo esempio, Tunnel VPN tra la rete VPC spoke-2 e l'hub La rete VPC consente la connettività a spoke-2 la rete VPC dagli altri spoke. Se hai bisogno di connettività tra pochi spoke specifici, puoi eseguire il peering di questi direttamente le coppie di rete.

Architettura utilizzando Cloud VPN

La scalabilità di una topologia hub e spoke che utilizza il peering di rete VPC soggetti ai limiti di peering di rete VPC. Come indicato in precedenza, le connessioni di peering di rete VPC non consentono traffico transitivo oltre le due reti VPC che si trovano in della relazione di peering. Il seguente diagramma mostra un hub e spoke alternativi che utilizza Cloud VPN per superare le limitazioni del peering di rete VPC.

Architettura hub e spoke utilizzando Cloud VPN
  • Le risorse che richiedono il livello di rete utilizzano reti VPC spoke separate.
  • I tunnel VPN IPSec connettono ogni rete VPC spoke a un hub rete VPC.
  • Una zona privata DNS nella rete hub e una zona di peering DNS e in ciascuna rete spoke.
  • La larghezza di banda tra le reti è limitata dalle larghezze di banda totali del tunnelizzati.

Al momento di scegliere tra le due architetture discusse finora, considera le relativi del peering di rete VPC e di Cloud VPN:

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

Alternative di progettazione

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

Connettività tra spoke con un gateway nella rete VPC dell'hub
Per abilitare le comunicazioni tra risposte, puoi eseguire il deployment di una rete virtuale appliance (NVA) o un firewall di nuova generazione (NGFW) sull'hub Rete VPC, da utilizzare come gateway per il traffico spoke-to-spoke. Consulta Apparecchiature di rete centralizzate su Google Cloud.
Peering di rete VPC senza un hub
Se non hai bisogno di un controllo centralizzato sulla connettività o sulla condivisione on-premise su reti VPC, quindi viene usato un VPC hub non sia necessaria. Puoi configurare il peering per il VPC coppie di rete che richiedono connettività e gestire le interconnessioni singolarmente. Tieni in considerazione i limiti sul numero di relazioni di peering per rete VPC.
Più reti VPC condivise

Crea una rete VPC condiviso per ogni gruppo di risorse desiderato da isolare a livello di rete. Ad esempio, per separare le risorse utilizzate di sviluppo e produzione, creare una rete VPC condiviso per la produzione e un'altra rete VPC condiviso per lo sviluppo. Poi, eseguire il peering delle due reti VPC per abilitare le reti VPC comunicazione di rete. Risorse in singoli progetti per ciascuna applicazione possono utilizzare i servizi della rete VPC condiviso appropriata.

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

Passaggi successivi