Panoramica del bilanciamento del carico di rete TCP/UDP esterno basato sul servizio di backend

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Il bilanciamento del carico di rete TCP/UDP esterno di Google Cloud (in seguito chiamato Bilanciamento del carico di rete) è un bilanciatore del carico pass-through a livello di area geografica. Un bilanciatore del carico di rete distribuisce il traffico esterno tra istanze di macchine virtuali (VM) nella stessa area geografica.

Puoi configurare un bilanciatore del carico di rete per il traffico TCP, UDP, ESP, GRE, ICMP e ICMPv6.

Un bilanciatore del carico di rete può ricevere traffico da:

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

Il bilanciamento del carico di rete ha le seguenti caratteristiche:

  • Il bilanciamento del carico di rete è un servizio gestito.
  • Il bilanciamento del carico di rete viene implementato utilizzando la rete virtuale Andromeda e Google Maglev.
  • I bilanciatori del carico di rete non sono proxy.
    • I pacchetti con bilanciamento del carico vengono ricevuti dalle VM di backend con gli indirizzi IP di origine e di destinazione del pacchetto e del protocollo e, se il protocollo è basato su porta, le porte di origine e di destinazione non vengono modificate.
    • Le connessioni con bilanciamento del carico vengono terminate dalle VM di backend.
    • Le risposte dalle VM di backend vengono inviate direttamente ai client, non tramite il bilanciatore del carico. Il termine di settore per questo termine è Direct server server (DSR).

I bilanciatori del carico di rete basati su servizi di backend hanno le seguenti caratteristiche:

  • Backend di gruppi di istanze gestite. I bilanciatori del carico di rete basati su servizi di backend supportano l'utilizzo di gruppi di istanze gestite (MIG) come backend. I gruppi di istanze gestite automatizzano determinati aspetti della gestione del backend e offrono una migliore scalabilità e affidabilità rispetto ai gruppi di istanze non gestite.
  • Supporto per la connettività IPv6. I bilanciatori del carico di rete basati su servizio di backend possono gestire sia il traffico IPv4 sia il traffico IPv6.
  • Controllo granulare della distribuzione del traffico. Una configurazione di servizio di backend contiene un set di valori, come i controlli di integrità, l'affinità sessione, il monitoraggio della connessione, il svuotamento della connessione e i criteri di failover. La maggior parte di queste impostazioni ha valori predefiniti che ti consentono di iniziare rapidamente.
  • Controlli di integrità. I bilanciatori del carico di rete basati su servizi di backend utilizzano controlli di integrità che corrispondono al tipo di traffico (TCP, SSL, HTTP, HTTPS o HTTP/2) che distribuiscono.
  • Integrazione di Google Cloud Armor. Google Cloud Armor supporta la protezione DDoS di rete avanzata per i bilanciatori del carico di rete. Per ulteriori informazioni, consulta la pagina Configurare la protezione avanzata della rete DDoS.

Bilanciamento del carico per applicazioni GKE

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

Documentazione GKE correlata:

Architettura

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

Bilanciatore del carico di rete TCP/UDP esterno con servizio di backend a livello di regione
Bilanciamento del carico di rete con il servizio di backend a livello di area geografica

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

  • Uno o più indirizzi IP esterni a livello di regione
  • Una o più regole di forwarding esterno a livello di regione
  • Un servizio di backend esterno a livello di regione
  • Uno o più gruppi di istanze di backend
  • Controllo di integrità associato al servizio di backend

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

Indirizzo IP

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

  • Per il traffico IPv4, la regola di forwarding fa riferimento a un singolo indirizzo IPv4 esterno a livello di regione. Gli indirizzi IPv4 esterni a livello di area geografica provengono da un pool univoco per ciascuna area geografica Google Cloud. L'indirizzo IP può essere un indirizzo statico prenotato o un indirizzo temporaneo.
  • Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo /96 di indirizzi IP dall'intervallo di indirizzi IPv6 esterni della subnet /64. La subnet deve essere una subnet a doppio stack con ipv6-access-type impostato su EXTERNAL. Gli indirizzi IPv6 esterni sono disponibili solo nel livello Premium. La prenotazione di un indirizzo IPv6 esterno a livello di area geografica è supportata solo per le istanze, pertanto devi utilizzare un indirizzo IPv6 temporaneo per la regola di forwarding.

Utilizza un indirizzo IP riservato per la regola di forwarding se devi conservare l'indirizzo associato al tuo progetto per riutilizzarlo dopo aver eliminato una regola di forwarding oppure se hai bisogno di più regole di forwarding che fanno riferimento allo stesso indirizzo IP.

Il bilanciamento del carico di rete supporta sia il livello Standard che il livello Premium per gli indirizzi IPv4 esterni a livello di regione. Sia l'indirizzo IP che la regola di forwarding devono utilizzare lo stesso livello di rete. Gli indirizzi IPv6 esterni a livello di area geografica sono disponibili solo nel livello Premium.

Regola di forwarding

Una regola di forwarding esterno a livello di area geografica specifica il protocollo e le porte su cui il bilanciatore del carico accetta il traffico. Poiché i bilanciatori del carico di rete non sono proxy, passano il traffico ai backend sullo stesso protocollo e sulle stesse porte, se il pacchetto porta le informazioni delle porte. La regola di forwarding in combinazione con l'indirizzo IP forma il frontend del bilanciatore del carico.

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

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

  • Se la regola di forwarding fa riferimento a un indirizzo IPv4, la regola di forwarding non è associata ad alcuna subnet. In altre parole, l'indirizzo IP non appartiene a nessun intervallo di subnet di Google Cloud.

  • Se la regola di forwarding fa riferimento a un indirizzo IPv6, la regola di forwarding deve essere associata a una subnet, che deve essere (a) doppio stack e (b) --ipv6-access-type impostata su EXTERNAL.

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

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

Protocolli di forwarding

Il bilanciamento del carico di rete supporta 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 del protocollo L3_DEFAULT consente a un bilanciatore del carico di rete di bilanciare il carico del traffico TCP, UDP, ESP, GRE, ICMP e ICMPv6.

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

Le regole di forwarding che utilizzano i protocolli TCP o UDP possono fare riferimento a un servizio di backend utilizzando lo stesso protocollo della regola di forwarding o un servizio di backend il cui protocollo è UNSPECIFIED. L3_DEFAULT regole di forwarding possono fare riferimento solo a un servizio di backend con protocollo UNSPECIFIED.

Se utilizzi il protocollo L3_DEFAULT, devi configurare la regola di forwarding in modo che accetti il traffico su tutte le porte. Per configurare tutte le porte, imposta --ports=ALL utilizzando Google Cloud CLI oppure allPorts su True utilizzando l'API.

La tabella seguente riepiloga come utilizzare queste impostazioni per protocolli diversi.

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

Più regole di forwarding

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

La configurazione di più regole di forwarding esterno a livello di area geografica può essere utile per i seguenti casi d'uso:

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

Google Cloud richiede che i pacchetti in entrata non corrispondano a più di una regola di forwarding. Ad eccezione delle regole di forwarding di direzione descritte nella sezione successiva, due o più regole di forwarding che utilizzano lo stesso indirizzo IP esterno a livello di regione devono avere combinazioni di protocollo e porta 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 forwarding che utilizzano lo stesso protocollo e lo stesso indirizzo IP. È possibile configurare le regole di forwarding che utilizzano i protocolli TCP o UDP per utilizzare tutte le porte oppure possono essere configurate per porte specifiche. Ad esempio, se crei una regola di forwarding utilizzando l'indirizzo IP 198.51.100.1, il protocollo TCP e tutte le porte, non puoi creare altre regole di forwarding utilizzando l'indirizzo IP 198.51.100.1 e il protocollo TCP. Puoi creare due regole di forwarding, entrambe utilizzando l'indirizzo IP 198.51.100.1 e il protocollo TCP, se ognuna ha porte univoche o intervalli di porte non sovrapposti. Ad esempio, puoi creare due regole di forwarding utilizzando l'indirizzo IP 198.51.100.1 e il protocollo TCP, dove una porta della regola di forwarding è 80,443 e l'altra utilizza l'intervallo di porte 81-442.
  • È possibile creare una sola regola di forwarding L3_DEFAULT per indirizzo IP. Questo perché il protocollo L3_DEFAULT utilizza tutte le porte per definizione. In questo contesto, il termine "tutte le porte" include protocolli senza informazioni sulle porte.
  • Una singola regola di forwarding L3_DEFAULT può coesistere con altre regole di forwarding che utilizzano protocolli specifici (TCP o UDP). La regola di forwarding L3_DEFAULT può essere utilizzata come ultima risorsa quando le regole di forwarding utilizzano lo stesso indirizzo IP ma esistono protocolli più specifici. Una regola di forwarding L3_DEFAULT elabora i pacchetti inviati al suo indirizzo IP di destinazione se e solo se l'indirizzo IP di destinazione del pacchetto, il protocollo e la porta di destinazione del pacchetto non corrispondono a una regola di forwarding specifica del protocollo.

    Per illustrare questo concetto, considera questi due scenari. Le regole di forwarding 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 di 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 quelli TCP inviati a porte di destinazione diverse, vengono elaborati dalla prima regola di forwarding.

Selezione della regola di forwarding

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

  • Elimina le regole di forwarding il cui protocollo non corrisponde al protocollo del pacchetto, ad eccezione di L3_DEFAULT regole di forwarding. Le regole di forwarding che utilizzano il protocollo L3_DEFAULT non vengono mai eliminate in 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 forwarding la cui porta non corrisponde alla porta del pacchetto. Le regole di forwarding configurate per tutte le porte non vengono mai eliminate da questo passaggio perché una regola di forwarding per tutte le porte corrisponde a qualsiasi porta.

  • Se i restanti criteri di forwarding includono L3_DEFAULT e regole di forwarding specifiche per il protocollo, elimina le L3_DEFAULTregole di forwarding. Se i restanti candidati per la regola di forwarding sono tutte L3_DEFAULTregole di forwarding, nessuna viene eliminata in questo passaggio.

  • A questo punto, i candidati per le regole di forwarding rimanenti rientrano in una delle seguenti categorie:

    • Rimane una sola regola di forwarding che corrisponde all'indirizzo IP, al protocollo e alla porta della destinazione del pacchetto e viene utilizzata per instradare il pacchetto.
    • Rimangono due o più candidati per la regola di forwarding che corrispondono all'indirizzo IP, al protocollo e alla porta del pacchetto. Ciò significa che i restanti candidati alla regola di forwarding includono regole di inoltro dello sterzo (parlate nella prossima sezione). Seleziona la regola di forwarding di direzione il cui intervallo source include il CIDR più specifico (corrispondenza di prefisso più lungo) contenente l'indirizzo IP di origine del pacchetto. Se nessuna regola di forwarding di direzione ha un intervallo di origine che include l'indirizzo IP di origine del pacchetto, seleziona la regola di forwarding principale.
    • Zero regole di forwarding rimanenti rimangono e il pacchetto viene eliminato.

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

Sterzo

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

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

  • L'indirizzamento del traffico ti consente di creare due regole di forwarding che indirizzano il traffico allo stesso gruppo di istanze di backend mediante due servizi di backend. I due servizi di backend possono essere configurati con diversi controlli di integrità, diverse affinità sessione 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 due regole di forwarding che indirizzano il traffico a servizi di backend diversi, con gruppi di istanze di backend diversi. Ad esempio, un gruppo di istanze potrebbe essere configurato utilizzando tipi di macchine diversi per elaborare meglio il traffico proveniente da un determinato insieme di indirizzi IP di origine.

Il controllo del traffico è configurato con un parametro API della regola di forwarding denominato sourceIPRanges. Le regole di forwarding che hanno almeno un intervallo IP di origine configurato sono chiamate regole di forwarding di direzione.

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

Ogni regola di forwarding di sterzo richiede la creazione di una regola di forwarding principale. Le regole di forwarding principali e di direzione condividono gli stessi indirizzi IP esterni a livello di area geografica, protocollo IP e informazioni sulla porta; tuttavia, la regola di forwarding principale non contiene informazioni sull'indirizzo IP di origine. Ad esempio:

  • Regola di forwarding principale: indirizzo IP: 198.51.100.1, protocollo IP: TCP, porte: 80
  • Regola di forwarding di sterzo: indirizzo IP: 198.51.100.1, protocollo IP: TCP, porte: 80, sorgenteIPRanges: 203.0.113.0/24

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

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

Devi eliminare tutte le regole di forwarding di direzione prima di poter eliminare la regola di forwarding principale da cui dipendono.

Per informazioni su come vengono elaborati i pacchetti in entrata quando si utilizzano le regole di forwarding di reindirizzamento, consulta la sezione Selezione delle regole di forwarding.

Comportamento di affinità sessione per altre modifiche

Questa sezione descrive le condizioni in base alle quali l'affinità sessione potrebbe interrompersi quando vengono aggiornati gli intervalli IP di origine per l'aggiornamento delle regole di forwarding:

  • Se una connessione esistente continua a corrispondere alla stessa regola di forwarding dopo aver modificato gli intervalli IP di origine per una regola di forwarding di direzione, l'affinità sessione non subirà interruzioni. Se, a seguito della modifica, una connessione esistente corrisponde a una regola di forwarding diversa:
  • L'affinità sessione si interrompe sempre nei seguenti casi:
    • La regola di forwarding con corrispondenza nuova indirizza una connessione stabilita a un servizio di backend (o un'istanza di destinazione) che non fa riferimento alla VM di backend selezionata in precedenza.
    • La regola di forwarding con corrispondenza recente 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 continuare a mantenere le connessioni quando i backend sono in stato non integro e la VM di backend non supera il controllo di integrità del servizio di backend.
  • L'affinità sessione potrebbe non funzionare quando la regola di forwarding con corrispondenza recente indirizza una connessione stabilita a un servizio di backend e il servizio di backend fa riferimento alla VM selezionata in precedenza, ma la combinazione del servizio di backend dell'affinità sessione e della modalità di monitoraggio della connessione genera un hash di monitoraggio delle connessioni diverso.

Preservare l'affinità sessione tra le modifiche apportate

In questa sezione viene spiegato come evitare di interrompere l'affinità sessione quando vengono aggiornati gli intervalli IP di origine per la gestione delle regole di forwarding:

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

Per istruzioni su come configurare il controllo del traffico, consulta Configurare il controllo del traffico.

Servizio di backend a livello di area geografica

Ogni bilanciatore del carico di rete dispone di un servizio di backend a livello di area geografica che definisce il comportamento del bilanciatore del carico e la distribuzione del traffico sui suoi backend. Il nome del servizio di backend è il nome del bilanciatore del carico di rete mostrato in Google Cloud Console.

Ogni servizio di backend definisce i seguenti parametri di backend:

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

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

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

    Per una tabella con le possibili combinazioni di regole di forwarding e protocollo di servizio di backend, consulta la specifica del protocollo di forwarding.

  • Distribuzione del traffico. Un servizio di backend consente di distribuire il traffico in base a criteri di affinità sessione e monitoraggio della connessione configurabili. Il servizio di backend può anche essere configurato per abilitare lo svuotamento della connessione e designare i backend di failover per il bilanciatore del carico.

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

Ogni servizio di backend opera in un'unica area geografica e distribuisce il traffico alla prima interfaccia di rete (nic0) delle VM di backend. I backend devono essere gruppi di istanze nella stessa regione del servizio di backend (e regola di forwarding). I backend possono essere gruppi di istanze non gestite a livello di zona, gruppi di istanze gestite a livello di zona o gruppi di istanze gestite a livello di regione.

I bilanciatori del carico di rete basati su servizio di backend supportano i gruppi di istanze le cui istanze membri utilizzano una rete VPC nella stessa area geografica, purché la rete VPC sia nello stesso progetto del servizio di backend. Tutte le VM all'interno di un determinato gruppo di istanze devono utilizzare la stessa rete VPC.

Se vuoi che il bilanciatore del carico supporti il traffico IPv6, il servizio di backend deve fare riferimento ai backend che soddisfano i requisiti per la gestione del traffico IPv6.

Gruppi di istanze di backend

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

  • Gruppi di istanze gestite a livello di area geografica. Utilizza i gruppi di istanze gestite a livello di regione se puoi eseguire il deployment del tuo software utilizzando i modelli di istanza. I gruppi di istanze gestite a livello di area geografica distribuiscono automaticamente il traffico tra più zone, offrendo la soluzione migliore per evitare potenziali problemi in una determinata zona.

    Di seguito è riportato un deployment di esempio che utilizza un gruppo di istanze gestite a livello di regione. Il gruppo di istanze ha un modello di istanza che definisce la modalità di provisioning delle istanze e ogni gruppo esegue il deployment delle istanze all'interno di tre zone della regione us-central1.

    Bilanciatore del carico di rete con un gruppo di istanze gestite a livello di regione
    Bilanciamento del carico di rete con un gruppo di istanze gestite a livello di area geografica
  • Gruppi di istanze gestite o non gestite a livello di area geografica. Utilizza gruppi di istanze a livello di zona in zone diverse (nella stessa area geografica) per evitare potenziali problemi in una determinata zona.

    Di seguito è riportato un deployment di esempio che utilizza gruppi di istanze a livello di zona. Questo bilanciatore del carico fornisce disponibilità tra due zone.

    Bilanciatore del carico di rete con gruppi di istanze a livello di zona
    Bilanciamento del carico di rete con gruppi di istanze a livello di zona

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 di stack doppio che si trovano nella stessa regione della regola di forwarding IPv6 del bilanciatore del carico. Per i backend, puoi utilizzare una subnet con il valore ipv6-access-type impostato su EXTERNAL o INTERNAL. Per utilizzare una subnet con ipv6-access-type impostata su INTERNAL, è necessaria una subnet a doppio stack separata con ipv6-access-type impostata su EXTERNAL per la regola di forwarding esterno del bilanciatore del carico. Per le istruzioni, consulta la sezione Aggiungere una subnet a doppio stack.
  • I gruppi di istanze di backend devono essere configurati per un doppio stack con il valore --ipv6-network-tier impostato su PREMIUM. Per le istruzioni, consulta la pagina Creare un modello di istanza con indirizzi IPv6.

Controlli di integrità

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

Per maggiori dettagli sul funzionamento dei controlli di integrità di Google Cloud, vedi Come funzionano i controlli di integrità.

Il bilanciamento del carico di rete supporta i seguenti tipi di controlli di integrità:

Controlli di integrità per il traffico di altro protocollo

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

Ad esempio, se esegui il bilanciamento del carico del traffico UDP, le richieste client vengono bilanciate utilizzando il protocollo UDP e devi eseguire un servizio TCP per fornire informazioni ai probe del controllo di integrità di Google Cloud. Per ottenere questo risultato, puoi eseguire un semplice server HTTP su ogni VM di backend che restituisce una risposta HTTP 200 ai probe del controllo di integrità. Devi utilizzare la tua logica in esecuzione sulla VM di backend per assicurarti che il server HTTP restituisca 200 solo se il servizio UDP è configurato ed eseguito correttamente.

Regole del firewall

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

Le regole di forwarding e i criteri in entrata consentono alle regole firewall o ai criteri firewall gerarchici di funzionare insieme nel modo seguente: una regola di forwarding specifica il protocollo e, se definito, i requisiti delle porte che un pacchetto deve soddisfare per poter essere inoltrati a una VM di backend. Le regole di autorizzazione Consenti firewall controllano se i pacchetti inoltrati vengono distribuiti alla VM o eliminati. Tutte le reti VPC prevedono una regola firewall firewall implicita di negazione 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 pre-inserite.

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

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

  • Il bilanciamento del carico di rete utilizza i controlli di integrità di Google Cloud. Pertanto, devi sempre consentire il traffico proveniente dagli intervalli di indirizzi IP del controllo di integrità. Queste regole firewall in entrata possono essere rese specifiche per il protocollo e le porte del controllo di integrità del bilanciatore del carico.

Indirizzi IP per i pacchetti di richiesta e ritorno

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

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

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

  • Monitora (associa a) l'indirizzo IP della regola di forwarding del bilanciatore del carico o qualsiasi indirizzo IP (0.0.0.0 o ::)
  • Se il protocollo della regola di forwarding del bilanciatore del carico supporta le porte: ascolta (vincola a) una porta inclusa nella regola di forwarding 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:

  • TCP è orientato alla connessione, quindi le VM di backend devono rispondere con pacchetti i cui indirizzi IP di origine corrispondono all'indirizzo IP della regola di forwarding in modo che il client possa associare i pacchetti di risposta alla connessione TCP appropriata.
  • UDP, ESP, GRE e ICMP sono senza connessione. Le VM di backend possono inviare pacchetti di risposta i cui indirizzi IP di origine corrispondono all'indirizzo IP della regola di forwarding o corrispondono a qualsiasi indirizzo IP esterno assegnato per la VM. In pratica, la maggior parte dei client prevede che la risposta provenga dallo stesso indirizzo IP a cui hanno inviato i pacchetti.

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

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

Quando una VM ha un indirizzo IP esterno o quando utilizzi Cloud NAT, è anche possibile impostare l'indirizzo IP di origine del pacchetto di risposta sull'indirizzo IPv4 interno principale della VM NIC. Google Cloud o Cloud NAT modifica l'indirizzo IP di origine del pacchetto di risposta all'indirizzo IPv4 esterno del NIC o all'indirizzo IPv4 esterno di Cloud NAT per inviare il pacchetto di risposta all'indirizzo IP esterno del client. Non utilizzare l'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

Il bilanciamento del carico di rete utilizza route speciali all'esterno della rete VPC per indirizzare le richieste in entrata e i probe di controllo di integrità a ogni VM di backend.

Il bilanciatore del carico conserva gli indirizzi IP di origine dei pacchetti. Le risposte dalle VM di backend vengono inviate direttamente ai client, non tramite il bilanciatore del carico. Il termine utilizzato nel settore per questo termine è ritorno diretto del server.

Architettura VPC condivisa

Ad eccezione dell'indirizzo IP, tutti i componenti di un bilanciatore del carico di rete devono esistere nello stesso progetto. La tabella seguente riepiloga i componenti del VPC condiviso per il bilanciamento del carico di rete:

Indirizzo IP Regola di forwarding Componenti di backend
Un indirizzo IP esterno a livello di area geografica deve essere definito nello stesso progetto del bilanciatore del carico o del progetto host del VPC condiviso. Una regola di forwarding esterno a livello di area geografica deve essere definita nello stesso progetto delle istanze nel servizio di backend.

Il servizio di backend a livello di area geografica deve essere definito nello stesso progetto e nella stessa area geografica in cui esistono le istanze nel gruppo di istanze di backend.

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

Distribuzione del traffico

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

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

Per i dettagli su come sono distribuite le connessioni, vedi la sezione successiva Selezione del backend e monitoraggio delle connessioni.

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

Selezione del backend e monitoraggio della connessione

Il bilanciamento del carico di rete utilizza algoritmi di monitoraggio della connessione e di selezione del backend configurabili per determinare la distribuzione del traffico alle VM di backend.

Il bilanciamento del carico di rete utilizza il seguente algoritmo per distribuire i pacchetti tra le VM di backend (nel relativo pool attivo, se hai configurato il failover):

  1. Se il bilanciatore del carico contiene una voce nella tabella di monitoraggio delle connessioni che corrisponde alle caratteristiche di un pacchetto in entrata, il pacchetto viene inviato al backend specificato dalla voce della tabella di monitoraggio delle connessioni. Il pacchetto è considerato come parte di una connessione stabilita in precedenza, quindi il pacchetto 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, il bilanciatore del carico:

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

      • Per i pacchetti UDP e non frammentati, un hash a 5 tuple dell'indirizzo IP di origine del pacchetto, della porta di origine, dell'indirizzo IP di destinazione, della porta di destinazione e del protocollo.
      • Per i pacchetti UDP frammentati e tutti gli altri protocolli, un hash a 3 tuple dell'indirizzo IP di origine del pacchetto, dell'indirizzo IP di destinazione e del protocollo

      La selezione del backend può essere personalizzata usando un algoritmo hash che utilizza meno informazioni. Per tutte le opzioni supportate, consulta la sezione Opzioni di affinità sessione.

    2. Il bilanciatore del carico aggiunge una voce alla propria 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 è a 5 tuple, ma può essere configurato in modo che sia inferiore a 5 tuple. Quando è a 5 tuple, i pacchetti TCP SYN vengono trattati in modo diverso. A differenza dei pacchetti non SSH, ignorano qualsiasi voce di monitoraggio della connessione corrispondente e selezionano sempre un nuovo backend.

        Il monitoraggio della connessione a cinque tuple predefinito viene utilizzato quando:

        • La modalità di monitoraggio è PER_CONNECTION (tutte le affinità sessione) oppure,
        • la modalità di monitoraggio è PER_SESSION e l'affinità sessione è NONE, oppure,
        • la modalità di monitoraggio è PER_SESSION e l'affinità sessione è CLIENT_IP_PORT_PROTO.
      • Pacchetti UDP, ESP e GRE Il monitoraggio delle connessioni viene attivato solo se l'affinità sessione è impostata su un valore diverso da NONE.

      • Pacchetti ICMP e ICMPv6. Impossibile utilizzare il monitoraggio della connessione.

      Per ulteriori dettagli su quando il monitoraggio della connessione è attivo e sul metodo di monitoraggio utilizzato quando il monitoraggio delle connessioni è attivo, consulta la sezione relativa alla 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 elabora l'ultimo pacchetto corrispondente alla voce. Questo valore di timeout per inattività di 60 secondi non è configurabile.
      • A seconda del protocollo, il bilanciatore del carico potrebbe rimuovere le voci della tabella di monitoraggio delle connessioni quando i backend sono in stato non integro. Per maggiori dettagli e su come personalizzare questo comportamento, vedi Persistenza della connessione su backend in stato non integro.

Opzioni di affinità sessione

Affinità 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 a livello di regione, non a livello di gruppo di istanze di backend.

Il bilanciamento del carico di rete supporta le seguenti opzioni di affinità sessione:

  • Nessuno (NONE). Hash di 5 tuple di indirizzo IP di origine, porta di origine, protocollo, indirizzo IP di destinazione e porta di destinazione
  • IP client, IP di destinazione (CLIENT_IP). Hash di due tuple dell'indirizzo IP di origine e dell'indirizzo IP di destinazione
  • IP client, IP di destinazione, protocollo (CLIENT_IP_PROTO). Hash di 3 tuple dell'indirizzo IP di origine, dell'indirizzo IP di destinazione e del protocollo
  • IP client, porta client, IP di destinazione, porta di destinazione, protocollo (CLIENT_IP_PORT_PROTO). 5-tuple hash 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 sui metodi di selezione e connessione del backend, consulta questa tabella.

Modalità di monitoraggio delle connessioni

L'abilitazione del monitoraggio delle connessioni dipende solo dal protocollo del traffico con bilanciamento del carico e dalle impostazioni di affinità sessione. La modalità di monitoraggio specifica l'algoritmo di monitoraggio delle connessioni da utilizzare quando il monitoraggio della connessione è attivato. Esistono due modalità di monitoraggio: PER_CONNECTION (valore predefinito) 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, a prescindere dall'impostazione di affinità sessione. Per il traffico UDP, ESP e GRE, il monitoraggio della connessione viene attivato 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 della connessione a 2 e 3 tuple, rispettivamente, per tutti i protocolli (tranne ICMP e ICMPv6, che non sono monitorabili per la connessione). Per le altre impostazioni di affinità sessione, la modalità PER_SESSION si comporta in modo identico alla modalità PER_CONNECTION.

Per scoprire come queste modalità di monitoraggio funzionano con impostazioni di affinità sessione diverse per ogni protocollo, consulta la seguente tabella.

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

(NONE)

TCP e UDP non frammentato: hash a 5 tuple

UDP frammentato e tutti gli altri protocolli: hash a 3 tuple

  • TCP:monitoraggio della connessione a 5 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
  • TCP: monitoraggio delle connessioni a 5 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
IP client, IP di destinazione

(CLIENT_IP)

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

(CLIENT_IP_PROTO)

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

(CLIENT_IP_PORT_PROTO)

TCP e UDP non frammentato: hash a 5 tuple

UDP frammentato e tutti gli altri protocolli: hash a 3 tuple

  • TCP e UDP non frammentato: monitoraggio della connessione a 5 tuple
  • Fragmented UDP, ESP e GRE:monitoraggio della connessione a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato
  • TCP e UDP non frammentato: monitoraggio della connessione a 5 tuple
  • Fragmented UDP, ESP e GRE: monitoraggio della connessione a 3 tuple
  • Tutti gli altri protocolli: monitoraggio della connessione disattivato

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

Persistenza della connessione su backend in stato non integro

Le impostazioni di persistenza della connessione controllano se una connessione esistente rimane su un backend selezionato dopo che il backend diventa in stato non integro (purché il backend rimanga nel gruppo di istanze 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 persistono solo come descritto nello svuotamento delle connessioni.

Sono disponibili le seguenti opzioni di persistenza della connessione:

  • DEFAULT_FOR_PROTOCOL (valore predefinito)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

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

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

TCP: le connessioni persistono sui backend in stato non integro (tutte le affinità delle sessioni)

Tutti gli altri protocolli: le connessioni non vengono mai mantenute nei 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 nei backend in stato non integro.

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

TCP:le connessioni persistono sui backend in stato non integro (tutte le affinità delle sessioni)

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

ICMP, ICMPv6: non applicabile perché non sono monitorabili durante la connessione

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

Configurazione non possibile

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

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

  • Se il backend in stato 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 in stato non integro invia un pacchetto di reimpostazione TCP (RST) o non risponde ai pacchetti, il client potrebbe riprovare con una nuova connessione, consentendo al bilanciatore del carico di selezionare un backend diverso in stato integro. I pacchetti TCP SYN selezionano sempre un nuovo backend integro.

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

Svuotamento della connessione

Lo svuotamento delle connessioni è un processo applicato alle connessioni stabilite quando:

  • una VM di backend viene rimossa da un gruppo di istanze; oppure
  • Quando un gruppo di istanze gestite rimuove una VM di backend (per sostituzione, abbandono, quando esegue l'upgrade o lo scale down) oppure
  • Quando un gruppo di istanze viene rimosso da un servizio di backend.

Lo svuotamento della connessione è disattivato per impostazione predefinita. Se questa opzione è disattivata, le connessioni stabilite vengono terminate il più rapidamente possibile. Se è abilitato lo svuotamento delle connessioni, le connessioni stabilite rimangono valide per un timeout configurabile, dopodiché l'istanza VM di backend viene terminata.

Per maggiori dettagli su come viene attivato lo svuotamento della connessione e su come attivare lo svuotamento delle connessioni, consulta la sezione Abilitare lo svuotamento delle connessioni.

Frammentazione UDP

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

  • I pacchetti UDP potrebbero frammentarsi prima di raggiungere una rete VPC di Google Cloud.
  • Le reti VPC 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 inoltrare frammenti di UDP al loro arrivo, ritardare i pacchetti UDP frammentati fino a quando non saranno arrivati tutti i frammenti o ignorare i pacchetti UDP frammentati. Per i dettagli, consulta la documentazione del provider di rete o delle apparecchiature di rete.

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

  • Configurazione della regola di forwarding: utilizza solo una UDP oL3_DEFAULT una regola di forwarding per indirizzo IP con bilanciamento del carico e configura la regola di forwarding per accettare il traffico su tutte le porte. Ciò garantisce che tutti i frammenti arrivino alla stessa regola di forwarding. Anche se i pacchetti frammentati (diversi dal primo frammento) non hanno una porta di destinazione, la configurazione della regola di forwarding per l'elaborazione del traffico per tutte le porte la configura anche per ricevere frammenti UDP privi di 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à sessione del servizio di backend su CLIENT_IP (hash di 2 tuple) o CLIENT_IP_PROTO (hash di 3 tuple) in modo che venga selezionato lo stesso backend per i pacchetti UDP che includono informazioni sulla porta e frammenti UDP (diversi dal primo frammento) privi di informazioni sulla porta. Imposta la modalità di monitoraggio della connessione 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.

Utilizzo di istanze di destinazione come backend

Se utilizzi istanze di destinazione come backend per il bilanciatore del carico di rete e ti aspetti 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 con gcloud o allPorts su True utilizzando l'API.

Esegui il failover

Puoi configurare un bilanciatore del carico di rete per distribuire le connessioni tra le istanze di macchine virtuali (VM) nei gruppi di istanze di backend primarie e, se necessario, passare all'utilizzo dei gruppi di istanze di backend di failover. Failover fornisce un altro metodo per aumentare la disponibilità, offrendoti al tempo stesso un maggiore controllo sulla gestione del tuo carico di lavoro quando le VM di backend principali non sono integre.

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

Per maggiori dettagli sul funzionamento del failover, consulta la Panoramica del failover per il bilanciamento del carico di rete.

Limitazioni

  • I gruppi di endpoint di rete (NEG) non sono supportati come backend per i bilanciatori del carico di rete.
  • Non puoi utilizzare Google Cloud Console per eseguire le seguenti attività:

    • Crea o modifica un bilanciatore del carico di rete la cui regola di forwarding utilizza il protocollo L3_DEFAULT.
    • Crea o modifica un bilanciatore del carico di rete il cui protocollo del servizio di backend è impostato su UNSPECIFIED.
    • Creare o modificare un bilanciatore del carico di rete che configura un criterio di monitoraggio della connessione.
    • Crea o modifica lo sterzo del traffico basato su IP di origine per una regola di forwarding.

    Utilizza Google Cloud CLI o l'API REST.

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

Passaggi successivi