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 effettui le seguenti scelte:

  • La segmentazione generale della rete e la struttura del progetto.
  • Dove posizioni il carico di lavoro.
  • Modalità di connessione dei progetti a ambienti on-premise esterni e ad altri cloud reti di provider, compresa 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 decidere tra uno dei due progetti strutture:

  • in un progetto host dell'infrastruttura consolidato, in cui viene utilizzato dell'infrastruttura host per gestire tutte le risorse di networking applicazioni
  • Progetti host segmentati, in cui utilizzi un progetto host dell'infrastruttura combinazione con un progetto host diverso per ogni applicazione

Durante la fase di pianificazione, ti consigliamo di decidere anche la gestione per gli ambienti dei carichi di lavoro. Definisci l'ambito delle autorizzazioni per gli amministratori e gli sviluppatori dell'infrastruttura in base al principio del privilegio minimo e definisci l'ambito delle risorse dell'applicazione in progetti di applicazioni diversi. Gli amministratori dell'infrastruttura devono configurare la connettività per condividere risorse, le risorse dell'infrastruttura possono essere gestite all'interno di un'infrastruttura progetto. Ad esempio, per configurare la connettività alle risorse di infrastruttura condivise, gli amministratori dell'infrastruttura possono utilizzare un progetto di infrastruttura e risorse condivise. Allo stesso tempo, il team di sviluppo può gestire carichi di lavoro in un progetto, e il team di produzione potrebbe gestire 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 implementarle inizialmente e come verranno organizzate nella gerarchia delle tue risorse. Per maggiori dettagli su come scegliere una gerarchia delle risorse, vedi Decidere una risorsa della gerarchia di destinazione zona di destinazione. Per maggiori dettagli su come scegliere il numero di reti VPC, consulta Decidere se per creare più reti VPC reti.

Per la rete cross-cloud, consigliamo di utilizzare quanto segue VPC:

  • Uno o più VPC delle applicazioni per ospitare le risorse per i diversi 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 degli elementi consigliati struttura VPC 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 consolidato

Puoi utilizzare un progetto host dell'infrastruttura consolidato per gestire tutte le attività di networking di risorse 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 in modo che corrispondano alla struttura dell'organizzazione. Utilizza più progetti di servizi di applicazioni per delegare l'amministrazione delle risorse. Networking in tutte le applicazioni I VPC vengono fatturati nel progetto host dell'infrastruttura consolidato.

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

Il seguente diagramma fornisce una rappresentazione visiva dello schema consolidato dell'infrastruttura host e più progetti di servizio delle applicazioni appena descritto. Il diagramma non mostra la connettività tra tutti i progetti.

Progetto host dell'infrastruttura consolidato e più progetti di servizio delle 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. I costi per l'infrastruttura vengono fatturati alla del progetto host dell'infrastruttura e i costi di rete per le applicazioni vengono fatturati a ogni progetto host dell'applicazione.

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

Più progetti host e più progetti di servizio delle applicazioni

Posizionamento del carico di lavoro

Molte scelte di connettività dipendono dalle località regionali dei carichi di lavoro. Per guidance su come posizionare i carichi di lavoro, consulta Best practice per la scelta delle regioni Compute Engine. Tu deve decidere dove si troveranno i carichi di lavoro prima di scegliere la connettività luoghi.

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

La rete cross-cloud prevede l'interconnessione di più reti cloud o reti on-premise. Le reti esterne possono essere di proprietà e gestite da organizzazioni diverse. Queste reti si connettono fisicamente tra loro 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 possibilità di inserire NAV di sicurezza, per le connessioni esterne e il routing in un VPC di transito, 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.

La progettazione delle NNI e della connettività esterna viene utilizzata in seguito per le applicazioni connettività e VPC networking.

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à condivisa per altri VPC

Connessioni private ad altri cloud provider

Se hai servizi in esecuzione su altre reti di provider di servizi cloud (CSP) che alla rete Google Cloud, puoi connetterti tramite internet o connessioni private. Consigliamo di utilizzare connessioni private.

Quando scegli le opzioni, considera velocità effettiva, privacy, costi e operazioni la redditività.

Per massimizzare la velocità effettiva migliorando al contempo la privacy, utilizza un modello di accesso diretto ad alta velocità connessione tra reti cloud. I collegamenti diretti eliminano la necessità di apparecchiature 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 usare 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 target. Per la selezione della località, considera quanto segue:

  • Controlla l'elenco delle località:
    • Per Cross-Cloud Interconnect, controlla l'elenco di località disponibili sia per Google Cloud che per CSP (disponibilità varia a seconda del provider cloud).
    • Per Dedicated Interconnect o Partner Interconnect, scegli una latenza bassa località 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 per maggiori dettagli, consulta Cross-Cloud Interconnect High disponibilità, Stabilisci una disponibilità del 99,99% per Dedicated Interconnect, e Stabilisci una disponibilità del 99,99% per Partner Interconnect.

Se non hai bisogno di una larghezza di banda elevata tra diversi 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 a data center on-premise

Per la connettività ai data center privati, puoi utilizzare una delle seguenti opzioni 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 peering norme:

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, la simmetria del flusso al confine tra il dominio è obbligatorio.

Per le reti che trasferiscono dati in più regioni, il costo e il livello di qualità 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 i domini vicini sono strutturati da un sistema autonomo con indirizzi IP (subnetting) in diverse regioni. 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 tra regioni, considera quanto segue:

  • sulle reti VPC di Google Cloud Router Cloud entrambi e supportare il routing globale tra regioni. Altri fornitori di servizi cloud potrebbero avere VPC regionali e ambiti BGP (Border Gateway Protocol). Per maggiori dettagli, consulta la documentazione dell'altro CSP.
  • Cloud Router annuncia automaticamente le route con preferenze di percorso predeterminate in base alla vicinanza regionale. Questo percorso Il comportamento degli utenti dipende dal routing dinamico configurato del VPC. Potrebbe essere necessario eseguire l'override di queste preferenze, il comportamento di routing desiderato.
  • I diversi CSP supportano diverse funzioni BGP e Bidirectional Forwarding Detection (BFD) e Il router Cloud di Google ha anche funzionalità specifiche per i criteri di route come descritto in Stabilire BGP sessioni.
  • CSP diversi potrebbero utilizzare attributi tie-breaking BGP diversi per dettare la preferenza per i percorsi. Per maggiori dettagli, consulta la documentazione del tuo fornitore di servizi cloud.

Routing tra domini in una singola regione

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

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

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

  • Le attività attive/attivi utilizzano il routing ECMP (Equal Cost Multi-Path) per aggregare i valori la larghezza di banda di entrambi i percorsi e utilizzarli contemporaneamente per i domini per via del traffico. Cloud Interconnect supporta anche l'uso di Aggregata da LACP link fino a 200 Gbps di larghezza di banda aggregata per percorso.
  • Lo stato attivo/passivo obbliga un link a essere pronto per essere pronto, occupandosi solo del traffico se il collegamento 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.

Viene creata un'istanza del router Cloud in più zone, una maggiore resilienza rispetto a quella fornita da 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 locali connessi in modo ridondante gestito in una singola regione:

Le connessioni resilienti possono utilizzare un singolo router Cloud

Routing interdominio multiregionale

Per fornire connettività di riserva, le reti possono essere in peering in più aree geografiche. 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 Cloud Router gestiti in due regioni diverse.

Connessioni Cloud Interconnect in più regioni

Al di là della resilienza, la progettazione del routing multiregionale dovrebbe simmetria. La struttura deve anche indicare la rete preferita comunicazioni tra regioni, cosa che si può fare con patate calde e patate fredde i percorsi dei carichi di lavoro. Associa il routing con patate fredde in un dominio a quello per le patate calde nella il dominio peer. Per il dominio cold-potato, consigliamo di utilizzare il valore Dominio di rete Google Cloud, che fornisce il routing VPC globale funzionalità.

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

Il seguente diagramma mostra come utilizzare il routing hot-potato e cold-potato per specificare la rete di trasporto pubblico interregionale che preferisci. In questo caso, il traffico dei prefissi X e Y rimangono sulla rete di origine finché non arrivano nella regione più vicino alla destinazione (percorso per patate fredde). Traffico proveniente da prefissi A e B passano all'altra rete nella regione di origine, quindi viaggiano attraverso l'altra rete fino alla destinazione (instradamento hot-potato).

Utilizzo dell'itinerario per patate calde e fredde per specificare la rete di trasporto pubblico interregionale preferita

Crittografia del traffico tra domini

Salvo diversa indicazione, 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 su Connessioni Cloud Interconnect tra router e Router perimetrali 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 IPsec sono criptate e il loro deployment viene eseguito su connessioni Cloud Interconnect che possono essere MACsec criptato. In questa configurazione, le connessioni Cloud Interconnect e configurata in modo da 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à 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 internet e la connettività ai server delle applicazioni web e ai server di gioco ospitati su in Google Cloud.

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

Connettività a internet in uscita

Alcuni esempi di connettività in uscita a internet (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 la connettività internet in uscita è la connessione internet predefinita gateway principale nella tabella di routing VPC, che spesso è quella predefinita route nei VPC Google. Sia gli IP esterni sia Cloud NAT (il nome servizio NAT gestito), richiedono una route che punti al gateway internet predefinito del VPC. Pertanto, i design di routing VPC che sostituiscono il route predefinito devono fornire la connettività in uscita tramite altri mezzi. Per maggiori dettagli, vedi Router Cloud Panoramica.

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, però, il traffico segue la route predefinita per il gateway internet predefinito o tramite una route predefinita personalizzata nella tabella di routing VPC.

Utilizzo dei propri IP

Puoi utilizzare indirizzi IPv4 di proprietà di Google per internet connettività oppure puoi utilizzare l'opzione Bring Your Own IP Address (BYOIP) per utilizzare uno spazio IPv4 di proprietà della tua organizzazione. La maggior parte di Google Cloud Prodotti che richiedono il supporto di un indirizzo IP con routing a internet tramite intervalli BYOIP .

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

Connettività interna e networking VPC

Con la connettività esterna e ibrida configurato, le risorse nel VPC di transito possono raggiungere reti. Il passaggio successivo è rendere disponibile questa connettività alle risorse ospitati in altri VPC.

Il seguente diagramma mostra la struttura generale di VPC, indipendentemente da come hai abilitato la connettività esterna. Mostra un mezzo di trasporto pubblico VPC che termina le connessioni esterne e ospita un 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, il trasporto pubblico Il VPC funziona da hub per i 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 ottenere prestazioni migliori e servizi di cloud networking integrati, ti consigliamo interconnettere i VPC con la rete Cross-Cloud o il peering di rete VPC, anziché 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à tra VPC. Poiché l'uso della VPN ad alta disponibilità per la connettività tra VPC può comportare una riduzione della velocità effettiva e un aumento dell'overhead operativo, la progettazione di servizi centralizzati riduce la durata del deployment della VPN ad alta disponibilità.

In alternativa, puoi implementare il traffico transitivo agli endpoint di servizio pubblicati inserendo un bilanciatore del carico di rete proxy interno di fronte agli endpoint dei servizi. Questo approccio presenta alcune limitazioni da considerare, descritti nella sezione dedicata alla connettività con gli spoke di Network Connectivity Center mediante l'uso di Google Cloud.

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 questa progettazione, il VPC di transito è l'hub e tu devi eseguire il deployment punti di accesso consumer per gli endpoint di servizio privati in un servizio in un VPC.

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

  • Peering di rete VPC: fornisce connettività tra l'hub tra il VPC e i VPC delle applicazioni.
  • Connessioni inter-VPC VPN ad alta disponibilità: forniscono connettività transitiva per il VPC dei servizi all'hub.

Per indicazioni dettagliate e progetti di configurazione per il deployment di questi tipi di connettività, consulta Rete Hub e spoke dell'architettura.

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 di servizi connesso il VPC di transito con la VPN ad alta disponibilità VPC connessi al VPC di transito con Peering di rete VPC:

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

La struttura mostrata nel diagramma precedente contiene i seguenti componenti:

  • Posizione del cliente: un data center o un ufficio remoto in cui hai l'apparecchiatura di rete. Questo esempio presuppone che le sedi siano collegate tra loro utilizzando una rete esterna.
  • Metro: un'area metropolitana contenente uno o più domini di disponibilità edge di Cloud Interconnect. Cloud Interconnect si connette ad altre reti in queste aree metropolitane.
  • Progetto Hub: un progetto che ospita almeno una rete VPC da hub per altre reti VPC.
  • VPC di transito: una rete VPC nel progetto hub che riceve le connessioni da CSP on-premise e di 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 accesso centralizzato ai servizi necessari alle applicazioni nell'applicazione reti VPC.
  • 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. I sottogruppi di comunicazione possono essere creati usando più hub di Network Connectivity Center. Eventuali restrizioni alla comunicazione richieste tra gli endpoint all'interno di un determinato hub possono essere raggiunti usando criteri.

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 un piano dati full mesh la connettività fra tutte le reti VPC registrate all'hub di Network Connectivity Center. Il pattern fornisce connettività da qualsiasi tipo e consente il deployment dei punti di accesso ai servizi gestiti in qualsiasi VPC.

Per superare i limiti di transitività, i punti di accesso ai servizi gestiti e alle connessioni ibride sono accessibili tramite bilanciatori del carico di rete proxy interni. Sicurezza dei carichi di lavoro per est-ovest possono utilizzare il firewall Cloud Next Generation. 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 gli asset virtuali 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 carico del proxy con il bilanciatore del carico di rete passthrough esterno regionale. 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 ibrido di Network Connectivity Center come hub di gestione per le connessioni Cloud Interconnect. Mostra anche un Hub VPC di Network Connectivity Center che collega l'applicazione spoke VPC di servizi:

VPC delle applicazioni connessi come spoke a un hub di Network Connectivity Center

Bilanciamento del carico del proxy per la transitività

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

  • Endpoint di servizio Private Service Connect e frontend di 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 il servizio frontend e di fronte agli endpoint raggiungibili attraverso il e connessioni a Internet. Il deployment dei frontend del bilanciatore del carico di rete del proxy interno viene eseguito Subnet VPC che vengono propagate nello spoke di rete tra cloud VPC. 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 server 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 gli amministratori di diversi progetti di servizi delle applicazioni possono creare utilizzano i loro servizi cross-project, associazione di zone DNS. L'associazione tra progetti consente la segmentazione e la delega del DNS agli amministratori del progetto di servizio.

Nel caso del trasporto pubblico, quando le reti esterne comunicano con altre alle reti esterne tramite Google Cloud, le zone DNS esterne devono configurate per inoltrare le richieste direttamente l'una all'altra. Il team di La rete cross-cloud fornirebbe connettività per il DNS richieste e risposte da completare, ma Google Cloud DNS coinvolti nell'inoltro del traffico di risoluzione DNS tra le zone reti esterne. Qualsiasi regola firewall applicata nel La rete cross-cloud deve consentire il traffico di risoluzione DNS tra verso le reti esterne.

Il seguente diagramma mostra che una progettazione DNS può essere utilizzata con qualsiasi Configurazioni di connettività VPC proposte in questa guida alla progettazione:

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

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

  1. DNS on-premise
    Configura i server DNS on-premise in modo che siano autorevoli per le zone DNS on-premise. Configura l'inoltro DNS (per i nomi DNS di Google Cloud) scegliendo come target l'indirizzo IP di Cloud DNS per l'inoltro in entrata, creato tramite la configurazione del criterio del server in entrata nella VPC dell'hub. Questa configurazione consente alla rete on-premise di risolvere i problemi Nomi di Cloud DNS.
  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. 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. Configurare l'inoltro di Cloud DNS zona (per DNS on-premise nomi) che hanno come target i server DNS on-premise.
  4. VPC servizi - Cloud DNS
    1. Configurare la zona di peering DNS dei servizi (per i nomi DNS on-premise) impostando il VPC hub come peer in ogni rete. La risoluzione DNS per le risorse on-premise e di servizio passa il VPC dell'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. Ciò consente a tutti gli host (on-premise e in tutti i progetti di servizio) per risolvere i nomi DNS dei servizi.
  5. Progetto host dell'app - Cloud DNS
    1. Configura una zona di peering DNS dell'app per i nomi DNS on-premise impostando l'hub VPC come rete peer. La risoluzione DNS per gli host on-premise avviene tramite la VPC dell'hub.
    2. Configura le zone private DNS delle app nel progetto App Host e collega il VPC dell'applicazione, VPC condiviso dei servizi e hub VPC alla zona. Questa configurazione consente a tutti gli host (on-premise e tutti i progetti di servizio) per risolvere i nomi DNS dell'app.

Per maggiori informazioni, consulta Architettura ibrida con VPC hub rete connessa al VPC spoke reti.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: