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

Last reviewed 2023-09-11 UTC

Quando progetti la zona di destinazione, devi scegliere una struttura di rete che funzioni per la tua organizzazione. Questo documento descrive quattro progetti di rete comuni. ti aiuta a scegliere l'opzione più adatta ai requisiti della tua organizzazione, e la preferenza della tua organizzazione in termini di controllo centralizzato o decentralizzato controllo. È destinata a tecnici di rete, architetti e tecnici coinvolti nella creazione della progettazione della rete per zona di destinazione dell'organizzazione.

Questo articolo fa parte di una serie zone di destinazione.

Scegli la progettazione della rete

La progettazione della rete che scegli dipende principalmente da quanto segue: fattori:

  • Controllo centralizzato o decentralizzato: a seconda del preferenze dell'organizzazione, devi scegliere una delle seguenti opzioni:
      .
    • Centralizza il controllo sulla rete, inclusi gli indirizzi IP, il routing e il firewall tra diversi carichi di lavoro.
    • Dai ai tuoi team una maggiore autonomia nella gestione dei propri ambienti e creando elementi di rete all'interno dei rispettivi ambienti le istanze server autonomamente.
  • Opzioni di connettività on-premise o su cloud ibrido: tutta la rete i progetti discussi in questo documento forniscono l'accesso da on-premise al cloud ambienti tramite Cloud VPN o Cloud Interconnect. Tuttavia, alcune progettazioni richiedono la configurazione di più connessioni in parallelo, mentre altri usano la stessa connessione per tutti i carichi di lavoro.
  • Requisiti di sicurezza: la tua organizzazione potrebbe richiedere traffico. tra diversi carichi di lavoro in Google Cloud di appliance di rete centralizzate come firewall di nuova generazione (NGFW). Questo vincolo influenza la progettazione della tua rete Virtual Private Cloud (VPC).
  • Scalabilità: alcuni design potrebbero essere migliori di altri per la tua organizzazione, in base al numero di carichi di lavoro di cui vuoi eseguire il deployment e al numero macchine virtuali (VM), bilanciatori del carico interni e altre risorse consumare.

Punti decisionali per la progettazione di rete

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

Decisioni per progettazioni di rete.

Il diagramma precedente illustra le seguenti domande:

  1. Hai bisogno Livello 7 l'ispezione mediante appliance di rete tra diversi carichi di lavoro in Google Cloud?
  2. Molti dei tuoi carichi di lavoro richiedono connettività on-premise?
    • In caso affermativo, vai al punto decisionale 4.
    • In caso contrario, passa alla domanda successiva.
  3. I tuoi carichi di lavoro possono comunicare usando endpoint privati in un servizio il modello di produttore e consumatore?
  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ò essere utile anche se potrebbero essere adatti più design alla tua organizzazione. In queste , ti consigliamo di scegliere il design più adatto alle tue esigenze per verificare se è così.

Opzioni di progettazione della rete

Le seguenti sezioni descrivono quattro opzioni di progettazione comuni. Opzione consigliata 1 per la maggior parte dei casi d'uso. Gli altri progetti discussi in questa sezione sono alternative che si applicano a requisiti specifici di casi periferici dell'organizzazione.

La soluzione migliore per il tuo caso d'uso potrebbe essere anche una rete che combina elementi da più opzioni di progettazione illustrate in questa sezione. Ad esempio, puoi utilizzare VPC condiviso reti in topologie hub e spoke per una migliore collaborazione, e limitare il numero di spoke VPC. Oppure potresti Progettare la maggior parte dei carichi di lavoro in una topologia VPC condiviso, ma isolare un piccolo di carichi di lavoro in reti VPC separate che espongono solo attraverso 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 modelli Reti VPC condiviso per ogni ambiente di deployment in uso Google Cloud (sviluppo, test e produzione). Questo design ti consente gestire centralmente le risorse di rete in una rete comune e fornire e l'isolamento 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 questa struttura quando si verifica quanto segue:

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

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

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 le istanze Cloud Interconnect a due VPC condiviso separati una per la produzione e una per lo sviluppo.
  • Gli ambienti di produzione e di sviluppo sono connessi le istanze Cloud Interconnect Collegamenti VLAN.
  • Ogni VPC condiviso dispone di progetti di servizio che ospitano i carichi di lavoro.
  • Le regole firewall sono amministrate centralmente nel progetto host.
  • L'ambiente di sviluppo ha la stessa struttura VPC dell'ambiente nell'ambiente di produzione.

In base alla progettazione, il traffico proveniente da un ambiente non può raggiungerne un altro. Tuttavia, se carichi di lavoro specifici devono comunicare tra loro, puoi consentire puoi trasferire dati tramite canali controllati on-premise 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 combinare accidentalmente tra gli ambienti. Utilizzo del peering di rete VPC tra modelli aumenta anche il rischio di colpire Quote VPC intorno ai gruppi di peering e ai gruppi di peering.

Per ulteriori informazioni, consulta le seguenti risorse:

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

Opzione 2: topologia hub e spoke con elettrodomestici centralizzati

Questa progettazione di rete utilizza una topologia hub e spoke. Un VPC hub che contiene un insieme di VM dell'appliance, come le NGFW, collegate reti VPC spoke che contengono i carichi di lavoro. Traffico tra i carichi di lavoro, le reti on-premise oppure internet è instradata tramite le VM dell'appliance per l'ispezione e il filtro.

Utilizza questo design quando si verifica quanto segue:

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

Evita questa struttura quando 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 con tra loro.
  • È necessaria solo l'ispezione di livello 7 per il traffico che va verso on-premise di Google Cloud, come descritto in Caso d'uso speciale con una rete VPC condivisa su Google Cloud.

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 di più reti VPC spoke che contengono i carichi di lavoro.
  • Le reti VPC spoke sono connesse all'hub tramite peering di rete VPC.
  • La rete VPC hub ha più istanze di un in una gruppo di istanze gestite. Il traffico verso il gruppo di istanze gestite passa un bilanciatore del carico di rete passthrough interno.
  • Le reti VPC spoke comunicano tra loro tramite virtuale di Google Cloud utilizzando route statiche con il bilanciatore del carico interno come nell'hop successivo.
  • Cloud Interconnect connette le reti VPC di transito alle località on-premise.
  • Le reti on-premise sono connesse tramite lo stesso Cloud Interconnect utilizzando collegamenti VLAN separati.
  • Le reti VPC di transito sono collegate a un'interfaccia di rete separata sulle appliance virtuali, che consente di ispezionare e filtrare tutto il traffico e da queste reti utilizzando l'appliance.
  • L'ambiente di sviluppo ha la stessa struttura VPC dell'ambiente nell'ambiente di produzione.
  • Questa configurazione non utilizza SNAT (Network Address Translation) di origine. SEGNAPOSTO non è obbligatorio perché Google Cloud utilizza l'hashing simmetrico. Per ulteriori informazioni vedi Hashing simmetrico.

In base alla progettazione, 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 configurare il peering diretto tra le reti spoke utilizzando il peering di rete VPC possono condividere dati tra applicazioni con servizi Google Cloud come in Cloud Storage o Pub/Sub.

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

Regole firewall può limitare la connettività all'interno delle reti VPC spoke per contenere carichi di lavoro. Spesso, i team che amministrano i carichi di lavoro amministrano anche queste regole firewall. Per i criteri centrali, puoi utilizzare criteri firewall gerarchici. Se hai bisogno che un team di rete centrale abbia il controllo completo sulle regole firewall, considera la possibilità il deployment di queste regole in tutte le reti VPC mediante Approccio GitOps. In questo caso, limita le autorizzazioni IAM solo a quelle amministratori che possono modificare le regole firewall. VPC spoke le reti possono anche essere reti VPC condiviso se più team eseguono il deployment spoke.

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

  • Il limite attivo Connessioni di peering di rete VPC da una singola rete VPC.
  • I limiti del gruppo di peering, ad esempio il numero massimo di regole di forwarding il bilanciamento del carico TCP/UDP interno per ciascun gruppo di peering.

Se prevedi di raggiungere questi limiti, puoi connettere le reti spoke tramite o 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, consulta Crea l'opzione 2: topologia hub e spoke con appliance centralizzate.

Opzione 3: topologia hub e spoke senza appliance

Questa progettazione di rete utilizza anche una topologia hub e spoke, con un Rete VPC che si connette a reti e spoke on-premise sulle reti VPC che contengono carichi di lavoro con scale out impegnativi. 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 comunicare tra loro tramite indirizzi IP interni, ma condividono la connettività on-premise.
  • Vuoi concedere ai team l'autonomia nella gestione dei propri firewall regole di routing.

Evita questa struttura quando si verifica quanto segue:

  • È necessaria un'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 connesse agli spoke tramite un altro peering di rete VPC, poiché il peering di rete VPC non è transitivo.

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

Diagramma dell'opzione 3.

Il diagramma precedente mostra quanto segue:

  • Un ambiente di produzione che include una rete VPC hub di più reti VPC spoke che contengono i carichi di lavoro.
  • Le reti VPC spoke sono connesse all'hub tramite peering di rete VPC.
  • La connettività alle località on-premise passa Connessioni Cloud Interconnect nel VPC hub in ogni rete.
  • Le reti on-premise sono connesse tramite Istanze Cloud Interconnect utilizzando collegamenti VLAN separati.
  • L'ambiente di sviluppo ha la stessa struttura VPC dell'ambiente nell'ambiente di produzione.

In base alla progettazione, 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 configurare il peering diretto tra le reti spoke utilizzando il peering di rete VPC possono condividere dati tra applicazioni con servizi Google Cloud come in Cloud Storage o Pub/Sub.

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

Pertanto, questa struttura non è solitamente utilizzata nelle grandi organizzazioni che hanno per molti carichi di lavoro separati su Google Cloud.

Come variante del design, puoi utilizzare Cloud VPN anziché peering di rete VPC. Cloud VPN ti consente di aumentare il numero degli spoke, ma aggiunge limite di larghezza di banda per ogni tunnel e aumenta la complessità e i costi. Quando utilizzi route annunciate personalizzate, Cloud VPN consente inoltre la transitività tra gli spoke senza che richiedono la connessione diretta di tutte le reti spoke.

Per ulteriori informazioni, consulta le seguenti risorse:

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

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

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

Utilizza questo design quando si verifica quanto segue:

  • I carichi di lavoro comunicano solo tra loro e con l'ambiente on-premise attraverso endpoint definiti.
  • Vuoi che i team siano indipendenti gli uni dagli altri e gestiscano i propri indirizzi IP di indirizzi IP, firewall e regole di routing.

Evita questa struttura quando si verifica quanto segue:

  • La comunicazione tra servizi e applicazioni utilizza molte porte e canali oppure porte e canali cambiano di frequente.
  • La comunicazione tra i carichi di lavoro utilizza protocolli diversi da TCP o UDP.
  • È necessaria un'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:

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

Per ulteriori informazioni, consulta le seguenti risorse:

Per implementare questa opzione di progettazione, consulta Crea l'opzione 4: esponi i servizi in un modello consumer-producer con Private Service Connect.

Best practice per il deployment di rete

Dopo aver scelto la progettazione di rete più adatta al tuo caso d'uso, ti consigliamo di implementare le seguenti best practice:

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

Passaggi successivi