Panoramica del bilanciatore del carico di rete passthrough interno

Un bilanciatore del carico di rete passthrough interno è un bilanciatore del carico a livello di regione basato sullo stack di virtualizzazione di rete Andromeda.

I bilanciatori del carico di rete passthrough interni distribuiscono il traffico tra le istanze di macchine virtuali (VM) interne nella stessa regione in una rete Virtual Private Cloud (VPC). Consente di eseguire e scalare i servizi utilizzando un indirizzo IP interno accessibile solo ai sistemi nella stessa rete VPC o negli stessi sistemi connessi alla rete VPC.

Utilizza un bilanciatore del carico di rete passthrough interno nelle seguenti circostanze:

  • Hai bisogno di un bilanciatore del carico di livello 4 pass-through ad alte prestazioni per i protocolli TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE.
  • Se gestisci il traffico tramite TLS (SSL), è accettabile che il traffico SSL venga terminato dai tuoi backend anziché dal bilanciatore del carico. Il bilanciatore del carico di rete passthrough interno non può terminare il traffico SSL.
  • Devi inoltrare i pacchetti originali senza proxy. Ad esempio, se hai bisogno di conservare l'indirizzo IP di origine del client.
  • Disponi già di una configurazione che utilizza un bilanciatore del carico passthrough e vuoi eseguirne la migrazione senza modifiche.

I bilanciatori del carico di rete passthrough interni sono adatti a molti casi d'uso. Per alcuni esempi generali, consulta la panoramica del bilanciatore del carico di rete passthrough.

Come funzionano i bilanciatori del carico di rete passthrough interni

Un bilanciatore del carico di rete passthrough interno ha un frontend (la regola di forwarding) e un backend (il servizio di backend). Puoi utilizzare gruppi di istanze o GCE_VM_IP NEG di zona come backend nel servizio di backend. Questo esempio mostra i backend di gruppi di istanze.

Esempio di bilanciatore del carico di rete passthrough interno di alto livello.
Esempio di bilanciatore del carico di rete passthrough interno di alto livello (fai clic per ingrandire).

A differenza di un bilanciatore del carico proxy, un bilanciatore del carico di rete passthrough interno non termina le connessioni dai client e poi apre nuove connessioni ai backend. Invece, un bilanciatore del carico di rete passthrough interno instrada le connessioni direttamente dai client ai backend integri, senza alcuna interruzione. Le risposte delle VM di backend integre passano direttamente ai client, non tramite il bilanciatore del carico. Le risposte TCP usano i ritorno diretti del server. Per maggiori informazioni, consulta Pacchetti di reso e richieste TCP e UDP.

Il bilanciatore del carico monitora l'integrità del backend utilizzando probe di controllo di integrità. Per ulteriori informazioni, consulta la sezione Controllo di integrità.

L'ambiente guest di Google Cloud Linux, l'ambiente guest Windows o un processo equivalente configura ogni VM di backend con l'indirizzo IP del bilanciatore del carico. Per le VM create da immagini Google Cloud, l'agente guest (in precedenza ambiente guest Windows o ambiente guest Linux) installa la route locale per l'indirizzo IP del bilanciatore del carico. Le istanze di Google Kubernetes Engine basate su Container-Optimized OS implementano questa funzionalità utilizzando invece iptables.

Il networking virtuale di Google Cloud gestisce la distribuzione e la scalabilità del traffico in base alle esigenze.

Protocolli, schema e ambito

Ogni bilanciatore del carico di rete passthrough interno supporta quanto segue:

  • Un servizio di backend con schema di bilanciamento del carico INTERNAL e un protocollo supportato. Per maggiori informazioni, consulta il servizio di backend.
  • VM di backend specificate in una delle seguenti opzioni:
  • Supporto per il traffico IPv4 e IPv6 quando si utilizzano backend di gruppi di istanze. I gruppi di endpoint di rete (NEG) a livello di zona con endpoint GCE_VM_IP supportano solo il traffico IPv4.
  • Una o più regole di forwarding, ciascuna delle quali utilizza il protocollo TCP, UDP o L3_DEFAULT corrispondente al protocollo del servizio di backend.
  • Ogni regola di forwarding con il proprio indirizzo IP univoco o più regole di forwarding che condividono un indirizzo IP comune.
  • Ogni regola di forwarding può avere fino a cinque porte o tutte.
  • Se è abilitato l'accesso globale, i client in qualsiasi regione.
  • Se l'accesso globale è disabilitato, i client che si trovano nella stessa regione del bilanciatore del carico.

Un bilanciatore del carico di rete passthrough interno non supporta:

Accesso client

Per impostazione predefinita, il bilanciatore del carico supporta solo i client che si trovano nella stessa regione del bilanciatore del carico. I client possono trovarsi nella stessa rete del bilanciatore del carico o in una rete VPC connessa tramite il peering di rete VPC. Puoi abilitare l'accesso globale per consentire ai client di qualsiasi regione di accedere al tuo bilanciatore del carico di rete passthrough interno.

Bilanciatore del carico di rete passthrough interno con accesso globale.
Bilanciatore del carico di rete passthrough interno con accesso globale (fai clic per ingrandire).

La seguente tabella riassume l'accesso client.

Accesso globale disabilitato Accesso globale attivato
I client devono trovarsi nella stessa regione del bilanciatore del carico. Devono inoltre trovarsi nella stessa rete VPC del bilanciatore del carico o in una rete VPC connessa alla rete VPC del bilanciatore del carico tramite peering di rete VPC. I client possono trovarsi in qualsiasi regione. Devono comunque trovarsi nella stessa rete VPC del bilanciatore del carico o in una rete VPC connessa alla rete VPC del bilanciatore del carico tramite peering di rete VPC.
I client on-premise possono accedere al bilanciatore del carico tramite tunnel Cloud VPN o collegamenti VLAN. Questi tunnel o collegamenti devono trovarsi nella stessa regione del bilanciatore del carico. I client on-premise possono accedere al bilanciatore del carico tramite tunnel Cloud VPN o collegamenti VLAN. Questi tunnel o collegamenti possono trovarsi in qualsiasi regione.

Indirizzi IP per i pacchetti di richiesta e reso

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 IPv4, IPv6 o IPv4 interno del client da uno degli intervalli IPv4 alias del client.
  • Destinazione:l'indirizzo IP della regola di forwarding del bilanciatore del carico. La regola di forwarding utilizza un singolo indirizzo IPv4 interno o un intervallo IPv6 interno.

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

  • Ascolta (associazione) sull'indirizzo IP della regola di forwarding del bilanciatore del carico o su qualsiasi indirizzo IP (0.0.0.0 o ::)
  • Se il protocollo della regola di forwarding del bilanciatore del carico supporta le porte, ascolta (associa a) una porta inclusa nella regola di forwarding del bilanciatore del carico

I pacchetti restituiti 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 è senza connessione, quindi le VM di backend possono inviare pacchetti di risposta i cui indirizzi IP di origine corrispondono all'indirizzo IP della regola di forwarding o a qualsiasi indirizzo IP assegnato alla VM. In pratica, la maggior parte dei client si aspetta che la risposta provenga dallo stesso indirizzo IP a cui hanno inviato i pacchetti.

La seguente tabella riassume 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 Nella maggior parte dei casi d'uso, l'indirizzo IP della regola di forwarding del bilanciatore del carico † L'origine del pacchetto richiedente

† È possibile impostare l'origine del pacchetto di risposta sull'indirizzo IPv4 interno principale del NIC della VM o su un intervallo di indirizzi IP alias. Se per la VM è abilitato l'inoltro IP, è possibile utilizzare anche origini di indirizzi IP arbitrari. Il mancato utilizzo dell'indirizzo IP della regola di forwarding come origine è uno scenario avanzato perché il client riceve un pacchetto di risposta da un indirizzo IP interno che non corrisponde all'indirizzo IP a cui ha inviato un pacchetto di richiesta.

Architettura

Un bilanciatore del carico di rete passthrough interno con più backend distribuisce le connessioni tra tutti questi backend. Per informazioni sul metodo di distribuzione e sulle sue opzioni di configurazione, consulta distribuzione del traffico.

Puoi utilizzare gruppi di istanze o NEG a livello di zona, ma non una combinazione di entrambi, come backend per un bilanciatore del carico di rete passthrough interno:

  • Se scegli gruppi di istanze, puoi utilizzare gruppi di istanze non gestite, gruppi di istanze gestite a livello di zona, gruppi di istanze gestite a livello di regione o una combinazione di tipi di gruppi di istanze.
  • Se scegli NEG a livello di zona, devi utilizzare GCE_VM_IP NEG di zona.

Disponibilità elevata descrive come progettare un bilanciatore del carico interno che non dipenda da una singola zona.

Le istanze che partecipano come VM di backend per i bilanciatori del carico di rete passthrough interni devono eseguire l'ambiente guest Linux o Windows appropriato oppure altri processi che forniscono funzionalità equivalenti. Questo ambiente guest deve essere in grado di contattare il server dei metadati (metadata.google.internal, 169.254.169.254) per leggere i metadati dell'istanza, in modo da poter generare route locali per accettare il traffico inviato all'indirizzo IP interno del bilanciatore del carico.

Questo diagramma illustra la distribuzione del traffico tra le VM situate in due gruppi di istanze separati. Il traffico inviato dall'istanza client all'indirizzo IP del bilanciatore del carico (10.10.10.9) viene distribuito tra le VM di backend in entrambi i gruppi di istanze. Le risposte inviate da una delle VM di backend di pubblicazione vengono consegnate direttamente alla VM client.

Puoi utilizzare un bilanciatore del carico di rete passthrough interno con una rete VPC in modalità personalizzata o automatica. Puoi anche creare bilanciatori del carico di rete passthrough interni con una rete legacy esistente.

Un bilanciatore del carico di rete passthrough interno è costituito dai seguenti componenti Google Cloud.

Componente Finalità Requisiti
Indirizzo IP interno Questo è l'indirizzo per il bilanciatore del carico. L'indirizzo IP interno deve trovarsi nella stessa subnet della regola di forwarding interno. La subnet deve trovarsi nella stessa regione e nella stessa rete VPC del servizio di backend.
Regola di forwarding interno Una regola di forwarding interno in combinazione con l'indirizzo IP interno è il frontend del bilanciatore del carico. Definisce il protocollo e le porte accettate dal bilanciatore del carico e indirizza il traffico a un servizio di backend interno a livello di regione. Le regole di forwarding per i bilanciatori del carico di rete passthrough interni devono:
• Avere un valore di load-balancing-scheme pari a INTERNAL.
• Usa un valore ip-protocol per TCP o UDP, corrispondente al valore protocol del servizio di backend.
• Fai riferimento a un subnet nella stessa rete VPC e nella stessa regione del servizio di backend.
Servizio di backend interno a livello di regione Il servizio di backend interno regionale definisce il protocollo utilizzato per comunicare con i backend e specifica un controllo di integrità. I backend possono essere gruppi di istanze non gestite, gruppi di istanze gestite a livello di zona, gruppi di istanze a livello di regione gestite o NEG di zona con endpoint GCE_VM_IP. Il servizio di backend deve:
• Avere un valore di load-balancing-scheme pari a INTERNAL.
• Usa un valore protocol di TCP o UDP, corrispondente al valore ip-protocol della regola di forwarding.
• Avere un controllo di integrità associato.
• Avere una regione associata. La regola di forwarding e tutti i backend devono trovarsi nella stessa regione del servizio di backend
• Essere associati a una singola rete VPC. Se non specificata, la rete viene dedotta in base alla rete utilizzata dall'interfaccia di rete predefinita di ogni VM di backend (nic0).

Sebbene il servizio di backend non sia legato a una subnet specifica, la subnet della regola di forwarding deve trovarsi nella stessa rete VPC del servizio di backend.
Controllo di integrità A ogni servizio di backend deve essere associato un controllo di integrità. Il controllo di integrità definisce i parametri in base ai quali Google Cloud considera i backend che gestisce come idonei a ricevere traffico. Solo le VM di backend integri ricevono il traffico inviato dalle VM client all'indirizzo IP del bilanciatore del carico.
 Anche se la regola di forwarding e il servizio di backend possono utilizzare TCP o UDP, Google Cloud non dispone di un controllo di integrità per il traffico UDP. Per maggiori informazioni, consulta Controlli di integrità e traffico UDP.

Un bilanciatore del carico di rete passthrough interno non supporta:

Indirizzo IP interno

I bilanciatori del carico di rete passthrough interni supportano solo subnet IPv4 (stack singolo) e subnet IPv4 e IPv6 (stack doppio). Per ulteriori informazioni, consulta Tipi di subnet.

Un bilanciatore del carico di rete passthrough interno richiede almeno una regola di forwarding. La regola di forwarding fa riferimento all'indirizzo IP interno:

  • Per il traffico IPv4, la regola di forwarding fa riferimento a un indirizzo IPv4 dell'intervallo di subnet IPv4 principale.
  • Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo /96 di indirizzi IPv6 interni dall'intervallo di indirizzi IPv6 interni /64 della subnet. La subnet deve essere una subnet a doppio stack con un intervallo di indirizzi IPv6 interno (ipv6-access-type impostato su INTERNAL).

Configurazione del firewall

I bilanciatori del carico di rete passthrough interni richiedono la seguente configurazione per i criteri firewall gerarchici e le regole firewall VPC:

Per ulteriori informazioni, consulta Configurazione delle regole firewall.

Regole di forwarding

Una regola di forwarding specifica il protocollo e le porte su cui il bilanciatore del carico accetta il traffico. Poiché i bilanciatori del carico di rete passthrough interni non sono proxy, passano il traffico ai backend sullo stesso protocollo e sulla stessa porta.

Un bilanciatore del carico di rete passthrough interno richiede almeno una regola di forwarding interno. Puoi definire più regole di forwarding per lo stesso bilanciatore del carico.

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

La regola di forwarding deve fare riferimento a una subnet specifica nella stessa rete VPC e nella stessa regione dei componenti di backend del bilanciatore del carico. Questo requisito ha le seguenti implicazioni:

  • La subnet specificata per la regola di forwarding non deve essere uguale a quella utilizzata dalle VM di backend; tuttavia, la subnet deve trovarsi nella stessa regione della regola di forwarding.
  • Per il traffico IPv4, la regola di forwarding interno fa riferimento all'indirizzo IPv4 interno a livello di regione dall'intervallo di indirizzi IPv4 principale della subnet selezionata. Questo indirizzo IPv4 può essere selezionato automaticamente oppure puoi utilizzare un indirizzo IPv4 statico (prenotato).
  • Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo /96 di indirizzi IPv6 dall'intervallo di indirizzi IPv6 interni della subnet. La subnet deve essere una subnet a doppio stack con ipv6-access-type impostato su INTERNAL. L'intervallo di indirizzi IPv6 /96 viene assegnato automaticamente oppure puoi utilizzare un indirizzo IP interno riservato.

Protocolli delle regole di forwarding

I bilanciatori del carico di rete passthrough interni supportano le seguenti opzioni di protocollo IPv4 per ogni regola di forwarding: TCP, UDP o L3_DEFAULT.

I bilanciatori del carico di rete passthrough interni supportano le seguenti opzioni di protocollo IPv6 per ogni regola di forwarding: TCP o UDP.

L'opzione L3_DEFAULT consente di bilanciare il carico dei protocolli TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE.

Oltre a supportare protocolli diversi da TCP e UDP, l'opzione L3_DEFAULT consente a una singola regola di forwarding di inoltrare contemporaneamente il traffico per più protocolli. Ad esempio, oltre a inviare richieste HTTP, puoi anche inviare un ping all'indirizzo IP del bilanciatore del carico.

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 che utilizza il 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 imposta allPorts su True utilizzando l'API.

La seguente tabella riassume come utilizzare queste impostazioni per i diversi protocolli:

Traffico da eseguire con bilanciamento del carico Protocollo della regola di forwarding Protocollo del servizio di backend
TCP (IPv4 o IPv6) TCP TCP or UNSPECIFIED
UDP (IPv4 o IPv6) UDP UDP or UNSPECIFIED
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE L3_DEFAULT UNSPECIFIED

Regole di forwarding e accesso globale

Le regole di forwarding di un bilanciatore del carico di rete passthrough interno sono a livello di regione, anche quando l'accesso globale è abilitato. Dopo aver abilitato l'accesso globale, il flag allowGlobalAccess della regola di forwarding interno a livello di regione è impostato su true.

Regole di forwarding e specifiche delle porte

Quando crei una regola di forwarding interno, devi scegliere una delle seguenti specifiche di porta:

  • Specifica almeno una porta e fino a cinque porte per numero.
  • Specifica ALL per inoltrare il traffico su tutte le porte.

Una regola di forwarding interno che supporta tutte le porte TCP o tutte le porte UDP consente alle VM di backend di eseguire più applicazioni, ciascuna sulla propria porta. Il traffico inviato a una determinata porta viene recapitato all'applicazione corrispondente e tutte le applicazioni utilizzano lo stesso indirizzo IP.

Se devi inoltrare il traffico su più di cinque porte specifiche, combina le regole firewall con le regole di forwarding. Quando crei la regola di forwarding, specifica tutte le porte, quindi crea regole firewall allow in entrata che consentono solo il traffico verso le porte desiderate. Applica le regole firewall alle VM di backend.

Non puoi modificare una regola di forwarding dopo averla creata. Se devi modificare le porte specificate o l'indirizzo IP interno per una regola di forwarding interno, devi eliminarla e ricrearla.

Più regole di forwarding per un singolo servizio di backend

Puoi configurare più regole di forwarding interno che fanno tutte riferimento allo stesso servizio di backend interno. Un bilanciatore del carico di rete passthrough interno richiede almeno una regola di forwarding interno.

La configurazione di più regole di forwarding per lo stesso servizio di backend ti consente di:

  • Assegna più indirizzi IP al bilanciatore del carico. Puoi creare più regole di forwarding, ciascuna con un indirizzo IP univoco. Ogni regola di forwarding può specificare tutte le porte o un insieme di massimo cinque porte.

  • Assegna un insieme specifico di porte, utilizzando lo stesso indirizzo IP, al bilanciatore del carico. Puoi creare più regole di forwarding che condividono lo stesso indirizzo IP, in cui ogni regola di forwarding utilizza un insieme specifico di massimo cinque porte. Questa è un'alternativa alla configurazione di una singola regola di forwarding che specifica tutte le porte.

Per ulteriori informazioni su scenari che coinvolgono due o più regole di forwarding interno che condividono un indirizzo IP interno comune, consulta Più regole di forwarding con lo stesso indirizzo IP.

Quando utilizzi più regole di forwarding interno, assicurati di configurare il software in esecuzione sulle VM di backend per l'associazione a tutti gli indirizzi IP delle regola di forwarding o a qualsiasi indirizzo (0.0.0.0/0 per IPv4 o ::/0 per IPv6). L'indirizzo IP di destinazione per un pacchetto consegnato tramite il bilanciatore del carico è l'indirizzo IP interno associato alla regola di forwarding interno corrispondente. Per maggiori informazioni, consulta Pacchetti di reso e richieste TCP e UDP.

Servizio di backend

Ogni bilanciatore del carico di rete passthrough interno dispone di un servizio di backend interno regionale che definisce i parametri e il comportamento di backend. Il nome del servizio di backend è il nome del bilanciatore del carico di rete passthrough interno mostrato nella console Google Cloud.

Ogni servizio di backend definisce i seguenti parametri di backend:

  • Protocollo. Un servizio di backend supporta il traffico IPv4 e IPv6. Se il protocollo prevede il concetto di porta (come TCP o UDP), il servizio di backend consegna i pacchetti alle VM di backend sulla stessa porta di destinazione a cui è stato inviato il traffico.

    I servizi di backend supportano le seguenti opzioni di protocollo IPv4: TCP, UDP o UNSPECIFIED.

    I servizi di backend supportano le seguenti opzioni di protocollo IPv6: TCP o UDP. Il protocollo del servizio di backend deve coordinarsi con il protocollo della regola di forwarding.

    Per una tabella con le possibili combinazioni di regole di forwarding e protocollo del servizio di backend, consulta Specifica del protocollo della regola di forwarding.

  • Distribuzione del traffico. Un servizio di backend consente la distribuzione del traffico in base a un'affinità sessione configurabile.

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

Ogni servizio di backend opera in una singola regione e distribuisce il traffico per le VM di backend in un'unica rete VPC:

Backend di gruppi di istanze e interfacce di rete

La rete VPC associata a un gruppo di istanze è la rete VPC utilizzata dall'interfaccia di rete nic0 di ogni VM membro.

  • Per i gruppi di istanze gestite, la rete VPC del gruppo di istanze è definita nel modello di istanza.
  • Per i gruppi di istanze non gestite, la rete VPC del gruppo di istanze è definita come la rete VPC utilizzata dall'interfaccia di rete nic0 della prima istanza VM che aggiungi al gruppo di istanze non gestite.

All'interno di un determinato gruppo di istanze (gestite o non gestite), tutte le istanze VM devono avere le interfacce di rete nic0 nella stessa rete VPC. Ogni VM membro può avere facoltativamente interfacce di rete aggiuntive (da nic1 a nic7), ma ogni interfaccia di rete deve collegarsi a una rete VPC diversa. Queste reti devono anche essere diverse dalla rete VPC associata al gruppo di istanze.

Backend e interfacce di rete NEG a livello di zona

Quando crei un nuovo NEG a livello di zona con endpoint GCE_VM_IP, devi associare esplicitamente il NEG a una subnet di una rete VPC prima di poter aggiungere endpoint al NEG. Non è possibile modificare né la subnet né la rete VPC dopo la creazione del NEG.

All'interno di un determinato NEG, ogni endpoint GCE_VM_IP rappresenta in realtà un'interfaccia di rete. L'interfaccia di rete deve trovarsi nella subnet associata al NEG. Dal punto di vista di un'istanza Compute Engine, l'interfaccia di rete può utilizzare qualsiasi identificatore (da nic0 a nic7). Dal punto di vista di un endpoint in un NEG, l'interfaccia di rete viene identificata utilizzando il suo indirizzo IPv4 principale.

Esistono due modi per aggiungere un endpoint GCE_VM_IP a un NEG:

  • Se specifichi solo il nome di una VM (senza indirizzo IP) quando aggiungi un endpoint, Google Cloud richiede che la VM abbia un'interfaccia di rete nella subnet associata al NEG. L'indirizzo IP che Google Cloud sceglie per l'endpoint è l'indirizzo IPv4 interno principale dell'interfaccia di rete della VM nella subnet associata al NEG.
  • Se specifichi sia un nome di VM sia un indirizzo IP quando aggiungi un endpoint, l'indirizzo IP fornito deve essere un indirizzo IPv4 interno principale di una delle interfacce di rete della VM. L'interfaccia di rete deve trovarsi nella subnet associata al NEG. Tieni presente che specificare un indirizzo IP è ridondante perché nella subnet associata al NEG può esistere una sola interfaccia di rete.

Specifica della rete del servizio di backend

Puoi associare esplicitamente una rete VPC a un servizio di backend utilizzando il flag --network quando crei il servizio di backend. Le regole di rete del servizio di backend vengono applicate immediatamente.

Se ometti il flag --network quando crei un servizio di backend, Google Cloud utilizza uno dei seguenti eventi di qualificazione per impostare in modo implicito la rete VPC associata al servizio di backend. Una volta impostato, la rete VPC associata al servizio di backend non può essere modificata:

  • Se al servizio di backend non sono ancora associati backend e configuri la prima regola di forwarding per fare riferimento al servizio di backend, Google Cloud imposta la rete VPC associata al servizio di backend sulla rete VPC contenente la subnet utilizzata da questa regola di forwarding.

  • Se il servizio di backend non ha ancora una regola di forwarding che fa riferimento e aggiungi al servizio di backend il backend del primo gruppo di istanze, Google Cloud imposta la rete VPC del servizio di backend sulla rete VPC associata al backend del primo gruppo di istanze. Ciò significa che la rete VPC associata al servizio di backend è la rete utilizzata dall'interfaccia di rete nic0 di ogni VM nel backend del primo gruppo di istanze.

  • Se il servizio di backend non ha ancora una regola di forwarding che fa riferimento e aggiungi il primo backend NEG a livello di zona (con endpoint GCE_VM_IP) al servizio di backend, Google Cloud imposta la rete VPC del servizio di backend sulla rete VPC associata al primo backend NEG.

Dopo che la rete VPC del servizio di backend è stata impostata da un evento idoneo, eventuali regole di forwarding aggiuntive, gruppi di istanza di backend o NEG di zona di backend aggiunti devono seguire le regole di rete del servizio di backend.

Regole di rete dei servizi di backend

Le seguenti regole si applicano dopo che un servizio di backend è associato a una rete VPC specifica:

  • Quando configuri una regola di forwarding per fare riferimento al servizio di backend, la regola di forwarding deve utilizzare una subnet della rete VPC del servizio di backend. La regola di forwarding e il servizio di backend non possono utilizzare reti VPC diverse, anche se queste sono connesse tramite peering di rete VPC.

  • Quando aggiungi backend di gruppi di istanze, deve essere vera una delle seguenti condizioni:

    • La rete VPC associata al gruppo di istanze, ovvero la rete VPC utilizzata dall'interfaccia di rete nic0 di ogni VM nel gruppo di istanze, deve corrispondere alla rete VPC associata del servizio di backend.
    • Ogni VM di backend deve avere un'interfaccia non nic0 (da nic1 a nic7) nella rete VPC associata al servizio di backend.

  • Quando aggiungi backend NEG a livello di zona con endpoint GCE_VM_IP, la rete VPC associata al NEG deve corrispondere alla rete VPC associata al servizio di backend.

Creazione di sottoinsiemi di backend

L'impostazione di sottoinsiemi di backend è una funzionalità facoltativa che migliora le prestazioni limitando il numero di backend a cui il traffico è distribuito.

Abilita l'impostazione secondaria solo se devi supportare più di 250 VM di backend su un singolo bilanciatore del carico. Per maggiori informazioni, consulta Creazione di sottoinsiemi di backend per il bilanciatore del carico di rete passthrough interno.

Controllo di integrità

Il servizio di backend del bilanciatore del carico deve essere associato a un controllo di integrità globale o regionale. Route speciali esterne alla rete VPC facilitano la comunicazione tra i sistemi di controllo di integrità e i backend.

Puoi utilizzare un controllo di integrità esistente o definirne uno nuovo. I bilanciatori del carico di rete passthrough interni utilizzano lo stato del controllo di integrità per determinare come instradare nuove connessioni, come descritto in Distribuzione del traffico.

Puoi utilizzare uno dei seguenti protocolli di controllo di integrità. Il protocollo del controllo di integrità non deve corrispondere a quello del bilanciatore del carico:

  • HTTP, HTTPS o HTTP/2. Se le VM di backend gestiscono il traffico tramite HTTP, HTTPS o HTTP/2, ti consigliamo di utilizzare un controllo di integrità corrispondente a quel protocollo, perché i controlli di integrità basati su HTTP offrono opzioni appropriate per quel protocollo. Gestire il traffico di tipo HTTP attraverso un bilanciatore del carico di rete passthrough interno significa che il protocollo del bilanciatore del carico è TCP.
  • SSL o TCP. Se le VM di backend non gestiscono traffico di tipo HTTP, devi utilizzare un controllo di integrità SSL o TCP.

A prescindere dal tipo di controllo di integrità che crei, Google Cloud invia i probe del controllo di integrità all'indirizzo IP della regola di forwarding del bilanciatore del carico di rete passthrough interno all'interfaccia di rete nella rete VPC selezionata dal servizio di backend del bilanciatore del carico. Questo simula la distribuzione del traffico con bilanciamento del carico. Il software in esecuzione sulle VM di backend deve rispondere sia al traffico con bilanciamento del carico sia ai probe di controllo di integrità inviati all'indirizzo IP di ogni regola di forwarding (il software deve rimanere in ascolto su 0.0.0.0:<port> e non su un indirizzo IP specifico assegnato a un'interfaccia di rete). Per maggiori informazioni, consulta Destinazione dei pacchetti del probe.

Controlli di integrità e traffico UDP

Google Cloud non offre un controllo di integrità che utilizza il protocollo UDP. Quando utilizzi un bilanciatore del carico di rete passthrough interno con traffico UDP, devi eseguire un servizio basato su TCP sulle VM di backend per fornire informazioni sul controllo di integrità.

In questa configurazione, il bilanciamento del carico delle richieste client viene eseguito utilizzando il protocollo UDP e viene utilizzato un servizio TCP per fornire informazioni ai probe dei controlli di integrità di Google Cloud. Ad esempio, puoi eseguire un semplice server HTTP su ogni VM di backend che restituisce una risposta HTTP 200 a Google Cloud. In questo esempio, dovresti utilizzare la tua logica in esecuzione sulla VM di backend per assicurarti che il server HTTP restituisca 200 solo se il servizio UDP è configurato correttamente e in esecuzione.

Architettura ad alta disponibilità

Il bilanciatore del carico di rete passthrough interno è ad alta disponibilità per progettazione. Non sono previsti passaggi speciali per rendere il bilanciatore del carico ad alta disponibilità perché il meccanismo non si basa su un singolo dispositivo o istanza VM.

Per assicurarti che il deployment delle istanze VM di backend venga eseguito in più zone, segui questi suggerimenti per il deployment:

  • 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 regione distribuiscono automaticamente il traffico tra più zone, rappresentando l'opzione migliore per evitare potenziali problemi in una determinata zona.

  • Se utilizzi gruppi di istanze gestite a livello di zona o gruppi di istanze non gestite, utilizza più gruppi di istanze in zone diverse (nella stessa regione) per lo stesso servizio di backend. L'utilizzo di più zone protegge da potenziali problemi in una determinata zona.

Architettura di un VPC condiviso

La seguente tabella riassume i requisiti dei componenti per i bilanciatori del carico di rete passthrough interni utilizzati con le reti VPC condiviso. Per un esempio, consulta la sezione sulla creazione di un bilanciatore del carico di rete passthrough interno nella pagina Provisioning del VPC condiviso.

Indirizzo IP Regola di forwarding Componenti di backend
È necessario definire un indirizzo IP interno nello stesso progetto delle VM di backend.

Affinché il bilanciatore del carico sia disponibile in una rete VPC condiviso, l'indirizzo IP interno di Google Cloud deve essere definito nello stesso progetto di servizio in cui si trovano le VM di backend e deve fare riferimento a una subnet nella rete VPC condiviso desiderata nel progetto host. L'indirizzo stesso proviene dall'intervallo IP principale della subnet di riferimento.

Se crei un indirizzo IP interno in un progetto di servizio e la subnet dell'indirizzo IP si trova nella rete VPC del progetto di servizio, il bilanciatore del carico di rete passthrough interno è locale rispetto al progetto di servizio. Non è locale per nessun progetto host del VPC condiviso.		 È necessario definire una regola di forwarding interno nello stesso progetto delle VM di backend.

Affinché il bilanciatore del carico sia disponibile in una rete VPC condiviso, la regola di forwarding interno deve essere definita nello stesso progetto di servizio in cui si trovano le VM di backend e deve fare riferimento alla stessa subnet (nella rete VPC condiviso) a cui fa riferimento l'indirizzo IP interno associato.

Se crei una regola di forwarding interno in un progetto di servizio e la subnet della regola di forwarding si trova nella rete VPC del progetto di servizio, il bilanciatore del carico di rete passthrough interno è locale del progetto di servizio. Non è locale per nessun progetto host del VPC condiviso.		 In uno scenario di VPC condiviso, le VM di backend si trovano in un progetto di servizio. Nel progetto di servizio devono essere definiti un servizio di backend interno a livello di regione e un controllo di integrità.

Distribuzione del traffico

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

  • Se non hai configurato il failover, un bilanciatore del carico di rete passthrough interno distribuisce nuove connessioni alle sue VM di backend integri se almeno una VM di backend è in stato integro. Se 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 del backend in stato non integro.

  • Se hai configurato il failover, un bilanciatore del carico di rete passthrough interno distribuisce le nuove connessioni tra le VM nel proprio pool attivo, in base a un criterio di failover configurato. Quando tutte le VM di backend sono in stato non integro, puoi scegliere uno dei seguenti comportamenti:

    • (Predefinito) Il bilanciatore del carico distribuisce il traffico solo alle VM principali. Questa soluzione è l'ultima alternativa possibile. Le VM di backup sono escluse da questa distribuzione dell'ultima risorsa delle connessioni.
    • Il bilanciatore del carico è configurato per interrompere il traffico.

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

Lo stato del controllo di integrità controlla la distribuzione di nuove connessioni. Per impostazione predefinita, le connessioni TCP vengono mantenute su backend in stato non integro. Per maggiori dettagli e per scoprire come modificare questo comportamento, consulta Persistenza della connessione sui backend in stato non integro.

Selezione backend e monitoraggio delle connessioni

I bilanciatori del carico di rete passthrough interni utilizzano algoritmi di selezione del backend e monitoraggio della connessione configurabili per determinare in che modo il traffico viene distribuito alle VM di backend. I bilanciatori del carico di rete passthrough interni utilizzano il seguente algoritmo per distribuire i pacchetti tra le VM di backend (nel pool attivo, se hai configurato failover):

  1. Se nella tabella di monitoraggio delle connessioni del bilanciatore del carico è presente una voce corrispondente alle caratteristiche di un pacchetto in entrata, il pacchetto viene inviato al backend specificato dalla voce nella tabella di monitoraggio delle connessioni. Il pacchetto è considerato parte di una connessione stabilita in precedenza, quindi viene inviato alla VM di backend che il bilanciatore del carico aveva precedentemente determinato e registrato nella propria tabella di monitoraggio delle connessioni.

  2. Se il bilanciatore del carico riceve un pacchetto per il quale non esiste una voce di monitoraggio della connessione, effettua le seguenti operazioni:

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

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

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

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

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

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

      Se l'hash di monitoraggio delle connessioni è a 5 tuple, i pacchetti SYN TCP creano sempre una nuova voce nella tabella di monitoraggio delle connessioni.

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

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

      Per ulteriori dettagli su quando il monitoraggio delle connessioni è abilitato e sul metodo di monitoraggio utilizzato quando questo è abilitato, consulta Modalità di monitoraggio delle connessioni.

      Tieni inoltre presente quanto segue:

      • Per impostazione predefinita, una voce nella tabella di monitoraggio delle connessioni scade 600 secondi dopo che il bilanciatore del carico ha elaborato l'ultimo pacchetto corrispondente alla voce. Per maggiori dettagli su come personalizzare il timeout di inattività, consulta Timeout di inattività.
      • 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 per sapere come personalizzare questo comportamento, consulta Persistenza della connessione sui backend in stato non integro.

Opzioni di affinità sessione

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

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

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

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

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

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

Quando utilizzi un bilanciatore del carico di rete passthrough interno come hop successivo per una route statica personalizzata, è molto probabile che la destinazione del pacchetto non sia l'indirizzo IP della regola di forwarding del bilanciatore del carico.

Un pacchetto viene consegnato al bilanciatore del carico se la sua destinazione rientra nella destinazione della route statica personalizzata e la route statica personalizzata è una route applicabile.

Tutte le opzioni di affinità sessione tranne IP client, nessuna destinazione utilizzano l'indirizzo IP di destinazione del pacchetto. Se utilizzi una route statica personalizzata il cui hop successivo è un bilanciatore del carico di rete passthrough interno:

  • Se il bilanciatore del carico ha un solo backend (il pool attivo, se hai configurato il failover), tutte le opzioni di affinità sessione scelgono quel backend. La scelta di affinità sessione non fa differenza quando è presente un solo backend (nel pool attivo).

  • Se il bilanciatore del carico ha più backend (nel pool attivo, se hai configurato il failover) e scegli un'opzione di affinità sessione tranne l'IP client, nessuna destinazione, non è garantito che i pacchetti inviati dallo stesso client a qualsiasi indirizzo IP nella destinazione della route vengano elaborati dallo stesso backend. Questo perché l'hash di affinità sessione viene calcolato da informazioni che includono anche l'indirizzo IP di destinazione del pacchetto, che può essere qualsiasi indirizzo nell'intervallo di destinazione della route.

  • Se devi garantire che lo stesso backend elabori tutti i pacchetti inviati dallo stesso client a qualsiasi indirizzo IP nella destinazione della route, devi utilizzare l'opzione di affinità sessione IP client, nessuna destinazione.

Modalità di monitoraggio delle connessioni

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

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

  • PER_SESSION. In questa modalità, il traffico TCP e UDP viene monitorato in base all'affinità sessione configurata. Ciò significa che se l'affinità sessione è CLIENT_IP o CLIENT_IP_PROTO, la configurazione di questa modalità comporta il monitoraggio delle connessioni a 2 tuple e a 3 tuple, rispettivamente. Questo può essere utile in scenari in cui la rottura dell'affinità è costosa e dovrebbe essere evitata anche dopo l'aggiunta di altri backend.

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

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

NONE

 Hash a 5 tuple Monitoraggio della connessione a 5 tuple Monitoraggio della connessione a 5 tuple

IP client, nessuna destinazione

CLIENT_IP_NO_DESTINATION

 Hash a 1 tuple Monitoraggio della connessione a 5 tuple Monitoraggio della connessione in una tuple

IP client

CLIENT_IP

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

 Hash a due tuple Monitoraggio della connessione a 5 tuple Monitoraggio della connessione a 2 tuple

IP client, IP di destinazione, protocollo

CLIENT_IP_PROTO

 Hash a tre tuple Monitoraggio della connessione a 5 tuple Monitoraggio della connessione a 3 tuple

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

CLIENT_IP_PORT_PROTO

 Hash a 5 tuple Monitoraggio della connessione a 5 tuple Monitoraggio della connessione a 5 tuple

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

Persistenza della connessione su backend in stato non integro

La persistenza della connessione sui backend in stato non integro controlla se una connessione esistente persiste su un backend selezionato dopo che questo diventa non integro (a condizione che il backend rimanga nel gruppo di istanza di backend configurato del bilanciatore del carico).

Il comportamento descritto in questa sezione non si applica ai casi in cui rimuovi una VM di backend dal relativo gruppo di istanze o rimuovi il gruppo di istanze dal servizio di backend. In questi casi, le connessioni stabilite vengono mantenute solo come descritto in Attivare lo svuotamento delle connessioni.

Sono disponibili le seguenti opzioni di persistenza della connessione:

  • DEFAULT_FOR_PROTOCOL (valore predefinito)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

La seguente tabella riassume le opzioni di persistenza della connessione e il modo in cui le connessioni vengono mantenute per diversi protocolli, opzioni di affinità sessione e modalità di monitoraggio.

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

TCP: le connessioni rimangono invariate su backend in stato non integro (tutte le affinità delle sessioni)

UDP:le connessioni non vengono mai mantenute su backend in stato non integro

TCP: le connessioni rimangono invariate su backend in stato non integro se l'affinità sessione è NONE o CLIENT_IP_PORT_PROTO

UDP:le connessioni non vengono mai mantenute su backend in stato non integro
NEVER_PERSIST TCP, UDP: le connessioni non vengono mai mantenute su backend in stato non integro
ALWAYS_PERSIST

TCP, UDP: le connessioni rimangono invariate su backend in stato non integro (tutte le affinità delle sessioni)

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

 Configurazione impossibile

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

Timeout di inattività

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

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

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

Test delle connessioni da un singolo client

Quando verifichi le connessioni all'indirizzo IP di un bilanciatore del carico di rete passthrough interno da un singolo sistema client, tieni presente quanto segue:

  • Se il sistema client non è una VM con bilanciamento del carico, ovvero non una VM di backend, le nuove connessioni vengono consegnate alle VM di backend del bilanciatore del carico integro. Tuttavia, poiché tutte le opzioni di affinità sessione si basano almeno sull'indirizzo IP del sistema client, le connessioni dallo stesso client potrebbero essere distribuite sulla stessa VM di backend più spesso di quanto ci si possa aspettare.

    In pratica, questo significa che non puoi monitorare con precisione la distribuzione del traffico tramite un bilanciatore del carico di rete passthrough interno connettendoti da un singolo client. Il numero di client necessari per monitorare la distribuzione del traffico varia a seconda del tipo di bilanciatore del carico, del tipo di traffico e del numero di backend in stato integro.

  • Se la VM client è una VM di backend del bilanciatore del carico, le connessioni inviate all'indirizzo IP della regola di forwarding del bilanciatore del carico ricevono sempre una risposta dalla VM client/di backend. Ciò accade a prescindere dal fatto che la VM di backend sia integro. Questo avviene per tutto il traffico inviato all'indirizzo IP del bilanciatore del carico, non solo per il traffico sul protocollo e sulle porte specificate nella regola di forwarding interno del bilanciatore del carico.

    Per maggiori informazioni, consulta Invio di richieste da VM con bilanciamento del carico.

Frammentazione UDP

I bilanciatori del carico di rete passthrough interni possono elaborare pacchetti UDP frammentati e non frammentati. Se l'applicazione utilizza pacchetti UDP frammentati, tieni presente quanto segue:
  • I pacchetti UDP potrebbero frammentarsi prima di raggiungere una rete VPC Google Cloud.
  • Le reti VPC di Google Cloud inoltrano i frammenti UDP all'arrivo (senza attendere l'arrivo di tutti i frammenti).
  • Le reti non Google Cloud e le apparecchiature di rete on-premise potrebbero inoltrare i frammenti UDP all'arrivo, ritardare i pacchetti UDP frammentati fino all'arrivo di tutti i frammenti o eliminare i pacchetti UDP frammentati. Per i dettagli, consulta la documentazione del provider di rete o dell'apparecchiatura di rete.

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

  • Configurazione della regola di forwarding: utilizza una sola regola di forwarding UDP per indirizzo IP con bilanciamento del carico e configura la regola di forwarding in modo che accetti 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, se configuri la regola di forwarding per l'elaborazione del traffico per tutte le porte, la porta viene anche configurata in modo da ricevere frammenti UDP senza informazioni sulle porte. 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à della sessione del servizio di backend su CLIENT_IP (hash a due tuple) o CLIENT_IP_PROTO (hash a tre 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 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 due o tre tuple.

Failover

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

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

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

Quote e limiti

Per informazioni su quote e limiti, consulta Quote delle risorse di bilanciamento del carico.

Limitazioni

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

    • Crea o modifica un bilanciatore del carico di rete passthrough interno la cui regola di forwarding utilizza il protocollo L3_DEFAULT.
    • Crea o modifica un bilanciatore del carico di rete passthrough interno con il protocollo del servizio di backend impostato su UNSPECIFIED.
    • Crea un bilanciatore del carico di rete passthrough interno con backend NEG a livello di zona.

Passaggi successivi