Risolvere i problemi relativi ai bilanciatori del carico di rete passthrough interni

Questa guida descrive come risolvere i problemi di configurazione per un bilanciatore del carico di rete passthrough interno di Google Cloud. Prima di esaminare i problemi, consulta le seguenti pagine:

Risolvere i problemi comuni relativi a Network Analyzer

Network Analyzer monitora automaticamente la configurazione della rete VPC e rileva sia le configurazioni non ottimali sia quelle errate. Identifica i guasti di rete, fornisce informazioni sulle cause principali e suggerisce possibili soluzioni. Per scoprire di più sui diversi scenari di configurazione errata che vengono rilevati automaticamente da Network Analyzer, vedi Approfondimenti sul bilanciatore del carico nella documentazione di Network Analyzer.

Network Analyzer è disponibile nella console Google Cloud come parte di Network Intelligence Center.

Vai a Network Analyzer

I backend hanno modalità di bilanciamento incompatibili

Quando crei un bilanciatore del carico, potresti visualizzare l'errore:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Questo accade quando provi a utilizzare lo stesso backend in due bilanciatori del carico diversi e i backend non hanno modalità di bilanciamento compatibili.

Per ulteriori informazioni, consulta le seguenti risorse:

Risolvere i problemi generali di connettività

Se non riesci a connetterti al bilanciatore del carico di rete passthrough interno, verifica i seguenti problemi comuni.

Verifica le regole firewall

Assicurati che siano definite regole firewall di autorizzazione in entrata per consentire i controlli di integrità alle VM di backend.
Assicurati che le regole firewall di autorizzazione in entrata consentano il traffico dai client alle VM di backend.
Assicurati che esistano regole firewall pertinenti per consentire al traffico di raggiungere le VM di backend sulle porte utilizzate dal bilanciatore del carico.
Se utilizzi tag target per le regole firewall, assicurati che le VM di backend del bilanciatore del carico siano codificate in modo appropriato.

Per scoprire come configurare le regole firewall richieste dal bilanciatore del carico di rete passthrough interno, consulta Configurazione delle regole firewall.

Verifica che l'ambiente guest sia in esecuzione sulla VM di backend

Se riesci a connetterti a una VM di backend integro, ma non al bilanciatore del carico, è possibile che l'ambiente guest (in precedenza Windows Guest Environment o Linux Guest Environment) sulla VM non sia in esecuzione o non sia in grado di comunicare con il server di metadati (metadata.google.internal, 169.254.169.254).

Verifica quanto segue:

Assicurati che l'ambiente guest sia installato e in esecuzione sulla VM di backend.
Assicurati che le regole firewall all'interno del sistema operativo guest della VM di backend (iptables o Windows Firewall) non blocchino l'accesso al server di metadati.

Verifica che le VM di backend accettino i pacchetti inviati al bilanciatore del carico

Ogni VM di backend deve essere configurata in modo da accettare i pacchetti inviati al bilanciatore del carico. In altre parole, la destinazione dei pacchetti consegnati alle VM di backend è l'indirizzo IP del bilanciatore del carico. Nella maggior parte dei casi, questo viene fatto con una route locale.

Per le VM create da immagini Google Cloud, il Guest agent installa la route locale per l'indirizzo IP del bilanciatore del carico. Le istanze di Google Kubernetes Engine basate su Container-Optimized OS implementano questa soluzione utilizzando iptables.

Su una VM backend Linux, puoi verificare la presenza della route locale eseguendo il comando seguente. Sostituisci LOAD_BALANCER_IP con l'indirizzo IP del bilanciatore del carico:

sudo ip route list table local | grep LOAD_BALANCER_IP

Verifica l'indirizzo IP del servizio e l'associazione delle porte sulle VM di backend

I pacchetti inviati a un bilanciatore del carico di rete passthrough interno arrivano alle VM di backend con l'indirizzo IP di destinazione del bilanciatore del carico stesso. Questo tipo di bilanciatore del carico non è un proxy e si tratta di un comportamento previsto.

Il software in esecuzione sulla VM backend deve:

In ascolto sull'indirizzo IP o su qualsiasi indirizzo IP del bilanciatore del carico (0.0.0.0 o ::)
In ascolto su (associata a) una porta inclusa nella regola di forwarding del bilanciatore del carico

Per verificarlo, connettiti a una VM di backend utilizzando SSH o RDP. Poi esegui i seguenti test utilizzando curl, telnet o uno strumento simile:

Prova a raggiungere il servizio contattandolo utilizzando l'indirizzo IP interno della VM di backend stessa, 127.0.0.1 o localhost.
Prova a raggiungere il servizio contattandolo utilizzando l'indirizzo IP della regola di forwarding del bilanciatore del carico.

Verifica se la VM client si trova nella stessa regione del bilanciatore del carico

Se il client che si connette al bilanciatore del carico si trova in un'altra regione, assicurati che l'accesso globale sia abilitato.

Verifica che il traffico del controllo di integrità possa raggiungere le VM di backend

Per verificare che il traffico del controllo di integrità raggiunga le VM di backend, abilita il logging del controllo di integrità e cerca le voci di log riuscite.

Puoi anche verificare che la funzionalità del bilanciatore del carico sia integro visualizzando lo stato"Integro" per il backend.

Se nel backend non sono presenti istanze integre, assicurati che sia configurato il controllo di integrità appropriato e che ogni VM nel backend sia in ascolto sulle porte configurate per il controllo di integrità.

Da un client nella stessa rete VPC, esegui questo comando per verificare che la VM di backend sia in ascolto su una porta TCP specifica:

telnet SERVER_IP_ADDRESS PORT

Sostituisci quanto segue:

SERVER_IP_ADDRESS: l'indirizzo IP della VM backend.
PORT: la porta che hai configurato per il controllo di integrità. Per impostazione predefinita, la porta per il controllo di integrità è 80.

In alternativa, puoi utilizzare SSH per connettere la VM di backend ed eseguire questo comando:

curl localhost:PORT

Sostituisci di nuovo PORT con la porta che hai configurato per il controllo di integrità.

Un altro modo per eseguire questo test è eseguire il comando seguente:

netstat -npal | grep LISTEN

Nell'output, verifica quanto segue:

<var>LB_IP_ADDRESS</var>:<var>PORT</var>
0.0.0.0:<var>PORT</var>
:::<var>PORT</var>

Questo non determina se il routing è configurato correttamente per rispondere all'indirizzo IP del bilanciatore del carico. Questo è un problema separato con un sintomo simile. Per il routing, esegui il comando ip route list table local e verifica che l'indirizzo IP del bilanciatore del carico sia elencato, come descritto in Verificare che le VM di backend accettino i pacchetti inviati al bilanciatore del carico.

Risolvere i problemi di prestazioni

Se noti problemi di prestazioni e maggiore latenza, verifica i seguenti problemi comuni.

Verifica la funzionalità del server

Se tutti i server di backend rispondono ai controlli di integrità, verifica che le richieste del client funzionino correttamente quando vengono inviate direttamente sul server. Ad esempio, se il client invia richieste HTTP al server attraverso il bilanciatore del carico e non viene ricevuta alcuna risposta o se la risposta è sostanzialmente più lenta del normale, invia la stessa richiesta HTTP su ciascuno dei server di backend e osserva il comportamento.

Se uno dei singoli server di backend non si comporta correttamente quando la richiesta viene emessa dall'interno del server, puoi concludere che lo stack di applicazioni server non funziona correttamente. Puoi concentrarti ulteriormente sulla risoluzione dei problemi relativi all'applicazione stessa. Se tutti i server si comportano correttamente, la fase successiva è esaminare il lato client e la rete.

Verificare la latenza e la connettività di rete

Se tutti i server di backend rispondono alle richieste correttamente, verifica la latenza di rete. Da una VM client, invia un comando ping costante a ciascuno dei server, come indicato di seguito:

ping SERVER_IP_ADDRESS

Questo test mostra la latenza di rete integrata e se la rete sta riducendo i pacchetti. In alcuni casi, le regole firewall potrebbero bloccare il traffico ICMP. Se sì, questo test non riesce a produrre alcun risultato. Verifica con l'amministratore delle regole firewall se questo è il caso.

Se il comando ping mostra una latenza significativamente più elevata rispetto alla perdita di pacchetti normale o significativa, apri una richiesta di assistenza Google Cloud per esaminare ulteriormente il problema.

Identificare combinazioni client-server problematiche

Se il test ping della rete suggerisce una bassa latenza e nessuna perdita di pacchetti, il passaggio successivo consiste nell'identificare quale combinazione client-server specifica, se presente, produce risultati problematici. Puoi farlo dimezzando il numero di server di backend finché il numero di server non raggiunge 1, riproducendo contemporaneamente il comportamento problematico (ad esempio, alta latenza o nessuna risposta).

Se identifichi una o più combinazioni client-server problematiche, esegui acquisizione e analisi del traffico.

Se non viene identificata alcuna combinazione client-server problematica, passa ai test delle prestazioni.

Acquisizione e analisi del traffico

Se identifichi una combinazione problematica specifica di client-server, puoi utilizzare l'acquisizione di pacchetti per individuare la parte della comunicazione che causa ritardo o interruzione. L'acquisizione dei pacchetti può essere eseguita con tcpdump nel seguente modo:

Installa tcpdump sul server.
Avvia l'acquisizione tcpdump sul server.
Da un client, invia una richiesta di esempio, come la seguente:
```
curl URL
```
Analizza l'output di tcpdump per identificare il problema.

Eseguire test del rendimento

Se non identifichi combinazioni client-server problematiche e le prestazioni aggregate di tutti i client e i server insieme sono inferiori al previsto, prendi in considerazione i seguenti test:

Un solo client e un server, senza bilanciamento del carico.
Un solo client e un server, con bilanciamento del carico.

Risultato: la combinazione dei risultati dei test [1] e [2] identifica se il problema è causato dal bilanciatore del carico.
Un solo client e più server, con bilanciamento del carico.

Risultato: identifica il limite di rendimento di un client.
Più client e un server, con bilanciamento del carico.

Risultato: identifica il limite di prestazioni di un server.
Più client e più server, senza bilanciamento del carico.

Risultato: identifica il limite di prestazioni della rete.

Quando esegui uno stress test con più client e server, le risorse client o server (CPU, memoria, I/O) potrebbero diventare colli di bottiglia e ridurre i risultati aggregati. La riduzione dei risultati aggregati può verificarsi anche se ogni client e server si comporta correttamente.

Risolvere i problemi del VPC condiviso

Se utilizzi un VPC condiviso e non riesci a creare un nuovo bilanciatore del carico di rete passthrough interno in una determinata subnet, la causa potrebbe essere un criterio dell'organizzazione. Nel criterio dell'organizzazione, aggiungi la subnet all'elenco delle subnet consentite o contatta l'amministratore dell'organizzazione. Per ulteriori informazioni, consulta il vincolo constraints/compute.restrictSharedVpcSubnetworks.

Risolvere i problemi di failover

Se hai configurato il failover per un bilanciatore del carico di rete passthrough interno, le sezioni seguenti descrivono i problemi che possono verificarsi.

Connettività

Assicurati di aver designato almeno un backend di failover.
Verifica le impostazioni dei criteri di failover:
- Rapporto di failover
- Eliminazione del traffico quando tutte le VM di backend non sono integri
- Disabilitazione dello svuotamento della connessione al failover

Problemi con i gruppi di istanze gestite e il failover

Sintomo:il pool attivo cambia continuamente tra il backend primario e quello di failover.
Possibile causa: l'utilizzo di gruppi di istanze gestite con scalabilità automatica e failover potrebbe causare il failover e il failover ripetuto del pool attivo tra il backend primario e quello di failover. Google Cloud non ti impedisce di configurare il failover con gruppi di istanze gestite, in quanto il deployment potrebbe trarre vantaggio da questa configurazione.

Disabilita la limitazione per lo svuotamento della connessione per i gruppi di failover

La disabilitazione dello svuotamento della connessione funziona solo se il servizio di backend è configurato con il protocollo TCP.

Se crei un servizio di backend con UDP mentre lo svuotamento della connessione è disabilitato, viene visualizzato il seguente messaggio di errore:

gcloud compute backend-services create my-failover-bs \
    --global-health-checks \
    --load-balancing-scheme=internal \
    --health-checks=my-tcp-health-check \
    --region=us-central1 \
    --no-connection-drain-on-failover \
    --drop-traffic-if-unhealthy \
    --failover-ratio=0.5 \
    --protocol=UDP
ERROR: (gcloud.compute.backend-services.create) Invalid value for
[--protocol]: can only specify --connection-drain-on-failover if the protocol is
TCP.

Il traffico viene inviato a VM di backend impreviste

Innanzitutto controlla quanto segue: se la VM client è anche una VM di backend del bilanciatore del carico, si prevede che le connessioni inviate all'indirizzo IP della regola di forwarding del bilanciatore del carico ricevano sempre risposta dalla VM stessa. Per saperne di più, consulta gli articoli sui test delle connessioni da un singolo client e sull'invio di richieste da VM con bilanciamento del carico.

Se la VM client non è una VM di backend del bilanciatore del carico:

Per le richieste da un solo client, consulta l'articolo Test delle connessioni da un singolo client per comprendere le limitazioni di questo metodo.
Assicurati di aver configurato regole firewall per consentire i controlli di integrità in entrata.
Per una configurazione di failover, assicurati di comprendere come funziona l'appartenenza al pool attivo e quando Google Cloud esegue failover e failback. Esamina la configurazione del bilanciatore del carico:
- Utilizza la console Google Cloud per verificare il numero di VM di backend in stato integro in ogni gruppo di istanza di backend. La console Google Cloud mostra anche le VM nel pool attivo.
- Assicurati che il rapporto di failover del bilanciatore del carico sia impostato correttamente. Ad esempio, se hai dieci VM principali e un rapporto di failover impostato su 0.2, significa che Google Cloud esegue un failover quando meno di due VM principali (10 × 0.2 = 2) sono integre. Un rapporto di failover 0.0 ha un significato speciale: Google Cloud esegue un failover quando nessuna VM principale è integra.

Le connessioni esistenti vengono terminate durante il failover o il failover

Modifica il criterio di failover del servizio di backend. Assicurati che lo svuotamento della connessione al failover sia abilitato.

Risolvi i problemi relativi al bilanciatore del carico come hop successivo

Quando imposti un bilanciatore del carico di rete passthrough interno come hop successivo di una route statica personalizzata, potrebbero verificarsi i seguenti problemi:

Problemi di connettività

Se non puoi inviare un ping a un indirizzo IP nell'intervallo di destinazione di una route il cui hop successivo è una regola di forwarding per un bilanciatore del carico di rete passthrough interno, tieni presente che una route che utilizza questo tipo di hop successivo potrebbe non elaborare il traffico ICMP a seconda di quando è stata creata la route. Se la route è stata creata prima del 15 maggio 2021, elabora solo il traffico TCP e UDP fino al 16 agosto 2021. A partire dal 16 agosto 2021, tutte le route inoltrano automaticamente tutto il traffico dei protocolli (TCP, UDP e ICMP) indipendentemente da quando è stata creata. Se non vuoi aspettare, puoi attivare subito la funzionalità di ping creando nuove route ed eliminando quelle precedenti.
Quando utilizzi un bilanciatore del carico di rete passthrough interno come hop successivo per una route statica personalizzata, tutto il traffico viene consegnato alle VM del backend integro del bilanciatore del carico, indipendentemente dal protocollo configurato per il servizio di backend interno del bilanciatore del carico e dalla porta o dalle porte configurate nella regola di forwarding interno del bilanciatore del carico.
Assicurati di aver creato regole firewall di autorizzazione in entrata che identificano correttamente le origini del traffico da consegnare alle VM di backend tramite l'hop successivo della route statica personalizzata. I pacchetti che arrivano sulle VM di backend conservano i propri indirizzi IP di origine, anche se vengono recapitati tramite una route statica personalizzata.

Valore non valido per l'intervallo di destinazione

L'intervallo di destinazione di una route statica personalizzata non può essere più specifico di qualsiasi route di subnet nella rete VPC. Se viene visualizzato il seguente messaggio di errore durante la creazione di una route statica personalizzata:

Invalid value for field 'resource.destRange': [ROUTE_DESTINATION].
[ROUTE_DESTINATION] hides the address space of the network .... Cannot change
the routing of packets destined for the network.

Non puoi creare una route statica personalizzata con una destinazione che corrisponde esattamente o è più specifica (con una maschera più lunga) di una route subnet. Per ulteriori informazioni, fai riferimento a applicabilità e ordine.
Se i pacchetti vanno a una destinazione imprevista, rimuovi altre route nella tua rete VPC con destinazioni più specifiche. Esamina l'ordine di routing per comprendere la selezione della route Google Cloud.

Risolvere i problemi di logging

Se configuri il logging per un bilanciatore del carico di rete passthrough interno, potrebbero verificarsi i seguenti problemi:

In alcuni log potrebbero mancare misurazioni RTT, ad esempio i valori di byte, se non viene campionato un numero sufficiente di pacchetti per acquisire RTT. Questo è più probabile che si verifichi per le connessioni a basso volume.
I valori RTT sono disponibili solo per i flussi TCP.
Alcuni pacchetti vengono inviati senza payload. Se i pacchetti solo su intestazione vengono campionati, il valore dei byte è 0.

Passaggi successivi

Consulta Logging e Monitoring del bilanciatore del carico di rete passthrough interno per informazioni sulla configurazione di Logging e Monitoring per i bilanciatori del carico di rete passthrough interni.
Consulta Bilanciatori del carico di rete passthrough interni e reti connesse per informazioni sull'accesso ai bilanciatori del carico di rete passthrough interni da reti peer connesse alla tua rete VPC.