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

Last reviewed 2024-04-05 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 subnet VPC di Google Cloud sono collegate tra loro e ad altre reti, inclusa la configurazione della raggiungibilità del servizio 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 informazioni dettagliate su come scegliere una gerarchia delle risorse, vedi Decidere una gerarchia delle risorse per la 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 le seguenti reti VPC:

  • Uno o più VPC di applicazioni per ospitare le risorse per le diverse applicazioni.
  • Un VPC di transito, in cui viene gestita tutta la connettività esterna.
  • Un VPC per i servizi facoltativo, che può essere utilizzato 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 subnet, peering 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 corrispondenti 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 e i propri VPC. È possibile collegare più progetti di servizi per 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 host dell'infrastruttura, mentre gli addebiti di rete 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 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 guidance su come posizionare i carichi di lavoro, consulta 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 la VPC di transito che funge da servizio di connettività condiviso per altre VPC, connesse tramite peering di rete VPC, Network Connectivity Center o VPN ad alta disponibilità:

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 rete Google Cloud, 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 località disponibili sia per Google Cloud sia 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 al router Cloud 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 qualitativo del servizio di ciascuna 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:

  • Sia le reti VPC di Google Cloud sia il router Cloud supportano 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.
  • 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 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 dei criteri 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 in 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'uso di funzioni di sicurezza stateful possono richiedere un design attivo/passivo.

Router Cloud 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 singolo 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 router Cloud gestito in un'unica regione:

Le connessioni resilienti possono utilizzare un singolo router Cloud

Routing interdominio multiregionale

Per fornire connettività di backup, le reti possono essere in peering in più aree geografiche. Collegando le reti in più regioni, lo 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 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 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, ti consigliamo di utilizzare il dominio di rete Google 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 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

Se non diversamente indicato, il traffico non è criptato sulle connessioni Cloud Interconnect tra diversi fornitori di servizi cloud o tra Google Cloud e 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 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 tramite 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 contemporaneamente entrambe le direzioni.

Connettività a internet in entrata

La connettività in entrata a internet 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 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 integrate di Google Cloud, come descritto in Creazione della 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 indirizzi IP esterni sia Cloud NAT (il servizio NAT gestito di Google Cloud) richiedono una route che indichi il gateway internet predefinito della VPC. Pertanto, i design di routing VPC che sostituiscono la route predefinita 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 il proxy web sicuro 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 gli indirizzi IPv4 di proprietà di Google per la connettività internet oppure puoi utilizzare gli indirizzi Bring Your Own IP (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 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 altri 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

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

Per prestazioni migliori e servizi di rete cloud integrati, ti consigliamo di interconnettere i VPC con Cross-Cloud Network o VPC Network Peering anziché con la VPN ad alta disponibilità.

Gli endpoint di Private Service Connect e i frontend di accesso ai servizi privati non sono raggiungibili tramite il peering di rete VPC o la rete cross-cloud. Per superare queste limitazioni, consigliamo di utilizzare la VPN ad alta disponibilità per la connettività inter-VPC. Poiché l'utilizzo della VPN ad alta disponibilità per la connettività inter-VPC può comportare un throughput inferiore e un aumento del sovraccarico operativo, la progettazione dei servizi centralizzati riduce l'ambito del deployment della VPN ad alta disponibilità.

In alternativa, puoi implementare la connettività transitiva inter-VPC agli endpoint di servizio pubblicati posizionando un bilanciatore del carico di rete proxy interno davanti agli endpoint di servizio. Questo approccio presenta alcuni limiti da tenere in considerazione, discussi nella sezione Connettività con gli spoke di Network Connectivity Center tramite il bilanciamento del carico.

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

Connettività tra VPC per l'accesso ai servizi condivisi

Quando gli endpoint di servizio pubblicati vengono di cui vengono eseguiti il deployment in una VPC di servizi, consigliamo di connettere le VPC dell'applicazione tramite il peering di rete VPC all'hub (VPC di transito) e di connettere la VPC di servizi all'hub tramite la 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 servizi.

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

  • Peering di rete VPC: fornisce connettività tra la VPC hub e le VPC dell'applicazione.
  • Connessioni inter-VPC VPN ad alta disponibilità: forniscono connettività transitiva per il VPC dei servizi all'hub.

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

Quando combini queste architetture, tieni conto delle seguenti considerazioni:

  • Ridistribuzione delle subnet peer VPC nel routing dinamico (a VPN ad alta disponibilità e a ibrida)
  • Considerazioni sul routing multiregionale
  • Propagazione delle route dinamiche nel peering VPC (da VPN ad alta disponibilità e da ibrida)

Il seguente diagramma mostra un VPC per i servizi connesso al VPC di transito con VPN ad alta disponibilità e i VPC per le applicazioni 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à di 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 dei 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 hub-and-spoke, quando le VPC dell'applicazione devono comunicare tra loro, puoi collegarle come spoke a un hub di Network Connectivity Center. 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 di firewall.

Connettività con le VPC spoke di Network Connectivity Center che utilizzano il bilanciamento del carico

Questo modello include tutte le VPC come spoke in un hub di Network Connectivity Center e può supportare fino a 250 VPC interconnesse. Un hub di Network Connectivity Center è un costrutto del piano di gestione che crea una connettività del piano dati mesh completa tra tutte le reti VPC registrate come spoke nell'hub di Network Connectivity Center. Il pattern fornisce connettività any-to-any e consente il deployment di punti di accesso ai servizi gestiti in qualsiasi VPC.

Per superare le limitazioni di transitività, si accede ai punti di accesso ai servizi gestiti e alle connessioni ibride tramite bilanciatori del carico di rete proxy interni. La sicurezza del carico di lavoro per le connessioni est-ovest può utilizzare Cloud Next Generation Firewall. Con questo pattern puoi anche utilizzare Inter-VPC NAT.

Questo pattern presenta alcune limitazioni, pertanto prima di adottarlo è necessario prendere in considerazione quanto segue:

  • Non puoi utilizzare le NVA per i firewall perimetrali con questo pattern. I firewall perimetrali devono rimanere sulle reti esterne.
  • È supportato solo il traffico TCP verso e da reti esterne. Questa limitazione si verifica perché le connessioni alle reti esterne passano attraverso un bilanciatore del carico di rete proxy interno.
  • I servizi pubblicati avranno un frontend aggiuntivo nel bilanciatore del carico proxy. Questo frontend aggiuntivo moltiplica i record nel DNS e richiede ricerche DNS suddivise.
  • I servizi di livello 4 richiedono un nuovo bilanciatore del carico di rete proxy interno per ogni nuovo servizio. Potresti aver bisogno di bilanciatori di carico diversi a seconda dei protocolli richiesti per la connessione.
  • Le quote di bilanciamento del carico sono limitate per ogni rete VPC. Si tratta di un aspetto importante perché i servizi di livello 4 richiedono un nuovo bilanciatore del carico di rete proxy interno per ogni servizio di destinazione.
  • L'opzione di progettazione per il failover tra regioni e ad alta disponibilità selezionata dipende dai tuoi requisiti.
  • Il traffico criptato oltre il confine ibrida ha implicazioni sul coordinamento della gestione dei certificati.

Se le considerazioni precedenti sono compromessi gestibili o irrilevanti per il tuo ambiente, consigliamo questo pattern come opzione preferita.

Il seguente diagramma mostra un hub ibrida di Network Connectivity Center come piano di gestione per le connessioni Cloud Interconnect. Mostra anche un hub VPC di Network Connectivity Center che connette gli spoke VPC di applicazioni e servizi:

VPC di applicazioni connesse come spoke a un hub di Network Connectivity Center

Bilanciamento del carico del proxy per la transitività

I seguenti elementi non sono raggiungibili nelle VPC spoke di Network Connectivity Center:

  • Endpoint dei servizi Private Service Connect e frontend dei servizi gestiti.
  • Le reti dietro le connessioni ibride (Cloud Interconnect o VPN ad alta disponibilità) perché le route dinamiche non vengono propagate sulla rete cross-cloud.

Queste limitazioni di transitività possono essere superate implementando bilanciatori del carico di rete proxy interni con le risorse non transitive gestite come gruppi di endpoint di rete (NEG) ibride. Puoi eseguire il deployment di bilanciatori del carico di rete proxy interni davanti ai frontend dei servizi e agli endpoint raggiungibili tramite le connessioni ibride. I frontend del bilanciatore del carico di rete proxy interno vengono implementati nelle subnet VPC propagate nelle VPC spoke della rete Cross-Cloud. I bilanciatori del carico di rete proxy interni consentono la raggiungibilità tramite la rete cross-cloud delle risorse non transitive. Per gli host e i servizi esterni, gli endpoint Private Service Connect e le reti di accesso privato ai servizi, i backend devono essere configurati come NEG ibride. I backend di Private Service Connect sono l'unico modello in cui i NEG non devono essere ibridi.

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 zone Google Cloud. Il forwarding DNS deve essere abilitato in modo bidirezionale tra Google 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 dei servizi centrali, 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 Cloud DNS per l'inoltro in entrata, 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 dei 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 app 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 servizi) 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: