Segmentazione della rete e connettività per le applicazioni distribuite in Cross-Cloud Network

Last reviewed 2025-01-30 UTC

Questo documento fa parte di una serie di guide alla progettazione per Cross-Cloud Network.

La serie è composta dai seguenti componenti:

Questa parte illustra la struttura e la connettività della segmentazione della rete, che costituisce la base del design. Questo documento illustra le fasi in cui puoi effettuare le seguenti scelte:

  • La segmentazione della rete e la struttura del progetto complessive.
  • Dove posizioni il carico di lavoro.
  • Il modo in cui i tuoi progetti sono connessi alle reti on-premise esterne e ad altre reti di fornitori di servizi cloud, inclusa la progettazione per connettività, routing e crittografia.
  • Il modo in cui le reti VPC sono connesse tra loro internamente.
  • Come le tue Google Cloud subnet VPC sono collegate tra loro e ad altre reti, inclusa la configurazione della raggiungibilità dei servizi e del DNS.

Segmentazione della rete e struttura del progetto

Durante la fase di pianificazione, devi scegliere tra una delle due strutture del progetto:

  • Un progetto host di infrastruttura consolidato, in cui utilizzi un singolo progetto host di infrastruttura per gestire tutte le risorse di rete per tutte le applicazioni
  • Progetti host segmentati, in cui utilizzi un progetto host di infrastruttura in combinazione con un progetto host diverso per ogni applicazione

Durante la fase di pianificazione, ti consigliamo di decidere anche i domini amministrativi per gli ambienti di lavoro. Definisci l'ambito delle autorizzazioni per gli amministratori e gli sviluppatori dell'infrastruttura in base al principio del privilegio minimo e definisci l'ambito delle risorse dell'applicazione in progetti di applicazioni diversi. Poiché gli amministratori dell'infrastruttura devono configurare la connettività per condividere le risorse, queste possono essere gestite all'interno di un progetto di infrastruttura. Ad esempio, per configurare la connettività alle risorse di infrastruttura condivise, gli amministratori dell'infrastruttura possono utilizzare un progetto di infrastruttura per gestire queste risorse condivise. Allo stesso tempo, il team di sviluppo potrebbe gestire i propri carichi di lavoro in un progetto e il team di produzione in un progetto separato. Gli sviluppatori utilizzeranno quindi le risorse di infrastruttura nel progetto di infrastruttura per creare e gestire risorse, servizi, bilanciamento del carico e criteri di routing DNS per i loro carichi di lavoro.

Inoltre, devi decidere quante reti VPC implementerai inizialmente e come verranno organizzate nella gerarchia delle risorse. Per maggiori dettagli su come scegliere una gerarchia delle risorse, consulta Decidere una gerarchia delle risorse per la tua Google Cloud zona di destinazione. Per informazioni dettagliate su come scegliere il numero di reti VPC, consulta Decidere se creare più reti VPC.

Per la rete cross-cloud, ti consigliamo di utilizzare le seguenti reti VPC:

  • Uno o più VPC di applicazioni per ospitare le risorse per le diverse applicazioni.
  • Uno o più VPC di transito, in cui viene gestita tutta la connettività esterna.
  • Uno o più VPC di accesso ai servizi, che possono essere utilizzati per consolidare il deployment dell'accesso privato ai servizi pubblicati.

Il seguente diagramma mostra una rappresentazione visiva della struttura VPC consigliata appena descritta. Puoi utilizzare la struttura VPC mostrata nel diagramma con una struttura di progetto consolidata o segmentata, come descritto nelle sezioni successive. Il diagramma mostrato qui non mostra la connettività tra le reti VPC.

Struttura VPC consigliata

Progetto host dell'infrastruttura consolidata

Puoi utilizzare un progetto host di infrastruttura consolidato per gestire tutte le risorse di rete come reti e subnet VPC, hub Network Connectivity Center, peering di rete VPC e bilanciatori del carico.

Nel progetto host dell'infrastruttura è possibile creare più VPC condivise per le applicazioni con i relativi progetti di servizio per le applicazioni in modo che corrispondano alla struttura dell'organizzazione. Utilizza più progetti di servizi di applicazioni per delegare l'amministrazione delle risorse. Tutta la rete in tutte le reti VPC delle applicazioni viene fatturata al progetto host dell'infrastruttura consolidata.

Per questa struttura di progetto, molti progetti di servizi di applicazioni possono condividere un numero minore di VPC di applicazioni.

Il seguente diagramma fornisce una rappresentazione visiva del progetto host dell'infrastruttura consolidata e di più progetti di servizi di applicazioni appena descritti. Il diagramma non mostra la connettività tra tutti i progetti.

Progetto host dell'infrastruttura consolidata e più progetti di servizi di applicazioni

Progetti host segmentati

In questo pattern, ogni gruppo di applicazioni ha il proprio progetto host dell'applicazione e le proprie reti VPC. È possibile collegare più progetti di servizi di applicazioni al progetto host. La fatturazione dei servizi di rete è suddivisa tra il progetto host dell'infrastruttura e i progetti host dell'applicazione. Gli addebiti per l'infrastruttura vengono fatturati al progetto di hosting dell'infrastruttura, mentre gli addebiti di rete, come quelli per il trasferimento dei dati per le applicazioni, vengono fatturati a ogni progetto di hosting dell'applicazione.

Il seguente diagramma fornisce una rappresentazione visiva dei più progetti host e dei più progetti di servizi di applicazioni appena descritti. Il diagramma non mostra la connettività tra tutti i progetti.

Più progetti host e più progetti di servizi di applicazioni

Posizionamento del carico di lavoro

Molte scelte di connettività dipendono dalle località regionali dei tuoi workload. Per indicazioni su come posizionare i carichi di lavoro, consulta le best practice per la scelta delle regioni Compute Engine. Devi decidere dove si troveranno i tuoi workload prima di scegliere le località di connettività.

Connettività esterna e ibrida

Questa sezione descrive i requisiti e i consigli per i seguenti percorsi di connettività:

  • Connessioni private ad altri cloud provider
  • Connessioni private ai data center on-premise
  • Connettività a internet per i carichi di lavoro, in particolare la connettività in uscita

Cross-Cloud Network prevede l'interconnessione di più reti cloud o on-premise. Le reti esterne possono essere di proprietà e gestite da organizzazioni diverse. Queste reti si connettono fisicamente tra loro tramite una o più interfacce network-to-network (NNI). La combinazione di NNI deve essere progettata, pianificata e configurata per prestazioni, resilienza, privacy e sicurezza.

Per modularità, riutilizzabilità e la possibilità di inserire NVA di sicurezza, posiziona le connessioni esterne e il routing in un VPC di transito, che funge da servizio di connettività condivisa per altri VPC. Le policy di routing per resilienza, failover e preferenza del percorso tra i domini possono essere configurate una volta nella VPC di transito e sfruttate da molte altre reti VPC.

Il design degli NNI e la connettività esterna vengono utilizzati in un secondo momento per la connettività interna e la rete VPC.

Il seguente diagramma mostra un VPC di transito che funge da servizio di connettività condiviso per altri VPC, connessi tramite peering di rete VPC, Network Connectivity Center o VPN ad alta disponibilità. Per semplicità illustrativa, il diagramma mostra un singolo VPC di transito, ma puoi utilizzare più VPC di transito per la connettività in regioni diverse.

VPC di transito utilizzato come servizio di connettività condiviso per altri VPC

Connessioni private ad altri cloud provider

Se hai servizi in esecuzione in altre reti di fornitori di servizi cloud (CSP) che vuoi collegare alla tua Google Cloud rete, puoi connetterti tramite internet o tramite connessioni private. Ti consigliamo di utilizzare connessioni private.

Quando scegli le opzioni, tieni conto di throughput, privacy, costo e fattibilità operativa.

Per massimizzare il throughput e migliorare la privacy, utilizza una connessione diretta ad alta velocità tra le reti cloud. Le connessioni dirette eliminano la necessità di attrezzature di rete fisiche intermedie. Ti consigliamo di utilizzare Cross-Cloud Interconnect, che fornisce queste connessioni dirette, nonché crittografia MACsec e un tasso di throughput fino a 100 Gbps per link.

Se non puoi utilizzare Cross-Cloud Interconnect, puoi utilizzare Dedicated Interconnect o Partner Interconnect tramite una struttura di colocation.

Seleziona le località in cui ti connetti agli altri fornitori di servizi cloud in base alla vicinanza delle località alle regioni di destinazione. Per la scelta della località, tieni presente quanto segue:

  • Controlla l'elenco delle località:
    • Per Cross-Cloud Interconnect, consulta l'elenco di sedi disponibili sia per Google Cloud che per i CSP (la disponibilità varia in base al provider cloud).
    • Per Dedicated Interconnect o Partner Interconnect, scegli una località con bassa latenza per la struttura di colocation.
  • Valuta la latenza tra il punto di presenza (POP) specificato e la regione pertinente in ogni CSP.

Per massimizzare l'affidabilità delle connessioni tra cloud, consigliamo una configurazione che supporti uno SLA con uptime del 99,99% per i carichi di lavoro di produzione. Per maggiori dettagli, consulta Elevata disponibilità di Cross-Cloud Interconnect, Stabilire una disponibilità del 99,99% per Dedicated Interconnect e Stabilire una disponibilità del 99,99% per Partner Interconnect.

Se non hai bisogno di una larghezza di banda elevata tra diversi fornitori di servizi cloud, puoi utilizzare i tunnel VPN. Questo approccio può aiutarti a iniziare e puoi eseguire l'upgrade a Cross-Cloud Interconnect quando le tue applicazioni distribuite utilizzano più larghezza di banda. Anche i tunnel VPN possono raggiungere uno SLA del 99,99%. Per maggiori dettagli, consulta Topologie VPN ad alta disponibilità.

Connessioni private ai data center on-premise

Per la connettività ai data center privati, puoi utilizzare una delle seguenti opzioni di connettività ibrida:

  • Dedicated Interconnect
  • Partner Interconnect
  • VPN ad alta disponibilità

Le considerazioni sul routing per queste connessioni sono simili a quelle per le connessioni private ad altri cloud provider.

Il seguente diagramma mostra le connessioni alle reti on-premise e come i router on-premise possono connettersi a Cloud Router tramite un criterio di peering:

Connessioni alle reti on-premise

Routing interdominio con reti esterne

Per aumentare la resilienza e la velocità effettiva tra le reti, utilizza più percorsi per collegarle.

Quando il traffico viene trasferito tra i domini di rete, deve essere ispezionato da dispositivi di sicurezza stateful. Di conseguenza, è necessaria la simmetria del flusso al confine tra i domini.

Per le reti che trasferiscono dati in più regioni, il costo e il livello di qualità del servizio di ogni rete potrebbero variare notevolmente. In base a queste differenze, potresti decidere di utilizzare alcune reti rispetto ad altre.

Configura il criterio di routing interdominio in modo da soddisfare i tuoi requisiti per il transito interregionale, la simmetria del traffico, il throughput e la resilienza.

La configurazione dei criteri di routing interdominio dipende dalle funzioni disponibili all'edge di ciascun dominio. La configurazione dipende anche da come sono strutturati i domini adiacenti dal punto di vista di un sistema autonomo e dell'indirizzamento IP (subnetting) in regioni diverse. Per migliorare la scalabilità senza superare i limiti di prefisso sui dispositivi edge, ti consigliamo di scegliere un piano di indirizzamento IP che generi meno prefissi aggregati per ogni combinazione di regione e dominio.

Quando progetti il routing interregionale, tieni presente quanto segue:

  • Google Cloud Le reti VPC e il router Cloud supportano entrambi il routing tra regioni globali. Altri fornitori di servizi cloud potrebbero avere VPC regionali e ambiti BGP (Border Gateway Protocol). Per maggiori dettagli, consulta la documentazione dell'altro CSP.
  • Cloud Router annuncia automaticamente le route con preferenze di percorso predeterminate in base alla vicinanza regionale. Questo comportamento di routing dipende dalla modalità di routing dinamico configurata della VPC. Potresti dover eseguire l'override di queste preferenze per il comportamento di routing che preferisci.
  • I diversi fornitori di servizi cloud supportano funzioni BGP e BFD (Bidirectional Forwarding Detection) diverse e il router cloud di Google dispone anche di funzionalità specifiche per le policy di route, come descritto in Creare sessioni BGP.
  • CSP diversi potrebbero utilizzare attributi di parità BGP diversi per stabilire la preferenza per le route. Per maggiori dettagli, consulta la documentazione del tuo fornitore di servizi cloud.

Routing interdominio in una singola regione

Ti consigliamo di iniziare con il routing interdominio per una singola regione, su cui puoi basarti per creare più connessioni tra regioni con routing interdominio.

I design che utilizzano Cloud Interconnect devono avere almeno due località di connessione nella stessa regione, ma con domini di disponibilità perimetrale diversi.

Decidi se configurare queste connessioni duplicate in un design attivo/attivo o attivo/passivo:

  • La modalità Attivo/attivo utilizza il routing ECMP (Equal-cost multipath) per aggregare la larghezza di banda di entrambi i percorsi e utilizzarli contemporaneamente per il traffico interdominio. Cloud Interconnect supporta anche l'utilizzo di link aggregati LACP per raggiungere fino a 200 Gbps di larghezza di banda aggregata per percorso.
  • La modalità Attivo/passivo forza un link in modalità standby, che gestisce il traffico solo se il link attivo viene interrotto.

Consigliamo un design attivo/attivo per i collegamenti all'interno della regione. Tuttavia, determinate reti on-premise combinate con l'utilizzo di funzioni di sicurezza stateful possono richiedere un design attivo/passivo.

Cloud Router viene creato in più zone, il che offre una resilienza superiore rispetto a un singolo elemento. Il seguente diagramma mostra come tutte le connessioni resilienti convergono su un unico router Cloud all'interno di una regione. Questo design può supportare uno SLA con disponibilità del 99,9% all'interno di una singola area metropolitana se vengono seguite le linee guida per stabilire una disponibilità del 99,9% per Dedicated Interconnect.

Il seguente diagramma mostra due router on-premise connessi in modo ridondante al servizio Cloud Router gestito in un'unica regione:

Le connessioni resilienti possono utilizzare un singolo router Cloud

Routing interdominio multiregionale

Per fornire connettività di riserva, le reti possono essere in peering in più aree geografiche. Se colleghi le reti in più regioni, l'SLA di disponibilità può aumentare fino al 99,99%.

Il seguente diagramma mostra le architetture con SLA del 99,99%. Mostra i router on-premise in due località diverse connessi in modo ridondante ai servizi Cloud Router gestiti in due regioni diverse.

Connessioni Cloud Interconnect in più regioni

Oltre alla resilienza, il design del routing multiregionale deve garantire la simmetria del flusso. Il design deve indicare anche la rete preferita per le comunicazioni interregionali, che puoi utilizzare con il routing hot-potato e cold-potato. Accoppia il routing a patate fredde in un dominio con il routing a patate calde nel dominio peer. Per il dominio cold-potato, consigliamo di utilizzare ilGoogle Cloud dominio di rete, che fornisce la funzionalità di routing VPC globale.

La simmetria del flusso non è sempre obbligatoria, ma l'asimmetria del flusso può causare problemi con le funzioni di sicurezza stateful.

Il seguente diagramma mostra come utilizzare il routing hot-potato e cold-potato per specificare la rete di trasporto interregionale che preferisci. In questo caso, il traffico proveniente dai prefissi X e Y rimane nella rete di origine fino a quando non raggiunge la regione più vicina alla destinazione (routing cold-potato). Il traffico proveniente dai prefissi A e B passa all'altra rete nella regione di origine, quindi viaggia attraverso l'altra rete fino alla destinazione (routing hot-potato).

Utilizzo del routing hot-potato e cold-potato per specificare la rete di trasporto pubblico interregionale che preferisci

Crittografia del traffico tra domini

Salvo diversa indicazione, il traffico non viene criptato sulle connessioni Cloud Interconnect tra diversi fornitori di servizi cloud o tra questi e i data center on-premise. Google Cloud Se la tua organizzazione richiede la crittografia per questo traffico, puoi utilizzare le seguenti funzionalità:

  • MACsec per Cloud Interconnect:cripta il traffico sulle connessioni Cloud Interconnect tra i tuoi router e i router di confine di Google. Per maggiori dettagli, consulta la panoramica di MACsec per Cloud Interconnect.
  • VPN ad alta disponibilità su Cloud Interconnect:utilizza più tunnel VPN ad alta disponibilità per poter fornire l'intera larghezza di banda delle connessioni Cloud Interconnect sottostanti. I tunnel VPN ad alta disponibilità sono criptati con IPsec e vengono implementati su connessioni Cloud Interconnect che possono essere anche criptate con MACsec. In questa configurazione, le connessioni Cloud Interconnect sono configurate per consentire solo il traffico VPN ad alta disponibilità. Per maggiori dettagli, consulta la panoramica della VPN ad alta disponibilità su Cloud Interconnect.

Connettività a internet per i carichi di lavoro

Per la connettività a internet in entrata e in uscita, si presume che il traffico di risposta segua in modo statoso la direzione opposta a quella della richiesta originale.

In genere, le funzionalità che forniscono connettività internet in entrata sono separate dalle funzionalità internet in uscita, ad eccezione degli indirizzi IP esterni che forniscono entrambe le direzioni contemporaneamente.

Connettività a internet in entrata

La connettività in entrata su internet riguarda principalmente la fornitura di endpoint pubblici per i servizi ospitati sul cloud. Alcuni esempi sono la connettività internet ai server di applicazioni web e ai server di giochi ospitati su Google Cloud.

Le funzionalità principali che forniscono connettività in entrata a internet sono i prodotti Cloud Load Balancing di Google. Il design di una rete VPC è indipendente dalla sua capacità di fornire connettività internet in entrata:

Connettività a internet in uscita

Alcuni esempi di connettività a internet in uscita (in cui la richiesta iniziale proviene dal carico di lavoro a una destinazione internet) includono i carichi di lavoro che accedono alle API di terze parti, scaricano pacchetti software e aggiornamenti e inviano notifiche push agli endpoint webhook su internet.

Per la connettività in uscita, puoi utilizzare le opzioni Google Cloud integrate, come descritto in Creare la connessione a internet per le VM private. In alternativa, puoi utilizzare le NVA NGFW centrali come descritto in Sicurezza di rete.

Il percorso principale per fornire connettività in uscita a internet è la destinazione del gateway internet predefinito nella tabella di routing VPC, che spesso è la route predefinita nelle VPC di Google. Sia gli IP esterni sia Cloud NAT (il servizio NAT gestito diGoogle Cloud) richiedono una route che indichi il gateway internet predefinito della VPC. Pertanto, i design di routing VPC che sostituiscono il route predefinito devono fornire la connettività in uscita tramite altri mezzi. Per maggiori dettagli, consulta la panoramica del router Cloud.

Per proteggere la connettività in uscita, Google Cloud offre sia l'applicazione di Cloud Next Generation Firewall sia di Secure Web Proxy per fornire un filtraggio più approfondito degli URL HTTP e HTTPS. In tutti i casi, tuttavia, il traffico segue la route predefinita per il gateway internet predefinito o tramite una route predefinita personalizzata nella tabella di routing VPC.

Utilizzo dei tuoi indirizzi IP

Puoi utilizzare indirizzi IPv4 di proprietà di Google per la connettività internet oppure utilizzare indirizzi Bring Your Own IP (BYOIP) per utilizzare uno spazio IPv4 di proprietà della tua organizzazione. La maggior parte Google Cloud dei prodotti che richiedono un indirizzo IP instradabile su internet supporta invece l'utilizzo di intervalli BYOIP.

Puoi anche controllare la reputazione dello spazio IP tramite il suo utilizzo esclusivo. BYOIP facilita la portabilità della connettività e può farti risparmiare sui costi degli indirizzi IP.

Connettività interna e reti VPC

Con il servizio di connettività ibrida ed esterna configurato, le risorse nella VPC di transito possono raggiungere le reti esterne. Il passaggio successivo consiste nel rendere disponibile questa connettività alle risorse ospitate in altre reti VPC.

Il seguente diagramma mostra la struttura generale del VPC, indipendentemente da come hai attivato la connettività esterna. Mostra una VPC di transito che termina le connessioni esterne e ospita un router Cloud in ogni regione. Ogni router Cloud riceve route dai propri peer esterni tramite le NNI in ogni regione. I VPC per le applicazioni sono collegati al VPC di transito in modo da poter condividere la connettività esterna. Inoltre, la VPC di transito funge da hub per le VPC spoke. Le VPC spoke possono ospitare applicazioni, servizi o una combinazione di entrambi.

Struttura generale di Cross-Cloud Network

Per prestazioni e scalabilità ottimali con i servizi di cloud networking integrati, i VPC devono essere connessi utilizzando Network Connectivity Center come descritto in Connettività tra VPC con Network Connectivity Center. Network Connectivity Center fornisce quanto segue:

  • Accesso transitivo agli endpoint L4 e L7 di Private Service Connect e ai relativi servizi associati
  • Accesso transitivo alle reti on-premise apprese tramite BGP
  • Scalabilità della rete VPC di 250 reti per hub

Se vuoi inserire appliance virtuali di rete (NVA) per firewall o altre funzioni di rete, devi utilizzare il peering di rete VPC. I firewall perimetrali possono rimanere su reti esterne. Se l'inserimento di un NVA è un requisito, utilizza il pattern Connettività tra VPC con peering di rete VPC per interconnettere le tue VPC.

Configura anche l'inoltro DNS e il peering nella VPC di transito. Per maggiori dettagli, consulta la sezione Progettazione dell'infrastruttura DNS.

Le sezioni seguenti illustrano i possibili design per la connettività ibrida che supportano la connettività IP di base e i deployment dei punti di accesso API.

Connettività tra VPC con Network Connectivity Center

Ti consigliamo di connettere le VPC di applicazione, le VPC di transito e le VPC di accesso ai servizi utilizzando gli spoke VPC di Network Connectivity Center.

I punti di accesso dei consumer di servizi vengono implementati in VPC di accesso ai servizi quando devono essere raggiungibili da altre reti (altre VPC o reti esterne). Puoi implementare punti di accesso consumer di servizi nei VPC dell'applicazione se devono essere raggiunti solo dall'interno del VPC dell'applicazione

Se devi fornire l'accesso ai servizi protetti dall'accesso privato ai servizi, crea un VPC con accesso ai servizi collegato a un VPC di transito utilizzando la VPN ad alta disponibilità. Quindi, connetti il VPC dei servizi gestiti al VPC di accesso ai servizi. La VPN ad alta disponibilità consente il routing transitivo da altre reti.

Il design è una combinazione di due tipi di connettività:

  • Network Connectivity Center: fornisce connettività tra VPC di transito, VPC di applicazioni e VPC di accesso ai servizi che ospitano gli endpoint Private Service Connect.
  • Connessioni inter-VPC VPN ad alta disponibilità: forniscono connettività transitiva per le sottoreti di accesso ai servizi privati ospitate sui VPC di accesso ai servizi. Queste VPC di accesso ai servizi non devono essere aggiunte come spoke dell'hub di Network Connectivity Center.

Quando combini questi tipi di connettività, tieni presenti le seguenti considerazioni:

  • Ridistribuzione delle subnet di peering della rete VPC e delle subnet di peering di Network Connectivity Center nel routing dinamico (al VPC di accesso ai servizi tramite VPN ad alta disponibilità e alle reti esterne tramite interconnessioni ibride)
  • Considerazioni sul routing multiregionale
  • Propagazione di route dinamiche nel peering di rete VPC e nel peering di Network Connectivity Center (dal VPC di accesso ai servizi tramite VPN ad alta disponibilità e dalle reti esterne tramite interconnessioni ibride)

Il seguente diagramma mostra un VPC di accesso ai servizi che ospita subnet di accesso ai servizi privati connesse al VPC di transito con VPN HA. Il diagramma mostra anche le reti VPC per le applicazioni, le reti VPC di transito e le reti VPC per l'accesso ai servizi che ospitano gli endpoint consumer di Private Service Connect connessi utilizzando Network Connectivity Center:

Struttura generale della rete cross-cloud che utilizza gli spoke VPC di Network Connectivity Center

La struttura mostrata nel diagramma precedente contiene i seguenti componenti:

  • Rete esterna: un data center o un ufficio remoto in cui sono presenti apparecchiature di rete. Questo esempio presuppone che le sedi siano collegate tra loro utilizzando una rete esterna.
  • Rete VPC di transito: una rete VPC nel progetto hub che riceve le connessioni da ambienti on-premise e da altri CSP, quindi funge da percorso di transito da altri VPC alle reti on-premise e CSP.
  • VPC per app: progetti e reti VPC che ospitano varie applicazioni.
  • VPC consumer per l'accesso privato ai servizi: una rete VPC che ospita l'accesso centralizzato tramite l'accesso privato ai servizi necessari per le applicazioni in altre reti.
  • VPC di servizi gestiti: servizi forniti e gestiti da altre entità, ma resi accessibili alle applicazioni in esecuzione nelle reti VPC.
  • VPC consumer per Private Service Connect: una rete VPC che ospita i punti di accesso Private Service Connect ai servizi ospitati in altre reti.

Utilizza Network Connectivity Center per connettere le VPC dell'applicazione ai collegamenti VLAN di Cloud Interconnect e alle istanze VPN ad alta disponibilità nelle VPC di transito. Crea tutte le VPC come spoke dell'hub di Network Connectivity Center e gli attacchi VLAN e le VPN ad alta disponibilità come spoke ibride dello stesso hub di Network Connectivity Center. Utilizza la topologia mesh predefinita di Network Connectivity Center per abilitare la comunicazione tra tutti gli spoke (VPC e ibridi). Questa topologia consente anche la comunicazione tra le VPC delle applicazioni soggette ai criteri di Cloud NGFW. Eventuali reti VPC dei servizi consumer connesse tramite VPN ad alta disponibilità non devono essere sposti dell'hub di Network Connectivity Center. Gli endpoint Private Service Connect possono essere implementati negli spoke VPC di Network Connectivity Center e non richiedono una connessione VPN ad alta disponibilità per la transitività tra VPC quando utilizzi Network Connectivity Center.

Connettività tra VPC con il peering di rete VPC

Quando i punti di accesso dei consumer di servizi pubblicati vengono implementati in una VPC di accesso ai servizi, consigliamo di connettere le VPC dell'applicazione utilizzando il peering di rete VPC alla VPC di transito e di connettere le VPC di accesso ai servizi alla VPC di transito tramite VPN ad alta disponibilità.

In questo design, la VPC di transito è l'hub e i punti di accesso dei consumer per gli endpoint dei servizi privati vengono di cui vengono eseguiti il deployment in una VPC di accesso ai servizi.

Il design è una combinazione di due tipi di connettività:

  • Peering di rete VPC: fornisce connettività tra la VPC di transito e le VPC dell'applicazione.
  • Connessioni inter-VPC VPN ad alta disponibilità: forniscono connettività transitiva tra i VPC di accesso ai servizi e il VPC di transito.

Quando combini queste architetture, tieni conto delle seguenti considerazioni:

  • Ridistribuzione delle subnet peer VPC nel routing dinamico (alla VPC di accesso ai servizi tramite VPN ad alta disponibilità e alle reti esterne tramite connessioni ibride)
  • Considerazioni sul routing multiregionale
  • Propagazione delle route dinamiche nel peering VPC (dalla VPC di accesso ai servizi tramite VPN ad alta disponibilità e dalle reti esterne tramite connessioni ibride)

Il seguente diagramma mostra un VPC di accesso ai servizi, connesso al VPC di transito con VPN ad alta disponibilità, e i VPC di applicazione, connessi al VPC di transito con il peering di rete VPC:

La VPC dei servizi centrali connessa alla VPC di transito con VPN ad alta disponibilità e le VPC delle applicazioni connesse alla VPC di transito con il peering di rete VPC

La struttura mostrata nel diagramma precedente contiene i seguenti componenti:

  • Posizione del cliente: un data center o un ufficio remoto in cui hai l'apparecchiatura di rete. Questo esempio presuppone che le sedi siano collegate tra loro utilizzando una rete esterna.
  • Metro: un'area metropolitana contenente uno o più domini di disponibilità edge di Cloud Interconnect. Cloud Interconnect si connette ad altre reti in queste aree metropolitane.
  • Progetto hub: un progetto che ospita almeno una rete VPC che funge da hub per altre reti VPC.
  • VPC di transito: una rete VPC nel progetto hub che riceve le connessioni da on-premise e da altri CSP, quindi funge da percorso di transito da altri VPC alle reti on-premise e dei CSP.
  • Progetti e VPC host per app: progetti e reti VPC che ospitano varie applicazioni.
  • VPC con accesso ai servizi: una rete VPC che ospita l'accesso centralizzato ai servizi necessari per le applicazioni nelle reti VPC dell'applicazione.
  • VPC di servizi gestiti: servizi forniti e gestiti da altre entità, ma resi accessibili alle applicazioni in esecuzione nelle reti VPC.

Per il design del peering di rete VPC, quando le VPC dell'applicazione devono comunicare tra loro, puoi collegarle a un hub di Network Connectivity Center come spoke VPC. Questo approccio fornisce connettività tra tutte le VPC nell'hub di Network Connectivity Center. È possibile creare sottogruppi di comunicazione utilizzando più hub di Network Connectivity Center. Eventuali limitazioni di comunicazione richieste tra gli endpoint all'interno di un determinato hub possono essere ottenute utilizzando i criteri firewall.

La sicurezza del carico di lavoro per le connessioni est-ovest tra i VPC delle applicazioni può utilizzare Cloud Next Generation Firewall.

Per indicazioni dettagliate e modelli di configurazione per il deployment di questi tipi di connettività, consulta Architettura di rete hub e spoke.

Progettazione dell'infrastruttura DNS

In un ambiente ibrido, Cloud DNS o un fornitore esterno (on-premise o CSP) possono gestire una ricerca DNS. I server DNS esterni sono autorevoli per le zone DNS esterne e Cloud DNS è autorevole per le zoneGoogle Cloud . Il forwarding DNS deve essere abilitato in modo bidirezionale traGoogle Cloud e le reti esterne e i firewall devono essere impostati per consentire il traffico di risoluzione DNS.

Se utilizzi un VPC condiviso per il tuo VPC di accesso ai servizi, in cui gli amministratori di diversi progetti di servizi di applicazioni possono creare i propri servizi, utilizza il collegamento tra progetti delle zone DNS. Il binding tra progetti consente la segmentazione e la delega dello spazio dei nomi DNS agli amministratori del progetto di servizio.

Nel caso di transito, quando le reti esterne comunicano con altre reti esterne tramite Google Cloud, le zone DNS esterne devono essere configurate per inoltrare le richieste direttamente l'una all'altra. La rete cross-cloud di Google fornirà la connettività per il completamento delle richieste e delle risposte DNS, ma Google Cloud DNS è coinvolto nel forwarding del traffico di risoluzione DNS tra le zone nelle reti esterne. Eventuali regole firewall applicate nella rete cross-cloud devono consentire il traffico di risoluzione DNS tra le reti esterne.

Il seguente diagramma mostra che un design DNS può essere utilizzato con qualsiasi configurazione di connettività VPC hub-and-spoke proposta in questa guida alla progettazione:

Progettazione DNS che può essere utilizzata con modelli di connettività hub-and-spoke

Il diagramma precedente mostra i seguenti passaggi del flusso di progettazione:

  1. DNS on-premise
    Configura i server DNS on-premise in modo che siano autorevoli per le zone DNS on-premise. Configura l'inoltro DNS (per i nomi DNS di Google Cloud) scegliendo come target l'indirizzo IP di inoltro in entrata di Cloud DNS, creato tramite la configurazione del criterio del server in entrata nella VPC hub. Questa configurazione consente alla rete on-premise di risolvere i nomi DNS di Google Cloud.
  2. Transit VPC - DNS Egress Proxy
    Pubblicizza l'intervallo 35.199.192.0/19 del proxy di uscita DNS di Google alla rete on-premise utilizzando i router cloud. Le richieste DNS in uscita da Google a on-premise provengono da questo intervallo di indirizzi IP.
  3. VPC di transito - Cloud DNS
    1. Configura un criterio del server in entrata per le richieste DNS in entrata dall'on-premise.
    2. Configura la zona di inoltro Cloud DNS (per i nomi DNS on-premise) che ha come target i server DNS on-premise.
  4. VPC per l'accesso ai servizi - Cloud DNS
    1. Configura la zona di peering DNS dei servizi (per i nomi DNS on-premise) impostando la VPC hub come rete peer. La risoluzione DNS per le risorse on-premise e di servizio avviene tramite la VPC hub.
    2. Configura le zone private DNS dei servizi nel progetto host dei servizi e collega il VPC condiviso dei servizi, il VPC condiviso dell'applicazione e il VPC hub alla zona. In questo modo, tutti gli host (on-premise e in tutti i progetti di servizi) possono risolvere i nomi DNS dei servizi.
  5. Progetto host dell'app - Cloud DNS
    1. Configura una zona di peering DNS per i nomi DNS on-premise impostando la VPC hub come rete peer. La risoluzione DNS per gli host on-premise avviene tramite la VPC dell'hub.
    2. Configura le zone private DNS dell'app nel progetto host dell'app e collega il VPC dell'applicazione, il VPC condiviso dei servizi e il VPC dell'hub alla zona. Questa configurazione consente a tutti gli host (on-premise e in tutti i progetti di servizio) di risolvere i nomi DNS dell'app.

Per ulteriori informazioni, consulta Architettura ibrida che utilizza una rete VPC hub connessa a reti VPC spoke.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: