Questo documento fa parte di una serie di guide alla progettazione per Cross-Cloud Network.
La serie è composta dai seguenti componenti:
- Cross-Cloud Network per applicazioni distribuite
- Segmentazione e connettività di rete per le applicazioni distribuite in Cross-Cloud Network
- Networking dei servizi per le applicazioni distribuite in Cross-Cloud Network (questo documento)
- Sicurezza della rete per le applicazioni distribuite in Cross-Cloud Network
Questo documento descrive come assemblare un'applicazione da un insieme di servizi di 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 il singolo servizio autonomamente o se utilizzi un servizio di terze parti
- Indica se il servizio è disponibile a livello globale o regionale
- Indica se il servizio viene utilizzato on-premise, su altri cloud o su nessuno
- Se accedi all'endpoint di servizio tramite un VPC di servizi condivisi o se lo distribuisci in tutti i VPC delle applicazioni pertinenti
Questo documento illustra i seguenti passaggi:
- Decidere se la tua applicazione è globale o regionale
- Scegliere servizi gestiti di terze parti o creare e pubblicare i tuoi servizi
- Configurazione dell'accesso privato agli endpoint del servizio utilizzando una modalità condivisa o dedicata
- Assemblare i servizi in applicazioni in modo che corrispondano a un archetipo globale o regionale
Gli sviluppatori definiscono il livello di rete di 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 networking dei servizi descritte in questo documento. In alcuni casi esistono vincoli dovuti alla transitività limitata tra VPC. Descriviamo questi vincoli quando possono influire sulle decisioni di progettazione.
Decidere se la tua applicazione è regionale o globale
Determina se i clienti dell'applicazione che stai creando hanno bisogno di un archetipo di implementazione regionale o globale. Puoi ottenere la resilienza a livello di regione suddividendo i carichi tra le zone di una regione. Puoi ottenere 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, consulta gli Google Cloud archetipi di deployment.
Questa guida alla progettazione illustra come supportare i seguenti archetipi di distribuzione:
In un'applicazione distribuita su più cloud, i diversi servizi dell'applicazione possono essere forniti da diversi fornitori di servizi cloud (CSP) o da data center privati. Per contribuire a garantire una struttura di resilienza coerente, posiziona i servizi ospitati in diversi CSP in data center dei CSP vicini tra loro.
Il seguente diagramma mostra uno stack di applicazioni globale distribuito su cloud e diversi servizi di applicazioni vengono implementati in diversi fornitori di servizi cloud. Ogni servizio di applicazioni globale ha istanze di carico di lavoro in regioni diverse dello stesso CSP.
Definire e accedere ai servizi di applicazioni
Per assemblare l'applicazione, puoi utilizzare i servizi gestiti di terze parti esistenti, creare e ospitare i tuoi servizi di applicazione o utilizzare una combinazione di entrambi.
Utilizzare i servizi gestiti da 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 le opzioni di accesso privato supportate da ciascun servizio.
Una volta che sai quali servizi gestiti puoi utilizzare, puoi determinare quali servizi devi creare.
Creare e accedere ai servizi di applicazioni
Ogni servizio è ospitato da una o più istanze di carico di lavoro a cui è possibile accedere come singolo endpoint o come gruppo di endpoint.
Il pattern generale di un servizio di applicazioni è mostrato nel seguente diagramma. Il servizio dell'applicazione viene implementato in una raccolta di istanze di workload. In questo caso, un'istanza di carico di lavoro 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.
Per ottenere la distribuzione del carico scelta e per 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 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 per la connessione.
Determina l'ambito del servizio: regionale o globale
Decidi se il tuo servizio ha bisogno e può supportare la resilienza a livello regionale o globale. Un servizio software regionale può essere progettato per la sincronizzazione entro un budget di latenza regionale. Un servizio di applicazioni globali può supportare i failover sincronizzati tra i nodi distribuiti nelle regioni. Se la tua applicazione è globale, ti consigliamo di scegliere servizi di supporto globali. Tuttavia, se il tuo servizio richiede la sincronizzazione tra le sue istanze per supportare il failover, devi prendere in considerazione la latenza tra le regioni. Per la 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 all'interno di una singola regione o distribuiti in più regioni. In questo modo, puoi creare un livello rivolto ai clienti a livello globale che interagisce con livelli di servizio globali, regionali o ibride. Scegli i deployment dei servizi per assicurarti che il failover di rete dinamico (o il bilanciamento del carico tra regioni) sia in linea con lo stato di resilienza e con le funzionalità 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 le richieste alla regione locale, ma può eseguire il failover alle regioni remote.
- 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 è regionale.
- In questo pattern di architettura, i bilanciatori del carico distribuiscono principalmente il traffico 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 di bilanciatori del carico regionali, ciascuno accessibile da altre regioni e ciascuno in grado di raggiungere i backend in altre regioni, forma 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 i controlli di integrità per realizzare 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 il failover globale. Il seguente diagramma mostra un servizio pubblicato che utilizza backend globali.
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 del consumer. Il failover tra regioni del servizio deve essere implementato sia nella logica di applicazione del servizio sia nel design 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 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 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 gli endpoint o i backend di Private Service Connect. Se il servizio richiede connessioni avviate dal produttore, 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. Accesso VPC serverless supporta anche l'invio di pacchetti ad altre reti connesse alla rete VPC selezionata.
Metodi per accedere ai servizi in privato
L'applicazione può essere composta da servizi gestiti forniti da Google, servizi di terze parti forniti da fornitori esterni o gruppi di pari nella tua organizzazione e servizi sviluppati dal tuo team. Alcuni di questi servizi potrebbero essere accessibili tramite 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 presenti 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 è indicata come produttore del servizio. Tu e la tua applicazione siete considerati utenti del servizio.
Alcuni servizi gestiti vengono pubblicati esclusivamente utilizzando l'accesso ai servizi privati. I design di rete consigliati in Connettività interna e reti VPC supportano i servizi pubblicati con accesso privato ai servizi e Private Service Connect.
Per una panoramica delle opzioni per accedere ai servizi in privato, 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 produttore del servizio. Se vuoi un maggiore controllo sull'autenticazione e sulla resilienza del servizio, puoi utilizzare i 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 viene eseguito l'accesso tramite gli endpoint Private Service Connect:
Il diagramma mostra il seguente pattern:
- Viene implementato un endpoint Private Service Connect nella VPC del consumer, che rende il servizio del 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 di Private Service Connect utilizzano un bilanciatore del carico configurato con i backend del gruppo di endpoint di rete (NEG) di Private Service Connect. Per un elenco dei bilanciatori del carico supportati, consulta Informazioni sui backend di Private Service Connect.
I backend di Private Service Connect ti 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 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 per stabilire la comunicazione con il fornitore di servizi. Non è richiesta alcuna ulteriore configurazione di rete e i dati vengono trasmessi tramite la struttura SDN di Google.
La maggior parte dei servizi è progettata per le connessioni avviate dal consumatore. Quando i servizi devono avviare connessioni dal producer, utilizza le interfacce Private Service Connect.
Un aspetto chiave da considerare durante il deployment dell'accesso privato ai servizi o di Private Service Connect è la transitività. I servizi pubblicati generalmente non sono raggiungibili tramite una connessione di peering di rete VPC o tramite Network Connectivity Center. La posizione della subnet o degli endpoint di accesso ai servizi nella topologia VPC determina se la rete è progettata 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 reti VPC. Se hai bisogno di questo tipo di connettività, esegui il deployment di un bilanciatore del carico interno e di un NEG di Private Service Connect come backend, come mostrato nel seguente diagramma:
È possibile accedere alle API di Google in privato utilizzando endpoint e backend di Private Service Connect. L'utilizzo degli endpoint è generalmente consigliato in quanto il produttore dell'API di Google offre 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 del consumer è un indirizzo IP globale privato, è necessaria una singola mappatura DNS per ogni servizio, anche se esistono istanze di endpoint in più VPC, come mostrato nel seguente diagramma:
Definire i pattern di consumo dei servizi
I servizi possono essere eseguiti in varie posizioni: nella 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, l'applicazione li utilizza 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 dei consumatori possono essere condivisi tra reti o dedicati a una singola rete. Decidi se creare punti di accesso ai servizi 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 ai servizi prevede le seguenti attività:
- Creazione dei punti di accesso
- Distribuzione dei punti di accesso in un VPC con il tipo di accessibilità 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 viene aggiunto il bilanciamento del carico davanti ai punti di accesso consumer
Per alcune organizzazioni, potrebbe essere possibile assegnare la gestione dell'accesso ai servizi a un team centrale, mentre altre potrebbero essere strutturate per offrire maggiore indipendenza a ciascun team di consumatori o applicazioni. Un sottoprodotto del funzionamento in modalità dedicata è che alcuni degli elementi vengono replicati. Ad esempio, un servizio viene registrato con più nomi DNS da ciascun gruppo di applicazioni e gestisce più insiemi di certificati TLS.
Il design VPC descritto in Segmentazione della rete e connettività per le applicazioni distribuite in una rete cross-cloud consente la raggiungibilità per il deployment dei punti di accesso ai servizi in modalità condivisa o dedicata. I punti di accesso dei consumer condivisi vengono implementati in VPC di servizio a cui è possibile accedere da qualsiasi altro VPC o rete esterna. I punti di accesso dedicati ai consumatori vengono implementati in VPC per applicazioni, a cui è possibile accedere solo dalle risorse all'interno del VPC per applicazioni.
La differenza principale tra un VPC di servizio e un VPC di applicazione è la connettività transitiva dei punti di accesso ai servizi abilitata da un VPC di servizio. Le VPC di servizio non sono limitate all'hosting di punti di accesso per i consumatori. Un VPC può ospitare risorse di applicazioni, nonché punti di accesso condivisi per i consumatori. In questo caso, il VPC deve essere configurato e gestito come VPC di servizio.
Accesso ai servizi gestiti condivisi
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 dei consumer di servizi in una VPC di servizi. I VPC di servizio hanno raggiungibilità transitiva ad altri VPC.
- Annunci la subnet per il punto di accesso del consumatore come annuncio route personalizzata dal router Cloud che esegue il peering con altre reti tramite VPN ad alta disponibilità. Per le API Google, pubblicizza l'indirizzo IP host dell'API.
- Aggiorna le regole del firewall multicloud per consentire alla subnet di accesso ai servizi privati.
In particolare, per l'accesso privato ai servizi, assicurati di poter soddisfare i seguenti requisiti aggiuntivi:
- Esporta le route personalizzate nella rete del producer di servizi. Per ulteriori informazioni, consulta Gli host on-premise non riescono a comunicare con la rete del produttore del servizio
- Crea regole firewall in entrata per consentire alla subnet di accesso ai servizi privati di accedere alle VPC dell'applicazione
- Crea regole firewall in entrata per consentire alla subnet di accesso ai servizi privati di accedere alla VPC dei servizi
Per l'accesso ai servizi serverless, assicurati di soddisfare i seguenti requisiti:
- Il connettore Access richiede una subnet normale /28 dedicata
- Per impostazione predefinita, router Cloud annuncia le subnet regolari
- Crea regole firewall in entrata per consentire a tutte le subnet di accesso VPC all'interno delle VPC
- Aggiorna le regole del 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 ai servizi privati di accedere alle VPC dell'applicazione
Accesso ai servizi gestiti dedicati
Assicurati di svolgere le seguenti attività:
- In ogni VPC dell'applicazione in cui è necessario l'accesso, esegui il deployment di una regola di forwarding per il servizio in modo da creare un punto di accesso.
- Per l'accesso ai servizi privati, crea regole firewall in entrata per consentire alla subnet di accesso ai servizi privati di accedere alle VPC dell'applicazione.
Per l'accesso ai servizi serverless, assicurati di soddisfare i seguenti requisiti:
- Il connettore Access richiede una subnet normale /28 dedicata
- Crea regole firewall in entrata per consentire la subnet del connettore di accesso VPC all'interno delle 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 regionale o multiregionale, utilizza gli stack di applicazioni regionali. Le serie di applicazioni regionali possono essere considerate come una concatenazione di livelli di servizi per applicazioni regionali. Ad esempio, un livello di servizio web regionale 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 regionale.
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à viene ottenuta distribuendo le risorse di backend su tre o più zone della regione.
I livelli di servizio delle applicazioni in altri CSP o 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 dell'applicazione devono risolvere l'indirizzo IP regionale frontend del bilanciatore del carico specifico. Questi mappaggi DNS sono registrati nella zona DNS pertinente per ogni servizio dell'applicazione.
Il seguente diagramma mostra uno stack regionale con resilienza attiva/in standby:
Un'istanza completa dello stack delle applicazioni viene dispiata in ogni regione nei diversi data center cloud. Quando si verifica un errore regionale in uno dei livelli di servizio dell'applicazione, lo stack nell'altra regione assume il controllo dell'intera applicazione. Questo failover viene eseguito in risposta al monitoraggio out-of-band dei diversi livelli di servizio delle applicazioni.
Quando viene registrato un errore per uno dei livelli di servizio, il frontend dell'applicazione viene ancorato allo stack di backup. L'applicazione è scritta in modo da fare riferimento a un insieme di record dei nomi regionali che riflettono la serie di indirizzi IP regionali nel DNS in modo che ogni livello dell'applicazione mantenga le connessioni all'interno della stessa regione.
Progettare stack di applicazioni globali
Quando un'applicazione segue l'archetipo di deployment delle applicazioni globali, 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 ricovergenza automatica del failover.
Il seguente diagramma mostra uno stack di applicazioni globale:
Il diagramma precedente mostra un'applicazione globale assemblata dai seguenti componenti:
- Servizi in esecuzione in data center on-premise con frontend di bilanciatori del carico. I punti di accesso del bilanciatore del carico sono raggiungibili tramite Cloud Interconnect dalla 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 di base in esecuzione sulle istanze del carico di lavoro. Queste istanze di 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 di servizi che ospita punti di accesso per i servizi in esecuzione in altre località, ad esempio in VPC di terze parti. Questi punti di accesso ai servizi sono accessibili tramite la connessione VPN ad alta disponibilità tra il VPC dei servizi e il VPC di transito.
- VPC dei produttori di servizi ospitati da altre organizzazioni o dall'organizzazione principale e applicazioni in esecuzione in altre località. I servizi pertinenti vengono resi accessibili dai backend Private Service Connect di cui è stato eseguito il deployment come backend globali per i 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 indichi i 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. In questo modo è possibile recuperare da un 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, i frontend dei bilanciatori del carico regionali interni possono essere raggiunti in più regioni, perché utilizzano l'accesso globale. Poiché lo stack delle applicazioni è globale, vengono utilizzati i criteri di routing della geolocalizzazione DNS per selezionare il frontend regionale più appropriato per una determinata richiesta o un determinato flusso. In caso di errore del frontend, i controlli di integrità DNS possono essere utilizzati 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 di Private Service Connect possono essere utilizzati come backend globali, come descritto in Determinare l'ambito del servizio: regionale o globale.
Fornire 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 ibride. Puoi creare un servizio ospitato on-premise o in altri ambienti cloud disponibili per i clienti nella tua rete VPC, come mostrato nel seguente diagramma:
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. Posizionando un collegamento di servizio davanti al bilanciatore del carico proxy TCP regionale interno, 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 tra applicazioni.
Quando un'organizzazione diversa pubblica un servizio di applicazione, utilizza un NEG ibrido per estendere le astrazioni di accesso privato per quel servizio. Il seguente diagramma illustra questo scenario:
Nel diagramma precedente, il livello di servizio dell'applicazione è completamente composto nel CSP adiacente, che è evidenziato nelle parti del diagramma non disattivate. I bilanciatori del carico ibride vengono utilizzati in combinazione con i collegamenti di servizio Private Service Connect come meccanismo per pubblicare il servizio di applicazione esterno per il consumo privato all'interno diGoogle Cloud. I bilanciatori del carico ibride con NEG ibride e i collegamenti di servizio Private Service Connect si trovano in un VPC che fa parte di un progetto di producer di servizi. In genere, questo progetto di producer di servizi potrebbe essere una VPC diversa dalla VPC di transito, perché rientra nell'ambito amministrativo dell'organizzazione o del progetto del produttore ed è quindi separato dai servizi di transito comuni. La VPC producer non deve essere connessa tramite peering VPC o VPN ad alta disponibilità con la VPC consumer (ovvero la VPC condiviso per i servizi nel diagramma).
Centralizzare l'accesso ai servizi
L'accesso ai servizi può essere centralizzato in una rete VPC e può essere eseguito da altre reti di applicazioni. Il seguente diagramma mostra il pattern comune che consente la centralizzazione dei punti di accesso:
Il seguente diagramma mostra tutti i servizi a cui viene eseguito l'accesso da una VPC di servizi dedicata:
Quando i servizi sono in primo piano con bilanciatori del carico delle applicazioni, puoi consolidare su un numero inferiore di bilanciatori del carico utilizzando le mappe URL per indirizzare il traffico per i backend dei servizi diversi anziché utilizzare bilanciatori del carico diversi per ogni servizio. In linea di principio, uno stack di applicazioni potrebbe essere completamente composto utilizzando un singolo bilanciatore del carico delle applicazioni, oltre a backend di servizi e mappature URL appropriate.
In questa implementazione, devi utilizzare NEG ibridi nelle VPC per la maggior parte dei tipi di backend. L'eccezione è un NEG o un backend di Private Service Connect, come descritto in Eseguire il chaining esplicito dei bilanciatori del carico L7 con Private Service Connect. Google Cloud
L'utilizzo di NEG ibridi nelle VPC comporta la rinuncia alla riparazione automatica e alla scalabilità automatica per i backend. I servizi pubblicati dispongono già di un bilanciatore del carico nel tenant del produttore che fornisce la scalabilità automatica. Pertanto, incontrerai le limitazioni dei NEG ibridi solo se centralizzi la funzione di bilanciamento del carico per i livelli di servizio composti in modo nativo anziché essere consumati dalla pubblicazione.
Quando utilizzi questo pattern di networking dei servizi, ricorda che i servizi vengono consumati tramite un livello aggiuntivo di bilanciamento del carico.
Utilizza il bilanciamento del carico proxy per usufruire dei vantaggi della scalabilità della connettività VPC spoke di Network Connectivity Center tra le VPC, fornendo al contempo connettività transitiva ai servizi pubblicati tramite i bilanciatori del carico proxy.
Gli endpoint di servizio e le regole di inoltro di Private Service Connect per l'accesso ai servizi privati non sono raggiungibili nelle VPC spoke di Network Connectivity Center. Analogamente, le reti dietro le connessioni ibride (Cloud Interconnect o VPN ad alta disponibilità) non sono raggiungibili tramite le VPC spoke di Network Connectivity Center perché le route dinamiche non vengono propagate tramite Network Connectivity Center.
Questa mancanza di transitività può essere superata implementando bilanciatori del carico proxy con le risorse non transitive gestite come NEG ibride. Di conseguenza, possiamo implementare bilanciatori del carico proxy davanti ai frontend dei servizi e ai carichi di lavoro raggiungibili tramite le connessioni ibride.
I frontend proxy del bilanciatore del carico vengono implementati in subnet VPC che vengono propagate nelle VPC spoke di Network Connectivity Center. Questa propagazione consente la raggiungibilità tramite Network Connectivity Center delle risorse non transitive tramite i bilanciatori di carico proxy.
La modalità centralizzata aggiunge un livello di bilanciamento del carico 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 trattati esplicitamente in questo documento.
Considerazioni sul control plane GKE
Il piano di controllo GKE viene implementato in un progetto tenant gestito da Google collegato al VPC del cliente tramite il peering di rete VPC. Poiché il peering di rete VPC non è transitivo, non è possibile la comunicazione diretta con il control plane tramite una topologia di rete in peering VPC con hub e spoke.
Quando si valutano le opzioni di progettazione di GKE, ad esempio centralizzate o decentrate, l'accesso diretto al piano di controllo da origini multicloud è un aspetto fondamentale. Se GKE viene eseguito in una VPC centralizzata, l'accesso al control plane è disponibile nei cloud e all'interno di Google Cloud. Tuttavia, se GKE viene eseguito in VPC decentralizzate, 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 implementare un agente di connessione che agisce 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 perimetri di servizio attorno alle risorse VPC e ai servizi gestiti da Google e per controllare il movimento dei dati attraverso il confine del perimetro. Con 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 ingressi e uscite di VPC Service Controls possono essere utilizzate per consentire la comunicazione tra progetti e servizi in perimetri di servizio diversi (incluse le reti VPC esterne al perimetro).
Per le architetture di deployment consigliate, una procedura di onboarding completa e le best practice operative, consulta le best practice per VPC Service Controls per le aziende e il Security Foundations Blueprint.
DNS per API/servizi
I producer di servizi possono pubblicare servizi utilizzando Private Service Connect. Il produttore del servizio 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 le voci DNS per il servizio in una zona DNS privata nella rete VPC del consumer di servizi.
Passaggi successivi
- Progetta la sicurezza della rete per le applicazioni Cross-Cloud Network.
- Scopri di più sui Google Cloud prodotti utilizzati in questa guida di progettazione:
- Per altre architetture di riferimento, diagrammi e best practice, visita il Centro architetture di Google Cloud.
Collaboratori
Autori:
- Victor Moreno | Product Manager, Cloud Networking
- Ghaleb Al-habian | Specialista della rete
- Deepak Michael | Customer Engineer esperto di networking
- Osvaldo Costa | Networking Specialist Customer Engineer
- Jonathan Almaleh | Technical Solutions Consultant di livello superiore
Altri collaboratori:
- Zach Seils | Specialista di networking
- Christopher Abraham | Customer Engineer esperto di reti
- Emanuele Mazza | Networking Product Specialist
- Aurélien Legrand | Strategic Cloud Engineer
- Eric Yu | Networking Specialist Customer Engineer
- Kumar Dhanagopal | Sviluppatore di soluzioni cross-product
- Mark Schlagenhauf | Technical Writer, Networking
- Marwan Al Shawi | Partner Customer Engineer
- Ammett Williams | Developer Relations Engineer