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 della rete, che costituiscono la base del design. Questo documento spiega le fasi in cui effettui le seguenti scelte:

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

Segmentazione della rete e struttura del progetto

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

  • Un progetto host dell'infrastruttura consolidato, in cui utilizzi un unico progetto host dell'infrastruttura per gestire tutte le risorse di networking 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 tuoi workload. Definisci l'ambito delle autorizzazioni per gli amministratori e gli sviluppatori dell'infrastruttura in base al principio del privilegio minimo e l'ambito delle risorse delle applicazioni in progetti di applicazioni diversi. 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 di 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 workload in un progetto e il team di produzione potrebbe gestire i propri workload in un progetto separato. Gli sviluppatori utilizzeranno quindi le risorse dell'infrastruttura nel progetto di infrastruttura per creare e gestire risorse, servizi, bilanciamento del carico e policy di routing DNS per i propri workload.

Inoltre, devi decidere quante reti VPC implementare inizialmente e come organizzarle nella gerarchia delle risorse. Per informazioni dettagliate su come scegliere una gerarchia delle risorse, consulta Scegli una gerarchia delle risorse per la tua zona di destinazione Google Cloud . Per informazioni dettagliate su come scegliere il numero di reti VPC, consulta Decidi se creare più reti VPC.

Per la Cross-Cloud Network, 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 networking, come reti VPC e subnet, hub Network Connectivity Center, peering di rete VPC e bilanciatori del carico.

Nel progetto host dell'infrastruttura è possibile creare più VPC condivisi per le applicazioni con i relativi progetti di servizio per le applicazioni, in modo da riflettere la struttura dell'organizzazione. Utilizza più progetti di servizio dell'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 progetti, molti progetti di servizio dell'applicazione possono condividere un numero inferiore di VPC dell'applicazione.

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

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

Progetti host segmentati

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

Il seguente diagramma fornisce una rappresentazione visiva dei progetti host e dei progetti di servizio dell'applicazione multipli appena descritti. Il diagramma non mostra la connettività tra tutti i progetti.

Più progetti host e più progetti di servizio dell'applicazione

Posizionamento dei workload

Molte opzioni di connettività dipendono dalle località regionali dei tuoi workload. Per indicazioni sul posizionamento dei workload, consulta Best practice per la scelta delle regioni di 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 suggerimenti per i seguenti percorsi di connettività:

  • Connessioni private ad altri cloud provider
  • Connessioni private ai data center on-premise
  • Connettività a internet per i workload, in particolare 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 in una o più interfacce network-to-network (NNI). La combinazione di NNI deve essere progettata, sottoposta a provisioning e configurata per garantire prestazioni, resilienza, privacy e sicurezza.

Per la modularità, la riusabilità e la possibilità di inserire NVA di sicurezza, posiziona le connessioni esterne e il routing in un VPC di transito, che funge poi 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 utilizzate da molte altre reti VPC.

La progettazione delle 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, connessi tramite il peering di rete VPC, Network Connectivity Center o VPN ad alta disponibilità affidabilità. 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 provider di servizi cloud (CSP) che vuoi connettere alla tua rete Google Cloud , puoi connetterti tramite internet o tramite connessioni private. Consigliamo le connessioni private.

Quando scegli le opzioni, considera la velocità effettiva, la privacy, i costi e la 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 apparecchiature di rete fisiche intermedie. Ti consigliamo di utilizzare Cross-Cloud Interconnect, che fornisce queste connessioni dirette, oltre alla crittografia MACsec e a 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à, tieni presente 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 cloud provider).
    • Per Dedicated Interconnect o Partner Interconnect, scegli una località 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 workload di produzione. Per maggiori dettagli, consulta Alta affidabilità 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 CSP diversi, 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. I tunnel VPN possono anche raggiungere uno SLA del 99,99%. Per maggiori dettagli, consulta Topologie VPN ad alta affidabilità.

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 il modo in cui i router on-premise possono connettersi al router Cloud tramite una policy di peering:

Connessioni a reti on-premise

Routing tra domini con reti esterne

Per aumentare la resilienza e il throughput tra le reti, utilizza più percorsi per connetterle.

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 tra più regioni, il costo e il livello qualitativo del servizio di ciascuna rete potrebbero variare in modo significativo. In base a queste differenze, potresti decidere di utilizzare alcune reti anziché altre.

Configura la policy di routing tra domini per soddisfare i requisiti di transito tra regioni, simmetria del traffico, throughput e resilienza.

La configurazione delle policy di routing tra domini dipende dalle funzioni disponibili all'edge di ogni dominio. La configurazione dipende anche dal modo in cui i domini adiacenti sono strutturati dal punto di vista del sistema autonomo e dell'indirizzamento IP (subnetting) tra regioni diverse. Per migliorare la scalabilità senza superare i limiti dei prefissi sui dispositivi edge, ti consigliamo di creare un piano di indirizzamento IP che generi un numero inferiore di prefissi aggregati per ogni combinazione di regione e dominio.

Quando progetti il routing tra regioni, tieni presente quanto segue:

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

Routing tra domini in una singola regione

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

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

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

  • La modalità attiva/attiva utilizza il routing ECMP (Equal-Cost Multi-Path) per aggregare la larghezza di banda di entrambi i percorsi e utilizzarli contemporaneamente per il traffico tra domini. Cloud Interconnect supporta anche l'utilizzo di link aggregati LACP per ottenere fino a 200 Gbps di larghezza di banda aggregata per percorso.
  • La modalità attiva/passiva forza un link a essere in standby, pronto a subentrare solo se il link attivo viene interrotto.

Ti consigliamo un design attivo/attivo per i link intraregionali. Tuttavia, alcune topologie di networking on-premise combinate con l'utilizzo di funzioni di sicurezza stateful possono richiedere un design attivo/passivo.

Il router Cloud viene istanziato in più zone, il che offre una maggiore resilienza 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 design può supportare uno SLA con disponibilità del 99,9% all'interno di una singola area metropolitana se segui 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 tra domini multiregionale

Per fornire connettività di backup, le reti possono eseguire il peering in più aree geografiche. Collegando le reti in più regioni, lo SLA di disponibilità può aumentare 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 router Cloud 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 inoltre indicare la rete preferita per le comunicazioni tra regioni, che puoi eseguire con il routing hot-potato e cold-potato. Abbinare il routing cold potato in un dominio con il routing hot potato nel dominio peer. Per il dominio cold potato, ti consigliamo di utilizzare il dominio di reteGoogle Cloud , che fornisce 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 proveniente dai prefissi X e Y rimane sulla rete di origine finché 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 tra regioni preferita

Crittografia del traffico tra domini

Salvo diversa indicazione, il traffico non è 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 perimetrali di Google. Per maggiori dettagli, consulta la panoramica di MACsec per Cloud Interconnect.
  • VPN ad alta affidabilità su Cloud Interconnect: utilizza più tunnel VPN ad alta disponibilità affidabilità per fornire la larghezza di banda completa delle connessioni Cloud Interconnect sottostanti. I tunnel VPN ad alta affidabilità sono crittografati con IPsec e vengono distribuiti su connessioni Cloud Interconnect che possono anche essere crittografate 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 affidabilità su Cloud Interconnect.

Connettività internet per i workload

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 rispetto alla direzione della richiesta originale.

In genere, le funzionalità che forniscono connettività a internet in entrata sono separate dalle funzionalità internet 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 sono la connettività a internet per i server di applicazioni web e i server di gioco ospitati suGoogle Cloud.

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

Connettività internet in uscita

Esempi di connettività a internet in uscita (dove la richiesta iniziale proviene dal workload a una destinazione internet) includono i workload che accedono ad 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 integrate di Google Cloud , come descritto in Alternative all'utilizzo di un indirizzo IP esterno. In alternativa, puoi utilizzare le NVA NGFW centrali, come descritto in Sicurezza di rete.

Il percorso principale per fornire connettività a internet in uscita è la destinazione del gateway internet predefinito nella tabella di routing VPC, che spesso è la route predefinita nei VPC di Google. Sia gli IP esterni sia 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 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 Secure Web Proxy per fornire un filtro più approfondito sugli 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 gli indirizzi IPv4 di proprietà di Google per la connettività a internet o Bring Your Own IP (BYOIP) per utilizzare uno spazio IPv4 di proprietà della tua organizzazione. La maggior parte dei prodotti Google Cloudche richiedono un indirizzo IP instradabile su internet supporta l'utilizzo di intervalli BYOIP.

Puoi anche controllare la reputazione dello spazio IP tramite l'utilizzo esclusivo. BYOIP aiuta con la 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 abilitato 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 suoi peer esterni tramite le NNI in ogni regione. I VPC delle applicazioni 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 networking cloud integrati, i VPC devono essere connessi utilizzando NCC come descritto in Connettività tra VPC con NCC. NCC fornisce quanto segue:

  • Accesso transitivo agli endpoint L4 e L7 di Private Service Connect e ai 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 il firewall o altre funzioni di rete, devi utilizzare il peering di rete VPC. I firewall perimetrali possono rimanere sulle reti esterne. Se l'inserimento di NVA è un requisito, utilizza il pattern Connettività tra VPC con peering di rete VPC per interconnettere le reti VPC.

Configura il forwarding e il peering DNS anche nel 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 connessione IP di base e i deployment dei punti di accesso API.

Connettività tra VPC con NCC

Ti consigliamo di connettere i VPC delle applicazioni, i VPC di transito e i VPC di accesso ai servizi utilizzando gli spoke VPC NCC.

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

Se devi fornire l'accesso ai servizi dietro l'accesso privato ai servizi, crea un VPC di accesso ai servizi connesso a un VPC di transito tramite VPN ad alta disponibilità affidabilità. 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à:

  • NCC: fornisce la connettività tra VPC di transito, VPC di applicazioni e VPC di accesso ai servizi che ospitano endpoint Private Service Connect.
  • Connessioni inter-VPC della VPN ad alta affidabilità: forniscono connettività transitiva per le subnet di accesso privato ai servizi ospitate su VPC di accesso ai servizi. Questi VPC di accesso ai servizi non devono essere aggiunti come spoke dell'hub NCC.

Quando combini questi tipi di connettività, tieni conto delle seguenti considerazioni:

  • Ridistribuzione delle subnet di peering di rete VPC e dei peer NCC nel routing dinamico (alla VPC di accesso ai servizi tramite VPN ad alta disponibilità affidabilità e alle reti esterne tramite interconnessioni ibride)
  • Considerazioni sul routing multiregionale
  • Propagazione delle route dinamiche nel peering di rete VPC e nel peering NCC (dal VPC di accesso ai servizi tramite VPN ad alta disponibilità affidabilità 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à affidabilità. Il diagramma mostra anche i VPC dell'applicazione, i VPC di transito e i VPC di accesso ai servizi che ospitano gli endpoint consumer di Private Service Connect connessi tramite NCC:

Struttura generale di Cross-Cloud Network che utilizza spoke VPC NCC

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 località siano connesse tra loro tramite una rete esterna.
  • Rete VPC di transito: una rete VPC nel progetto hub che riceve le connessioni on-premise e di 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 punti di accesso Private Service Connect ai servizi ospitati in altre reti.

Utilizza NCC per connettere i VPC dell'applicazione ai collegamenti VLAN di Cloud Interconnect e alle istanze VPN ad alta disponibilità affidabilità nei VPC di transito. Trasforma tutti i VPC in spoke dell'hub NCC e trasforma i collegamenti VLAN e le VPN ad alta affidabilità in spoke ibridi dello stesso hub NCC. Utilizza la topologia mesh NCC predefinita per abilitare la comunicazione tra tutti gli spoke (VPC e ibridi). Questa topologia consente anche la comunicazione tra i VPC dell'applicazione soggetti alle policy di Cloud NGFW. I VPC dei servizi consumer connessi tramite VPN ad alta disponibilità non devono essere spoke dell'hub NCC. Gli endpoint Private Service Connect possono essere distribuiti negli spoke VPC NCC e non richiedono una connessione VPN ad alta disponibilità affidabilità per la transitività tra VPC quando si utilizza NCC.

Connettività tra VPC con il peering di rete VPC

Quando i punti di accesso dei consumer di servizi pubblicati vengono distribuiti in un VPC di accesso ai servizi, consigliamo di connettere i VPC delle applicazioni al VPC di transito tramite il peering di rete VPC e di connettere i VPC di accesso ai servizi al VPC di transito tramite VPN ad alta affidabilità.

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

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

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

Quando combini queste architetture, tieni presente le seguenti considerazioni:

  • Ridistribuzione delle subnet peer VPC nel routing dinamico (al VPC di accesso ai servizi tramite VPN ad alta disponibilità affidabilità e alle reti esterne tramite connessioni ibride)
  • Considerazioni sul routing multiregionale
  • Propagazione delle route dinamiche nel peering VPC (dal VPC di accesso ai servizi tramite VPN ad alta affidabilità 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 delle applicazioni, 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 VPC delle applicazioni connessi al VPC di transito con il peering di rete VPC

La struttura mostrata nel diagramma precedente contiene i seguenti componenti:

  • Sede del cliente: un data center o un ufficio remoto in cui hai 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 altri VPC alle reti on-premise e CSP.
  • Progetti App Hosting e VPC: progetti e reti VPC che ospitano varie applicazioni.
  • VPC di accesso ai servizi: una rete VPC che ospita l'accesso centralizzato ai servizi richiesti dalle 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 il design del peering di rete VPC, quando i VPC delle applicazioni devono comunicare tra loro, puoi connetterli a un hub di Network Connectivity Center come spoke VPC. Questo approccio fornisce connettività tra tutti i VPC nell'hub Network Connectivity Center. È possibile creare sottogruppi di comunicazione utilizzando più hub Network Connectivity Center. Eventuali limitazioni di comunicazione richieste tra gli endpoint all'interno di un determinato hub possono essere ottenute utilizzando le policy del firewall.

La sicurezza dei workload 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 and spoke.

Progettazione dell'infrastruttura DNS

In un ambiente ibrido, Cloud DNS o un provider esterno (on-premise o CSP) possono gestire una ricerca DNS. I server DNS esterni sono autoritativi per le zone DNS esterne, mentre Cloud DNS è autoritativo 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 VPC di accesso ai servizi, in cui gli amministratori di diversi progetti di servizi applicativi possono creare istanze dei propri servizi, utilizza l'associazione tra progetti delle zone DNS. L'associazione tra progetti consente la segmentazione e la delega dello spazio dei nomi DNS agli amministratori dei progetti 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 Google Cross-Cloud Network fornirebbe la connettività per il completamento delle richieste e delle risposte DNS, ma Google Cloud DNS è coinvolto nell'inoltro del traffico di risoluzione DNS tra le zone nelle reti esterne. Le regole firewall applicate nella Cross-Cloud Network devono consentire il traffico di risoluzione DNS tra le reti esterne.

Il seguente diagramma mostra un design DNS che 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 i pattern di connettività hub and spoke

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

  1. DNS on-premise
    Configura i tuoi server DNS on-premise in modo che siano autorevoli per le zone DNS on-premise. Configura il forwarding DNS (per i nomi Google Cloud DNS) scegliendo come target l'indirizzo IP di forwarding in entrata di Cloud DNS, creato tramite la configurazione della policy dei server in entrata nel VPC hub. Questa configurazione consente alla rete on-premise di risolvere i nomi Google Cloud DNS.
  2. VPC di transito - Proxy DNS in uscita
    Annuncia l'intervallo del proxy DNS in uscita di Google 35.199.192.0/19 alla rete on-premise utilizzando i router Cloud. Le richieste DNS in uscita da Google verso l'ambiente on-premise provengono da questo intervallo di indirizzi IP.
  3. VPC di transito - Cloud DNS
    1. Configura una policy dei server in entrata per le richieste DNS in entrata da on-premise.
    2. Configura la zona di forwarding di Cloud DNS (per i nomi DNS on-premise) scegliendo come target i server DNS on-premise.
  4. VPC di accesso ai servizi - Cloud DNS
    1. Configura la 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 avviene tramite il VPC hub.
    2. Configura le zone private DNS dei servizi nel progetto host dei servizi e collega alla zona il VPC condiviso dei servizi, il VPC condiviso dell'applicazione e il VPC hub. In questo modo, tutti gli host (on-premise e in tutti i progetti di servizio) possono risolvere i nomi DNS dei servizi.
  5. App Hosting project - Cloud DNS
    1. Configura una zona di peering DNS dell'app per i 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 dell'app nel progetto App Hosting 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 maggiori informazioni, consulta Architettura ibrida con una rete VPC hub connessa a reti VPC spoke.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: