Networking di servizi per applicazioni distribuite nella rete Cross-Cloud

Last reviewed 2024-05-31 UTC

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

La serie è costituita dai seguenti componenti:

Questo documento descrive come assemblare un'applicazione da un insieme di i servizi dei componenti creati. Ti consigliamo di leggere l'intero documento una volta prima di seguire la procedura.

Questo documento ti guida nelle seguenti decisioni:

  • Sia che crei personalmente il singolo servizio o utilizzi una servizio di terze parti
  • Se il servizio è disponibile a livello globale o regionale
  • Se il servizio viene utilizzato on-premise, da altri cloud o da nessuna delle due opzioni
  • Sia che si acceda all'endpoint di servizio tramite un VPC di servizi condivisi distribuire gli endpoint attraverso tutti i VPC delle applicazioni

Questo documento ti guida nei seguenti passaggi:

  1. Decidere se l'applicazione è globale o regionale
  2. Scegliere servizi gestiti di terze parti o creare e pubblicare propri servizi
  3. Configura l'accesso privato agli endpoint di servizio utilizzando un server modalità dedicata
  4. Assemblaggio dei servizi in applicazioni per farli corrispondere a un ambiente archetipo regionale

Gli sviluppatori definiscono il livello di networking dei servizi per la rete cross-cloud. A questo punto, gli amministratori hanno progettato una connettività per la rete cross-cloud che consente flessibilità delle opzioni di networking dei servizi descritte in questo documento. Nel in alcuni casi, i vincoli dovuti a una limitata transitività tra VPC esistono. Descriviamo questi vincoli quando possono influenzare le decisioni di progettazione.

Decidi se la tua applicazione è regionale o globale

Determina se i clienti dell'applicazione che stai creando hanno bisogno di una regione o archetipo di deployment globale. Puoi ottenere la resilienza regionale diffondendo vengono caricati in più zone di una regione. Puoi ottenere la resilienza globale e distribuire i carichi tra le regioni.

Prendi in considerazione i seguenti fattori quando scegli un archetipo:

  • I requisiti di disponibilità dell'applicazione
  • La località in cui viene utilizzata l'applicazione.
  • Costo

Per maggiori dettagli, consulta Deployment di Google Cloud archetipi.

Questa guida alla progettazione illustra come supportare i seguenti archetipi di deployment:

In un'applicazione distribuita cross-cloud, i diversi servizi dell'applicazione possono essere fornite da diversi provider di servizi cloud (CSP) o data center privati. Per garantire una struttura di resilienza coerente, inserisci i servizi in hosting in data center CSP geograficamente vicini tra loro.

Il seguente diagramma mostra uno stack di applicazioni globale distribuito tra cloud e in diversi servizi per applicazioni viene eseguito il deployment in diversi CSP. Ciascuna il servizio globale delle applicazioni dispone di istanze dei carichi di lavoro in diverse regioni dello stesso CSP.

Stack di applicazioni globale distribuito nuvole.

Definizione e accesso ai servizi per le applicazioni

Per assemblare la tua applicazione, puoi usare servizi gestiti di terze parti esistenti, crea e ospita i tuoi servizi per le applicazioni oppure usa una combinazione di entrambi.

Utilizzare servizi gestiti di terze parti esistenti

Decidi quali servizi gestiti di terze parti puoi utilizzare per la tua applicazione. Determina quali ovvero quelli strutturati come servizi regionali o globali. Inoltre, per determinare le opzioni di accesso privato supportate da ciascun servizio.

Quando sai quali servizi gestiti puoi utilizzare, puoi determinare quali che devi creare.

Crea e accedi ai servizi per le applicazioni

Ogni servizio è ospitato da una o più istanze del carico di lavoro a cui è possibile accedere un singolo endpoint o come un gruppo di endpoint.

Il pattern generale per un servizio dell'applicazione è mostrato di seguito in questo diagramma. Il servizio dell'applicazione viene distribuito in una raccolta di carichi di lavoro di Compute Engine. In questo caso, un'istanza di un carico di lavoro potrebbe essere una VM un cluster Google Kubernetes Engine (GKE) o un altro backend che esegue il codice. Le istanze del carico di lavoro sono organizzati come set di backend associati a un bilanciatore del carico.

Il seguente diagramma mostra un bilanciatore del carico generico con un set di backend.

Bilanciatore del carico con backend.

Per ottenere la distribuzione del carico scelta e automatizzare i failover, questi gruppi di endpoint utilizzano un bilanciatore del carico frontend. Utilizzando l'istanza gestita gruppi (MIG), puoi aumentare o diminuire elasticamente la capacità mediante la scalabilità automatica degli endpoint che costituiscono il backend del carico con il bilanciatore del carico di rete passthrough esterno regionale. Inoltre, a seconda dei requisiti del servizio dell'applicazione, il bilanciatore del carico può anche fornire autenticazione, terminazione TLS e e servizi specifici per la connessione.

Determina l'ambito del servizio (regionale o globale)

Decidi se il tuo servizio ha bisogno e può supportare la resilienza regionale o globale. Un servizio software regionale può essere progettato per la sincronizzazione rispettando un budget di latenza regionale. Un servizio delle applicazioni globale può supportare i failover tra nodi distribuiti in più regioni. Se la tua applicazione è globale, è possibile che anche i servizi che lo supportano siano globali. Ma se il servizio richiede la sincronizzazione tra le istanze per supportare il failover, devi considerare la latenza tra le regioni. Per la tua situazione, potresti fare affidamento su servizi regionali con ridondanza nelle stesse regioni o nelle vicinanze, supportando quindi la sincronizzazione a bassa latenza per il failover.

Cloud Load Balancing supporta gli endpoint ospitati all'interno di una singola regione o distribuiti in più regioni. In questo modo, puoi creare livello globale rivolto ai clienti, rivolto a servizi globali, regionali o ibridi. diversi strati. Scegli i deployment dei servizi per garantire che il failover di rete dinamico (o il bilanciamento del carico tra regioni) sia in linea con lo stato di resilienza e le funzionalità della logica dell'applicazione.

Il seguente diagramma mostra come un servizio globale creato dal carico a livello di regione possono raggiungere backend in altre regioni, fornendo così il failover automatico tra regioni diverse. In questo esempio, la logica dell'applicazione è globale e il backend scelto supporta la sincronizzazione tra regioni. A ogni caricamento il bilanciatore invia principalmente richieste alla regione locale, ma può eseguire il failover regioni.

Bilanciatori del carico con backend in regioni diverse.

  • Un backend globale è una raccolta di backend regionali a cui accede un o più bilanciatori del carico.
  • Sebbene i backend siano globali, il frontend di ogni bilanciatore del carico è a livello di regione.
  • In questo modello di architettura, i bilanciatori del carico distribuiscono principalmente il traffico solo all'interno regione, ma può anche bilanciare il traffico verso altre regioni quando le risorse nella regione locale non sono disponibili.
  • Un insieme di frontend dei bilanciatori del carico a livello di regione, ciascuno accessibile da altre regioni e ognuno in grado di raggiungere backend in altre regioni, formano un servizio globale aggregato.
  • Per assemblare uno stack di applicazioni globale, come discusso in Progettare stack di applicazioni globali, puoi utilizzare il routing DNS e controlli di integrità per ottenere il failover tra regioni dei frontend.
  • I frontend dei bilanciatori del carico sono a loro volta accessibili da altre regioni utilizzando accesso globale (non mostrato nel diagramma).

Lo stesso pattern può essere usato per includere i servizi pubblicati con di failover. Il seguente diagramma illustra un servizio pubblicato che utilizza di backend globali.

Bilanciatori del carico accessibili da regioni diverse.

Nel diagramma, tieni presente che nel servizio pubblicato è implementato un failover globale nell'ambiente del produttore. L'aggiunta del failover globale nell'ambiente consumer consente la resilienza agli errori regionali nell'infrastruttura di bilanciamento del carico consumer. Il failover del servizio tra regioni deve essere implementato sia nella logica dell'applicazione del servizio sia nella progettazione del bilanciamento del carico del producer di servizi. Il servizio può implementare altri meccanismi produttori.

Per determinare quale prodotto di Cloud Load Balancing utilizzare, devi prima determinare il tipo di traffico che i bilanciatori del carico devono gestire. Considera le le seguenti regole generali:

  • Utilizza un bilanciatore del carico delle applicazioni per il traffico HTTP(S).
  • Utilizza un bilanciatore del carico di rete proxy per il traffico TCP non HTTP(S). Questo bilanciatore del carico proxy supporta anche l'offload TLS.
  • Utilizza un bilanciatore del carico di rete passthrough per conservare l'indirizzo IP di origine del client nell'intestazione o per supportare protocolli aggiuntivi come UDP, ESP e ICMP.

Per indicazioni dettagliate sulla scelta del bilanciatore del carico più adatto al tuo caso d'uso, consulta Scegliere un carico Google Cloud.

Servizi con backend serverless

Un servizio può essere definito utilizzando backend serverless. Il backend nel producer può essere organizzato in un ambiente serverless NEG come backend per un bilanciatore del carico. Questo servizio può essere pubblicato utilizzando Private Service Connect mediante la creazione di un collegamento a un servizio associati al frontend del bilanciatore del carico del producer, L'elemento pubblicato il servizio può essere utilizzato tramite endpoint Private Service Connect Backend Private Service Connect. Se il servizio richiede connessioni avviate dal producer, puoi utilizzare un Accesso VPC serverless per consentire a Cloud Run, App Engine standard e Gli ambienti Cloud Functions inviano i pacchetti agli indirizzi IPv4 interni di in una rete VPC. L'accesso VPC serverless supporta anche l'invio di pacchetti ad altre reti connesse alla rete VPC selezionata.

Metodi per l'accesso privato ai servizi

La tua applicazione può essere costituita da servizi gestiti forniti da Google, di terze parti Servizi forniti da fornitori esterni o gruppi di app peer nella tua organizzazione. che il tuo team sviluppa. Alcuni di questi servizi potrebbero essere accessibili utilizzando indirizzi IP pubblici. Questa sezione descrive i metodi che puoi utilizzare possono utilizzare per accedere a questi servizi tramite la rete privata. Il seguente servizio tipi esistenti:

  • API pubbliche di Google
  • API serverless di Google
  • Pubblicazione di servizi gestiti di Google
  • Pubblicazione di servizi gestiti di fornitori e peer
  • I servizi che hai pubblicato

Tieni presenti queste opzioni quando leggi le sezioni successive. In base a come allocare i servizi, puoi utilizzare uno o più dei servizi di accesso le opzioni descritte.

L'organizzazione (o il gruppo all'interno di un'organizzazione) che assembla, pubblica e gestisce un servizio è detto producer di servizi. Tu e i tuoi per applicazioni sono definite consumer di servizi.

Alcuni servizi gestiti vengono pubblicati esclusivamente utilizzando servizi privati l'accesso alle app. Le progettazioni di rete consigliate in Connettività interna e VPC networking gestire i servizi pubblicati con accesso privato ai servizi Private Service Connect.

Per una panoramica delle opzioni per accedere ai servizi in privato, vedi Privato le opzioni di accesso per i servizi.

È consigliabile utilizzare Private Service Connect di connettersi ai servizi gestiti quando possibile. Per ulteriori informazioni per i pattern di deployment di Private Service Connect, Deployment di Private Service Connect modelli.

Esistono due tipi di Private Service Connect e i diversi possono essere pubblicati nei seguenti due tipi:

I servizi pubblicati come endpoint Private Service Connect possono essere consumato direttamente da altri carichi di lavoro. I servizi si basano sull'autenticazione di resilienza di cui il producer del servizio ha eseguito il provisioning. Se vuoi aggiungere di controllo sull'autenticazione e sulla resilienza del servizio, puoi utilizzare Backend di Private Service Connect per aggiungere un livello di bilanciamento del carico per l'autenticazione e la resilienza nella rete del consumatore.

Il seguente diagramma mostra i servizi a cui si accede tramite Endpoint Private Service Connect:

Accesso ai servizi tramite endpoint Private Service Connect.

Il diagramma mostra il seguente pattern:

  • Viene eseguito il deployment di un endpoint Private Service Connect nel consumer VPC, che rende disponibile il servizio producer per le VM nodi GKE.
  • Il deployment delle reti di consumatori e produttori deve avvenire nella stessa regione.

Il diagramma precedente mostra gli endpoint come risorse a livello di regione. Gli endpoint sono raggiungibile da altre regioni a causa della l'accesso alle app.

Per ulteriori informazioni sui pattern di deployment, consulta Deployment di Private Service Connect modelli.

I backend Private Service Connect utilizzano un bilanciatore del carico configurato con il gruppo di endpoint di rete (NEG) Private Service Connect di backend. Per un elenco dei bilanciatori del carico supportati, vedi Informazioni Private Service Connect di backend.

I backend Private Service Connect consentono di creare quanto segue configurazioni backend:

  • Domini e certificati di proprietà del cliente visibili ai servizi gestiti
  • Failover controllato dal consumatore tra servizi gestiti in diverse regioni
  • Configurazione di sicurezza e controllo dell'accesso centralizzati per i servizi gestiti

Nel diagramma seguente, il bilanciatore del carico globale utilizza una NEG Private Service Connect come backend che stabilisce la comunicazione con il provider di servizi. Non sono disponibili altre configurazioni di rete e i dati vengono trasferiti all'infrastruttura SDN di Google.

Bilanciatore del carico globale che utilizza un gruppo di endpoint di rete.

La maggior parte dei servizi è progettata per le connessioni avviate dal consumer. Quando i servizi devono avviare connessioni dal producer, usa Private Service Connect di archiviazione.

Un aspetto chiave da considerare quando si esegue il deployment dell'accesso privato ai servizi Private Service Connect è la transitività. I servizi pubblicati sono generalmente non raggiungibile tramite una connessione di peering di rete VPC o tramite Network Connectivity Center. La la posizione della subnet o degli endpoint di accesso al servizio nella topologia VPC sia che si progetta la rete per il deployment di servizi condivisi o dedicati.

Opzioni come VPN ad alta disponibilità e proxy gestiti dal cliente forniscono metodi per consentire le comunicazioni transitive tra VPC.

Gli endpoint di Private Service Connect non sono raggiungibili su peering di rete VPC. Se hai bisogno di questo tipo di connettività, esegui il deployment di un bilanciatore del carico interno e il NEG Private Service Connect come backend, come illustrato nel seguente diagramma:

Utilizzo dei NEG per fornire la connettività.

È possibile accedere alle API di Google in privato utilizzando Endpoint e backend Private Service Connect. L'uso degli endpoint è generalmente consigliato in quanto Google Il producer di API fornisce resilienza e autenticazione basata su certificati.

crea un endpoint Private Service Connect in ogni VPC in cui è necessario accedere al servizio. Poiché l'indirizzo IP consumer è un indirizzo globale privato indirizzo IP, è necessaria una singola mappatura DNS per ogni servizio, anche se ci sono di istanze di endpoint in più VPC, come illustrato nelle diagramma:

Private Service Connect con le API di Google.

Definisci i pattern di consumo dei servizi

I servizi possono essere eseguiti in diverse località: sulla rete VPC, su un altro VPC in un data center on-premise o nel cloud. Indipendentemente da dove dei carichi di lavoro di servizio, l'applicazione consuma quei servizi tramite di accesso rapido, ad esempio uno dei seguenti:

  • Un indirizzo IP in una subnet di accesso privato ai servizi
  • Un endpoint Private Service Connect
  • Un VIP per un bilanciatore del carico che utilizza i NEG Private Service Connect

I punti di accesso per i consumatori possono essere condivisi tra reti o dedicati a un un'unica rete. Decidi se creare un accesso consumer condiviso o dedicato punti in base al fatto che la tua organizzazione deleghi o meno l'attività di creazione del servizio consumer a ogni gruppo di applicazioni o gestisce l'accesso ai servizi in modo consolidato.

La gestione dell'accesso ai servizi riguarda le seguenti attività:

  • Creazione dei punti di accesso
  • Deployment dei punti di accesso in un VPC che ha il tipo appropriato di raggiungibilità
  • Registrazione dei punti di accesso consumer Indirizzi IP e URL in DNS
  • La gestione dei certificati di sicurezza e della resilienza per il servizio nel consumer spazio, quando si aggiunge il bilanciamento del carico davanti all'accesso consumer punti

Per alcune organizzazioni, potrebbe essere opportuno assegnare la gestione dell'accesso ai servizi a un di marketing, mentre altri potrebbero essere strutturati per dare una maggiore indipendenza a ciascun consumatore o dal team addetto all'applicazione. Un sottoprodotto del funzionamento in modalità dedicata è che degli elementi vengono replicati. Ad esempio, se un servizio è registrato con più nomi DNS per ogni gruppo di applicazioni e gestisce più set di certificati TLS.

La struttura del VPC descritta in Segmentazione della rete e per le applicazioni distribuite Rete cross-cloud consente la connettività per il deployment di punti di accesso ai servizi in un ambiente modalità dedicata. Il deployment dei punti di accesso consumer condivisi viene eseguito nel servizio VPC a cui è possibile accedere da qualsiasi altro VPC rete esterna. Nell'applicazione viene eseguito il deployment di punti di accesso consumer dedicati VPC, a cui è possibile accedere solo dalle risorse al suo interno VPC dell'applicazione.

La differenza principale tra un servizio e il VPC di un'applicazione è l'accesso al servizio una connettività transitiva puntiforme abilitata da un VPC di servizio. Servizio I VPC non sono limitati all'hosting di punti di accesso consumer. R Il VPC può ospitare sia le risorse delle applicazioni, sia e punti di accesso. In questo caso, il VPC deve essere configurato gestito come servizio in un VPC.

Accesso condiviso ai servizi gestiti

Per tutti i metodi di consumo dei servizi, tra cui Private Service Connect, assicurati di eseguire le seguenti attività:

  • Esegui il deployment dei punti di accesso consumer dei servizi in un VPC dei servizi. VPC di servizio hanno la connettività transitiva ad altri VPC.
  • Pubblicizza la subnet per il punto di accesso consumer come route personalizzata pubblicità dal router Cloud che esegue il peering ad altre reti tramite VPN ad alta disponibilità. Per Google API, pubblicizzano l'indirizzo IP host dell'API.
  • Aggiorna le regole firewall multi-cloud per consentire alla subnet di accesso privato ai servizi.

In particolare per l'accesso privato ai servizi, assicurati di poter soddisfare le i seguenti requisiti aggiuntivi:

  • Esporta route personalizzate nella rete del producer di servizi. Per ulteriori informazioni, vedi Gli host on-premise non riescono a comunicare con
  • Crea regole firewall in entrata per consentire alla subnet di accesso privato ai servizi i VPC dell'applicazione
  • Crea regole firewall in entrata per consentire alla subnet di accesso privato ai servizi il VPC dei servizi

Per l'accesso ai servizi serverless, assicurati di poter soddisfare quanto segue requisiti:

  • Il connettore di accesso richiede una subnet standard /28 dedicata
  • Il router Cloud pubblicizza subnet normali per impostazione predefinita
  • Crea regole firewall in entrata per consentire a tutte le subnet di accesso VPC all'interno dei VPC
  • Aggiorna le regole firewall multi-cloud per consentire la subnet del connettore di accesso VPC
  • Crea regole firewall in entrata per consentire alla subnet di accesso privato ai servizi nei VPC dell'applicazione

Accesso ai servizi gestiti dedicato

Esegui le seguenti attività:

  • In ogni VPC di applicazione in cui l'accesso è necessario, esegui il deployment di una regola di forwarding affinché il servizio crei un accesso punto di accesso.
  • Per l'accesso privato ai servizi, crea regole firewall in entrata per consentire una subnet di accesso privato ai servizi nei VPC delle applicazioni.

Per l'accesso ai servizi serverless, assicurati di poter soddisfare quanto segue requisiti:

  • Il connettore di accesso richiede una subnet standard /28 dedicata
  • Crea regole firewall in entrata per consentire la subnet del connettore di accesso VPC all'interno dei VPC dell'applicazione

Assembla lo stack di applicazioni

Questa sezione descrive l'assemblaggio di uno stack di applicazioni a livello di regione o globale.

Progetta stack di applicazioni a livello di regione

Quando un'applicazione segue il deployment a livello di una o più regioni gli archetipi, usa gli stack di applicazioni regionali. Gli stack di applicazioni a livello di regione è pensato come una concatenazione di livelli di servizio delle applicazioni a livello di regione. Per ad esempio un livello del servizio web a livello di regione che interagisce con un livello dell'applicazione nella stessa regione, che a sua volta comunica con un livello di database nella stessa regione, e lo stack di applicazioni a livello di regione.

Ogni livello di servizio delle applicazioni a livello di regione utilizza bilanciatori del carico per distribuire il traffico attraverso gli endpoint del livello in quella regione. L'affidabilità è ottenuto mediante la distribuzione delle risorse di backend in tre o più zone regione.

Livelli di servizio delle applicazioni in altri CSP o dati on-premise center deve essere implementato in regioni equivalenti nelle reti esterne. Inoltre, rende disponibili i servizi pubblicati nella regione dello stack. Per allineare lo stack di applicazioni all'interno di una regione, gli URL del livello di servizio dell'applicazione nello specifico indirizzo IP a livello di regione frontend del bilanciatore del carico. Questi DNS vengono registrate nella zona DNS pertinente per ogni servizio dell'applicazione.

Il seguente diagramma mostra uno stack regionale con resilienza in standby attivo:

Stack regionale con resilienza in standby attivo.

Viene eseguito il deployment di un'istanza completa dello stack di applicazioni in ogni regione tra i diversi data center del cloud. Quando si verifica un errore a livello di regione in uno qualsiasi dei per i livelli di servizio delle applicazioni, lo stack nell'altra regione prende in carico la dell'intera applicazione. Questo failover viene eseguito in risposta il monitoraggio dei diversi livelli di servizio delle applicazioni.

Quando un errore viene per uno dei livelli di servizio, il frontend dell'applicazione di nuovo ancorate allo stack di backup. L'applicazione è scritta per fare riferimento a un insieme di record dei nomi regionali che riflettono lo stack di indirizzi IP a livello di regione in DNS, in modo che dell'applicazione mantiene le proprie connessioni all'interno della stessa regione.

Progetta stack di applicazioni globali

Quando un'applicazione segue l'archetipo di deployment globale delle applicazioni, ogni e include backend in più regioni. L'inclusione dei backend in più regioni espande il pool di resilienza per il livello di servizio dell'applicazione oltre una singola regione consente il rilevamento e la riconvergenza automatici del failover.

Il seguente diagramma mostra uno stack di applicazioni globale:

Stack globale utilizzando un progetto hub e un progetto applicazione.

Il diagramma precedente mostra un'applicazione globale assemblata dai seguenti componenti:

  • Servizi in esecuzione in data center on-premise con frontend dei bilanciatori del carico. La i punti di accesso del bilanciatore del carico sono raggiungibili tramite Cloud Interconnect VPC di transito.
  • Un VPC di transito ospita connessioni ibride un data center esterno e il VPC dell'applicazione.
  • Un VPC dell'applicazione che ospita l'applicazione principale in esecuzione sul carico di lavoro di Compute Engine. Queste istanze dei carichi di lavoro sono dietro ai bilanciatori del carico. Il carico i bilanciatori sono raggiungibili da qualsiasi regione della rete e possono raggiungere in qualsiasi regione della rete.
  • Un VPC di servizi che ospita punti di accesso per servizi in esecuzione in altri ad esempio in VPC di terze parti. Questi punti di accesso ai servizi raggiungibile tramite la connessione VPN ad alta disponibilità tra il VPC dei servizi e VPC di transito.
  • VPC dei producer di servizi ospitati da altre organizzazioni o sia l'organizzazione principale sia le applicazioni eseguite in altre località. I contenuti pertinenti sono resi raggiungibili dai backend Private Service Connect il cui deployment viene eseguito come backend globali su bilanciatori del carico regionali VPC di servizi Google Cloud. I bilanciatori del carico a livello di regione sono raggiungibili da qualsiasi altra regione.

Se vuoi che l'applicazione creata sia raggiungibile da internet, puoi Aggiungi un bilanciatore del carico delle applicazioni esterno globale che punta ai carichi di lavoro dell'applicazione nel VPC dell'applicazione (non illustrato nel diagramma).

Per supportare uno stack di applicazioni globale, abbiamo utilizzato backend globali per ogni livello di applicazione. Ciò consente il ripristino da un errore di tutti gli endpoint di backend in una regione. Ogni regione ha un frontend del bilanciatore del carico a livello di regione il livello di servizio dell'applicazione. Quando si verifica un failover a livello di regione, viene generato i frontend dei bilanciatori del carico possono essere raggiunti in più regioni, perché usano access. Poiché lo stack di applicazioni è globale, il routing di geolocalizzazione DNS norme vengono utilizzati per selezionare il frontend regionale più appropriato per una una richiesta o un flusso di lavoro. In caso di errore del frontend, integrità DNS controlli può essere usato per automatizzare il failover da un frontend all'altro.

Servizi pubblicati utilizzando i backend Private Service Connect sfrutta i vantaggi di Private Service Connect Global l'accesso alle app. Questa funzione consente Backend di Private Service Connect raggiungibile da qualsiasi regione riduce le interruzioni dovute a errori del livello di servizio delle applicazioni. Questo significa che i backend Private Service Connect possono essere utilizzati backend globali come descritto in Determinazione dell'ambito del servizio - a livello di regione o globale.

Fornisci accesso privato ai servizi ospitati in reti esterne

Potresti voler pubblicare un punto di accesso locale per un servizio ospitato in un altro in ogni rete. In questi casi, puoi utilizzare un carico proxy TCP regionale interno bilanciatore del carico utilizzando NEG ibridi. Puoi creare un servizio ospitato on-premise o in disponibili per i client nella tua rete VPC, come come mostrato nel seguente diagramma:

Punto di accesso locale che utilizza NEG ibridi.

Se vuoi rendere il servizio ibrido disponibile in una rete VPC diversa dalla rete VPC uno che ospita il bilanciatore del carico, puoi utilizzare Private Service Connect per pubblicare Google Cloud. Posizionando un collegamento a un servizio davanti al proxy TCP regionale interno puoi consentire ai client in altre reti VPC di raggiungere la rete in esecuzione on-premise o in altri ambienti cloud.

In un ambiente cross-cloud, l'uso di un NEG ibrido consente la comunicazione tra applicazioni.

Quando un'altra organizzazione pubblica un servizio dell'applicazione, usa un NEG ibrido per estendere le astrazioni dell'accesso privato per quel servizio. La il seguente diagramma illustra questo scenario:

NEG ibridi davanti ai servizi in altre reti.

Nel diagramma precedente, il livello di servizio dell'applicazione è completamente composto vicino CSP, che è evidenziato nelle parti del diagramma che non sono non è selezionabile. I bilanciatori del carico ibridi vengono utilizzati insieme Collegamenti di servizio Private Service Connect come meccanismo pubblicare il servizio dell'applicazione esterna per il consumo privato all'interno in Google Cloud. I bilanciatori del carico ibridi con NEG ibridi I collegamenti di servizio Private Service Connect si trovano in un VPC che fanno parte di un progetto di producer di servizi. Questo progetto di producer di servizi di solito potrebbe essere un VPC diverso VPC di transito, perché rientra nell'ambito amministrativo del producer organizzazione o progetto, quindi separati dai sistemi di trasporto i servizi di machine learning. Il VPC del producer non deve essere connesso tramite VPC o HA-VPN con il VPC consumer (ovvero la rete VPC VPC condiviso nel diagramma).

Centralizza l'accesso ai servizi

L'accesso ai servizi può essere centralizzato in una rete VPC e accedervi da altre reti di applicazioni. Il seguente diagramma mostra il pattern comune che consente la centralizzazione dei punti di accesso:

VPC di servizi dedicati.

Il seguente diagramma mostra tutti i servizi a cui si accede da un VPC di servizi dedicati:

VPC di servizi dedicati con bilanciatori del carico centralizzati.

Quando i servizi hanno un frontend con bilanciatori del carico delle applicazioni, puoi consolidare su meno bilanciatori del carico utilizzando le mappe URL per indirizzare il traffico per backend di servizio diversi invece di utilizzare bilanciatori del carico diversi per ogni servizio. In linea di principio, uno stack di applicazioni può essere composto completamente usando un unico bilanciatore del carico delle applicazioni, più backend di servizio e mapping di URL appropriati.

In questa implementazione, devi utilizzare NEG ibridi tra i VPC per la maggior parte dei backend di testo. L'eccezione è un NEG Private Service Connect come descritto in Concatenamento esplicito dei bilanciatori del carico Google Cloud L7 con Private Service Connect.

L'uso di NEG ibridi nei VPC va a scapito di quanto precede e scalabilità automatica per i backend. I servizi pubblicati hanno già da un bilanciatore del carico nel tenant del producer che fornisce la scalabilità automatica. Pertanto, le limitazioni dei NEG ibridi centralizzare la funzione di bilanciamento del carico per i livelli di servizio che vengono composti in modo nativo invece che consumato dalla pubblicazione.

Quando utilizzi questo pattern di rete di servizi, ricorda che i servizi consumate tramite un ulteriore livello di bilanciamento del carico.

Utilizza il bilanciamento del carico del proxy per ottenere i vantaggi di scalabilità del VPC dello spoke di Network Connectivity Center tra più VPC, fornendo al contempo connettività transitiva ai tramite i bilanciatori del carico proxy.

Endpoint di servizio Private Service Connect e regole di forwarding per il servizio privato non sono raggiungibili nei VPC dello spoke di Network Connectivity Center. Analogamente, le reti dietro connessioni ibride (Cloud Interconnect o HA-VPN) non sono raggiungibile nei VPC spoke di Network Connectivity Center poiché le route dinamiche non vengono propagate Network Connectivity Center.

Questa mancanza di transitività può essere aggirata eseguendo il deployment di bilanciatori del carico proxy con le risorse non transitive gestite come NEG ibridi. Possiamo quindi eseguire il deployment i bilanciatori del carico proxy davanti ai frontend del servizio e carichi di lavoro raggiungibili tra le connessioni ibride.

Il deployment dei frontend proxy del bilanciatore del carico viene eseguito nelle subnet VPC che vengono propagate nei VPC spoke di Network Connectivity Center. Questa propagazione consente la connettività nel Network Connectivity Center delle risorse non transitive attraverso il proxy bilanciatori del carico.

La modalità centralizzata aggiunge un livello di bilanciamento del carico sul lato consumer completamente gestito di Google Cloud. Quando utilizzi questa modalità, devi gestire anche i certificati, resilienza e ulteriori mappature DNS nel progetto consumer.

Altre considerazioni

Questa sezione contiene considerazioni relative a prodotti e servizi comuni non esplicitamente trattati in questo documento.

Considerazioni sul piano di controllo GKE

Il deployment del piano di controllo GKE viene eseguito in una progetto tenant collegato al VPC del cliente tramite peering di rete VPC. Poiché Il peering di rete VPC non è una comunicazione transitiva e diretta con il piano di controllo su una la topologia di rete in peering VPC hub e spoke non è possibile.

Quando valuti le opzioni di progettazione di GKE, come l'accesso diretto e decentralizzato al piano di controllo da origini multi-cloud è una considerazione chiave. Se il deployment di GKE viene eseguito in un VPC centralizzato, l'accesso al piano di controllo è disponibile tra i cloud e all'interno in Google Cloud. Tuttavia, se il deployment di GKE viene eseguito in VPC decentralizzati, la comunicazione diretta con il piano di controllo non è possibile. Se i requisiti di un'organizzazione richiedono l'accesso ai il piano di controllo GKE oltre ad adottare la strategia di progettazione, gli amministratori di rete possono implementare un che agisce da proxy, superando così la limitazione del peering non transitivo il piano di controllo GKE.

Sicurezza - Controlli di servizio VPC

Per i carichi di lavoro che coinvolgono dati sensibili, utilizza Controlli di servizio VPC per configurare i perimetri di servizio attorno alle tue risorse VPC e servizi e controllare il movimento dei dati attraverso il confine del perimetro. Utilizzo Controlli di servizio VPC, puoi raggruppare i progetti e la rete on-premise in un unico perimetro che impedisce l'accesso ai dati attraverso i servizi di machine learning. Controlli di servizio VPC in entrata e in uscita regole può essere utilizzata per consentire a progetti e servizi in perimetri di servizio diversi per comunicare (incluse le reti VPC che non sono perimetrale).

Per le architetture di deployment consigliate, un processo di onboarding completo, e operative, consulta le best practice per Controlli di servizio VPC per imprese e Nozioni di base sulla sicurezza Schema.

DNS per API/servizi

I producer di servizi possono pubblicare servizi utilizzando Private Service Connect. Facoltativamente, il producer di servizi può configurare un nome di dominio DNS da associare. con il servizio. Se è configurato un nome di dominio e un consumer di servizi crea un endpoint che ha come target , Private Service Connect e Service Directory crea automaticamente le voci DNS per il servizio in una zona DNS privata nel alla rete VPC del consumer di servizi.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: