Questo documento presenta due opzioni di architettura per la configurazione di una topologia di rete hub-and-spoke 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 la fatturazione, l'isolamento dell'ambiente e altre considerazioni. Tuttavia, l'azienda potrebbe anche dover condividere risorse specifiche tra 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-and-spoke risultante, a volte chiamata topologia a stella.
In questo esempio, vengono utilizzate reti VPC spoke separate per i carichi di lavoro dei singoli reparti di un'azienda di grandi dimensioni. Ogni rete VPC spoke è collegata a una rete VPC hub centrale che contiene servizi condivisi e può fungere da unico punto di accesso 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 utilizzando 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 attivo rete interna di Google e non attraversa la rete internet pubblica.
- In questa architettura, le risorse che richiedono l'isolamento a livello di rete
utilizzano reti VPC spoke separate. Ad esempio,
mostra una VM di Compute Engine nel VPC
spoke-1in ogni rete. La rete VPCspoke-2ha 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 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 per la comunicazione in uscita con internet.
- Il peering di rete VPC non prevede annunci di route transitivi.
A meno che non venga utilizzato un meccanismo aggiuntivo, la VM nella rete
spoke-1non può inviare traffico alla VM nella retespoke-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, i tunnel VPN tra la rete VPCspoke-2e la rete VPC hub consentono la raggiungibilità della rete VPCspoke-2degli 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 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.
- 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 un hub rete VPC.
- In ogni rete spoke è presente una zona DNS privata nella rete hub e una zona DNS peering e privata.
- La larghezza di banda tra le reti è limitata dalle larghezze di banda totali del tunneling.
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. 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) è limitato alle larghezze di banda dei tunnel.
Alternative di design
Prendi in considerazione le seguenti alternative di architettura per interconnettere le risorse messe in produzione in reti VPC separate in Google Cloud:
- Connettività tra spoke tramite 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.
- Peering di rete VPC senza un hub
- Se non hai bisogno di un controllo centralizzato della connettività on-premise o della condivisione di servizi tra reti VPC, non è necessaria una rete VPC hub. Puoi configurare il peering per le coppie di reti VPC 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 condivisa 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 di sviluppo, crea una rete VPC condivisa per la produzione e un'altra rete VPC condivisa per lo sviluppo. Quindi, effettua il peering delle due reti VPC per abilitare la comunicazione tra le reti VPC. 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
- Esegui il deployment di una rete hub and spoke utilizzando il peering di rete VPC.
- Esegui il deployment di una rete hub and spoke utilizzando Cloud VPN.
- Scopri di più su altre opzioni di progettazione per connettere più VPC reti.
- Scopri le best practice per creare una topologia cloud sicura e resiliente ottimizzata per costi e prestazioni.