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

Questa pagina spiega i concetti relativi alla distribuzione del traffico da parte dei bilanciatori del carico di rete passthrough esterni.

Selezione del backend e monitoraggio delle connessioni

La selezione del backend e il monitoraggio delle connessioni funzionano insieme per bilanciare più connessioni tra backend diversi e per instradare tutti i pacchetti per ogni connessione allo stesso backend. Questo risultato si ottiene con una strategia in due parti. Per prima cosa, viene selezionato un backend utilizzando l'hashing coerente. Questa selezione viene registrata in una tabella di monitoraggio delle connessioni.

I seguenti passaggi descrivono la selezione del backend e il monitoraggio della connessione.

1. Controllare la presenza di una voce nella tabella di monitoraggio delle connessioni

Il bilanciatore del carico determina se un pacchetto bilanciato appartiene a una nuova connessione o a una connessione esistente utilizzando la seguente procedura:

  • Pacchetto TCP con il flag SYN:

    • Se la modalità di monitoraggio della connessione del bilanciatore del carico è PER_CONNECTION, vai al passaggio Identifica i backend idonei. Nella modalità di monitoraggio PER_CONNECTION, un pacchetto TCP con il flag SYN rappresenta sempre una nuova connessione, indipendentemente dall'affinità sessione configurata.

    • Se la modalità di monitoraggio della connessione del bilanciatore del carico è PER_SESSION e l'affinità sessione è NONE o CLIENT_IP_PORT_PROTO, vai al passaggio Identifica i backend idonei. In modalità di monitoraggio PER_SESSION, un pacchetto TCP con il flag SYN rappresenta una nuova connessione solo quando si utilizza una delle opzioni di affinità di sessione a 5 tuple (NONE o CLIENT_IP_PORT_PROTO).

  • Tutti gli altri pacchetti: il bilanciatore del carico controlla se il pacchetto corrisponde a una voce esistente nella tabella di monitoraggio delle connessioni. La granularità dell'hash del pacchetto utilizzato per verificare la presenza di una voce esistente nella tabella di monitoraggio della connessione dipende dalla modalità di monitoraggio della connessione e dall&#3affinità sessionene che hai configurato. Per ulteriori informazioni, consulta la tabella nella sezione Modalità di monitoraggio delle connessioni.

    • Se il pacchetto corrisponde a una voce della tabella di monitoraggio della connessione, il bilanciatore del carico invia il pacchetto al backend selezionato in precedenza.

    • Se il pacchetto non corrisponde a una voce della tabella di monitoraggio delle connessioni, continua con il passaggio Identifica i backend idonei.

    Per informazioni su quanto tempo persiste una voce della tabella di monitoraggio delle connessioni e in quali condizioni, consulta il passaggio Gestisci le voci della tabella di monitoraggio delle connessioni.

2. Passaggi per la selezione del backend

Per una nuova connessione, il bilanciatore del carico utilizza l'hashing coerente per selezionare un backend tra quelli idonei.

I passaggi seguenti descrivono la procedura per selezionare un backend idoneo per una nuova connessione e quindi registrare la connessione in una tabella di monitoraggio delle connessioni.

2.1 Identificare i backend idonei

I backend idonei sono i backend candidati a ricevere nuove connessioni. La seguente tabella definisce l'insieme di backend idonei a seconda che tu abbia configurato un'policy di failover e che sia attivato il bilanciamento del carico ponderato.

Policy di failover Bilanciamento del carico ponderato Backend idonei

Se non è configurata alcuna policy di failover e il bilanciamento del carico ponderato è disattivato, tutti i backend configurati sono backend principali. L'insieme di backend idonei è definito come segue:

  • Quando almeno un backend è integro, l'insieme dei backend idonei è costituito da tutti i backend integri.
  • Quando tutti i backend non sono integri, l'insieme dei backend idonei è costituito da tutti i backend.

Quando non è configurata alcuna policy di failover e il bilanciamento del carico ponderato è attivato, i backend idonei sono quelli che provengono dal primo dei seguenti insiemi non vuoti:

  • Tutti i backend integri con peso diverso da zero
  • Tutti i backend non integri con peso diverso da zero
  • Tutti i backend integri con peso pari a zero
  • Tutti i backend non integri con peso zero

Quando viene configurato un criterio di failover e il bilanciamento del carico ponderato è disattivato, il bilanciatore del carico utilizza le informazioni sul controllo di integrità e la configurazione dei criteri di failover per definire l'insieme di backend idonei:

  • Quando almeno un backend (primario o di failover) è integro, i backend idonei sono quelli che provengono dal primo dei seguenti set non vuoti:
    1. Se non sono presenti backend primari integri, i backend idonei sono tutti i backend di failover integri.
    2. Se non ci sono backend di failover integri, i backend idonei sono tutti i backend primari integri.
    3. Se il rapporto di failover è impostato su 0.0 (il valore predefinito), i backend idonei sono tutti i backend primari integri.
    4. Se il rapporto tra il numero di backend primari integri e il numero totale di backend primari è maggiore o uguale al rapporto di failover configurato, i backend idonei sono costituiti da tutti i backend primari integri.
    5. I backend idonei sono costituiti da tutti i backend di failover integri.
  • Quando non sono presenti backend integri (primari e di failover), l'insieme di backend idonei dipende esclusivamente dalla configurazione della policy di failover:
    • Se la policy di failover è configurata per eliminare le nuove connessioni quando tutti i backend primari e di failover non sono integri, l'insieme di backend idonei è vuoto. Di conseguenza, il bilanciatore del carico elimina i pacchetti per le nuove connessioni.
    • Se la norma di failover non è configurata per eliminare le nuove connessioni quando tutti i backend primari e di failover non sono integri, i backend idonei sono tutti i backend primari non integri.

Quando viene configurata una policy di failover e il bilanciamento del carico ponderato è abilitato, il bilanciatore del carico utilizza le informazioni sul peso, le informazioni sul controllo di integrità e la configurazione della policy di failover per definire l'insieme di backend idonei:

  • Quando almeno un backend con peso diverso da zero (primario o di failover) è integro, i backend idonei sono quelli che provengono dal primo dei seguenti set non vuoto:
    1. Se l'insieme dei backend primari integri con peso diverso da zero è vuoto, i backend idonei sono tutti i backend di failover integri con peso diverso da zero.
    2. Se l'insieme dei backend di failover integri con peso diverso da zero è vuoto, i backend idonei sono tutti i backend primari integri con peso diverso da zero.
    3. Se il rapporto di failover è impostato su 0.0 (il valore predefinito), i backend idonei sono tutti i backend primari integri con peso diverso da zero.
    4. Se il rapporto tra il numero di backend primari integri con peso diverso da zero e il numero totale di backend primari è maggiore o uguale al rapporto di failover configurato, i backend idonei sono costituiti da tutti i backend primari integri con peso diverso da zero.
    5. I backend idonei sono costituiti da tutti i backend di failover integri con peso diverso da zero.
  • Quando non sono presenti backend integri con peso diverso da zero (primari e di failover), l'insieme dei backend idonei dipende dalla configurazione della policy di failover:
    • Se la policy di failover è configurata per eliminare le nuove connessioni quando non sono presenti backend primari e di failover integri e con peso diverso da zero, l'insieme dei backend idonei è vuoto. Di conseguenza, il bilanciatore del carico elimina i pacchetti per le nuove connessioni.
    • Se il criterio di failover non è configurato per eliminare le nuove connessioni quando non sono presenti backend primari e di failover integri e con peso diverso da zero, i backend idonei sono quelli che provengono dal primo dei seguenti insiemi non vuoti:
      1. Tutti i backend principali non integri con peso diverso da zero
      2. Tutti i backend di failover non integri con peso diverso da zero
      3. Tutti i backend principali integri con peso zero
      4. Tutti i backend di failover integri con peso zero
      5. Tutti i backend principali non integri con peso zero
      6. Tutti i backend di failover non integri con peso zero

2.2 Seleziona un backend idoneo

Il bilanciatore del carico gestisce gli hash dei backend idonei, con ogni hash del backend mappato a un cerchio unitario. Il bilanciamento del carico ponderato modifica la mappatura dei backend idonei al cerchio in modo che i backend con pesi maggiori abbiano più probabilità di essere selezionati, in proporzione ai loro pesi.

Quando elabora un pacchetto per una connessione che non si trova nella tabella di monitoraggio delle connessioni, il bilanciatore del carico calcola un hash delle caratteristiche del pacchetto e lo mappa allo stesso cerchio unitario, selezionando un backend idoneo sulla circonferenza del cerchio. L'insieme delle caratteristiche dei pacchetti utilizzate per calcolare l'hash del pacchetto è definito dall'impostazione di affinità di sessione. Ad esempio, quando l'affinità sessione selezionata genera un hash di selezione del backend a 2 tuple o 3 tuple, tutte le connessioni TCP da un indirizzo IP di origine vengono mappate allo stesso backend idoneo.

  • Se l'affinità sessione non è configurata in modo esplicito, l'affinità di sessione NONE è quella predefinita.
  • L'hashing coerente garantisce che il bilanciatore del carico assegni nuove connessioni ai backend idonei in modo da ridurre al minimo le interruzioni della mappatura anche se il numero di backend idonei o i relativi pesi cambiano.

    • Il bilanciatore del carico seleziona sempre lo stesso backend idoneo per una connessione e, più in generale, seleziona sempre lo stesso backend idoneo per tutti i pacchetti con caratteristiche identiche a quelle definite dall'impostazione di affinità di sessione, nelle seguenti situazioni:

      • Se il bilanciamento del carico ponderato non è configurato, quando l'insieme di backend idonei non cambia.

      • Se è configurato il bilanciamento del carico ponderato, quando l'insieme di backend idonei non cambia, e il peso di ogni backend idoneo rimane costante.

    • Se un backend idoneo viene aggiunto, rimosso o il suo peso viene modificato, l'hashing coerente mira a ridurre al minimo l'interruzione dei mapping agli altri backend idonei, ovvero la maggior parte delle connessioni che vengono mappate ad altri backend idonei continuano a essere mappate allo stesso backend idoneo.

  • Inoltre, l'hashing coerente garantisce che il bilanciatore del carico distribuisca le nuove connessioni tra i backend idonei nel modo più equo possibile. Per tutti gli hash dei pacchetti possibili, come definito dall'impostazione di affinità sessione configurata (e più nello specifico, per tutte le connessioni possibili quando l'affinità sessione genera un hash a 5 tuple per la selezione del backend):

    • Se il bilanciamento del carico ponderato non è configurato, circa 1/N hash di pacchetti possibili vengono mappati a ogni backend idoneo, dove N è il conteggio dei backend idonei.

    • Se è configurato il bilanciamento del carico ponderato, il rapporto tra gli hash dei pacchetti possibili che vengono mappati a ogni backend idoneo è approssimativamente: il peso di un backend idoneo diviso per la somma di tutti i pesi dei backend idonei.

  • I due esempi seguenti mostrano in che modo il bilanciamento del carico ponderato influisce sulle probabilità di selezione di ogni backend idoneo:

    • Se il servizio di backend ha due backend idonei, il primo con peso 1 e il secondo con peso 4, il primo backend idoneo ha una probabilità di selezione del 20% (1÷(1+4)) e il secondo backend idoneo ha una probabilità di selezione dell'80% (4÷(1+4)).

    • Se il servizio di backend ha tre backend idonei (backend idoneo a con peso 0, backend idoneo b con peso 2 e backend idoneo c con peso 6), il backend a ha una probabilità di selezione dello 0% (0÷(0+2+6)), il backend b ha una probabilità di selezione del 25% (2÷(0+2+6)) e il backend c ha una probabilità di selezione del 75% (6÷(0+2+6)).

2.3 Crea una voce della tabella di monitoraggio delle connessioni

Dopo aver selezionato un backend, il bilanciatore del carico crea una voce nella tabella di monitoraggio delle connessioni se l'affinità sessione configurata supporta il monitoraggio delle connessioni per il protocollo del pacchetto.

  • Se l'affinità sessione configurata non supporta il monitoraggio della connessione per il protocollo del pacchetto, ignora questo passaggio.

  • Se l'affinità sessione configurata supporta il monitoraggio della connessione per il protocollo del pacchetto, la voce della tabella di monitoraggio della connessione creata mappa le caratteristiche del pacchetto al backend selezionato. I campi dell'intestazione del pacchetto utilizzati per questo mapping dipendono dalla modalità di monitoraggio della connessione e dall'affinità sessione che hai configurato.

Per informazioni sui protocolli di cui è possibile monitorare la connessione in base alle tue scelte di configurazione e sulle caratteristiche dei pacchetti utilizzate per l'hash nella tabella di monitoraggio della connessione, consulta la tabella nella sezione Modalità di monitoraggio della connessione.

3. Gestisci le voci della tabella di monitoraggio delle connessioni

Il bilanciatore del carico gestisce le voci della tabella di monitoraggio delle connessioni in base ai seguenti eventi e regole:

  • Le voci inattive vengono rimosse: una voce della tabella di monitoraggio delle connessioni viene rimossa dopo che la connessione è rimasta inattiva per 60 secondi. Per saperne di più, consulta Timeout di inattività.
  • Connessioni TCP chiuse: le voci della tabella di monitoraggio delle connessioni per le connessioni TCP non vengono rimosse quando una connessione TCP viene chiusa con un pacchetto FIN o RST. Potrebbe essere rimosso in un secondo momento come voce inattiva. Ogni nuova connessione TCP trasporta sempre il flag SYN ed è soggetta all'elaborazione descritta nel passaggio Controlla la presenza di una voce nella tabella di monitoraggio delle connessioni.

  • Svuotamento connessioni al failover: quando è configurato almeno un backend di failover e l'svuotamento della connessione al failover è disattivata, il bilanciatore del carico rimuove tutte le voci nella tabella di monitoraggio delle connessioni quando l'insieme di backend idonei passa dai backend primari a quelli di failover. Per saperne di più, consulta Svuotamento connessioni al failover.

  • Persistenza della connessione su backend in stato non integro: le voci nella tabella di monitoraggio della connessione possono essere rimosse se un backend diventa non integro. Questo comportamento dipende dai fattori descritti in Persistenza della connessione su backend in stato non integro.

    • Quando una voce della tabella di monitoraggio della connessione viene rimossa perché un backend selezionato in precedenza passa da integro a non integro, i pacchetti successivi per la connessione vengono trattati come se appartenessero a una nuova connessione. Dopo aver selezionato un nuovo backend idoneo per i pacchetti successivi, il bilanciatore del carico crea una voce sostitutiva nella tabella di monitoraggio delle connessioni.

    • Una voce della tabella di monitoraggio delle connessioni sostitutiva si comporta esattamente come qualsiasi altra voce della tabella di monitoraggio delle connessioni ed è soggetta agli eventi e alle regole di questo passaggio.

    • Se il backend selezionato in precedenza torna da non integro a integro, la modifica del controllo di integrità da sola non comporta la rimozione della voce della tabella di monitoraggio della connessione di sostituzione. Si verifica un'eccezione quando è configurato almeno un backend di failover e l'impostazione Svuotamento connessioni in caso di failover è disattivata; se la modifica dello stato del controllo di integrità di un backend selezionato in precedenza coincide con il passaggio dell'insieme di backend idonei tra backend primari e di failover, le voci della tabella di monitoraggio delle connessioni vengono rimosse.

  • Svuotamento della connessione per i backend rimossi, arrestati o eliminati: se lo svuotamento della connessione per i backend rimossi, arrestati o eliminati è abilitato, le voci della tabella di monitoraggio della connessione vengono rimosse dopo un timeout di svuotamento della connessione configurabile. Il conteggio del timeout inizia quando viene ricevuto il comando per rimuovere, arrestare o eliminare un backend. Se svuotamento della connessione per i backend rimossi, arrestati o eliminati è disattivato, le voci della tabella di monitoraggio delle connessioni vengono rimosse quando viene ricevuto il comando per rimuovere, arrestare o eliminare un backend. Per ulteriori informazioni, vedi Attivare l'interruzione delle connessioni.

Affinità sessione

L'impostazione dell'affinità sessione di un bilanciatore del carico di rete passthrough esterno definisce l'hash del pacchetto per la selezione del backend e, in base alla modalità di monitoraggio della connessione, l'hash del pacchetto per il monitoraggio della connessione.

Configuri l'affinità sessione sul servizio di backend, non su ogni gruppo di istanze o NEG di backend. L'affinità sessione determina quali intestazioni IP e di livello 4 vengono utilizzate per calcolare un hash delle caratteristiche del pacchetto. L'hash delle caratteristiche del pacchetto viene utilizzato nei passaggi di selezione del backend.

I bilanciatori del carico di rete passthrough esterni supportano le seguenti impostazioni di affinità sessione.

Metodo hash per la selezione del backend Impostazione dell'affinità sessione

Hash a 5 tuple (composto da indirizzo IP di origine, porta di origine, protocollo, indirizzo IP di destinazione e porta di destinazione) per pacchetti non frammentati che includono informazioni sulla porta (pacchetti TCP e pacchetti UDP non frammentati)

OR

Hash a tre tuple (formato da indirizzo IP di origine, indirizzo IP di destinazione e protocollo) per pacchetti UDP frammentati e pacchetti di tutti gli altri protocolli

NONE1
OPPURE
CLIENT_IP_PORT_PROTO
Hash a tre tuple
(formato da indirizzo IP di origine, indirizzo IP di destinazione e protocollo)
CLIENT_IP_PROTO
Hash a due tuple
(formato da indirizzo IP di origine e indirizzo IP di destinazione)
CLIENT_IP

1 NONE affinità sessione non indica che non esiste un'affinità sessione. Significa invece che l'affinità sessione viene eseguita con un hash a 5 tuple o a 3 tuple delle caratteristiche del pacchetto, ovvero lo stesso comportamento di quando è impostato CLIENT_IP_PORT_PROTO.

Policy di tracciamento delle connessioni

Questa sezione descrive le impostazioni nella policy di monitoraggio delle connessioni del bilanciatore del carico:

Modalità di tracciamento delle connessioni

Questa sezione descrive quando e come il bilanciatore del carico crea voci nella tabella di monitoraggio delle connessioni. I bilanciatori del carico di rete passthrough esterni supportano il monitoraggio delle connessioni in base al protocollo e all&#39affinità sessionee:

  • Le connessioni TCP sono sempre tracciabili per tutte le opzioni di affinità sessione.

  • Le connessioni UDP, ESP e GRE sono tracciabili per tutte le opzioni di affinità di sessione ad eccezione di NONE.

  • Tutti gli altri protocolli, come ICMP e ICMPv6, non sono tracciabili per la connessione.

Quando il monitoraggio delle connessioni è possibile, la modalità di monitoraggio delle connessioni, il protocollo e l&#39affinità sessionee determinano l'insieme delle caratteristiche dei pacchetti utilizzate per creare l'hash dei pacchetti in ogni voce della tabella di monitoraggio delle connessioni.

La modalità di monitoraggio della connessione può essere una delle seguenti:

  • PER_CONNECTION. Questa è la modalità di monitoraggio delle connessioni predefinita e più granulare. Ogni connessione è definita come hash a 5 tuple o hash a 3 tuple delle caratteristiche del pacchetto, a seconda che le informazioni sulla porta siano presenti nel pacchetto. I pacchetti non frammentati che includono informazioni sulla porta (come i pacchetti TCP e i pacchetti UDP non frammentati) vengono monitorati con hash a 5 tuple. Tutti gli altri pacchetti vengono monitorati con hash a 3 tuple.

  • PER_SESSION. Questa modalità di monitoraggio delle connessioni meno granulare utilizza un hash che corrisponde all'hash di affinità sessione. A seconda dell'affinità di sessione scelta, la modalità di monitoraggio PER_SESSION può considerare più connessioni distinte come una singola connessione ai fini del monitoraggio delle connessioni. In questo modo si riduce la frequenza con cui una connessione viene considerata nuova e soggetta ai passaggi di selezione del backend.

La tabella seguente riepiloga:

  • Gli hash dei pacchetti utilizzati per la selezione del backend e
  • Gli hash dei pacchetti utilizzati per il monitoraggio delle connessioni, in base alla modalità di monitoraggio delle connessioni, al protocollo e all'affinità sessione.
Affinità sessione Hash del pacchetto per la selezione del backend Hash del pacchetto per il monitoraggio della connessione
Quando utilizzi la modalità di monitoraggio PER_CONNECTION (impostazione predefinita) Quando utilizzi la modalità di monitoraggio PER_SESSION
NONE (valore predefinito)
  • TCP e UDP non frammentato:hash a 5 tuple
  • UDP frammentato e tutti gli altri protocolli: hash a 3 tuple
  • TCP:monitoraggio della connessione attivo, hash a 5 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
  • TCP:monitoraggio della connessione attivo, hash a 5 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
CLIENT_IP_PORT_PROTO
  • TCP e UDP non frammentato:hash a 5 tuple
  • UDP frammentato e tutti gli altri protocolli: hash a 3 tuple
  • TCP e UDP non frammentato:monitoraggio delle connessioni attivo, hash a 5 tuple
  • UDP, ESP e GRE frammentati:monitoraggio della connessione attivo, hash a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
  • TCP e UDP non frammentato:monitoraggio delle connessioni attivo, hash a 5 tuple
  • UDP, ESP e GRE frammentati:monitoraggio della connessione attivo, hash a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
CLIENT_IP_PROTO
  • Tutti i protocolli: hash a 3 tuple
  • TCP e UDP non frammentato:monitoraggio delle connessioni attivo, hash a 5 tuple
  • UDP, ESP e GRE frammentati:monitoraggio della connessione attivo, hash a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
  • TCP, UDP, ESP, GRE: monitoraggio della connessione attivo, hash a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
CLIENT_IP
  • Tutti i protocolli:hash a 2 tuple
  • TCP e UDP non frammentato:monitoraggio delle connessioni attivo, hash a 5 tuple
  • UDP, ESP e GRE frammentati:monitoraggio della connessione attivo, hash a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
  • TCP, UDP, ESP, GRE: monitoraggio della connessione attivo, hash a 2 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato

Per scoprire come modificare la modalità di monitoraggio della connessione, consulta Configurare un criterio di monitoraggio della connessione.

Persistenza della connessione su backend in stato non integro

Persistenza della connessione su backend in stato non integro controlla se le connessioni esistenti persistono su una VM o un endpoint di backend selezionati in precedenza dopo che il backend diventa non integro, a condizione che rimanga in un gruppo di istanze con bilanciamento del carico o in un gruppo NEG.

Sono disponibili le seguenti opzioni di persistenza della connessione:

  • DEFAULT_FOR_PROTOCOL (valore predefinito)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

La tabella seguente riassume se le connessioni persistono in base ai backend in stato non integro, a seconda dell'opzione di persistenza della connessione, dell'affinità sessione, della modalità di monitoraggio della connessione e del protocollo.

Opzione Persistenza della connessione su backend in stato non integro Comportamento della persistenza della connessione su backend in stato non integro
Quando utilizzi la modalità di monitoraggio PER_CONNECTION (impostazione predefinita) Quando utilizzi la modalità di monitoraggio PER_SESSION
DEFAULT_FOR_PROTOCOL
  • TCP:le connessioni persistono sui backend in stato non integro (tutte le affinità sessione)
  • Tutti gli altri protocolli: le connessioni non vengono mai mantenute su backend in stato non integro
  • TCP:le connessioni persistono sui backend in stato non integro se l'affinità sessione è NONE o CLIENT_IP_PORT_PROTO.
  • Tutti gli altri protocolli: le connessioni non vengono mai mantenute su backend in stato non integro
NEVER_PERSIST Tutti i protocolli: le connessioni non vengono mai mantenute sui backend in stato non integro
ALWAYS_PERSIST

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

  • TCP:le connessioni persistono sui backend in stato non integro (tutte le affinità di sessione)
  • ESP, GRE, UDP: le connessioni persistono sui backend non integri se l'affinità sessione non è NONE
  • Tutti gli altri protocolli:non applicabile perché non sono tracciabili per la connessione
Configurazione non possibile

Quando la persistenza della connessione su backend in stato non integro si applica al traffico, ogni connessione persiste finché esiste una voce corrispondente nella tabella di monitoraggio delle connessioni. Per saperne di più, consulta il passaggio Gestisci le voci della tabella di monitoraggio delle connessioni.

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

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

Il bilanciatore del carico utilizza il monitoraggio delle connessioni hash a 5 tuple per le connessioni TCP in queste situazioni:

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

Quando il bilanciatore del carico utilizza il monitoraggio delle connessioni hash a 5 tuple per le connessioni TCP, tieni presente i seguenti comportamenti:

  • Se il backend non integro continua a rispondere ai pacchetti, la connessione continua finché non viene reimpostata o chiusa (dal backend non integro o dal client).
  • Se il backend non integro invia un pacchetto TCP reset (RST) o non risponde ai pacchetti, il client potrebbe riprovare con una nuova connessione, consentendo al bilanciatore del carico di selezionare un altro backend idoneo. I pacchetti TCP SYN vengono trattati come nuove connessioni nel passaggio Identifica i backend idonei.

Timeout di inattività

Le voci nelle tabelle di monitoraggio delle connessioni scadono 60 secondi dopo che il bilanciamento del carico elabora l'ultimo pacchetto corrispondente alla voce. Questo valore di timeout per inattività non può essere modificato.

Svuotamento della connessione per i backend rimossi, arrestati o eliminati

Lo svuotamento delle connessioni fornisce un periodo di tempo minimo configurabile per la persistenza delle connessioni esistenti nella tabella di monitoraggio delle connessioni del bilanciatore del carico quando si verifica uno dei seguenti eventi:

  • Un'istanza di macchina virtuale (VM) viene rimossa da un gruppo di istanza di backend (incluso l'abbandono di un'istanza in un gruppo di istanze gestite di backend)
  • Una VM viene arrestata o eliminata (incluse le azioni automatiche come gli aggiornamenti in sequenza o la riduzione delle dimensioni di un gruppo di istanze gestite di backend)
  • Un endpoint viene rimosso da un gruppo di endpoint di rete (NEG) di backend

Per impostazione predefinita, svuotamento della connessione quando i backend vengono rimossi, arrestati o eliminati è disattivato. Per saperne di più, vedi Attivazione dello svuotamento delle connessioni.

Bilanciamento del carico ponderato

Il bilanciamento del carico ponderato influenza i backend idonei nei passaggi di selezione del backend. Ogni VM o endpoint di backend comunica il proprio peso al bilanciatore del carico utilizzando un controllo di integrità HTTP e un'intestazione di risposta personalizzata. Per utilizzare il bilanciamento del carico ponderato, devi configurare quanto segue nel servizio di backend del bilanciatore del carico:

  • La policy per le località (localityLbPolicy) deve essere impostata su WEIGHTED_MAGLEV.
  • Il controllo di integrità deve essere un controllo di integrità HTTP che invia un'intestazione di risposta speciale:

    • Il nome del campo dell'intestazione della risposta deve essere X-Load-Balancing-Endpoint-Weight.
    • I valori dei campi dell'intestazione della risposta possono variare da 0 a 1000 inclusi.

Per saperne di più, consulta Configurare il bilanciamento del carico ponderato.

Considerazioni sul bilanciamento del carico ponderato

Il bilanciamento del carico ponderato è utile nei seguenti scenari, che consentono a un backend di continuare a elaborare le connessioni esistenti:

  • Il bilanciamento del carico ponderato consente a un backend che elabora connessioni a esecuzione prolungata o connessioni che coinvolgono grandi quantità di dati di comunicare al bilanciatore del carico di ridurre il numero di nuove connessioni che riceve.

  • Il bilanciamento del carico ponderato consente a un backend sovraccarico o in fase di manutenzione di rimuoversi dai backend idonei per le nuove connessioni. A questo scopo, il backend sovraccarico invia l'intestazione della risposta X-Load-Balancing-Endpoint-Weight: 0 (e può continuare a superare o non superare il controllo di integrità del bilanciatore del carico). Questo funziona perché tutti i backend con peso diverso da zero (indipendentemente dallo stato del controllo di integrità) sono backend idonei più preferibili nel passaggio Identifica i backend idonei.

Quando utilizzi il bilanciamento del carico, tieni presente quanto segue:

  • Se i backend idonei cambiano spesso i propri pesi, il bilanciamento del carico ponderato può influire negativamente sull'affinità sessione. Per ulteriori informazioni, consulta il passaggio Seleziona un backend idoneo.

  • Se utilizzi lo stesso gruppo di istanze o NEG come backend di due o più servizi di backend del bilanciatore del carico, puoi segnalare un peso univoco per ogni servizio di backend utilizzando la seguente strategia:

    • Utilizza un controllo di integrità HTTP univoco per ogni servizio di backend. Ogni controllo di integrità può utilizzare una porta di destinazione o un parametro request-path univoco.

    • Configura le istanze o gli endpoint di backend in modo che rispondano con informazioni sul peso appropriate per ogni controllo di integrità.

Failover

Il failover ti consente di influenzare l'insieme di backend idonei per le nuove connessioni classificando ogni gruppo di istanza di backend o NEG come primario o di failover.

Per impostazione predefinita, quando aggiungi un gruppo di istanze o un NEG a un servizio di backend, le VM o gli endpoint membri sono backend principali e il gruppo di istanze o il NEG è un gruppo di backend principale. Con il failover, puoi aggiungere un gruppo di backend di failover (gruppo di istanze o NEG) le cui VM o i cui endpoint membri sono backend di failover:

  • Il failover richiede che un servizio di backend abbia almeno un gruppo di backend primario e almeno un gruppo di backend di failover.
  • Puoi aggiungere fino a 50 gruppi di backend principali e 50 gruppi di backend di failover a un servizio di backend.

Con il failover, i seguenti fattori determinano l'insieme di backend idonei:

  • Lo stato di integrità di ogni backend
  • Il rapporto di failover che hai configurato
  • L'impostazione Interrompi il traffico se i backend non sono integri
  • Se utilizzi il failover da solo o in combinazione con il bilanciamento del carico ponderato

Policy di failover

Quando un servizio di backend ha almeno un gruppo di backend primario e almeno un gruppo di backend di failover, puoi modificare le seguenti impostazioni nella relativa norma di failover:

  • Rapporto di failover: un numero compreso tra 0.0 e 1.0 inclusi.
  • Elimina il traffico se i backend non sono integri: un valore booleano che determina il comportamento di ultima risorsa del bilanciatore del carico. L'intervallo di failover e l'impostazione Interrompi il traffico se i backend non sono integri funzionano insieme ad altri fattori per controllare l'insieme dei backend idonei.
  • Svuotamento connessioni al failover: un valore booleano che controlla se le connessioni persistono sui backend selezionati in precedenza quando l'insieme di backend idonei passa dai backend primari a quelli di failover.

Rapporto di failover

Il rapporto di failover configurato determina quando l'insieme di backend idonei passa dai backend principali a quelli di failover. Il rapporto può essere un numero compreso tra 0.0 e 1.0, inclusi. Se non specifichi un rapporto di failover, Cloud de Confiance utilizza un valore predefinito di 0.0. È una best practice impostare il rapporto di failover su un numero adatto al tuo caso d'uso anziché fare affidamento a questo valore predefinito.

Svuotamento connessioni al failover

L'opzione Svuotamento connessioni al failover controlla se una connessione esistente persiste su una VM o un endpoint di backend selezionati in precedenza quando l'insieme di backend idonei passa dai backend primari a quelli di failover.

Lo svuotamento delle connessioni al failover è attivato per impostazione predefinita. La tabella seguente riepiloga se le connessioni persistono, a seconda dell'opzione e del protocollo di svuotamento svuotamento della connessione al failover:

Opzione Svuotamento della connessione al failover Comportamento quando l'insieme di backend idonei passa tra i backend primari e di failover
Abilitati (impostazione predefinita)
  • Protocolli tracciabili della connessione:le connessioni persistono, finché esiste una voce corrispondente nella tabella di monitoraggio delle connessioni, quando l'insieme di backend idonei passa dai backend principali a quelli di failover. Per saperne di più, consulta il passaggio Gestisci le voci della tabella di monitoraggio delle connessioni.
  • Protocolli non tracciabili della connessione: le connessioni non vengono mantenute quando l'insieme di backend idonei passa da backend principali a backend di failover.

Per informazioni sui protocolli di cui è possibile monitorare la connessione, consulta la tabella nella sezione Modalità di monitoraggio della connessione.

Disabilitato Tutti i protocolli:le connessioni non vengono mantenute quando l'insieme di backend idonei passa dai backend primari a quelli di failover

La disattivazione dello svuotamento della connessione in caso di failover e failback è utile per gli scenari seguenti:

  • Applicazione di patch alle VM di backend. Prima dell'applicazione delle patch, puoi configurare i backend primari integri con peso diverso da zero in modo che non superino i controlli di integrità oppure puoi impostare i loro pesi su zero. In questo modo, i backend idonei possono essere backend di failover integri con peso diverso da zero. Se disattivi lo svuotamento delle connessioni durante il failover e il failback, il bilanciatore del carico rimuove le voci della tabella di monitoraggio delle connessioni, applica i passaggi di selezione del backend ai pacchetti successivi e li invia a un backend idoneo diverso. Il backend diverso chiude quindi la connessione con un ripristino TCP, in modo che le VM client possano stabilire rapidamente una nuova connessione al bilanciatore del carico.

  • Singola VM di backend per la coerenza dei dati. Se devi assicurarti che l'insieme di backend idonei non contenga più di una VM o un endpoint membro, la disattivazione del svuotamento della connessione durante il failover e il failback riduce la possibilità di incoerenze dei dati.

Per scoprire come disattivare svuotamento della connessione in caso di failover e failback, consulta Disattivazione svuotamento della connessione in caso di failover e failback.

Best practice e indicazioni

Puoi ottimizzare il bilanciatore del carico di rete passthrough esterno seguendo queste linee guida operative. Le sezioni seguenti forniscono i requisiti tecnici per la gestione dei pacchetti UDP frammentati e le best practice per testare la distribuzione del carico da un singolo client.

Gestione della frammentazione UDP

I bilanciatori del carico di rete passthrough esterni basati sui servizi di backend possono elaborare pacchetti UDP frammentati e 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. Cloud de Confiance
  • Le reti VPC inoltrano i frammenti UDP man mano che arrivano (senza attendere l'arrivo di tutti i frammenti).Cloud de Confiance
  • Le reti nonCloud de Confiance e le apparecchiature di rete on-premise potrebbero inoltrare i frammenti UDP man mano che arrivano, ritardare i pacchetti UDP frammentati fino all'arrivo di tutti i frammenti o scartare i pacchetti UDP frammentati. Per maggiori dettagli, consulta la documentazione del provider di rete o delle apparecchiature di rete.

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

  • Configurazione della regola di forwarding:utilizza una sola regola di forwarding UDP o L3_DEFAULT per indirizzo IP bilanciato del 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 consente anche di ricevere i frammenti UDP che non hanno informazioni sulla porta. Per configurare tutte le porte, utilizza Google Cloud CLI per impostare --ports=ALL o l'API per impostare allPorts su True.

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

Test da un singolo client

Quando testi un bilanciatore del carico di rete passthrough esterno da un singolo client, tieni presente quanto segue:

  • Se la VM client non è un backend del bilanciatore del carico: le nuove connessioni vengono elaborate come descritto nei passaggi Selezione e monitoraggio della connessione del backend. Nel passaggio Seleziona un backend idoneo, il bilanciatore del carico crea un hash delle caratteristiche dei pacchetti in base all'affinità di sessione.

    Ricorda che tutte le opzioni di affinità sessione si basano almeno sull'indirizzo IP del client, quindi le connessioni dallo stesso client potrebbero essere distribuite allo stesso backend idoneo più spesso di quanto potresti aspettarti. Di conseguenza, non puoi modellare con precisione la distribuzione complessiva delle nuove connessioni connettendoti a un bilanciatore del carico di rete passthrough esterno da un singolo client.

  • Se la VM client è anche una VM di backend del bilanciatore del carico: le nuove connessioni non vengono elaborate dal bilanciatore del carico. I pacchetti in uscita con l'indirizzo IP di destinazione della regola di forwarding del bilanciatore del carico vengono instradati localmente all'interno del sistema operativo guest del client a causa della presenza di una route locale per la regola di forwarding.

Passaggi successivi