Panoramica del bilanciatore del carico di rete passthrough esterno basato sul servizio 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 i 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 cliente su internet
  • VM Google Cloud con IP esterni
  • VM Google Cloud con accesso a internet tramite Cloud NAT o NAT basata su istanza

I bilanciatori del carico di rete passthrough esterni non sono proxy. Il bilanciatore del carico stesso 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 degli utenti. Le risposte provenienti dalle VM di backend vengono inviate direttamente ai client, non tramite il bilanciatore del carico. Questa procedura è nota come direct server return (DSR).

I bilanciatori del carico di rete passthrough esterni basati sui 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 sia i gruppi di istanze gestite che quelli 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 sui servizi di backend supportano l'utilizzo di NEG di zona con endpoint GCE_VM_IP. Gli endpoint GCE_VM_IP NEG a livello di zona ti consentono di:
    • Inoltra i pacchetti a qualsiasi interfaccia di rete, non solo a nic0.
    • Posiziona lo stesso endpoint GCE_VM_IP in due o più NEG di zona collegati a diversi servizi di backend.
  • Supporto di più protocolli. I bilanciatori del carico di rete passthrough esterni basati sui 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 sui servizi di backend possono gestire sia il traffico IPv4 sia quello IPv6.
  • Controllo granulare della distribuzione del traffico. Un servizio di backend consente di distribuire il traffico in base a un'affinità sessione, a una modalità di monitoraggio delle connessioni e a un bilanciamento del carico ponderato configurabili. Il servizio di backend può anche essere configurato per abilitare lo svuotamento delle connessioni e designare backend di failover per il bilanciatore del carico. La maggior parte di queste impostazioni ha valori predefiniti che ti consentono di iniziare rapidamente.
  • Supporto per i controlli di integrità non legacy. I bilanciatori del carico di rete passthrough esterni basati su servizi di backend consentono di utilizzare controlli di integrità corrispondenti al tipo di traffico (TCP, SSL, HTTP, HTTPS o HTTP/2) che stanno distribuendo.
  • Integrazione di Google Cloud Armor. Google Cloud Armor supporta la protezione DDoS di rete avanzata per i bilanciatori del carico di rete passthrough esterni. Per ulteriori informazioni, consulta Configurare la protezione DDoS di rete avanzata.

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

    Documentazione di 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 regionali
  • Una o più regole di inoltro esterno regionali
  • 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 al traffico del bilanciamento del carico e ai probe 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 regionale accessibile da qualsiasi parte di internet.

  • Per il traffico IPv4, la regola di forwarding fa riferimento a un singolo indirizzo IPv4 esterno regionale. Gli indirizzi IPv4 esterni regionali 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 di 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 riutilizzarlo dopo aver eliminato una regola di inoltro o se hai bisogno di più regole di inoltro che fanno 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 inoltro 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 regionale 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, trasmettono il traffico ai backend sullo stesso protocollo e sulle stesse porte, se il pacchetto contiene informazioni sulle porte. La regola di forwarding in combinazione con l'indirizzo IP costituisce 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 viene associato a una regola di forwarding, che è una combinazione di un determinato indirizzo IP (un indirizzo IPv4 o un intervallo di indirizzi IPv6), un protocollo e, se il protocollo è basato su 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, non è associata a nessuna subnet. In altre parole, il suo 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 inoltro deve essere associata a una subnet e questa subnet 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 scelta. 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 inoltro possono essere configurate per 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 Indirizzamento del traffico. Puoi definire più regole di inoltro per lo stesso bilanciatore del carico come descritto in Più regole di inoltro.

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.

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 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 ESP e traffico IKE e NAT-T basato su UDP. L'opzione L3_DEFAULT consente di configurare una singola regola di forwarding per l'elaborazione di tutti questi protocolli.

Le regole di inoltro che utilizzano i protocolli TCP o UDP possono fare riferimento a un servizio di backend che utilizza lo stesso protocollo della regola di forwarding o a 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 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 TCP TCP o UNSPECIFIED
L3_DEFAULT UNSPECIFIED
UDP UDP UDP o UNSPECIFIED
L3_DEFAULT UNSPECIFIED
ESP, GRE, ICMP/ICMPv6 (solo richiesta di eco) L3_DEFAULT UNSPECIFIED

Più regole di forwarding

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

La configurazione di più regole di inoltro 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 bilanciatori del carico specifici.

Google Cloud richiede che i pacchetti in arrivo corrispondano a non più di una regola di forwarding. Ad eccezione delle regole di inoltro di sterzo, discusse nella sezione successiva, due o più regole di inoltro che utilizzano lo stesso indirizzo IP esterno regionale devono avere combinazioni di protocolli e porte univoche in base a questi vincoli:

  • Una regola di forwarding configurata per tutte le porte di un protocollo impedisce la creazione di altre regole di inoltro che utilizzano lo stesso protocollo e lo stesso indirizzo IP. Le regole di inoltro che utilizzano i protocolli TCP o UDP possono essere configurate per utilizzare tutte le porte o 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 regola di forwarding utilizzando l'indirizzo IP 198.51.100.1 e il protocollo TCP. Puoi creare due regole di inoltro, entrambe che utilizzano 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 inoltro utilizzando l'indirizzo IP198.51.100.1 e il protocollo TCP, in cui le porte di una regola di forwarding sono80,443 e l'altra utilizza l'intervallo di porte 81-442.
  • Per indirizzo IP può essere creata una sola regola di forwarding L3_DEFAULT. Questo accade perché il protocollo L3_DEFAULT utilizza tutte le porte per definizione. In questo contesto, il termine tutte le porte include i protocolli senza informazioni sulle porte.

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

    Per illustrare questo concetto, prendiamo in considerazione questi due scenari. Le regole di inoltro in entrambi gli scenari 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 198.51.100.1 vengono elaborati dalla seconda regola di forwarding. I pacchetti che utilizzano 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 i pacchetti TCP inviati a porte di destinazione diverse, vengono elaborati dalla prima regola di forwarding.

Selezione della regola di inoltro

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

  • Elimina le regole di inoltro il cui protocollo non corrisponde a quello del pacchetto, tranne le regole di inoltro L3_DEFAULT. Le regole di inoltro che utilizzano il protocolloL3_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 inoltro che utilizzano il protocollo UDP.

  • Elimina le regole di inoltro la cui porta non corrisponde a quella del pacchetto. Le regole di inoltro 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 regola di forwarding rimanenti candidate includono sia le regole di inoltro L3_DEFAULT sia quelle specifiche per protocollo, elimina le regole di inoltro L3_DEFAULT. Se le regola di forwarding rimanenti sono tutte L3_DEFAULT regole di inoltro, nessuna viene eliminata in questo passaggio.

  • A questo punto, le regola di forwarding rimanenti rientrano in una delle seguenti categorie:

    • Rimane una singola regola di forwarding che corrisponde all'indirizzo IP, al protocollo e alla porta di destinazione del pacchetto e viene utilizzata per inoltrarlo.
    • Rimangono due o più regola di forwarding candidate che corrispondono all'indirizzo IP, al protocollo e alla porta di destinazione del pacchetto. Ciò significa che le altre possibili regola di forwarding includono le regole di inoltro di reindirizzamento (discusse nella sezione successiva). Seleziona la regola di inoltro di instradamento il cui intervallo source include il CIDR più specifico (corrispondenza del prefisso più lungo) contenente l'indirizzo IP di provenienza del pacchetto. Se nessuna regola di inoltro di orientamento ha un intervallo di origine che include l'indirizzo IP di origine del pacchetto, seleziona la regola di forwarding principale.
    • Non ci sono regola di forwarding candidate e il pacchetto viene ignorato.

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

Indirizzamento del traffico

Le regole di inoltro per i bilanciatori del carico di rete passthrough esterni possono essere configurate per indirizzare il traffico proveniente da un intervallo specifico di indirizzi IP di origine a un servizio di backend (o istanza di destinazione) specifico.

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

  • Lo steering del traffico ti consente di creare due regole di inoltro 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 delle connessioni, svuotamento della connessione e failover).
  • L'indirizzamento del traffico ti consente di creare una regola di forwarding per reindirizzare il traffico da un servizio di backend a bassa larghezza di banda a un servizio di backend ad alta larghezza di banda. Entrambi i servizi di backend contengono lo stesso insieme di endpoint o VM di backend, ma il bilanciamento del carico avviene con pesi diversi utilizzando il bilanciamento del carico ponderato.
  • L'indirizzamento del traffico ti consente di creare due regole di inoltro che indirizzano il traffico a diversi servizi di backend, con backend diversi (gruppi di istanze o NEG). Ad esempio, un backend potrebbe essere configurato utilizzando diversi tipi di macchine per elaborare meglio il traffico da un determinato insieme di indirizzi IP di origine.

La gestione del traffico viene configurata con un parametro API regola di forwarding chiamato sourceIPRanges. Le regole di inoltro con almeno un intervallo IP di origine configurato sono chiamate regole di inoltro per l'indirizzamento.

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

Ogni regola di inoltro di orientamento richiede innanzitutto la creazione di una regola di inoltro principale. Le regole di inoltro principali e di instradamento condividono lo stesso indirizzo IP esterno regionale, lo stesso protocollo IP e le stesse informazioni sulla porta. Tuttavia, la regola di forwarding principale non contiene informazioni sull'indirizzo IP di origine. Ad esempio:

  • Regola di inoltro principale: indirizzo IP: 198.51.100.1, protocollo IP: TCP, porte: 80
  • Regola di inoltro di orientamento: indirizzo IP: 198.51.100.1, protocollo IP: TCP, porte: 80, intervalli IP di origine: 203.0.113.0/24

Una regola di forwarding principale che rimanda a un servizio di backend può essere associata a una regola di inoltro di orientamento che rimanda a un servizio di backend o a un'istanza di destinazione.

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

Devi eliminare tutte le regole di inoltro di orientamento prima di poter eliminare la regola di forwarding principale 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 dell'affinità sessione in caso di modifiche alle impostazioni di indirizzamento

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

  • 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 orientamento, l'affinità della sessione non viene interrotta. Se la modifica comporta una corrispondenza di una connessione esistente con una regola di forwarding diversa:
  • L'affinità sessione viene sempre interrotta nelle seguenti circostanze:
    • La regola di forwarding appena trovata indirizza una connessione stabilita a un servizio di backend (o istanza di destinazione) che non fa riferimento alla VM di backend selezionata in precedenza.
    • La regola di forwarding appena associata 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 non sono integri e la VM di backend non supera il controllo di integrità del servizio di backend.
  • L'affinità di sessione potrebbe non funzionare quando la regola di forwarding appena associata 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.

Preservare l'affinità sessione durante le modifiche al timone

Questa sezione descrive come evitare di interrompere l'affinità sessione quando gli intervalli IP di origine per le regole di inoltro dello steering vengono aggiornati:

  • Regole di inoltro che indirizzano il traffico ai servizi di backend. Se sia la regola di inoltro principale sia quella di inoltro di orientamento rimandano a servizi di backend, dovrai assicurarti manualmente che le impostazioni di affinità di sessione e norme di monitoraggio delle connessioni siano identiche. Google Cloud non rifiuta automaticamente le configurazioni se non sono identiche.
  • Regole di inoltro che indirizzano le richieste alle istanze target. Una regola di forwarding principale che rimanda a un servizio di backend può essere associata a una regola di inoltro di orientamento che rimanda a un'istanza di destinazione. In questo caso, la regola di inoltro di orientamento eredita le impostazioni di affinità sessione e dei criteri di monitoraggio delle connessioni dalla regola di forwarding principale.

Per istruzioni su come configurare la gestione del traffico, consulta Configurare la gestione del traffico.

Servizio di backend regionale

Ogni bilanciatore del carico di rete passthrough esterno ha un servizio di backend regionale che definisce il comportamento del bilanciatore del carico e la modalità di distribuzione del traffico ai suoi backend. Il nome del servizio di backend è il nome del bilanciatore del carico di rete passthrough esterno visualizzato 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 inoltro esterno a livello di regione. Il servizio di backend passa i pacchetti alle VM di backend preservando gli indirizzi IP di origine e di destinazione, il protocollo e, se il protocollo è basato su porte, le porte di origine e di destinazione dei pacchetti.

    I servizi di backend utilizzati con i 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. I servizi di backend con un protocollo specifico (TCP o UDP) possono essere richiamati solo dalle regole di inoltro con lo stesso protocollo (TCP o UDP). Le regole di inoltro con il protocollo L3_DEFAULT possono fare riferimento solo ai servizi di backend con il protocollo UNSPECIFIED.

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

  • Distribuzione del traffico. Un servizio di backend consente di distribuire il traffico in base a un'affinità sessione, a una modalità di monitoraggio delle connessioni e a un bilanciamento del carico ponderato configurabili. Il servizio di backend può anche essere configurato per abilitare lo svuotamento delle connessioni e designare backend di failover per il bilanciatore del carico.

  • Controllo di integrità. Un servizio di backend deve avere un controllo di integrità regionale associato.

  • Backend: ogni servizio di backend opera in un'unica regione e distribuisce il traffico ai gruppi di istanze o ai NEG di zona nella stessa regione. 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 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 i NEG a livello di zona, devi utilizzare GCE_VM_IP NEG a livello di zona.

    Ogni gruppo di istanze o backend NEG ha una rete VPC associata, anche se il gruppo di istanze o il NEG non è ancora stato collegato 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.

Gruppi di istanze

Un bilanciatore del carico di rete passthrough esterno distribuisce le connessioni tra le VM di backend contenute in gruppi di istanze gestiti o non gestiti. I gruppi di istanze possono essere regionali o a livello 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 i gruppi di istanze le cui istanze member utilizzano qualsiasi rete VPC nella stessa regione, purché la rete VPC si trovi nello stesso progetto del servizio di backend. Tutte le VM all'interno di un determinato gruppo di istanze devono utilizzare la stessa rete VPC.

Ogni gruppo di istanze ha una rete VPC associata, anche se il gruppo di istanze non è ancora stato collegato a un servizio di backend. Per ulteriori informazioni su come una rete è associata ai gruppi di istanze, consulta Backend e interfacce di rete dei gruppi di istanze.

Il bilanciatore del carico di rete passthrough esterno è altamente disponibile per progettazione. Non sono necessari passaggi speciali per rendere il bilanciatore del carico ad alta disponibilità perché il meccanismo non si basa su un singolo dispositivo o istanza VM. Devi solo assicurarti che le istanze VM di backend vengano implementate in più zone in modo che il bilanciatore del carico possa risolvere i potenziali problemi in una determinata zona.

  • 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 utilizzando i modelli di istanza. I gruppi di istanze gestite a livello di regione distribuiscono automaticamente il traffico tra più zone, offrendo la migliore opzione per evitare potenziali problemi in una determinata zona.

    Di seguito è riportato un esempio di deployment che utilizza un gruppo di istanze gestite a livello di regione. Il gruppo di istanze ha un modello di istanza che definisce come deve essere eseguito il provisioning delle istanze e ogni gruppo esegue il deployment delle istanze in tre zone della regioneus-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 regionale

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

    Di seguito è riportato un esempio di deployment che utilizza gruppi di istanze zonali. Questo bilanciatore del carico garantisce la disponibilità in due zone.

    Bilanciatore del carico di rete passthrough esterno con gruppi di istanze zonali
    Bilanciatore del carico di rete passthrough esterno con gruppi di istanze zonali

NEG a livello di zona

Un bilanciatore del carico di rete passthrough esterno distribuisce le connessioni tra gli endpoint GCE_VM_IP contenuti nei 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 consigliati per i NEG a livello di zona, consulta la panoramica dei gruppi di endpoint di rete a livello di zona.

Gli endpoint nel NEG devono essere indirizzi IPv4 interni principali delle interfacce di rete della 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 con più NIC può essere aggiunto a un NEG purché si trovi nella subnet del NEG.

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

Ogni NEG zonale ha una rete VPC e una subnet associate, anche se non è ancora stato collegato a un servizio di backend. Per ulteriori informazioni su come una rete è associata ai NEG a livello di zona, consulta Backend e interfacce di rete dei NEG a livello di zona.

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.

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

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.

Servizi di backend e reti VPC

Il servizio di backend non è associato a nessuna rete VPC. Tuttavia, ogni gruppo di istanza di backend o NEG zonale è associato a una rete VPC, come indicato in precedenza. Purché tutti i backend si trovino nella stessa regione e nello stesso progetto e siano dello stesso tipo (gruppi di istanze o NEG zonali), puoi aggiungere backend che utilizzano la stessa rete VPC o reti VPC diverse.

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

Back-end 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 dual-stack che si trovano nella stessa regione della regola di inoltro IPv6 del bilanciatore del carico. Per i backend, puoi utilizzare una sottorete 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 istruzioni, vedi Aggiungere una sottorete dual-stack.
  • I backend devono essere configurati in modalità 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à regionali 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à regionale. I bilanciatori del carico utilizzano lo stato del controllo di integrità per determinare come instradare le nuove connessioni alle istanze di backend.

Per ulteriori dettagli sul funzionamento dei controlli di stato di Google Cloud, consulta Come funzionano i controlli di stato.

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

Controlli di integrità per il traffico di altri protocolli

Google Cloud non offre controlli di integrità specifici per i protocolli oltre a quelli elencati nella sezione Controlli di integrità, all'inizio di questa pagina. 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 necessarie per i controllo di integrità.

Ad esempio, se esegui il bilanciamento del carico del traffico UDP, le richieste dei client vengono bilanciate utilizzando il protocollo UDP e devi eseguire un servizio TCP per fornire informazioni ai sondaggi di controllo di integrità di Google Cloud. Per farlo, puoi eseguire un server HTTP su ogni VM di backend che restituisce una risposta HTTP 200 ai sondaggi di 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 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 del firewall di Google Cloud. Devi creare regole firewall che consentano il traffico in entrata o un criterio firewall gerarchico che consenta il traffico in entrata per consentire i controlli di integrità e il traffico sottoposto a bilanciamento del carico.

Le regole di inoltro e di entrata consentono alle regole firewall o ai criteri firewall gerarchici di lavorare insieme nel seguente modo: una regola di forwarding specifica il protocollo e, se definiti, i requisiti della 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 inviati alla VM o ignorati. Tutte le reti VPC hanno una regola firewall 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 predefinite.

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

  • Come best practice per la sicurezza, le regole del firewall che consentono l'ingresso 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 le regole di inoltro il cui protocollo è impostato su L3_DEFAULT. Le regole di L3_DEFAULT forwarding 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 per il traffico in entrata possono essere specifiche per il protocollo e le porte del controllo di integrità del bilanciatore del carico.

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'indirizzo IP esterno associato a una VM Google Cloud o l'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 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, ESP, GRE e ICMP sono senza connessione. 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 esterno 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, ESP, GRE, ICMP 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.

† 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 della NIC della VM. Google Cloud o Cloud NAT modifica l'indirizzo IP di origine del pacchetto di risposta nell'indirizzo IPv4 esterno della 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 al di fuori della rete VPC per indirizzare le richieste in arrivo 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 vengono inviate direttamente ai client, non tramite il bilanciatore del carico. Il termine di settore è direct server return.

Architettura VPC condiviso

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

Indirizzo IP Regola di forwarding Componenti di backend
Un annuncio IP esterno regionale deve essere definito nello stesso progetto del bilanciatore del carico o nel progetto host VPC condiviso. Deve essere definita una regola di inoltro esterno regionale nello stesso progetto delle istanze nel servizio di backend.

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

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 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 esterno distribuisce le nuove connessioni alle VM di backend integre se almeno una VM di backend è integra. Quando tutte le VM di backend non sono integre, come ultima risorsa il bilanciatore del carico distribuisce le nuove connessioni tra tutti i backend. In questa situazione, il bilanciatore del carico indirizza ogni nuova connessione a una VM di backend non integra.
  • Se hai configurato il failover, un bilanciatore del carico di rete passthrough esterno distribuisce le nuove connessioni tra le VM di backend integre nel pool attivo, in base a un criterio di failover configurato. Quando tutte le VM di backend non sono in stato integro, puoi scegliere 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 perde traffico.

Per informazioni dettagliate sulla distribuzione delle connessioni, consulta la sezione successiva Selezione del backend e monitoraggio delle connessioni.

Per informazioni dettagliate sul funzionamento del failover, consulta la sezione Failover.

Monitoraggio della selezione e della connessione del backend

I bilanciatori del carico di rete passthrough esterni 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 esterni 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 tra quelli integri (a meno che non siano tutti non integri, nel qual caso vengono considerati tutti i backend, a condizione che il criterio di failover non sia stato configurato per interrompere il traffico in questa situazione). L'affinità sessione predefinita, NONE, utilizza i seguenti algoritmi di hashing:

      • 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 per tutti gli altri protocolli, un hash a tre tuple dell'indirizzo IP di origine, dell'indirizzo IP 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.

      Inoltre, tieni presente quanto segue:

      Se attivi il bilanciamento del carico ponderato, la selezione del backend basata su hash diventa ponderata in base ai pesi registrati dalle istanze del backend. Ad esempio:

      • Prendi in considerazione un servizio di backend configurato con l'affinità sessione impostata su NONE e una regola di forwarding con protocollo UDP. Se sono presenti due istanze di backend attive con pesi 1 e 4, i backend riceveranno rispettivamente il 20% e l'80% dei pacchetti UDP.
      • Prendi in considerazione un servizio di backend configurato con affinità di sessione e monitoraggio delle connessioni di terne. L'affinità sessione è CLIENT_IP_PROTO e la modalità di monitoraggio delle connessioni è PER_SESSION. Se sono presenti tre istanze di backend integre con pesi 0, 2 e 6, i backend riceveranno rispettivamente il 0%, il 25% e il 75% del traffico per i nuovi indirizzi IP di origine (ovvero gli indirizzi IP di origine per i quali non esistono voci della tabella di monitoraggio delle connessioni). Il traffico per le connessioni esistenti verrà inviato 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 attivo e non può essere disattivato. Per impostazione predefinita, il monitoraggio delle connessioni è di tipo 5-tuple, ma può essere configurato in modo da essere inferiore a 5-tuple. Quando è una 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 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.

      • 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. Non è possibile utilizzare il monitoraggio delle connessioni.

      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:

      • 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. Per maggiori dettagli, consulta Timeout 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. L'affinità sessione viene specificata per l'intero servizio di backend esterno regionale, non per singolo backend.

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

  • 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, IP destinazione (CLIENT_IP). Hash di coppia di tuple di indirizzo IP di origine e indirizzo IP di 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

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'attivazione del monitoraggio delle connessioni dipende solo dal protocollo del traffico bilanciato in base al 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 è attivo. 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 tuple di 5 elementi, 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 il monitoraggio delle connessioni con tuple di 2 e 3 elementi, rispettivamente, per tutti i protocolli (tranne ICMP e ICMPv6, che non sono monitorabili in base alle connessioni). Per altre impostazioni di affinità sessione, la modalità PER_SESSION si comporta in modo identico alla modalità PER_CONNECTION.

Per scoprire come funzionano queste modalità di monitoraggio con impostazioni di affinità sessione diverse 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)

TCP e UDP non frammentato: hash di 5 tuple

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

(CLIENT_IP)

 Tutti i protocolli: hash di tupla 2
  • TCP e UDP non frammentato: monitoraggio delle connessioni con 5 tuple
  • UDP, ESP e GRE frammentati: monitoraggio delle connessioni con tre tuple
  • Tutti gli altri protocolli: monitoraggio delle connessioni disattivato
  • TCP, UDP, ESP, GRE: monitoraggio delle connessioni con due tuple
  • Tutti gli altri protocolli: monitoraggio delle connessioni disattivato
IP client, IP di destinazione, Protocollo

(CLIENT_IP_PROTO)

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

(CLIENT_IP_PORT_PROTO)

TCP e UDP non frammentato: hash di 5 tuple

UDP frammentato e tutti gli altri protocolli: hash di tuple di 3 elementi
  • TCP e UDP non frammentato: monitoraggio delle connessioni con 5 tuple
  • UDP, ESP e GRE frammentati: monitoraggio delle connessioni con tre tuple
  • Tutti gli altri protocolli: monitoraggio delle connessioni disattivato
  • TCP e UDP non frammentato: monitoraggio delle connessioni con 5 tuple
  • UDP, ESP e GRE frammentati: monitoraggio delle connessioni con tre tuple
  • Tutti gli altri protocolli: monitoraggio delle connessioni 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 permane su un endpoint o una VM di backend selezionata 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 gruppo di negazioni).

Il comportamento descritto in questa sezione non si applica ai casi in cui rimuovi un'istanza di backend da un gruppo di istanze o un endpoint di backend dal relativo gruppo NEG oppure rimuovi il gruppo di istanze o il gruppo NEG dal servizio di backend. In questi casi, le connessioni stabilite rimangono attive solo come descritto nella sezione Svuotamento della connessione.

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)

Tutti gli altri protocolli: le connessioni non rimangono mai su backend non integri

TCP: le connessioni persistono sui backend non integri se l'affinità sessione è NONE o CLIENT_IP_PORT_PROTO

Tutti gli altri protocolli: le connessioni non rimangono mai su backend non integri
NEVER_PERSIST Tutti i protocolli: le connessioni non vengono mai conservate su backend non integri
ALWAYS_PERSIST

TCP: le connessioni persistono sui backend non integri (tutte le affinità sessione)

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

ICMP, ICMPv6: non applicabili perché non sono monitorabili in base alla connessione

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

 Configurazione non possibile

Comportamento della persistenza della connessione TCP su backend non integri

Ogni volta che una connessione TCP con monitoraggio delle tuple da 5 elementi persiste su un backend non integro:

  • Se il backend non funzionante continua a rispondere ai pacchetti, la connessione continua finché non viene reimpostata o chiusa (dal backend non funzionante o dal client).
  • Se il backend non funzionante invia un pacchetto di ripristino 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 funzionante. I pacchetti TCP SYN scelgono sempre un nuovo backend integro.

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

Timeout di inattività

Le voci nelle tabelle di monitoraggio delle connessioni scadono 60 secondi dopo che il bilanciatore del carico ha elaborato l'ultimo pacchetto corrispondente alla voce. Questo valore del timeout inattivo non può essere modificato.

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 ai pesi segnalati 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 di bilanciamento del carico per le località (localityLbPolicy) del servizio di backend su WEIGHTED_MAGLEV.
  • Devi configurare il servizio di backend con un controllo di integrità HTTP. Le risposte controllo di integrità HTTP devono contenere un campo dell'intestazione di risposta HTTP personalizzataX-Load-Balancing-Endpoint-Weight per specificare i pesi con valori da 0 a 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 pesi diversi a diversi servizi di backend. Per ulteriori informazioni, consulta Criteri di esito positivo per i controlli di stato HTTP, HTTPS e HTTP/2.

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

Peso Stato integro Priorità di selezione del backend
Peso maggiore di zero Sì 4
Peso maggiore di zero No 3
Il peso è uguale a zero Sì 2
Il peso è uguale a zero No 1

Solo i backend con la priorità più alta sono idonei per la selezione. Se tutti i backend idonei hanno un peso pari a zero, il bilanciatore del carico distribuisce le nuove connessioni tra tutti i backend idonei, trattandoli con lo stesso peso. 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 rimangono attive più a lungo di altre, la distribuzione del carico del backend potrebbe essere non uniforme. Se viene indicato un peso per istanza inferiore, un'istanza con un carico elevato può ridurre la sua quota di nuove connessioni, continuando al contempo a gestire le connessioni esistenti.

  • Se un backend è sovraccaricato e l'assegnazione di più connessioni potrebbe interrompere quelle esistenti, questi backend si assegnano un peso pari a zero. Se viene indicato un peso pari a zero, un'istanza di backend interrompe il servizio per le nuove connessioni, ma continua a fornire il servizio per quelle esistenti.

  • Se un backend sta esaurendo le connessioni esistenti prima della manutenzione, si assegna un valore di peso pari a zero. Se segnali un peso pari a zero, l'istanza di backend interrompe il servizio per le nuove connessioni, ma continua a fornire il servizio per quelle esistenti.

Per ulteriori 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 (sostituzione, ritiro, durante gli upgrade incrementali o riduzione).
  • Un backend viene rimosso da un servizio di backend.

Per impostazione predefinita, svuotamento della connessione è disattivato. Se questa opzione è disattivata, le connessioni stabilite vengono interrotte il più rapidamente possibile. Quando svuotamento della connessione è attivo, le connessioni stabilite possono persistere per un timeout configurabile, dopodiché l'istanza VM di backend viene terminata.

Per ulteriori dettagli su come viene attivato lo svuotamento della connessione e su come attivarlo, consulta Attivare lo svuotamento della connessione.

Frammentazione UDP

I bilanciatori del carico di rete passthrough esterni basati su servizi di backend 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 o L3_DEFAULT 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.

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 una sola 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. In questo modo, tutti i frammenti arrivano 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 le istanze VM o gli endpoint nei backend principali (gruppi di istanze o NEG) e, se necessario, passare all'utilizzo di backend di failover. Il failover fornisce un altro metodo per aumentare la disponibilità, offrendo al contempo un maggiore controllo su come gestire il tuo carico di lavoro quando i backend principali non sono operativi.

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

Per maggiori dettagli sul funzionamento del failover, consulta la Panoramica del failover per i bilanciatori del carico di rete passthrough esterni.

Connettività internet in uscita dai backend

Le istanze VM configurate come endpoint di backend di un bilanciatore del carico di rete passthrough esterno possono avviare connessioni a internet utilizzando l'indirizzo IP della regola di forwarding del bilanciatore del carico come indirizzo IP di origine della connessione in uscita.

In genere, un'istanza VM utilizza sempre il proprio indirizzo IP esterno o Cloud NAT per avviare le connessioni. L'indirizzo IP della regola di forwarding viene utilizzato per avviare le connessioni dagli endpoint di backend solo in scenari speciali, ad esempio quando è necessario che le istanze VM iniziano e ricevano connessioni allo stesso indirizzo IP esterno e hai anche bisogno della ridondanza di backend fornita dal bilanciatore del carico di rete passthrough esterno per le connessioni in entrata.

I pacchetti in uscita inviati dalle VM di backend direttamente a internet non hanno limitazioni per i protocolli e le porte di traffico. Anche se un pacchetto in uscita utilizza l'indirizzo IP della regola di regola di forwarding come origine, il protocollo e la porta di origine del pacchetto non devono corrispondere alla specifica della regola di forwarding e del protocollo della regola di inoltro. Tuttavia, i pacchetti di risposta in entrata devono corrispondere all'indirizzo IP, al protocollo e alla porta di destinazione della regola di forwarding. Per ulteriori informazioni, consulta Percorsi per i bilanciatori del carico di rete passthrough esterni e per il forwarding del protocollo esterno.

Inoltre, tutte le risposte alle connessioni in uscita della VM sono soggette al bilanciamento del carico, come tutti gli altri pacchetti in entrata destinati al bilanciatore del carico. Ciò significa che le risposte potrebbero non arrivare sulla stessa VM di backend che ha avviato la connessione a internet. Se le connessioni in uscita e quelle in entrata bilanciate in base al carico condividono protocolli e porte comuni, puoi provare uno dei seguenti suggerimenti:

  • Sincronizza lo stato delle connessioni in uscita tra le VM di backend, in modo che le connessioni possano essere servite anche se le risposte arrivano a una VM di backend diversa da quella che ha avviato la connessione.

  • Utilizza una configurazione di failover con una singola VM principale e una singola VM di backup. Poi, la VM di backend attiva che avvia le connessioni in uscita riceve sempre i pacchetti di risposta.

Questo percorso per la connettività a internet dai backend di un bilanciatore del carico di rete passthrough esterno è il comportamento previsto per impostazione predefinita in base alle regole del firewall implicite di Google Cloud. Tuttavia, se hai dubbi sulla sicurezza di lasciare aperto questo percorso, puoi utilizzare regole firewall in uscita mirate per bloccare il traffico in uscita non richiesto verso internet.

Limitazioni

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

    • Crea o modifica un bilanciatore del carico di rete passthrough esterno la cui regola di forwarding utilizza il protocolloL3_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 in base all'IP di origine per una regola di forwarding.

    Utilizza l'interfaccia a Google Cloud CLI o l'API REST.

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

Prezzi

Per informazioni sui prezzi, consulta la sezione Prezzi.

Passaggi successivi