Decidi la progettazione di rete per la tua zona di destinazione Google Cloud

Quando progetti la tua landing zone, devi scegliere una progettazione di rete adatta alla tua organizzazione. Questo documento descrive quattro progetti di rete comuni e ti aiuta a scegliere l'opzione che soddisfa al meglio i requisiti della tua organizzazione e la sua preferenza per il controllo centralizzato o decentralizzato. È rivolto a ingegneri di rete, architetti e professionisti tecnici che sono coinvolti nella creazione della progettazione di rete per la landing zone della tua organizzazione.

Questo articolo fa parte di una serie sulle landing zone.

Scegliere la progettazione della rete

La progettazione della rete che scegli 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 l'indirizzamento IP, il routing e il firewalling tra diversi carichi di lavoro.
    • Offri ai tuoi team maggiore autonomia nella gestione dei propri ambienti e nella creazione di elementi di rete all'interno dei propri ambienti.
  • Opzioni di connettività on-premise o cloud ibrido:tutti i progetti di rete descritti in questo documento forniscono l'accesso dagli ambienti on-premise a quelli 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 workload.
  • Requisiti di sicurezza:la tua organizzazione potrebbe richiedere che il traffico tra diversi carichi di lavoro in Google Cloud passi attraverso appliance di rete centralizzate come firewall di nuova generazione (NGFW). Questo vincolo influisce sulla progettazione della rete Virtual Private Cloud (VPC).
  • Scalabilità:alcuni design potrebbero essere più adatti alla tua organizzazione di altri, in base al numero di workload che vuoi distribuire e al numero di macchine virtuali (VM), bilanciatori del carico interni e altre risorse che consumeranno.

Punti decisionali per la progettazione della rete

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

Decisioni per i progetti di rete.

Il diagramma precedente ti guida attraverso le seguenti domande:

  1. Hai bisogno dell'ispezione del livello 7 utilizzando appliance di rete tra diversi carichi di lavoro inGoogle Cloud?
  2. Molti dei tuoi carichi di lavoro richiedono la 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 modello di producer e consumer di servizi?
  4. Vuoi amministrare il firewalling e il routing a livello centrale?

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

Opzioni di progettazione della rete

Le sezioni seguenti 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 di casi limite organizzativi.

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 le reti VPC condiviso nelle topologie hub e spoke per una migliore collaborazione, un controllo centralizzato e per limitare il numero di spoke VPC. In alternativa, potresti progettare la maggior parte dei workload in una topologia VPC condiviso, ma isolare un numero ridotto di workload in reti VPC separate che espongono i servizi solo tramite alcuni endpoint definiti utilizzando Private Service Connect.

Opzione 1: rete VPC condiviso per ogni ambiente

Consigliamo questa progettazione di rete per la maggior parte dei casi d'uso. Questo design utilizza reti VPC condiviso separate per ogni ambiente di deployment che hai inGoogle Cloud (sviluppo, test e produzione). Questo design consente di gestire a livello centrale le risorse di rete 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 centralizzato sulle regole di firewall e routing.
  • Hai bisogno di un'infrastruttura semplice e scalabile.
  • Hai bisogno di una gestione centralizzata dello spazio degli indirizzi IP.

Evita questo design quando si verifica quanto segue:

  • Vuoi che i team di sviluppo abbiano piena autonomia, inclusa la possibilità di gestire le proprie regole firewall, il routing e il peering con altre reti del team.
  • È necessaria l'ispezione di livello 7 utilizzando le appliance NGFW.

Il seguente diagramma mostra un'implementazione di esempio di questa progettazione.

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 sviluppo sono connessi a entrambe le istanze Cloud Interconnect con collegamenti VLAN diversi.
  • Ogni VPC condiviso ha 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 di un ambiente non può raggiungere un altro ambiente. Tuttavia, se specifici workload devono comunicare tra loro, puoi consentire il trasferimento dei dati tramite canali controllati on-premise oppure puoi condividere i dati tra le applicazioni con servizi come Cloud Storage o Pub/Sub. Google Cloud Ti consigliamo di evitare di connettere direttamente ambienti separati tramite il peering di rete VPC, perché aumenta il rischio di combinare 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 VPC relative al peering e ai gruppi di peering.

Per ulteriori informazioni, consulta le seguenti risorse:

Per implementare questa opzione di progettazione, consulta Opzione di creazione 1: rete VPC condiviso per ogni ambiente.

Opzione 2: topologia hub-and-spoke con appliance centralizzate

Questa progettazione di rete utilizza la topologia hub-and-spoke. Una rete VPC hub contiene un insieme di VM appliance come i firewall NGFW che sono connessi alle reti VPC spoke che contengono i workload. Il traffico tra i workload, le reti on-premise o internet viene instradato tramite le VM appliance per l'ispezione e il filtraggio.

Utilizza questo design quando si verifica quanto segue:

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

Evita questo design quando si verifica quanto segue:

  • Non è necessaria l'ispezione del livello 7 per la maggior parte dei tuoi carichi di lavoro.
  • Vuoi che i workload su Google Cloud non comunichino tra loro.
  • È necessaria solo l'ispezione di livello 7 per il traffico diretto alle reti on-premise.

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

Diagramma dell'opzione 2.

Il diagramma precedente mostra quanto segue:

  • Un ambiente di produzione che include una rete VPC hub e più reti VPC spoke che contengono i workload.
  • Le reti VPC spoke sono connesse alla rete VPC hub tramite il peering di rete VPC.
  • La rete VPC hub ha 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 di transito alle località on-premise.
  • Le reti on-premise sono connesse tramite gli stessi Cloud Interconnect utilizzando collegamenti VLAN separati.
  • Le reti VPC di transito sono connesse a un'interfaccia di rete separata sulle appliance virtuali, il che ti consente di ispezionare e filtrare tutto il traffico verso e da queste reti utilizzando la tua appliance.
  • L'ambiente di sviluppo ha la stessa struttura VPC dell'ambiente di produzione.
  • Questa configurazione non utilizza la Network Address Translation dell'origine (SNAT). SNAT non è richiesto perché Google Cloud utilizza l'hashing simmetrico. Per maggiori informazioni, consulta Hashing simmetrico.

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

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 insieme di appliance e un VPC hub per ogni ambiente in ogni regione. In alternativa, puoi utilizzare i tag di rete con le 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 i 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 vuoi che un team di rete centrale abbia il controllo completo sulle regole firewall, valuta la possibilità di implementarle 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, ti consigliamo di utilizzare il peering di rete VPC per connettere la rete VPC hub e le reti VPC spoke perché aggiunge una complessità minima. Tuttavia, il numero massimo di raggi è limitato da quanto segue:

  • Il limite per le connessioni di peering di rete VPC da una singola rete VPC.
  • Limiti del gruppo di peering, ad esempio il numero massimo di regole di inoltro 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 aggiunge costi e complessità extra 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, consulta Creare l'opzione 2: topologia hub-and-spoke con appliance centralizzate.

Opzione 3: topologia hub e spoke senza appliance

Questo progetto di rete utilizza anche una topologia hub-and-spoke, con una rete VPC hub che si connette alle reti on-premise e alle reti VPC spoke che contengono i workload. Poiché il peering di rete VPC non è transitivo, 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 utilizzando indirizzi IP interni, ma vuoi che condividano la connettività on-premise.
  • Vuoi dare ai team autonomia nella gestione delle proprie regole di firewall e di routing.

Evita questo design quando si verifica quanto segue:

  • È necessaria l'ispezione di livello 7 tra i carichi di lavoro.
  • Vuoi gestire centralmente le regole di routing e firewall.
  • Hai bisogno di comunicazioni dai servizi on-premise ai servizi gestiti che sono connessi agli spoke tramite un altro peering di rete VPC, perché il peering di rete VPC non è transitivo.

Il seguente diagramma mostra un'implementazione di esempio di questa progettazione.

Diagramma dell'opzione 3.

Il diagramma precedente mostra quanto segue:

  • Un ambiente di produzione che include una rete VPC hub e più reti VPC spoke che contengono i workload.
  • Le reti VPC spoke sono connesse alla rete VPC hub tramite il peering di rete VPC.
  • La connettività alle posizioni 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 progettazione, il traffico di una rete spoke non può raggiungere un'altra rete spoke. Tuttavia, se specifici carichi di lavoro devono comunicare tra loro, puoi configurare il peering diretto tra le reti spoke utilizzando il peering di rete VPC oppure puoi condividere i dati tra le applicazioni con servizi come Cloud Storage o Pub/Sub. Google Cloud

Questo design di rete viene spesso utilizzato in ambienti in cui i team agiscono in modo autonomo e non esiste un controllo centralizzato sulle regole di firewall e routing. Tuttavia, la scalabilità di questo progetto è limitata da quanto segue:

Pertanto, questo design non viene in genere utilizzato nelle grandi organizzazioni che hanno molti carichi di lavoro separati su Google Cloud.

Come variante della progettazione, puoi utilizzare Cloud VPN anziché il peering di rete VPC. Cloud VPN ti consente di aumentare il numero di spoke, ma aggiunge un limite di larghezza di banda per ogni tunnel e aumenta la complessità e i costi. Quando utilizzi le route pubblicizzate personalizzate, 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, consulta Crea opzione 3: topologia hub-and-spoke senza appliance.

Opzione 4: esporre 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ò essere anche una rete VPC condiviso. Ogni rete VPC viene gestita in modo indipendente e utilizza Private Service Connect per esporre tutti i servizi a cui è necessario 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 tramite endpoint definiti.
  • Vuoi che i team siano indipendenti l'uno dall'altro e gestiscano il proprio spazio di indirizzi IP, i firewall e le regole di routing.

Evita questo design quando si verifica quanto segue:

  • La comunicazione tra servizi e applicazioni utilizza molte porte o canali diversi oppure le porte e i canali cambiano di frequente.
  • La comunicazione tra i carichi di lavoro utilizza protocolli diversi da TCP o UDP.
  • È necessaria l'ispezione di livello 7 tra i carichi di lavoro.

Il seguente diagramma mostra un'implementazione di esempio 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 al servizio nella rete VPC in cui si trova il servizio. Il collegamento del 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 del carico di lavoro possono raggiungere i carichi di lavoro che si trovano on-premise nel seguente modo:
    • L'endpoint è collegato a un collegamento del servizio in una rete VPC di transito.
    • L'allegato del servizio è connesso alla rete on-premise utilizzando Cloud Interconnect.
  • Un bilanciatore del carico delle applicazioni interno è collegato al collegamento al servizio e utilizza un gruppo di endpoint di rete ibrido 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 di transito che si connettono ai collegamenti di servizio nelle reti VPC del workload.

Per ulteriori informazioni, consulta le seguenti risorse:

Per implementare questa opzione di progettazione, consulta Opzione di creazione 4: esporre i servizi in un modello consumer-producer con Private Service Connect.

Best practice per il deployment di rete

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

Per saperne di più, consulta Best practice e architetture di riferimento per la progettazione di VPC.

Passaggi successivi