Panoramica del bilanciatore del carico delle applicazioni interno

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

  1. Nella console Google Cloud, vai alla pagina Bilanciamento del carico.

    Vai a Bilanciamento del carico

  2. 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

  1. 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.

Componenti dell'Application Load Balancer interno regionale.
Componenti del bilanciatore del carico delle applicazioni interno regionale (fai clic per ingrandire).

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.

Componenti del bilanciatore del carico delle applicazioni interno tra regioni.
Componenti del bilanciatore del carico delle applicazioni interno tra regioni (fai clic per ingrandire).

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

REGIONAL_MANAGED_PROXY

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

GLOBAL_MANAGED_PROXY

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:

INTERNAL_MANAGED

Subnet solo proxy --purpose:

REGIONAL_MANAGED_PROXY

Indirizzo IP --purpose:

SHARED_LOADBALANCER_VIP

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

Regola di forwarding globale

Indirizzi IP a livello di regione

Schema di bilanciamento del carico:

INTERNAL_MANAGED

Subnet solo proxy --purpose:

GLOBAL_MANAGED_PROXY

Indirizzo IP --purpose:

SHARED_LOADBALANCER_VIP

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:

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:
  • Crea servizi di backend e backend (gruppi di istanze, NEG serverless o qualsiasi altro tipo di backend supportato) nello stesso progetto di servizio dei componenti di frontend.
  • Crea servizi e backend di backend (gruppi di istanze, NEG serverless o altri tipi di backend supportati) nel numero di progetti di servizio necessario. Una singola mappa URL può fare riferimento a servizi di backend in progetti diversi. Questo tipo di deployment è noto come riferimento al servizio cross-project.

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.

Bilanciatore del carico delle applicazioni interno su una rete VPC condiviso
Bilanciatore del carico delle applicazioni interno su VPC condiviso condivisa

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).

Per scoprire come configurare un VPC condiviso per un bilanciatore del carico delle applicazioni interno, con e senza riferimento al servizio tra progetti, consulta Configurare un bilanciatore del carico delle applicazioni interno con VPC condiviso.

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.

Mappa URL e frontend del bilanciatore del carico nel progetto di servizio
frontend e backend del bilanciatore del carico in progetti di servizio diversi

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.

Mappa URL e frontend del bilanciatore del carico nel progetto host
Mappa URL e frontend del bilanciatore del carico nel progetto host

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.

  • Per i NEG serverless su un servizio di backend: 60 minuti
  • Per tutti gli altri tipi di backend su un servizio di backend: 30 secondi
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 le connessioni WebSocket utilizzate con bilanciatori del carico delle applicazioni interni, le connessioni WebSocket attive non seguono il timeout del servizio di backend. Le connessioni WebSocket inattive vengono chiuse dopo il timeout del servizio di backend.

Google Cloud riavvia o modifica periodicamente il numero di attività di gestione del software Envoy. Più lungo è il valore di timeout del servizio di backend, maggiore è la probabilità che l'attività Envoy riavvii o sostituisca la connessione TCP.

Per configurare il timeout del servizio di backend, utilizza uno dei seguenti metodi:

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 regione us-west1.
  • Un servizio di backend globale che fa riferimento ai backend nelle regioni Google Cloud us-west1 e us-east1.
  • Quando i backend nella regione us-west1 sono inattivi, il traffico non riesce verso la regione us-east1.
Bilanciatore del carico delle applicazioni interno tra regioni con deployment di failover tra regioni.
Bilanciatore del carico delle applicazioni interno tra regioni con un deployment di failover tra regioni (fai clic per ingrandire).

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 e us-east1 nella tua rete VPC. I tuoi clienti si trovano nella regione us-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.
Bilanciatore del carico delle applicazioni interno tra regioni con deployment ad alta disponibilità.
Bilanciatore del carico delle applicazioni interno tra regioni con deployment ad alta disponibilità (fai clic per ingrandire).

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:

  1. Configurare un bilanciatore del carico HTTPS.
  2. 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