Segmentazione e connettività di rete per 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 è costituita dai seguenti componenti:

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

  • La segmentazione complessiva della rete e la struttura del progetto.
  • Dove posizioni il tuo 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.
  • Modalità di connessione interna delle reti VPC tra loro.
  • Modalità di connessione delle subnet VPC Google Cloud tra loro e ad altre reti, incluso il modo in cui configuri la connettività dei servizi e 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. Scegli l'ambito delle autorizzazioni per per gli amministratori e gli sviluppatori dell'infrastruttura in base al principio del privilegiare e definire l'ambito delle risorse dell'applicazione in diversi progetti. 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 dell'infrastruttura il progetto di infrastruttura per creare e gestire risorse, servizi, e i criteri di routing DNS per i propri 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 di servizi facoltativo, che può essere utilizzato per consolidare dell'accesso privato ai servizi pubblicati.

Il seguente diagramma mostra una rappresentazione visiva degli elementi consigliati struttura VPC appena descritta. Puoi utilizzare lo Struttura VPC mostrata nel diagramma con un'istanza del progetto segmentato, come descritto nelle sezioni successive. Il diagramma mostrato qui e 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.

VPC condivisi di più applicazioni con l'applicazione corrispondente i progetti di servizio possono essere creati nel progetto host dell'infrastruttura in modo che struttura organizzativa. Utilizza più progetti di servizio delle 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 dell'applicazione e VPC. È possibile collegare più progetti di servizio delle applicazioni all'host progetto. La fatturazione per i servizi di rete è divisa tra l'host dell'infrastruttura nel progetto e nei 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. La non mostra la connettività tra tutti i progetti.

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

Posizionamento del carico di lavoro

Molte opzioni di connettività dipendono dalle località regionali dei carichi di lavoro. Per indicazioni sul posizionamento dei carichi di lavoro, consulta le best practice per le regioni di 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: percorsi di connettività:

  • Connessioni private ad altri cloud provider
  • Connessioni private a 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 a una o più interfacce rete-rete (NNI). La di NNI devono essere progettate, sottoposte a provisioning e configurate di 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. Calcolo dei percorsi i criteri per la resilienza, il failover e le preferenze per il percorso tra i domini possono essere configurato una volta nel VPC di transito e sfruttato da molti altri 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 il VPC di transito che funge da rete VPC di connettività per altri VPC, che sono connessi 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 l'utilizzo come privato e connessioni a Internet.

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, oltre alla crittografia MACsec e a di velocità effettiva massima di 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 perimetro del punto di presenza (POP) specificato e il regione pertinente in ogni CSP.

Per massimizzare l'affidabilità delle connessioni cross-cloud, ti consigliamo una che supporta 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 larghezza di banda elevata tra CSP diversi, puoi utilizzare tunnel VPN. Questo approccio è utile per iniziare ed eseguire l'upgrade Cross-Cloud Interconnect quando le tue applicazioni distribuite utilizzano e una maggiore larghezza di banda. I tunnel VPN possono inoltre raggiungere uno SLA del 99,99%. Per maggiori dettagli, vedi 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 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 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 i 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 servizio livello qualitativo di ciascuna rete può differire significativamente. Puoi decidere di utilizzare alcune reti piuttosto che altre, sulla base di queste differenze.

Configura il criterio di routing tra domini per soddisfare i tuoi requisiti per transito tra regioni, simmetria del traffico, velocità effettiva e resilienza.

La configurazione dei criteri di routing tra domini dipende dalla disponibilità sul perimetro 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 periferici, consigliamo che il tuo indirizzo IP il piano di gestione di indirizzi comporta un minor numero di prefissi aggregati per ogni regione e dominio combinazione.

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 CSP potrebbero avere a livello di regione VPC e ambiti BGP (Border Gateway Protocol). Per maggiori dettagli, consulta la documentazione dell'altro CSP.
  • Il router Cloud annuncia automaticamente le route con preferenze di percorso predeterminate in base alla vicinanza della regione. 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. Consulta la documentazione del CSP per i dettagli.

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 una progettazione attiva/attiva per i collegamenti tra regioni. Tuttavia, alcune topologie di networking on-premise combinate con l'uso della sicurezza stateful possono richiedere una progettazione attiva/passiva.

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 verso un singolo router Cloud all'interno di una regione. Questo design può supportare uno SLA con disponibilità del 99,9% in un un'area metropolitana quando segue le linee guida per stabilire il 99,9% disponibilità 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 tra domini tra più regioni

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

Il seguente diagramma mostra le architetture dello SLA del 99,99%. Mostra le risorse on-premise di rete in due diverse località collegate in modo ridondante router Cloud 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 un 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 l'instradamento con patate calde e fredde per specificare la rete di trasporto pubblico interregionale preferita. 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

Se non diversamente indicato, il traffico non è criptato su Cloud Interconnect connessioni tra diversi CSP o tra Google Cloud e on-premise 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, vedi MACsec per Cloud Interconnect Panoramica.
  • VPN ad alta disponibilità su Cloud Interconnect: utilizza più VPN ad alta disponibilità in modo da poter fornire l'intera larghezza di banda dell'infrastruttura e le connessioni Cloud Interconnect. 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, vedi VPN ad alta disponibilità su Cloud Interconnect Panoramica.

Connettività a internet per i carichi di lavoro

Per la connettività internet sia in entrata che in uscita, si presume che il traffico di risposta seguire in modo state tutto l'inverso rispetto alla direzione della richiesta originale.

In genere, le funzionalità che forniscono la connettività Internet in entrata sono separate funzionalità internet in uscita, ad eccezione dell'IP esterno che forniscono entrambi indicazioni stradali contemporaneamente.

Connettività Internet in entrata

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

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

Connettività a internet in uscita

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

Per la connettività in uscita, puoi utilizzare le opzioni integrate di Google Cloud, descritto in Creazione di una connettività internet per privati delle VM. In alternativa, puoi utilizzare le VM di NGFW centrali come descritto in sicurezza.

Il percorso principale per fornire la connettività internet in uscita è la connessione internet predefinita gateway principale nella tabella di routing VPC, che spesso è l'impostazione 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, le progettazioni di routing VPC che eseguono l'override della route predefinita fornire connettività in uscita con altri mezzi. Per maggiori dettagli, vedi Router Cloud Panoramica.

Per proteggere la connettività in uscita, Google Cloud offre Applicazione di Cloud Next Generation Firewall e Secure Web Proxy consente di applicare filtri più approfonditi sulle HTTP e HTTPS. In tutti i casi, tuttavia, il traffico segue la route predefinita. al gateway internet predefinito o tramite una route predefinita personalizzata nel VPC di routing.

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 attraverso l'uso esclusivo li annotino. BYOIP contribuisce alla portabilità della connettività e può far risparmiare gli 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. Ciascun router Cloud riceve dai peer esterni sulle NNI di ogni regione. Applicazione I VPC sono connessi 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. La 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 nel VPC di transito come beh. 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à.

Accesso agli endpoint Private Service Connect e ai servizi privati i frontend non sono raggiungibili nel peering di rete VPC o nella rete cross-cloud. I nostri suggerimenti la VPN ad alta disponibilità per la connettività tra VPC al fine di superare limitazioni. 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 discutono i possibili progetti per la connettività ibrida supportare la connettività IP di base e i deployment degli endpoint API.

Connettività tra VPC per l'accesso ai servizi condivisi

Quando viene eseguito il deployment degli endpoint dei servizi pubblicati in servizi VPC, consigliamo ai VPC dell'applicazione connettersi tramite peering di rete VPC all'hub (VPC di transito) che il VPC dei servizi si connette all'hub tramite 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 VPN ad alta disponibilità tra VPC: forniscono immagini transitive 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, pianifica le seguenti considerazioni:

  • Ridistribuzione delle subnet VPC peer nel routing dinamico (to da VPN ad alta disponibilità a cloud ibrido)
  • Considerazioni sul routing per più regioni
  • Propagazione di route dinamiche al peering VPC (dalla VPN ad alta disponibilità e da un modello ibrido)

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:

  • Località del cliente: un data center o un ufficio remoto in cui è disponibile la rete apparecchiature. Questo esempio presuppone che le località siano collegate tra loro usando una rete esterna.
  • Area metropolitana: un'area metropolitana contenente uno o più Disponibilità perimetrale di Cloud Interconnect di terze parti. Cloud Interconnect si connette ad altre reti nell'area in queste aree.
  • Progetto Hub: un progetto che ospita almeno una rete VPC da hub per altre reti VPC.
  • VPC di transito: una rete VPC nell'hub che invia connessioni da on-premise e da altri CSP, quindi gestisce come percorso di transito da altri VPC a on-premise e CSP reti.
  • Progetti host di app e VPC: 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 servizi gestiti: servizi forniti e gestiti da ma rese accessibili alle applicazioni in esecuzione reti VPC.

Per la progettazione 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 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 i VPC spoke di Network Connectivity Center tramite il bilanciamento del carico

Questo pattern include tutti i VPC 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 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. Puoi anche utilizzare Inter-VPC NAT con questo pattern.

Questo pattern presenta alcune limitazioni, per cui è necessario considerare prima gli aspetti riportati di seguito adottando questo schema:

  • Non puoi utilizzare gli asset virtuali per i firewall perimetrali con questo pattern. Perimetro i firewall devono rimanere su reti esterne.
  • È supportato solo il traffico TCP da e verso reti esterne. Questo limite si verifica perché le connessioni alle reti esterne passano attraverso il 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 prolifera record aggiuntivi 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. Potrebbero essere necessari bilanciatori del carico diversi a seconda dei protocolli richiesti per la connessione.
  • Le quote di bilanciamento del carico sono limitate per ciascuno rete VPC. Questa è una considerazione importante perché 4 servizi richiedono un nuovo bilanciatore del carico di rete proxy interno per ogni servizio di destinazione.
  • L'alta disponibilità scelta e tra regioni failover dipende dai tuoi requisiti.
  • Il traffico criptato attraverso il confine ibrido ha implicazioni sul certificato il coordinamento gestionale.

Se le considerazioni precedenti sono compromissioni gestibili o irrilevanti per ambiente, consigliamo di utilizzare 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:

  • Endend di servizio Private Service Connect e frontend di servizi gestiti.
  • Reti dietro connessioni ibride (Cloud Interconnect o VPN ad alta disponibilità) poiché le route dinamiche non vengono propagate sulla rete cross-cloud.

Questi limiti di transitivi possono essere superati eseguendo il deployment bilanciatori del carico di rete proxy interni con risorse non transitive gestite come ibride gruppi di endpoint di rete (NEG). 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 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 connettività su Rete cross-cloud dei sistemi non transitivi Google Cloud. Per host e servizi esterni, Endpoint Private Service Connect e 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 è necessario che siano 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 per le zone DNS esterne, mentre Cloud DNS è autorevole nelle zone di 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 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, 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 Google i nomi Cloud DNS) scegliendo come target la posta in entrata di Cloud DNS di inoltro, creato mediante il server in entrata policy nell'hub. in un VPC. Questa configurazione consente alla rete on-premise di risolvere i problemi Nomi di Cloud DNS.
  2. VPC di transito - Proxy in uscita DNS
    Pubblicizza il traffico DNS in uscita di Google. del proxy 35.199.192.0/19 al sulla rete on-premise usando 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 da richieste DNS in entrata da 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 il DNS dei servizi privato zone nel progetto host dei servizi e collegare il VPC condiviso, l'applicazione VPC condiviso e VPC hub nella 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 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. Risoluzione DNS per on-premise passano attraverso l'hub in un VPC.
    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: