Distribuzione del traffico per i bilanciatori del carico di rete passthrough esterni

Questa pagina descrive i seguenti concetti per aiutarti a comprendere e personalizzare ulteriormente la modalità di distribuzione del traffico da parte dei bilanciatori del carico di rete passthrough esterni: affinità sessione, monitoraggio delle connessioni, bilanciamento del carico ponderato, svuotamento della connessione, frammentazione UDP e failover.

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 emergenza delle connessioni.
    • 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 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 lo 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 nella 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 ulteriori informazioni, consulta la sezione 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.

Policy di monitoraggio delle connessioni

Questa sezione descrive le impostazioni che controllano il comportamento del monitoraggio delle connessioni dei bilanciatori del carico di rete passthrough esterni. Un criterio di monitoraggio delle connessioni include le seguenti impostazione:

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 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 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 viene rimossa un'istanza di backend da un gruppo di istanze o un endpoint di backend dal relativo gruppo NEG oppure viene rimosso 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 rimangono attive 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 di 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 personalizzata X-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 Google Cloud.
  • Le reti VPC diGoogle Cloud inoltrano i frammenti UDP man mano che arrivano (senza attendere l'arrivo di tutti i frammenti).
  • Le reti nonGoogle Cloud e le apparecchiature di rete on-premise potrebbero forwardare i frammenti UDP man mano che arrivano, ritardare i pacchetti UDP frammentati fino a quando 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.

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.

Passaggi successivi