Panoramica del bilanciatore del carico di rete passthrough interno

Un bilanciatore del carico di rete passthrough interno è un bilanciatore del carico regionale creato sulla virtualizzazione della rete Andromeda .

I bilanciatori del carico di rete passthrough interni distribuiscono il traffico tra le macchine virtuali interne (VM) nella stessa regione in una rete Virtual Private Cloud (VPC). it di eseguire e scalare i servizi dietro un indirizzo IP interno che accessibile solo ai sistemi nella stessa rete VPC o negli stessi sistemi è connesso 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 passthrough ad alte prestazioni TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE protocolli.
  • Se gestisci traffico tramite TLS (SSL), è accettabile il traffico SSL. terminati dai backend invece che tramite il 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 l'indirizzo IP di origine del client da conservare.
  • Hai una configurazione esistente che utilizza un bilanciatore del carico passthrough vuoi eseguirne la migrazione senza modifiche.

I bilanciatori del carico di rete passthrough interni rispondono a molti casi d'uso. Per alcuni esempi di alto livello, consulta Bilanciatore del carico di rete passthrough Panoramica.

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 di servizio di backend). Puoi utilizzare gruppi di istanze o GCE_VM_IP NEG a livello di zona come backend sul servizio di backend. Questo esempio mostra i backend dei 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 quindi aprono nuove connessioni ai backend. Invece, il 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 vanno direttamente a i client, non tramite il bilanciatore del carico. Le risposte TCP utilizzano un server diretto return. Per ulteriori informazioni, consulta Richiesta e ritorno TCP e UDP pacchetti.

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

L'ambiente Linux guest di Google Cloud ambiente, ambiente guest Windows ambiente o un processo equivalente configura ogni VM di backend con l'indirizzo IP del carico con il bilanciatore del carico di rete passthrough esterno regionale. Per le VM create da immagini Google Cloud, il campo Guest agent (in precedenza, Windows Guest Environment o Linux) installa la route locale per il caricamento l'indirizzo IP del bilanciatore. Istanze Google Kubernetes Engine basate su Container- Optimized OS implementa questa funzionalità utilizzando iptables .

La rete virtuale Google Cloud gestisce la distribuzione del traffico e la scalabilità in modo appropriato.

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 servizio protocollo. Per ulteriori informazioni, consulta la sezione sul servizio di backend.
  • VM di backend specificate in uno dei seguenti modi:
  • Supporto per il traffico IPv4 e IPv6 quando si utilizzano i backend di gruppi di istanze. I gruppi di endpoint di rete (NEG) di zona con GCE_VM_IP endpoint supportano solo Traffico IPv4.
  • Una o più regole di forwarding, ciascuna che utilizza 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 lo stesso indirizzo IP.
  • Ogni regola di forwarding con un massimo di cinque porte o tutte le porte.
  • Se l'accesso globale è abilitato, saranno client in qualsiasi regione.
  • Se l'accesso globale è disabilitato, i client nella stessa regione come 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 come bilanciatore del carico. I client possono trovarsi nella stessa rete del bilanciatore del carico in una rete VPC connessa Peering di rete VPC. Puoi abilitare la condivisione l'accesso per consentire i client di qualsiasi regione per accedere al 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 del client.

Accesso globale disabilitato Accesso globale abilitato
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 al bilanciatore del carico, tramite peering di rete VPC. I clienti possono trovarsi in qualsiasi regione. Devono essere comunque nello stesso modo rete VPC come bilanciatore del carico o in una Rete VPC connessa al carico utilizzando il peering di rete VPC per la rete VPC del bilanciatore.
I client on-premise possono accedere al bilanciatore del carico tramite Cloud VPN tunnel o collegamenti VLAN. Questi tunnel i collegamenti devono trovarsi nella stessa regione del bilanciatore del carico. I client on-premise possono accedere al bilanciatore del carico tramite Cloud VPN tunnel o collegamenti VLAN. Questi tunnel o collegamenti possono essere in qualsiasi regione.

Indirizzi IP per i pacchetti di richiesta e restituzione

Quando una VM di backend riceve un pacchetto con bilanciamento del carico da un client, sono:

  • Origine:l'IPv4, IPv6 o IPv4 interno del client da uno degli intervalli IPv4 alias del client.
  • Destinazione:l'indirizzo IP dell'inoltro del bilanciatore del carico personalizzata. La regola di forwarding utilizza un singolo indirizzo IPv4 interno o intervallo IPv6 interno.

Poiché il bilanciatore del carico è un bilanciatore del carico passthrough (non un proxy), arriva con l'indirizzo IP di destinazione dell'inoltro del bilanciatore del carico personalizzata. Il software in esecuzione sulle VM di backend deve essere configurato in modo da:

  • Ascolta (collega) l'indirizzo IP della regola di forwarding del bilanciatore del carico o qualsiasi IP indirizzo (0.0.0.0 o ::)
  • Se il protocollo della regola di forwarding del bilanciatore del carico supporta le porte: ascolta su (associazione 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 alla di alto profilo. Gli indirizzi IP di origine e di destinazione del pacchetto restituito dipendono dalla protocollo:

  • TCP è orientato alla connessione, quindi le VM di backend devono rispondere con pacchetti gli indirizzi IP di origine corrispondano all'indirizzo IP della regola di forwarding, in modo che 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 corrispondere a qualsiasi indirizzo IP assegnato per la VM. In pratica, la maggior parte i client si aspettano che la risposta provenga dallo stesso indirizzo IP a cui e pacchetti inviati.

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

† È possibile impostare il valore dell'origine del pacchetto di risposta all'indirizzo IPv4 interno principale del NIC della VM o nell'intervallo di indirizzi IP alias. Se per la VM è abilitato l'IP forwarding, viene usato un IP arbitrario possono essere utilizzate anche origini di indirizzi. Non viene utilizzato l'indirizzo IP della regola di forwarding come un'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 è stato inviato un pacchetto di richiesta.

Architettura

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

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 i gruppi di istanze, puoi usare i gruppi di istanze non gestite, gruppi di istanze gestite a livello di zona, gruppi di istanze gestite a livello di regione o un una combinazione di tipi di gruppi di istanze.
  • Se scegli NEG a livello di zona, devi utilizzare GCE_VM_IP NEG a livello di zona.

Alta disponibilità descrive come progettare un carico interno che non dipende da una singola zona.

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

Questo diagramma illustra il traffico. tra le VM situate in due gruppi di istanze separati. 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. Risposte inviate da che qualsiasi VM di backend di pubblicazione viene consegnata direttamente alla VM client.

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

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

Componente Finalità Requisiti
Indirizzo IP interno Questo è l'indirizzo del bilanciatore del carico. L'indirizzo IP interno deve trovarsi nella stessa subnet dell'indirizzo IP interno di una regola di forwarding. La subnet deve trovarsi nella stessa regione rete VPC come 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, che indirizza il traffico a un'istanza di servizio di backend interno. Le regole di forwarding per i bilanciatori del carico di rete passthrough interni devono fare quanto segue:
• Avere un load-balancing-scheme pari a INTERNAL.
• Usa un ip-protocol di TCP o UDP, corrispondente a protocol del backend completamente gestito di Google Cloud.
• Riferimento a un subnet nella stessa rete VPC e regione come servizio di backend.
Servizio di backend interno a livello di regione Il servizio di backend interno regionale definisce il protocollo utilizzato comunicare con i backend e specificare controllo. I backend possono essere gruppi di istanze non gestite, istanze di zona gestite gruppi, gruppi di istanze regionali gestite o NEG a livello di zona con GCE_VM_IP endpoint. Il servizio di backend deve:
• Avere un load-balancing-scheme pari a INTERNAL.
• Usa un protocol di TCP o UDP, corrispondente a ip-protocol dell'inoltro personalizzata.
• 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 associata a una singola rete VPC. Quando non è specificato, la rete viene dedotta in base alla rete utilizzata l'interfaccia di rete predefinita di ciascuna VM di backend (nic0).

Sebbene il servizio di backend non sia collegato a una subnet specifica, la subnet della regola di forwarding deve trovarsi nella stessa rete VPC come servizio di backend.
Controllo di integrità A ogni servizio di backend deve essere associato un controllo di integrità. La il controllo di integrità definisce i parametri in base ai quali Google Cloud considera i backend che gestisce essere idonei a ricevere per via del traffico. Solo le VM di backend integre ricevono il traffico inviato dal client VM 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 un controllo di integrità per il traffico UDP. Per ulteriori informazioni, vedi 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 dal nell'intervallo di subnet IPv4 principale.
  • Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo /96 di Indirizzi IPv6 dell'intervallo di indirizzi IPv6 interni /64 della subnet. La subnet deve essere una subnet a doppio stack intervallo di indirizzi IPv6 interni (ipv6-access-type impostato su INTERNAL).

Configurazione del firewall

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

Per ulteriori informazioni, consulta Configurazione del firewall .

Regole di forwarding

Una regola di forwarding specifica 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 su lo stesso protocollo e la stessa porta.

Un bilanciatore del carico di rete passthrough interno richiede almeno un forwarding interno personalizzata. Puoi definire più richieste di inoltro per lo stesso bilanciatore del carico.

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

La regola di forwarding deve fare riferimento a una specifica subnet nello stesso VPC e la regione come componenti backend del bilanciatore del carico. Questo requisito ha le seguenti implicazioni:

  • La subnet specificata per la regola di forwarding non deve essere necessariamente la stessa delle subnet utilizzate 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 a livello di regione indirizzo IPv4 interno dall'intervallo di indirizzi IPv4 principali della subnet che selezionate. Questo indirizzo IPv4 può essere selezionato automaticamente oppure puoi utilizzare indirizzo IPv4 statico (prenotato).
  • Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo /96 di IPv6 indirizzi IP compresi nell'intervallo di indirizzi IPv6 interno della subnet. La 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 utilizza un indirizzo IP interno riservato.

Protocolli delle regole di forwarding

I bilanciatori del carico di rete passthrough interni supportano le seguenti opzioni del 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 ti consente per bilanciare il carico TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH e GRE protocolli.

Oltre a supportare protocolli diversi da TCP e UDP, il L'opzione L3_DEFAULT rende è possibile che una singola regola di forwarding inoltri simultaneamente il traffico più protocolli. Ad esempio, oltre a effettuare richieste HTTP, è possibile e 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 backend utilizzando lo stesso protocollo della regola di forwarding o un backend utilizzando il protocollo UNSPECIFIED.

Se utilizzi L3_DEFAULT devi configurare il protocollo di forwarding per accettare il traffico su tutte le porte. Per configurare tutte le porte, imposta --ports=ALL mediante l'utilizzo Google Cloud CLI oppure imposta allPorts su True tramite l'API.

La tabella seguente riassume come utilizzare queste impostazioni per diverse protocolli:

Traffico per il 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 sia abilitato. Dopo aver abilitato l'accesso globale, l'inoltro interno a livello di regione il flag allowGlobalAccess della regola è impostato su true.

Regole di forwarding e specifiche delle porte

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

  • Specifica almeno una e fino a cinque porte, in base al numero.
  • Specifica ALL per inoltrare il traffico su tutte le porte.

Una regola di forwarding interno che supporti tutte le porte TCP o tutte le porte UDP consente alle VM di backend di eseguire più applicazioni, ciascuna sulla propria porta. Traffico a una determinata porta vengono consegnati all'applicazione corrispondente usano lo stesso indirizzo IP.

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

Non puoi modificare una regola di forwarding dopo averla creata. Se hai bisogno di modificare le porte specificate o l'indirizzo IP interno per una regola di forwarding interno devi eliminarlo e ricrearlo.

Più regole di forwarding per un singolo servizio di backend

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

La configurazione di più regole di forwarding per lo stesso servizio di backend consente procedi nel seguente modo:

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

  • Assegnare un insieme specifico di porte, utilizzando lo stesso indirizzo IP, con il bilanciatore del carico di rete passthrough esterno regionale. Puoi creare più regole di forwarding che condividono lo stesso IP in cui ogni regola di forwarding utilizza un insieme specifico di massimo cinque porte. È un'alternativa alla configurazione di una singola regola di forwarding che specifica tutte le porte.

Per ulteriori informazioni sugli scenari che coinvolgono due o più inoltri interni che condividono lo stesso indirizzo IP interno, consulta regole di forwarding con lo stesso indirizzo IP.

Se utilizzi più regole di forwarding interno, assicurati di configurare il il software in esecuzione sulle VM di backend per l'associazione a tutti gli IP della regola di forwarding indirizzi o a qualsiasi indirizzo (0.0.0.0/0 per IPv4 o ::/0 per IPv6). La indirizzo IP di destinazione di un pacchetto consegnato attraverso il carico è l'indirizzo IP interno associato al bilanciatore del carico interno di una regola di forwarding. Per ulteriori informazioni, consulta Richiesta e ritorno TCP e UDP pacchetti.

Servizio di backend

Ogni bilanciatore del carico di rete passthrough interno ha un servizio di backend interno regionale che definisce i parametri e il comportamento del backend. Il nome del servizio di backend è il nome Il 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 pacchetti alle VM di backend sulla stessa porta di destinazione a cui è stato inviato il traffico.

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

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

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

  • Distribuzione del traffico. Un servizio di backend consente traffico da distribuire in base a configurabile affinità sessione.

  • 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 di backend in una singola rete VPC:

Backend di gruppi di istanze e interfacce di rete

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

  • Per i gruppi di istanze gestite, la rete VPC per l'istanza viene definito nel modello di istanza.
  • Per i gruppi di istanze non gestite, la rete VPC per l'istanza il gruppo è definito come la rete VPC utilizzata dall'nic0 dell'interfaccia di rete della prima istanza VM che aggiungi gruppo di istanze gestite.

All'interno di un determinato gruppo di istanze (gestite o non gestite), tutte le istanze VM devono che presentano le interfacce di rete nic0 nella stessa rete VPC. Ogni VM membro può avere facoltativamente interfacce di rete aggiuntive (nic1 fino a nic7), ma ogni interfaccia di rete deve essere collegata a un rete VPC. Queste reti devono inoltre essere diverse Rete VPC associata al gruppo di istanze.

Backend NEG a livello di zona e interfacce di rete

Quando crei un nuovo NEG a livello di zona con GCE_VM_IP endpoint, devi specificare associare il NEG a una subnet di una rete VPC prima di può aggiungere qualsiasi endpoint al NEG. Né la subnet né il VPC la rete può essere modificata dopo la creazione del NEG.

All'interno di un determinato NEG, ogni endpoint GCE_VM_IP rappresenta effettivamente una rete a riga di comando. L'interfaccia di rete deve trovarsi nella subnet associata alla NEG. Dal punto di vista di un'istanza Compute Engine, la rete può utilizzare qualsiasi identificatore (da nic0 a nic7). Dal punto di vista di essere un endpoint in un NEG, l'interfaccia di rete viene identificata utilizzando la sua l'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 indirizzi IP) quando aggiungi un dell'endpoint, Google Cloud richiede che la VM abbia un'interfaccia di rete nella subnet associata al NEG. L'indirizzo IP che Google Cloud per l'endpoint è l'indirizzo IPv4 interno primario della VM nella subnet associata al NEG.
  • Se specifichi sia il nome di una VM sia un indirizzo IP quando aggiungi un endpoint, L'indirizzo IP fornito deve essere un indirizzo IPv4 interno principale per uno dei alle interfacce di rete della VM. L'interfaccia di rete deve trovarsi nella subnet associati al NEG. Tieni presente che specificare un indirizzo IP è ridondante perché può esserci una sola interfaccia di rete nella subnet associati al NEG.

Specifica della rete dei servizi di backend

Puoi associare esplicitamente una rete VPC a un backend usando il flag --network quando crei il servizio di backend. La le regole di rete dei servizi di backend entrano in vigore immediatamente.

Se ometti il flag --network quando crei un servizio di backend, Google Cloud utilizza uno dei seguenti eventi di qualificazione per imposta 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 configurare la prima regola di forwarding per fare riferimento al servizio di backend, Google Cloud imposta il VPC associato al servizio di backend rete VPC che contiene la subnet utilizzata questa regola di forwarding.

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

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

Dopo che la rete VPC del servizio di backend è stata impostata da un qualificato, eventuali regole di forwarding aggiuntive, gruppi di istanza di backend o NEG a livello di zona backend che aggiungi segui le regole di rete dei servizi di backend.

Regole di rete dei servizi di backend

Le seguenti regole si applicano dopo che un servizio di backend è stato associato a un indirizzo Rete VPC:

  • Quando configuri una regola di forwarding per fare riferimento al servizio di backend, la regola di forwarding deve utilizzare una subnet del VPC del servizio di backend in ogni rete. La regola di forwarding e il servizio di backend non possono utilizzare valori diversi le reti VPC, 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 all'istanza ovvero la rete VPC utilizzata dall'nic0 interfaccia di rete di ogni VM nell'istanza deve corrispondere al valore alla rete VPC associata al 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 GCE_VM_IP endpoint, La rete VPC associata al NEG deve corrispondere alla Rete VPC associata al servizio di backend.

Creazione secondaria di backend

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

Abilita l'impostazione secondaria solo se devi supportare più di 250 backend su un singolo bilanciatore del carico. Per ulteriori informazioni, vedi Impostazione secondaria del 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 una regione globale o a livello di regione controllo di integrità. Route speciali al di fuori della 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. La i bilanciatori del carico di rete passthrough interni utilizzano stato del controllo di integrità per determinare come instradare nuove connessioni, come descritto in Distribuzione del traffico.

Puoi utilizzare uno qualsiasi dei seguenti protocolli di controllo di integrità: il protocollo Il controllo di integrità non deve necessariamente corrispondere al protocollo del bilanciatore del carico:

  • HTTP, HTTPS o HTTP/2. Se le tue VM di backend gestiscono il traffico utilizzando HTTP, HTTPS o HTTP/2, è preferibile utilizzare un controllo di integrità che corrisponda perché i controlli di integrità basati su HTTP offrono opzioni appropriate per quel protocollo. Gestire 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, dovrebbe utilizzare Controllo di integrità SSL o TCP.

Indipendentemente dal tipo di controllo di integrità che crei, Google Cloud invia il controllo di integrità verifica l'indirizzo IP dell'inoltro del bilanciatore del carico di rete passthrough interno regolabile, all'interfaccia di rete nella rete VPC selezionata dal carico servizio di backend del bilanciatore del carico. Questo simula il modo in cui il traffico con bilanciamento del carico viene sono recapitate. Il software in esecuzione sulle VM di backend deve rispondere a entrambi probe di traffico e controllo di integrità bilanciati inviati all'IP di ogni regola di forwarding (il software deve rimanere in ascolto su 0.0.0.0:<port> e non su uno specifico indirizzo IP assegnato a un'interfaccia di rete). Per ulteriori informazioni, consulta Destinazione per i pacchetti 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 del client viene eseguito tramite il protocollo UDP, e un servizio TCP è utilizzato per fornire informazioni all'integrità di Google Cloud per controllare i probatori. 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, utilizza la tua logica in esecuzione sulla VM di backend per garantire che restituisce 200 solo se il servizio UDP è configurato e in esecuzione correttamente.

Architettura ad alta disponibilità

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

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

  • Utilizza istanza gestita a livello di regione gruppi se puoi eseguire il deployment del software utilizzando i modelli di istanza. Gestito a livello di regione I gruppi di istanze distribuiscono automaticamente il traffico tra più zone, offrendo l'opzione migliore per evitare potenziali problemi in una determinata zona.

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

Architettura VPC condiviso

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

Indirizzo IP Regola di forwarding Componenti di backend
Un l'indirizzo IP interno deve essere definito 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 progetto. L'indirizzo stesso proviene dall'intervallo IP principale una subnet a cui viene fatto riferimento.

Se crei un indirizzo IP interno in un progetto di servizio e la subnet dell'indirizzo IP si trova nel progetto VPC, il bilanciatore del carico di rete passthrough interno è locale progetto di servizio. Non è locale in nessun progetto host del VPC condiviso.		 Un regola di forwarding deve essere definita nello stesso progetto del backend delle VM in esecuzione.

Affinché il bilanciatore del carico sia disponibile in una rete VPC condiviso, la regola di forwarding interno deve essere definita nello stesso servizio progetto in cui si trovano le VM di backend e deve fare riferimento nella stessa subnet (nella rete VPC condiviso) che come riferimenti agli indirizzi IP interni.

Se crei una regola di forwarding interno in un progetto di servizio e la subnet della regola di forwarding si trova VPC, il bilanciatore del carico di rete passthrough interno è locale progetto di servizio. Non è locale in nessun progetto host del VPC condiviso.		 In uno scenario di VPC condiviso, le VM di backend si trovano in un servizio progetto. R è necessario definire un servizio di backend interno regionale e il controllo di integrità in quel progetto di servizio.

Distribuzione del traffico

Il modo in cui un bilanciatore del carico di rete passthrough interno distribuisce le nuove connessioni dipende da se hai configurato o meno il failover:

  • Se non hai configurato il failover, un bilanciatore del carico di rete passthrough interno distribuisce i nuovi delle connessioni alle rispettive VM di backend integre se è presente almeno una VM di backend integro. Se tutte le VM di backend sono in stato non integro, il bilanciatore del carico distribuisce nuovi delle connessioni tra tutti i backend come ultima risorsa. In questa situazione, il 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 passthrough interno distribuisce i nuovi delle connessioni tra le VM nel pool attivo, secondo un failover che che configuri. Se tutte le VM di backend sono in stato non integro, puoi scegliere una delle seguenti opzioni: i seguenti comportamenti:

    • (Predefinito) Il bilanciatore del carico distribuisce il traffico solo all'istanza principale delle VM. Questa operazione è l'ultima risorsa. Le VM di backup sono escluse da questo la distribuzione delle connessioni.
    • Il bilanciatore del carico è configurato per rilasciare traffico.

Il metodo per la distribuzione di nuove connessioni dipende dalla configurazione impostazione di affinità sessione.

Lo stato del controllo di integrità controlla la distribuzione delle nuove connessioni. Per impostazione predefinita, Le connessioni TCP persistono sui backend in stato non integro. Per ulteriori dettagli e per scoprire come modifica questo comportamento. Consulta Persistenza della connessione in stato non integro di backend.

Selezione del backend e monitoraggio delle connessioni

I bilanciatori del carico di rete passthrough interni utilizzano la selezione e la connessione del backend configurabili algoritmi di monitoraggio 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 le caratteristiche di un pacchetto in entrata, quest'ultimo viene inviato al backend specificato dalla voce della tabella per il monitoraggio delle connessioni. Il pacchetto viene considerato far parte di una connessione stabilita in precedenza, quindi il pacchetto viene inviato di backend che il bilanciatore del carico ha precedentemente determinato e registrato nella sua tabella di monitoraggio della connessione.

  2. Se il bilanciatore del carico riceve un pacchetto per cui non ha connessione di monitoraggio, il bilanciatore del carico esegue le seguenti operazioni:

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

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

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

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

    2. Il bilanciatore del carico aggiunge una voce alla propria tabella di monitoraggio delle connessioni. Questo registra il backend selezionato per la connessione del pacchetto, e i futuri pacchetti di questa connessione vengono inviati allo stesso backend. Indica se il monitoraggio della connessione utilizzato dipende dal protocollo:

      Per i pacchetti TCP e UDP, il monitoraggio della connessione è sempre abilitato e non può la disattivazione dell'accesso. Per impostazione predefinita, il monitoraggio delle connessioni è a 5 tuple, ma può essere configurato in modo da essere inferiore a 5 tuple.

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

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

      • la modalità di monitoraggio è PER_CONNECTION (tutte le affinità delle sessioni) 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.

      Per ulteriori dettagli su quando il monitoraggio delle connessioni è abilitato e quale metodo di monitoraggio viene utilizzato quando il monitoraggio della connessione è attivato; consulta modalità di monitoraggio della connessione.

      Inoltre, tieni presente quanto segue:

      • Per impostazione predefinita, una voce nella tabella di monitoraggio delle connessioni scade 600 secondi Dopo che il bilanciatore del carico elabora l'ultimo pacchetto corrispondente alla voce. Per maggiori dettagli su come personalizzare il timeout per inattività, vedi Inattività timeout.
      • A seconda del protocollo, il bilanciatore del carico potrebbe rimuovere la connessione delle voci della tabella di monitoraggio quando i backend sono in stato non integro. Per maggiori dettagli e per sapere come personalizzare questo comportamento, consulta Connessione persistenza su 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 il backend Le VM devono tenere traccia delle informazioni sullo stato per i loro client. Si tratta di un metodo requisito 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 specifichi per l'intero servizio di backend interno, non per ogni istanza di backend. gruppo.

  • Nessuno (NONE). Hash a 5 tuple di indirizzo IP di origine, porta di origine, protocollo l'indirizzo IP di destinazione e la 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 due tuple dell'indirizzo IP di origine e della destinazione Indirizzo IP. 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 del pacchetto deve corrispondere all'indirizzo IP del bilanciatore del carico una regola di forwarding per inviare il pacchetto al bilanciatore del carico. Per considerazioni sull'utilizzo del bilanciatore del carico come hop successivo per una route, Bilanciatore del carico di rete passthrough interno di affinità sessione e hop successivo.

Bilanciatore del carico di rete passthrough interno per affinità sessione e hop successivo

Quando si utilizza un bilanciatore del carico di rete passthrough interno come hop successivo per una di routing, la destinazione del pacchetto molto probabilmente non è l'indirizzo IP del carico la regola di forwarding del bilanciatore.

Un pacchetto viene consegnato al bilanciatore del carico se la destinazione del pacchetto è adatta all'interno della destinazione della route statica personalizzata percorso applicabile.

Tutte le opzioni di affinità sessione tranne IP client, nessuna destinazione utilizzano il valore Indirizzo IP di destinazione del pacchetto. Quando utilizzi una route statica personalizzata la cui successiva hop è un bilanciatore del carico di rete passthrough interno:

  • Se il bilanciatore del carico ha un solo backend (il suo pool attivo, se configurato, tutte le opzioni di affinità sessione scelgono il backend in questione. La scelta dell'affinità sessione non fa differenza quando è presente un singolo backend (nel pool attivo).

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

  • Se devi assicurarti che lo stesso backend elabori tutti i pacchetti inviati dallo stesso client a qualsiasi indirizzo IP nella destinazione della route, devi utilizzare 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 tracciato sempre per 5 tuple, indipendentemente dall'impostazione di affinità sessione. Ciò implica che la chiave per il monitoraggio della connessione (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 può essere suddivisa nuove connessioni per una sessione possono selezionare un backend diverso se l'insieme i backend o le modifiche di integrità.

  • PER_SESSION. In questa modalità, il traffico TCP e UDP viene monitorato in base a l'affinità sessione configurata. Vale a dire, se l'affinità sessione è CLIENT_IP o CLIENT_IP_PROTO, la configurazione di questa modalità genera in due tuple e Monitoraggio della connessione a 3 tuple, rispettivamente. Ciò potrebbe essere utile in scenari in cui interrompere l'affinità è costoso e andrebbe evitato anche dopo aver aggiunto 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 sul funzionamento di queste modalità di rilevamento impostazioni di affinità sessione diverse per ogni protocollo, consulta la tabella seguente.

Selezione del backend Modalità di monitoraggio delle connessioni
Impostazione di affinità sessione Metodo di 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 tupla Monitoraggio della connessione a 5 tuple Monitoraggio connessione a 1 tupla

IP client

CLIENT_IP

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

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

IP client, IP di destinazione, protocollo

CLIENT_IP_PROTO

 Hash a 3 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 informazioni su come modificare la modalità di monitoraggio della connessione, consulta Configurare una monitoraggio della connessione .

Persistenza della connessione su backend in stato non integro

La persistenza della connessione sui backend in stato non integro controlla se la connessione esistente persiste su un backend selezionato dopo che questo diventa in stato non integro (purché il backend rimanga nell'account configurato nel bilanciatore del carico) gruppo di istanza di backend).

Il comportamento descritto in questa sezione non si applica ai casi in cui rimuovi una VM di backend dal relativo gruppo di istanze oppure rimuovi il gruppo di istanze del servizio di backend. In questi casi, le connessioni stabilite rimangono valide descritto in Attivazione della connessione drenaggio.

Sono disponibili le seguenti opzioni di persistenza della connessione:

  • DEFAULT_FOR_PROTOCOL (valore predefinito)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

La tabella seguente riassume le opzioni di persistenza della connessione e come le connessioni persistono per diversi protocolli, le opzioni di affinità sessione e di rilevamento delle immagini.

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

TCP: le connessioni vengono mantenute su backend in stato non integro (tutte affinità sessione)

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

TCP: le connessioni persistono su backend in stato non integro se 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 in stato non integro backend (tutte le affinità delle sessioni)

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

 Configurazione non possibile

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

Timeout di inattività

Per impostazione predefinita, una voce nella tabella di monitoraggio delle connessioni scade 600 secondi dopo il bilanciatore del carico elabora l'ultimo pacchetto corrispondente alla voce. Questo Il valore predefinito di timeout di inattività può essere modificato solo se il monitoraggio della connessione è meno di 5 tuple (ossia, quando l'affinità sessione è configurata per essere CLIENT_IP o CLIENT_IP_PROTO e la modalità di rilevamento è PER_SESSION).

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

Per informazioni su come modificare il valore di timeout di inattività, consulta Configurare un monitoraggio della connessione .

Test delle connessioni da un singolo client

Durante il test delle connessioni all'indirizzo IP di un bilanciatore del carico di rete passthrough interno da un unico sistema client, è importante tenere presente quanto segue:

  • Se il sistema client non è una VM in fase di bilanciamento del carico, ovvero di backend, le nuove connessioni vengono consegnate all'integrità del bilanciatore del carico di backend. Tuttavia, poiché tutte le opzioni di affinità sessione si basano almeno sull'indirizzo IP del sistema client e sulle connessioni potrebbe essere distribuito sulla stessa VM di backend con una frequenza maggiore ci si potrebbe aspettare.

    In pratica, ciò significa che non è possibile monitorare accuratamente il traffico distribuzione tramite un bilanciatore del carico di rete passthrough interno connettendosi da un di alto profilo. Il numero di client necessario per monitorare la distribuzione del traffico varia a seconda del tipo di bilanciatore del carico, del tipo di traffico e del numero di backend integre.

  • Se la VM client è una VM di backend del bilanciatore del carico, le connessioni inviate a gli indirizzi IP della regola di forwarding del bilanciatore del carico ricevono sempre risposta dalla una VM client/di backend. Ciò si verifica indipendentemente dal fatto che la VM di backend sia integro. Succede per tutto il traffico inviato all'indirizzo IP del bilanciatore del carico, non per solo il traffico sul protocollo e sulle porte specificate nell'interfaccia di una regola di forwarding.

    Per ulteriori informazioni, vedi di richieste da VM con bilanciamento del carico.

Frammentazione UDP

I bilanciatori del carico di rete passthrough interni possono elaborare UDP frammentato e non frammentato e pacchetti. Se l'applicazione utilizza pacchetti UDP frammentati, mantieni quanto segue mente:
  • I pacchetti UDP potrebbero diventare frammentati prima di raggiungere un server Google Cloud rete VPC.
  • Le reti VPC di Google Cloud inoltrano i frammenti UDP quando vengono arrivino (senza attendere l'arrivo di tutti i frammenti).
  • Le reti non Google Cloud e le apparecchiature di rete on-premise inoltrare i frammenti UDP all'arrivo, ritardare i pacchetti UDP frammentati finché tutti i frammenti sono arrivati o scarta i pacchetti UDP frammentati. Per maggiori dettagli, consultare la documentazione del provider di rete o dell'apparecchiatura di rete.

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

  • Configurazione della regola di forwarding: utilizza un solo UDP regola di forwarding per indirizzo IP con bilanciamento del carico e configura per accettare il traffico su tutte le porte. Questo assicura che tutti i frammenti arrivino la stessa regola di forwarding. Anche se i pacchetti frammentati (diversi dai primo frammento) non è presente una porta di destinazione, configurando la regola di forwarding il traffico di processo per tutte le porte lo configura anche per ricevere i frammenti UDP che senza informazioni sulle porte. Per configurare tutte le porte, utilizza Google Cloud CLI per impostare --ports=ALL o utilizzare l'API per impostare allPorts su True.

  • Configurazione del servizio di backend: imposta la sessione del servizio di backend affinità a CLIENT_IP (hash a 2 tuple) o CLIENT_IP_PROTO (hash a 3 tuple) per selezionare lo stesso backend per UDP e pacchetti che includono informazioni sulle porte e frammenti UDP (diversi dal primo di codice) senza informazioni sulle porte. Imposta la connessione del servizio di backend modalità di rilevamento su PER_SESSION, in modo che la connessione le voci della tabella di monitoraggio vengono 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 failover di backend. Questi backend vengono utilizzati solo quando il numero di VM integre gruppi di istanza di backend primarie sono scesi al di sotto di una soglia configurabile. Per impostazione predefinita, se tutte le VM primarie e di failover sono in stato non integro, come ultima risorsa Google Cloud distribuisce le nuove connessioni solo tra tutte le VM principali.

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

Per una panoramica concettuale dettagliata del failover nei bilanciatori del carico di rete passthrough interni, consulta Failover per 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 creare un bilanciatore del carico di rete passthrough interno con Backend del NEG.

Passaggi successivi