Segmentazione e connettività della rete per applicazioni distribuite nella rete Cross-Cloud

Last reviewed 2024-04-05 UTC

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

La serie è costituita dai seguenti componenti:

Questa parte esplora la struttura e la connettività di segmentazione della rete, che costituiscono la base della progettazione. Questo documento illustra le fasi in cui effettui le seguenti scelte:

  • La segmentazione della rete complessiva e la struttura del progetto.
  • Dove posizioni il carico di lavoro.
  • Modalità di connessione dei progetti a reti on-premise esterne e di altri cloud provider, inclusa la progettazione di connettività, routing e crittografia.
  • Modalità di connessione interna delle reti VPC.
  • Il modo in cui le subnet VPC di Google Cloud sono connesse tra loro e ad altre reti, incluso la configurazione della connettività del servizio e del DNS.

Segmentazione della rete e struttura del progetto

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

  • Un progetto host di infrastruttura consolidata, in cui utilizzi un singolo progetto host di infrastruttura per gestire tutte le risorse di networking per tutte le applicazioni
  • Progetti host segmentati, in cui si utilizza un progetto host dell'infrastruttura insieme a 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. Limita le autorizzazioni per gli amministratori e gli sviluppatori dell'infrastruttura in base al principio del privilegio minimo e applica le risorse delle applicazioni a progetti di applicazioni diversi. Poiché gli amministratori dell'infrastruttura devono configurare la connettività per condividere le risorse, le risorse di infrastruttura possono essere gestite all'interno di un progetto di infrastruttura. Ad esempio, per configurare la connettività alle risorse di infrastruttura condivisa, gli amministratori dell'infrastruttura possono utilizzare un progetto di infrastruttura per gestire le risorse condivise. Allo stesso tempo, il team di sviluppo potrebbe gestire i carichi di lavoro in un solo progetto, mentre il team di produzione potrebbe gestire i carichi di lavoro in un progetto separato. Gli sviluppatori potrebbero quindi usare le risorse dell'infrastruttura nel progetto di infrastruttura per creare e gestire risorse, servizi, bilanciamento del carico e criteri di routing DNS per i carichi di lavoro.

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

Per la rete Cross-Cloud, consigliamo di utilizzare i seguenti VPC:

  • Uno o più VPC delle applicazioni per ospitare le risorse per le diverse applicazioni.
  • Un VPC in transito in cui viene gestita tutta la connettività esterna.
  • Un VPC di servizi centrali 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 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 consolidata per gestire tutte le risorse di networking, come subnet, peering e bilanciatori del carico.

Nel progetto host dell'infrastruttura è possibile creare più VPC condivisi con i relativi progetti di servizio dell'applicazione in modo che corrispondano alla struttura organizzativa. Usare più progetti di servizio delle applicazioni per delegare l'amministrazione delle risorse. Tutte le reti di networking in tutti i VPC dell'applicazione vengono fatturate al progetto host dell'infrastruttura consolidata.

Per questa struttura, molti progetti di servizio delle applicazioni possono condividere un numero inferiore di VPC delle applicazioni.

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

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

Progetti host segmentati

In questo pattern, ogni gruppo di applicazioni ha il proprio progetto host dell'applicazione e VPC. È possibile collegare più progetti di servizio dell'applicazione al progetto host. La fatturazione dei servizi di rete è suddivisa tra progetto host dell'infrastruttura e progetti host dell'applicazione. I costi dell'infrastruttura vengono fatturati al progetto host dell'infrastruttura, mentre i costi di rete per le applicazioni vengono fatturati a ciascun progetto host dell'applicazione.

Il seguente diagramma fornisce una rappresentazione visiva dei vari progetti host e dei vari progetti di servizio delle applicazioni appena descritti. Lo schema non mostra la connettività tra tutti i progetti.

Più progetti host e più progetti di servizio per le applicazioni

Posizionamento del carico di lavoro

