Decidere la progettazione della rete per la tua zona di destinazione Google Cloud

Last reviewed 2023-09-11 UTC

Quando progetti la zona di destinazione, devi scegliere una struttura di rete adatta alla tua organizzazione. Questo documento descrive quattro progettazioni di rete comuni e ti aiuta a scegliere l'opzione più adatta ai requisiti della tua organizzazione e alle preferenze della tua organizzazione per il controllo centralizzato o il controllo decentralizzato. È destinato a ingegneri, architetti e tecnici di rete coinvolti nella creazione della progettazione della rete per la zona di destinazione della tua organizzazione.

Questo articolo fa parte di una serie sulle zone di destinazione.

Scegliere il design della rete

La scelta della struttura di rete dipende principalmente dai seguenti fattori:

  • Controllo centralizzato o decentralizzato: a seconda delle preferenze della tua organizzazione, devi scegliere una delle seguenti opzioni:
    • Centralizza il controllo della rete, inclusi gli indirizzi IP, il routing e il firewall tra diversi carichi di lavoro.
    • Offri ai team una maggiore autonomia nella gestione dei propri ambienti e nella creazione di elementi di rete all'interno dei rispettivi ambienti.
  • Opzioni di connettività cloud on-premise o ibrida: tutti i progetti di rete descritti in questo documento consentono l'accesso da ambienti on-premise a cloud tramite Cloud VPN o Cloud Interconnect. Tuttavia, alcuni progetti richiedono di configurare più connessioni in parallelo, mentre altri utilizzano la stessa connessione per tutti i carichi di lavoro.
  • Requisiti di sicurezza: la tua organizzazione potrebbe richiedere che il traffico tra i diversi carichi di lavoro in Google Cloud passi attraverso appliance di rete centralizzate, come i firewall di nuova generazione (NGFW). Questo vincolo influenza la progettazione della tua rete Virtual Private Cloud (VPC).
  • Scalabilità: alcuni progetti potrebbero essere migliori per la tua organizzazione rispetto ad altri, in base al numero di carichi di lavoro di cui vuoi eseguire il deployment e al numero di macchine virtuali (VM), bilanciatori del carico interni e altre risorse che utilizzeranno.

Punti decisionali per la progettazione della rete

Il seguente diagramma di flusso mostra le decisioni che devi prendere per scegliere la progettazione di rete migliore per la tua organizzazione.

Decisioni per le progettazioni di rete.

Il diagramma precedente ti guida nelle seguenti domande:

  1. Hai bisogno di un'ispezione di livello 7 utilizzando appliance di rete tra diversi carichi di lavoro in Google Cloud?
  2. Molti dei tuoi carichi di lavoro richiedono una connettività on-premise?
    • In caso affermativo, vai al punto decisionale 4.
    • In caso contrario, vai alla domanda successiva.
  3. I tuoi carichi di lavoro possono comunicare utilizzando endpoint privati in un producer di servizi e in un modello consumer?
  4. Vuoi amministrare il firewall e il routing a livello centrale?

Questo grafico ha lo scopo di aiutarti a prendere una decisione, ma spesso può capitare che più progetti siano adatti alla tua organizzazione. In questi casi, ti consigliamo di scegliere il design più adatto al tuo caso d'uso.

Opzioni di progettazione della rete

Le seguenti sezioni descrivono quattro opzioni di progettazione comuni. Consigliamo l'opzione 1 per la maggior parte dei casi d'uso. Gli altri progetti descritti in questa sezione sono alternative che si applicano a requisiti specifici relativi ai casi limite dell'organizzazione.

La soluzione migliore per il tuo caso d'uso potrebbe anche essere una rete che combina elementi di più opzioni di progettazione discusse in questa sezione. Ad esempio, puoi utilizzare reti VPC condivisi nelle topologie hub e spoke per migliorare la collaborazione, il controllo centralizzato e limitare il numero di spoke VPC. In alternativa, puoi progettare la maggior parte dei carichi di lavoro in una topologia VPC condiviso, ma isolare un numero ridotto di carichi di lavoro in reti VPC separate che espongono i servizi solo tramite alcuni endpoint definiti utilizzando Private Service Connect.

Opzione 1: rete VPC condiviso per ciascun ambiente

Consigliamo questa struttura di rete per la maggior parte dei casi d'uso. Questa progettazione utilizza reti VPC condiviso separate per ogni ambiente di deployment disponibile in Google Cloud (sviluppo, test e produzione). Questa progettazione consente di gestire le risorse di rete a livello centrale in una rete comune e fornisce l'isolamento di rete tra i diversi ambienti.

Utilizza questo design quando si verifica quanto segue:

  • Vuoi un controllo centrale sulle regole di firewall e di routing.
  • Hai bisogno di un'infrastruttura semplice e scalabile.
  • Hai bisogno di una gestione centralizzata dello spazio di indirizzi IP.

Evita questo design se si verifica quanto segue:

  • Vuoi che i team di sviluppatori abbiano una piena autonomia, inclusa la possibilità di gestire le proprie regole firewall, il routing e il peering alle reti di altri team.
  • Devi eseguire l'ispezione di livello 7 utilizzando appliance NGFW.

Il seguente diagramma mostra un esempio di implementazione di questo progetto.

Diagramma dell'opzione 1.

Il diagramma precedente mostra quanto segue:

  • La rete on-premise è distribuita in due località geografiche.
  • La rete on-premise si connette tramite istanze Cloud Interconnect ridondanti a due reti VPC condiviso separate, una per la produzione e una per lo sviluppo.
  • Gli ambienti di produzione e di sviluppo sono connessi a entrambe le istanze Cloud Interconnect con diversi collegamenti VLAN.
  • Ogni VPC condiviso include progetti di servizio che ospitano i carichi di lavoro.
  • Le regole firewall vengono amministrate centralmente nel progetto host.
  • L'ambiente di sviluppo ha la stessa struttura VPC dell'ambiente di produzione.

Per progettazione, il traffico da un ambiente non può raggiungere un altro. Tuttavia, se carichi di lavoro specifici devono comunicare tra loro, puoi consentire il trasferimento di dati attraverso canali controllati on-premise oppure condividere i dati tra le applicazioni con servizi Google Cloud come Cloud Storage o Pub/Sub. Ti consigliamo di evitare di connettere direttamente ambienti separati tramite peering di rete VPC, perché aumenta il rischio di mischiare accidentalmente i dati tra gli ambienti. L'utilizzo del peering di rete VPC tra ambienti di grandi dimensioni aumenta anche il rischio di raggiungere le quote di VPC relative ai gruppi di peering e peering.

Per ulteriori informazioni, consulta le seguenti risorse:

Per implementare questa opzione di progettazione, consulta Creazione dell'opzione 1: rete VPC condiviso per ogni ambiente.

Opzione 2: topologia hub e spoke con appliance centralizzate

Questa progettazione di rete utilizza la topologia hub e spoke. Una rete VPC hub contiene un insieme di VM dell'appliance, ad esempio NGFW, collegate alle reti VPC spoke che contengono i carichi di lavoro. Il traffico tra i carichi di lavoro, le reti on-premise o internet viene instradato attraverso VM dell'appliance per l'ispezione e l'applicazione di filtri.

Utilizza questo design quando si verifica quanto segue:

  • Hai bisogno dell'ispezione di livello 7 tra diversi carichi di lavoro o applicazioni.
  • Disponi di un mandato aziendale che specifica il fornitore dell'appliance di sicurezza per tutto il traffico.

Evita questo design se si verifica quanto segue:

  • Non è necessaria l'ispezione di livello 7 per la maggior parte dei carichi di lavoro.
  • Vuoi che i carichi di lavoro su Google Cloud non comunichino affatto tra loro.
  • È necessaria solo l'ispezione di livello 7 per il traffico diretto alle reti on-premise, come descritto in Caso d'uso speciale con una rete VPC condivisa su Google Cloud.

Il seguente diagramma mostra un esempio di implementazione di questo pattern.

Diagramma dell'opzione 2.

Il diagramma precedente mostra quanto segue:

  • Un ambiente di produzione che include una rete VPC hub e reti VPC a più spoke contenenti i carichi di lavoro.
  • Le reti VPC spoke sono connesse alla rete VPC hub tramite peering di rete VPC.
  • La rete VPC hub contiene più istanze di un'appliance virtuale in un gruppo di istanze gestite. Il traffico verso il gruppo di istanze gestite passa attraverso un bilanciatore del carico di rete passthrough interno.
  • Le reti VPC spoke comunicano tra loro tramite le appliance virtuali utilizzando route statiche con il bilanciatore del carico interno come hop successivo.
  • Cloud Interconnect connette le reti VPC in transito alle località on-premise.
  • Le reti on-premise sono connesse tramite le stesse Cloud Interconnect utilizzando collegamenti VLAN separati.
  • Le reti VPC in transito sono collegate a un'interfaccia di rete separata sulle appliance virtuali, che ti consente di ispezionare e filtrare tutto il traffico da e verso queste reti utilizzando l'appliance.
  • L'ambiente di sviluppo ha la stessa struttura VPC dell'ambiente di produzione.
  • Questa configurazione non utilizza la traduzione dell'indirizzo di rete di origine (SNAT). La SNAT non è necessaria perché Google Cloud utilizza l'hashing simmetrico. Per ulteriori informazioni, consulta Hashing simmetrico.

Per impostazione predefinita, il traffico proveniente da una rete spoke non può raggiungere un'altra rete spoke. Tuttavia, se carichi di lavoro specifici devono comunicare tra loro, puoi impostare il peering diretto tra le reti spoke utilizzando il peering di rete VPC oppure condividere i dati tra le applicazioni con servizi Google Cloud come Cloud Storage o Pub/Sub.

Per mantenere una bassa latenza quando l'appliance comunica tra i carichi di lavoro, l'appliance deve trovarsi nella stessa regione dei carichi di lavoro. Se utilizzi più regioni nel deployment cloud, puoi avere un set di appliance e un VPC hub per ogni ambiente in ogni regione. In alternativa, puoi utilizzare i tag di rete con route per fare in modo che tutte le istanze comunichino con l'appliance più vicina.

Le regole firewall possono limitare la connettività all'interno delle reti VPC spoke che contengono carichi di lavoro. Spesso, i team che amministrano i carichi di lavoro amministrano anche queste regole firewall. Per i criteri centrali, puoi utilizzare i criteri firewall gerarchici. Se richiedi che un team di rete centrale abbia il controllo completo sulle regole firewall, valuta la possibilità di eseguirne il deployment centralmente in tutte le reti VPC utilizzando un approccio GitOps. In questo caso, limita le autorizzazioni IAM solo agli amministratori che possono modificare le regole firewall. Le reti VPC spoke possono anche essere reti VPC condiviso se più team eseguono il deployment negli spoke.

In questa progettazione, consigliamo di utilizzare il peering di rete VPC per connettere la rete VPC hub e le reti VPC spoke, in quanto aggiunge complessità minima. Tuttavia, il numero massimo di spoke è limitato da quanto segue:

  • Il limite di connessioni di peering di rete VPC da una singola rete VPC.
  • Limiti dei gruppi di peering come il numero massimo di regole di forwarding per il bilanciamento del carico TCP/UDP interno per ogni gruppo di peering.

Se prevedi di raggiungere questi limiti, puoi connettere le reti spoke tramite Cloud VPN. L'utilizzo di Cloud VPN aumenta i costi e la complessità e ogni tunnel Cloud VPN ha un limite di larghezza di banda.

Per ulteriori informazioni, consulta le seguenti risorse:

Per implementare questa opzione di progettazione, vedi Creare l'opzione 2: topologia hub e spoke con appliance centralizzate.

Opzione 3: topologia hub e spoke senza appliance

Questo design di rete utilizza anche una topologia hub e spoke, con una rete VPC hub che si connette a reti on-premise e reti VPC spoke che contengono i carichi di lavoro. Poiché il peering di rete VPC non è transitorio, le reti spoke non possono comunicare direttamente tra loro.

Utilizza questo design quando si verifica quanto segue:

  • Vuoi che i carichi di lavoro o gli ambienti in Google Cloud non comunichino tra loro tramite indirizzi IP interni, ma vuoi che condividano la connettività on-premise.
  • Vuoi concedere ai team autonomia per la gestione del proprio firewall e delle regole di routing.

Evita questo design se si verifica quanto segue:

  • Hai bisogno dell'ispezione di livello 7 tra i carichi di lavoro.
  • Vuoi gestire centralmente le regole di routing e del firewall.
  • Hai bisogno di comunicazioni dai servizi on-premise a servizi gestiti connessi agli spoke tramite un altro peering di rete VPC, poiché il peering di rete VPC è non transitorio.

Il seguente diagramma mostra un esempio di implementazione di questo progetto.

Diagramma dell'opzione 3.

Il diagramma precedente mostra quanto segue:

  • Un ambiente di produzione che include una rete VPC hub e reti VPC a più spoke contenenti i carichi di lavoro.
  • Le reti VPC spoke sono connesse alla rete VPC hub tramite peering di rete VPC.
  • La connettività alle località on-premise passa attraverso le connessioni Cloud Interconnect nella rete VPC hub.
  • Le reti on-premise sono connesse tramite le istanze Cloud Interconnect utilizzando collegamenti VLAN separati.
  • L'ambiente di sviluppo ha la stessa struttura VPC dell'ambiente di produzione.

Per impostazione predefinita, il traffico proveniente da una rete spoke non può raggiungere un'altra rete spoke. Tuttavia, se carichi di lavoro specifici devono comunicare tra loro, puoi impostare il peering diretto tra le reti spoke utilizzando il peering di rete VPC oppure condividere i dati tra le applicazioni con servizi Google Cloud come Cloud Storage o Pub/Sub.

Questa progettazione di rete viene spesso utilizzata in ambienti in cui i team agiscono autonomamente e non esiste un controllo centralizzato sulle regole firewall e di routing. Tuttavia, la portata di questo design è limitata da quanto segue:

Pertanto, questo design non viene generalmente utilizzato nelle grandi organizzazioni con molti carichi di lavoro separati su Google Cloud.

In variante al design, puoi utilizzare Cloud VPN anziché il peering di rete VPC. Cloud VPN consente di aumentare il numero di spoke, ma aggiunge un limite di larghezza di banda per ogni tunnel e aumenta complessità e costi. Quando utilizzi annunci di route personalizzati, Cloud VPN consente anche la transitività tra gli spoke senza richiedere la connessione diretta di tutte le reti spoke.

Per ulteriori informazioni, consulta le seguenti risorse:

Per implementare questa opzione di progettazione, vedi Creare l'opzione 3: topologia hub e spoke senza appliance.

Opzione 4: espone i servizi in un modello consumer-producer con Private Service Connect

In questa progettazione di rete, ogni team o carico di lavoro ha la propria rete VPC, che può anche essere una rete VPC condiviso. Ogni rete VPC è gestita in modo indipendente e utilizza Private Service Connect per esporre tutti i servizi a cui occorre accedere dall'esterno della rete VPC.

Utilizza questo design quando si verifica quanto segue:

  • I carichi di lavoro comunicano tra loro e con l'ambiente on-premise solo attraverso endpoint definiti.
  • I team devono essere indipendenti tra loro e gestire il proprio spazio di indirizzi IP, i firewall e le regole di routing.

Evita questo design se si verifica quanto segue:

  • La comunicazione tra servizi e applicazioni utilizza molte porte o canali diversi oppure porte e canali cambiano spesso.
  • La comunicazione tra carichi di lavoro utilizza protocolli diversi da TCP o UDP.
  • Hai bisogno dell'ispezione di livello 7 tra i carichi di lavoro.

Il seguente diagramma mostra un esempio di implementazione di questo pattern.

Diagramma dell'opzione 4.

Il diagramma precedente mostra quanto segue:

  • I carichi di lavoro separati si trovano in progetti e reti VPC separati.
  • Una VM client in una rete VPC può connettersi a un carico di lavoro in un'altra rete VPC tramite un endpoint Private Service Connect.
  • L'endpoint è collegato a un collegamento a un servizio nella rete VPC in cui si trova il servizio. Il collegamento al servizio può trovarsi in una regione diversa dall'endpoint se quest'ultimo è configurato per l'accesso globale.
  • Il collegamento al servizio si connette al carico di lavoro tramite Cloud Load Balancing.
  • I client nel VPC dei carichi di lavoro possono raggiungere carichi di lavoro che si trovano on-premise, come segue:
    • L'endpoint è connesso a un collegamento a un servizio in una rete VPC in transito.
    • Il collegamento al servizio è connesso alla rete on-premise mediante Cloud Interconnect.
  • Un bilanciatore del carico delle applicazioni interno è collegato al collegamento al servizio e utilizza un gruppo ibrido di endpoint di rete per bilanciare il carico del traffico tra gli endpoint che si trovano on-premise.
  • I client on-premise possono anche raggiungere gli endpoint nella rete VPC in transito che si connettono ai collegamenti ai servizi nelle reti VPC dei carichi di lavoro.

Per ulteriori informazioni, consulta le seguenti risorse:

Per implementare questa opzione di progettazione, vedi Creazione dell'opzione 4: espone i servizi in un modello consumer-producer con Private Service Connect.

Best practice per il deployment della rete

Dopo aver scelto la progettazione di rete migliore per il tuo caso d'uso, ti consigliamo di implementare le seguenti best practice:

Per ulteriori informazioni, consulta Best practice e architetture di riferimento per la progettazione di VPC.

Passaggi successivi