Questo documento illustra i concetti che devi conoscere 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. La il bilanciatore del carico delle applicazioni interno distribuisce il traffico HTTP e HTTPS ai backend ospitati su delle piattaforme Google Cloud come Compute Engine, Google Kubernetes Engine (GKE) e in Cloud Run. Per maggiori dettagli, vedi Casi d'uso.
Modalità di funzionamento
Puoi configurare un bilanciatore del carico delle applicazioni interno nelle seguenti modalità:
- Bilanciatore del carico delle applicazioni interno tra regioni. Si tratta di un bilanciatore del carico multiregionale viene implementato come servizio gestito sulla base del protocollo open source Envoy proxy. La modalità tra regioni consente di bilanciare il carico del traffico verso i servizi di backend globali distribuiti, compresa la gestione del traffico che ne assicura la indirizzamento il backend più vicino. Questo bilanciatore del carico consente anche l'alta disponibilità. Posizionare i backend in più regioni consente di evitare guasti in una singola regione. Se i backend di una regione non sono disponibili, il traffico può essere eseguito in un'altra regione.
Bilanciatore del carico delle applicazioni interno regionale. Si tratta di un bilanciatore del carico a livello di regione, implementato come servizio gestito sulla base del protocollo open source Envoy proxy. La modalità a livello di regione garantisce che tutti i client e i backend provengano da una regione specificata, il che è utile è necessaria la conformità regionale. Questo bilanciatore del carico è abilitato con funzionalità avanzate di controllo del traffico basate sui parametri HTTP(S). Al termine della configurazione, il bilanciatore del carico alloca automaticamente i proxy Envoy per soddisfare le tue esigenze di traffico.
La seguente tabella descrive le differenze importanti tra le modalità regionali e tra regioni:
Funzionalità Bilanciatore del carico delle applicazioni interno tra regioni Bilanciatore del carico delle applicazioni interno regionale Indirizzo IP virtuale (VIP) del bilanciatore del carico. 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 dei client all'indirizzo VIP più vicino.
Assegnato da una subnet in una regione Google Cloud specifica. Accesso client Sempre accessibile a livello globale. I client di qualsiasi regione Google Cloud in un VPC possono inviare traffico al bilanciatore del carico. Non accessibile a livello globale per impostazione predefinita.
Se vuoi, puoi abilitare l'accesso globale.Backend con bilanciamento del carico Backend globali.
Il bilanciatore del carico può inviare traffico ai backend in qualsiasi regione.Backend regionali.
Il bilanciatore del carico può inviare traffico solo ai backend che si trovano nella stessa regione del proxy del bilanciatore del carico.Alta disponibilità e failover Failover automatico su backend integri nella stessa regione o in regioni diverse. Failover automatico a backend integri nella stessa regione.
Identifica la modalità
console Cloud
Nella console Google Cloud, vai alla pagina Bilanciamento del carico.
Nella scheda Bilanciatori del carico puoi vedere il tipo di bilanciatore del carico, il protocollo e la regione. Se la regione è vuota, il bilanciatore del carico è in modalità interregionale. La tabella seguente riassume come identificare la modalità del bilanciatore del carico.
Modalità del bilanciatore del carico Tipo di bilanciatore del carico Tipo di accesso Regione Bilanciatore del carico delle applicazioni interno regionale Applicazione Interno Specifica una regione Bilanciatore del carico delle applicazioni interno tra regioni Applicazione Interno
gcloud
Per determinare la modalità di un bilanciatore del carico, esegui il seguente comando:
gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
Nell'output comando, controlla lo schema di bilanciamento del carico, la regione e la rete livello. La tabella seguente 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 tra regioni INTERNAL_MANAGED Globale Bilanciatore del carico delle applicazioni interno regionale INTERNAL_MANAGED Regionale
Architettura e risorse
Il seguente diagramma mostra le risorse Google Cloud necessarie per i bilanciatori del carico delle applicazioni interni in ogni modalità:
Tra regioni
Questo diagramma mostra i componenti di un bilanciatore del carico delle applicazioni interno tra regioni il deployment nel livello Premium rete VPC. Ogni regola di inoltro globale utilizza un indirizzo IP regionale utilizzato dai client per la connessione.
Regionale
Questo diagramma mostra i componenti di un bilanciatore del carico delle applicazioni interno regionale il deployment nel livello Premium.
Ogni bilanciatore del carico delle applicazioni interno utilizza le seguenti risorse di configurazione 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 un'istanza una subnet solo proxy in ogni regione di una rete VPC in cui utilizzi dei bilanciatori del carico delle applicazioni interni.
La tabella seguente descrive le differenze tra le subnet solo proxy in modalità regionale e tra regioni:
Modalità del bilanciatore del carico | Valore del flag --purpose della subnet solo proxy |
---|---|
Bilanciatore del carico delle applicazioni interno tra regioni |
GLOBAL_MANAGED_PROXY I bilanciatori del carico regionali e tra 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. Proxy del bilanciatore del carico tra regioni nella stessa regione e nella stessa condivisione di rete la stessa subnet solo proxy. |
Bilanciatore del carico delle applicazioni interno regionale |
REGIONAL_MANAGED_PROXY I bilanciatori del carico a livello di regione e tra regioni non possono condividere le stesse subnet Tutti i bilanciatori del carico basati su Envoy a livello di regione in una regione La rete VPC condivide la stessa subnet solo proxy |
Inoltre:
- Le subnet solo proxy vengono utilizzate solo per i proxy Envoy, non per i backend.
- Le VM di backend o gli endpoint di tutti i bilanciatori del carico delle applicazioni interni in una regione e nella rete VPC ricevono connessioni dalla subnet solo proxy.
- L'indirizzo IP virtuale di un bilanciatore del carico delle applicazioni interno non si trova nella configurazione una subnet. L'indirizzo IP del bilanciatore del carico è definito dalla sua rete di una regola di forwarding, descritta di seguito.
Regola di forwarding e indirizzo IP
Le regole di forwarding instradano il traffico per indirizzo IP, porta e protocollo a una configurazione di bilanciamento del carico che consiste di un proxy di destinazione e di un servizio di backend.
Specifica degli indirizzi IP. Ogni regola di forwarding fa riferimento a una singola regione Indirizzo IP che puoi utilizzare nei record DNS per la tua applicazione. Puoi prenotare un indirizzo IP statico da utilizzare o consentire a Cloud Load Balancing di assegnare una per te. Ti consigliamo di prenotare un indirizzo IP statico. In caso contrario, ogni volta che elimini una regola di inoltro e ne crei una nuova, devi aggiornare il record DNS con l'indirizzo IP temporaneo appena assegnato.
I client utilizzano l'indirizzo IP e la porta per connettersi ai proxy Envoy del bilanciatore del carico. L'indirizzo IP della regola di inoltro è 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 delle protocolli, consulta Funzionalità del bilanciatore del carico.
L'indirizzo IP interno associato alla regola di forwarding può provenire da un nella stessa rete e nella stessa regione dei backend.
Specifica della porta. Ogni regola di forwarding per un bilanciatore del carico delle applicazioni può fare riferimento a una singola porta 1-65535. Per supportare più porte, devi configurare più regole di inoltro. Puoi configurare più regole di forwarding per utilizzare lo stesso indirizzo IP interno (VIP) e fare riferimento allo stesso proxy HTTP(S) di destinazione, purché la configurazione combinazione di indirizzo IP, porta e protocollo è univoca per ogni forwarding personalizzata. In questo modo, puoi utilizzare un singolo bilanciatore del carico con una mappa URL condivisa come proxy per più applicazioni.
La tabella seguente mostra le differenze tra le regole di inoltro nelle modalità regionale 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 tra regioni |
Schema di bilanciamento del carico:
Subnet solo proxy
Indirizzo IP
|
L'accesso globale è abilitato per impostazione predefinita per consentire ai client di qualsiasi regione in un VPC di accedere al bilanciatore del carico. I backend possono trovarsi in più regioni. |
Bilanciatore del carico delle applicazioni interno regionale | Regola di forwarding a livello di regione Schema di bilanciamento del carico:
Subnet solo proxy
Indirizzo IP
|
Puoi abilitare l'accesso globale per autorizzare i clienti di qualsiasi regione in un VPC per accedere al bilanciatore del carico. I backend devono inoltre trovarsi nella stessa regione del bilanciatore del carico. |
Regole di inoltro e reti VPC
Questa sezione descrive come le regole di inoltro utilizzate dai bilanciatori del carico delle applicazioni esterni vengono associate alle reti VPC.
Modalità bilanciatore del carico | Associazione di rete VPC |
---|---|
Bilanciatore del carico delle applicazioni interno tra regioni Bilanciatore del carico delle applicazioni interno regionale |
Gli indirizzi IPv4 interni a livello di regione esistono sempre all'interno delle reti VPC. Quando crei la regola di forwarding, devi specificare la subnet da cui l'IP interno è già in uso. Questa subnet deve trovarsi nella stessa regione una rete VPC in cui una subnet solo proxy è stata è stato creato. Esiste perciò un'associazione di rete implicita. |
Proxy di destinazione
Un proxy HTTP(S) di destinazione termina le connessioni HTTP(S) dai client. Il proxy HTTP(S) consulta la mappa degli URL per determinare come instradare il traffico a di backend. Un proxy HTTPS di destinazione utilizza un certificato SSL per autenticarsi al clienti.
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 la richiesta in entrata non contiene un'intestazione X-Forwarded-For
, questi due indirizzi IP
sono l'intero valore dell'intestazione. Se la richiesta contiene un'intestazioneX-Forwarded-For
, altre informazioni, come gli indirizzi IP registrati dai proxy sulla strada per il bilanciatore del carico, vengono conservate prima dei due indirizzi IP. Il bilanciatore del carico non verifica gli indirizzi IP che precedono il
gli ultimi due indirizzi IP in questa intestazione.
Se esegui un proxy come server di backend, questo proxy in genere aggiunge
ulteriori informazioni nell'intestazione X-Forwarded-For
e il software potrebbe dover
tenere conto di questo. Le richieste proxy dal bilanciatore del carico provengono da un indirizzo IP nella subnet solo proxy e il proxy nell'istanza di backend potrebbe registrare questo indirizzo e l'indirizzo IP dell'istanza di backend.
A seconda del tipo di traffico che la tua applicazione deve gestire, puoi configurare un bilanciatore del carico con un proxy HTTP di destinazione o un proxy HTTPS di destinazione.
La tabella seguente mostra le API proxy target richieste dagli Application Load Balancer interni in ogni modalità:
Proxy di destinazione | Bilanciatore del carico delle applicazioni interno tra regioni | Bilanciatore del carico delle applicazioni interno regionale |
---|---|---|
HTTP | Globale targetHttpProxies |
regionTargetHttpProxies |
HTTPS | Globale targetHttpsProxies |
regionTargetHttpsProxies |
Certificati SSL
I bilanciatori del carico delle applicazioni interni che utilizzano proxy HTTPS di destinazione richiedono chiavi private e certificati SSL nell'ambito della configurazione del bilanciatore del carico.
La tabella seguente specifica il tipo di certificati SSL richiesti da bilanciatori del carico delle applicazioni 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 Certificate Manager supporta i certificati autogestiti a livello di regione e i certificati gestiti da Google. Con Gestore certificati sono supportati 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 | Certificate Manager supporta i certificati autogestiti e i certificati gestiti da Google. Con Gestore certificati sono supportati 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 agli attributi HTTP (ad esempio il percorso della richiesta, i cookie o le 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 operazioni come la riscrittura delle intestazioni, l'invio di reindirizzamenti ai client e la configurazione criteri di timeout, tra gli altri.
Nella tabella seguente viene specificato il tipo di mappa URL richiesta da: bilanciatori del carico delle applicazioni interni in ciascuna modalità:
Modalità del bilanciatore del carico | Tipo di mappa URL |
---|---|
Bilanciatore del carico delle applicazioni interno tra regioni | Mappe URL globali |
Bilanciatore del carico delle applicazioni interno regionale | Mappe degli URL delle regioni |
Servizio di backend
Un servizio di backend fornisce le informazioni di configurazione al bilanciatore del carico in modo che che può indirizzare le richieste ai suoi backend, ad esempio gruppi di istanze Compute Engine o gruppi di endpoint di rete (NEG). Per maggiori informazioni sui servizi di backend, consulta la Panoramica dei servizi di backend.
Ambito del servizio di backend
La tabella seguente indica la risorsa e l'ambito del servizio di backend utilizzati da ciascuna modalità del bilanciatore del carico delle applicazioni interno:
Modalità del bilanciatore del carico | Risorsa del servizio di backend |
---|---|
Bilanciatore del carico delle applicazioni interno tra regioni |
backendServices (a livello globale) |
Bilanciatore del carico delle applicazioni interno regionale |
regionBackendServices (a livello di regione) |
Protocollo per i backend
I servizi di backend per i bilanciatori del carico delle applicazioni devono utilizzare uno dei seguenti protocolli per l'invio di richieste ai backend:
HTTP
, che utilizza HTTP/1.1 e nessun protocollo TLSHTTPS
, che utilizza HTTP/1.1 e TLSHTTP/2
, che utilizza HTTP/2 e TLS (HTTP/2 senza crittografia non è supportato).
Il bilanciatore del carico utilizza solo il protocollo del servizio di backend specificato per comunicare con i suoi backend. Il bilanciatore del carico non utilizza un protocollo diverso se non è in grado di comunicare con i backend utilizzando il protocollo del servizio di backend specificato.
Il protocollo del servizio di backend non deve necessariamente corrispondere a quello utilizzato dai client per comunicare con il bilanciatore del carico. Ad esempio, i client possono inviare richieste al bilanciatore del carico tramite HTTP/2, ma può comunicare che utilizzano HTTP/1.1 (HTTP o HTTPS).
Funzionalità di backend
La tabella seguente specifica le funzionalità di backend supportate dai bilanciatori del carico delle applicazioni interni in ogni modalità.
Modalità bilanciatore del carico |
Backend supportati su un servizio di backend* | Supporta bucket di backend | Supporta Google Cloud Armor | Supporta Cloud CDN | Supporta IAP | Supporta Service Extensions | |||||
---|---|---|---|---|---|---|---|---|---|---|---|
Gruppi di istanze† | NEG a livello di zona‡ | NEG internet | NEG serverless | NEG ibridi | NEG Private Service Connect | ||||||
Bilanciatore del carico delle applicazioni interno tra regioni | Cloud Run |
||||||||||
Bilanciatore del carico delle applicazioni interno regionale | Cloud Run |
* I backend di un servizio di backend devono essere dello stesso tipo: tutte le istanze
gruppi o tutti lo stesso tipo di NEG. Un'eccezione a questa regola è che
GCE_VM_IP_PORT
NEG a livello di zona e NEG ibridi possono essere utilizzati sulla stessa
per supportare un servizio di backend
un'architettura ibrida.
† Combinazioni di impostazioni non gestite a livello di zona, gestite a livello di zona e regionali sono supportati sullo stesso servizio di backend. Quando utilizzi la scalabilità automatica per un gruppo di istanze gestite che è un backend per due o più servizi di backend, configura il criterio di scalabilità automatica del gruppo di istanze in modo che utilizzi più indicatori.
‡ I NEG a livello di zona devono utilizzare endpoint GCE_VM_IP_PORT
.
Backend e reti VPC
Le limitazioni relative alla posizione dei backend dipendono dal tipo di bilanciatore del carico.
Ad esempio gruppi di istanze, NEG a livello di zona e NEG di connettività ibrida, tutti i backend deve trovarsi nello stesso progetto e nella stessa regione del servizio di backend. Tuttavia, un bilanciatore del carico può fare riferimento a un backend che utilizza una rete VPC diversa nello stesso progetto del servizio di backend (questa funzionalità è in anteprima). Connettività tra i carichi di lavoro rete VPC e rete VPC di backend può essere configurato utilizzando il peering di rete VPC, tunnel, collegamenti VLAN di Cloud Interconnect o un Network Connectivity Center il modello di machine learning.
Definizione della rete di backend
- Per i NEG a livello di zona e i NEG ibridi, devi specificare esplicitamente il rete VPC quando crei il NEG.
- Per i gruppi di istanze gestite, la rete VPC è definita il modello di istanza.
- Per i gruppi di istanze non gestite,
La rete VPC è impostata in modo da corrispondere alla rete VPC
dell'interfaccia
nic0
per la prima VM aggiunta al gruppo di istanze.
Requisiti di rete di backend
La rete del backend deve soddisfare una delle seguenti reti requisiti:
La rete VPC del backend deve corrispondere esattamente alla rete VPC della regola di inoltro.
La rete VPC del backend deve essere connessa alla rete VPC della regola di inoltro tramite il peering di rete VPC. Devi configurare gli scambi di route subnet consente la comunicazione tra la subnet solo proxy nella regola di forwarding Rete VPC e subnet utilizzate dalle istanze di backend o endpoint.
- Sia la rete VPC del backend che la rete VPC della regola di forwarding, La rete VPC deve essere VPC spoke sullo stesso Network Connectivity Center . I filtri di importazione ed esportazione devono consentire la comunicazione solo tra proxy nella rete VPC della regola di forwarding e nelle subnet utilizzate dalle istanze di backend o dagli endpoint.
- Per tutti gli altri tipi di backend, tutti i backend devono trovarsi nella stessa rete VPC e nella stessa regione.
Backend e interfacce di rete
Se utilizzi backend di gruppi di istanze, i pacchetti vengono sempre inviati a nic0
. Se
vuoi inviare pacchetti a NIC diverse, utilizza i backend NEG.
Se utilizzi backend NEG a livello di zona, i pacchetti vengono inviati a qualsiasi interfaccia di rete rappresentata dall'endpoint nel NEG. Gli endpoint NEG devono essere nello stesso rete VPC come VPC definito esplicitamente dal NEG in ogni rete.
Sottoinsieme di backend
Il sottoinsieme di backend è una funzionalità facoltativa supportata dal bilanciatore del carico delle applicazioni interno regionale che migliora le prestazioni e la scalabilità assegnando un sottoinsieme di backend a ciascuna delle istanze proxy.
Per impostazione predefinita, l'impostazione secondaria dei backend è disabilitata. Per informazioni sull'abilitazione di questa funzionalità, consulta Impostazione di sottoinsiemi di backend per del carico delle applicazioni interno.
Controlli di integrità
Ogni servizio di backend specifica un controllo di integrità che monitora periodicamente dei backend per ricevere una connessione dal bilanciatore del carico. In questo modo si riduce il rischio che le richieste vengano inviate a backend che non possono gestire la richiesta. I controlli di integrità non controllano se l'applicazione stessa funziona.
Affinché i probe del controllo di integrità abbiano esito positivo, devi creare un'autorizzazione Ingress regola firewall che consente ai probe del controllo di integrità di raggiungere il tuo backend di Compute Engine. In genere, i probe del controllo di integrità provengono dall'integrità centralizzata di Google meccanismo di controllo. Tuttavia, per i gruppi di elenchi di negazioni ibride, i controlli di integrità provengono dalla subnet solo proxy. Per maggiori dettagli, consulta i controlli di integrità di Envoy distribuiti nella panoramica dei NEG ibridi.
Protocollo di controllo di integrità
Sebbene non sia obbligatorio e non sempre possibile, è buona norma utilizza un controllo di integrità il cui protocollo corrisponde a quello del protocollo del backend Google Cloud. Ad esempio, un controllo di integrità HTTP/2 verifica con maggiore precisione la connettività HTTP/2 ai backend. I bilanciatori del carico delle applicazioni interni che utilizzano backend NEG ibridi, invece, non supportano i controlli di integrità gRPC. Per l'elenco dei protocolli di controllo di integrità supportati, consulta Funzionalità di bilanciamento del carico.
La tabella seguente specifica l'ambito dei controlli di integrità supportati dai bilanciatori del carico delle applicazioni interni in ogni modalità:
Modalità del bilanciatore del carico | Tipo di controllo di integrità |
---|---|
Bilanciatore del carico delle applicazioni interno tra regioni | Global |
Bilanciatore del carico delle applicazioni interno regionale | A livello di regione |
Per ulteriori informazioni sui controlli di integrità, consulta quanto segue:
Regole firewall
Un bilanciatore del carico delle applicazioni interno richiede le seguenti regole firewall:
- Una regola di autorizzazione in entrata che consenta il traffico proveniente dal controllo di integrità centrale di Google
più intervalli.
35.191.0.0/16
130.211.0.0/22
Per il traffico IPv6 verso i backend:
2600:2d00:1:b029::/64
- Una regola di autorizzazione in entrata che consente il traffico solo subnet.
Esistono alcune eccezioni ai requisiti delle regole del firewall per questi intervalli:
- L'inserimento nella lista consentita degli intervalli di probe di controllo di integrità di Google non è necessario per i NEG ibridi. Tuttavia, se utilizzi una combinazione di NEG ibridi e a livello di zona un unico servizio di backend, devi inserire nella lista consentita intervalli di probe del controllo di integrità per i NEG a livello di zona.
- Per i NEG internet a livello di regione, i controlli di integrità sono facoltativi. Il traffico proveniente dai bilanciatori del carico che utilizzano NEG internet regionali ha origine dalla subnet solo proxy e viene poi sottoposto a traduzione NAT (utilizzando Cloud NAT) in indirizzi IP NAT manuali o allocati automaticamente. Questo traffico include sia i probe del controllo di integrità sia le richieste degli utenti dal bilanciatore del carico ai backend. Per maggiori dettagli, consulta NEG regionali: utilizzare Cloud NAT per l'egress.
Accesso client
I client possono trovarsi nella stessa rete o in una rete VPC connessa tramite peering di rete VPC.
Per i bilanciatori del carico delle applicazioni interni tra regioni, l'accesso globale è abilitato per impostazione predefinita. Clienti di qualsiasi regione di un VPC può accedere al bilanciatore del carico.
Per i bilanciatori del carico delle applicazioni 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 in un VPC di accedere al tuo bilanciatore del carico.
La tabella seguente riassume l'accesso client per gli Application Load Balancer interni regionali:
Accesso globale disabilitato | Accesso globale abilitato |
---|---|
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 al bilanciatore del carico, tramite peering di rete VPC. | I client possono trovarsi in qualsiasi regione. Tuttavia, devono trovarsi nella stessa rete VPC del bilanciatore del carico o in una rete VPC connessa alla rete VPC del bilanciatore del carico utilizzando il peering di rete VPC. |
I client on-premise possono accedere al bilanciatore del carico tramite Cloud VPN tunnel o collegamenti VLAN. Questi tunnel o attacchi devono trovarsi nella stessa regione del bilanciatore del carico. | I client on-premise possono accedere al bilanciatore del carico tramite tunnel VPN Cloud o collegamenti VLAN. Questi tunnel o collegamenti possono essere in qualsiasi regione. |
Supporto GKE
GKE utilizza i bilanciatori del carico delle applicazioni interni nei seguenti modi:
Gateway interni creati utilizzando il gateway GKE un controller può usare qualsiasi modalità un bilanciatore del carico delle applicazioni interno. Puoi controllare la modalità del bilanciatore del carico scegliendo un'opzione GatewayClass. La Il controller gateway GKE utilizza sempre
GCE_VM_IP_PORT
NEG a livello di zona di backend.Ingress interni creati utilizzando GKE Ingress un controller sono sempre Bilanciatori del carico delle applicazioni interni regionali. Controller GKE Ingress utilizza sempre
GCE_VM_IP_PORT
backend NEG a livello di zona.
- Puoi utilizzare NEG di zona
GCE_VM_IP_PORT
creati e gestiti da GKE Services come backend per qualsiasi bilanciatore del carico delle applicazioni o bilanciatore del carico di rete proxy. Per saperne di più, consulta Caricamento nativo del container del bilanciamento del carico tramite rete NEG.
Architetture 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, in modo che possano comunicare le altre in modo sicuro ed efficiente utilizzando IP interni di quella rete. Se non hai già familiarità con il VPC condiviso, leggi l'articolo sul VPC condiviso panoramica.
Esistono molti modi per configurare un bilanciatore del carico delle applicazioni interno all'interno di una Rete VPC condiviso. Indipendentemente dal tipo di deployment, del bilanciatore del carico devono trovarsi nella stessa organizzazione.
Subnet e indirizzo IP | Componenti del frontend | Componenti di backend |
---|---|---|
Crea la rete e le subnet richieste (inclusa la rete subnet), 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 condivisa desiderata nel progetto host. L'indirizzo stesso arriva 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 deve essere definita nello stesso progetto. Questo progetto può essere il progetto host o un progetto di servizio. | Puoi procedere in uno dei seguenti modi:
Ogni servizio di backend deve essere definito nello stesso progetto come backend a cui fa riferimento. Salute i controlli associati ai servizi di backend devono essere definiti nello stesso anche come servizio di backend. |
Sebbene sia possibile creare tutti i componenti e i backend di bilanciamento del carico progetto host del VPC condiviso, questo tipo di deployment non separa responsabilità di amministrazione di rete e sviluppo dei servizi.
Tutti i componenti e i backend del bilanciatore del carico in un progetto di servizio
Il seguente diagramma di architettura mostra un VPC condiviso standard in cui tutti i componenti e i backend del bilanciatore del carico si trovano in un servizio progetto. Questo tipo di implementazione è supportato da tutti i bilanciatori del carico delle applicazioni.
Il bilanciatore del carico utilizza gli indirizzi IP e le subnet del progetto host. Clienti possono accedere a un bilanciatore del carico delle applicazioni interno se si trovano nella stessa Regione e rete VPC condiviso come bilanciatore del carico. I clienti possono essere che si trovano nel progetto host, in un progetto di servizio collegato oppure connesso reti.
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 deve trovarsi nello stesso progetto di servizio della il servizio di backend e il NEG serverless. I componenti frontend del bilanciatore del carico (regola di inoltro, proxy target, 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.
Riferimenti ai servizi tra progetti
In questo modello, il frontend e la mappa URL del bilanciatore del carico si trovano in un host o in un servizio progetto. I servizi di backend e i backend del bilanciatore del carico possono essere distribuiti tra i progetti nell'ambiente VPC condiviso. Backend tra progetti ai servizi è possibile fare riferimento in una singola mappa URL. Questo è noto come riferimento ai servizi tra progetti.
Il riferimento ai servizi tra progetti consente alle organizzazioni di configurare un bilanciatore del carico centralizzato e instradare il traffico verso centinaia di servizi distribuiti su più progetti diversi. Puoi gestire centralmente tutte le regole e i criteri di routing del traffico in una mappa URL. Puoi anche associare il bilanciatore del carico a un singolo insieme di nomi host e certificati SSL. Puoi quindi ottimizzare di bilanciatori del carico necessari per il deployment dell'applicazione e ridurre gestibilità, costi operativi e requisiti di quota.
Avendo diversi progetti per ogni team funzionale, puoi anche ottenere una separazione dei ruoli all'interno dell'organizzazione. I proprietari di servizi possono concentrarsi sulla creazione di servizi nei progetti di servizi, mentre i team di rete possono eseguire il provisioning e la manutenzione dei bilanciatori del carico in un altro progetto. Entrambi possono essere collegati utilizzando il riferimento ai servizi tra progetti.
I proprietari dei servizi possono mantenere l'autonomia sull'esposizione dei loro servizi e
controlla quali utenti possono accedere ai servizi
usando il bilanciatore del carico. Questo è
da un ruolo IAM speciale chiamato
Ruolo Utente servizi bilanciatore del carico Compute
(roles/compute.loadBalancerServiceUser
).
Limitazioni note relative ai riferimenti ai servizi tra progetti
- Non puoi fare riferimento a un servizio di backend tra progetti se il servizio di backend ha backend NEG internet regionali. Tutti gli altri tipi di backend sono supportati.
- Google Cloud non fa distinzione tra le risorse (ad esempio, di backend) utilizzando lo stesso nome in più progetti. Pertanto, quando utilizzi i riferimenti ai servizi multiprogetto, ti consigliamo utilizza nomi univoci per servizio di backend nei vari progetti dell'organizzazione.
Esempio 1: frontend e backend del bilanciatore del carico in progetti di servizio diversi
Di seguito è riportato 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
richiedono l'accesso ai servizi di backend nel progetto di servizio B. Progetto di servizio B
gli amministratori concedono il ruolo IAM compute.loadBalancerServiceUser
agli amministratori del bilanciatore del carico nel progetto di servizio A che vogliono fare riferimento al backend
nel progetto di servizio B.
Esempio 2: frontend del bilanciatore del carico nel progetto host e backend nei progetti di servizio
In questo tipo di deployment, il frontend e la mappa URL del bilanciatore del carico vengono creati nel progetto host e i servizi di backend (e i backend) vengono create nei progetti di servizio.
In questo caso, gli amministratori di rete o gli amministratori del bilanciatore del carico nel progetto host
richiedono l'accesso ai servizi di backend nel progetto di servizio. Gli amministratori del progetto di servizio devono concedere 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 e descrizione del timeout | Valori predefiniti | Supporta valori personalizzati | |
---|---|---|---|
Tra regioni | Regionale | ||
Timeout del servizio di backend
Un timeout per richiesta e risposta. Rappresenta il tempo massimo consentito tra l'invio da parte del bilanciatore del carico del primo byte di una richiesta al backend e il ritorno da parte del backend dell'ultimo byte della risposta HTTP al bilanciatore del carico. Se il backend non ha restituito l'intero codice HTTP al bilanciatore del carico entro questo limite di tempo, i dati delle risposte vengono eliminati. |
|
||
Timeout keepalive HTTP del client
La quantità di tempo massima che la connessione TCP tra un client e il proxy Envoy gestito del bilanciatore del carico può essere inattivo. La stessa connessione TCP potrebbe essere utilizzata per più richieste HTTP. |
10 minuti (600 secondi) | ||
Timeout keepalive HTTP del backend
Il tempo massimo di inattività della connessione TCP tra il proxy Envoy gestito del bilanciatore del carico e un backend. 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 di attesa del bilanciatore del carico prima che il backend elabori una richiesta HTTP restituiscono la risposta HTTP corrispondente. Fatta eccezione per i NEG serverless, il valore predefinito il valore di 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 è 90 secondi, il bilanciatore del carico si aspetta che il backend invii l'intero file da 500 MB entro 90 secondi. È possibile configurare il timeout del servizio di backend non è sufficiente per consentire al backend di inviare il messaggio completo Risposta HTTP. In questo caso, se il bilanciatore del carico ha ricevuto almeno Intestazioni della risposta HTTP dal backend, il bilanciatore del carico restituisce il testo delle intestazioni della risposta e tutto il corpo della risposta che potrebbe ottenere all'interno dal timeout del servizio di backend.
Devi impostare il timeout del servizio di backend sul periodo di tempo più lungo che prevedi sia necessario al backend per elaborare una risposta HTTP. Devi 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ù elevati non sono opzioni di configurazione pratiche.
Inoltre, Google Cloud non garantisce che una connessione TCP sottostante possa
e rimarranno aperte per tutta la durata del timeout del servizio di backend.
I sistemi client devono implementare una logica per i nuovi tentativi invece di affidarsi a un TCP
la connessione rimanga aperta per lunghi periodi di tempo.
Per configurare il timeout del servizio di backend, utilizza uno dei seguenti metodi:
Console
Modifica il campo Timeout del parametro di servizio di backend.
gcloud
Utilizza il
comando gcloud compute backend-services update
per modificare il parametro --timeout
della risorsa del servizio di backend.
API
Modifica il parametro timeoutSec
per
regionBackendServices
risorsa
Timeout keepalive HTTP del client
Il timeout keepalive HTTP del client rappresenta il tempo massimo che una connessione TCP può essere inattiva tra il client (a valle) e un proxy Envoy. Per il bilanciatore del carico delle applicazioni interno regionale e il bilanciatore del carico delle applicazioni interno tra regioni, il valore predefinito è 600 secondi. Puoi configurare il timeout keepalive HTTP del client con un valore compreso tra 5 e 600 secondi.
Un timeout keepalive HTTP viene chiamato anche timeout di inattività TCP.
Il timeout keepalive HTTP del client del bilanciatore del carico deve essere maggiore del valore Timeout keepalive HTTP (TCP inattivo) utilizzato da client o proxy downstream. Se un client downstream ha un timeout keepalive HTTP (TCP inattivo) maggiore di il timeout keepalive HTTP del client del bilanciatore del carico, è possibile che venga che si verifichi. Dal punto di vista di un client a valle, è consentito che una connessione TCP stabilita rimanga 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 chiusa la connessione TCP. In questo caso, il carico 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 (a valle) e un proxy Envoy e una seconda connessione TCP tra il proxy Envoy e i backend.
Le connessioni TCP secondarie del bilanciatore del carico potrebbero non chiudersi dopo ogni richiesta; possono rimanere aperte per gestire più richieste e risposte HTTP. Il timeout keepalive HTTP del backend definisce il timeout di inattività TCP tra il bilanciatore del carico e i backend. Il timeout keepalive HTTP del backend non si applica ai websocket.
Il timeout keepalive del backend è fissato a 10 minuti (600 secondi) e non può essere modificata. Il backend del bilanciatore del carico Il timeout keepalive deve essere inferiore al timeout keepalive utilizzato dal software in esecuzione sui tuoi backend. In questo modo si evita una condizione di gara in cui il sistema operativo dei tuoi backend potrebbe chiudere le connessioni TCP con un reset 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 del timeout keepalive HTTP (inattività TCP) sia superiore a 600 secondi.
La tabella seguente elenca le modifiche necessarie per modificare i valori del 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 tentativi di nuovo invio, puoi utilizzare un
criterio di nuovo invio nella
mappa URL. Il numero predefinito di nuovi tentativi (numRetries
) è 1.
Il valore massimo configurabile di perTryTimeout
è 24 ore.
Senza un criterio di ripetizione, le richieste non riuscite senza corpo HTTP (ad
esempio, richieste GET
) che restituiscono HTTP 502
, 503
,
o 504
risposte vengono riprovate una volta.
Le richieste HTTP POST
non vengono ripetute.
Le richieste di cui è stato eseguito il riavvio generano una sola voce di log per la risposta finale.
Per ulteriori informazioni, vedi Logging e monitoraggio del bilanciatore del carico delle applicazioni interno.
Accesso alle reti connesse
I tuoi clienti possono accedere a un bilanciatore del carico delle applicazioni interno nella tua rete VPC da una rete connessa, utilizzando:
- 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 ai backend integri.
La tabella seguente descrive il comportamento del failover in ogni modalità:
Modalità bilanciatore del carico | Comportamento di failover | Comportamento quando tutti i backend non sono integri |
---|---|---|
Bilanciatore del carico delle applicazioni interno tra regioni | Failover automatico su backend integri nello stesso o in altre regioni. Il traffico è distribuito tra backend integri che coprono più regioni in base al della distribuzione del traffico. |
Restituisce HTTP 503 |
Bilanciatore del carico delle applicazioni interno regionale | Failover automatico su backend integri nella stessa regione. Il proxy Envoy invia il traffico a backend integri in una regione in base a configurato della distribuzione del traffico. |
Restituisce HTTP 503 |
Alta disponibilità e failover tra regioni
Per bilanciatori del carico delle applicazioni interni regionali
Per ottenere una disponibilità elevata, esegui il deployment di più istanze Application Load Balancer interni regionali nelle regioni che supportano al meglio per via del traffico. Quindi utilizzerai un routing di geolocalizzazione di Cloud DNS per rilevare se un bilanciatore del carico risponde durante una regione o un'interruzione del servizio. Un criterio di geolocalizzazione instrada il traffico alla successiva regione disponibile più vicina in base all'origine della richiesta del cliente. Il controllo di integrità è disponibile predefinita per i bilanciatori del carico delle applicazioni interni.
Per i bilanciatori del carico delle applicazioni interni tra regioni
Puoi configurare un bilanciatore del carico delle applicazioni interno tra regioni in più regioni per ottenere quanto segue vantaggi:
In caso di errore del bilanciatore del carico delle applicazioni interno tra regioni in una regione, i criteri di routing del DNS instradare il traffico a un bilanciatore del carico delle applicazioni interno tra regioni in un'altra regione.
L'esempio di deployment ad alta disponibilità mostra quanto segue:
- Un bilanciatore del carico delle applicazioni interno tra regioni con indirizzo IP virtuale (VIP) frontend nelle regioni
RegionA
eRegionB
della tua rete VPC. I tuoi clienti si trovano nella regioneRegionA
. - Puoi rendere accessibile il bilanciatore del carico utilizzando VIP frontend di due regioni e utilizzare i criteri di routing DNS per restituire il VIP ottimale ai tuoi client. Utilizzare Routing di geolocalizzazione norme se vuoi che i tuoi clienti utilizzino il VIP geograficamente più vicino.
- I criteri di routing del DNS possono rilevare se un VIP non risponde durante a livello di regione e restituire il successivo VIP ottimale ai tuoi client, assicurando che l'applicazione rimanga attiva anche durante le interruzioni regionali.
- Un bilanciatore del carico delle applicazioni interno tra regioni con indirizzo IP virtuale (VIP) frontend nelle regioni
Se i backend di una determinata regione non sono attivi, il traffico del bilanciatore del carico delle applicazioni interno tra regioni viene trasferito in modo corretto ai backend di un'altra regione.
L'esempio di implementazione del failover tra regioni mostra quanto segue:
- Un bilanciatore del carico delle applicazioni interno tra regioni con un indirizzo VIP frontend in
RegionA
della tua rete VPC. I tuoi clienti si trovano anche nella regioneRegionA
. - Un servizio di backend globale che fa riferimento ai backend nelle regioni Google Cloud
RegionA
eRegionB
. - Quando i backend nella regione
RegionA
sono inattivi, il traffico esegue il failover nella regioneRegionB
.
- Un bilanciatore del carico delle applicazioni interno tra regioni con un indirizzo VIP frontend in
Supporto WebSocket
I bilanciatori del carico basati su HTTP(S) di Google Cloud supportano il protocollo WebSocket quando utilizzi HTTP o HTTPS come protocollo per il backend. Il bilanciatore del carico non richiede alcuna configurazione per il proxy di WebSocket e connessioni a Internet.
Il protocollo websocket fornisce un canale di comunicazione full-duplex tra e il bilanciatore del carico. Per maggiori informazioni, consulta la RFC 6455.
Il protocollo WebSocket funziona nel seguente modo:
- Il bilanciatore del carico riconosce una richiesta WebSocket
Upgrade
da un client HTTP(S). La richiesta contieneConnection: Upgrade
,Upgrade: websocket
, seguite da altre intestazioni WebSocket pertinenti intestazioni delle richieste. - Il backend invia una risposta
Upgrade
di WebSocket. L'istanza di backend invia una risposta101 switching protocol
con intestazioniConnection: Upgrade
,Upgrade: websocket
e altre intestazioni di risposta relative a websocket. - Il bilanciatore del carico esegue il proxy del traffico bidirezionale per la durata del connessione corrente.
Se l'istanza di backend restituisce una risposta di errore con
codice di risposta 426
o 502
, il bilanciatore del carico chiude la connessione.
L'affinità sessione per i websocket funziona come per qualsiasi altra richiesta. Per ulteriori informazioni, consulta Affinità della sessione.
Supporto gRPC
gRPC è un framework open source per le chiamate di procedura remota. Si basa sullo standard HTTP/2. I casi d'uso di gRPC includono:
- Sistemi distribuiti a bassa latenza e altamente scalabili
- Sviluppo di client mobile che comunicano con un server cloud
- Progettazione di nuovi protocolli che devono essere accurati, efficienti e indipendenti dal linguaggio
- Design a più livelli per abilitare estensioni, autenticazione e logging
Per utilizzare gRPC con le tue applicazioni Google Cloud, devi eseguire il proxy 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 potrebbe comunque negoziare HTTPS con alcuni client o accettare richieste HTTP non sicure su un bilanciatore del carico configurato per utilizzare HTTP/2 tra il bilanciatore del carico e le istanze di backend. Gli indirizzi HTTP o HTTPS vengono trasformate dal bilanciatore del carico per eseguirne il proxy su HTTP/2 alle istanze di backend.
Devi attivare TLS sui tuoi backend. Per ulteriori informazioni, consulta l'articolo Crittografia da 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 terminando le richieste SSL del client.
Quando il bilanciatore del carico delle applicazioni interno utilizza HTTPS come protocollo del servizio di backend, può negoziare TLS 1.0, 1.1, 1.2 o 1.3 al backend.
Limitazioni
Non c'è alcuna garanzia che una richiesta da un client in una zona della regione viene inviato a un backend che si trova nella stessa zona del client. L'affinità di 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 su TLS.
I client che si connettono a un bilanciatore del carico delle applicazioni interno devono utilizzare HTTP versione 1.1 o in un secondo momento. HTTP 1.0 non è supportato.
Google Cloud non ti avvisa se il server solo proxy e la subnet VPC esaurisce gli indirizzi IP.
La regola di forwarding interno utilizzata dal bilanciatore del carico delle applicazioni interno deve avere esattamente su una porta.
I bilanciatori del carico delle applicazioni interni non supportano Cloud Trace.
Quando utilizzi un bilanciatore del carico delle applicazioni interno con in Cloud Run in un ambiente VPC condiviso, reti VPC autonome nei progetti di servizio può inviare traffico a qualsiasi altro servizio Cloud Run con deployment in altri progetti di servizio all'interno dello stesso VPC condiviso completamente gestito di Google Cloud. Questo è un problema noto e questa forma di accesso verrà bloccata in per il futuro.
Google Cloud non garantisce che una connessione TCP di base possa rimanere aperta per l'intero valore del timeout del servizio di backend. I sistemi client devono implementare una logica per i nuovi tentativi invece di affidarsi a un TCP la connessione rimanga aperta per lunghi periodi di tempo.
Passaggi successivi
- Per configurare il bilanciamento del carico in una configurazione di VPC condiviso, consulta Configurare un bilanciatore del carico delle applicazioni interno per VPC condiviso.
- Per configurare il bilanciamento del carico per i servizi in esecuzione su GKE sui pod, consulta Deployment di gateway GKE. Bilanciamento del carico nativo del container con funzionalità NEG e Collegare un bilanciatore del carico delle applicazioni interno a un ambiente NEG.
- Per configurare un bilanciatore del carico delle applicazioni interno regionale con Private Service Connect, consulta Configurazione di Private Service Connect con i controlli di servizio HTTP(S) consumer.
- Per gestire la risorsa subnet solo proxy, consulta Subnet solo proxy.
- Per configurare l'impostazione secondaria del backend sui bilanciatori del carico delle applicazioni interni regionali, consulta Impostazione secondaria del backend.
- Per inserire logica personalizzata nel percorso dei dati per il bilanciamento del carico, configurare i callout di Service Extensions.