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

Questa pagina descrive i seguenti concetti per aiutarti a comprendere e personalizzare ulteriormente il modo in cui i bilanciatori del carico di rete passthrough interni distribuiscono il traffico: affinità sessione, monitoraggio delle connessioni, frammentazione UDP e failover.

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

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

  • Se hai configurato il failover, un bilanciatore del carico di rete passthrough interno distribuisce le nuove connessioni tra le VM nel pool attivo in base a un criterio di failover configurato. Quando tutte le VM di backend non sono in stato integro, puoi scegliere 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 di ultima istanza.
    • Il bilanciatore del carico è configurato per interrompere il traffico.

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

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

Monitoraggio della selezione e della connessione del backend

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

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

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

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

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

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

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

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

      Quando l'hash del monitoraggio delle connessioni è una tupla di 5 elementi, i pacchetti SYN TCP creano sempre una nuova voce nella tabella di monitoraggio delle connessioni.

      Il monitoraggio delle connessioni con 5 tuple predefinito viene utilizzato quando:

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

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

      Tieni inoltre presente quanto segue:

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

Opzioni di affinità sessione

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

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

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

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

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

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

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

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

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

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

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

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

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

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 interni. Un criterio di monitoraggio delle connessioni include le seguenti impostazione:

Modalità di monitoraggio delle connessioni

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

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

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

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

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

NONE

Hash di 5 tuple Monitoraggio delle connessioni con 5 tuple Monitoraggio delle connessioni con 5 tuple

IP client, nessuna destinazione

CLIENT_IP_NO_DESTINATION

Hash di tupla 1 Monitoraggio delle connessioni con 5 tuple Monitoraggio delle connessioni con una tupla

IP client

CLIENT_IP

(uguale a IP client, IP destinazione per i bilanciatori del carico di rete passthrough esterni)

Hash di tuple di 2 elementi Monitoraggio delle connessioni con 5 tuple Monitoraggio delle connessioni con due tuple

IP client, IP di destinazione, Protocollo

CLIENT_IP_PROTO

Hash di tuple di 3 elementi Monitoraggio delle connessioni con 5 tuple Monitoraggio delle connessioni con tre tuple

IP client, porta client, IP di destinazione, porta di destinazione, protocollo

CLIENT_IP_PORT_PROTO

Hash di 5 tuple Monitoraggio delle connessioni con 5 tuple Monitoraggio delle connessioni con 5 tuple

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

Persistenza della connessione su backend in stato non integro

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

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

Sono disponibili le seguenti opzioni di persistenza della connessione:

  • DEFAULT_FOR_PROTOCOL (valore predefinito)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

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

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

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

UDP: le connessioni non vengono mai mantenute su backend non integri

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

UDP: le connessioni non vengono mai mantenute su backend non integri

NEVER_PERSIST TCP, UDP: le connessioni non persistono mai su backend non integri
ALWAYS_PERSIST

TCP, UDP: le connessioni persistono su backend in stato non integro (tutte le affinità di sessione)

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

Configurazione non possibile

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

Timeout di inattività

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

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

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

Connessioni per i deployment con un solo client

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

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

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

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

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

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).

Per impostazione predefinita, lo 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 interni possono elaborare pacchetti UDP sia frammentati che non frammentati. Se la tua applicazione utilizza pacchetti UDP frammentati, tieni presente quanto segue:
  • I pacchetti UDP potrebbero essere frammentati prima di raggiungere una rete VPC 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 all'arrivo di tutti i frammenti o eliminare i pacchetti UDP frammentati. Per maggiori dettagli, consulta la documentazione del fornitore di servizi di rete o dell'apparecchiatura di rete.

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

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

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

Failover

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

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

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

Passaggi successivi