Molte scelte di connettività dipendono dalle località a livello di regione dei carichi di lavoro. Per indicazioni sul posizionamento dei carichi di lavoro, consulta Best practice per la selezione delle regioni di Compute Engine. Dovresti decidere dove si troveranno i carichi di lavoro prima di scegliere le località di connettività.

Connettività esterna e ibrida

In questa sezione vengono descritti i requisiti e i consigli per i seguenti percorsi di connettività:

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

La rete cross-cloud 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 su una o più interfacce da rete a rete (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 in transito, che poi funge da servizio di connettività condivisa per altri VPC. I criteri di routing per resilienza, failover e preferenza di percorso tra i domini possono essere configurati una volta nel VPC in transito e sfruttati da molte altre reti VPC.

Il design delle reti NNI e della connettività esterna verrà utilizzato successivamente per connettività interna e networking VPC.

Il seguente diagramma mostra il VPC in transito che funge da servizio di connettività condivisa per altri VPC, connessi tramite peering di rete VPC, Network Connectivity Center o VPN ad alta disponibilità:

VPC in transito utilizzato come servizio di connettività condivisa per altri VPC

Connessioni private ad altri cloud provider

Se hai servizi in esecuzione su reti di altri provider di servizi cloud (CSP) che vuoi connettere alla tua rete Google Cloud, puoi connetterti a loro 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 la velocità effettiva migliorando al contempo la privacy, utilizza una connessione diretta ad alta velocità tra 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 velocità effettiva 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 colleghi agli altri CSP in base alla vicinanza della località alle regioni target. Per la selezione della località, considera quanto segue:

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

Per massimizzare l'affidabilità delle connessioni cross-cloud, consigliamo una configurazione che supporta 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 richiedi un'elevata larghezza di banda tra diversi CSP, puoi utilizzare i tunnel VPN. Questo approccio può aiutarti a iniziare ed eseguire l'upgrade a Cross-Cloud Interconnect quando le tue applicazioni distribuite utilizzano una larghezza di banda maggiore. I tunnel VPN possono inoltre 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 in che modo 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 dai dispositivi di sicurezza stateful. Di conseguenza, è necessaria una simmetria del flusso in corrispondenza del confine tra i domini.

Per le reti che trasferiscono dati in più regioni, il livello di costi e qualità del servizio di ciascuna rete potrebbe variare in modo significativo. Potresti decidere di utilizzare alcune reti rispetto ad altre, in base a queste differenze.

Configura il criterio di routing tra domini per soddisfare i requisiti relativi a trasporto pubblico tra regioni, simmetria del traffico, velocità effettiva e resilienza.

La configurazione dei criteri di routing tra domini dipende dalle funzioni disponibili sul perimetro di ciascun dominio. La configurazione dipende anche da come sono strutturati i domini vicini dal punto di vista di un sistema autonomo e di un indirizzo IP (subnetting) in diverse regioni. Per migliorare la scalabilità senza superare i limiti di prefissi sui dispositivi periferici, ti consigliamo di ridurre il numero di prefissi aggregati del tuo piano di indirizzi IP per ogni combinazione di regione e dominio.

Quando progetti il routing tra regioni, considera quanto segue:

  • Le reti VPC Google 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.
  • Il router Cloud pubblicizza automaticamente route con preferenze di percorso predeterminate in base alla vicinanza regionale. Questo comportamento di routing dipende dalla modalità di routing dinamico configurata del VPC. Potrebbe essere necessario eseguire l'override di queste preferenze per il comportamento di routing che preferisci.
  • I diversi CSP supportano funzioni BGP e Bidirectional Forwarding Detection (BFD) diverse e il router Cloud di Google dispone anche di funzionalità specifiche per i criteri di route come descritto in Stabilire sessioni BGP.
  • CSP diversi potrebbero utilizzare attributi di tie-breaking BGP diversi per dettare le preferenze per le route. Per i dettagli, consulta la documentazione del CSP.

Routing tra domini a regione singola

Ti consigliamo di iniziare con il routing tra domini a regione singola, che potrai sfruttare per creare più connessioni tra regioni con il routing tra domini.

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

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

  • Attivo/attivo 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.
  • Lo stato attivo/passivo obbliga un link a essere pronto in standby, prendendo traffico solo se il link attivo viene interrotto.

Consigliamo una progettazione attiva/attiva per i collegamenti all'interno delle regioni. Tuttavia, alcune topologie di rete on-premise, combinate con l'uso di funzioni di sicurezza stateful, possono richiedere una progettazione attiva/passiva.

Viene creata un'istanza del router Cloud su più zone, il che offre una resilienza maggiore rispetto a quella fornita da un singolo elemento. Il seguente diagramma mostra in che modo tutte le connessioni resilienti convergono in un singolo router Cloud all'interno di una regione. Questo design può supportare uno SLA (accordo sul livello del servizio) con disponibilità del 99,9% all'interno di una singola area metropolitana se viene seguita 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 tra più regioni

Per fornire connettività di backup, le reti possono eseguire il peering in più aree geografiche. Collegando le reti in più regioni, lo SLA (accordo sul livello del servizio) con disponibilità può aumentare fino al 99,99%.

Il seguente diagramma mostra le architetture dello SLA (accordo sul livello del servizio) del 99,99%. Mostra i router on-premise in due località diverse collegate in modo ridondante ai servizi del router Cloud gestiti in due regioni diverse.

Connessioni Cloud Interconnect in più regioni

Oltre alla resilienza, la progettazione del routing a più regioni dovrebbe realizzare una simmetria dei flussi. Il design deve anche indicare la rete preferita per le comunicazioni tra regioni, che è possibile fare con il routing a patate calde e fredde. Accoppia il routing "freddo" in un dominio con il routing "hot-potato" nel dominio peer. Per il dominio Cold Potato, consigliamo di utilizzare il dominio della rete Google Cloud, che offre 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 tua rete di trasporto pubblico 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 a freddo). Il traffico proveniente dai prefissi A e B passa all'altra rete nella regione di origine e poi attraversa l'altra rete fino alla destinazione (routing hot-potato).

Tramite il routing "patate piccanti" o "fredde" per specificare la rete di trasporto pubblico interregionale che preferisci

Crittografia del traffico tra domini

Se non diversamente indicato, il traffico non viene criptato sulle connessioni di 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 router e i router perimetrali di Google. Per maggiori dettagli, consulta la panoramica su MACsec per Cloud Interconnect.
  • VPN ad alta disponibilità su Cloud Interconnect: utilizza più tunnel VPN ad alta disponibilità per fornire l'intera larghezza di banda delle connessioni Cloud Interconnect sottostanti. I tunnel VPN ad alta disponibilità sono criptati con IPsec e vengono distribuiti tramite connessioni Cloud Interconnect che possono anche essere 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 sulla VPN ad alta disponibilità su Cloud Interconnect.

Connessione a internet per i carichi di lavoro

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

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

Connettività internet in entrata

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

Le principali funzionalità che forniscono la connettività internet in entrata sono i prodotti Cloud Load Balancing di Google.

Tutti i tipi di Cloud Load Balancing forniscono il proprio percorso per il traffico che torna all'origine internet, indipendentemente dal fatto che utilizzi percorsi di ritorno speciali VPC o subnet proxy definite dall'utente. La progettazione del VPC è generalmente indipendente dalla sua capacità di fornire connettività a internet in entrata.

Connettività internet in uscita

Esempi di connettività internet in uscita (dove la richiesta iniziale ha origine dal carico di lavoro a una destinazione internet) includono i carichi di lavoro che accedono ad API di terze parti, il download di pacchetti software e aggiornamenti e l'invio di 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 connettività internet per le VM private. In alternativa, puoi utilizzare NGFW centrali NVA come descritto in Sicurezza di rete.

Il percorso principale per fornire la connettività internet in uscita è la destinazione predefinita del gateway internet nella tabella di routing VPC, che spesso è la route predefinita nei VPC Google. Sia gli IP esterni sia Cloud NAT (il servizio NAT gestito di Google Cloud) richiedono una route che punta al gateway internet predefinito del VPC. Pertanto, le progettazioni di routing VPC che sostituiscono la route predefinita devono fornire la connettività in uscita con altri mezzi. Per maggiori dettagli, consulta la panoramica del router Cloud.

Per proteggere la connettività in uscita, Google Cloud offre l'applicazione sia del firewall Cloud Next Generation sia di Secure Web Proxy per applicare un filtro più approfondito sugli URL HTTP e HTTPS. In ogni caso, tuttavia, il traffico segue la route predefinita in uscita al gateway internet predefinito o attraverso 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 oppure puoi utilizzare l'opzione Bring your own IP addresses (BYOIP) per utilizzare uno spazio IPv4 di proprietà dell'organizzazione. La maggior parte dei prodotti Google Cloud che richiedono il supporto di un indirizzo IP instradabile su internet utilizzando invece intervalli BYOIP.

Puoi inoltre controllare la reputazione dello spazio IP attraverso l'uso esclusivo di quest'ultimo. BYOIP favorisce la portabilità della connettività e può far risparmiare i costi degli indirizzi IP.

Connettività interna e networking VPC

Con il servizio di connettività esterna e ibrida configurato, le risorse nel VPC in 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 abilitato la connettività esterna. Mostra un VPC in transito che termina le connessioni esterne e ospita un router Cloud in ogni regione. Ogni router Cloud riceve route dai suoi peer esterni tramite le reti NNI di ogni regione. I VPC dell'applicazione sono connessi al VPC di transito e possono condividere la connettività esterna. Inoltre, il VPC in transito funziona come un hub per i VPC spoke. I VPC spoke possono ospitare applicazioni, servizi o una combinazione di entrambi.

Struttura generale della rete Cross-Cloud

Configura l'inoltro e il peering DNS anche nel VPC in transito. Per maggiori dettagli, consulta la sezione relativa alla progettazione dell'infrastruttura DNS.

Per migliorare le prestazioni e i servizi di networking cloud integrati, consigliamo di interconnettere i VPC con la rete Cross-Cloud o con il peering di rete VPC, anziché con la VPN ad alta disponibilità.

Gli endpoint Private Service Connect e i frontend di accesso ai servizi privati non sono raggiungibili nel peering di rete VPC o nella rete Cross-Cloud. Consigliamo di utilizzare VPN ad alta disponibilità per la connettività tra VPC per superare queste limitazioni. Poiché l'utilizzo della VPN ad alta disponibilità per la connettività tra VPC può comportare una velocità effettiva inferiore e un aumento dell'overhead operativo, la progettazione dei servizi centralizzati riduce la durata 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 alcune limitazioni da considerare, illustrate nella sezione Connettività con gli spoke di Network Connectivity Center utilizzando il bilanciamento del carico.

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

Connettività tra VPC per servizi centralizzati

Quando è possibile eseguire il deployment degli endpoint di servizio pubblicati in un VPC di servizi centrali, è consigliabile che i VPC dell'applicazione si connettano tramite peering di rete VPC all'hub (VPC di transito) e che il VPC dei servizi centrali si connetta all'hub tramite VPN ad alta disponibilità.

In questo progetto, il VPC di transito è l'hub e viene eseguito il deployment delle regole di forwarding per gli endpoint di servizio privati in un VPC di servizi centrali. Imposta il VPC dei servizi centrali come rete VPC condiviso e consenti agli amministratori dei progetti di servizio di creare endpoint di servizio nella rete condivisa.

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

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

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

Quando combini queste architetture, tieni in considerazione le seguenti considerazioni:

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

Il seguente diagramma mostra un VPC di servizi centrali connesso al VPC in transito con VPN ad alta disponibilità e i VPC dell'applicazione connessi al VPC in transito con peering di rete VPC:

Il VPC di servizi centrali connesso al VPC in transito con VPN ad alta disponibilità e i VPC dell'applicazione connessi al VPC in transito con peering di rete VPC

La struttura mostrata nel diagramma precedente contiene i seguenti componenti:

  • Località del cliente: un data center o un ufficio remoto in cui sono installate apparecchiature di rete. Questo esempio presuppone che le località siano collegate 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 per il trasporto pubblico: una rete VPC nel progetto hub che collega le connessioni da on-premise e da altri CSP, quindi funge da percorso di transito da altri VPC a reti on-premise e CSP.
  • Progetti host e VPC di app: progetti e reti VPC che ospitano varie applicazioni.
  • VPC di servizi: una rete VPC che ospita l'accesso centralizzato ai servizi richiesti dalle 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 e spoke, quando i VPC delle applicazioni devono comunicare tra loro, puoi connettere i VPC dell'applicazione a un hub di Network Connectivity Center come spoke. Questo approccio fornisce connettività tra tutti i VPC nell'hub di Network Connectivity Center. Puoi creare sottogruppi di comunicazione utilizzando più hub di Network Connectivity Center. Eventuali restrizioni di comunicazione richieste tra endpoint in un determinato hub possono essere raggiunte usando i criteri firewall.

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

Questo pattern include tutti i VPC come spoke in un hub di Network Connectivity Center e può ospitare fino a 250 VPC interconnessi. Un hub di Network Connectivity Center è un costrutto del piano di gestione che crea una connettività completa del piano dati mesh tra tutte le reti VPC registrate come spoke dell'hub di Network Connectivity Center. Il pattern fornisce connettività da qualsiasi a qualsiasi e consente il deployment di servizi gestiti in qualsiasi VPC, eliminando la necessità di decidere tra servizi centralizzati o distribuiti.

Per superare le limitazioni di transitività, i servizi gestiti e le connessioni ibride sono accessibili tramite bilanciatori del carico di rete proxy interni. Per la sicurezza delle connessioni est-ovest, è possibile usare il firewall Cloud Next Generation. Puoi anche utilizzare Inter-VPC NAT con questo pattern.

Questo modello presenta alcune limitazioni, pertanto è necessario considerare i seguenti aspetti prima di adottarlo:

  • Non puoi utilizzare NVA per i firewall perimetrali con questo pattern. I firewall perimetrali devono rimanere sulle reti esterne.
  • È supportato solo il traffico TCP da e verso reti esterne. Questo limite si verifica perché le connessioni a reti esterne vengono eseguite tramite un bilanciatore del carico di rete proxy interno.
  • I servizi pubblicati avranno un frontend aggiuntivo nel bilanciatore del carico del proxy. Questo frontend aggiuntivo prolifera di record aggiuntivi in DNS e richiede ricerche DNS divise.
  • I servizi di livello 4 richiedono un nuovo bilanciatore del carico di rete proxy interno per ogni nuovo servizio. Potresti aver bisogno di bilanciatori del carico diversi a seconda dei protocolli richiesti per la connessione.
  • Le quote per il bilanciamento del carico sono limitate per ogni rete VPC. Questa è una considerazione 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 alta disponibilità e failover tra regioni dipende dai requisiti.
  • Il traffico criptato attraverso il confine ibrido ha implicazioni sul coordinamento della gestione dei certificati.

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

Il seguente diagramma mostra un hub ibrido di Network Connectivity Center come piano di gestione per le connessioni Cloud Interconnect. Mostra inoltre un hub VPC di Network Connectivity Center che connette gli spoke VPC dell'applicazione e dei servizi:

VPC dell'applicazione connessi come spoke a un hub di Network Connectivity Center

Bilanciamento del carico del proxy per la transitività

I seguenti elementi non sono raggiungibili tra i VPC dello spoke di Network Connectivity Center:

  • Endpoint di servizio Private Service Connect e frontend di servizi gestiti.
  • Reti protette da connessioni ibride (Cloud Interconnect o VPN ad alta disponibilità) perché le route dinamiche non vengono propagate in Cross-Cloud Network.

Questi limiti di transitività possono essere superati eseguendo il deployment di bilanciatori del carico di rete proxy interni con risorse non transitive gestite come gruppi di endpoint di rete ibridi (NEG). Puoi eseguire il deployment di bilanciatori del carico di rete proxy interni davanti ai frontend di servizio e agli endpoint raggiungibili attraverso le connessioni ibride. Il deployment dei frontend del bilanciatore del carico di rete proxy interno viene eseguito in subnet VPC che vengono propagate nei VPC dello spoke di rete Cross-Cloud. I bilanciatori del carico di rete proxy interni consentono la connettività sulla rete cross-cloud delle risorse non transitive. Per host e servizi esterni, endpoint Private Service Connect e reti di accesso privato ai servizi, i backend devono essere configurati come NEG ibridi. I backend 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 provider esterno (on-premise o CSP) può gestire una ricerca DNS. I server DNS esterni sono autorevoli per le zone DNS esterne e Cloud DNS è autorevole per le zone Google Cloud. L'inoltro 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 servizio per le applicazioni possono creare un'istanza 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 in modo da inoltrare le richieste direttamente l'una all'altra. La rete Google Cross-Cloud Network fornirà connettività per il completamento delle richieste e delle risposte DNS, ma Google Cloud DNS si impegna a inoltrare qualsiasi traffico di risoluzione DNS tra zone nelle reti esterne. Qualsiasi regola firewall applicata nella rete cross-cloud deve consentire il traffico di risoluzione DNS tra le reti esterne.

Il seguente diagramma mostra una progettazione DNS che può essere utilizzata con qualsiasi configurazione di connettività VPC hub e spoke proposta in questa guida alla progettazione:

Design DNS che può essere utilizzato con pattern di connettività hub e 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 l'inoltro DNS (per i nomi Google Cloud DNS) scegliendo come target l'indirizzo IP di forwarding in entrata di Cloud DNS, creato tramite la configurazione dei criteri del server in entrata nel VPC dell'hub. Questa configurazione consente alla rete on-premise di risolvere i nomi Google Cloud DNS.
  2. VPC di transito - Proxy in uscita DNS
    Pubblicizza l'intervallo proxy DNS in uscita di Google 35.199.192.0/19 verso la 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 in transito - Cloud DNS
    1. Configurare un criterio del 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) che ha come target i server DNS on-premise.
  4. VPC di servizi - Cloud DNS
    1. Configura la zona di peering del DNS dei servizi (per i nomi DNS on-premise) impostando il VPC dell'hub come rete peer. La risoluzione DNS per le risorse di servizio e on-premise passa tramite il VPC dell'hub.
    2. Configura le zone private del DNS dei servizi nel progetto host dei servizi e collega il VPC condiviso dei servizi, il VPC condiviso dell'applicazione e il VPC dell'hub alla zona. Ciò consente a tutti gli host (on-premise e in tutti i progetti di servizio) di risolvere i nomi DNS dei servizi.
  5. Progetto host app - Cloud DNS
    1. Configura una zona di peering DNS dell'app per i nomi DNS on-premise impostando il VPC dell'hub come rete peer. La risoluzione DNS per gli host on-premise passa attraverso il VPC dell'hub.
    2. Configura le zone private DNS dell'app nel progetto host di app e collega il VPC dell'applicazione, il VPC condiviso dei servizi e il VPC dell'hub alla zona. Questa configurazione consente a tutti gli host (on-premise e in tutti i progetti di servizio) di risolvere i nomi DNS dell'app.

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

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: