I bilanciatori del carico di rete passthrough esterni sono bilanciatori del carico a livello di regione e di livello 4 che distribuiscono traffico esterno tra i backend (gruppi di istanze o gruppi di endpoint di rete (NEG)) nella stessa regione del bilanciatore del carico. Questi backend devono trovarsi la stessa regione e lo stesso progetto, ma possono trovarsi in reti VPC diverse. Questi bilanciatori del carico si basano Maglev e la virtualizzazione della rete Andromeda stack.
I bilanciatori del carico di rete passthrough esterni possono ricevere traffico da:
- Qualsiasi client su internet
- VM Google Cloud con IP esterni
- VM di Google Cloud che hanno accesso a internet tramite Cloud NAT o NAT basato su istanza
I bilanciatori del carico di rete passthrough esterni non sono proxy. Il bilanciatore del carico in sé e terminare le connessioni utente. I pacchetti con bilanciamento del carico vengono inviati alle VM di backend con i relativi indirizzi IP di origine e di destinazione, il protocollo e, se applicabile, senza modifiche. Le VM di backend quindi terminano le connessioni utente. Risposte dalle VM di backend passano direttamente ai client, non attraverso il carico con il bilanciatore del carico di rete passthrough esterno regionale. Questa procedura è nota come Direct Server Return (DSR).
I bilanciatori del carico di rete passthrough esterni basati sul servizio di backend supportano le seguenti funzionalità:
- Backend di gruppi di istanze gestite e non gestite. In base al servizio di backend i bilanciatori del carico di rete passthrough esterni supportano gruppi di istanze gestite e non gestite come backend. I gruppi di istanze gestite automatizzano determinati aspetti del backend per la gestione e forniscono una migliore scalabilità e affidabilità rispetto gruppi di istanze non gestite.
- Backend NEG a livello di zona. In base al servizio di backend
i bilanciatori del carico di rete passthrough esterni supportano l'utilizzo di NEG a livello di zona con endpoint
GCE_VM_IP
. Gli endpoint NEGGCE_VM_IP
di zona ti consentono di:- Inoltra i pacchetti a qualsiasi interfaccia di rete, non solo a
nic0
. - Posiziona lo stesso endpoint
GCE_VM_IP
in due o più NEG di zona connessi servizi di backend diversi.
- Inoltra i pacchetti a qualsiasi interfaccia di rete, non solo a
- Supporto di più protocolli. Bilanciatori del carico di rete passthrough esterni basati sul servizio di backend può bilanciare il carico TCP, UDP, ESP, GRE, ICMP e ICMPv6 per via del traffico.
- Supporto per la connettività IPv6. In base al servizio di backend i bilanciatori del carico di rete passthrough esterni possono gestire il traffico IPv4 e IPv6.
- Controllo granulare della distribuzione del traffico. Un servizio di backend consente traffico da distribuire in base a un modello configurabile affinità sessione, connessione modalità di monitoraggio e bilanciamento del carico ponderato. Il servizio di backend può anche essere configurato per abilitare lo svuotamento della connessione designare i backend di failover per il bilanciatore del carico. La maggior parte di queste impostazioni hanno valori predefiniti che ti consentono di iniziare rapidamente.
- Supporto per controlli di integrità non legacy. Bilanciatori del carico di rete passthrough esterni basati sul servizio di backend consente di utilizzare controlli di integrità corrispondenti al tipo di traffico (TCP, SSL, HTTP, HTTPS o HTTP/2) che distribuisce.
- Integrazione di Google Cloud Armor. Google Cloud Armor supporta reti avanzate Protezione DDoS per i bilanciatori del carico di rete passthrough esterni. Per ulteriori informazioni, vedi Configura protezione DDoS di rete avanzata.
Integrazione di GKE. Se crei applicazioni in GKE, ti consigliamo di utilizzare il servizio GKE integrato un controller, che esegue il deployment Bilanciatori del carico di Google Cloud per conto di utenti GKE. Questo è la stessa dell'architettura di bilanciamento del carico autonoma descritta in di pagina, ma il ciclo di vita è completamente automatizzato e controllato con GKE.
Documentazione GKE correlata:
Architettura
Il seguente diagramma illustra i componenti di un bilanciatore del carico di rete passthrough esterno:
Il bilanciatore del carico è composto da diversi componenti di configurazione. Un singolo bilanciatore del carico può avere i seguenti componenti:
- Uno o più indirizzi IP esterni a livello di regione
- Una o più regole di forwarding esterno a livello di regione
- Un servizio di backend esterno a livello di regione
- Uno o più backend: tutti i gruppi di istanze o tutti i backend NEG a livello di zona
(
GCE_VM_IP
endpoint) - Controllo di integrità associato al servizio di backend
Inoltre, devi creare regole firewall che consentano il bilanciamento del carico probe di traffico e controllo di integrità per raggiungere le VM di backend.
Indirizzo IP
Un bilanciatore del carico di rete passthrough esterno richiede almeno una regola di forwarding. La regola di forwarding fa riferimento a un indirizzo IP esterno regionale accessibile ovunque internet.
- Per il traffico IPv4, la regola di forwarding fa riferimento a una singola regione indirizzo IPv4 esterno. IPv4 esterno a livello di regione provengono da un pool univoco per ogni regione Google Cloud. L'IP di un indirizzo può essere un statico riservato o un temporaneo.
Per il traffico IPv6, la regola di forwarding fa riferimento a un intervallo
/96
da un una subnet a doppio stack con un intervallo di subnet IPv6 esterne nel VPC in ogni rete. Gli indirizzi IPv6 esterni sono disponibili solo nel livello Premium. Il protocollo IPv6 di indirizzi possono essere statici riservati o un temporaneo.
Utilizza un indirizzo IP riservato per la regola di forwarding se devi mantenere il associato al tuo progetto per il riutilizzo dopo l'eliminazione di un o se hai bisogno di più regole di forwarding che facciano riferimento allo stesso indirizzo IP.
I bilanciatori del carico di rete passthrough esterni supportano sia il livello Standard che il livello Premium per gli indirizzi IPv4 esterni a livello di regione. Sia l'indirizzo IP che il server deve usare lo stesso livello di rete. Gli indirizzi IPv6 esterni a livello di regione sono disponibile nel livello Premium.
Regola di forwarding
Una regola di forwarding esterno a livello di regione specifica il protocollo e le porte su cui il bilanciatore del carico accetta il traffico. Poiché i bilanciatori del carico di rete passthrough esterni non sono proxy, passano il traffico ai backend sullo stesso protocollo e sulle stesse porte, se il pacchetto trasporta informazioni sulle porte. La regola di forwarding in combinazione con l'indirizzo IP costituisce il frontend del bilanciatore del carico.
Il bilanciatore del carico conserva gli indirizzi IP di origine dei pacchetti in entrata. La l'indirizzo IP di destinazione per i pacchetti in entrata è un indirizzo IP associato a: la regola di forwarding del bilanciatore del carico.
Il traffico in entrata viene abbinato a una regola di forwarding, che è una combinazione di un particolare indirizzo IP (un indirizzo IPv4 o un intervallo di indirizzi IPv6), e, se il protocollo è basato su porta, una delle porte, un intervallo di porte oppure tutte le porte. La regola di forwarding indirizza quindi il traffico agli di servizio di backend.
Se la regola di forwarding fa riferimento a un indirizzo IPv4, non viene associate a qualsiasi subnet. Vale a dire che il suo indirizzo IP proviene dall'esterno di nell'intervallo di subnet Google Cloud.
Se la regola di forwarding fa riferimento a un intervallo di indirizzi IPv6
/96
, il protocollo deve essere associata a una subnet e questa subnet deve essere (a) a doppio stack e (b) avere un intervallo di subnet IPv6 esterno (--ipv6-access-type
impostato suEXTERNAL
). La subnet a cui la regola di forwarding fa riferimento può essere la stessa alla subnet utilizzata dalle istanze di backend; ma le istanze di backend possono utilizzare una subnet separata, se scelta. Quando le istanze di backend utilizzano una subnet separata, deve essere vero:
Un bilanciatore del carico di rete passthrough esterno richiede almeno una regola di forwarding. Le regole di forwarding possono essere configurate per indirizzare il traffico proveniente da un intervallo specifico di indirizzi IP di origine. a uno specifico servizio di backend (o istanza di destinazione). Per i dettagli, consulta Informazioni sul traffico sterzo. Puoi definire più regole di forwarding per lo stesso bilanciatore del carico, come descritto in Più regole regole di forwarding.
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.
Protocolli delle regole di forwarding
I bilanciatori del carico di rete passthrough esterni supportano le seguenti opzioni di protocollo per ciascuno
regola di forwarding: TCP
, UDP
e L3_DEFAULT
.
Utilizza le opzioni TCP
e UDP
per configurare il bilanciamento del carico TCP o UDP.
L'opzione del protocollo L3_DEFAULT
consente a un bilanciatore del carico di rete passthrough esterno di
bilanciamento del carico
TCP, UDP, ESP, GRE, ICMP e ICMPv6
per via del traffico.
Oltre a supportare protocolli diversi da TCP e UDP, L3_DEFAULT
offre
è possibile che una singola regola di forwarding gestisca più protocolli. Per
Ad esempio, i servizi IPsec gestiscono tipicamente una combinazione di ESP e
Traffico IKE e NAT-T basato su UDP. L'opzione L3_DEFAULT
consente a una singola
configurare una regola di forwarding
in modo da elaborare tutti questi protocolli.
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
servizio il cui protocollo è UNSPECIFIED
.
L3_DEFAULT
regole di forwarding possono solo
Fare riferimento a un servizio di backend con protocollo UNSPECIFIED
.
Se utilizzi il protocollo L3_DEFAULT
, devi configurare l'inoltro
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 | TCP |
TCP o UNSPECIFIED |
L3_DEFAULT |
UNSPECIFIED |
|
UDP | UDP |
UDP o UNSPECIFIED |
L3_DEFAULT |
UNSPECIFIED |
|
ESP, GRE, ICMP/ICMPv6 (solo richiesta echo) | L3_DEFAULT |
UNSPECIFIED |
Più regole di forwarding
Puoi configurare più regole di forwarding esterno a livello di regione per lo stesso un bilanciatore del carico di rete passthrough esterno. Ogni regola di forwarding può avere una diversa regione L'indirizzo IP o più regole di forwarding possono avere lo stesso IP esterno a livello di regione .
Può essere utile configurare più regole di forwarding esterno a livello di regione per questi casi d'uso:
- Devi configurare più di un indirizzo IP esterno per lo stesso backend completamente gestito di Google Cloud.
- Devi configurare protocolli diversi oppure porte o porte non sovrapposte per lo stesso indirizzo IP esterno.
- Devi indirizzare il traffico da determinati indirizzi IP di origine a un carico specifico dei bilanciatori del carico.
Google Cloud richiede che i pacchetti in entrata corrispondano a non più di uno di una regola di forwarding. Ad eccezione delle regole di forwarding, che vengono discusse nel nella sezione successiva, due o più regole di forwarding che usano le stesse l'indirizzo IP esterno deve avere combinazioni univoche di protocollo e porta, in base questi vincoli:
- Una regola di forwarding configurata per tutte le porte di un protocollo impedisce
Creazione di altre regole di forwarding utilizzando lo stesso protocollo e indirizzo IP.
È possibile configurare regole di forwarding che utilizzano i protocolli
TCP
oUDP
in modo da utilizzare tutte o possono essere configurate per porte specifiche. Ad esempio, se crea una regola di forwarding utilizzando l'indirizzo IP198.51.100.1
, il protocolloTCP
, e tutte le porte, non puoi creare altre regola di forwarding utilizzando l'indirizzo IP198.51.100.1
e il protocolloTCP
. Puoi creare due regole di forwarding, entrambe utilizzando l'indirizzo IP198.51.100.1
e il protocolloTCP
, se ciascuno ha porte univoche o porta non sovrapposta intervalli di tempo. Ad esempio, puoi creare due regole di forwarding utilizzando l'indirizzo IP198.51.100.1
e il protocollo TCP, dove le porte di una regola di forwarding sono80,443
e l'altro utilizza l'intervallo di porte81-442
. - È possibile creare una sola regola di forwarding
L3_DEFAULT
per indirizzo IP. Questo è che il protocolloL3_DEFAULT
utilizza tutte le porte per definizione. In questo Nel contesto, il termine "tutte le porte" include i protocolli senza informazioni sulle porte. Una singola regola di forwarding
L3_DEFAULT
può coesistere con altri tipi di forwarding regole che usano protocolli specifici (TCP
oUDP
).L3_DEFAULT
può essere utilizzata come ultima risorsa quando le regole di forwarding utilizzano allo stesso indirizzo IP, ma esistono protocolli più specifici. Un inoltroL3_DEFAULT
elabora i pacchetti inviati all'indirizzo IP di destinazione se e solo se indirizzo IP di destinazione, protocollo e porta di destinazione del pacchetto non corrispondono una regola di forwarding specifica per il protocollo.Per illustrare questo aspetto, considera questi due scenari. Inoltro in entrambi gli scenari utilizzano lo stesso indirizzo IP
198.51.100.1
.- Scenario 1. La prima regola di forwarding utilizza il protocollo
L3_DEFAULT
. La seconda regola di forwarding utilizza il protocolloTCP
e tutte le porte. I pacchetti TCP inviati a qualsiasi porta di destinazione di198.51.100.1
vengono elaborati la seconda regola di forwarding. I pacchetti che utilizzano protocolli diversi vengono elaborati dalla prima regola di forwarding. - Scenario 2. La prima regola di forwarding utilizza il protocollo
L3_DEFAULT
. La seconda regola di forwarding utilizza il protocolloTCP
e la porta 8080. TCP i pacchetti inviati a198.51.100.1:8080
vengono elaborati al secondo di una regola di forwarding. Tutti gli altri pacchetti, compresi quelli TCP inviati diverse porte di destinazione, vengono elaborate dalla prima regola di forwarding.
- Scenario 1. La prima regola di forwarding utilizza il protocollo
Selezione regola di forwarding
Google Cloud seleziona una o nessuna regola di forwarding per elaborare un messaggio in entrata pacchetto utilizzando questo processo di eliminazione, a partire dalla serie di dati regola candidati che corrispondono all'indirizzo IP di destinazione del pacchetto:
Elimina le regole di forwarding il cui protocollo non corrisponde al protocollo del pacchetto, tranne
L3_DEFAULT
regole di forwarding. Le regole di forwarding utilizzandoL3_DEFAULT
non viene mai eliminato con questo passaggio perchéL3_DEFAULT
corrisponde a tutti i protocolli. Ad esempio, se il protocollo del pacchetto è TCP, le regole di forwarding che utilizzano il protocolloUDP
vengono eliminate.Elimina le regole di forwarding la cui porta non corrisponde alla porta del pacchetto. Le regole di forwarding configurate per tutte le porte non vengono mai eliminate con questo passaggio perché una regola di forwarding per tutte le porte corrisponde a qualsiasi porta.
Se le altre regola di forwarding candidati includono sia
L3_DEFAULT
che regole di forwarding specifiche per il protocollo, eliminaL3_DEFAULT
di forwarding le regole del caso. Se le altre regola di forwarding candidati sono tutteL3_DEFAULT
di forwarding, nessuna viene eliminata in questo passaggio.A questo punto, le altre regola di forwarding candidati rientrano in una delle seguenti categorie:
- Rimane un'unica regola di forwarding che corrisponde all'IP di destinazione del pacchetto indirizzo IP, protocollo e porta e viene utilizzato per instradare il pacchetto.
- Restano due o più opzioni candidati per la regola di forwarding che corrispondono l'indirizzo IP, il protocollo e la porta di destinazione. Ciò significa che i restanti le regola di forwarding candidati includono l'indirizzamento di regole di forwarding (discusse nella prossima sezione). Seleziona il regola di forwarding di reindirizzamento il cui intervallo source include il maggior numero CIDR specifico (corrispondenza prefisso più lungo) contenente l'IP di origine del pacchetto . Se nessuna regola di forwarding di reindirizzamento ha un intervallo di origine che include il parametro all'indirizzo IP di origine del pacchetto, seleziona la regola di forwarding padre.
- Nessuna regola di forwarding candidato rimanente e il pacchetto viene eliminato.
Se utilizzi più regole di forwarding, assicurati di configurare il software in esecuzione sulle VM di backend in modo che si colleghi a tutti gli indirizzi IP esterni delle regola di forwarding del bilanciatore del carico.
Direzione del traffico
Le regole di forwarding per i bilanciatori del carico di rete passthrough esterni possono essere configurate in modo da indirizzare il traffico provenienti da un intervallo specifico di indirizzi IP di origine a un backend specifico (o istanza di destinazione).
La direzione del traffico è utile per la risoluzione dei problemi e per le configurazioni avanzate. Con l'indirizzamento del traffico, puoi indirizzare determinati clienti a un insieme diverso e/o una configurazione del servizio di backend diversa. Ad esempio:
- L'indirizzamento del traffico consente di creare due regole di forwarding che indirizzano il traffico lo stesso backend (gruppo di istanze o NEG) mediante due servizi di backend. I due e i servizi di backend possono essere configurati con controlli di integrità diversi, affinità di sessione o criteri di controllo della distribuzione del traffico diversi (monitoraggio della connessione, svuotamento della connessione e failover).
- L'indirizzamento del traffico consente di creare una regola di forwarding per reindirizzare il traffico da un da un servizio di backend a bassa larghezza di banda a un servizio di backend a larghezza di banda elevata. Entrambi i servizi di backend contengono lo stesso insieme di VM o endpoint di backend, ma bilanciato il carico con pesi diversi utilizzando il carico ponderato bilanciato.
- L'indirizzamento del traffico consente di creare due regole di forwarding che indirizzano il traffico servizi di backend diversi, con backend diversi (gruppi di istanze o NEG). Ad esempio, un backend potrebbe essere configurato utilizzando tipi di macchine diversi in in modo da elaborare meglio il traffico da un determinato insieme di indirizzi IP di origine.
L'indirizzamento del traffico è configurato con un parametro API della regola di forwarding chiamato
sourceIPRanges
. Regole di forwarding con almeno un intervallo IP di origine
sono dette regole di forwarding.
Una regola di forwarding di reindirizzamento può avere un elenco di massimo 64 intervalli IP di origine. Puoi aggiorna l'elenco degli intervalli IP di origine configurati per una regola di forwarding di reindirizzamento all'indirizzo in qualsiasi momento.
Ogni regola di forwarding di reindirizzamento richiede la creazione di un account padre di una regola di forwarding. Le regole di forwarding padre e di reindirizzamento condividono lo stesso indirizzo IP esterno a livello di regione, lo stesso protocollo e le stesse informazioni sulla porta; ma la regola di forwarding padre non ha informazioni sull'indirizzo IP di origine. Ad esempio:
- Regola di forwarding padre: indirizzo IP:
198.51.100.1
, protocollo IP:TCP
, porte: 80 - Regola di forwarding di reindirizzamento: indirizzo IP:
198.51.100.1
, protocollo IP:TCP
, porte: 80, intervalli IPdi origine:203.0.113.0/24
È possibile associare una regola di forwarding padre che punta a un servizio di backend una regola di forwarding di reindirizzamento che punta a un servizio di backend o a una destinazione in esecuzione in un'istanza Compute Engine.
Per una determinata regola di forwarding padre, possono essere presenti due o più regole di forwarding di reindirizzamento
avere intervalli IP di origine sovrapposti ma non identici. Ad esempio, uno
la regola di forwarding di reindirizzamento può avere l'intervallo IP di origine 203.0.113.0/24
e
un'altra regola di forwarding di reindirizzamento per lo stesso padre può avere l'IP di origine
intervallo 203.0.113.0
.
Devi eliminare tutte le regole di forwarding di reindirizzamento prima di poter eliminare l'elemento principale da cui dipendono.
Scopri come vengono elaborati i pacchetti in entrata quando vengono applicate le regole di forwarding di reindirizzamento. utilizzata, consulta Selezione delle regole di forwarding.
Comportamento dell'affinità sessione nelle modifiche di orientamento
Questa sezione descrive le condizioni in cui l'affinità sessione potrebbe interrompersi quando vengono aggiornati gli intervalli IP di origine per le regole di forwarding di reindirizzamento:
- Se una connessione esistente continua a corrispondere alla stessa regola di forwarding dopo gli intervalli IP di origine per una regola di forwarding di reindirizzamento, sessione l'affinità non si interrompe. Se la modifica determina una connessione esistente corrisponde a un'altra regola di forwarding,
- L'affinità sessione si interrompe sempre nelle seguenti circostanze:
- .
- La regola di forwarding appena abbinata indirizza una connessione stabilita a un di servizio di backend (o istanza di destinazione) che non fa riferimento una VM di backend selezionata in precedenza.
- La regola di forwarding appena abbinata indirizza una connessione stabilita a un che fa riferimento alla VM di backend selezionata in precedenza, ma il servizio di backend non è configurato per mantenere connessioni persistenti quando di backend non integro, e la VM di backend non supera il controllo di integrità del servizio di backend.
- L'affinità sessione potrebbe interrompersi quando la regola di forwarding con nuova corrispondenza indirizza una connessione stabilita a un servizio di backend, servizio di backend fa riferimento alla VM selezionata in precedenza, combinazione di affinità sessione e connessione del servizio di backend modalità di monitoraggio determina un hash di monitoraggio delle connessioni diverso.
Conservare l'affinità sessione tra i cambiamenti di orientamento
Questa sezione descrive come evitare di interrompere l'affinità sessione quando vengono aggiornati gli intervalli IP di origine per le regole di forwarding di reindirizzamento:
- Indirizzamento di regole di forwarding che puntano ai servizi di backend. Se entrambi gli elementi principali e la regola di forwarding di reindirizzamento punta ai servizi di backend, dovrai assicurati manualmente che i valori di affinità sessione Le impostazioni dei criteri di monitoraggio della connessione sono identiche. Google Cloud non rifiuta automaticamente le configurazioni se sono non identici.
- Indirizzamento di regole di forwarding che puntano alle istanze di destinazione. Un genitore una regola di forwarding che punta a un servizio di backend può essere associata una regola di forwarding di reindirizzamento che punta a un'istanza di destinazione. In questo caso, la regola di forwarding di reindirizzamento eredita l'affinità sessione e le impostazioni dei criteri di monitoraggio della connessione una regola di forwarding padre.
Per istruzioni su come configurare l'indirizzamento del traffico, consulta Configurare il traffico sterzo.
Servizio di backend regionale
Ogni bilanciatore del carico di rete passthrough esterno ha un servizio di backend regionale che definisce il comportamento del bilanciatore del carico e come il traffico viene distribuito di backend. Il nome del servizio di backend è il nome del bilanciatore del carico di rete passthrough esterno mostrato nella console Google Cloud.
Ogni servizio di backend definisce i seguenti parametri di backend:
Protocollo. Un servizio di backend accetta il traffico sull'indirizzo IP e sulle porte (se configurato) specificato da una o più regole di forwarding esterno a livello di regione. Il servizio di backend passa i pacchetti alle VM di backend preservando gli indirizzi IP di origine e di destinazione, il protocollo e se il protocollo è basato su porta, ovvero le porte di origine e di destinazione.
I servizi di backend utilizzati con bilanciatori del carico di rete passthrough esterni supportano il seguente protocollo opzioni:
TCP
,UDP
oUNSPECIFIED
.I servizi di backend con il protocollo
UNSPECIFIED
possono essere utilizzati con qualsiasi a prescindere dal protocollo della regola di forwarding. Servizi di backend con un protocollo specifico (TCP
oUDP
) è possibile fare riferimento solo tramite inoltro regole con lo stesso protocollo (TCP
oUDP
). Le regole di forwarding con Il protocolloL3_DEFAULT
può fare riferimento solo ai servizi di backend con ilUNSPECIFIED
.Consulta la specifica del protocollo delle regole di forwarding per una tabella con possibili combinazioni di regola di forwarding e protocolli del servizio di backend.
Distribuzione del traffico. Un servizio di backend consente traffico da distribuire in base a un modello configurabile affinità sessione, connessione modalità di monitoraggio e bilanciamento del carico ponderato. Il servizio di backend può anche essere configurato per abilitare lo svuotamento della connessione designare i backend di failover per il bilanciatore del carico.
Controllo di integrità. Un servizio di backend deve essere associato a un stato di integrità regionale controllo.
Backend: ogni servizio di backend opera in una singola regione e distribuisce il traffico verso gruppi di istanze o NEG a livello di zona nella stessa regione. Puoi utilizzano gruppi di istanze o NEG a livello di zona, ma non una combinazione di entrambi, poiché per un bilanciatore del carico di rete passthrough esterno:
- Se scegli gruppi di istanze, puoi utilizzare modelli non gestiti gruppi di istanze, gruppi di istanze gestite a livello di zona, istanze gestite a livello di regione gruppi di istanze gestite o 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.
A ogni gruppo di istanze o backend NEG è associato un VPC anche se il gruppo di istanze o il NEG non è stato connesso a un backend Google Cloud. Per ulteriori informazioni su come una rete viene associata a ogni tipo di backend, consulta Backend e rete di gruppi di istanze interfacce e backend e interfacce di rete NEG a livello di zona.
Gruppi di istanze
Un bilanciatore del carico di rete passthrough esterno distribuisce le connessioni tra le VM backend contenute all'interno gruppi di istanze gestite o non gestite. I gruppi di istanze possono essere a livello di regione o zona nell'ambito di applicazione.
Un bilanciatore del carico di rete passthrough esterno distribuisce il traffico solo alla prima interfaccia di rete (nic0
)
delle VM di backend. Il bilanciatore del carico supporta i gruppi di istanze il cui membro
utilizzano qualsiasi rete VPC nella stessa regione, purché la rete VPC sia
nello stesso progetto
del servizio di backend. (tutte le VM all'interno di una determinata istanza)
deve usare la stessa rete VPC).
A ogni gruppo di istanze è associata una rete VPC, anche se gruppo di istanze non è stato ancora connesso a un servizio di backend. Per ulteriori informazioni informazioni su come una rete viene associata ai gruppi di istanze, consulta Backend di gruppi di istanze e interfacce di rete.
Gruppi di istanze gestite a livello di regione. Utilizza i gruppi di istanze gestite a livello di regione se puoi eseguire il deployment del tuo software utilizzando i modelli di istanza. Gestito a livello di regione I gruppi di istanze distribuiscono automaticamente il traffico tra più zone, l'opzione migliore per evitare potenziali problemi in una determinata zona.
Qui viene mostrato un esempio di deployment mediante un gruppo di istanze gestite a livello di regione. Il gruppo di istanze ha un modello di istanza che definisce il modo in cui le istanze devono e ogni gruppo esegue il deployment delle istanze all'interno di tre zone Regione
us-central1
.Gruppi di istanze gestite o non gestite a livello di zona. Utilizza i gruppi di istanze a livello di zona zone diverse (nella stessa regione) per proteggerti da potenziali problemi in qualsiasi una data zona.
Qui è mostrato un esempio di deployment che utilizza gruppi di istanze a livello di zona. Questo caricamento fornisce disponibilità tra due zone.
NEG a livello di zona
Un bilanciatore del carico di rete passthrough esterno distribuisce le connessioni tra GCE_VM_IP
endpoint contenuti
all'interno di un endpoint di rete della zona
gruppi di lavoro. Questi endpoint devono essere
che si trova nella stessa regione
del bilanciatore del carico. Per alcuni NEG a livello di zona consigliato
per i casi d'uso, consulta Gruppi di endpoint di rete a livello di zona
Panoramica.
Gli endpoint nel NEG devono essere indirizzi IPv4 interni primari della rete VM interfacce che si trovano nella stessa subnet e zona del NEG a livello di zona. Il principale a un indirizzo IPv4 interno da qualsiasi interfaccia di rete di un'istanza VM con più NIC verrà aggiunto a un NEG purché si trovi nella subnet del NEG.
I NEG di zona supportano le VM sia IPv4 che a doppio stack (IPv4 e IPv6). Sia per IPv4 e a doppio stack, è sufficiente specificare solo l'istanza VM collegamento di un endpoint a un NEG. Non è necessario specificare l'IP dell'endpoint . L'istanza VM deve trovarsi sempre nella stessa zona del NEG.
Ogni NEG a livello di zona è associato a una rete VPC e a una subnet, se quel NEG a livello di zona non è ancora stato connesso a un servizio di backend. Per ulteriori informazioni informazioni su come una rete viene associata ai NEG a livello di zona, consulta NEG a livello di zona e interfacce di rete.
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.
nic0
. Se vuoi ricevere traffico su una rete non predefinita
(da nic1
a nic7
), devi utilizzare NEG a livello di zona con GCE_VM_IP
endpoint.
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.
Servizi di backend e reti VPC
Il servizio di backend non è associato ad alcuna rete VPC. tuttavia, ogni gruppo di istanza di backend o NEG a livello di zona è associato rete VPC, come indicato in precedenza. Purché tutti i backend si trovano nella stessa regione e nello stesso progetto, purché tutti i backend siano dello stesso tipo (gruppi di istanze o NEG a livello di zona), puoi aggiungere backend che utilizzano sulla stessa rete VPC o su reti VPC diverse.
Per distribuire i pacchetti in nic1
tramite nic7
, devi utilizzare
backend NEG a livello di zona (con GCE_VM_IP
endpoint) perché
rete VPC associata corrisponde sempre
rete utilizzata dall'interfaccia nic0
di tutte le istanze membri.
Backend a doppio stack (IPv4 e IPv6)
Se vuoi che il bilanciatore del carico supporti il traffico IPv6, i backend devono soddisfare i seguenti requisiti:
- I backend devono essere configurati in dual stack
che si trovano nella stessa regione
la regola di forwarding IPv6 del bilanciatore
del carico. Per i backend, puoi utilizzare una subnet
con
ipv6-access-type
impostato suEXTERNAL
oINTERNAL
. Per utilizzare una subnet conipv6-access-type
impostato suINTERNAL
è necessario usare un subnet a doppio stack separata conipv6-access-type
impostata suEXTERNAL
per la regola di forwarding esterno del bilanciatore del carico. Per le istruzioni, consulta Aggiungere un una subnet a doppio stack. - I backend devono essere configurati in modo da essere a doppio stack con
--ipv6-network-tier
impostato suPREMIUM
. Per le istruzioni, consulta la sezione Creare un modello di istanza con IPv6 indirizzi IP.
Controlli di integrità
I bilanciatori del carico di rete passthrough esterni utilizzano i controlli di integrità a livello di regione per determinare quali le istanze possono ricevere nuove connessioni. Il servizio di backend di ogni bilanciatore del carico di rete passthrough esterno deve essere associato a un controllo di integrità a livello di regione. I bilanciatori del carico utilizzano il controllo di integrità per determinare come instradare nuove connessioni alle istanze di backend.
Per maggiori dettagli sul funzionamento dei controlli di integrità di Google Cloud, consulta Come funzionano i controlli di integrità.
I bilanciatori del carico di rete passthrough esterni supportano i seguenti tipi di controlli di integrità:
- HTTP, HTTPS o HTTP/2. Se le VM di backend gestiscono il traffico utilizzando HTTP, HTTPS o HTTP/2, è preferibile utilizzare un controllo di integrità che corrisponda il protocollo. Per maggiori dettagli, vedi Criteri di successo per HTTP, HTTPS e HTTP/2 i controlli di integrità.
- SSL o TCP. Se le VM di backend non gestiscono traffico di tipo HTTP, dovrebbe utilizzare un controllo di integrità SSL o TCP. Per maggiori dettagli, vedi Criteri di successo per l'integrità SSL e TCP controlli.
Controlli di integrità per altro traffico del protocollo
Google Cloud non offre controlli di integrità specifici del protocollo oltre alle quelli elencati nella sezione Controlli di integrità e in precedenza . Quando utilizzi un bilanciatore del carico di rete passthrough esterno per bilanciare il carico di un protocollo diverso da TCP, devi comunque eseguire un sulle tue VM di backend per fornire le informazioni richieste sul controllo di integrità.
Ad esempio, se utilizzi il bilanciamento del carico del traffico UDP, le richieste del client vengono bilanciato mediante il protocollo UDP, e devi eseguire un servizio TCP per fornire informazioni ai probe del controllo di integrità di Google Cloud. A questo scopo, puoi eseguire un server HTTP su ogni VM di backend che restituisce una risposta HTTP 200 i probe del controllo di integrità. Devi utilizzare la tua logica in esecuzione sulla VM di backend per verifica che il server HTTP restituisca 200 solo se il servizio UDP è corretto configurato e in esecuzione.
Regole firewall
Poiché i bilanciatori del carico di rete passthrough esterni sono bilanciatori del carico passthrough, controlla l'accesso ai backend del bilanciatore del carico utilizzando il firewall Google Cloud le regole del caso. Devi creare regole firewall di autorizzazione in entrata. un criterio firewall gerarchico in entrata che consenta consentono i controlli di integrità e il traffico per cui è impostato il bilanciamento del carico.
Regole di forwarding e regole firewall di autorizzazione in entrata o criteri firewall gerarchici funzionano insieme nel seguente modo: una regola di forwarding specifica e, se definiti, requisiti delle porte che un pacchetto deve soddisfare per a una VM di backend. Le regole firewall di autorizzazione in entrata controllano se i pacchetti inoltrati vengono consegnati alla VM o eliminati. Tutti i VPC Le reti hanno un firewall implicito per negare l'accesso regola che blocca i messaggi in arrivo di pacchetti da qualsiasi origine. Il VPC predefinito di Google Cloud La rete include un insieme limitato di firewall di autorizzazione in entrata precompilato .
Per accettare il traffico da qualsiasi indirizzo IP su internet, devi creare una regola firewall di autorizzazione in entrata con l'intervallo di origine
0.0.0.0/0
. Solo a consentire il traffico da determinati intervalli di indirizzi IP, utilizzare origini più restrittive intervalli di tempo.Come best practice per la sicurezza, le regole firewall di autorizzazione in entrata devono in modo corretto i protocolli e le porte IP necessaria. Limitazione del protocollo e, se possibile, la configurazione delle porte è particolarmente importante quando si utilizza di regole di forwarding con protocollo impostato
L3_DEFAULT
L3_DEFAULT
regole di forwarding inoltra pacchetti per tutti i protocolli IP supportati (su tutte le porte e il pacchetto hanno informazioni sulle porte).I bilanciatori del carico di rete passthrough esterni utilizzano i controlli di integrità di Google Cloud. Pertanto, devi sempre consentire il traffico dall'indirizzo IP del controllo di integrità più intervalli. Questi traffico in entrata consentire regole firewall specifiche per il protocollo e le porte controllo di integrità del bilanciatore del carico.
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'indirizzo IP esterno associato a un Indirizzo IP di un sistema o di una VM Google Cloud instradabile su internet la connessione al bilanciatore del carico.
- Destinazione:l'indirizzo IP dell'inoltro del bilanciatore del carico personalizzata.
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, ESP, GRE e ICMP sono senza connessione. Le VM di backend possono inviare risposte pacchetti i cui indirizzi IP di origine corrispondono all'indirizzo IP della regola di forwarding corrispondere a qualsiasi indirizzo IP esterno 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, ESP, GRE, ICMP | Nella maggior parte dei casi d'uso, l'indirizzo IP del forwarding del bilanciatore del carico regola † | L'origine del pacchetto richiedente. |
† Quando una VM ha un indirizzo IP esterno o quando utilizzi Cloud NAT, è anche possibile impostare l'IP di origine del pacchetto di risposta all'indirizzo IPv4 interno principale del NIC della VM. in Google Cloud Cloud NAT cambia l'indirizzo IP di origine del pacchetto di risposta nel l'indirizzo IPv4 esterno del NIC o un indirizzo IPv4 esterno di Cloud NAT per inviare il pacchetto di risposta all'indirizzo IP esterno del client. Non in uso l'indirizzo IP della regola di forwarding come origine è uno scenario avanzato perché riceve un pacchetto di risposta da un indirizzo IP esterno che non corrisponda all'indirizzo IP a cui ha inviato un pacchetto di richiesta.
Percorso di ritorno
I bilanciatori del carico di rete passthrough esterni utilizzano route fuori da alla rete VPC per indirizzare le richieste in entrata e il controllo di integrità a ogni VM di backend.
Il bilanciatore del carico conserva gli indirizzi IP di origine dei pacchetti. Risposte di Le VM di backend passano direttamente ai client, non attraverso il bilanciatore del carico. Il termine nel settore per questo parametro è direct server Return.
Architettura VPC condiviso
Ad eccezione dell'indirizzo IP, tutti i componenti di un bilanciatore del carico di rete passthrough esterno devono nello stesso progetto. La tabella seguente riassume il VPC condiviso per i bilanciatori del carico di rete passthrough esterni:
Indirizzo IP | Regola di forwarding | Componenti di backend |
---|---|---|
R indirizzo IP esterno regionale deve essere definito nella stessa come bilanciatore del carico o come progetto host VPC condiviso. | R la regola di forwarding esterno a livello di regione deve essere definita nello stesso progetto delle istanze nel servizio di backend. | Il servizio di backend regionale deve essere definito nello stesso e nella stessa regione in cui si trovano i backend (gruppo di istanze o NEG a livello di zona) esistono. Controlli di integrità associati al il servizio di backend deve essere definito nello stesso progetto e nella stessa regione come servizio di backend. |
Distribuzione del traffico
Il modo in cui i bilanciatori del carico di rete passthrough esterni distribuiscono le nuove connessioni dipende se hai configurato il failover:
- Se non hai configurato il failover, un bilanciatore del carico di rete passthrough esterno distribuisce le nuove connessioni alle proprie VM di backend integre, se almeno una la VM di backend è integro. Se tutte le VM di backend sono in stato non integro, il bilanciatore del carico distribuisce equamente nuove connessioni tra tutti i backend. In questo in una situazione di situazione, il bilanciatore del carico instrada ogni nuova connessione a un di backend.
- Se hai configurato il failover, un bilanciatore del carico di rete passthrough esterno distribuisce
nuove connessioni tra VM di backend integre nel pool attivo, secondo
il criterio di failover
che hai configurato. Se 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 operazione è l'ultima risorsa. Le VM di backup sono escluse da questo la distribuzione delle connessioni.
- Il bilanciatore del carico elimina il traffico.
Per maggiori dettagli su come vengono distribuite le connessioni, consulta la sezione successiva Selezione del backend e monitoraggio delle connessioni.
Per i dettagli sul funzionamento del failover, consulta la sezione Failover.
Selezione del backend e monitoraggio delle connessioni
I bilanciatori del carico di rete passthrough esterni 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 esterni utilizzano il seguente algoritmo per distribuire i pacchetti tra le VM di backend (nel pool attivo, se hai configurato failover):
- 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 di 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.
Se il bilanciatore del carico riceve un pacchetto per cui non ha connessione di monitoraggio, il bilanciatore del carico esegue le seguenti operazioni:
Il bilanciatore del carico seleziona un backend. Il bilanciatore del carico calcola basato sull'affinità sessione configurata. Utilizza questo hash per selezionare tra quelli in stato integro (a meno che tutti uno stato non integro, in questo caso tutti i backend sono considerati a lungo poiché il criterio di failover non è stato configurato per trasferire il traffico questa situazione). L'affinità sessione predefinita,
NONE
, utilizza quanto segue algoritmi hash:- Per i pacchetti TCP e UDP non frammentati, un hash a 5 tuple del indirizzo IP di origine, porta di origine, indirizzo IP di destinazione, destinazione e il protocollo.
- Per i pacchetti UDP frammentati e tutti gli altri protocolli, un hash a 3 tuple tra l'indirizzo IP di origine e l'indirizzo IP di destinazione del pacchetto 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.
Inoltre, tieni presente quanto segue:
Se attivi il bilanciamento del carico ponderato, i valori basati su hash la selezione del backend viene ponderata in base alle ponderazioni riportate dal backend di Compute Engine. Ad esempio:
- Considera un servizio di backend configurato con l'affinità sessione impostata su
NONE
e una regola di forwarding con protocolloUDP
. Se sono presenti due in stato integro con pesi 1 e 4, i backend otteniamo rispettivamente il 20% e l'80% dei pacchetti UDP. - Considera un servizio di backend configurato con una sessione a tre tuple
di affinità e il monitoraggio delle connessioni.
L'affinità sessione è
CLIENT_IP_PROTO
e modalità di monitoraggio delle connessioni èPER_SESSION
. Se sono presenti tre istanze di backend integre con ponderazioni 0, 2 e 6, i backend riceveranno traffico per lo 0%, il 25% e il 75% dei nuovi indirizzi IP di origine (gli indirizzi IP di origine per che non esistono voci della tabella di monitoraggio delle connessioni) rispettivamente. Il traffico per le connessioni esistenti verrà indirizzato assegnati in precedenza. di Gemini Advanced.
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:
TCP. Il monitoraggio delle connessioni è sempre attivo e non può essere disattivata. Per impostazione predefinita, il monitoraggio delle connessioni è a 5 tuple, ma può essere configurato in modo da essere inferiore a 5 tuple. se sono a 5 tuple, i pacchetti SYN TCP vengono trattati in modo diverso. A differenza dei pacchetti non SYN, ignorano qualsiasi corrispondente alla voce di monitoraggio delle connessioni e seleziona sempre un nuovo backend.
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
.
- la modalità di monitoraggio è
Pacchetti UDP, ESP e GRE. Il monitoraggio delle connessioni viene attivato solo se l'affinità sessione è impostata su un valore diverso da
NONE
.Pacchetti ICMP e ICMPv6. Impossibile utilizzare il monitoraggio delle connessioni.
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:
- Una voce nella tabella di monitoraggio delle connessioni scade 60 secondi dopo il bilanciatore del carico elabora l'ultimo pacchetto corrispondente alla voce. Per maggiori dettagli, consulta Timeout di inattività.
- 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. L'affinità sessione è specificata per l'intera a livello di servizio di backend esterno regionale, non per backend.
I bilanciatori del carico di rete passthrough esterni supportano le seguenti opzioni di affinità sessione:
- 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, IP di destinazione (
CLIENT_IP
). Hash a 2 tuple dell'indirizzo IP di origine e l'indirizzo 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
Per scoprire in che modo queste opzioni di affinità sessione influiscono sulla selezione del backend di monitoraggio della connessione, consulta questo dalla tabella.
Modalità di monitoraggio delle connessioni
L'abilitazione del monitoraggio delle connessioni dipende solo dal protocollo del
per il traffico con bilanciamento del carico
e per le impostazioni di affinità sessione. La modalità di monitoraggio specifica
l'algoritmo di monitoraggio delle connessioni da usare quando il monitoraggio delle connessioni
attivata. Esistono due modalità di monitoraggio: PER_CONNECTION
(predefinita) e
PER_SESSION
.
PER_CONNECTION
(valore predefinito). Questa è la modalità di rilevamento predefinita. Con questo monitoraggio della connessione, il traffico TCP viene sempre tracciato per 5 tuple a prescindere dall'impostazione di affinità sessione. Per il traffico UDP, ESP e GRE, il monitoraggio della connessione è attivato quando l'affinità sessione selezionata non èNONE
. I pacchetti UDP, ESP e GRE vengono monitorati utilizzando i metodi di monitoraggio descritti in questa tabella.PER_SESSION
. Se l'affinità sessione èCLIENT_IP
oCLIENT_IP_PROTO
, la configurazione di questa modalità comporta il monitoraggio delle connessioni a due e tre tuple. rispettivamente, per tutti i protocolli (tranne ICMP e ICMPv6, che non sono tracciabile della connessione). Per altre impostazioni di affinità sessione, modalitàPER_SESSION
si comporta in modo identico alla modalitàPER_CONNECTION
.
Per informazioni sul funzionamento di queste modalità di rilevamento con impostazioni di affinità sessione 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
( |
TCP e UDP non frammentato: hash a 5 tuple UDP frammentato e tutti gli altri protocolli: a 3 tuple hash |
|
|
IP client, IP di destinazione
( |
Tutti i protocolli:hash a 2 tuple |
|
|
IP client, IP di destinazione, protocollo
( |
Tutti i protocolli:hash a 3 tuple |
|
|
IP client, porta client, IP di destinazione, porta di destinazione, protocollo
( |
TCP e UDP non frammentato: hash a 5 tuple UDP frammentato e tutti gli altri protocolli: a 3 tuple hash |
|
|
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
Le impostazioni di persistenza della connessione controllano se una connessione esistente persiste su una VM o un endpoint di backend selezionati dopo che il backend diventa in stato non integro, finché il backend rimane nella configurazione del bilanciatore del carico gruppo di backend (in un gruppo di istanze o in un NEG).
Il comportamento descritto in questa sezione non si applica ai casi in cui rimuovi un'istanza di backend da un gruppo di istanze o un endpoint di backend dal relativo NEG oppure rimuovere il gruppo di istanze o il NEG dal servizio di backend. In questi casi, le connessioni stabilite rimangono valide solo come descritto nella sezione 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) Tutti gli altri protocolli:le connessioni non vengono mai conservate. backend in stato non integro |
TCP: le connessioni persistono su backend in stato non integro se
affinità sessione è Tutti gli altri protocolli:le connessioni non vengono mai conservate. backend in stato non integro |
NEVER_PERSIST |
Tutti i protocolli:le connessioni non vengono mai mantenute. su backend in stato non integro | |
ALWAYS_PERSIST |
TCP: le connessioni vengono mantenute su backend in stato non integro (tutte affinità sessione) ESP, GRE, UDP: le connessioni vengono mantenute in stato non integro
backend se l'affinità sessione non è ICMP, ICMPv6:non applicabile perché non sono tracciabile della connessione Questa opzione deve essere utilizzata solo per casi d'uso avanzati. |
Configurazione non possibile |
Comportamento di persistenza della connessione TCP su backend in stato non integro
Ogni volta che una connessione TCP con monitoraggio a 5 tuple persiste su un stato non integro di backend:
- Se il backend in stato non integro continua a rispondere ai pacchetti, continua fino a quando non viene reimpostata o chiusa (dallo stato backend o il client).
- Se il backend in stato non integro invia o meno un pacchetto di reimpostazione TCP (RST) a un pacchetto, il client potrebbe riprovare con una nuova connessione, consentendo al bilanciatore del carico di selezionare un backend diverso e integro. SYN TCP e pacchetti selezionano sempre un nuovo backend integro.
Per scoprire come modificare il comportamento di persistenza della connessione, consulta Configurare un monitoraggio della connessione .
Timeout di inattività
Le voci nelle tabelle di monitoraggio delle connessioni scadono 60 secondi dopo il bilanciatore del carico elabora l'ultimo pacchetto che corrisponde alla voce. Questo valore di timeout per inattività non può possono essere modificate.
Bilanciamento del carico ponderato
Puoi configurare un bilanciatore del carico di rete per distribuire il traffico tra alle istanze di backend del bilanciatore del carico in base alle ponderazioni riportate da un Controllo di integrità HTTP utilizzando il bilanciamento del carico ponderato.
Il bilanciamento del carico ponderato richiede la configurazione di entrambi i seguenti elementi:
- Devi impostare il criterio del bilanciatore del carico per le località (
localityLbPolicy
) del dal tuo servizio di backend aWEIGHTED_MAGLEV
. - Devi configurare il servizio di backend con un controllo di integrità HTTP. L'interfaccia HTTP
le risposte del controllo di integrità devono contenere un campo di intestazione della risposta HTTP personalizzato
X-Load-Balancing-Endpoint-Weight
per specificare i pesi con i valori da0
a1000
per ogni istanza di backend.
Se utilizzi lo stesso backend (gruppo di istanze o NEG) per più backend
di bilanciatori del carico di rete passthrough esterni basati su servizi che utilizzano il bilanciamento del carico ponderato,
utilizzando un valore request-path
univoco per ogni controllo di integrità del servizio di backend. Questo
consente all'istanza di endpoint di assegnare pesi diversi a diversi backend
Google Cloud. Per ulteriori informazioni
per informazioni, consulta Criteri di successo per l'integrità HTTP, HTTPS e HTTP/2
controlli.
Per selezionare un backend per una nuova connessione, ai backend viene assegnato un livello di priorità in base al peso e allo stato di salute, come mostrato di seguito tabella:
Peso | Stato integro | Priorità selezione backend |
---|---|---|
Peso maggiore di zero | Sì | 4 |
Peso maggiore di zero | No | 3 |
Il peso è uguale a zero | Sì | 2 |
Il peso è uguale a zero | No | 1 |
Solo i backend con priorità più elevata sono idonei alla selezione. Se tutti i backend idonei hanno un peso pari a zero, il bilanciatore del carico distribuisce nuovi delle connessioni tra tutti i backend idonei, considerando le loro esigenze con la stessa ponderazione. Per esempi di bilanciamento del carico ponderato, consulta Selezione del backend e monitoraggio delle connessioni.
Il bilanciamento del carico ponderato può essere utilizzato nei seguenti scenari:
Se alcune connessioni elaborano più dati di altre o alcune connessioni più a lungo di altre, la distribuzione del carico backend potrebbe diventare non uniforme. Indicando un peso per istanza inferiore, un'istanza con un carico elevato può a ridurre la sua quota di nuove connessioni, continua a servire le connessioni esistenti.
Se un backend è sovraccarico e l'assegnazione di più connessioni potrebbe interrompere di rete, questi backend non assegnano alcun peso a se stessi. Di segnalando un peso pari a zero, un'istanza di backend smette di gestire le nuove connessioni ma continua a servire quelli esistenti.
Se un backend svuota le connessioni esistenti prima della manutenzione, assegna nullo per se stesso. Segnalando il peso pari a zero, il backend smette di fornire le nuove connessioni, ma continua a utilizzare quelle esistenti quelli.
Per ulteriori informazioni, vedi Configurare il bilanciamento del carico ponderato.
Svuotamento della connessione
Lo svuotamento della connessione è un processo applicato alle connessioni stabilite i seguenti casi:
- Una VM o un endpoint viene rimosso da un backend (gruppo di istanze o NEG).
- Un backend rimuove una VM o un endpoint (per sostituzione, l'abbandono, durante l'esecuzione di upgrade o lo scale down).
- Un backend viene rimosso da un servizio di backend.
Per impostazione predefinita, lo svuotamento della connessione è disattivato. Se disattivato, stabilito vengono terminate il più rapidamente possibile. Quando lo svuotamento della connessione è attiva, le connessioni stabilite possono essere mantenute per un di timeout, dopo il quale viene terminata l'istanza VM di backend.
Per ulteriori dettagli su come viene attivato lo svuotamento della connessione e su come attivare lo svuotamento della connessione. Consulta Attivazione della connessione drenaggio.
Frammentazione UDP
I bilanciatori del carico di rete passthrough esterni basati sul servizio di backend possono elaborare sia dati frammentati che frammentati di pacchetti UDP non frammentati. Se l'applicazione utilizza pacchetti UDP frammentati, mantieni tieni presente quanto segue:
- 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
oL3_DEFAULT
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 impostareallPorts
suTrue
.Configurazione del servizio di backend: imposta la sessione del servizio di backend affinità a
CLIENT_IP
(hash a 2 tuple) oCLIENT_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 suPER_SESSION
, in modo che la connessione le voci della tabella di monitoraggio vengono create utilizzando gli stessi hash a due o tre tuple.
Utilizzo di istanze di destinazione come backend
Se utilizzi target
di Compute Engine
come backend per il bilanciatore del carico di rete passthrough esterno e prevedi pacchetti UDP frammentati,
utilizza una sola regola di forwarding UDP
o L3_DEFAULT
per indirizzo IP
e configurare 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 non hanno
la stessa porta di destinazione. Per configurare tutte le porte, imposta
--ports=ALL
con
gcloud
o imposta allPorts
su
True
utilizzando l'API.
Failover
Puoi configurare un bilanciatore del carico di rete passthrough esterno per distribuire le connessioni tra le istanze VM o endpoint nei backend primari (gruppi di istanze o NEG), quindi effettua la modifica, se necessarie all'uso dei backend di failover. Il failover fornisce un altro metodo aumentando la disponibilità, offrendo al contempo un maggiore controllo su come gestire il carico di lavoro quando i backend principali non sono integri.
Per impostazione predefinita, quando aggiungi un backend a un servizio di backend del bilanciatore del carico di rete passthrough esterno, si tratta di un backend principale. Puoi designare un backend come failover quando lo aggiungi al servizio di backend del bilanciatore del carico oppure modificando al servizio di backend in un secondo momento.
Per maggiori dettagli sul funzionamento del failover, consulta Panoramica del failover per bilanciatori del carico di rete passthrough esterni.
Connettività a internet in uscita dai backend
Le istanze VM configurate come endpoint di backend del bilanciatore del carico di rete passthrough esterno possono avviare connessioni a internet utilizzando l'indirizzo IP della regola di forwarding del bilanciatore del carico come indirizzo IP di origine della connessione in uscita.
In genere, un'istanza VM utilizza sempre il proprio indirizzo IP esterno, Cloud NAT per avviare le connessioni. Utilizzi l'IP della regola di forwarding per avviare le connessioni dagli endpoint di backend solo in scenari speciali ad esempio quando è necessario che le istanze VM abbiano origine e ricezione delle connessioni allo stesso indirizzo IP esterno ed è necessaria anche la ridondanza del backend fornita il bilanciatore del carico di rete passthrough esterno per le connessioni in entrata.
I pacchetti in uscita inviati dalle VM di backend direttamente a internet non hanno restrizioni riguardanti i protocolli di traffico e le porte. Anche se un pacchetto in uscita sta utilizzando l'indirizzo IP della regola di forwarding come origine, e la porta di origine non devono necessariamente corrispondere al regola di forwarding delle specifiche della porta. Tuttavia, i pacchetti di risposta in entrata devono corrispondere l'indirizzo IP, il protocollo e la porta di destinazione della regola di forwarding. Per ulteriori informazioni per informazioni, vedi Percorsi per bilanciatori del carico di rete passthrough esterni e protocollo esterno l'inoltro.
Inoltre, tutte le risposte alle connessioni in uscita della VM sono soggette a carico. proprio come tutti gli altri pacchetti in entrata destinati al bilanciatore del carico. Ciò significa che le risposte potrebbero non arrivare sulla stessa VM di backend da cui è stato avviato la connessione a internet. Se le connessioni in uscita e il carico sono bilanciati connessioni in entrata condividono protocolli e porte comuni, quindi puoi provare uno di i seguenti suggerimenti:
Sincronizza lo stato delle connessioni in uscita tra le VM di backend, in modo che e connessioni possono essere fornite anche se le risposte arrivano a una VM di backend, di quello che ha avviato la connessione.
Utilizza un failover configurazione, con una singola VM principale e una singola VM di backup. Quindi, i pod attivi la VM di backend che avvia le connessioni in uscita riceve sempre pacchetti di risposta.
Il percorso per la connettività a internet dai backend di un bilanciatore del carico di rete passthrough esterno comportamento predefinito previsto in base al firewall implicito di Google Cloud . Tuttavia, se disponi problemi di sicurezza riguardo a lasciare aperto questo percorso, puoi utilizzare il traffico e regole firewall per bloccare il traffico non richiesto in uscita verso internet.
Limitazioni
Non puoi utilizzare la console Google Cloud per eseguire le attività seguenti:
- Crea o modifica un bilanciatore del carico di rete passthrough esterno la cui regola di forwarding utilizza il
protocollo
L3_DEFAULT
. - Crea o modifica un bilanciatore del carico di rete passthrough esterno di cui è impostato il protocollo del servizio di backend
a
UNSPECIFIED
. - Crea o modifica un bilanciatore del carico di rete passthrough esterno che configura un monitoraggio delle connessioni .
- Crea o modifica il reindirizzamento del traffico basato su IP di origine per una regola di forwarding.
Utilizza Google Cloud CLI o l'API REST.
- Crea o modifica un bilanciatore del carico di rete passthrough esterno la cui regola di forwarding utilizza il
protocollo
I bilanciatori del carico di rete passthrough esterni non supportano il peering di rete VPC.
Prezzi
Per informazioni sui prezzi, vedi Prezzi.
Passaggi successivi
- Configurazione di un bilanciatore del carico di rete passthrough esterno con un servizio di backend per il traffico TCP o UDP (supporta il traffico IPv4 e IPv6), consulta Configurare un bilanciatore del carico di rete passthrough esterno con backend Google Cloud.
- Per configurare un bilanciatore del carico di rete passthrough esterno per più protocolli IP (che supporta IPv4 e traffico IPv6), vedi Configurare un bilanciatore del carico di rete passthrough esterno per più indirizzi IP protocolli.
- Per configurare un bilanciatore del carico di rete passthrough esterno con un backend NEG a livello di zona, consulta Configurare un bilanciatore del carico di rete passthrough esterno con NEG a livello di zona
- Per configurare un bilanciatore del carico di rete passthrough esterno con un pool di destinazione, consulta Configurare un bilanciatore del carico di rete passthrough esterno con una destinazione pool.
- Scopri come eseguire la transizione di un bilanciatore del carico di rete passthrough esterno dal backend di un pool di destinazione a un dal servizio di backend regionale, consulta Transizione di un bilanciatore del carico di rete passthrough esterno da una destinazione in un backend Google Cloud.