Panoramica del bilanciatore del carico di rete passthrough interno

Un bilanciatore del carico di rete passthrough interno è un bilanciatore del carico regionale basato sullo stack di virtualizzazione di rete Andromeda.

I bilanciatori del carico di rete passthrough interni distribuiscono il traffico tra le istanze di macchine virtuali (VM) interne nella stessa regione in una rete Virtual Private Cloud (VPC). Ti consente di eseguire e scalare i servizi dietro un indirizzo IP interno accessibile solo ai sistemi nella stessa rete VPC o ai sistemi collegati alla tua rete VPC.

Utilizza un bilanciatore del carico di rete passthrough interno nelle seguenti circostanze:

• Hai bisogno di un bilanciatore del carico di livello 4 passthrough ad alte prestazioni per i protocolli TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE.
• Se servi il traffico tramite TLS (SSL), è accettabile che il traffico SSL venga terminato dai tuoi backend anziché dal bilanciatore del carico. Il bilanciatore del carico di rete passthrough interno non può terminare il traffico SSL.
• Devi inoltrare i pacchetti originali senza proxy. Ad esempio, se devi conservare l'indirizzo IP di origine del client.
• Hai una configurazione esistente che utilizza un bilanciatore del carico passthrough e vuoi eseguirne la migrazione senza modifiche.

I bilanciatori del carico di rete passthrough interni soddisfano molti casi d'uso. Per alcuni esempi di alto livello, consulta la Panoramica del bilanciatore del carico di rete passthrough.

Come funzionano i bilanciatori del carico di rete passthrough interni

Un bilanciatore del carico di rete passthrough interno ha un frontend (la regola di forwarding) e un backend (il servizio di backend). Puoi utilizzare gruppi di istanze o GCE_VM_IP NEG a livello di zona come backend nel servizio di backend. Questo esempio mostra i backend del gruppo di istanze.

A differenza di un bilanciatore del carico proxy, un bilanciatore del carico di rete passthrough interno non termina le connessioni dai client e poi apre nuove connessioni ai backend. Un bilanciatore del carico di rete passthrough interno, invece, instrada le connessioni direttamente dai client ai backend funzionanti, senza interruzioni. Le risposte delle VM di backend funzionanti vengono inviate direttamente ai client, non tramite il bilanciatore del carico. Le risposte TCP utilizzano il ritorno diretto del server. Per ulteriori informazioni, consulta la sezione Pacchetti di richiesta e risposta TCP e UDP.

Il bilanciatore del carico monitora l'integrità del backend utilizzando i probe del controllo di integrità. Per ulteriori informazioni, consulta la sezione Controllo di integrità.

L'ambiente guest Linux, l'ambiente guest Windows o un processo equivalente configura ogni VM di backend con l'indirizzo IP del bilanciatore del carico. Per le VM create dalle immagini Google Cloud, l'agente ospite (in precedenza Ambiente ospite Windows o Ambiente ospite Linux) installa la route locale per l'indirizzo IP del bilanciatore del carico. Le istanze Google Kubernetes Engine basate su Container-Optimized OS implementano questa funzionalità utilizzando iptables.

La rete virtuale di Google Cloud gestisce la distribuzione e la scalabilità del traffico in base alle esigenze.

Protocolli, schema e ambito

Ogni bilanciatore del carico di rete passthrough interno supporta quanto segue:

• Un servizio di backend con schema di bilanciamento del carico INTERNAL e un protocollo supportato. Per ulteriori informazioni, consulta Servizio di backend.
• VM di backend specificate come una delle seguenti:
  • Gruppi di istanze gestite e non gestite che si trovano in una regione e in una rete VPC.
  • Gruppi di endpoint di rete a livello di zona (NEG) di backend con endpoint di tipo GCE_VM_IP che si trovano nella stessa regione e nella stessa rete VPC. Gli endpoint nel gruppo di elenchi di negazioni devono essere indirizzi IP interni principali nella stessa subnet e nella stessa zona utilizzati dal gruppo di elenchi di negazioni.
• Supporto del traffico IPv4 e IPv6 quando si utilizzano i backend del gruppo di istanze. I gruppi di endpoint di rete a livello di zona (NEG) con endpoint GCE_VM_IP supportano solo il traffico IPv4.
• Una o più regole di inoltro, ciascuna delle quali utilizza il protocollo TCP, UDP o L3_DEFAULT corrispondente al protocollo del servizio di backend.
• Ogni regola di forwarding con il proprio indirizzo IP univoco o più regole di forwarding che condividono un indirizzo IP comune.
• Ogni regola di forwarding con fino a cinque porte o tutte le porte.
• Se è abilitato l'accesso globale, i client in qualsiasi regione.
• Se l'accesso globale è disattivato, i client nella stessa regione del bilanciatore del carico.

Un bilanciatore del carico di rete passthrough interno non supporta:

• VM di backend in più regioni.
• Bilancia il traffico proveniente da internet, a meno che non lo utilizzi con un bilanciatore del carico esterno.
• Pacchetti IPv6 con intestazioni frammentate.

Accesso client

Per impostazione predefinita, il bilanciatore del carico supporta solo i client che si trovano nella stessa regione del bilanciatore del carico. I client possono trovarsi nella stessa rete del bilanciatore del carico o in una rete VPC connessa tramite il peering di rete VPC. Puoi abilitare l'accesso globale per consentire ai client di qualsiasi regione di accedere al tuo bilanciatore del carico di rete passthrough interno.

La tabella seguente riassume l'accesso dei client.

Accesso globale disattivato	Accesso globale abilitato
I client devono trovarsi nella stessa regione del bilanciatore del carico. Inoltre, devono essere nella stessa rete VPC del bilanciatore del carico o in una rete VPC connessa alla rete VPC del bilanciatore del carico tramite il 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 tunnel VPN Cloud 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 Cloud VPN o collegamenti VLAN. Questi tunnel o allegati possono trovarsi in qualsiasi regione.

Indirizzi IP per i pacchetti di richiesta e risposta

Quando una VM di backend riceve un pacchetto con bilanciamento del carico da un client, la fonte e la destinazione del pacchetto sono:

• Origine:l'IPv4 interno del cliente, l'IPv6 o l'indirizzo IPv4 di uno degli intervalli IPv4 dell'alias del cliente.
• Destinazione:l'indirizzo IP della regola di forwarding del bilanciatore del carico. La regola di forwarding utilizza un singolo indirizzo IPv4 interno o un intervallo IPv6 interno.

Poiché il bilanciatore del carico è un bilanciatore del carico passthrough (non un proxy), i pacchetti arrivano con l'indirizzo IP di destinazione della regola di inoltro del bilanciatore del carico. Il software in esecuzione sulle VM di backend deve essere configurato per:

• Ascolta (associa a) l'indirizzo IP della regola di forwarding del bilanciatore del carico o a qualsiasi indirizzo IP (0.0.0.0 o ::)
• Se il protocollo della regola di inoltro del bilanciatore del carico supporta le porte: ascolta su (associa a) una porta inclusa nella regola di forwarding di inoltro del bilanciatore del carico

I pacchetti di ritorno vengono inviati direttamente dalle VM di backend del bilanciatore del carico al client. Gli indirizzi IP di origine e di destinazione del pacchetto di ritorno dipendono dal protocollo:

• Il protocollo TCP è orientato alla connessione, pertanto le VM di backend devono rispondere con pacchetti i cui indirizzi IP di origine corrispondono all'indirizzo IP della regola di forwarding in modo che il client possa associare i pacchetti di risposta alla connessione TCP appropriata.
• UDP è senza connessione, quindi le VM di backend possono inviare pacchetti di risposta cuyos indirizzi IP di origine corrispondono all'indirizzo IP della regola di forwarding o a qualsiasi indirizzo IP assegnato alla VM. In pratica, la maggior parte dei client si aspetta che la risposta provenga dallo stesso indirizzo IP a cui ha inviato i pacchetti.

La tabella seguente riassume le origini e le destinazioni per i pacchetti di risposta:

Tipo di traffico	Origine	Destinazione
TCP	L'indirizzo IP della regola di forwarding del bilanciatore del carico	L'origine del pacchetto che effettua la richiesta
UDP	Per la maggior parte dei casi d'uso, l'indirizzo IP della regola di forwarding del bilanciatore del carico †	L'origine del pacchetto che effettua la richiesta

Architettura

Un bilanciatore del carico di rete passthrough interno con più backend distribuisce le connessioni tra tutti questi backend. Per informazioni sul metodo di distribuzione e sulle relative opzioni di configurazione, consulta la sezione Distribuzione del traffico.

Puoi utilizzare gruppi di istanze o NEG di zona, ma non una combinazione di entrambi, come backend per un bilanciatore del carico di rete passthrough interno:

• Se scegli i gruppi di istanze, puoi utilizzare gruppi di istanze non gestite, gruppi di istanze gestite a livello di zona, gruppi di istanze gestite a livello di regione o una combinazione di tipi di gruppi di istanze.
• Se scegli i NEG a livello di zona, devi utilizzare GCE_VM_IP NEG a livello di zona.

Disponibilità elevata descrive come progettare un bilanciatore del carico interno che non dipende da una singola zona.

Le istanze che partecipano come VM di backend per i bilanciatori del carico di rete passthrough interni devono eseguire l'ambiente guest Linux o Windows appropriato o altri processi che forniscono funzionalità equivalenti. Questo ambiente guest deve essere in grado di contattare il server dei metadati (metadata.google.internal, 169.254.169.254) per leggere i metadati dell'istanza in modo da poter generare route locali per accettare il traffico inviato all'indirizzo IP interno del bilanciatore del carico.

Questo diagramma illustra la distribuzione del traffico tra le VM situate in due gruppi di istanze distinti. Il traffico inviato dall'istanza client all'indirizzo IP del bilanciatore del carico (10.10.10.9) viene distribuito tra le VM di backend in entrambi i gruppi di istanze. Le risposte inviate da qualsiasi VM di backend di servizio vengono inviate direttamente alla VM client.

Puoi utilizzare un bilanciatore del carico di rete passthrough interno con una rete VPC in modalità personalizzata o automatica. Puoi anche creare bilanciatori del carico di rete passthrough interni con una rete precedente esistente.

Un bilanciatore del carico di rete passthrough interno è costituito dai seguenti componenti di Google Cloud.

Componente	Finalità	Requisiti
Indirizzo IP interno	Questo è l'indirizzo del bilanciatore del carico.	L'indirizzo IP interno deve trovarsi nella stessa subnet della regola di forwarding interna. La subnet deve trovarsi nella stessa regione e nella stessa rete VPC del servizio di backend.
Regola di inoltro interno	Una regola di forwarding interna in combinazione con l'indirizzo IP interno costituisce il frontend del bilanciatore del carico. Definisce il protocollo e le porte accettati dal bilanciatore del carico e indirizza il traffico a un servizio di backend interno regionale.	Le regole di inoltro per i bilanciatori del carico di rete passthrough interni devono: • Avere un load-balancing-scheme di INTERNAL. • Utilizza un ip-protocol di TCP o UDP, corrispondente al protocol del servizio di backend. • Fai riferimento a un subnet nella stessa rete VPC e nella stessa regione del servizio di backend.
Servizio di backend interno regionale	Il servizio di backend interno regionale definisce il protocollo utilizzato per comunicare con i backend e specifica un controllo di integrità. I backend possono essere gruppi di istanze non gestite, gruppi di istanze gestite per zona, gruppi di istanze gestite a livello di regione o NEG zonali con endpoint GCE_VM_IP.	Il servizio di backend deve: • Avere un load-balancing-scheme di INTERNAL. • Utilizza un protocol di TCP o UDP, corrispondente al ip-protocol della regola di forwarding. • Avere un controllo di integrità associato. • Avere una regione associata. La regola di forwarding e tutti i backend devono trovarsi nella stessa regione del servizio di backend • Essere associati a una singola rete VPC. Se non viene specificata, la rete viene dedotta in base alla rete utilizzata dall'interfaccia di rete predefinita (nic0) di ogni VM di backend. Sebbene il servizio di backend non sia associato a una subnet specifica, la subnet della regola di regola di forwarding deve trovarsi nella stessa rete VPC del servizio di backend.
Controllo di integrità	A ogni servizio di backend deve essere associato un controllo di integrità. Il controllo di integrità definisce i parametri in base ai quali Google Cloud considera idonei a ricevere il traffico i backend che gestisce. Solo le VM di backend attive ricevono il traffico inviato dalle VM client all'indirizzo IP del bilanciatore del carico.	Anche se la regola di forwarding e il servizio di backend possono utilizzare TCP o UDP, Google Cloud non dispone di un controllo di integrità per il traffico UDP. Per ulteriori informazioni, consulta Controlli di integrità e traffico UDP.

Un bilanciatore del carico di rete passthrough interno non supporta:

• VM di backend in più regioni.
• Bilancia il traffico proveniente da internet, a meno che non lo utilizzi con un bilanciatore del carico esterno.
• Pacchetti IPv6 con intestazioni frammentate.

Indirizzo IP interno

I bilanciatori del carico di rete passthrough interni supportano subnet solo IPv4 (stack singolo) e IPv4 e IPv6 (stack doppio). Per ulteriori informazioni, consulta Tipi di sottorete.

Un bilanciatore del carico di rete passthrough interno richiede almeno una regola di forwarding. La regola di forwarding fa riferimento all'indirizzo IP interno:

• Per il traffico IPv4, la regola di forwarding fa riferimento a un indirizzo IPv4 dell'intervallo della subnet IPv4 principale.
• Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo di /96 indirizzi IPv6 interni dell'intervallo di indirizzi IPv6 interno /64 della subnet. La subnet deve essere una subnet a doppio stack con un intervallo di indirizzi IPv6 interno (ipv6-access-type impostato su INTERNAL).

Configurazione del firewall

I bilanciatori del carico di rete passthrough interni richiedono la seguente configurazione per i criteri firewall gerarchici e le regole firewall VPC:

• Consenti l'ingresso da intervalli di origine del controllo di integrità IPv4 o IPv6.
• Consenti l'ingresso da intervalli di origine degli indirizzi IPv4 o IPv6 dei client.

Per ulteriori informazioni, consulta la sezione Configurare le regole del firewall.

Regole di forwarding

Una regola di inoltro specifica il protocollo e le porte su cui il bilanciatore del carico accetta il traffico. Poiché i bilanciatori del carico di rete passthrough interni non sono proxy, trasmettono il traffico ai backend sulla stessa porta e con lo stesso protocollo.

Un bilanciatore del carico di rete passthrough interno richiede almeno una regola di forwarding interna. Puoi definire più regole di inoltro per lo stesso bilanciatore del carico.

Se vuoi che il bilanciatore del carico gestisca sia il traffico IPv4 che IPv6, crea due regole di inoltro: una per il traffico IPv4 che rimanda ai backend IPv4 (o a doppio stack) e una per il traffico IPv6 che rimanda solo ai backend a doppio stack. È possibile che una regola di inoltro IPv4 e una regola di forwarding IPv6 facciano riferimento allo stesso servizio di backend, ma il servizio di backend deve fare riferimento a backend dual-stack.

La regola di forwarding deve fare riferimento a una subnet specifica nella stessa rete VPC e nella stessa regione dei componenti di backend del bilanciatore del carico. Questo requisito ha le seguenti implicazioni:

• La subnet specificata per la regola di forwarding non deve essere uguale a nessuna delle subnet utilizzate dalle VM di backend, ma deve trovarsi nella stessa regione della regola di forwarding.
• Per il traffico IPv4, la regola di forwarding interno fa riferimento all'indirizzo IPv4 interno regionale dell'intervallo di indirizzi IPv4 principale della subnet selezionata. Questo indirizzo IPv4 può essere selezionato automaticamente o puoi utilizzare un indirizzo IPv4 statico (riservato).
• Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo /96 di indirizzi IPv6 dall'intervallo di indirizzi IPv6 interno della subnet. La subnet deve essere una subnet a doppio stack con ipv6-access-type impostato su INTERNAL. L'intervallo di indirizzi IPv6 /96 viene assegnato automaticamente o puoi utilizzare un indirizzo IP interno riservato.

Protocolli delle regole di forwarding

I bilanciatori del carico di rete passthrough interni supportano le seguenti opzioni di protocollo IPv4 per ogni regola di forwarding: TCP, UDP o L3_DEFAULT.

I bilanciatori del carico di rete passthrough interni supportano le seguenti opzioni di protocollo IPv6 per ogni regola di forwarding: TCP o UDP.

L'opzione L3_DEFAULT ti consente di bilanciare il carico dei protocolli TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE.

Oltre a supportare protocolli diversi da TCP e UDP, l'opzione L3_DEFAULT consente a una singola regola di forwarding di inoltrare contemporaneamente il traffico per più protocolli. Ad esempio, oltre a inviare richieste HTTP, puoi anche eseguire un ping all'indirizzo IP del bilanciatore del carico.

Le regole di inoltro che utilizzano i protocolli TCP o UDP possono fare riferimento a un servizio di backend utilizzando lo stesso protocollo della regola di forwarding o un servizio di backend che utilizza il protocollo UNSPECIFIED.

Se utilizzi il protocollo L3_DEFAULT, devi configurare la regola di inoltro in modo che accetti il traffico su tutte le porte. Per configurare tutte le porte, imposta --ports=ALL utilizzando Google Cloud CLI oppure imposta allPorts su True utilizzando l'API.

La seguente tabella riassume come utilizzare queste impostazioni per diversi protocolli:

Traffico da bilanciare	Protocollo della regola di forwarding	Protocollo del servizio di backend
TCP (IPv4 o IPv6)	TCP	TCP or UNSPECIFIED
UDP (IPv4 o IPv6)	UDP	UDP or UNSPECIFIED
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE	L3_DEFAULT	UNSPECIFIED

Regole di forwarding e accesso globale

Le regole di inoltro di un bilanciatore del carico di rete passthrough interno sono a livello di regione, anche se è abilitato l'accesso globale. Dopo aver attivato l'accesso globale, il flag allowGlobalAccess della regola di inoltro interno regionale è impostato su true.

Regole di inoltro e specifiche delle porte

Quando crei una regola di forwarding interno, devi scegliere una delle seguenti specifiche di porta:

• Specifica almeno una e fino a cinque porte, in base al numero.
• Specifica ALL per inoltrare il traffico su tutte le porte.

Una regola di forwarding interna che supporta tutte le porte TCP o tutte le porte UDP consente alle VM di backend di eseguire più applicazioni, ciascuna sulla propria porta. Il traffico inviato a una determinata porta viene inviato all'applicazione corrispondente e tutte le applicazioni utilizzano lo stesso indirizzo IP.

Quando devi inoltrare il traffico su più di cinque porte specifiche, combina le regole del firewall con le regole di inoltro. Quando crei la regola di forwarding, specifica tutte le porte e poi crea regole firewall allow in entrata che consentano il traffico solo alle porte desiderate. Applica le regole firewall alle VM di backend.

Non puoi modificare una regola di forwarding dopo averla creata. Se devi modificare le porte specificate o l'indirizzo IP interno per una regola di forwarding interno, devi eliminarla e ricrearla.

Più regole di inoltro per un singolo servizio di backend

Puoi configurare più regole di forwarding interno che fanno tutte riferimento allo stesso servizio di backend interno. Un bilanciatore del carico di rete passthrough interno richiede almeno una regola di forwarding interna.

La configurazione di più regole di inoltro per lo stesso servizio di backend ti consente di svolgere le seguenti operazioni:

• Assegna più indirizzi IP al bilanciatore del carico. Puoi creare più regole di inoltro, ciascuna con un indirizzo IP univoco. Ogni regola di forwarding può specificare tutte le porte o un insieme di massimo cinque porte.

• Assegna un insieme specifico di porte, che utilizzano lo stesso indirizzo IP, al bilanciatore del carico. Puoi creare più regole di inoltro che condividono lo stesso indirizzo IP, in cui ogni regola di forwarding utilizza un insieme specifico di massimo cinque porte. Si tratta di un'alternativa alla configurazione di una singola regola di forwarding che specifica tutte le porte.

Per ulteriori informazioni sugli scenari che coinvolgono due o più regole di forwarding interno che condividono un indirizzo IP interno comune, consulta Più regole di forwarding con lo stesso indirizzo IP.

Quando utilizzi più regole di inoltro interne, assicurati di configurare il software in esecuzione sulle VM di backend in modo che si leghi a tutti gli indirizzi IP delle regola di forwarding o a qualsiasi indirizzo (0.0.0.0/0 per IPv4 o ::/0 per IPv6). L'indirizzo IP di destinazione di un pacchetto inviato tramite il bilanciatore del carico è l'indirizzo IP interno associato alla regola di forwarding interna corrispondente. Per ulteriori informazioni, consulta la sezione Pacchetti di richiesta e risposta TCP e UDP.

Servizio di backend

Ogni bilanciatore del carico di rete passthrough interno ha un servizio di backend interno regionale che definisce i parametri e il comportamento del backend. Il nome del servizio di backend è il nome del bilanciatore del carico di rete passthrough interno visualizzato nella console Google Cloud.

Ogni servizio di backend definisce i seguenti parametri di backend:

• Protocollo. Un servizio di backend supporta il traffico IPv4 e IPv6. Se il protocollo prevede il concetto di porta (ad esempio TCP o UDP), il servizio di backend invia i pacchetti alle VM di backend sulla stessa porta di destinazione a cui è stato inviato il traffico.

  I servizi di backend supportano le seguenti opzioni di protocollo IPv4: TCP, UDP o UNSPECIFIED.

  I servizi di backend supportano le seguenti opzioni di protocollo IPv6: TCP o UDP. Il protocollo del servizio di backend deve essere coordinato con il protocollo della regola di forwarding.

  Per una tabella con le possibili combinazioni di regola di forwarding e protocolli di servizio di backend, consulta la specifica del protocollo della regola di inoltro.

• Distribuzione del traffico. Un servizio di backend consente di distribuire il traffico in base a un'affinità sessione configurabile.

• Controllo di integrità. A un servizio di backend deve essere associato un controllo di integrità.

Ogni servizio di backend opera in un'unica regione e distribuisce il traffico per le VM di backend in un'unica rete VPC:

• Un tipo di backend, una regione. I backend sono gruppi di istanze o NEG a livello di zona con endpoint GCE_VM_IP situati nella stessa regione del servizio di backend e della regola di forwarding. I backend dei gruppi di istanze possono essere gruppi di istanze non gestite, gruppi di istanze gestite a livello di zona o gruppi di istanze gestite a livello di regione. I backend di NEG a livello di zona devono utilizzare endpoint GCE_VM_IP.

• Una rete VPC. Ogni gruppo di istanze o backend NEG ha una rete VPC associata, anche se il gruppo di istanze o il NEG non è ancora stato connesso a un servizio di backend. Per ulteriori informazioni su come una rete è associata a ogni tipo di backend, consulta Backend e interfacce di rete dei gruppi di istanze e Backend e interfacce di rete dei NEG a livello di zona. La risorsa di servizio di backend stessa ha anche una rete VPC associata, che può essere definita esplicitamente o implicitamente. Per ulteriori informazioni sulla rete del servizio di backend, consulta la specifica della rete del servizio di backend e le regole della rete del servizio di backend.

Backend dei gruppi di istanze e interfacce di rete

La rete VPC associata a un gruppo di istanze è la rete VPC utilizzata dall'interfaccia di rete nic0 di ogni VM membro.

• Per i gruppi di istanze gestite (MIG), la rete VPC per il gruppo di istanze è definita nel modello di istanza.
• Per i gruppi di istanze non gestite, la rete VPC per il gruppo di istanze è definita come la rete VPC utilizzata dall'interfaccia di rete nic0 della prima istanza VM aggiunta al gruppo di istanze non gestite.

All'interno di un determinato gruppo di istanze (gestite o non gestite), tutte le istanze VM devono avere le interfacce di rete nic0 nella stessa rete VPC. Ogni VM membro può avere facoltativamente interfacce di rete aggiuntive (nic1 tramite nic7), ma ogni interfaccia di rete deve essere collegata a una rete VPC diversa. Inoltre, queste reti devono essere diverse dalla rete VPC associata al gruppo di istanze.

Backend di NEG a livello di zona e interfacce di rete

Quando crei un nuovo NEG zonale con endpoint GCE_VM_IP, devi associare esplicitamente il NEG a una sottorete di una rete VPC prima di poter aggiungere endpoint al NEG. Né la subnet né la rete VPC possono essere modificate dopo la creazione del NEG.

All'interno di un determinato NEG, ogni endpoint GCE_VM_IP rappresenta in realtà un'interfaccia di rete. L'interfaccia di rete deve trovarsi nella subnet associata al NEG. Dal punto di vista di un'istanza Compute Engine, l'interfaccia di rete può utilizzare qualsiasi identificatore (da nic0 a nic7). Dal punto di vista di un endpoint in un NEG, l'interfaccia di rete viene identificata utilizzando il suo indirizzo IPv4 principale.

Esistono due modi per aggiungere un endpoint GCE_VM_IP a un NEG:

• Se specifichi solo un nome VM (senza indirizzo IP) quando aggiungi un endpoint, Google Cloud richiede che la VM abbia un'interfaccia di rete nella sottorete associata al gruppo di elenchi di esclusione. L'indirizzo IP scelto da Google Cloud per l'endpoint è l'indirizzo IPv4 interno principale dell'interfaccia di rete della VM nella sottorete associata al NEG.
• Se specifichi sia il nome di una VM sia un indirizzo IP quando aggiungi un endpoint, l'indirizzo IP fornito deve essere un indirizzo IPv4 interno principale per una delle interfacce di rete della VM. L'interfaccia di rete deve trovarsi nella sottorete associata al NEG. Tieni presente che la specifica di un indirizzo IP è ridondante perché nella subnet associata al gruppo di esclusioni di rete può essere presente una sola interfaccia di rete.

Specifica della rete del servizio di backend

Puoi associare esplicitamente una rete VPC a un servizio di backend utilizzando il flag --network quando crei il servizio di backend. Le regole di rete del servizio di backend entrano in vigore immediatamente.

Se ometti il flag --network quando crei un servizio di backend, Google Cloud utilizza uno dei seguenti eventi idonei per impostare implicitamente la rete VPC associata al servizio di backend. Una volta impostata, la rete VPC associata al servizio di backend non può essere modificata:

• Se il servizio di backend non ha ancora backend associati e configuri la prima regola di forwarding in modo che faccia riferimento al servizio di backend, Google Cloud imposta la rete VPC associata al servizio di backend sulla rete VPC contenente la sottorete utilizzata da questa regola di forwarding.

• Se il servizio di backend non ha ancora una regola di forwarding che lo rimandi, e aggiungi il backend del primo gruppo di istanze al servizio di backend, Google Cloud imposta la rete VPC del servizio di backend sulla rete VPC associata al backend del primo gruppo di istanze. Ciò significa che la rete VPC associata al servizio di backend è la rete utilizzata dall'interfaccia di rete nic0 di ogni VM nel backend del primo gruppo di istanze.

• Se il servizio di backend non ha ancora una regola di forwarding che lo rimandi, e aggiungi il primo backend NEG zonale (con endpoint GCE_VM_IP) al servizio di backend, Google Cloud imposta la rete VPC del servizio di backend sulla rete VPC associata al primo backend NEG.

Dopo che la rete VPC del servizio di backend è stata impostata da un evento idoneo, eventuali regole di inoltro aggiuntive, gruppi di istanza di backend o NEG zonali di backend che aggiungi devono rispettare le regole di rete del servizio di backend.

Regole di rete del servizio di backend

Dopo che un servizio di backend è stato associato a una rete VPC specifica, si applicano le seguenti regole:

• Quando configuri una regola di forwarding per fare riferimento al servizio di backend, la regola di forwarding deve utilizzare una sottorete della rete VPC del servizio di backend. La regola di forwarding e il servizio di backend non possono utilizzare reti VPC diverse, anche se queste sono connesse tramite il peering di rete VPC.

• Quando aggiungi i backend del gruppo di istanze, uno dei seguenti requisiti deve essere soddisfatto:

  • La rete VPC associata al gruppo di istanze, ovvero la rete VPC utilizzata dall'interfaccia di rete nic0 di ogni VM nel gruppo di istanze, deve corrispondere alla rete VPC associata al servizio di backend.
  • Ogni VM di backend deve avere un'interfaccia non nic0 (da nic1 a nic7) nella rete VPC associata al servizio di backend.

• Quando aggiungi backend NEG zonali con endpoint GCE_VM_IP, la rete VPC associata al NEG deve corrispondere alla rete VPC associata al servizio di backend.

Sottoinsieme di backend

La sottoimpostazione del backend è una funzionalità facoltativa che migliora il rendimento limitando il numero di backend a cui viene distribuito il traffico.

Devi attivare i sottoinsiemi solo se devi supportare più di 250 VM di backend su un singolo bilanciatore del carico. Per ulteriori informazioni, consulta Impostazione secondaria del backend per il bilanciatore del carico di rete passthrough interno.

Controllo di integrità

Il servizio di backend del bilanciatore del carico deve essere associato a un controllo di integrità globale o regionale. Le route speciali esterne alla rete VPC facilitano la comunicazione tra i sistemi di controllo di integrità e i backend.

Puoi utilizzare un controllo di integrità esistente o definirne uno nuovo. I bilanciatori del carico di rete passthrough interni utilizzano lo stato del controllo di integrità per determinare come instradare le nuove connessioni, come descritto in Distribuzione del traffico.

Puoi utilizzare uno dei seguenti protocolli di controllo di integrità. Il protocollo del controllo di integrità non deve corrispondere a quello del bilanciatore del carico:

• HTTP, HTTPS o HTTP/2. Se le VM di backend pubblicano il traffico utilizzando HTTP, HTTPS o HTTP/2, è meglio utilizzare un controllo di integrità corrispondente a questo protocollo, in quanto i controlli di integrità basati su HTTP offrono opzioni appropriate per questo protocollo. Se servi il traffico di tipo HTTP tramite un bilanciatore del carico di rete passthrough interno, il protocollo del bilanciatore del carico è TCP.
• SSL o TCP. Se le VM di backend non servono traffico di tipo HTTP, devi utilizzare un controllo di integrità SSL o TCP.

Indipendentemente dal tipo di controllo di integrità creato, Google Cloud invia i probe di controllo di integrità all'indirizzo IP della regola di inoltro del bilanciatore del carico di rete passthrough interno e all'interfaccia di rete nella rete VPC selezionata dal servizio di backend del bilanciatore del carico. In questo modo viene simulato il modo in cui viene fornito il traffico bilanciato in base al carico. Il software in esecuzione sulle VM di backend deve rispondere sia al traffico bilanciato in base al carico sia alle sonde di controllo di integrità inviate all'indirizzo IP di ogni regola di forwarding (il software deve ascoltare su 0.0.0.0:<port> e non su un indirizzo IP specifico assegnato a un'interfaccia di rete). Per ulteriori informazioni, consulta Destinazione per i pacchetti di prova.

Controlli di integrità e traffico UDP

Google Cloud non offre un controllo di integrità che utilizza il protocollo UDP. Quando utilizzi un bilanciatore del carico di rete passthrough interno con traffico UDP, devi eseguire un servizio basato su TCP sulle VM di backend per fornire informazioni sul controllo di integrità.

In questa configurazione, le richieste dei client vengono bilanciate in base al carico utilizzando il protocollo UDP e un servizio TCP viene utilizzato per fornire informazioni ai probatori di controllo dell'integrità di Google Cloud. Ad esempio, puoi eseguire un semplice server HTTP su ogni VM di backend che restituisce una risposta HTTP 200 a Google Cloud. In questo esempio, devi utilizzare la tua logica in esecuzione sulla VM di backend per assicurarti che il server HTTP restituisca 200 solo se il servizio UDP è configurato e in esecuzione correttamente.

Architettura ad alta disponibilità

Il bilanciatore del carico di rete passthrough interno è altamente disponibile per progettazione. Non sono previsti passaggi speciali per rendere il bilanciatore del carico ad alta disponibilità perché il meccanismo non si basa su un singolo dispositivo o istanza VM.

Per assicurarti che le istanze VM di backend vengano di cui il deployment è stato eseguito in più zone, segui questi consigli per il deployment:

• Utilizza i gruppi di istanze gestite a livello di regione se puoi eseguire il deployment del software utilizzando i modelli di istanza. I gruppi di istanze gestite a livello di regione distribuiscono automaticamente il traffico tra più zone, offrendo la soluzione migliore per evitare potenziali problemi in una determinata zona.

• Se utilizzi gruppi di istanze gestite a livello di zona o gruppi di istanze non gestite, utilizza più gruppi di istanze in zone diverse (nella stessa regione) per lo stesso servizio di backend. L'utilizzo di più zone protegge da potenziali problemi in una determinata zona.

Architettura VPC condiviso

La tabella seguente riassume i requisiti dei componenti per i bilanciatori del carico di rete passthrough interni utilizzati con le reti VPC condiviso. Per un esempio, consulta la creazione di un bilanciatore del carico di rete passthrough interno nella pagina di provisioning della rete VPC condivisa.

Indirizzo IP	Regola di forwarding	Componenti di backend
Deve essere definito un indirizzo IP interno nello stesso progetto delle VM di backend. Affinché il bilanciatore del carico sia disponibile in una rete VPC condiviso, l'indirizzo IP interno di Google Cloud deve essere definito nello stesso progetto di servizio in cui si trovano le VM di backend e deve fare riferimento a una sottorete nella rete VPC condiviso desiderata nel progetto host. L'indirizzo stesso proviene dall'intervallo IP principale della subnet a cui si fa riferimento. Se crei un indirizzo IP interno in un progetto di servizio e la subnet dell'indirizzo IP si trova nella rete VPC del progetto di servizio, il bilanciatore del carico di rete passthrough interno è locale per il progetto di servizio. Non è locale per nessun progetto host VPC condiviso.	È necessario definire una regola di forwarding interna nello stesso progetto delle VM di backend. Affinché il bilanciatore del carico sia disponibile in una rete VPC condiviso, la regola di forwarding interna deve essere definita nello stesso progetto di servizio in cui si trovano le VM di backend e deve fare riferimento alla stessa subnet (nella rete VPC condiviso) a cui fa riferimento l'indirizzo IP interno associato. Se crei una regola di forwarding interno in un progetto di servizio e la subnet della regola di forwarding si trova nella rete VPC del progetto di servizio, il bilanciatore del carico di rete passthrough interno è locale per il progetto di servizio. Non è locale per nessun progetto host VPC condiviso.	In uno scenario VPC condiviso, le VM di backend si trovano in un progetto di servizio. In questo progetto di servizio devono essere definiti un servizio di backend interno regionale e un controllo di integrità.

Distribuzione del traffico

Il modo in cui un bilanciatore del carico di rete passthrough interno distribuisce le nuove connessioni dipende dal fatto che tu abbia configurato il failover:

• Se non hai configurato il failover, un bilanciatore del carico di rete passthrough interno distribuisce le nuove connessioni alle VM di backend integre se almeno una VM di backend è integra. Quando tutte le VM di backend non sono in stato integro, come ultima risorsa il bilanciatore del carico distribuisce le nuove connessioni tra tutti i backend. In questa situazione, il bilanciatore del carico inoltra ogni nuova connessione a una VM di backend non integra.

• Se hai configurato il failover, un bilanciatore del carico di rete passthrough interno distribuisce le nuove connessioni tra le VM nel pool attivo in base a un criterio di failover configurato. Quando tutte le VM di backend non sono in stato integro, puoi scegliere tra uno dei seguenti comportamenti:

  • (Predefinito) Il bilanciatore del carico distribuisce il traffico solo alle VM principali. Questa operazione viene eseguita come ultima risorsa. Le VM di backup sono escluse da questa distribuzione di connessioni come ultima risorsa.
  • Il bilanciatore del carico è configurato per interrompere il traffico.

Il metodo di distribuzione delle nuove connessioni dipende dall'impostazione di affinità sessione del bilanciatore del carico.

Lo stato del controllo di integrità controlla la distribuzione delle nuove connessioni. Per impostazione predefinita, le connessioni TCP rimangono attive sui backend non integri. Per maggiori dettagli e su come cambiare questo comportamento, consulta Persistenza della connessione su backend non in stato di salute.

Monitoraggio della selezione e della connessione del backend

I bilanciatori del carico di rete passthrough interni utilizzano algoritmi di monitoraggio delle connessioni e di selezione del backend configurabili per determinare la modalità di distribuzione del traffico alle VM di backend. I bilanciatori del carico di rete passthrough interni utilizzano il seguente algoritmo per distribuire i pacchetti tra le VM di backend (nel pool attivo, se hai configurato il failover):

1. Se il bilanciatore del carico ha una voce nella tabella di monitoraggio delle connessioni che corrisponde alle caratteristiche di un pacchetto in arrivo, il pacchetto viene inviato al backend specificato dalla voce della tabella di monitoraggio delle connessioni. Il pacchetto è considerato parte di una connessione stabilita in precedenza, pertanto viene inviato alla VM di backend che il bilanciatore del carico ha determinato e registrato in precedenza nella tabella di monitoraggio delle connessioni.

2. Se il bilanciatore del carico riceve un pacchetto per il quale non ha una voce di monitoraggio della connessione, esegue le seguenti operazioni:

   1. Il bilanciatore del carico seleziona un backend. Il bilanciatore del carico calcola un hash in base all'affinità della sessione configurata. Utilizza questo hash per selezionare un backend:

      • Se almeno un backend è in stato integro, l'hash seleziona uno dei backend integri.
      • Se tutti i backend non sono integri e non è configurato alcun criterio di failover, l'hash seleziona uno dei backend.
      • Se tutti i backend non sono integri, è configurato un criterio di failover e questo criterio non è configurato per eliminare il traffico in questa situazione, l'hash seleziona uno dei backend VM principali.

      L'affinità sessione predefinita, NONE, utilizza un hash a 5 tuple dell'indirizzo IP di origine, della porta di origine, dell'indirizzo IP di destinazione, della porta di destinazione e del protocollo del pacchetto

      La selezione del backend può essere personalizzata utilizzando un algoritmo di hashing che utilizza meno informazioni. Per tutte le opzioni supportate, consulta le opzioni di affinità di sessione.

   2. Il bilanciatore del carico aggiunge una voce alla tabella di monitoraggio delle connessioni. Questa voce registra il backend selezionato per la connessione del pacchetto in modo che tutti i pacchetti futuri di questa connessione vengano inviati allo stesso backend. L'utilizzo del monitoraggio delle connessioni dipende dal protocollo:

      Per i pacchetti TCP e UDP, il monitoraggio delle connessioni è sempre abilitato e non può essere disattivato. Per impostazione predefinita, il monitoraggio delle connessioni è di 5 tuple, ma può essere configurato per essere inferiore a 5 tuple.

      Quando l'hash del monitoraggio delle connessioni è una tupla di 5 elementi, i pacchetti TCP SYN creano sempre una nuova voce nella tabella di monitoraggio delle connessioni.
      
      Il monitoraggio delle connessioni con 5 tuple predefinito viene utilizzato quando:

      • la modalità di monitoraggio è PER_CONNECTION (tutte le affinità sessione) o,
      • la modalità di monitoraggio è PER_SESSION e l'affinità sessione è NONE, o,
      • la modalità di monitoraggio è PER_SESSION e l'affinità sessione è CLIENT_IP_PORT_PROTO.

      Per ulteriori dettagli su quando è attivato il monitoraggio delle connessioni e su quale metodo di monitoraggio viene utilizzato quando è attivo, consulta la modalità di monitoraggio delle connessioni.

      Inoltre, tieni presente quanto segue:

      • Per impostazione predefinita, una voce nella tabella di monitoraggio delle connessioni scade 600 secondi dopo che il bilanciatore del carico ha elaborato l'ultimo pacchetto corrispondente alla voce. Per informazioni dettagliate su come personalizzare il timeout di inattività, vedi Timeout di inattività.
      • A seconda del protocollo, il bilanciatore del carico potrebbe rimuovere le voci della tabella di monitoraggio delle connessioni quando i backend non sono operativi. Per informazioni dettagliate e su come personalizzare questo comportamento, consulta Persistenza della connessione su backend in stato non integro.

Opzioni di affinità sessione

L'affinità di sessione controlla la distribuzione delle nuove connessioni dai client alle VM di backend del bilanciatore del carico. Imposti l'affinità sessione quando le VM di backend devono tenere traccia delle informazioni sullo stato per i propri clienti. Si tratta di un requisito comune per le applicazioni web.

L'affinità sessione funziona secondo il criterio del "best effort".

I bilanciatori del carico di rete passthrough interni supportano le seguenti opzioni di affinità sessione, che devi specificare per l'intero servizio di backend interno, non per gruppo di istanza di backend.

• Nessuna (NONE). Hash a 5 tuple di indirizzo IP di origine, porta di origine, protocollo, indirizzo IP di destinazione e porta di destinazione
• IP client, nessuna destinazione (CLIENT_IP_NO_DESTINATION). Hash di tuple 1 creato solo dall'indirizzo IP di origine.
• IP client (CLIENT_IP). Hash di tupla 2 di indirizzo IP di origine e indirizzo IP di destinazione. I bilanciatori del carico di rete passthrough esterni chiamano questa opzione di affinità sessione IP client, IP destinazione.
• IP client, IP di destinazione, protocollo (CLIENT_IP_PROTO). Hash di terne di indirizzo IP di origine, indirizzo IP di destinazione e protocollo
• IP client, porta client, IP destinazione, porta destinazione, protocollo (CLIENT_IP_PORT_PROTO). Hash a 5 tuple di indirizzo IP di origine, porta di origine, protocollo, indirizzo IP di destinazione e porta di destinazione

A meno che non utilizzi il bilanciatore del carico come hop successivo per una route statica personalizzata, l'indirizzo IP di destinazione di un pacchetto deve corrispondere all'indirizzo IP della regola di forwarding del bilanciatore del carico affinché il pacchetto venga consegnato al bilanciatore del carico. Per le considerazioni sull'utilizzo del bilanciatore del carico come hop successivo per una route statica personalizzata, consulta Affinità di sessione e bilanciatore del carico di rete passthrough interno dell'hop successivo.

Affinità di sessione e bilanciatore del carico di rete passthrough interno dell'hop successivo

Quando configuri una route statica per utilizzare un bilanciatore del carico di rete passthrough interno dell'hop successivo, il bilanciatore del carico utilizza lo stesso metodo di monitoraggio del collegamento e della selezione del backend discusso in precedenza. La selezione del backend avviene ancora calcolando un hash in base all'affinità della sessione configurata. Ad eccezione dell'affinità sessione CLIENT_IP_NO_DESTINATION, l'hash di selezione del backend dipende, in parte, dall'indirizzo IP di destinazione del pacchetto.

Quando un bilanciatore del carico di rete passthrough interno è un hop successivo di una route statica, l'indirizzo IP di destinazione non è limitato all'indirizzo IP della regola di forwarding del bilanciatore del carico. L'indirizzo IP di destinazione del pacchetto può invece essere qualsiasi indirizzo IP che rientra nell'intervallo di destinazione della route statica.

Se il numero di VM di backend configurate e integre è costante (quando il failover non è configurato o quando è configurato, ma non si verificano eventi di failover o di failback), il bilanciatore del carico si comporta nel seguente modo:

• Se esiste una sola VM di backend configurata e integra (nel pool attivo, se è configurato il failover), non importa quale affinità sessione utilizzi perché tutti gli hash sono mappati a questa VM di backend.

• Se sono presenti due o più VM di backend configurate e integre (nel pool attivo, se è configurato il failover), la scelta dell'affinità sessione è importante:

  • Se hai bisogno che la stessa VM di backend elabori tutti i pacchetti di un client, in base esclusivamente all'indirizzo IP di origine del pacchetto, indipendentemente dagli indirizzi IP di destinazione del pacchetto, utilizza l'affinità sessione CLIENT_IP_NO_DESTINATION. A seconda dei pattern di traffico, alcune VM di backend potrebbero ricevere più pacchetti o più connessioni rispetto ad altre VM di backend.

  • Se utilizzi un'opzione di affinità sessione diversa da CLIENT_IP_NO_DESTINATION, il bilanciatore del carico seleziona una VM di backend in base a informazioni che includono almeno entrambi l'indirizzo IP di origine e l'indirizzo IP di destinazione del pacchetto. I pacchetti inviati dallo stesso client, utilizzando lo stesso indirizzo IP di origine, ma indirizzi IP di destinazione diversi, possono essere instradati a VM di backend diverse.

Modalità di monitoraggio delle connessioni

La modalità di monitoraggio specifica l'algoritmo di monitoraggio delle connessioni da utilizzare. Esistono due modalità di monitoraggio: PER_CONNECTION (predefinita) e PER_SESSION.

• PER_CONNECTION (valore predefinito). In questa modalità, il traffico TCP e UDP viene sempre monitorato per 5 tuple, indipendentemente dall'impostazione di affinità sessione. Ciò implica che la chiave per il monitoraggio delle connessioni (tuple di 5 elementi) può essere diversa dall'impostazione di affinità sessione configurata (ad es. tuple di 3 elementi con l'impostazione CLIENT_IP_PROTO). Di conseguenza, l'affinità sessione potrebbe essere suddivisa e le nuove connessioni per una sessione potrebbero selezionare un backend diverso se l'insieme di backend o il loro stato cambia.

• PER_SESSION. In questa modalità, il traffico TCP e UDP viene monitorato in base all'affinità della sessione configurata. In altre parole, se l'affinità sessione è CLIENT_IP o CLIENT_IP_PROTO, la configurazione di questa modalità comporta rispettivamente il monitoraggio delle connessioni con due tuple e tre tuple. Questa opzione potrebbe essere preferibile in scenari in cui l'interruzione dell'affinità è costosa e deve essere evitata anche dopo l'aggiunta di altri backend.

L'impostazione della modalità di monitoraggio della connessione è ridondante se l'affinità sessione è impostata su NONE o CLIENT_IP_PORT_PROTO. Per scoprire come funzionano queste modalità di monitoraggio con diverse impostazioni di affinità sessione per ciascun protocollo, consulta la tabella seguente.

Selezione del backend		Modalità di monitoraggio delle connessioni
Impostazione dell'affinità sessione	Metodo di hashing per la selezione del backend	PER_CONNECTION (valore predefinito)	PER_SESSION
Valore predefinito: nessuna affinità sessione NONE	Hash di 5 tuple	Monitoraggio delle connessioni con 5 tuple	Monitoraggio delle connessioni con 5 tuple
IP client, nessuna destinazione CLIENT_IP_NO_DESTINATION	Hash di tupla 1	Monitoraggio delle connessioni con 5 tuple	Monitoraggio delle connessioni con una tupla
IP client CLIENT_IP (uguale a IP client, IP destinazione per i bilanciatori del carico di rete passthrough esterni)	Hash di tuple di 2 elementi	Monitoraggio delle connessioni con 5 tuple	Monitoraggio delle connessioni con due tuple
IP client, IP di destinazione, Protocollo CLIENT_IP_PROTO	Hash di tuple di 3 elementi	Monitoraggio delle connessioni con 5 tuple	Monitoraggio delle connessioni con tre tuple
IP client, porta client, IP di destinazione, porta di destinazione, protocollo CLIENT_IP_PORT_PROTO	Hash di 5 tuple	Monitoraggio delle connessioni con 5 tuple	Monitoraggio delle connessioni con 5 tuple

Per scoprire come modificare la modalità di monitoraggio delle connessioni, consulta Configurare un criterio di monitoraggio delle connessioni.

Persistenza della connessione su backend in stato non integro

Le impostazioni di persistenza della connessione su backend non integri controllano se una connessione esistente persiste su un backend selezionato dopo che il backend diventa non integro (a condizione che il backend rimanga nel gruppo di istanza di backend configurato del bilanciatore del carico).

Il comportamento descritto in questa sezione non si applica ai casi in cui viene rimossa una VM di backend dal relativo gruppo di istanze o il gruppo di istanze dal servizio di backend. In questi casi, le connessioni stabilite rimangono attive solo come descritto in Abilitazione del ritiro delle connessioni.

Sono disponibili le seguenti opzioni di persistenza della connessione:

• DEFAULT_FOR_PROTOCOL (valore predefinito)
• NEVER_PERSIST
• ALWAYS_PERSIST

La tabella seguente riassume le opzioni di persistenza delle connessioni e la modalità di persistenza delle connessioni per diversi protocolli, opzioni di affinità sessione e modalità di monitoraggio.

Opzione Persistenza della connessione su backend in stato non integro	Modalità di monitoraggio delle connessioni
	PER_CONNECTION	PER_SESSION
DEFAULT_FOR_PROTOCOL	TCP: le connessioni persistono sui backend non integri (tutte le affinità sessione) UDP: le connessioni non vengono mai mantenute su backend non integri	TCP: le connessioni persistono sui backend non integri se l'affinità sessione è NONE o CLIENT_IP_PORT_PROTO UDP: le connessioni non vengono mai mantenute su backend non integri
NEVER_PERSIST	TCP, UDP: le connessioni non persistono mai su backend non integri
ALWAYS_PERSIST	TCP, UDP: le connessioni persistono su backend in stato non integro (tutte le affinità di sessione) Questa opzione deve essere utilizzata solo per casi d'uso avanzati.	Configurazione non possibile

Per scoprire come modificare il comportamento di persistenza della connessione, consulta Configurare un criterio di monitoraggio delle connessioni.

Timeout di inattività

Per impostazione predefinita, una voce nella tabella di monitoraggio delle connessioni scade 600 secondi dopo che il bilanciatore del carico ha elaborato l'ultimo pacchetto corrispondente alla voce. Questo valore predefinito del timeout di inattività può essere modificato solo quando il monitoraggio delle connessioni è inferiore a 5 tuple (ovvero quando l'affinità sessione è configurata su CLIENT_IP o CLIENT_IP_PROTO e la modalità di monitoraggio è PER_SESSION).

Il valore massimo del timeout di inattività configurabile è 57.600 secondi (16 ore).

Per scoprire come modificare il valore del timeout inattivo, consulta Configurare un criterio di monitoraggio delle connessioni.

Testare le connessioni da un singolo client

Quando testi le connessioni all'indirizzo IP di un bilanciatore del carico di rete passthrough interno da un singolo sistema client, tieni presente quanto segue:

• Se il sistema client non è una VM con bilanciamento del carico, ovvero non è una VM di backend, le nuove connessioni vengono inviate alle VM di backend integre del bilanciatore del carico. Tuttavia, poiché tutte le opzioni di affinità di sessione si basano almeno sull'indirizzo IP del sistema client, le connessioni dello stesso client potrebbero essere distribuite alla stessa VM di backend più spesso di quanto potresti aspettarti.

  In pratica, ciò significa che non puoi monitorare con precisione la distribuzione del traffico tramite un bilanciatore del carico di rete passthrough interno collegandoti da un singolo client. Il numero di client necessari per monitorare la distribuzione del traffico varia in base al tipo di bilanciatore del carico, al tipo di traffico e al numero di backend funzionanti.

• Se la VM client è una VM di backend del bilanciatore del carico, le connessioni inviate all'indirizzo IP della regola di inoltro del bilanciatore del carico ricevono sempre una risposta dalla VM client/di backend. Questo accade indipendentemente dal fatto che la VM di backend sia in stato integro. Si verifica per tutto il traffico inviato all'indirizzo IP del bilanciatore del carico, non solo per il traffico sul protocollo e sulle porte specificati nella regola di forwarding interna del bilanciatore del carico.

  Per ulteriori informazioni, consulta la sezione Inviare richieste da VM con bilanciamento del carico.

Frammentazione UDP

I bilanciatori del carico di rete passthrough interni possono elaborare pacchetti UDP sia frammentati che non frammentati. Se la tua applicazione utilizza pacchetti UDP frammentati, tieni presente quanto segue:

• I pacchetti UDP potrebbero essere frammentati prima di raggiungere una rete VPC di Google Cloud.
• Le reti VPC di Google Cloud inoltrano i frammenti UDP man mano che arrivano (senza attendere l'arrivo di tutti i frammenti).
• Le reti non Google Cloud e le apparecchiature di rete on-premise potrebbero forwardare i frammenti UDP man mano che arrivano, ritardare i pacchetti UDP frammentati finché non sono arrivati tutti i frammenti o eliminare i pacchetti UDP frammentati. Per maggiori dettagli, consulta la documentazione del fornitore di servizi di rete o dell'apparecchiatura di rete.

Se prevedi pacchetti UDP frammentati e devi inoltrarli agli stessi backend, utilizza i seguenti parametri di configurazione della regola di forwarding e del servizio di backend:

• Configurazione della regola di forwarding: utilizza una sola regola di forwarding UDP per indirizzo IP bilanciato in base al carico e configura la regola di forwarding in modo che accetti il traffico su tutte le porte. In questo modo, tutti i frammenti arrivano alla stessa regola di forwarding. Anche se i pacchetti frammentati (diversi dal primo frammento) non hanno una porta di destinazione, la configurazione della regola di forwarding per elaborare il traffico per tutte le porte la configura anche per ricevere frammenti UDP che non hanno informazioni sulla porta. Per configurare tutte le porte, utilizza Google Cloud CLI per impostare --ports=ALL o utilizza l'API per impostare allPorts su True.

• Configurazione del servizio di backend: imposta l'affinità della sessione del servizio di backend su CLIENT_IP (hash di tupla 2) o CLIENT_IP_PROTO (hash di tupla 3) in modo che venga selezionato lo stesso backend per i pacchetti UDP che includono informazioni sulla porta e frammenti UDP (diversi dal primo frammento) che non contengono informazioni sulla porta. Imposta la modalità di monitoraggio delle connessioni del servizio di backend su PER_SESSION in modo che le voci della tabella di monitoraggio delle connessioni vengano create utilizzando gli stessi hash di tuple di 2 o 3 elementi.

Failover

Un bilanciatore del carico di rete passthrough interno ti consente di designare alcuni backend come backend di failover. Questi backend vengono utilizzati solo quando il numero di VM integre nei gruppi di istanza di backend principali è inferiore a una soglia configurabile. Per impostazione predefinita, se tutte le VM principali e di failover non sono in stato di salute, come ultima risorsa Google Cloud distribuisce le nuove connessioni solo tra tutte le VM principali.

Quando aggiungi un backend al servizio di backend di un bilanciatore del carico di rete passthrough interno, per impostazione predefinita il backend è un backend principale. Puoi designare un backend come backend di failover quando lo aggiungi al servizio di backend del bilanciatore del carico o modificandolo in un secondo momento.

Per una panoramica concettuale dettagliata del failover nei bilanciatori del carico di rete passthrough interni, consulta Failover per i bilanciatori del carico di rete passthrough interni.

Quote e limiti

Per informazioni su quote e limiti, consulta Quote delle risorse di bilanciamento del carico.

Limitazioni

• Non puoi utilizzare la console Google Cloud per creare un bilanciatore del carico di rete passthrough interno con backend NEG zonali.

Passaggi successivi

• Per configurare e testare un bilanciatore del carico di rete passthrough interno, consulta Configura un bilanciatore del carico di rete passthrough interno.
• Per configurare Cloud Monitoring per i bilanciatori del carico di rete passthrough interni, consulta Monitoraggio e logging dei bilanciatori del carico di rete passthrough interni.
• Per risolvere i problemi relativi al bilanciatore del carico di rete passthrough interno, consulta Risolvere i problemi relativi ai bilanciatori del carico di rete passthrough interni.