Questo documento introduce i concetti da comprendere per configurare i bilanciatori del carico delle applicazioni interni.
Un bilanciatore del carico delle applicazioni interno di Google Cloud è un bilanciatore del carico di livello 7 basato su proxy che ti consente di eseguire e scalare i servizi dietro un singolo indirizzo IP interno. L'Application Load Balancer interno distribuisce il traffico HTTP e HTTPS ai backend ospitati su una serie di piattaforme Google Cloud come Compute Engine, Google Kubernetes Engine (GKE) e Cloud Run. Per i dettagli, consulta Panoramica del bilanciatore del carico delle applicazioni: casi d'uso.
Modalità di funzionamento
Puoi configurare un bilanciatore del carico delle applicazioni interno nelle seguenti modalità:
- Bilanciatore del carico delle applicazioni interno regionale. Questo è un bilanciatore del carico a livello di regione implementato come servizio gestito basato sul proxy Envoy open source. La modalità a livello di regione assicura che tutti i client e i backend provengano da una regione specificata, il che è utile quando è necessaria la conformità a livello di regione. Questo bilanciatore del carico è abilitato con funzionalità avanzate di controllo del traffico basate su parametri HTTP(S). Al termine della configurazione, il bilanciatore del carico alloca automaticamente i proxy Envoy per soddisfare le tue esigenze di traffico.
Bilanciatore del carico delle applicazioni interno tra regioni. Si tratta di un bilanciatore del carico per più regioni implementato come servizio gestito basato sul proxy Envoy open source. La modalità tra regioni consente di bilanciare il carico del traffico verso i servizi di backend distribuiti a livello globale, inclusa la gestione del traffico che garantisce che il traffico sia indirizzato al backend più vicino. Questo bilanciatore del carico consente inoltre una disponibilità elevata. Il posizionamento dei backend in più regioni consente di evitare errori in una singola regione. Se i backend di una regione sono inattivi, il traffico può eseguire il failover su un'altra regione. Il bilanciatore del carico delle applicazioni interno tra regioni è in anteprima.
La seguente tabella descrive le importanti differenze tra le modalità a livello di regione e tra regioni:
Selezione delle Bilanciatore del carico delle applicazioni interno regionale Bilanciatore del carico delle applicazioni interno tra regioni Indirizzo IP virtuale (VIP) del bilanciatore del carico. Assegnato da una subnet in una regione Google Cloud specifica. Assegnato da una subnet in una regione Google Cloud specifica. Gli indirizzi VIP di più regioni possono condividere lo stesso servizio di backend globale. Puoi configurare il bilanciamento del carico globale basato su DNS utilizzando i criteri di routing DNS per instradare le richieste client all'indirizzo VIP più vicino.
Accesso client Non accessibile a livello globale per impostazione predefinita.
Facoltativamente, puoi abilitare l'accesso globale.Sempre accessibile a livello globale. I client di qualsiasi regione Google Cloud possono inviare traffico al bilanciatore del carico. Backend con bilanciamento del carico Backend a livello di regione.
Il bilanciatore del carico può inviare traffico solo a backend che si trovano nella stessa regione del proxy del bilanciatore del carico.Backend globali.
Il bilanciatore del carico può inviare traffico ai backend in qualsiasi regione.Alta disponibilità e failover Failover automatico ai backend integri nella stessa regione. Failover automatico a backend integri nelle stesse regioni o in regioni diverse.
Identifica la modalità
console Cloud
Nella console Google Cloud, vai alla pagina Bilanciamento del carico.
Nella scheda Bilanciatori del carico puoi vedere il tipo, il protocollo e la regione del bilanciatore del carico. Se la regione è vuota, il bilanciatore del carico è in modalità tra regioni. La tabella seguente riassume come identificare la modalità del bilanciatore del carico.
Modalità bilanciatore del carico Tipo di bilanciatore del carico Tipo di accesso Regione Bilanciatore del carico delle applicazioni interno regionale Applicazione IP Specifica una regione Bilanciatore del carico delle applicazioni interno tra regioni Applicazione IP
gcloud
Per determinare la modalità di un bilanciatore del carico, esegui questo comando:
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
Nell'output comando, verifica lo schema di bilanciamento del carico, la regione e il livello di rete. La seguente tabella riassume come identificare la modalità del bilanciatore del carico.
Modalità bilanciatore del carico Schema di bilanciamento del carico Regola di forwarding Bilanciatore del carico delle applicazioni interno regionale INTERNAL_MANAGED Regionale Bilanciatore del carico delle applicazioni interno tra regioni INTERNAL_MANAGED Globale
Architettura e risorse
Il seguente diagramma mostra le risorse Google Cloud necessarie per gli Application Load Balancer interni in ciascuna modalità:
Regionale
Questo diagramma mostra i componenti del deployment di un bilanciatore del carico delle applicazioni interno regionale nel livello Premium.
Tra regioni
Questo diagramma mostra i componenti del deployment di un bilanciatore del carico delle applicazioni interno tra regioni nel livello Premium all'interno della stessa rete VPC. Ogni regola di forwarding globale utilizza un indirizzo IP a livello di regione utilizzato dai client per la connessione.
Ogni bilanciatore del carico delle applicazioni interno utilizza le seguenti risorse di configurazione di Google Cloud.
Subnet solo proxy
Nel diagramma precedente, la subnet solo proxy fornisce un insieme di indirizzi IP che Google utilizza per eseguire i proxy Envoy per tuo conto. Devi creare una subnet solo proxy in ogni regione di una rete VPC in cui utilizzi bilanciatori del carico delle applicazioni interni.
La seguente tabella descrive le differenze tra le subnet solo proxy in modalità a livello di regione e tra regioni:
Modalità bilanciatore del carico | Valore del flag della subnet solo proxy --purpose |
---|---|
Bilanciatore del carico delle applicazioni interno regionale |
I bilanciatori del carico a livello di una o più regioni non possono condividere le stesse subnet Tutti i bilanciatori del carico basati su Envoy a livello di regione di una regione e di una rete VPC condividono la stessa subnet solo proxy |
Bilanciatore del carico delle applicazioni interno tra regioni |
I bilanciatori del carico a livello di una o più regioni non possono condividere le stesse subnet Il bilanciatore del carico basato su Envoy tra regioni deve avere una subnet solo proxy in ogni regione in cui è configurato il bilanciatore del carico. I proxy del bilanciatore del carico tra regioni nella stessa regione e nella stessa rete condividono la stessa subnet solo proxy. |
Inoltre:
- Le subnet solo proxy vengono utilizzate solo per i proxy Envoy, non per i tuoi backend.
- Le VM di backend o gli endpoint di tutti gli Application Load Balancer interni in una regione e la rete VPC ricevono connessioni dalla subnet solo proxy.
- L'indirizzo IP di un bilanciatore del carico delle applicazioni interno non si trova nella subnet solo proxy. L'indirizzo IP del bilanciatore del carico è definito dalla regola di forwarding gestito interna, descritta di seguito.
Regola di forwarding e indirizzo IP
Le regole di forwarding instradano il traffico in base a indirizzo IP, porta e protocollo a una configurazione di bilanciamento del carico composta da un proxy di destinazione e un servizio di backend.
Ogni regola di forwarding fa riferimento a un singolo indirizzo IP a livello di regione che puoi utilizzare nei record DNS per la tua applicazione. Puoi prenotare un indirizzo IP statico da utilizzare oppure lasciare che Cloud Load Balancing ne assegni uno. Ti consigliamo di prenotare un indirizzo IP statico; in caso contrario, devi aggiornare il record DNS con l'indirizzo IP temporaneo appena assegnato ogni volta che elimini una regola di forwarding e ne crei una nuova.
I client utilizzano l'indirizzo IP e la porta per connettersi ai proxy Envoy del bilanciatore del carico; l'indirizzo IP della regola di forwarding è l'indirizzo IP del bilanciatore del carico (a volte chiamato indirizzo IP virtuale o VIP). I client che si connettono a un bilanciatore del carico devono utilizzare HTTP 1.1 o versioni successive. Per l'elenco completo dei protocolli supportati, consulta Funzionalità del bilanciatore del carico.
L'indirizzo IP interno associato alla regola di forwarding può provenire da una subnet nella stessa rete e nella stessa regione dei backend.
Ogni regola di forwarding per un bilanciatore del carico delle applicazioni può fare riferimento a una singola porta da 1-65535. Per supportare più porte, devi configurare più regole di forwarding. Puoi configurare più regole di forwarding in modo da utilizzare lo stesso indirizzo IP interno (VIP) e fare riferimento allo stesso proxy HTTP(S) di destinazione, purché la combinazione complessiva di indirizzo IP, porta e protocollo sia univoca per ogni regola di forwarding. In questo modo, puoi utilizzare un singolo bilanciatore del carico con una mappa URL condivisa come proxy per più applicazioni.
La seguente tabella mostra le differenze tra le regole di forwarding nelle modalità a livello di regione e tra regioni:
Modalità bilanciatore del carico | Regola di forwarding, indirizzo IP e subnet solo proxy --purpose |
Routing dal client al frontend del bilanciatore del carico |
---|---|---|
Bilanciatore del carico delle applicazioni interno regionale | Regola di forwarding a livello di regione Indirizzo IP a livello di regione Schema di bilanciamento del carico:
Subnet solo proxy
Indirizzo IP
|
Puoi abilitare l'accesso globale per consentire ai client di qualsiasi regione di accedere al tuo bilanciatore del carico. Anche i backend devono trovarsi nella stessa regione del bilanciatore del carico. |
Bilanciatore del carico delle applicazioni interno tra regioni |
Indirizzi IP a livello di regione Schema di bilanciamento del carico:
Subnet solo proxy
Indirizzo IP
|
L'accesso globale è abilitato per impostazione predefinita per consentire ai client di qualsiasi regione di accedere al bilanciatore del carico. I backend possono trovarsi in più regioni. |
Proxy di destinazione
Un proxy HTTP(S) di destinazione termina le connessioni HTTP(S) dai client. Il proxy HTTP(S) consulta la mappa URL per determinare come instradare il traffico ai backend. Un proxy HTTPS di destinazione utilizza un certificato SSL per l'autenticazione presso i client.
Il bilanciatore del carico conserva l'intestazione Host della richiesta client originale. Il bilanciatore del carico aggiunge anche due indirizzi IP all'intestazione X-Forwarded-For
:
- L'indirizzo IP del client che si connette al bilanciatore del carico
- L'indirizzo IP della regola di forwarding del bilanciatore del carico
Se non è presente alcuna intestazione X-Forwarded-For
nella richiesta in entrata, questi due indirizzi IP corrispondono all'intero valore dell'intestazione. Se la richiesta ha un'intestazione X-Forwarded-For
, altre informazioni, come gli indirizzi IP registrati dai proxy lungo il percorso verso il bilanciatore del carico, vengono conservate prima dei due indirizzi IP. Il bilanciatore del carico non verifica gli indirizzi IP che precedono gli ultimi due indirizzi IP in questa intestazione.
Se utilizzi un proxy come server di backend, questo in genere aggiunge ulteriori informazioni all'intestazione X-Forwarded-For
e il tuo software potrebbe dover tenerne conto. Le richieste inviate tramite proxy dal bilanciatore del carico provengono da un indirizzo IP nella subnet solo proxy e il tuo proxy nell'istanza di backend potrebbe registrare questo indirizzo e l'indirizzo IP dell'istanza di backend.
A seconda del tipo di traffico che l'applicazione deve gestire, puoi configurare un bilanciatore del carico con un proxy HTTP di destinazione o un proxy HTTPS di destinazione.
La seguente tabella mostra le API proxy di destinazione richieste dagli Application Load Balancer interni in ciascuna modalità:
Proxy di destinazione | Bilanciatore del carico delle applicazioni interno regionale | Bilanciatore del carico delle applicazioni interno tra regioni |
---|---|---|
HTTP | regionTargetHttpProxies |
Livello globale targetHttpProxies |
HTTPS | regionTargetHttpsProxies |
Globale targetHttpsProxies |
Certificati SSL
I bilanciatori del carico delle applicazioni interni che utilizzano proxy HTTPS di destinazione richiedono chiavi private e certificati SSL come parte della configurazione del bilanciatore del carico.
La seguente tabella specifica il tipo di certificati SSL richiesti dagli Application Load Balancer interni in ciascuna modalità:
Modalità bilanciatore del carico | Tipo di certificato SSL |
---|---|
Bilanciatore del carico delle applicazioni interno regionale | Certificati SSL a livello di regione di Compute Engine Certificati autogestiti a livello di regione e certificati gestiti da Google nel Gestore certificati. Gestore certificati supporta i seguenti tipi di certificati gestiti da Google:
I certificati gestiti da Google con autorizzazione del bilanciatore del carico non sono supportati. |
Bilanciatore del carico delle applicazioni interno tra regioni | Certificati autogestiti e certificati gestiti da Google nel Gestore certificati. Gestore certificati supporta i seguenti tipi di certificati gestiti da Google:
I certificati gestiti da Google con autorizzazione del bilanciatore del carico non sono supportati. I certificati SSL di Compute Engine non sono supportati. |
Mappe URL
Il proxy HTTP(S) di destinazione utilizza le mappe URL per determinare il routing in base ad attributi HTTP (come percorso di richiesta, cookie o intestazioni). In base alla decisione di routing, il proxy inoltra le richieste del client a servizi di backend specifici. La mappa URL può specificare ulteriori azioni da intraprendere, come la riscrittura delle intestazioni, l'invio di reindirizzamenti ai client e la configurazione dei criteri di timeout, tra le altre cose.
La seguente tabella specifica il tipo di mappa URL richiesto dagli Application Load Balancer interni in ogni modalità:
Modalità bilanciatore del carico | Tipo di mappa URL |
---|---|
Bilanciatore del carico delle applicazioni interno regionale | Mappe URL per regione |
Bilanciatore del carico delle applicazioni interno tra regioni | Mappe URL globali |
Servizio di backend
Un servizio di backend distribuisce le richieste ai backend integri: gruppi di istanze contenenti VM di Compute Engine, Cloud Run o NEG contenenti container GKE.
I servizi di backend supportano i protocolli HTTP, HTTPS o HTTP/2. HTTP/2 è supportato solo su TLS. Client e backend non devono utilizzare lo stesso protocollo di richiesta. Ad esempio, i client possono inviare richieste al bilanciatore del carico utilizzando HTTP/2, e il bilanciatore del carico può inoltrare queste richieste ai backend utilizzando HTTP/1.1.
La seguente tabella specifica il tipo di servizio di backend richiesto dagli Application Load Balancer interni in ogni modalità:
Modalità bilanciatore del carico | Tipo di servizio di backend |
---|---|
Bilanciatore del carico delle applicazioni interno regionale | Servizi di backend regionali |
Bilanciatore del carico delle applicazioni interno tra regioni | Servizi di backend globali |
La seguente tabella specifica le funzionalità di backend supportate dagli Application Load Balancer interni in ogni modalità:
Modalità bilanciatore del carico |
Backend supportati su un servizio di backend | Supporta i bucket di backend | Supporta Google Cloud Armor | Supporta Cloud CDN | Supporta IAP | Supporta le estensioni di servizio | |||||
---|---|---|---|---|---|---|---|---|---|---|---|
Gruppi di istanze | NEG a livello di zona | NEG internet | NEG serverless | NEG ibridi | NEG Private Service Connect | ||||||
Bilanciatore del carico delle applicazioni interno regionale | 1 | Cloud Run |
|||||||||
Bilanciatore del carico delle applicazioni interno tra regioni | 2 | Cloud Run (qualsiasi regione, ma solo una per servizio di backend) |
1 Usa endpoint di tipo GCE_VM_IP_PORT
con GKE:
usa NEG autonomi a livello di zona o
utilizza Ingress
2 Usa endpoint di tipo GCE_VM_IP_PORT
con GKE:
Usa NEG autonomi a livello di zona
Per ulteriori informazioni, consulta la panoramica dei servizi di backend.
Backend e reti VPC
Tutti i backend devono trovarsi nella stessa rete VPC. Il posizionamento dei backend in reti VPC diverse, anche quelli connessi tramite peering di rete VPC, non è supportato. Per maggiori dettagli su come i sistemi client nelle reti VPC in peering possono accedere ai bilanciatori del carico, consulta Bilanciatori del carico delle applicazioni interni e reti connesse.
Creazione di sottoinsiemi di backend
L'addestramento di sottoinsiemi di backend è una funzionalità facoltativa supportata dall'Application Load Balancer interno regionale che migliora le prestazioni e la scalabilità assegnando un sottoinsieme di backend a ciascuna delle istanze del proxy.
Per impostazione predefinita, l'impostazione di sottoinsiemi di backend è disabilitata. Per informazioni sull'abilitazione di questa funzionalità, consulta Creazione di sottoinsiemi di backend per il bilanciatore del carico delle applicazioni interno.
Controlli di integrità
Ogni servizio di backend specifica un controllo di integrità che monitora periodicamente l'idoneità dei backend a ricevere una connessione dal bilanciatore del carico. In questo modo ridurrai il rischio che le richieste vengano inviate a backend che non possono rispondere alla richiesta. I controlli di integrità non controllano se l'applicazione stessa funziona.
Affinché i probe del controllo di integrità abbiano esito positivo, devi creare una regola firewall di autorizzazione in entrata che consenta ai probe del controllo di integrità di raggiungere le istanze di backend. In genere, i probe di controllo di integrità hanno origine dal meccanismo di controllo di integrità centralizzato di Google. Tuttavia, per i NEG ibridi, i controlli di integrità provengono invece dalla subnet solo proxy. Per maggiori dettagli, consulta Controlli di integrità Envoy distribuiti nella panoramica sui NEG ibridi.
Protocollo del controllo di integrità
Sebbene non sia obbligatorio e non sempre possibile, una best practice consiste nell'utilizzare un controllo di integrità il cui protocollo corrisponde al protocollo del servizio di backend. Ad esempio, un controllo di integrità HTTP/2 verifica in modo più accurato la connettività HTTP/2 ai backend. Al contrario, gli Application Load Balancer interni che utilizzano backend NEG ibridi non supportano i controlli di integrità gRPC. Per l'elenco dei protocolli di controllo di integrità supportati, consulta Funzionalità di bilanciamento del carico.
La seguente tabella specifica l'ambito dei controlli di integrità supportati dagli Application Load Balancer interni in ogni modalità:
Modalità bilanciatore del carico | Tipo di controllo di integrità |
---|---|
Bilanciatore del carico delle applicazioni interno regionale | A livello di regione |
Bilanciatore del carico delle applicazioni interno tra regioni | Global |
Per maggiori informazioni sui controlli di integrità, consulta quanto segue:
Regole del firewall
Un bilanciatore del carico delle applicazioni interno richiede le seguenti regole firewall:
- Una regola di autorizzazione in entrata che consente il traffico dagli intervalli di controllo di integrità centrale di Google.
35.191.0.0/16
130.211.0.0/22
- Una regola di autorizzazione in entrata che consente il traffico dalla subnet solo proxy.
Esistono alcune eccezioni ai requisiti delle regole firewall per questi intervalli:
- La lista consentita degli intervalli di probe del controllo di integrità di Google non è necessaria per i NEG ibridi. Tuttavia, se utilizzi una combinazione di NEG ibridi e di zona in un unico servizio di backend, devi inserire nella lista consentita gli intervalli del probe del controllo di integrità di Google per i NEG di zona.
- Per i NEG internet a livello di regione, i controlli di integrità sono facoltativi. Il traffico proveniente da bilanciatori del carico che utilizzano NEG internet a livello di regione ha origine dalla subnet solo proxy e viene quindi tradotto (utilizzando Cloud NAT) in indirizzi IP NAT manuali o allocati automaticamente. Questo traffico include sia i probe di controllo di integrità sia le richieste degli utenti dal bilanciatore del carico ai backend. Per maggiori dettagli, consulta NEG regionali: utilizzare Cloud NAT per il traffico in uscita.
Accesso client
I client possono trovarsi nella stessa rete o in una rete VPC connessa tramite peering di rete VPC.
Per gli Application Load Balancer interni regionali, per impostazione predefinita i client devono trovarsi nella stessa regione del bilanciatore del carico. Puoi abilitare l'accesso globale per consentire ai client di qualsiasi regione di accedere al bilanciatore del carico.
Per gli Application Load Balancer interni tra regioni, l'accesso globale è abilitato per impostazione predefinita. I client di qualsiasi regione possono accedere al bilanciatore del carico.
La seguente tabella riassume l'accesso client per gli Application Load Balancer interni regionali:
Accesso globale disabilitato | Accesso globale attivato |
---|---|
I client devono trovarsi nella stessa regione del bilanciatore del carico. Devono inoltre trovarsi nella stessa rete VPC del bilanciatore del carico o in una rete VPC connessa alla rete VPC del bilanciatore del carico tramite peering di rete VPC. | I client possono trovarsi in qualsiasi regione. Devono comunque trovarsi nella stessa rete VPC del bilanciatore del carico o in una rete VPC connessa alla rete VPC del bilanciatore del carico tramite peering di rete VPC. |
I client on-premise possono accedere al bilanciatore del carico tramite tunnel Cloud VPN o collegamenti VLAN. Questi tunnel o collegamenti devono trovarsi nella stessa regione del bilanciatore del carico. | I client on-premise possono accedere al bilanciatore del carico tramite tunnel Cloud VPN o collegamenti VLAN. Questi tunnel o collegamenti possono trovarsi in qualsiasi regione. |
Architetture di VPC condiviso
I bilanciatori del carico delle applicazioni interni supportano le reti che utilizzano il VPC condiviso. Un VPC condiviso consente alle organizzazioni di connettere risorse di più progetti a una rete VPC comune per comunicare tra loro in modo sicuro ed efficiente utilizzando gli IP interni di quella rete. Se non hai ancora familiarità con il VPC condiviso, leggi la documentazione di panoramica sul VPC condiviso.
Esistono molti modi per configurare un bilanciatore del carico delle applicazioni interno in una rete VPC condiviso. Indipendentemente dal tipo di deployment, tutti i componenti del bilanciatore del carico devono trovarsi nella stessa organizzazione.
Subnet e indirizzo IP | Componenti di frontend | Componenti di backend |
---|---|---|
Crea la rete e le subnet richieste (inclusa la subnet solo proxy) nel progetto host del VPC condiviso. L'indirizzo IP interno del bilanciatore del carico può essere definito nel progetto host o in un progetto di servizio, ma deve utilizzare una subnet nella rete VPC condiviso desiderata nel progetto host. L'indirizzo stesso proviene dall'intervallo IP principale della subnet di riferimento. |
L'indirizzo IP interno a livello di regione, la regola di forwarding, il proxy HTTP(S) di destinazione e la mappa URL associata devono essere definiti nello stesso progetto. Può essere il progetto host o un progetto di servizio. | Puoi eseguire una delle seguenti operazioni:
Ogni servizio di backend deve essere definito nello stesso progetto dei backend a cui fa riferimento. I controlli di integrità associati ai servizi di backend devono essere definiti anche nello stesso progetto del servizio di backend. |
Sebbene sia possibile creare tutti i componenti e i backend di bilanciamento del carico nel progetto host del VPC condiviso, questo tipo di deployment non separa le responsabilità di amministrazione della rete e di sviluppo dei servizi.
Tutti i componenti e i backend del bilanciatore del carico in un progetto di servizio
Il seguente diagramma dell'architettura mostra un deployment di un VPC condiviso standard in cui tutti i componenti e i backend del bilanciatore del carico si trovano in un progetto di servizio. Questo tipo di deployment è supportato da tutti i bilanciatori del carico delle applicazioni.
Il bilanciatore del carico utilizza indirizzi IP e subnet del progetto host. I client possono accedere a un bilanciatore del carico delle applicazioni interno se si trovano nella stessa rete VPC condiviso e nella stessa regione del bilanciatore del carico. I client possono essere trovati nel progetto host, in un progetto di servizio collegato o in qualsiasi rete connessa.
Backend serverless in un ambiente VPC condiviso**
Per un bilanciatore del carico delle applicazioni interno che utilizza un backend NEG serverless, il servizio Cloud Run di supporto deve trovarsi nello stesso progetto di servizio del servizio di backend e del NEG serverless. I componenti frontend del bilanciatore del carico (regola di forwarding, proxy di destinazione, mappa URL) possono essere creati nel progetto host, nello stesso progetto di servizio dei componenti di backend o in qualsiasi altro progetto di servizio nello stesso ambiente VPC condiviso.
Riferimento ai servizi tra progetti
In questo modello, il frontend e la mappa URL del bilanciatore del carico si trovano in un progetto host o di servizio. I backend e i servizi di backend del bilanciatore del carico possono essere distribuiti tra progetti nell'ambiente VPC condiviso. È possibile fare riferimento ai servizi di backend tra progetti in una singola mappa URL. Questo servizio è noto come riferimento al servizio cross-project.
Il riferimento ai servizi tra progetti consente alle organizzazioni di configurare un bilanciatore del carico centrale e instradare il traffico a centinaia di servizi distribuiti in più progetti diversi. Puoi gestire centralmente tutte le regole e i criteri di routing del traffico in un'unica mappa. Puoi anche associare il bilanciatore del carico a un singolo set di nomi host e certificati SSL. Puoi quindi ottimizzare il numero di bilanciatori del carico necessari per eseguire il deployment dell'applicazione e ridurre la gestibilità, i costi operativi e i requisiti di quota.
Creando progetti diversi per ogni team funzionale, puoi anche separare i ruoli all'interno dell'organizzazione. I proprietari dei servizi possono concentrarsi sulla creazione di servizi nei progetti di servizio, mentre i team di rete possono eseguire il provisioning e la manutenzione dei bilanciatori del carico in un altro progetto ed entrambi possono essere connessi utilizzando i riferimenti ai servizi tra progetti.
I proprietari dei servizi possono mantenere l'autonomia durante l'esposizione dei loro servizi e controllare quali utenti possono accedere ai servizi utilizzando il bilanciatore del carico. Ciò è
assegnato a uno speciale ruolo IAM chiamato
ruolo Utente servizi bilanciatore del carico Compute
(roles/compute.loadBalancerServiceUser
).
Limitazioni note con riferimento al servizio tra progetti
- Non puoi fare riferimento a un servizio di backend tra progetti se il servizio di backend ha backend NEG internet regionali. Sono supportati tutti gli altri tipi di backend.
- Google Cloud non fa differenza tra risorse (ad esempio servizi di backend) che utilizzano lo stesso nome in più progetti. Di conseguenza, quando utilizzi il riferimento al servizio tra progetti, ti consigliamo di utilizzare nomi univoci per i servizio di backend in tutti i progetti all'interno dell'organizzazione.
Esempio 1: frontend e backend del bilanciatore del carico in progetti di servizio diversi
Ecco un esempio di deployment in cui la mappa URL e il frontend del bilanciatore del carico vengono creati nel progetto di servizio A e la mappa URL fa riferimento a un servizio di backend nel progetto di servizio B.
In questo caso, gli amministratori di rete o gli amministratori del bilanciatore del carico nel progetto di servizio A richiederanno l'accesso ai servizi di backend nel progetto di servizio B. Gli amministratori del progetto di servizio B concedono il ruolo IAM compute.loadBalancerServiceUser
agli amministratori del bilanciatore del carico nel progetto di servizio A che vogliono fare riferimento al servizio di backend nel progetto di servizio B.
Esempio 2: frontend del bilanciatore del carico nel progetto host e nei backend nei progetti di servizio
In questo tipo di deployment, nel progetto host vengono creati il frontend e la mappa URL del bilanciatore del carico, mentre i servizi di backend (e i backend) vengono creati nei progetti di servizio.
In questo caso, gli amministratori di rete o del bilanciatore del carico nel progetto host richiederanno l'accesso ai servizi di backend nel progetto di servizio. Gli amministratori dei progetti di servizio concedono il ruolo IAM compute.loadBalancerServiceUser
agli amministratori del bilanciatore del carico nel progetto host A che vogliono fare riferimento al servizio di backend nel progetto di servizio.
Timeout e nuovi tentativi
I bilanciatori del carico delle applicazioni interni supportano i seguenti tipi di timeout:Tipo di timeout e descrizione | Valori predefiniti | Supporta valori personalizzati | ||
---|---|---|---|---|
Timeout del servizio di backend
Un timeout di richiesta e risposta. Rappresenta il tempo massimo che può trascorrere da quando il bilanciatore del carico invia il primo byte della richiesta HTTP al backend a quando il backend restituisce l'ultimo byte della risposta HTTP. Se l'intera risposta HTTP non è stata restituita al bilanciatore del carico entro il timeout della richiesta o della risposta, i restanti dati di risposta vengono eliminati. |
|
|||
Timeout keepalive HTTP client
Il periodo di tempo massimo durante il quale la connessione TCP tra un client e il proxy Envoy gestito del bilanciatore del carico può essere inattiva. (La stessa connessione TCP potrebbe essere utilizzata per più richieste HTTP). |
10 minuti (600 secondi) | |||
Timeout keepalive HTTP di backend
Il periodo di tempo massimo durante il quale la connessione TCP tra il proxy Envoy gestito del bilanciatore del carico e un backend può essere inattiva. (La stessa connessione TCP potrebbe essere utilizzata per più richieste HTTP). |
10 minuti (600 secondi) |
Timeout del servizio di backend
Il timeout del servizio di backend configurabile rappresenta la quantità massima di tempo che il bilanciatore del carico attende prima che il backend elabori una richiesta HTTP e restituisca la risposta HTTP corrispondente. Ad eccezione dei NEG serverless, il valore predefinito per il timeout del servizio di backend è 30 secondi.
Ad esempio, se vuoi scaricare un file da 500 MB e il valore del timeout del servizio di backend è di 90 secondi, il bilanciatore del carico prevede che il backend consegni l'intero file da 500 MB entro 90 secondi. È possibile configurare il timeout del servizio di backend in modo che non sia sufficiente affinché il backend invii la sua risposta HTTP completa. In questa situazione, se il bilanciatore del carico ha ricevuto almeno le intestazioni di risposta HTTP dal backend, restituisce le intestazioni della risposta complete e la maggior parte del corpo della risposta possibile entro il timeout del servizio di backend.
Dovresti impostare il timeout del servizio di backend sul periodo di tempo più lungo previsto dal backend per elaborare una risposta HTTP. Dovresti aumentare il timeout del servizio di backend se il software in esecuzione sul tuo backend ha bisogno di più tempo per elaborare una richiesta HTTP e restituire l'intera risposta.
Il timeout del servizio di backend accetta valori compresi tra 1
e 2,147,483,647
secondi. Tuttavia, i valori più grandi non sono opzioni di configurazione pratiche.
Google Cloud non garantisce che una connessione TCP sottostante possa rimanere aperta per l'intero valore del timeout del servizio di backend. I sistemi client devono implementare la logica dei nuovi tentativi invece di affidarsi a una connessione TCP per essere aperta per lunghi periodi di tempo.
Per configurare il timeout del servizio di backend, utilizza uno dei seguenti metodi:
- Console Google Cloud: modifica il campo Timeout del servizio di backend del bilanciatore del carico.
- Google Cloud CLI: usa il comando
gcloud compute backend-services update
per modificare il parametro--timeout
della risorsa del servizio di backend. - API: modifica il parametro
timeoutSec
per la risorsaregionBackendServices
.
Timeout keepalive HTTP client
Il timeout keepalive HTTP del client rappresenta il tempo massimo di inattività di una connessione TCP tra il client (downstream) e un proxy Envoy. Il valore di timeout keepalive HTTP del client è fisso su 600 secondi.
Un timeout keepalive HTTP è anche chiamato timeout di inattività TCP.
Il timeout keepalive HTTP del client del bilanciatore del carico deve essere maggiore del timeout keepalive HTTP (TCP inattivo) utilizzato da client o proxy downstream. Se un client downstream ha un timeout keepalive HTTP maggiore (TCP inattivo) rispetto al timeout keepalive HTTP del client del bilanciatore del carico, è possibile che si verifichi una racecondition. Dal punto di vista di un client downstream, una connessione TCP stabilita può rimanere inattiva per più tempo di quanto consentito dal bilanciatore del carico. Ciò significa che il client downstream può inviare pacchetti dopo che il bilanciatore del carico considera la connessione TCP chiusa. In questo caso, il bilanciatore del carico risponde con un pacchetto di reimpostazione TCP (RST).
Timeout keepalive HTTP di backend
I bilanciatori del carico delle applicazioni interni sono proxy che utilizzano una prima connessione TCP tra il client (downstream) e un proxy Envoy e una seconda connessione TCP tra il proxy Envoy e i tuoi backend.
Le connessioni TCP secondarie del bilanciatore del carico potrebbero non essere chiuse dopo ogni richiesta; possono rimanere aperte per gestire più richieste e risposte HTTP. Il timeout keepalive HTTP di backend definisce il timeout di inattività TCP tra il bilanciatore del carico e i tuoi backend. Il timeout keepalive HTTP di backend non si applica a WebSocket.
Il timeout keepalive del backend è fisso su 10 minuti (600 secondi) e non può essere modificato. Il timeout keepalive del backend del bilanciatore del carico deve essere inferiore al timeout keepalive utilizzato dal software in esecuzione sui tuoi backend. In questo modo si evita una race condition in cui il sistema operativo dei backend potrebbe chiudere le connessioni TCP con una reimpostazione TCP (RST). Poiché il timeout keepalive del backend per il bilanciatore del carico non è configurabile, devi configurare il software di backend in modo che il valore di timeout keepalive HTTP (TCP inattivo) sia maggiore di 600 secondi.
La seguente tabella elenca le modifiche necessarie per modificare i valori di timeout keepalive per il software del server web comune.
Software server web | Parametro | Impostazione predefinita | Impostazione consigliata |
---|---|---|---|
Apache | KeepAliveTimeout | KeepAliveTimeout 5 |
KeepAliveTimeout 620 |
nginx | keepalive_timeout | keepalive_timeout 75s; |
keepalive_timeout 620s; |
Nuovi tentativi
Per configurare i nuovi tentativi, puoi utilizzare un criterio di nuovo tentativo nella mappa URL. Il numero predefinito di nuovi tentativi (numRetries
) è 1.
Il timeout predefinito per ogni tentativo (perTryTimeout
) è di 30 secondi con un valore massimo configurabile di 24 ore per perTryTimeout
.
Senza un criterio per i tentativi, le richieste non riuscite senza un corpo HTTP (ad esempio, richieste GET
) che generano risposte HTTP 502
, 503
o 504
vengono tentate una volta.
Le richieste HTTP POST
non vengono tentate di nuovo.
Le richieste ripetute generano solo una voce di log per la risposta finale.
Per maggiori informazioni, consulta Logging e monitoraggio del bilanciatore del carico delle applicazioni interno.
Accesso alle reti connesse
Puoi accedere a un Application Load Balancer interno nella tua rete VPC da una rete connessa utilizzando quanto segue:
- Peering di rete VPC
- Cloud VPN e Cloud Interconnect
Per esempi dettagliati, consulta Bilanciatori del carico delle applicazioni interni e reti connesse.
Failover
Se un backend non è integro, il traffico viene reindirizzato automaticamente a backend integri.
La tabella seguente descrive il comportamento di failover in ciascuna modalità:
Modalità bilanciatore del carico | Comportamento del failover | Comportamento quando tutti i backend sono in stato non integro |
---|---|---|
Bilanciatore del carico delle applicazioni interno regionale | Failover automatico ai backend integri nella stessa regione. Il proxy Envoy invia il traffico a backend integri in una regione in base alla distribuzione del traffico configurata. |
Restituisce HTTP 503 |
Bilanciatore del carico delle applicazioni interno tra regioni | Failover automatico ai backend integri nella stessa regione o in altre regioni. Il traffico viene distribuito tra backend integri che coprono più regioni in base alla distribuzione del traffico configurata. |
Restituisce HTTP 503 |
Alta disponibilità e failover tra regioni
I bilanciatori del carico delle applicazioni interni tra regioni consentono di migliorare la disponibilità dei servizi creando servizi di backend globali con backend in più regioni. Se i backend in una determinata regione sono inattivi, il traffico viene eseguito correttamente verso un'altra regione.
L'esempio di deployment di failover tra regioni mostra quanto segue:
- Un bilanciatore del carico delle applicazioni interno tra regioni con un indirizzo VIP frontend nella regione
us-west1
della tua rete VPC. I tuoi clienti si trovano anche nella regioneus-west1
. - Un servizio di backend globale che fa riferimento ai backend nelle regioni Google Cloud
us-west1
eus-east1
. - Quando i backend nella regione
us-west1
sono inattivi, il traffico non riesce verso la regioneus-east1
.
I bilanciatori del carico delle applicazioni interni tra regioni possono inoltre proteggere la tua applicazione da interruzioni regionali complete gestendo il traffico al tuo client da proxy e backend in un'altra regione.
L'esempio di deployment ad alta disponibilità mostra quanto segue:
- Un bilanciatore del carico delle applicazioni interno tra regioni con VIP frontend nelle regioni
us-west1
eus-east1
nella tua rete VPC. I tuoi clienti si trovano nella regioneus-west1
. - Puoi rendere accessibile il bilanciatore del carico utilizzando VIP frontend da due regioni e utilizzare i criteri di routing DNS per restituire il VIP ottimale ai tuoi client. Utilizza i criteri di routing della geolocalizzazione se vuoi che i tuoi client utilizzino il VIP geograficamente più vicino.
- I criteri di routing DNS sono in grado di rilevare se un VIP non risponde durante un'interruzione regionale e di restituire ai client il VIP ottimale successivo, garantendo che l'applicazione rimanga attiva anche in caso di interruzioni regionali.
Supporto per WebSocket
I bilanciatori del carico basati su HTTP(S) di Google Cloud supportano integrato il protocollo WebSocket quando si utilizza HTTP o HTTPS come protocollo per il backend. Il bilanciatore del carico non richiede alcuna configurazione per il proxy delle connessioni WebSocket.
Il protocollo WebSocket fornisce un canale di comunicazione full-duplex tra client e server. Una richiesta HTTP(S) avvia il canale. Per informazioni dettagliate sul protocollo, consulta RFC 6455.
Quando il bilanciatore del carico riconosce una richiesta Upgrade
WebSocket da un client HTTP(S) seguita da una risposta Upgrade
riuscita dall'istanza di backend, il bilanciatore del carico esegue il proxy del traffico bidirezionale per la durata della connessione attuale. Se l'istanza di backend non restituisce una risposta Upgrade
riuscita, il bilanciatore del carico chiude la connessione.
L'affinità sessione per WebSocket funziona come per qualsiasi altra richiesta. Per informazioni, consulta Affinità sessione.
Supporto gRPC
gRPC è un framework open source per le chiamate di procedure remote. È basato sullo standard HTTP/2. I casi d'uso di gRPC includono:
- Sistemi distribuiti a bassa latenza e con scalabilità elevata
- Sviluppo di client mobili che comunicano con un server cloud
- Progettare nuovi protocolli che devono essere accurati, efficienti e indipendenti dalla lingua
- Design a più livelli per consentire estensioni, autenticazione e logging
Per utilizzare gRPC con le tue applicazioni Google Cloud, devi eseguire il proxy per le richieste end-to-end su HTTP/2. Per farlo:
- Configurare un bilanciatore del carico HTTPS.
- Abilita HTTP/2 come protocollo dal bilanciatore del carico ai backend.
Il bilanciatore del carico negozia HTTP/2 con i client nell'ambito dell'handshake SSL utilizzando l'estensione TLS ALPN.
Il bilanciatore del carico può comunque negoziare HTTPS con alcuni client o accettare richieste HTTP non sicure su un bilanciatore del carico configurato per l'utilizzo di HTTP/2 tra il bilanciatore del carico e le istanze di backend. Queste richieste HTTP o HTTPS vengono trasformate dal bilanciatore del carico per eseguire il proxy delle richieste tramite HTTP/2 alle istanze di backend.
Devi abilitare TLS sui tuoi backend. Per ulteriori informazioni, consulta Crittografia dal bilanciatore del carico ai backend.
Supporto TLS
Per impostazione predefinita, un proxy di destinazione HTTPS accetta solo TLS 1.0, 1.1, 1.2 e 1.3 quando termina le richieste SSL del client.
Quando l'Application Load Balancer interno utilizza HTTPS come protocollo del servizio di backend, può negoziare TLS 1.0, 1.1, 1.2 o 1.3 con il backend.
Limitazioni
Non c'è alcuna garanzia che una richiesta da un client in una zona della regione venga inviata a un backend che si trova nella stessa zona del client. L'affinità sessione non riduce la comunicazione tra le zone.
I bilanciatori del carico delle applicazioni interni non sono compatibili con le seguenti funzionalità:
Un bilanciatore del carico delle applicazioni interno supporta HTTP/2 solo tramite TLS.
I client che si connettono a un bilanciatore del carico delle applicazioni interno devono utilizzare HTTP 1.1 o versioni successive. HTTP 1.0 non supportato.
Google Cloud non ti avvisa se la tua subnet solo proxy esaurisce gli indirizzi IP.
La regola di forwarding interno utilizzata dal bilanciatore del carico delle applicazioni interno deve avere esattamente una porta.
I bilanciatori del carico delle applicazioni interni non supportano Cloud Trace.
Quando utilizzi un bilanciatore del carico delle applicazioni interno con Cloud Run in un ambiente VPC condiviso, le reti VPC autonome nei progetti di servizio possono inviare traffico a qualsiasi altro servizio Cloud Run di cui è stato eseguito il deployment in qualsiasi altro progetto di servizio all'interno dello stesso ambiente VPC condiviso. Si tratta di un problema noto e questa forma di accesso verrà bloccata in futuro.
Google Cloud non garantisce che una connessione TCP sottostante possa rimanere aperta per l'intero valore del timeout del servizio di backend. I sistemi client devono implementare una logica di nuovo tentativo invece di affidarsi a una connessione TCP per rimanere aperta per lunghi periodi di tempo.
Passaggi successivi
- Per configurare il bilanciamento del carico in una configurazione di un VPC condiviso, consulta Configurare un bilanciatore del carico delle applicazioni interno per il VPC condiviso.
- Per configurare il bilanciamento del carico per i servizi in esecuzione nei pod GKE, consulta Eseguire il deployment di gateway GKE, Bilanciamento del carico nativo del container con NEG autonomi e la sezione Collegamento di un bilanciatore del carico delle applicazioni interno a NEG autonomi.
- Per configurare un bilanciatore del carico delle applicazioni interno regionale con Private Service Connect, consulta Configurazione di Private Service Connect con i controlli del servizio HTTP(S) consumer.
- Per gestire la risorsa della subnet solo proxy, consulta Subnet solo proxy.
- Per configurare l'impostazione di sottoinsiemi di backend su Application Load Balancer interni regionali, consulta Creazione di sottoinsiemi di backend.
- Per inserire una logica personalizzata nel percorso dati del bilanciamento del carico, configura i callout delle estensioni di servizio.