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 è composta dalle seguenti parti:

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:

  • Se crei tu stesso il singolo servizio o utilizzi un servizio di terze parti
  • Se il servizio è disponibile a livello globale o regionale
  • Indica se il servizio viene utilizzato on-premise, da altri cloud o da nessuno dei due.
  • Se accedi all'endpoint di servizio tramite un VPC di servizi condivisi o distribuisci gli endpoint in tutti i VPC delle applicazioni pertinenti

Questo documento ti guida attraverso i seguenti passaggi:

  1. Decidere se l'applicazione è globale o regionale
  2. Scegliere servizi gestiti di terze parti o creare e pubblicare i propri servizi
  3. Configurazione dell'accesso privato agli endpoint di servizio utilizzando una modalità condivisa o dedicata
  4. Assemblaggio dei servizi in applicazioni in modo che corrispondano a un archetipo globale o regionale

Gli sviluppatori definiscono il livello di networking dei servizi per Cross-Cloud Network. A questo punto, gli amministratori hanno progettato un livello di connettività per Cross-Cloud Network che consente flessibilità nelle opzioni di servizio di rete descritte in questo documento. In alcuni casi, esistono vincoli dovuti alla transitività cross-VPC limitata. Descriviamo questi vincoli quando possono influire sulle decisioni di progettazione.

Decidere se l'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 regionale distribuendo i carichi nelle zone di una regione. Puoi ottenere la resilienza globale distribuendo i carichi tra le regioni.

Quando scegli un archetipo, prendi in considerazione i seguenti fattori:

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

Per maggiori dettagli, vedi gli archetipi di deployment diGoogle Cloud .

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 forniti da diversi fornitori di servizi cloud (CSP) o data center privati. Per garantire una struttura di resilienza coerente, inserisci i servizi ospitati in CSP diversi nei data center CSP geograficamente vicini tra loro.

Il seguente diagramma mostra uno stack di applicazioni globale distribuito su più cloud e diversi servizi applicativi vengono implementati in CSP diversi. Ogni servizio di applicazione globale ha istanze di workload in regioni diverse dello stesso CSP.

Stack di applicazioni globale distribuito su più cloud.

Definire i servizi applicativi e accedervi

Per assemblare l'applicazione, puoi utilizzare servizi gestiti di terze parti esistenti, creare e ospitare i tuoi servizi applicativi oppure 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. Determina quali sono costruiti come servizi regionali o globali. Inoltre, determina quali opzioni di accesso privato supporta ogni servizio.

Una volta individuati i servizi gestiti che puoi utilizzare, puoi determinare quali servizi devi creare.

Creare e accedere ai servizi applicativi

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

Il pattern generale per un servizio applicativo è mostrato nel seguente diagramma. Il servizio applicazione viene implementato in una raccolta di istanze di workload. In questo caso, un'istanza di workload potrebbe essere una VM Compute Engine, un cluster Google Kubernetes Engine (GKE) o un altro backend che esegue 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 insieme 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 i gruppi di istanze gestite (MIG), puoi aumentare o diminuire in modo elastico la capacità del servizio eseguendo la scalabilità automatica degli endpoint che formano il backend del bilanciatore del carico. Inoltre, a seconda dei requisiti del servizio applicativo, il bilanciatore del carico può fornire anche autenticazione, terminazione TLS e altri servizi specifici per la connessione.

Determinare l'ambito del servizio: regionale o globale

Decidi se il tuo servizio ha bisogno di resilienza regionale o globale e se può supportarla. Un servizio software regionale può essere progettato per la sincronizzazione all'interno di un budget di latenza regionale. Un servizio di applicazione globale può supportare failover sincroni tra nodi distribuiti in più regioni. Se la tua applicazione è globale, potresti voler che anche i servizi che la supportano siano globali. Tuttavia, se il tuo servizio richiede la sincronizzazione tra le sue istanze per supportare il failover, devi considerare la latenza tra le regioni. Nella tua situazione, potresti dover fare affidamento su servizi regionali con ridondanza nelle stesse regioni o in quelle vicine, supportando così la sincronizzazione a bassa latenza per il failover.

Cloud Load Balancing supporta endpoint ospitati in una singola regione o distribuiti in più regioni. Pertanto, puoi creare un livello globale rivolto ai clienti che interagisce con livelli di servizio globali, regionali o ibridi. Scegli i deployment dei servizi per assicurarti che il failover di rete dinamico (o il bilanciamento del carico tra le 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 a partire da bilanciatori del carico regionali può raggiungere i backend in altre regioni, fornendo così il failover automatico tra le 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 nelle regioni remote.

Bilanciatori del carico con backend in regioni diverse.

  • Un backend globale è una raccolta di backend regionali a cui accede uno o più bilanciatori del carico.
  • Sebbene i backend siano globali, il frontend di ogni bilanciatore del carico è regionale.
  • In questo pattern architetturale, i bilanciatori del carico distribuiscono il traffico principalmente solo all'interno della loro regione, ma possono anche bilanciare il traffico verso altre regioni quando le risorse nella regione locale non sono disponibili.
  • Un insieme di frontend del bilanciatore del carico regionale, ciascuno accessibile da altre regioni e in grado di raggiungere i 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 tra regioni dei frontend.
  • I frontend del bilanciatore del carico sono accessibili da altre regioni utilizzando l'accesso globale (non mostrato nel diagramma).

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

Bilanciatori del carico accessibili da regioni diverse.

Nel diagramma, tieni presente che il servizio pubblicato ha il failover globale implementato nell'ambiente del producer. L'aggiunta del failover globale nell'ambiente consumer consente la resilienza ai guasti regionali nell'infrastruttura di bilanciamento del carico consumer. Il failover cross-region del servizio deve essere implementato sia nella logica dell'applicazione di servizio sia nella progettazione del bilanciamento del carico del producer di servizi. Altri meccanismi possono essere implementati dai produttori di servizi.

Per determinare quale prodotto Cloud Load Balancing utilizzare, devi innanzitutto determinare il tipo di traffico che i bilanciatori del carico devono gestire. Tieni in considerazione 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 preservare l'indirizzo IP di origine del client nell'intestazione o per supportare protocolli aggiuntivi come UDP, ESP e ICMP.

Per indicazioni dettagliate sulla selezione del miglior bilanciatore del carico per il 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 produttore può essere organizzato in un NEG serverless come backend di un bilanciatore del carico. Questo servizio può essere pubblicato utilizzando Private Service Connect creando un collegamento di 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, App Engine standard e Cloud Run Functions 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 accedere ai servizi in privato

La tua applicazione può essere costituita da servizi gestiti forniti da Google, servizi di terze parti forniti da fornitori esterni o gruppi peer della tua organizzazione e servizi sviluppati dal tuo team. Alcuni di questi servizi potrebbero essere accessibili su internet utilizzando indirizzi IP pubblici. Questa sezione descrive i metodi che puoi utilizzare per accedere a questi servizi utilizzando la rete privata. Esistono i seguenti tipi di servizio:

  • API pubbliche di Google
  • API serverless di Google
  • Servizi gestiti pubblicati da Google
  • Servizi gestiti pubblicati da fornitori e colleghi
  • I tuoi servizi pubblicati

Tieni presente queste opzioni quando leggi le sezioni successive. A seconda di come allochi 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 è denominataproducer di servizio. Tu e la tua applicazione siete indicati come consumer del servizio.

Alcuni servizi gestiti vengono pubblicati esclusivamente utilizzando l'accesso ai servizi privati. I progetti di rete consigliati in Connettività interna e networking VPC ospitano servizi pubblicati con accesso privato ai servizi e Private Service Connect.

Per una panoramica delle opzioni di accesso privato ai servizi, consulta Opzioni di accesso privato per i servizi.

Ti consigliamo di utilizzare Private Service Connect per connetterti ai servizi gestiti, se 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 come uno dei due 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 un maggiore controllo sull'autenticazione e sulla resilienza del servizio, 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 l'accesso ai servizi tramite gli endpoint Private Service Connect:

Accesso ai servizi tramite endpoint Private Service Connect.

Il diagramma mostra il seguente pattern:

  • Un endpoint Private Service Connect viene implementato nel VPC consumer, il che rende il servizio producer disponibile per le VM e i nodi GKE.
  • Le reti consumer e producer devono essere implementate nella stessa regione.

Il diagramma precedente mostra gli endpoint come risorse regionali. 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 backend del gruppo di endpoint di rete (NEG) Private Service Connect. Per un elenco dei bilanciatori del carico supportati, consulta 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 davanti ai servizi gestiti
  • Failover controllato dal consumatore tra servizi gestiti in regioni diverse
  • Configurazione della sicurezza centralizzata e controllo dell'accesso per i servizi gestiti

Nel seguente diagramma, il bilanciatore del carico globale utilizza un NEG di Private Service Connect come backend che stabilisce la comunicazione con il service provider. Non è richiesta alcuna ulteriore configurazione di rete e i dati vengono trasferiti tramite la SDN di Google.

Bilanciatore del carico globale che utilizza il 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.

Un aspetto fondamentale da considerare 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 Network Connectivity Center. I servizi pubblicati non sono raggiungibili tramite una connessione di peering di rete VPC per Private Service Connect o punti di accesso consumer per l'accesso ai servizi privati. In assenza di transitività tra VPC per tutti i punti di accesso consumer di servizi, la posizione della subnet di accesso al servizio o degli endpoint nella topologia VPC determina se progettare la rete per il deployment di servizi condivisi o dedicati.

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

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

Utilizzo dei NEG per fornire raggiungibilità.

È possibile accedere alle API di Google in privato utilizzando endpoint e backend Private Service Connect. L'utilizzo degli endpoint è generalmente consigliato in quanto il produttore dell'API Google 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 IP privato globale, è necessaria una singola mappatura DNS per ogni servizio, anche se sono presenti istanze endpoint in più VPC, come mostrato nel seguente diagramma:

Private Service Connect con le API di Google.

Definisci i pattern di consumo per i servizi pubblicati

I servizi pubblicati possono essere eseguiti in varie località: nella tua rete VPC, in un'altra rete VPC, in un data center on-premise o nel cloud. Indipendentemente da dove viene eseguito il workload del servizio, la tua applicazione utilizza questi servizi tramite 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 NEG Private Service Connect

I punti di accesso per i consumatori possono essere condivisi tra più reti o dedicati a una singola rete. Decidi se creare punti di accesso per i consumatori condivisi o dedicati in base al fatto che la tua organizzazione deleghi l'attività di creazione di punti di accesso ai servizi per i consumatori a ogni gruppo di applicazioni o gestisca l'accesso ai servizi in modo consolidato.

La gestione dell'accesso al servizio prevede le seguenti attività:

  • Creazione dei punti di accesso
  • Deployment dei punti di accesso in un VPC di accesso ai servizi, ovvero un VPC con il tipo di raggiungibilità appropriato
  • Registrazione degli indirizzi IP e degli URL dei punti di accesso dei consumatori nel DNS
  • Gestione dei certificati di sicurezza e della resilienza per il servizio nello spazio consumer, quando si aggiunge il bilanciamento del carico davanti ai punti di accesso consumer

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

La progettazione VPC descritta in Segmentazione e connettività di rete per applicazioni distribuite in Cross-Cloud Network consente la raggiungibilità per il deployment di punti di accesso al servizio in modalità condivisa o dedicata. I punti di accesso consumer condivisi vengono implementati nei VPC di accesso al servizio, a cui è possibile accedere da qualsiasi altro VPC o rete esterna. I punti di accesso consumer dedicati vengono implementati nei VPC delle applicazioni, a cui è possibile accedere solo dalle risorse all'interno di quel VPC dell'applicazione.

La differenza principale tra un VPC di accesso al servizio e un VPC dell'applicazione è la connettività transitiva del punto di accesso al servizio che un VPC di accesso al servizio abilita. I VPC di accesso al servizio non sono limitati all'hosting dei punti di accesso consumer. Un VPC può ospitare risorse dell'applicazione, nonché punti di accesso consumer condivisi. In questo caso, il VPC deve essere configurato e gestito come VPC di servizio.

Accesso condiviso ai servizi gestiti

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

  • Esegui il deployment dei punti di accesso consumer di servizi in un VPC di servizi. I VPC di servizio hanno raggiungibilità transitiva ad altri VPC.
  • Se il VPC di accesso al servizio è connesso alla VPN ad alta disponibilità, annuncia la subnet per il punto di accesso consumer come annuncio di route personalizzata dal router Cloud che esegue il peering con altre reti tramite la VPN ad alta disponibilità. Per le API di Google, pubblicizza l'indirizzo IP host dell'API.
  • Aggiorna le regole firewall multicloud per consentire la subnet di accesso ai servizi privati.

Per l'accesso privato ai servizi in particolare, 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 producer di servizi del servizio
  • Crea regole firewall in entrata per consentire alla subnet di accesso privato ai servizi di accedere ai VPC delle applicazioni
  • Crea regole firewall in entrata per consentire alla subnet di accesso privato ai servizi di accedere al VPC dei servizi

Per l'accesso al servizio serverless, assicurati di soddisfare i seguenti requisiti:

  • Il connettore di accesso richiede una subnet normale /28 dedicata
  • Per impostazione predefinita, router Cloud annuncia le subnet regolari
  • Crea regole firewall in entrata per consentire l'accesso alla subnet VPC all'interno dei VPC
  • Aggiorna le regole firewall multicloud per consentire la subnet del connettore di accesso VPC
  • Crea una o più regole firewall in entrata per consentire alla subnet di accesso privato ai servizi nei VPC dell'applicazione

Accesso ai servizi gestiti dedicati

Assicurati di svolgere le seguenti attività:

  • In ogni VPC dell'applicazione in cui è necessario l'accesso, implementa una regola di forwarding per il servizio per creare un punto di accesso.
  • Per l'accesso privato ai servizi, crea una o più regole firewall in entrata per consentire l'accesso privato ai servizi nella subnet nei VPC dell'applicazione.

Per l'accesso al servizio serverless, assicurati di soddisfare i seguenti requisiti:

  • Il connettore di accesso richiede una subnet normale /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 dell'applicazione

Questa sezione descrive l'assemblaggio di uno stack di applicazioni regionale o globale.

Progettare stack di applicazioni regionali

Quando un'applicazione segue gli archetipi di deployment regionali o multiregionali, utilizza gli stack di applicazioni regionali. Gli stack di applicazioni regionali possono essere considerati come una concatenazione di livelli di servizi per applicazioni regionali. Ad esempio, un livello di servizio web regionale che comunica con un livello applicativo nella stessa regione, che a sua volta comunica con un livello di database nella stessa regione, è uno stack di applicazioni regionale.

Ogni livello di servizio delle applicazioni regionale utilizza i bilanciatori del carico per distribuire il traffico tra gli endpoint del livello in quella regione. L'affidabilità viene ottenuta distribuendo le risorse di backend in tre o più zone della regione.

I livelli di servizio delle applicazioni in altri CSP o nei data center on-premise devono essere implementati in regioni equivalenti nelle reti esterne. Inoltre, rendi 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 delle applicazioni devono essere risolti nell'indirizzo IP regionale frontend del bilanciatore del carico specifico. Questi mapping DNS vengono registrati nella zona DNS pertinente per ogni servizio applicativo.

Il seguente diagramma mostra uno stack regionale con resilienza active-standby:

Stack regionale con resilienza attiva-standby.

In ogni regione viene implementata un'istanza completa dello stack di applicazioni nei diversi data center cloud. Quando si verifica un errore a livello di regione in uno dei livelli di servizio dell'applicazione, lo stack nell'altra regione assume la responsabilità della distribuzione dell'intera applicazione. Questo failover viene eseguito in risposta al monitoraggio out-of-band dei diversi livelli di servizio dell'applicazione.

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

Progettare stack di applicazioni globali

Quando un'applicazione segue l'archetipo di deployment globale, ogni livello di servizio dell'applicazione include backend in più regioni. L'inclusione di backend in più regioni espande il pool di resilienza per il livello di servizio dell'applicazione 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 che utilizza 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 del bilanciatore 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 del workload. Queste istanze del carico di lavoro si trovano dietro i 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 dei servizi che ospita i punti di accesso per i servizi in esecuzione in altre posizioni, ad esempio in VPC di terze parti. Questi punti di accesso al servizio sono raggiungibili tramite la connessione VPN ad alta disponibilità tra il VPC dei servizi e il VPC di transito.
  • VPC del produttore di servizi ospitati da altre organizzazioni o dall'organizzazione principale e applicazioni eseguite in altre località. I servizi pertinenti sono resi raggiungibili dai backend Private Service Connect implementati come backend globali nei bilanciatori del carico regionali 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 indirizza ai workload dell'applicazione nel VPC dell'applicazione (non mostrato nel diagramma).

Per supportare uno stack di applicazioni globale, abbiamo utilizzato backend globali per ogni livello dell'applicazione. Ciò consente il ripristino in caso di errore di tutti gli endpoint di backend in una regione. Ogni regione ha un frontend del bilanciatore del carico regionale per ogni livello di servizio dell'applicazione. Quando si verifica un failover regionale, è possibile raggiungere i frontend del bilanciatore del carico regionale interno in tutte le regioni, perché utilizzano l'accesso globale. Poiché lo stack di applicazioni è globale, vengono utilizzate le norme di routing basato sulla geolocalizzazione DNS 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 di Private Service Connect beneficiano dell'accesso globale di Private Service Connect. Questa funzionalità consente di raggiungere un backend Private Service Connect 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 Determinare l'ambito del servizio: regionale o globale.

Fornire l'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 interno regionale utilizzando i NEG ibridi. Puoi creare un producer di servizi ospitato on-premise o in altri ambienti cloud disponibili per i consumer di servizi (client) nella tua rete VPC, come mostrato nel seguente diagramma:

Punto di accesso locale che utilizza i NEG ibridi.

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

In un ambiente cross-cloud, l'utilizzo di un NEG ibrido consente una comunicazione sicura da applicazione ad applicazione.

Quando un'altra organizzazione pubblica un servizio applicativo, utilizza un NEG ibrido per estendere le astrazioni di accesso privato per quel servizio. Il seguente diagramma illustra questo scenario:

NEG ibridi davanti ai servizi in altre reti.

Nel diagramma precedente, il livello del servizio applicazione è composto interamente nel CSP adiacente, evidenziato nelle parti del diagramma non visualizzate in grigio. I bilanciatori del carico ibridi vengono utilizzati insieme ai collegamenti di servizio Private Service Connect come meccanismo per pubblicare il servizio di applicazione esterno per il consumo privato all'interno di Google Cloud. I bilanciatori del carico ibridi con NEG ibridi e collegamenti di servizio Private Service Connect si trovano in un VPC che fa parte di un progetto di producer di servizi. Questo progetto di producer di servizi di solito potrebbe essere un VPC diverso dal VPC di transito, perché si trova nell'ambito amministrativo dell'organizzazione o del progetto del produttore e quindi separato dai servizi di transito comuni. Il VPC producer non deve essere connesso tramite peering VPC o VPN ad alta disponibilità al VPC consumer (che è il VPC condiviso dei servizi nel diagramma).

Centralizzare l'accesso al servizio

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 dei servizi dedicati.

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

VPC dei servizi dedicati con bilanciatori del carico centralizzati.

Quando i servizi sono front-end con i bilanciatori del carico delle applicazioni, puoi consolidare un numero inferiore di bilanciatori del carico utilizzando le mappe URL per indirizzare il traffico per diversi backend di servizio anziché utilizzare bilanciatori del carico diversi per ogni servizio. In linea di principio, uno stack di applicazioni potrebbe essere composto interamente utilizzando un singolo bilanciatore del carico delle applicazioni più i backend del servizio e i mapping URL appropriati.

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

L'utilizzo di NEG ibridi in più VPC comporta la rinuncia alla riparazione automatica e alla scalabilità automatica per i backend. I servizi pubblicati hanno già un bilanciatore del carico nel tenant produttore che fornisce la scalabilità automatica. Pertanto, riscontri le limitazioni dei NEG ibridi solo se centralizzi la funzione di bilanciamento del carico per i livelli di servizio composti in modo nativo anziché utilizzati dalla pubblicazione.

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

Gli endpoint di servizio Private Service Connect sono raggiungibili tramite i VPC 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 per prodotti e servizi comuni non esplicitamente trattati in questo documento.

Considerazioni sul control plane GKE

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

Quando si prendono in considerazione le opzioni di progettazione di GKE, come quella centralizzata o decentralizzata, l'accesso diretto al control plane da origini multicloud è un aspetto fondamentale. Se GKE viene implementato in un VPC centralizzato, l'accesso al control plane è disponibile in tutti i cloud e all'interno diGoogle Cloud. Tuttavia, se GKE viene implementato in VPC decentralizzati, la comunicazione diretta con il control plane non è possibile. Se i requisiti di un'organizzazione richiedono l'accesso al piano di controllo GKE oltre all'adozione del pattern di progettazione decentralizzato, gli amministratori di rete possono eseguire il deployment di un agente connect che funge da proxy, superando così la limitazione del peering non transitivo al 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 attorno alle risorse VPC e ai servizi gestiti da Google e controllare lo spostamento dei dati oltre il confine del perimetro. Utilizzando i Controlli di servizio VPC, puoi raggruppare i progetti e la tua rete on-premise in un unico perimetro che impedisce l'accesso ai dati tramite i servizi gestiti da Google. Le regole di ingresso e uscita di Controlli di servizio VPC possono essere utilizzate 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 architetture di deployment consigliate, una procedura di onboarding completa e best practice operative, consulta le best practice per i controlli di servizio VPC per le aziende e il blueprint delle basi della sicurezza.

DNS per API/servizi

I producer di servizi possono pubblicare servizi utilizzando Private Service Connect. Il producer di servizi può facoltativamente 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 voci DNS per il servizio in una zona DNS privata nella rete VPC del consumer di servizi.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: