Networking dei servizi per le applicazioni distribuite in Cross-Cloud Network

Last reviewed 2025-01-30 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 servizi componenti scelti o creati. Ti consigliamo di leggere l'intero documento una volta prima di seguire i passaggi.

Questo documento ti guida nelle seguenti decisioni:

  • Sia che crei personalmente il servizio o utilizzi un 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 nessuno dei due
  • Sia che si acceda all'endpoint di servizio tramite un VPC di servizi condivisi sia che si distribuiscano gli endpoint

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 i tuoi servizi
  3. Configurazione dell'accesso privato agli endpoint di servizio utilizzando una modalità condivisa o dedicata
  4. Assemblaggio dei servizi in applicazioni per corrispondere a un archetipo globale o regionale

Gli sviluppatori definiscono il livello di networking dei servizi per la rete cross-cloud. In questa fase, gli amministratori hanno progettato un livello di connettività per la rete Cross-Cloud che consente la flessibilità delle opzioni di networking dei servizi descritte in questo documento. In alcuni casi, esistono vincoli di transitività tra VPC limitata. 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 un archetipo di deployment regionale o globale. Puoi ottenere la resilienza a livello regionale distribuendo i carichi tra le zone. Puoi ottenere la resilienza globale distribuendo 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, vedi Google Cloud archetipi di deployment.

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

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

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

Stack di applicazioni globali distribuito tra i cloud.

Definire e accedere ai servizi per le applicazioni

Per assemblare l'applicazione, puoi utilizzare servizi gestiti di terze parti esistenti, creare e ospitare i tuoi servizi per le applicazioni o utilizzare una combinazione di entrambi.

Utilizzare servizi gestiti di terze parti esistenti

Decidi quali servizi gestiti di terze parti puoi utilizzare per la tua applicazione. Stabilisci quali vengono creati come servizi regionali o globali. Inoltre, determina le opzioni di accesso privato supportate da ciascun servizio.

Una volta stabilito quali servizi gestiti puoi utilizzare, puoi determinare quali servizi devi creare.

Crea e accedi ai servizi per le applicazioni

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

Il pattern generale per un servizio dell'applicazione è mostrato nel seguente diagramma. Il deployment del servizio applicazioni viene eseguito in una raccolta di istanze dei carichi di lavoro. In questo caso, un'istanza di un carico di lavoro potrebbe essere una VM di Compute Engine, un cluster Google Kubernetes Engine (GKE) o un altro backend che esegue il codice. Le istanze del carico di lavoro sono organizzate come un insieme 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 gruppi di istanze gestite, puoi aumentare o diminuire elasticamente la capacità del servizio mediante la scalabilità automatica degli endpoint che formano il backend del bilanciatore del carico. Inoltre, a seconda dei requisiti del servizio dell'applicazione, il bilanciatore del carico può anche fornire autenticazione, terminazione TLS e altri servizi specifici della 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 applicazioni globale può supportare failover sincroni tra nodi distribuiti in più regioni. Se la tua applicazione è globale, potresti volere che anche i servizi che la supportano siano globali. Tuttavia, 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 dover fare affidamento su servizi regionali con ridondanza nella stessa regione o nelle regioni vicine, supportando quindi una 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 un livello globale rivolto ai clienti in grado di interagire con livelli di servizio globali, regionali o ibridi. Scegli i deployment dei servizi per assicurarti che il failover dinamico della rete (o il bilanciamento del carico tra regioni) sia in linea con lo stato di resilienza e le capacità della logica dell'applicazione.

Il seguente diagramma mostra in che modo un servizio globale creato da bilanciatori del carico regionali può raggiungere i backend in altre regioni, fornendo così il failover automatico tra regioni. In questo esempio, la logica dell'applicazione è globale e il backend scelto supporta la sincronizzazione tra regioni. Ogni bilanciatore del carico invia principalmente richieste alla regione locale, ma può eseguire il failover in regioni remote.

Bilanciatori del carico con backend in regioni diverse.

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

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

Bilanciatori del carico accessibili da regioni diverse.

Nel diagramma, tieni presente che il servizio pubblicato ha un failover globale implementato nell'ambiente producer. 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. Altri meccanismi possono essere implementati dai producer di servizi.

Per determinare quale prodotto di Cloud Load Balancing utilizzare, devi innanzitutto determinare il tipo di traffico che i bilanciatori del carico devono gestire. Tieni presente 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 bilanciatore del carico.

Servizi con backend serverless

Un servizio può essere definito utilizzando backend serverless. Il backend nell'ambiente del producer può essere organizzato in un NEG serverless come backend per un bilanciatore del carico. Questo servizio può essere pubblicato utilizzando Private Service Connect creando un collegamento al servizio associato al frontend del bilanciatore del carico del producer. Il servizio pubblicato può essere utilizzato tramite endpoint Private Service Connect o backend Private Service Connect. Se il servizio richiede connessioni avviate dal producer, puoi utilizzare un connettore di accesso VPC serverless per consentire agli ambienti Cloud Run, standard App Engine e Cloud Run di inviare pacchetti agli indirizzi IPv4 interni delle risorse 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, servizi di terze parti forniti da fornitori esterni o gruppi di app peer nella tua organizzazione e servizi sviluppati dal tuo team. Alcuni di questi servizi potrebbero essere accessibili su internet tramite indirizzi IP pubblici. Questa sezione descrive i metodi che puoi utilizzare per accedere a questi servizi tramite la rete privata. Esistono i seguenti tipi di servizio:

  • 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. A seconda di come assegni i servizi, puoi utilizzare una o più delle opzioni di accesso privato descritte.

L'organizzazione (o il gruppo all'interno di un'organizzazione) che assembla, pubblica e gestisce un servizio è definita producer di servizi. Tu e la tua applicazione siete definiti consumer di servizi.

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

Per una panoramica delle opzioni per accedere ai servizi privatamente, vedi Opzioni di accesso privato per i servizi.

Ti consigliamo di utilizzare Private Service Connect per connetterti ai servizi gestiti quando possibile. Per ulteriori informazioni sui pattern di deployment per Private Service Connect, consulta Pattern di deployment di Private Service Connect.

Esistono due tipi di Private Service Connect e i diversi servizi possono essere pubblicati in entrambi i tipi:

I servizi pubblicati come endpoint Private Service Connect possono essere utilizzati direttamente da altri carichi di lavoro. I servizi si basano sull'autenticazione e sulla resilienza fornite dal producer del servizio. Se vuoi controllare ulteriormente l'autenticazione e la resilienza dei servizi, puoi utilizzare i backend Private Service Connect per aggiungere un livello di bilanciamento del carico per l'autenticazione e la resilienza nella rete consumer.

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

Accesso ai servizi tramite endpoint Private Service Connect.

Il diagramma mostra il seguente pattern:

  • Nel VPC consumer viene eseguito il deployment di un endpoint Private Service Connect, che rende il servizio producer disponibile per le VM e i 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 raggiungibili da altre regioni grazie all'accesso globale.

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

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

I backend Private Service Connect consentono di creare le seguenti configurazioni di 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 un NEG Private Service Connect come backend che stabilisce la comunicazione con il provider di servizi. Non sono necessarie ulteriori configurazioni di rete e i dati vengono trasferiti nell'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, utilizza le interfacce Private Service Connect.

Una considerazione fondamentale quando si esegue il deployment dell'accesso privato ai servizi o di Private Service Connect è la transitività. I punti di accesso consumer Private Service Connect sono raggiungibili tramite il Network Connectivity Center. I servizi pubblicati non sono raggiungibili tramite una connessione di peering di rete VPC per Private Service Connect o per l'accesso di servizi privati ai punti di accesso consumer. In assenza di transitività tra VPC per tutti i punti di accesso dei consumer di servizi, la posizione della subnet o degli endpoint di accesso al servizio nella topologia VPC determina se progetti la rete per il deployment di servizi condivisi o dedicati.

Opzioni come la VPN ad alta disponibilità e i proxy gestiti dal cliente offrono metodi per consentire la comunicazione transitiva tra VPC.

Gli endpoint di Private Service Connect non sono raggiungibili sul peering di rete VPC. Se hai bisogno di questo tipo di connettività, esegui il deployment di un bilanciatore del carico interno e di un NEG Private Service Connect come backend, come mostrato 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. In genere si consiglia di usare gli endpoint, in quanto il producer di API di Google offre resilienza e autenticazione basata su certificati.

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

Private Service Connect con le API di Google.

Definisci i modelli di consumo per i servizi pubblicati

I servizi pubblicati possono essere eseguiti in diverse località: sulla tua rete VPC, su un'altra rete VPC, in un data center on-premise o nel cloud. Indipendentemente da dove viene eseguito il carico di lavoro del servizio, l'applicazione utilizza questi servizi utilizzando un punto di accesso, 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 consumer possono essere condivisi tra reti o dedicati a una singola rete. Decidi se creare punti di accesso consumer condivisi o dedicati a seconda che la tua organizzazione deleghi l'attività di creazione dei punti di accesso dei servizi consumer a ciascun gruppo di applicazioni o gestisca l'accesso ai servizi in modo consolidato.

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

  • Creazione dei punti di accesso
  • Il deployment dei punti di accesso in un VPC di accesso ai servizi, è un VPC
  • Registrazione degli indirizzi IP e degli URL dei punti di accesso consumer nel DNS
  • Gestione dei certificati di sicurezza e della resilienza per il servizio nello spazio consumer, durante l'aggiunta del bilanciamento del carico davanti ai punti di accesso del consumer

Per alcune organizzazioni, potrebbe essere possibile assegnare la gestione dell'accesso ai servizi a un team centrale, mentre altre potrebbero essere strutturate in modo da dare maggiore indipendenza a ciascun consumatore o team dedicato alle applicazioni. Un sottoprodotto del funzionamento in modalità dedicata è che alcuni elementi vengono replicati. Ad esempio, un servizio viene registrato con più nomi DNS per ogni gruppo di applicazioni e gestisce più set di certificati TLS.

La progettazione del VPC descritta in Segmentazione e connettività della rete per applicazioni distribuite in Cross-Cloud Network consente la connettività per il deployment di punti di accesso ai servizi in modalità condivisa o dedicata. Il deployment dei punti di accesso consumer condivisi viene eseguito nei VPC di accesso ai servizi, a cui è possibile accedere da qualsiasi altra rete VPC o esterna. Nei VPC delle applicazioni viene eseguito il deployment di punti di accesso consumer dedicati, a cui è possibile accedere solo dalle risorse all'interno del VPC dell'applicazione.

La differenza principale tra un VPC di accesso al servizio e un VPC di applicazione è la connettività transitiva del punto di accesso al servizio abilitata da un VPC di accesso ai servizi. I VPC di accesso al servizio non sono limitati all'hosting di punti di accesso consumer. Un VPC può ospitare risorse delle applicazioni e punti di accesso consumer condivisi. In tal caso, il VPC deve essere configurato e gestito come VPC di servizio.

Accesso condiviso ai servizi gestiti

Per tutti i metodi di utilizzo dei servizi, incluso Private Service Connect, assicurati di eseguire le seguenti attività:

  • Esegui il deployment dei punti di accesso consumer dei servizi in un VPC dei servizi. I VPC di servizio hanno la connettività transitiva ad altri VPC.
  • Se il VPC di accesso al servizio è connesso con la VPN ad alta disponibilità, pubblicizza la subnet per il punto di accesso consumer come pubblicità di route personalizzata dal router Cloud che esegue il peering ad altre reti tramite VPN ad alta disponibilità. Per le API di Google, pubblicizza 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 i seguenti requisiti aggiuntivi:

  • Esporta route personalizzate nella rete del producer di servizi. Per ulteriori informazioni, consulta Gli host on-premise non possono comunicare con la rete del producer di servizi.
  • Creare regole firewall in entrata per consentire alla subnet di accesso privato ai servizi nei VPC dell'applicazione
  • Creare regole firewall in entrata per consentire alla subnet di accesso privato ai servizi nel VPC dei servizi

Per l'accesso ai servizi serverless, assicurati di poter soddisfare i seguenti requisiti:

  • Il connettore di accesso richiede una subnet normale /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
  • Creare 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à:

  • Nel VPC di ogni applicazione in cui è necessario l'accesso, esegui il deployment di una regola di forwarding per il servizio per creare un punto di accesso.
  • Per l'accesso privato ai servizi, crea regole firewall in entrata per consentire alla subnet di accesso privato ai servizi nei VPC dell'applicazione.

Per l'accesso ai servizi serverless, assicurati di poter soddisfare i seguenti requisiti:

  • Il connettore di accesso richiede una subnet normale /28 dedicata
  • Creare 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 gli archetipi di deployment regionali o multiregionali, usa gli stack di applicazioni a livello di regione. Gli stack di applicazioni a livello di regione possono essere considerati come una concatenazione di livelli di servizio delle applicazioni a livello di regione. Ad esempio, un livello del servizio web a livello di regione che comunica con un livello di applicazione nella stessa regione, che a sua volta comunica con un livello di database nella stessa regione, è uno 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 tra gli endpoint del livello nella regione. L'affidabilità si ottiene distribuendo le risorse di backend in tre o più zone della regione.

I livelli di servizio delle applicazioni in altri CSP o data center on-premise devono essere distribuiti in regioni equivalenti nelle reti esterne. Inoltre, rendi disponibili i servizi pubblicati nella regione dello stack. Per allineare lo stack delle applicazioni all'interno di una regione, gli URL del livello di servizio dell'applicazione devono essere risolti all'indirizzo IP regionale frontend del bilanciatore del carico specifico. Queste mappature DNS sono 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.

In ogni regione viene eseguito il deployment di un'istanza completa dello stack di applicazioni nei diversi data center cloud. Quando si verifica un errore a livello di regione in uno qualsiasi dei livelli di servizio delle applicazioni, lo stack nell'altra regione prende in carico la distribuzione dell'intera applicazione. Il failover viene eseguito in risposta al monitoraggio fuori banda dei diversi livelli di servizio delle applicazioni.

Quando viene segnalato un errore per uno dei livelli di servizio, il frontend dell'applicazione viene nuovamente ancorato allo stack di backup. L'applicazione viene scritta per fare riferimento a un insieme di record di nomi regionali che riflettono lo stack di indirizzi IP a livello di regione in DNS, in modo che ogni livello dell'applicazione mantenga 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 livello di servizio delle applicazioni include backend in più regioni. L'inclusione di backend in più regioni espande il pool di resilienza per il livello di servizio delle applicazioni oltre una singola regione e 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 dell'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. I punti di accesso del bilanciatore del carico sono raggiungibili tramite Cloud Interconnect dal VPC di transito.
  • Un VPC di transito ospita connessioni ibride tra il data center esterno e il VPC dell'applicazione.
  • Un VPC dell'applicazione che ospita l'applicazione principale in esecuzione sulle istanze dei carichi di lavoro. Queste istanze dei carichi di lavoro sono dietro ai bilanciatori del carico. I bilanciatori del carico sono raggiungibili da qualsiasi regione della rete e possono raggiungere i backend in qualsiasi regione della rete.
  • Un VPC di servizi che ospita punti di accesso per servizi in esecuzione in altre località, ad esempio in VPC di terze parti. Questi punti di accesso ai servizi sono raggiungibili tramite la connessione VPN ad alta disponibilità tra il VPC dei servizi e il VPC di transito.
  • VPC dei producer di servizi ospitati da altre organizzazioni o dall'organizzazione principale e da applicazioni in esecuzione in altre località. I servizi pertinenti sono raggiungibili dai backend Private Service Connect di cui è stato eseguito il deployment come backend globali sui bilanciatori del carico a livello di regione ospitati nel VPC dei servizi. 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 aggiungere un bilanciatore del carico delle applicazioni esterno globale che punti ai carichi di lavoro dell'applicazione nel VPC dell'applicazione (non mostrato 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 per ogni livello di servizio delle applicazioni. Quando si verifica un failover a livello di regione, i frontend dei bilanciatori del carico a livello di regione interni possono essere raggiunti in più regioni, perché usano l'accesso globale. Poiché lo stack delle applicazioni è globale, i criteri di routing della geolocalizzazione DNS vengono utilizzati per selezionare il frontend regionale più appropriato per una determinata richiesta o flusso. In caso di errore del frontend, è possibile utilizzare i controlli di integrità DNS per automatizzare il failover da un frontend all'altro.

I servizi pubblicati utilizzando i backend Private Service Connect usufruiscono dell'accesso globale a Private Service Connect. Questa funzionalità consente a un backend Private Service Connect di essere raggiungibile da qualsiasi regione e riduce le interruzioni dovute a errori del livello di servizio dell'applicazione. Ciò significa che i backend Private Service Connect possono essere utilizzati come 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'altra rete. In questi casi, puoi utilizzare un bilanciatore del carico proxy TCP regionale interno con NEG ibridi. Puoi creare un producer di servizi ospitato on-premise o in altri ambienti cloud a disposizione dei consumer di servizi (client) nella rete VPC, come illustrato nel diagramma seguente:

Punto di accesso locale che utilizza NEG ibridi.

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

In un ambiente cross-cloud, l'uso di un NEG ibrido consente una comunicazione sicura 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. 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 nel CSP vicino, che è evidenziato nelle parti del diagramma non in grigio. I bilanciatori del carico ibridi vengono utilizzati insieme ai collegamenti del servizio Private Service Connect come meccanismo per pubblicare il servizio delle applicazioni esterne per il consumo privato all'interno diGoogle Cloud. I bilanciatori del carico ibridi con NEG ibridi e collegamenti di servizio Private Service Connect si trovano in un VPC che fa parte del progetto di un producer di servizi. Questo progetto del producer di servizi di solito potrebbe essere un VPC diverso dal VPC di transito, perché rientra nell'ambito amministrativo dell'organizzazione o del progetto del producer e quindi separato dai servizi di transito comuni. Il VPC del producer non deve essere connesso tramite peering VPC o VPN ad alta disponibilità con il VPC consumer (che è il VPC condiviso dei servizi nel diagramma).

Centralizza l'accesso ai servizi

L'accesso ai servizi può essere centralizzato in una rete VPC e accessibile 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 bilanciatori del carico delle applicazioni come frontend, puoi eseguire il consolidamento 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 ciascun servizio. In linea di principio, uno stack di applicazioni può essere completamente composto utilizzando un singolo bilanciatore del carico dell'applicazione, più backend di servizio e mapping di URL appropriati.

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

L'uso di NEG ibridi nei VPC comporta rinunciare alla riparazione automatica e alla scalabilità automatica dei backend. I servizi pubblicati hanno già un bilanciatore del carico nel tenant del producer che fornisce scalabilità automatica. Di conseguenza, incontrerai le limitazioni dei NEG ibridi solo se centralizza la funzione di bilanciamento del carico per i livelli di servizio composti in modo nativo che non vengono utilizzati dalla pubblicazione.

Quando utilizzi questo pattern di networking del servizio, ricorda che i servizi vengono utilizzati tramite un ulteriore livello di bilanciamento del carico.

Gli endpoint di servizio Private Service Connect sono raggiungibili nei VPC dello spoke di Network Connectivity Center.

La modalità centralizzata aggiunge un livello di bilanciamento del carico sul lato consumer del servizio. Quando utilizzi questa modalità, devi anche gestire i certificati, la resilienza e le mappature DNS aggiuntive nel progetto consumer.

Altre considerazioni

Questa sezione contiene considerazioni relative a prodotti e servizi comuni non esplicitamente trattati nel presente documento.

Considerazioni sul piano di controllo GKE

Il deployment del piano di controllo GKE viene eseguito in un progetto tenant gestito da Google connesso al VPC del cliente tramite peering di rete VPC. Poiché il peering di rete VPC non è transitivo, la comunicazione diretta con il piano di controllo tramite una topologia di rete in peering VPC di hub e spoke non è possibile.

Quando si considerano le opzioni di progettazione di GKE, come centralizzato o decentralizzato, l'accesso diretto al piano di controllo da origini multi-cloud è una considerazione fondamentale. Se il deployment di GKE viene eseguito in un VPC centralizzato, l'accesso al piano di controllo è disponibile in più cloud e all'interno di Google Cloud. Tuttavia, se il deployment di GKE viene eseguito in VPC decentralizzati, non è possibile la comunicazione diretta con il piano di controllo. Se i requisiti di un'organizzazione richiedono l'accesso al piano di controllo GKE oltre ad adottare il pattern di progettazione decentralizzato, gli amministratori di rete possono eseguire il deployment di un agente di connessione che agisce da proxy, superando così la limitazione del peering non transitorio per il piano di controllo GKE.

Sicurezza - Controlli di servizio VPC

Per i carichi di lavoro che coinvolgono dati sensibili, utilizza i Controlli di servizio VPC per configurare i perimetri di servizio intorno alle risorse VPC e ai servizi gestiti da Google, nonché per controllare il movimento dei dati attraverso il confine del perimetro. Con 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 gestiti da Google. È possibile utilizzare le regole in entrata e in uscita dei Controlli di servizio VPC per consentire a progetti e servizi in perimetri di servizio diversi di comunicare (incluse le reti VPC che non si trovano all'interno del perimetro).

Per le architetture di deployment consigliate, un processo di onboarding completo e le best practice operative, consulta le pagine Best practice per i Controlli di servizio VPC per le aziende e Progetto della piattaforma di sicurezza.

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 al servizio. Se è configurato un nome di dominio e un consumer di servizi crea un endpoint che ha come target quel servizio, Private Service Connect e Service Directory creano automaticamente le voci DNS per il servizio in una zona DNS privata nella rete VPC del consumer di servizi.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: