Panoramica del bilanciatore del carico di rete passthrough esterno basato su servizi di backend

I bilanciatori del carico di rete passthrough esterni sono bilanciatori del carico di livello 4 a livello di regione che distribuiscono il traffico esterno tra backend (gruppi di istanze o gruppi di endpoint di rete (NEG)) nella stessa regione del bilanciatore del carico. Questi backend devono trovarsi nella stessa regione e nello stesso progetto, ma possono trovarsi in reti VPC diverse. Questi bilanciatori del carico sono basati su Maglev e sullo stack di virtualizzazione di rete Andromeda.

I bilanciatori del carico di rete passthrough esterni possono ricevere traffico da:

  • Qualsiasi client su internet
  • VM Google Cloud con IP esterni
  • VM Google Cloud con accesso a internet tramite Cloud NAT o NAT basato su istanze

I bilanciatori del carico di rete passthrough esterni non sono proxy. Il bilanciatore del carico non termina le connessioni utente. I pacchetti con bilanciamento del carico vengono inviati alle VM di backend con gli indirizzi IP di origine e di destinazione, il protocollo e, se applicabile, le porte invariati. Le VM di backend terminano quindi le connessioni utente. Le risposte delle VM di backend passano direttamente ai client, non tramite il bilanciatore del carico. Questo processo è noto come Direct Server Return (DSR).

I bilanciatori del carico di rete passthrough esterni basati su servizi di backend supportano le seguenti funzionalità:

  • Backend di gruppi di istanze gestiti e non gestiti. I bilanciatori del carico di rete passthrough esterni basati su servizi di backend supportano gruppi di istanze gestite e non gestite come backend. I gruppi di istanze gestite automatizzano determinati aspetti della gestione del backend e offrono una maggiore scalabilità e affidabilità rispetto ai gruppi di istanze non gestite.
  • Backend di NEG a livello di zona. I bilanciatori del carico di rete passthrough esterni basati su servizi di backend supportano l'uso di NEG a livello di zona con endpoint GCE_VM_IP. Gli endpoint NEG GCE_VM_IP a livello di zona consentono di eseguire le seguenti operazioni:
    • Inoltra i pacchetti a qualsiasi interfaccia di rete, non solo a nic0.
    • Posiziona lo stesso endpoint GCE_VM_IP in due o più NEG a livello di zona connessi a servizi di backend diversi.
  • Supporto di più protocolli. I bilanciatori del carico di rete passthrough esterni basati su servizi di backend possono bilanciare il carico del traffico TCP, UDP, ESP, GRE, ICMP e ICMPv6.
  • Supporto per la connettività IPv6. I bilanciatori del carico di rete passthrough esterni basati su servizi di backend possono gestire il traffico IPv4 e IPv6.
  • Controllo granulare della distribuzione del traffico. Un servizio di backend consente la distribuzione del traffico in base a un'affinità sessione configurabile, alla modalità di monitoraggio delle connessioni e al bilanciamento del carico ponderato. Il servizio di backend può anche essere configurato per abilitare lo svuotamento della connessione e designare i backend di failover per il bilanciatore del carico. La maggior parte di queste impostazioni ha valori predefiniti che consentono di iniziare rapidamente.
  • Supporto per controlli di integrità non legacy. I bilanciatori del carico di rete passthrough esterni basati su servizi di backend ti consentono di utilizzare controlli di integrità corrispondenti al tipo di traffico (TCP, SSL, HTTP, HTTPS o HTTP/2) che distribuiscono.
  • Integrazione di Google Cloud Armor. Google Cloud Armor supporta la protezione DDoS di rete avanzata per bilanciatori del carico di rete passthrough esterni. Per maggiori informazioni, consulta l'articolo Configurare la protezione DDoS di rete avanzata.

  • Integrazione di GKE. Se stai creando applicazioni in GKE, ti consigliamo di utilizzare il controller di servizio GKE integrato, che esegue il deployment dei bilanciatori del carico Google Cloud per conto degli utenti GKE. Questa è la stessa architettura di bilanciamento del carico autonoma descritta in questa pagina, ma il suo ciclo di vita è completamente automatizzato e controllato da GKE.

    Documentazione relativa a GKE correlata:

Architettura

Il seguente diagramma illustra i componenti di un bilanciatore del carico di rete passthrough esterno:

Bilanciatore del carico di rete passthrough esterno con un servizio di backend regionale
Bilanciatore del carico di rete passthrough esterno con un servizio di backend regionale

Il bilanciatore del carico è costituito da diversi componenti di configurazione. Un singolo bilanciatore del carico può avere quanto segue:

  • Uno o più indirizzi IP esterni a livello di regione
  • Una o più regole di forwarding esterno a livello di regione
  • Un servizio di backend esterno regionale
  • Uno o più backend: tutti i gruppi di istanze o tutti i backend NEG a livello di zona (endpoint GCE_VM_IP)
  • Controllo di integrità associato al servizio di backend

Inoltre, devi creare regole firewall che consentano ai probe del bilanciamento del carico del traffico e del controllo di integrità di raggiungere le VM di backend.

Indirizzo IP

Un bilanciatore del carico di rete passthrough esterno richiede almeno una regola di forwarding. La regola di forwarding fa riferimento a un indirizzo IP esterno a livello di regione accessibile ovunque su internet.

  • Per il traffico IPv4, la regola di forwarding fa riferimento a un singolo indirizzo IPv4 esterno a livello di regione. Gli indirizzi IPv4 esterni a livello di regione provengono da un pool univoco per ogni regione Google Cloud. L'indirizzo IP può essere un indirizzo statico riservato o un indirizzo temporaneo.

  • Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo /96 da una subnet a doppio stack con un intervallo di subnet IPv6 esterno nella rete VPC. Gli indirizzi IPv6 esterni sono disponibili solo nel livello Premium. L'intervallo di indirizzi IPv6 può essere un indirizzo statico riservato o un indirizzo temporaneo.

Utilizza un indirizzo IP riservato per la regola di forwarding se devi mantenere l'indirizzo associato al progetto per il riutilizzo dopo aver eliminato una regola di forwarding o se hai bisogno di più regole di forwarding per fare riferimento allo stesso indirizzo IP.

I bilanciatori del carico di rete passthrough esterni supportano sia il livello Standard che il livello Premium per gli indirizzi IPv4 esterni regionali. Sia l'indirizzo IP sia la regola di forwarding devono utilizzare lo stesso livello di rete. Gli indirizzi IPv6 esterni regionali sono disponibili solo nel livello Premium.

Regola di forwarding

Una regola di forwarding esterno a livello di regione specifica il protocollo e le porte su cui il bilanciatore del carico accetta il traffico. Poiché i bilanciatori del carico di rete passthrough esterni non sono proxy, passano il traffico ai backend con lo stesso protocollo e le stesse porte, se il pacchetto contiene informazioni sulla porta. La regola di forwarding, insieme all'indirizzo IP, forma il frontend del bilanciatore del carico.

Il bilanciatore del carico conserva gli indirizzi IP di origine dei pacchetti in entrata. L'indirizzo IP di destinazione per i pacchetti in entrata è un indirizzo IP associato alla regola di forwarding del bilanciatore del carico.

Il traffico in entrata è abbinato a una regola di forwarding, cioè una combinazione di un determinato indirizzo IP (un indirizzo IPv4 o un intervallo di indirizzi IPv6), un protocollo e, se il protocollo è basato sulle porte, una o più porte, un intervallo di porte o tutte le porte. La regola di forwarding indirizza quindi il traffico al servizio di backend del bilanciatore del carico.

  • Se la regola di forwarding fa riferimento a un indirizzo IPv4, la regola di forwarding non è associata ad alcuna subnet. ovvero l'indirizzo IP proviene dall'esterno di qualsiasi intervallo di subnet di Google Cloud.

  • Se la regola di forwarding fa riferimento a un intervallo di indirizzi IPv6 /96, la regola di forwarding deve essere associata a una subnet e questa deve essere (a) a doppio stack e (b) avere un intervallo di subnet IPv6 esterno (--ipv6-access-type impostato su EXTERNAL). La subnet a cui fa riferimento la regola di forwarding può essere la stessa utilizzata dalle istanze di backend. Tuttavia, le istanze di backend possono utilizzare una subnet separata, se lo desiderano. Quando le istanze di backend utilizzano una subnet separata, deve essere vero quanto segue:

Un bilanciatore del carico di rete passthrough esterno richiede almeno una regola di forwarding. Le regole di forwarding possono essere configurate in modo da indirizzare il traffico proveniente da un intervallo specifico di indirizzi IP di origine a un servizio di backend (o istanza di destinazione) specifico. Per maggiori dettagli, consulta la sezione relativa al reindirizzamento del traffico. Puoi definire più regole di forwarding per lo stesso bilanciatore del carico, come descritto in Più regole di forwarding.

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

Protocolli delle regole di forwarding

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

Utilizza le opzioni TCP e UDP per configurare il bilanciamento del carico TCP o UDP. L'opzione di protocollo L3_DEFAULT consente a un bilanciatore del carico di rete passthrough esterno di bilanciare il carico del traffico TCP, UDP, ESP, GRE, ICMP e ICMPv6.

Oltre a supportare protocolli diversi da TCP e UDP, L3_DEFAULT consente a una singola regola di forwarding di gestire più protocolli. Ad esempio, i servizi IPSec in genere gestiscono una combinazione di traffico IKE e NAT-T basati su ESP e UDP. L'opzione L3_DEFAULT consente di configurare un'unica regola di forwarding per elaborare tutti questi protocolli.

Le regole di forwarding con 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 il cui protocollo è UNSPECIFIED. Le regole di forwarding L3_DEFAULT possono fare riferimento solo a un servizio di backend con protocollo UNSPECIFIED.

Se utilizzi il protocollo L3_DEFAULT, devi configurare la regola di forwarding 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 i diversi protocolli.

Traffico da bilanciare il carico Protocollo della regola di forwarding Protocollo del servizio di backend
TCP TCP TCP o UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP o UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP, GRE,
ICMP/ICMPv6 (solo richiesta echo)
 L3_DEFAULT UNSPECIFIED

Più regole di forwarding

Puoi configurare più regole di forwarding esterno a livello di regione per lo stesso bilanciatore del carico di rete passthrough esterno. Ogni regola di forwarding può avere un indirizzo IP esterno a livello di regione oppure più regole di forwarding possono avere lo stesso indirizzo IP esterno a livello di regione.

La configurazione di più regole di forwarding esterno a livello di regione può essere utile per questi casi d'uso:

  • Devi configurare più di un indirizzo IP esterno per lo stesso servizio di backend.
  • Devi configurare protocolli diversi o porte o intervalli di porte non sovrapposti per lo stesso indirizzo IP esterno.
  • Devi indirizzare il traffico da determinati indirizzi IP di origine a backend specifici del bilanciatore del carico.

Google Cloud richiede che i pacchetti in entrata non corrispondano a più di una regola di forwarding. Ad eccezione delle regole di forwarding di reindirizzamento, descritte nella prossima sezione, due o più regole di forwarding che utilizzano lo stesso indirizzo IP esterno a livello di regione devono avere combinazioni univoche di protocollo e porta in base a questi vincoli:

  • Una regola di forwarding configurata per tutte le porte di un protocollo impedisce la creazione di altre regole di forwarding utilizzando lo stesso protocollo e lo stesso indirizzo IP. Le regole di forwarding utilizzando i protocolli TCP o UDP possono essere configurate per l'utilizzo di tutte le porte oppure per porte specifiche. Ad esempio, se crei una regola di forwarding utilizzando l'indirizzo IP 198.51.100.1, il protocollo TCP e tutte le porte, non puoi creare altre regole di forwarding utilizzando l'indirizzo IP 198.51.100.1e il protocollo TCP. Puoi creare due regole di forwarding, entrambe utilizzando l'indirizzo IP 198.51.100.1 e il protocollo TCP, se ciascuna ha porte univoche o intervalli di porte non sovrapposti. Ad esempio, puoi creare due regole di forwarding utilizzando l'indirizzo IP 198.51.100.1e il protocollo TCP, dove le porte di una regola di forwarding sono 80,443 e l'altra utilizza l'intervallo di porte 81-442.
  • È possibile creare una sola regola di forwarding L3_DEFAULT per indirizzo IP. Questo perché il protocollo L3_DEFAULT utilizza tutte le porte per definizione. In questo contesto, il termine Tutte le porte include protocolli senza informazioni sulle porte.

  • Una singola regola di forwarding L3_DEFAULT può coesistere con altre regole di forwarding che utilizzano protocolli specifici (TCP o UDP). La regola di forwarding L3_DEFAULT può essere utilizzata come ultima risorsa quando le regole di forwarding utilizzano lo stesso indirizzo IP ma esistono protocolli più specifici. Una regola di forwarding L3_DEFAULT elabora i pacchetti inviati all'indirizzo IP di destinazione solo se l'indirizzo IP di destinazione del pacchetto, il protocollo e la porta di destinazione non corrispondono a una regola di forwarding specifica per il protocollo.

    Per spiegare meglio, considera questi due scenari. In entrambi gli scenari, le regole di forwarding utilizzano lo stesso indirizzo IP 198.51.100.1.

    • Scenario 1. La prima regola di forwarding utilizza il protocollo L3_DEFAULT. La seconda regola di forwarding utilizza il protocollo TCP e tutte le porte. I pacchetti TCP inviati a qualsiasi porta di destinazione di 198.51.100.1 vengono elaborati dalla seconda regola di forwarding. I pacchetti che usano protocolli diversi vengono elaborati dalla prima regola di forwarding.
    • Scenario 2. La prima regola di forwarding utilizza il protocollo L3_DEFAULT. La seconda regola di forwarding utilizza il protocollo TCP e la porta 8080. I pacchetti TCP inviati a 198.51.100.1:8080 vengono elaborati dalla seconda regola di forwarding. Tutti gli altri pacchetti, inclusi quelli TCP inviati a porte di destinazione diverse, vengono elaborati dalla prima regola di forwarding.

Selezione della regola di forwarding

Google Cloud seleziona una o nessuna regola di forwarding per elaborare un pacchetto in entrata utilizzando questo processo di eliminazione, a partire dall'insieme di candidati per le regole di forwarding che corrispondono all'indirizzo IP di destinazione del pacchetto:

  • Elimina le regole di forwarding il cui protocollo non corrisponde a quello del pacchetto, ad eccezione delle regole di forwarding L3_DEFAULT. Le regole di forwarding che utilizzano il protocollo L3_DEFAULT non vengono mai eliminate da questo passaggio perché L3_DEFAULT corrisponde a tutti i protocolli. Ad esempio, se il protocollo del pacchetto è TCP, vengono eliminate solo le regole di forwarding che utilizzano il protocollo UDP.

  • Elimina le regole di forwarding la cui porta non corrisponde a quella del pacchetto. Le regole di forwarding configurate per tutte le porte non vengono mai eliminate da questo passaggio perché una regola di forwarding per tutte le porte corrisponde a qualsiasi porta.

  • Se le restanti regola di forwarding candidati includono sia L3_DEFAULT sia regole di forwarding specifiche per protocollo, elimina le regole di forwarding L3_DEFAULT. Se le restanti regola di forwarding candidati sono tutte L3_DEFAULT, nessuna viene eliminata in questo passaggio.

  • A questo punto, le altre categorie candidati per la regola di forwarding rientrano in una delle seguenti categorie:

    • rimane un'unica regola di forwarding, che corrisponde all'indirizzo IP, al protocollo e alla porta di destinazione del pacchetto, e viene utilizzata per instradare il pacchetto.
    • Rimangono due o più regola di forwarding candidati che corrispondono all'indirizzo IP, al protocollo e alla porta di destinazione del pacchetto. Ciò significa che le restanti regola di forwarding candidati includono le regole di forwarding di reindirizzamento (discusse nella prossima sezione). Seleziona la regola di forwarding di reindirizzamento il cui intervallo di origine include il CIDR più specifico (corrispondenza del prefisso più lunga) contenente l'indirizzo IP di origine del pacchetto. Se nessuna regola di forwarding di reindirizzamento ha un intervallo di origine che include l'indirizzo IP di origine del pacchetto, seleziona la regola di forwarding padre.
    • Non rimangono candidati per le regola di forwarding e il pacchetto viene ignorato.

Se utilizzi più regole di forwarding, assicurati di configurare il software in esecuzione sulle VM di backend in modo che si associ a tutti gli indirizzi IP esterni delle regola di forwarding del bilanciatore del carico.

Indirizzamento del traffico

Puoi configurare le regole di forwarding per i bilanciatori del carico di rete passthrough esterni in modo da indirizzare il traffico che proviene da un intervallo specifico di indirizzi IP di origine a un servizio di backend (o istanza di destinazione) specifico.

L'indirizzamento del traffico è utile per la risoluzione dei problemi e per le configurazioni avanzate. Con l'indirizzamento del traffico, puoi indirizzare determinati client a un set diverso di backend, a una diversa configurazione del servizio di backend o a entrambi. Ad esempio:

  • L'indirizzamento del traffico consente di creare due regole di forwarding che indirizzano il traffico allo stesso backend (gruppo di istanze o NEG) tramite due servizi di backend. I due servizi di backend possono essere configurati con controlli di integrità diversi, affinità di sessione diverse o criteri di controllo della distribuzione del traffico diversi (monitoraggio della connessione, svuotamento della connessione e failover).
  • L'indirizzamento del traffico consente di creare una regola di forwarding per reindirizzare il traffico da un servizio di backend con larghezza di banda bassa a un servizio di backend con larghezza di banda elevata. Entrambi i servizi di backend contengono lo stesso insieme di VM o endpoint di backend, ma sono bilanciati con pesi diversi utilizzando il bilanciamento del carico ponderato.
  • L'indirizzamento del traffico consente di creare due regole di forwarding che indirizzano il traffico a servizi di backend diversi, con backend diversi (gruppi di istanze o NEG). Ad esempio, potresti configurare un backend utilizzando tipi di macchine diversi per elaborare meglio il traffico proveniente da un determinato insieme di indirizzi IP di origine.

L'indirizzamento del traffico è configurato con un parametro dell'API per le regola di forwarding denominato sourceIPRanges. Le regole di forwarding che hanno almeno un intervallo IP di origine configurato sono chiamate regole di forwarding per l'indirizzamento.

Una regola di forwarding di reindirizzamento può avere un elenco di massimo 64 intervalli IP di origine. Puoi aggiornare in qualsiasi momento l'elenco di intervalli IP di origine configurati per una regola di forwarding di reindirizzamento.

Ogni regola di forwarding per l'indirizzamento richiede prima la creazione di una regola di inoltro padre. Le regole di forwarding padre e di reindirizzamento condividono le stesse informazioni su indirizzo IP esterno a livello di regione, protocollo IP e porta. Tuttavia, la regola di forwarding padre non contiene informazioni sull'indirizzo IP di origine. Ad esempio:

  • Regola di forwarding padre: indirizzo IP: 198.51.100.1, protocollo IP: TCP, porte: 80
  • Regola di forwarding per l'indirizzamento: indirizzo IP: 198.51.100.1, protocollo IP: TCP, porte: 80, sourceIPRanges: 203.0.113.0/24

Una regola di forwarding padre che punta a un servizio di backend può essere associata a una regola di forwarding di reindirizzamento che punta a un servizio di backend o a un'istanza di destinazione.

Per una determinata regola di forwarding padre, due o più regole di forwarding di reindirizzamento possono avere intervalli IP di origine sovrapposizioni, ma non identici. Ad esempio, una regola di forwarding di reindirizzamento può avere l'intervallo IP di origine 203.0.113.0/24 e un'altra regola di forwarding di reindirizzamento per lo stesso elemento padre può avere l'intervallo IP di origine 203.0.113.0.

Devi eliminare tutte le regole di forwarding di reindirizzamento prima di poter eliminare la regola di forwarding padre da cui dipendono.

Per scoprire come vengono elaborati i pacchetti in arrivo quando vengono utilizzate le regole di forwarding per l'indirizzamento, consulta Selezione delle regole di forwarding.

Comportamento di affinità sessione tra le modifiche all'indirizzamento

Questa sezione descrive le condizioni in cui l'affinità sessione potrebbe non funzionare quando vengono aggiornati gli intervalli IP di origine per l'indirizzamento delle regole di forwarding:

  • Se una connessione esistente continua a corrispondere alla stessa regola di forwarding dopo aver modificato gli intervalli IP di origine per una regola di forwarding di reindirizzamento, l'affinità sessione non verrà interrotta. Se la modifica genera una connessione esistente corrispondente a una regola di forwarding diversa:
  • L'affinità sessione si interrompe sempre nelle seguenti circostanze:
    • La regola di forwarding con una nuova corrispondenza indirizza una connessione stabilita a un servizio di backend (o un'istanza di destinazione) che non fa riferimento alla VM di backend selezionata in precedenza.
    • La regola di forwarding con nuova corrispondenza indirizza una connessione stabilita a un servizio di backend che fa riferimento alla VM di backend selezionata in precedenza, ma il servizio di backend non è configurato per mantenere le connessioni quando i backend sono in stato non integro e la VM di backend non supera il controllo di integrità del servizio di backend.
  • L'affinità sessione potrebbe interrompersi quando la regola di forwarding a cui viene abbinata di recente indirizza una connessione stabilita a un servizio di backend e il servizio di backend fa riferimento alla VM selezionata in precedenza, ma la combinazione di affinità sessione e modalità di monitoraggio delle connessioni del servizio di backend genera un hash di monitoraggio delle connessioni diverso.

Mantenimento dell'affinità sessione nelle modifiche all'indirizzamento

Questa sezione descrive come evitare di interrompere l'affinità sessione quando vengono aggiornati gli intervalli IP di origine per l'indirizzamento delle regole di forwarding:

  • Indirizzare le regole di forwarding che puntano ai servizi di backend. Se la regola di forwarding principale e quella di forwarding puntano ai servizi di backend, devi assicurarti manualmente che le impostazioni di affinità sessione e criterio di monitoraggio delle connessioni siano identici. Google Cloud non rifiuta automaticamente le configurazioni se non sono identiche.
  • Reindirizzamento delle regole di forwarding che puntano alle istanze di destinazione. Una regola di forwarding padre che punta a un servizio di backend può essere associata a una regola di forwarding di reindirizzamento che punta a un'istanza di destinazione. In questo caso, la regola di forwarding di reindirizzamento eredita le impostazioni di affinità sessione e criterio di monitoraggio della connessione dalla regola di forwarding padre.

Per istruzioni su come configurare l'indirizzamento del traffico, consulta Configurare l'indirizzamento del traffico.

Servizio di backend a livello di area geografica

Ogni bilanciatore del carico di rete passthrough esterno dispone di un servizio di backend a livello di regione che definisce il comportamento del bilanciatore del carico e la modalità di distribuzione del traffico nei backend. Il nome del servizio di backend è il nome del bilanciatore del carico di rete passthrough esterno mostrato nella console Google Cloud.

Ogni servizio di backend definisce i seguenti parametri di backend:

  • Protocollo. Un servizio di backend accetta il traffico sull'indirizzo IP e sulle porte (se configurate) specificate da una o più regole di forwarding esterno a livello di regione. Il servizio di backend passa i pacchetti alle VM di backend, mantenendo gli indirizzi IP di origine e di destinazione del pacchetto, il protocollo e, se il protocollo è basato sulle porte, le porte di origine e di destinazione.

    I servizi di backend utilizzati con bilanciatori del carico di rete passthrough esterni supportano le seguenti opzioni di protocollo: TCP, UDP o UNSPECIFIED.

    I servizi di backend con il protocollo UNSPECIFIED possono essere utilizzati con qualsiasi regola di forwarding, indipendentemente dal protocollo della regola di forwarding. È possibile fare riferimento ai servizi di backend con un protocollo specifico (TCP o UDP) solo tramite regole di forwarding con lo stesso protocollo (TCP o UDP). Le regole di forwarding con il protocollo L3_DEFAULT possono fare riferimento solo ai servizi di backend con il protocollo UNSPECIFIED.

    Consulta Specifica del protocollo della regola di forwarding per una tabella con possibili combinazioni di regole di forwarding e protocollo di servizio di backend.

  • Distribuzione del traffico. Un servizio di backend consente la distribuzione del traffico in base a un'affinità sessione configurabile, alla modalità di monitoraggio delle connessioni e al bilanciamento del carico ponderato. Il servizio di backend può anche essere configurato per abilitare lo svuotamento della connessione e designare i backend di failover per il bilanciatore del carico.

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

  • Backend: ogni servizio di backend opera in una singola regione e distribuisce il traffico a gruppi di istanze o NEG a livello di zona nella stessa regione. Puoi utilizzare gruppi di istanze o NEG a livello di zona, ma non una combinazione di entrambi, come backend per un bilanciatore del carico di rete passthrough esterno:

    • Se scegli 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 NEG di zona, devi utilizzare GCE_VM_IP NEG di zona.

    A ogni gruppo di istanze o backend NEG è associata una rete VPC, anche se quel gruppo di istanze o NEG non è stato ancora connesso a un servizio di backend. Per saperne di più su come una rete viene associata a ogni tipo di backend, consulta Backend di gruppi di istanze e interfacce di rete e Interfacce di rete e backend NEG a livello di zona.

Gruppi di istanze

Un bilanciatore del carico di rete passthrough esterno distribuisce le connessioni tra le VM di backend contenute all'interno di gruppi di istanze gestite o non gestite. I gruppi di istanze possono avere un ambito a livello di regione o di zona.

Un bilanciatore del carico di rete passthrough esterno distribuisce il traffico solo alla prima interfaccia di rete (nic0) delle VM di backend. Il bilanciatore del carico supporta gruppi di istanze le cui istanze membri utilizzano qualsiasi rete VPC nella stessa regione, purché la rete VPC sia nello stesso progetto del servizio di backend. Tutte le VM all'interno di un determinato gruppo di istanze devono utilizzare la stessa rete VPC.

A ogni gruppo di istanze è associata una rete VPC, anche se quel gruppo non è stato ancora connesso a un servizio di backend. Per ulteriori informazioni su come una rete viene associata ai gruppi di istanze, consulta Backend di gruppi di istanze e interfacce di rete.

  • Gruppi di istanze gestite a livello di regione. Utilizza i gruppi di istanze gestite a livello di regione se puoi eseguire il deployment del software tramite modelli di istanza. I gruppi di istanze gestite a livello di regione distribuiscono automaticamente il traffico tra più zone, fornendo l'opzione migliore per evitare potenziali problemi in una determinata zona.

    Qui è mostrato un deployment di esempio che utilizza un gruppo di istanze gestite a livello di regione. Il gruppo di istanze ha un modello di istanza che definisce in che modo eseguire il provisioning delle istanze e ogni gruppo esegue il deployment delle istanze all'interno di tre zone della regione us-central1.

    Bilanciatore del carico di rete passthrough esterno con un gruppo di istanze gestite a livello di regione
    Bilanciatore del carico di rete passthrough esterno con un gruppo di istanze gestite a livello di regione

  • Gruppi di istanze gestite o non gestite a livello di zona. Utilizza gruppi di istanze a livello di zona in zone diverse (nella stessa regione) per proteggerti da potenziali problemi in qualsiasi zona specifica.

    Qui è mostrato un esempio di deployment mediante gruppi di istanze a livello di zona. Questo bilanciatore del carico offre disponibilità in due zone.

    Bilanciatore del carico di rete passthrough esterno con gruppi di istanze a livello di zona
    Bilanciatore del carico di rete passthrough esterno con gruppi di istanze a livello di zona

NEG a livello di zona

Un bilanciatore del carico di rete passthrough esterno distribuisce le connessioni tra GCE_VM_IP endpoint contenuti all'interno di gruppi di endpoint di rete a livello di zona. Questi endpoint devono trovarsi nella stessa regione del bilanciatore del carico. Per alcuni casi d'uso di NEG a livello di zona consigliati, consulta la panoramica sui gruppi di endpoint di rete a livello di zona.

Gli endpoint nel NEG devono essere indirizzi IPv4 interni principali delle interfacce di rete delle VM che si trovano nella stessa subnet e nella stessa zona del NEG di zona. L'indirizzo IPv4 interno primario di qualsiasi interfaccia di rete di un'istanza VM multi-NIC può essere aggiunto a un NEG, purché si trovi nella subnet del NEG.

I NEG di zona supportano sia le VM IPv4 che a doppio stack (IPv4 e IPv6). Sia per le VM IPv4 che per quelle a doppio stack, è sufficiente specificare solo l'istanza VM quando si collega un endpoint a un NEG. Non è necessario specificare l'indirizzo IP dell'endpoint. L'istanza VM deve trovarsi sempre nella stessa zona del NEG.

A ogni NEG di zona sono associate una rete VPC e una subnet, anche se quel NEG di zona non è ancora stato connesso a un servizio di backend. Per ulteriori informazioni su come una rete viene associata ai NEG a livello di zona, consulta Backend di NEG a livello di zona e interfacce di rete.

Backend di 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, la rete VPC del gruppo di istanze è definita nel modello di istanza.
  • Per i gruppi di istanze non gestite, la rete VPC del gruppo di istanze è definita come la rete VPC utilizzata dall'interfaccia di rete nic0 della prima istanza VM che aggiungi 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 (da nic1 a nic7), ma ogni interfaccia di rete deve collegarsi a una rete VPC diversa. Queste reti devono anche essere diverse dalla rete VPC associata al gruppo di istanze.

I servizi di backend non possono distribuire il traffico alle VM membri dei gruppi di istanze su interfacce non nic0. Se vuoi ricevere traffico su un'interfaccia di rete non predefinita (da nic1 a nic7), devi utilizzare NEG di zona con endpoint GCE_VM_IP.

Backend e interfacce di rete NEG a livello di zona

Quando crei un nuovo NEG a livello di zona con endpoint GCE_VM_IP, devi associare esplicitamente il NEG a una subnet di una rete VPC prima di poter aggiungere endpoint al NEG. Non è possibile modificare né la subnet né la rete VPC 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 il nome di una VM (senza indirizzo IP) quando aggiungi un endpoint, Google Cloud richiede che la VM abbia un'interfaccia di rete nella subnet associata al NEG. L'indirizzo IP che Google Cloud sceglie per l'endpoint è l'indirizzo IPv4 interno principale dell'interfaccia di rete della VM nella subnet associata al NEG.
  • Se specifichi sia un nome di VM sia un indirizzo IP quando aggiungi un endpoint, l'indirizzo IP fornito deve essere un indirizzo IPv4 interno principale di una delle interfacce di rete della VM. L'interfaccia di rete deve trovarsi nella subnet associata al NEG. Tieni presente che specificare un indirizzo IP è ridondante perché nella subnet associata al NEG può esistere una sola interfaccia di rete.

Servizi di backend e reti VPC

Il servizio di backend non è associato ad alcuna rete VPC; tuttavia, ogni gruppo di istanza di backend o NEG a livello di zona è associato a una rete VPC, come indicato in precedenza. Se tutti i backend si trovano nella stessa regione e nello stesso progetto e purché tutti i backend siano dello stesso tipo (gruppi di istanze o NEG a livello di zona), puoi aggiungere backend che utilizzano reti VPC uguali o diverse.

Per distribuire i pacchetti in nic1 tramite nic7, devi utilizzare backend NEG a livello di zona (con endpoint GCE_VM_IP) perché la rete VPC associata a un gruppo di istanze corrisponde sempre alla rete VPC utilizzata dall'interfaccia nic0 di tutte le istanze membri.

Backend a doppio stack (IPv4 e IPv6)

Se vuoi che il bilanciatore del carico supporti il traffico IPv6, i backend devono soddisfare i seguenti requisiti:

  • I backend devono essere configurati in subnet a doppio stack che si trovano nella stessa regione della regola di forwarding IPv6 del bilanciatore del carico. Per i backend, puoi utilizzare una subnet con ipv6-access-type impostato su EXTERNAL o INTERNAL. L'utilizzo di una subnet con ipv6-access-type impostato su INTERNAL richiede l'utilizzo di una subnet a doppio stack separata con ipv6-access-type impostato su EXTERNAL per la regola di forwarding esterno del bilanciatore del carico. Per le istruzioni, consulta Aggiungere una subnet a doppio stack.
  • I backend devono essere configurati in modo da essere dual stack con --ipv6-network-tier impostato su PREMIUM. Per le istruzioni, consulta Creare un modello di istanza con indirizzi IPv6.

Controlli di integrità

I bilanciatori del carico di rete passthrough esterni utilizzano i controlli di integrità a livello di regione per determinare quali istanze possono ricevere nuove connessioni. Il servizio di backend di ogni bilanciatore del carico di rete passthrough esterno deve essere associato a un controllo di integrità a livello di regione. I bilanciatori del carico usano lo stato del controllo di integrità per determinare come instradare nuove connessioni alle istanze di backend.

Per maggiori dettagli su come funzionano i controlli di integrità di Google Cloud, consulta Come funzionano i controlli di integrità.

I bilanciatori del carico di rete passthrough esterni supportano i seguenti tipi di controlli di integrità:

Controlli di integrità per altro traffico di protocolli

Google Cloud non offre controlli di integrità specifici di protocollo oltre a quelli elencati qui. Quando utilizzi un bilanciatore del carico di rete passthrough esterno per bilanciare il carico di un protocollo diverso da TCP, devi comunque eseguire un servizio basato su TCP sulle VM di backend per fornire le informazioni sul controllo di integrità richieste.

Ad esempio, se esegui il bilanciamento del carico del traffico UDP, le richieste del client vengono bilanciate tramite il protocollo UDP e devi eseguire un servizio TCP per fornire informazioni ai probe del controllo di integrità di Google Cloud. A questo scopo, puoi eseguire un semplice server HTTP su ogni VM di backend che restituisca una risposta HTTP 200 ai probe del controllo di integrità. 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.

Regole del firewall

Poiché i bilanciatori del carico di rete passthrough esterni sono bilanciatori del carico passthrough, puoi controllare l'accesso ai backend del bilanciatore del carico utilizzando le regole firewall di Google Cloud. Devi creare regole firewall di autorizzazione in entrata o un criterio firewall gerarchico di autorizzazione in entrata per consentire i controlli di integrità e il traffico del bilanciamento del carico.

Le regole di forwarding e il traffico in entrata consentono le regole firewall o i criteri firewall gerarchici funzionano insieme nel seguente modo: una regola di forwarding specifica il protocollo e, se definiti, i requisiti di porta che un pacchetto deve soddisfare per essere inoltrato a una VM di backend. Le regole firewall di autorizzazione in entrata controllano se i pacchetti inoltrati vengono consegnati alla VM o eliminati. Tutte le reti VPC hanno una regola firewall di negazione in entrata implicita che blocca i pacchetti in entrata da qualsiasi origine. La rete VPC predefinita di Google Cloud include un insieme limitato di regole firewall di autorizzazione in entrata precompilate.

  • Per accettare il traffico da qualsiasi indirizzo IP su internet, devi creare una regola firewall di autorizzazione in entrata con l'intervallo di origine 0.0.0.0/0. Per consentire solo il traffico proveniente da determinati intervalli di indirizzi IP, utilizza intervalli di origine più restrittivi.

  • Come best practice per la sicurezza, le regole firewall di autorizzazione in entrata devono consentire solo i protocolli e le porte IP di cui hai bisogno. La limitazione della configurazione del protocollo (e, se possibile, della porta) è particolarmente importante quando si utilizzano regole di forwarding il cui protocollo è impostato su L3_DEFAULT. Le regole di forwarding L3_DEFAULT inoltrano i pacchetti per tutti i protocolli IP supportati (su tutte le porte se il protocollo e il pacchetto contengono informazioni sulla porta).

  • I bilanciatori del carico di rete passthrough esterni utilizzano i controlli di integrità di Google Cloud. Di conseguenza, devi sempre consentire il traffico proveniente dagli intervalli di indirizzi IP del controllo di integrità. Queste regole firewall di autorizzazione in entrata possono essere rese specifiche per il protocollo e le porte del controllo di integrità del bilanciatore del carico.

Indirizzi IP per i pacchetti di richiesta e reso

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

  • Origine: l'indirizzo IP esterno associato a una VM Google Cloud o a un indirizzo IP instradabile su internet di un sistema che si connette al bilanciatore del carico.
  • Destinazione:l'indirizzo IP della regola di forwarding del bilanciatore del carico.

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

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

I pacchetti restituiti 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:

  • TCP è orientato alla connessione, quindi 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, ESP, GRE e ICMP sono senza connessione. Le VM di backend possono inviare pacchetti di risposta i cui indirizzi IP di origine corrispondono all'indirizzo IP della regola di forwarding o a qualsiasi indirizzo IP esterno assegnato alla VM. In pratica, la maggior parte dei client si aspetta che la risposta provenga dallo stesso indirizzo IP a cui hanno inviato i pacchetti.

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

Tipo di traffico Origine Destinazione
TCP L'indirizzo IP della regola di forwarding del bilanciatore del carico L'origine del pacchetto richiedente
UDP, ESP, GRE, ICMP Nella maggior parte dei casi d'uso, l'indirizzo IP della regola di forwarding del bilanciatore del carico † L'origine del pacchetto richiedente.

† Quando una VM ha un indirizzo IP esterno o quando utilizzi Cloud NAT, è anche possibile impostare l'indirizzo IP di origine del pacchetto di risposta sull'indirizzo IPv4 interno principale del NIC della VM. Google Cloud o Cloud NAT cambia l'indirizzo IP di origine del pacchetto di risposta nell'indirizzo IPv4 esterno del NIC o in un indirizzo IPv4 esterno di Cloud NAT per inviare il pacchetto di risposta all'indirizzo IP esterno del client. Il mancato utilizzo dell'indirizzo IP della regola di forwarding come origine è uno scenario avanzato perché il client riceve un pacchetto di risposta da un indirizzo IP esterno che non corrisponde all'indirizzo IP a cui ha inviato un pacchetto di richiesta.

Percorso di ritorno

I bilanciatori del carico di rete passthrough esterni utilizzano route speciali all'esterno della tua rete VPC per indirizzare le richieste in entrata e i probe di controllo di integrità a ogni VM di backend.

Il bilanciatore del carico conserva gli indirizzi IP di origine dei pacchetti. Le risposte delle VM di backend passano direttamente ai client, non tramite il bilanciatore del carico. Il termine del settore è ritorno diretto del server.

Architettura di un VPC condiviso

Ad eccezione dell'indirizzo IP, tutti i componenti di un bilanciatore del carico di rete passthrough esterno devono esistere nello stesso progetto. La seguente tabella riassume i componenti VPC condiviso per i bilanciatori del carico di rete passthrough esterni:

Indirizzo IP Regola di forwarding Componenti di backend
È necessario definire un indirizzo IP esterno a livello di regione nello stesso progetto del bilanciatore del carico o nel progetto host del VPC condiviso. È necessario definire una regola di forwarding esterno a livello di regione nello stesso progetto delle istanze nel servizio di backend.

Il servizio di backend a livello di regione deve essere definito nello stesso progetto e nella stessa regione in cui esistono i backend (gruppo di istanze o NEG a livello di zona).

I controlli di integrità associati al servizio di backend devono essere definiti nello stesso progetto e nella stessa regione del servizio di backend.

Distribuzione del traffico

Il modo in cui i bilanciatori del carico di rete passthrough esterni distribuiscono nuove connessioni dipende dalla configurazione del failover:

  • Se non hai configurato il failover, un bilanciatore del carico di rete passthrough esterno distribuisce nuove connessioni nelle sue VM di backend integre se almeno una VM di backend è in stato integro. Se tutte le VM di backend non sono integri, il bilanciatore del carico distribuisce le nuove connessioni tra tutti i backend come ultima risorsa. In questa situazione, il bilanciatore del carico instrada ogni nuova connessione a una VM di backend non integro.
  • Se hai configurato il failover, un bilanciatore del carico di rete passthrough esterno distribuisce le nuove connessioni tra le VM di backend integre nel proprio pool attivo, in base a un criterio di failover configurato da te. Quando tutte le VM di backend sono in stato non integro, puoi scegliere uno dei seguenti comportamenti:
    • (Predefinito) Il bilanciatore del carico distribuisce il traffico solo alle VM principali. Questa soluzione è l'ultima alternativa possibile. Le VM di backup sono escluse da questa distribuzione dell'ultima risorsa delle connessioni.
    • Il bilanciatore del carico ignora il traffico.

Per informazioni dettagliate su come vengono distribuite le connessioni, consulta la sezione successiva Selezione del backend e monitoraggio delle connessioni.

Per maggiori dettagli sul funzionamento del failover, consulta la sezione Failover.

Selezione backend e monitoraggio delle connessioni

I bilanciatori del carico di rete passthrough esterni utilizzano algoritmi di selezione del backend e monitoraggio della connessione configurabili per determinare in che modo il traffico viene distribuito alle VM di backend.

I bilanciatori del carico di rete passthrough esterni utilizzano il seguente algoritmo per distribuire i pacchetti tra le VM di backend (nel pool attivo, se hai configurato failover):

  1. Se nella tabella di monitoraggio delle connessioni del bilanciatore del carico è presente una voce corrispondente alle caratteristiche di un pacchetto in entrata, il pacchetto viene inviato al backend specificato dalla voce nella tabella di monitoraggio delle connessioni. Il pacchetto è considerato parte di una connessione stabilita in precedenza, quindi viene inviato alla VM di backend che il bilanciatore del carico aveva precedentemente determinato e registrato nella propria tabella di monitoraggio delle connessioni.

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

    1. Il bilanciatore del carico seleziona un backend. Il bilanciatore del carico calcola un hash in base all'affinità sessione configurata. Utilizza questo hash per selezionare un backend tra quelli attualmente integri (a meno che tutti i backend siano in stato non integro, nel qual caso tutti i backend sono considerati a condizione che il criterio di failover non sia stato configurato per eliminare il traffico in questa situazione). L'affinità sessione predefinita, NONE, utilizza i seguenti algoritmi hash:

      • Per i pacchetti TCP e UDP non frammentati, 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.
      • Per i pacchetti UDP frammentati e tutti gli altri protocolli, un hash a 3 tuple dell'indirizzo IP di origine del pacchetto, dell'indirizzo IP di destinazione e del protocollo.

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

      Tieni inoltre presente quanto segue:

      Se abiliti il bilanciamento del carico ponderato, la selezione di backend basata su hash diventa ponderata in base alle ponderazioni riportate dalle istanze di backend. Ad esempio:

      • Considera un servizio di backend configurato con un'affinità sessione impostata su NONE e una regola di forwarding con protocollo UDP. Se esistono due istanze di backend in stato integro con ponderazione 1 e 4, i backend riceveranno rispettivamente il 20% e l'80% dei pacchetti UDP.
      • Considera un servizio di backend configurato con affinità delle sessioni a 3 tuple e monitoraggio delle connessioni. L'affinità sessione è CLIENT_IP_PROTO e la modalità di monitoraggio delle connessioni è PER_SESSION. Se sono presenti tre istanze di backend integre con ponderazioni pari a 0, 2 e 6, i backend riceveranno rispettivamente lo 0%, il 25% e il 75% dei nuovi indirizzi IP di origine (gli indirizzi IP di origine per i quali non esistono voci della tabella di monitoraggio delle connessioni). Il traffico per le connessioni esistenti andrà ai backend assegnati in precedenza.

    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:

      • Pacchetti TCP. Il monitoraggio delle connessioni è sempre abilitato e non può essere disattivato. Per impostazione predefinita, il monitoraggio delle connessioni è a 5 tuple, ma può essere configurato per essere inferiore a 5 tuple. Quando è a 5 tuple, i pacchetti SYN TCP vengono trattati in modo diverso. A differenza dei pacchetti non SYN, ignorano qualsiasi voce di monitoraggio delle connessioni corrispondente e selezionano sempre un nuovo backend.

        Il monitoraggio delle connessioni a 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, oppure,
        • la modalità di monitoraggio è PER_SESSION e l'affinità sessione è CLIENT_IP_PORT_PROTO.

      • Pacchetti UDP, ESP e GRE. Il monitoraggio delle connessioni è abilitato solo se l'affinità sessione è impostata su un valore diverso da NONE.

      • Pacchetti ICMP e ICMPv6. Impossibile utilizzare il monitoraggio delle connessioni.

      Per ulteriori dettagli su quando il monitoraggio delle connessioni è abilitato e sul metodo di monitoraggio utilizzato quando questo è abilitato, consulta Modalità di monitoraggio delle connessioni.

      Tieni inoltre presente quanto segue:

      • Una voce nella tabella di monitoraggio delle connessioni scade 60 secondi dopo che il bilanciatore del carico ha elaborato l'ultimo pacchetto corrispondente alla voce. Questo valore di timeout di inattività di 60 secondi non è configurabile.
      • A seconda del protocollo, il bilanciatore del carico potrebbe rimuovere le voci della tabella di monitoraggio delle connessioni quando i backend sono in stato non integro. Per maggiori dettagli e per sapere come personalizzare questo comportamento, consulta Persistenza della connessione sui backend in stato non integro.

Opzioni di affinità sessione

L'affinità sessione controlla la distribuzione di nuove connessioni dai client alle VM di backend del bilanciatore del carico. L'affinità sessione è specificata per l'intero servizio di backend esterno a livello di regione, non per i singoli backend.

I bilanciatori del carico di rete passthrough esterni supportano le seguenti opzioni di affinità sessione:

  • Nessuno (NONE). Hash a 5 tuple di indirizzo IP di origine, porta di origine, protocollo, indirizzo IP di destinazione e porta di destinazione
  • IP client, IP di destinazione (CLIENT_IP). Hash a 2 tuple dell'indirizzo IP di origine e dell'indirizzo IP di destinazione
  • IP client, IP di destinazione, protocollo (CLIENT_IP_PROTO). Hash a 3 tuple di indirizzo IP di origine, indirizzo IP di destinazione e protocollo
  • IP client, porta client, IP di destinazione, porta di 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

Per scoprire in che modo queste opzioni di affinità sessione influiscono sulla selezione del backend e sui metodi di monitoraggio delle connessioni, consulta questa tabella.

Modalità di monitoraggio delle connessioni

L'abilitazione del monitoraggio delle connessioni dipende solo dal protocollo del traffico con bilanciamento del carico e dalle impostazioni di affinità sessione. La modalità di monitoraggio specifica l'algoritmo di monitoraggio delle connessioni da utilizzare quando il monitoraggio delle connessioni è abilitato. Esistono due modalità di monitoraggio: PER_CONNECTION (predefinita) e PER_SESSION.

  • PER_CONNECTION (valore predefinito). Questa è la modalità di monitoraggio predefinita. Con questa modalità di monitoraggio delle connessioni, il traffico TCP viene sempre monitorato per 5 tuple, indipendentemente dall'impostazione di affinità sessione. Per il traffico UDP, ESP e GRE, il monitoraggio delle connessioni è abilitato quando l'affinità sessione selezionata non è NONE. I pacchetti UDP, ESP e GRE vengono monitorati utilizzando i metodi di monitoraggio descritti in questa tabella.

  • PER_SESSION. Se l'affinità sessione è CLIENT_IP o CLIENT_IP_PROTO, la configurazione di questa modalità comporta rispettivamente il monitoraggio delle connessioni a due e tre tuple per tutti i protocolli (tranne ICMP e ICMPv6, che non sono monitorabili dalla connessione). Per altre impostazioni di affinità sessione, la modalità PER_SESSION si comporta in modo identico alla modalità PER_CONNECTION.

Per informazioni sul funzionamento di queste modalità di monitoraggio con impostazioni di affinità sessione diverse per ciascun protocollo, consulta la tabella seguente.

Selezione backend Modalità di monitoraggio delle connessioni
Impostazione di affinità sessione Metodo hash per la selezione del backend PER_CONNECTION (valore predefinito) PER_SESSION
Predefinito:nessuna affinità sessione

(NONE)

TCP e UDP non frammentato: hash a 5 tuple

UDP frammentato e tutti gli altri protocolli: hash a 3 tuple
  • TCP:monitoraggio delle connessioni a 5 tuple
  • Tutti gli altri protocolli:monitoraggio della connessione disattivato
  • TCP: monitoraggio delle connessioni a 5 tuple
  • Tutti gli altri protocolli:monitoraggio della connessione disattivato
IP client, IP di destinazione

(CLIENT_IP)

 Tutti i protocolli:hash a 2 tuple
  • TCP e UDP non frammentato: monitoraggio delle connessioni a 5 tuple
  • UDP, ESP e GRE frammentati: monitoraggio delle connessioni a 3 tuple
  • Tutti gli altri protocolli:monitoraggio della connessione disattivato
  • TCP, UDP, ESP, GRE: monitoraggio della connessione a due tuple
  • Tutti gli altri protocolli:monitoraggio della connessione disattivato
IP client, IP di destinazione, protocollo

(CLIENT_IP_PROTO)

 Tutti i protocolli:hash a 3 tuple
  • TCP e UDP non frammentato: monitoraggio delle connessioni a 5 tuple
  • UDP, ESP e GRE frammentati: monitoraggio delle connessioni a 3 tuple
  • Tutti gli altri protocolli:monitoraggio della connessione disattivato
  • TCP, UDP, ESP, GRE: monitoraggio della connessione a tre tuple
  • Tutti gli altri protocolli:monitoraggio della connessione disattivato
IP client, porta client, IP di destinazione, porta di destinazione, protocollo

(CLIENT_IP_PORT_PROTO)

TCP e UDP non frammentato: hash a 5 tuple

UDP frammentato e tutti gli altri protocolli: hash a 3 tuple
  • TCP e UDP non frammentato: monitoraggio delle connessioni a 5 tuple
  • UDP, ESP e GRE frammentati: monitoraggio delle connessioni a 3 tuple
  • Tutti gli altri protocolli:monitoraggio della connessione disattivato
  • TCP e UDP non frammentato: monitoraggio delle connessioni a 5 tuple
  • UDP, ESP e GRE frammentati: monitoraggio delle connessioni a 3 tuple
  • Tutti gli altri protocolli:monitoraggio della connessione disattivato

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 controllano se una connessione esistente rimane su una VM o un endpoint di backend selezionati dopo che il backend diventa non integro, purché il backend rimanga nel gruppo di backend configurato del bilanciatore del carico (in un gruppo di istanze o in un NEG).

Il comportamento descritto in questa sezione non si applica ai casi in cui viene rimossa un'istanza di backend da un gruppo di istanze, si rimuove un endpoint di backend dal relativo NEG oppure si rimuove il gruppo di istanze o il NEG dal servizio di backend. In questi casi, le connessioni stabilite vengono mantenute solo come descritto nella sezione relativa allo svuotamento della connessione.

Sono disponibili le seguenti opzioni di persistenza della connessione:

  • DEFAULT_FOR_PROTOCOL (valore predefinito)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

La seguente tabella riassume le opzioni di persistenza della connessione e il modo in cui le connessioni vengono mantenute per diversi protocolli, opzioni di affinità sessione e modalità di monitoraggio.

Opzione Permanenza della connessione su backend in stato non integro Modalità di monitoraggio delle connessioni
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP: le connessioni rimangono invariate su backend in stato non integro (tutte le affinità delle sessioni)

Tutti gli altri protocolli:le connessioni non vengono mai mantenute su backend in stato non integro

TCP: le connessioni rimangono invariate su backend in stato non integro se l'affinità sessione è NONE o CLIENT_IP_PORT_PROTO

Tutti gli altri protocolli:le connessioni non vengono mai mantenute su backend in stato non integro
NEVER_PERSIST Tutti i protocolli:le connessioni non vengono mai mantenute su backend in stato non integro
ALWAYS_PERSIST

TCP: le connessioni rimangono invariate su backend in stato non integro (tutte le affinità delle sessioni)

ESP, GRE, UDP: le connessioni rimangono invariate su backend in stato non integro se l'affinità sessione non è NONE

ICMP, ICMPv6: non applicabili perché non sono monitorabili per la connessione

Questa opzione deve essere utilizzata solo per casi d'uso avanzato.

 Configurazione impossibile

Comportamento di persistenza della connessione TCP su backend in stato non integro

Ogni volta che una connessione TCP con monitoraggio a 5 tuple persiste in un backend in stato non integro:

  • Se il backend in stato non integro continua a rispondere ai pacchetti, la connessione continua fino a quando non viene reimpostata o chiusa (dal backend in stato non integro o dal client).
  • Se il backend in stato non integro invia un pacchetto di reimpostazione TCP (RST) o non risponde ai pacchetti, il client potrebbe riprovare con una nuova connessione, consentendo al bilanciatore del carico di selezionare un backend diverso e integro. I pacchetti SYN TCP selezionano sempre un nuovo backend integro.

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

Bilanciamento del carico ponderato

Puoi configurare un bilanciatore del carico di rete per distribuire il traffico tra le istanze di backend del bilanciatore del carico in base alle ponderazioni riportate da un controllo di integrità HTTP utilizzando il bilanciamento del carico ponderato.

Il bilanciamento del carico ponderato richiede la configurazione di entrambi i seguenti elementi:

  • Devi impostare il criterio del bilanciatore del carico per la località (localityLbPolicy) del servizio di backend su WEIGHTED_MAGLEV.
  • Devi configurare il servizio di backend con un controllo di integrità HTTP. Le risposte del controllo di integrità HTTP devono contenere un campo intestazione della risposta HTTP personalizzato X-Load-Balancing-Endpoint-Weight per specificare le ponderazioni con valori compresi tra 0 e 1000 per ogni istanza di backend.

Se utilizzi lo stesso backend (gruppo di istanze o NEG) per più bilanciatori del carico di rete passthrough esterni basati su servizi di backend che utilizzano il bilanciamento del carico ponderato, ti consigliamo di utilizzare un request-path univoco per ogni controllo di integrità del servizio di backend. In questo modo l'istanza dell'endpoint può assegnare ponderazioni diverse a servizi di backend diversi. Per ulteriori informazioni, consulta Criteri di esito positivo per i controlli di integrità HTTP, HTTPS e HTTP/2.

Per selezionare un backend per una nuova connessione, ai backend viene assegnato un ordine di priorità rigoroso in base al peso e allo stato di integrità, come mostrato nella seguente tabella:

Ponderazione Integro Priorità selezione backend
Ponderazione maggiore di zero Sì 4
Ponderazione maggiore di zero No 3
Il peso è uguale a zero Sì 2
Il peso è uguale a zero No 1

Solo i backend con priorità più alta sono idonei per la selezione del backend. Se tutti i backend idonei hanno una ponderazione pari a zero, il bilanciatore del carico distribuisce le nuove connessioni tra tutti i backend idonei, trattandoli con la stessa ponderazione. Per esempi di bilanciamento del carico ponderato, consulta Selezione del backend e monitoraggio delle connessioni.

Il bilanciamento del carico ponderato può essere utilizzato nei seguenti scenari:

  • Se alcune connessioni elaborano più dati di altre o se alcune connessioni durano più di altre, la distribuzione del carico di backend potrebbe diventare non uniforme. Indicando una ponderazione per istanza inferiore, un'istanza con carico elevato può ridurre la propria quota di nuove connessioni, mantenendo al contempo le connessioni esistenti.

  • Se un backend è sovraccarico e l'assegnazione di più connessioni potrebbe interrompere le connessioni esistenti, questi backend si assegnano zero. Se segnali un'istanza di peso pari a zero, un'istanza di backend smette di gestire le nuove connessioni, ma continua a gestire quelle esistenti.

  • Se un backend svuota le connessioni esistenti prima della manutenzione, si assegna zero peso. Indicando la gravità zero, l'istanza di backend smette di gestire le nuove connessioni, ma continua a servire quelle esistenti.

Per maggiori informazioni, consulta Configurare il bilanciamento del carico ponderato.

Svuotamento della connessione

Lo svuotamento delle connessioni è un processo applicato alle connessioni stabilite nei seguenti casi:

  • Una VM o un endpoint viene rimosso da un backend (gruppo di istanze o NEG).
  • Un backend rimuove una VM o un endpoint (per sostituzione, abbandono, durante l'esecuzione di upgrade o lo scale down).
  • Un backend viene rimosso da un servizio di backend.

Per impostazione predefinita, lo svuotamento della connessione è disabilitato. Quando questa opzione è disabilitata, le connessioni stabilite vengono terminate il più rapidamente possibile. Quando è abilitato lo svuotamento della connessione, le connessioni stabilite possono rimanere per un timeout configurabile, dopo il quale l'istanza VM di backend viene terminata.

Per maggiori dettagli su come viene attivato lo svuotamento della connessione e su come abilitarlo, consulta Attivazione dello svuotamento delle connessioni.

Frammentazione UDP

I bilanciatori del carico di rete passthrough esterni basati su servizi di backend possono elaborare pacchetti UDP frammentati e non frammentati. Se l'applicazione utilizza pacchetti UDP frammentati, tieni presente quanto segue:

  • I pacchetti UDP potrebbero frammentarsi prima di raggiungere una rete VPC Google Cloud.
  • Le reti VPC di Google Cloud inoltrano i frammenti UDP all'arrivo (senza attendere l'arrivo di tutti i frammenti).
  • Le reti non Google Cloud e le apparecchiature di rete on-premise potrebbero inoltrare i frammenti UDP all'arrivo, ritardare i pacchetti UDP frammentati fino all'arrivo di tutti i frammenti o eliminare i pacchetti UDP frammentati. Per i dettagli, consulta la documentazione del provider di rete o dell'apparecchiatura di rete.

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

  • Configurazione della regola di forwarding: utilizza solo una regola di forwarding UDP o L3_DEFAULT per indirizzo IP con bilanciamento del carico e configura la regola di forwarding in modo che accetti il traffico su tutte le porte. Ciò garantisce che tutti i frammenti arrivino alla stessa regola di forwarding. Anche se i pacchetti frammentati (diversi dal primo frammento) non hanno una porta di destinazione, se configuri la regola di forwarding per l'elaborazione del traffico per tutte le porte, la porta viene anche configurata in modo da ricevere frammenti UDP senza informazioni sulle porte. Per configurare tutte le porte, utilizza Google Cloud CLI per impostare --ports=ALL o 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 a due tuple) o CLIENT_IP_PROTO (hash a tre tuple), in modo che venga selezionato lo stesso backend per i pacchetti UDP che includono informazioni sulla porta e frammenti UDP (diversi dal primo frammento) privi di 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 a due o tre tuple.

Utilizzo delle istanze di destinazione come backend

Se utilizzi istanze di destinazione come backend per il bilanciatore del carico di rete passthrough esterno e prevedi pacchetti UDP frammentati, utilizza solo una regola di forwarding UDP o L3_DEFAULT per indirizzo IP e configura la regola di forwarding in modo che accetti il traffico su tutte le porte. Ciò garantisce che tutti i frammenti arrivino alla stessa regola di forwarding anche se non hanno la stessa porta di destinazione. Per configurare tutte le porte, imposta --ports=ALL utilizzando gcloud oppure imposta allPorts su True utilizzando l'API.

Failover

Puoi configurare un bilanciatore del carico di rete passthrough esterno per distribuire le connessioni tra istanze VM o endpoint nei backend primari (gruppi di istanze o NEG) e quindi, se necessario, passare all'utilizzo di backend di failover. Il failover fornisce un ulteriore metodo per aumentare la disponibilità e, allo stesso tempo, offre un maggiore controllo su come gestire il carico di lavoro quando i backend principali non sono integri.

Per impostazione predefinita, quando aggiungi un backend al servizio di backend di un bilanciatore del carico di rete passthrough esterno, questo è un backend principale. Puoi designare un backend come backend di failover aggiungendolo al servizio di backend del bilanciatore del carico o modificando il servizio di backend in un secondo momento.

Per maggiori dettagli su come funziona il failover, consulta la Panoramica del failover per i bilanciatori del carico di rete passthrough esterni.

Limitazioni

  • Non puoi utilizzare la console Google Cloud per le seguenti attività:

    • Crea o modifica un bilanciatore del carico di rete passthrough esterno la cui regola di forwarding utilizza il protocollo L3_DEFAULT.
    • Crea o modifica un bilanciatore del carico di rete passthrough esterno il cui protocollo del servizio di backend è impostato su UNSPECIFIED.
    • Crea o modifica un bilanciatore del carico di rete passthrough esterno che configura un criterio di monitoraggio delle connessioni.
    • Crea o modifica l'indirizzamento del traffico basato su IP di origine per una regola di forwarding.

    Utilizza Google Cloud CLI o l'API REST.

  • I bilanciatori del carico di rete passthrough esterni non supportano il peering di rete VPC.

Passaggi successivi