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 dalle seguenti parti:

Questa parte esplora la struttura e la connettività della segmentazione di rete, che costituisce la base della progettazione. Questo documento spiega le fasi in cui devi effettuare le seguenti scelte:

  • La segmentazione di rete e la struttura del progetto complessive.
  • Dove posizioni il workload.
  • Il modo in cui i tuoi progetti sono connessi a reti esterne on-premise e di altri fornitori di servizi cloud, incluso il design per connettività, routing e crittografia.
  • Il modo in cui le reti VPC sono connesse internamente tra loro.
  • Come sono connesse le tue subnet VPC tra loro e ad altre reti, incluso come configurare la raggiungibilità del servizio e il DNS. Google Cloud

Segmentazione di rete e struttura del progetto

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

  • Un progetto host dell'infrastruttura consolidato, in cui utilizzi un singolo progetto host dell'infrastruttura per gestire tutte le risorse di rete per tutte le applicazioni
  • Progetti host segmentati, in cui utilizzi un progetto host dell'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 dei carichi di lavoro. Definisci l'ambito delle autorizzazioni per gli amministratori e gli sviluppatori dell'infrastruttura in base al principio del minimo privilegio e definisci l'ambito delle risorse dell'applicazione in diversi progetti di applicazione. Poiché gli amministratori dell'infrastruttura devono configurare la connettività per condividere le risorse, le risorse dell'infrastruttura possono essere gestite all'interno di un progetto dell'infrastruttura. Ad esempio, per configurare la connettività alle risorse dell'infrastruttura condivisa, 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, mentre il team di produzione potrebbe gestirli in un progetto separato. Gli sviluppatori utilizzerebbero quindi le risorse dell'infrastruttura nel progetto dell'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 informazioni dettagliate su come scegliere una gerarchia delle risorse, vedi Decidere una gerarchia delle risorse per la tua zona di destinazione Google Cloud . 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 i seguenti VPC:

  • Uno o più VPC dell'applicazione 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 dell'infrastruttura consolidato per gestire tutte le risorse di rete, come reti VPC e subnet, hub Network Connectivity Center, peering di rete VPC e bilanciatori del carico.

Nel progetto host dell'infrastruttura possono essere creati più VPC condivisi per le applicazioni con i relativi progetti di servizio delle applicazioni per corrispondere alla struttura dell'organizzazione. Utilizza più progetti di servizio applicazione per delegare l'amministrazione delle risorse. Tutto il networking in tutti i VPC delle applicazioni viene fatturato al progetto host dell'infrastruttura consolidata.

Per questa struttura di progetto, molti progetti di servizio applicazione possono condividere un numero inferiore di VPC applicazione.

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

Progetto host dell'infrastruttura consolidata e più progetti di servizio dell'applicazione

Progetti host segmentati

In questo pattern, ogni gruppo di applicazioni ha il proprio progetto host dell'applicazione e le proprie reti VPC. Al progetto host possono essere associati più progetti di servizio applicazione. La fatturazione dei servizi di rete è suddivisa tra il progetto host dell'infrastruttura e i progetti host delle applicazioni. I costi dell'infrastruttura vengono fatturati al progetto host dell'infrastruttura, mentre i costi di rete, come quelli per il trasferimento di dati per le applicazioni, vengono fatturati a ogni progetto host dell'applicazione.

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

Più progetti host e più progetti di servizio applicazione

Posizionamento del workload

Molte scelte di connettività dipendono dalle posizioni regionali dei tuoi carichi di lavoro. Per indicazioni sul posizionamento dei carichi di lavoro, consulta Best practice per la scelta delle regioni di Compute Engine. Devi decidere dove verranno eseguiti i 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 reti on-premise. Le reti esterne possono essere di proprietà e gestite da organizzazioni diverse. Queste reti si connettono fisicamente tra loro in una o più interfacce di rete-rete (NNI). La combinazione di NNI deve essere progettata, sottoposta a provisioning e configurata per prestazioni, resilienza, privacy e sicurezza.

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

La progettazione degli NNI e della connettività esterna viene utilizzata in un secondo momento per la connettività interna e il networking VPC.

Il seguente diagramma mostra un VPC di transito che funge da servizio di connettività condiviso per altri VPC, che sono 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 diverse regioni.

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) a cui vuoi connetterti alla tua rete Google Cloud , puoi connetterti a questi servizi tramite internet o tramite connessioni private. Ti consigliamo le connessioni private.

Quando scegli le opzioni, considera throughput, privacy, costi e fattibilità operativa.

Per massimizzare la velocità effettiva e migliorare la privacy, utilizza una connessione diretta ad alta velocità tra le reti cloud. Le connessioni dirette eliminano la necessità di apparecchiature di rete fisiche intermedie. Ti consigliamo di utilizzare Cross-Cloud Interconnect, che fornisce queste connessioni dirette, nonché la crittografia MACsec e una velocità 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 CSP in base alla vicinanza della località alle regioni di destinazione. Per la selezione della località, considera quanto segue:

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

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

Se non hai bisogno di una larghezza di banda elevata tra diversi CSP, puoi utilizzare 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. I tunnel VPN possono anche raggiungere uno SLA del 99,99%. Per i 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 al router Cloud tramite un criterio di peering:

Connessioni a reti on-premise

Routing tra domini con reti esterne

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

Quando il traffico viene trasferito tra 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 qualitativo del servizio di ciascuna rete potrebbero variare in modo significativo. Potresti decidere di utilizzare alcune reti rispetto ad altre, in base a queste differenze.

Configura i criteri di routing interdominio per soddisfare i requisiti di transito interregionale, simmetria del traffico, velocità effettiva e resilienza.

La configurazione dei criteri di routing tra domini dipende dalle funzioni disponibili all'edge di ciascun dominio. La configurazione dipende anche dalla struttura dei domini vicini dal punto di vista del sistema autonomo e dell'indirizzamento IP (subnetting) nelle diverse regioni. Per migliorare la scalabilità senza superare i limiti dei prefissi sui dispositivi edge, ti consigliamo di fare in modo che il tuo piano di indirizzamento IP generi un numero inferiore di prefissi aggregati per ogni combinazione di regione e dominio.

Quando progetti il routing interregionale, considera quanto segue:

  • Google Cloud Le reti VPC e Cloud Router supportano il routing globale tra regioni. Altri CSP potrebbero avere ambiti VPC e Border Gateway Protocol (BGP) regionali. Per maggiori dettagli, consulta la documentazione dell'altro CSP.
  • Router Cloud 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 del VPC. Potresti dover eseguire l'override di queste preferenze per il comportamento di routing che preferisci.
  • Diversi CSP supportano diverse funzioni BGP e Bidirectional Forwarding Detection (BFD) e router Cloudr di Google ha anche funzionalità specifiche per le policy di route come descritto in Stabilire sessioni BGP.
  • Diversi CSP potrebbero utilizzare attributi di risoluzione dei conflitti BGP diversi per stabilire la preferenza per le route. Per ulteriori dettagli, consulta la documentazione del tuo CSP.

Routing interdominio a regione singola

Ti consigliamo di iniziare con il routing tra domini in una singola regione, per poi creare connessioni multiregionali con il routing tra domini.

I progetti che utilizzano Cloud Interconnect devono avere un minimo di due località di connessione che si trovano nella stessa regione, ma in domini di disponibilità edge diversi.

Decidi se configurare queste connessioni duplicate in una progettazione attiva/attiva o attiva/passiva:

  • Active/active utilizza il routing ECMP (Equal Cost Multi-Path) 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 impone che un link sia in standby pronto a ricevere il traffico solo se il link attivo viene interrotto.

Consigliamo una progettazione attiva/attiva per i link intraregionali. Tuttavia, alcune topologie di rete on-premise combinate con l'utilizzo di funzioni di sicurezza stateful possono richiedere una progettazione attiva/passiva.

Router Cloud viene istanziato in più zone, il che offre una resilienza maggiore rispetto a un singolo elemento. Il seguente diagramma mostra come tutte le connessioni resilienti convergono in un unico router Cloud all'interno di una regione. Questo progetto 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 router Cloud gestito in una singola regione:

Le connessioni resilienti possono utilizzare un singolo router Cloud

Routing interdominio multiregionale

Per fornire connettività di backup, le reti possono eseguire il peering in più aree geografiche. Se colleghi le reti in più regioni, lo SLA di disponibilità può aumentare fino al 99,99%.

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

Connessioni Cloud Interconnect in più regioni

Oltre alla resilienza, la progettazione del routing multiregionale deve garantire la simmetria del flusso. Il progetto deve anche indicare la rete preferita per le comunicazioni tra regioni, cosa che puoi fare con il routing hot-potato e cold-potato. Abbina il routing cold-potato in un dominio al routing hot-potato nel dominio peer. Per il dominio cold-potato, ti consigliamo di utilizzare il dominio di reteGoogle Cloud , 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 transito interregionale preferita. In questo caso, il traffico dai prefissi X e Y rimane sulla 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 attraversa l'altra rete fino alla destinazione (routing hot potato).

Utilizzo del routing hot-potato e cold-potato per specificare la rete di transito interregionale preferita

Crittografia del traffico tra domini

Se non diversamente indicato, il traffico non viene criptato sulle connessioni Cloud Interconnect tra diversi CSP o tra Google Cloud e i data center on-premise. 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 edge 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 la larghezza di banda completa delle connessioni Cloud Interconnect sottostanti. I tunnel VPN ad alta disponibilità sono criptati con IPsec e vengono implementati su connessioni Cloud Interconnect che potrebbero essere criptate anche con MACsec. In questa configurazione, le connessioni Cloud Interconnect sono configurate per consentire solo il traffico VPN ad alta disponibilità. Per i dettagli, consulta la panoramica della VPN ad alta disponibilità su Cloud Interconnect.

Connettività internet per i carichi di lavoro

Per la connettività a internet sia in entrata che in uscita, si presume che il traffico di risposta segua in modo stateful la direzione inversa della richiesta originale.

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

Connettività internet in entrata

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

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

Connettività internet in uscita

Esempi di connettività a internet in uscita (in cui la richiesta iniziale ha origine dal carico di lavoro a una destinazione internet) includono carichi di lavoro che accedono ad API di terze parti, download di pacchetti software e aggiornamenti e invio di notifiche push a endpoint webhook su internet.

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

Il percorso principale per fornire connettività internet in uscita è la destinazione del gateway internet predefinito nella tabella di routing VPC, che spesso è la route predefinita nelle reti VPC di Google. Sia gli IP esterni che Cloud NAT (il servizio NAT gestito diGoogle Cloud) richiedono una route che punti al gateway internet predefinito del VPC. Pertanto, i progetti di routing VPC che sostituiscono la route predefinita devono fornire connettività in uscita con altri mezzi. Per i dettagli, vedi la panoramica del router Cloud.

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

Utilizzo dei tuoi IP

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

Puoi anche controllare la reputazione dello spazio IP tramite il suo utilizzo esclusivo. BYOIP contribuisce alla portabilità della connettività e può ridurre i costi degli indirizzi IP.

Connettività interna e networking VPC

Con il servizio di connettività esterna e ibrida configurato, le risorse nel 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 un VPC di transito che termina le connessioni esterne e ospita un router Cloud in ogni regione. Ogni router Cloud riceve le route dai peer esterni tramite le interfacce di rete interconnesse in ogni regione. I VPC dell'applicazione sono connessi al VPC di transito in modo da poter condividere la connettività esterna. Inoltre, il VPC di transito funge da hub per i VPC spoke. I 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 rete cloud 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
  • 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 il firewalling o altre funzioni di rete, devi utilizzare il peering di rete VPC. I firewall perimetrali possono rimanere su reti esterne. Se l'inserimento di NVA è un requisito, utilizza il pattern Connettività tra VPC con peering di rete VPC per interconnettere i tuoi VPC.

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

Le sezioni seguenti descrivono 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 i VPC delle applicazioni, i VPC di transito e i VPC di accesso ai servizi utilizzando gli spoke VPC di Network Connectivity Center.

I punti di accesso del consumer di servizi vengono implementati nei VPC services-access quando devono essere raggiungibili da altre reti (altri VPC o reti esterne). Puoi eseguire il deployment dei punti di accesso consumer di servizi nei VPC delle applicazioni se questi punti di accesso devono essere raggiunti solo dall'interno del VPC dell'applicazione

Se devi fornire l'accesso ai servizi dietro l'accesso privato ai servizi, crea un VPC services-access connesso a un VPC di transito utilizzando la VPN ad alta disponibilità. Poi, 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 i VPC di transito, i VPC delle applicazioni e i VPC di accesso ai servizi che ospitano gli endpoint Private Service Connect.
  • Connessioni VPN ad alta disponibilità tra VPC: forniscono connettività transitiva per le subnet di accesso privato ai servizi ospitate sui VPC di accesso ai servizi. Questi VPC di accesso ai servizi non devono essere aggiunti come spoke dell'hub Network Connectivity Center.

Quando combini questi tipi di connettività, pianifica quanto segue:

  • Ridistribuzione delle subnet peer di peering di rete VPC e 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 delle 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 privato ai servizi connesse al VPC di transito con VPN ad alta disponibilità. Il diagramma mostra anche i VPC delle applicazioni, i VPC di transito e i VPC di accesso ai servizi che ospitano gli endpoint consumer di Private Service Connect connessi tramite 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 questi 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 tramite una rete esterna.
  • Rete 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 CSP.
  • VPC delle 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 alle applicazioni in altre reti.
  • VPC dei 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 i VPC dell'applicazione ai collegamenti VLAN di Cloud Interconnect e alle istanze VPN ad alta disponibilità nei VPC di transito. Trasforma tutti i VPC in spoke dell'hub Network Connectivity Center e trasforma i collegamenti VLAN e le VPN ad alta disponibilità in spoke ibridi dello stesso hub 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 i VPC delle applicazioni soggetti ai criteri Cloud NGFW. Tutti i VPC di servizi consumer connessi tramite VPN ad alta disponibilità non devono essere spoke dell'hub 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 consumer di servizi pubblicati vengono implementati in un VPC di accesso ai servizi, consigliamo di connettere i VPC delle applicazioni utilizzando il peering di rete VPC al VPC di transito e di connettere i VPC di accesso ai servizi al VPC di transito tramite la VPN ad alta disponibilità.

In questa progettazione, il VPC di transito è l'hub e i punti di accesso consumer per gli endpoint di servizio privati vengono implementati in un VPC di accesso ai servizi.

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

  • Peering di rete VPC: fornisce connettività tra il VPC di transito e i VPC delle applicazioni.
  • 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, pianifica quanto segue:

  • Ridistribuzione delle subnet peer VPC nel routing dinamico (al 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, che è connesso al VPC di transito con VPN ad alta disponibilità e ai VPC delle applicazioni, che sono connessi al VPC di transito con il peering di rete VPC:

VPC dei servizi centrali connesso al VPC di transito con VPN ad alta disponibilità e i VPC delle applicazioni connessi al VPC di transito con peering di rete VPC

La struttura mostrata nel diagramma precedente contiene questi componenti:

  • Posizione del cliente: un data center o un ufficio remoto in cui disponi di apparecchiature di rete. Questo esempio presuppone che le località siano connesse tra loro tramite una rete esterna.
  • Area metropolitana: un'area metropolitana contenente uno o più domini di disponibilità perimetrale 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 altre VPC alle reti on-premise e CSP.
  • Progetti host e VPC delle app: progetti e reti VPC che ospitano varie applicazioni.
  • VPC di accesso ai servizi: una rete VPC che ospita l'accesso centralizzato ai servizi necessari alle applicazioni nelle reti VPC delle applicazioni.
  • VPC dei servizi gestiti: servizi forniti e gestiti da altre entità, ma resi accessibili alle applicazioni in esecuzione nelle reti VPC.

Per la progettazione del peering di rete VPC, quando i VPC delle applicazioni devono comunicare tra loro, puoi connetterli a un hub Network Connectivity Center come spoke VPC. Questo approccio fornisce connettività tra tutti i VPC nell'hub Network Connectivity Center. I sottogruppi di comunicazione possono essere creati utilizzando più hub Network Connectivity Center. Eventuali restrizioni di comunicazione richieste tra gli endpoint all'interno di un hub specifico possono essere ottenute utilizzando le norme firewall.

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

Per indicazioni dettagliate e progetti 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, una ricerca DNS può essere gestita da Cloud DNS o da un provider esterno (on-premise o CSP). I server DNS esterni sono autorevoli per le zone DNS esterne e Cloud DNS è autorevole per le zoneGoogle Cloud . L'inoltro DNS deve essere abilitato in modo bidirezionale tra Google Cloud e le reti esterne e i firewall devono essere configurati 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 servizio delle applicazioni possono istanziare i propri servizi, utilizza il binding 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 del transito, in cui 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 fornirebbe la connettività per il completamento delle richieste e delle risposte DNS, ma Google Cloud DNS è coinvolto nell'inoltro di qualsiasi traffico di risoluzione DNS tra le zone nelle reti esterne. Tutte le regole firewall applicate nella rete cross-cloud devono consentire il traffico di risoluzione DNS tra le reti esterne.

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

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

Il diagramma precedente mostra i seguenti passaggi nel 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 dei criteri del server in entrata nel VPC hub. Questa configurazione consente alla rete on-premise di risolvere i nomi DNS di Google Cloud.
  2. VPC di transito - Proxy di uscita DNS
    Pubblica l'intervallo 35.199.192.0/19 del proxy di uscita DNS di Google nella 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 da on-premise.
    2. Configura una zona di inoltro Cloud DNS (per i nomi DNS on-premise) che ha come target i server DNS on-premise.
  4. VPC di accesso ai servizi - Cloud DNS
    1. Configura l'impostazione della zona di peering DNS dei servizi (per i nomi DNS on-premise) impostando il VPC hub come rete peer. La risoluzione DNS per le risorse on-premise e di servizio passa attraverso il 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 delle applicazioni e il VPC hub alla zona. In questo modo, tutti gli host (on-premise e in tutti i progetti di servizio) possono risolvere i nomi DNS dei servizi.
  5. Progetto host dell'app - Cloud DNS
    1. Configura una zona di peering DNS dell'app per l'impostazione dei nomi DNS on-premise impostando il VPC hub come rete peer. La risoluzione DNS per gli host on-premise passa attraverso il VPC hub.
    2. Configura le zone private DNS di App in App Host Project e collega il VPC dell'applicazione, il VPC condiviso dei servizi e il VPC 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 alle reti VPC spoke.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: