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:
- Panoramica del bilanciatore del carico di rete passthrough interno
- Panoramica del failover per i bilanciatori del carico di rete passthrough interni
- Bilanciatori del carico di rete passthrough interni come successivi hop
- Logging del bilanciatore del carico di rete passthrough interno e monitoraggio
Risolvere i problemi comuni di Network Analyzer
Network Analyzer monitora automaticamente la configurazione della rete VPC e rileva sia le configurazioni non ottimali sia quelle errate. Identifica le reti errori, fornisce informazioni sulle cause principali e suggerisce possibili risoluzioni. A di conoscere i diversi scenari di errore di configurazione rilevato da Network Analyzer; consulta 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 AnalyzerI 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 carichi e i backend non hanno modalità di bilanciamento compatibili.
Per ulteriori informazioni, consulta le seguenti risorse:
- Limitazioni e indicazioni per i gruppi di istanze
- Modificare la modalità di bilanciamento di un carico bilanciatore del carico
Risolvere i problemi generali di connettività
Se non riesci a connetterti al bilanciatore del carico di rete passthrough interno, verifica i seguenti che le applicazioni presentino problemi di prestazioni.
Verifica le regole del firewall
- Assicurati che il traffico in entrata consenta firewall predefinite sono definite consentire controlli di integrità alle VM di backend.
- Assicurati che le regole firewall di autorizzazione in entrata consentano il traffico alle VM di backend dai client.
- Assicurati che esistano regole firewall pertinenti per consentire al traffico di raggiungere di backend sulle porte utilizzate dal bilanciatore del carico.
- Se utilizzi tag di destinazione per le regole del firewall, assicurati che le VM di backend del bilanciatore del carico siano taggate in modo appropriato.
Per scoprire come configurare le regole firewall richieste dal bilanciatore del carico di rete passthrough interno, consulta Configurare le regole firewall.
Verifica che l'ambiente guest sia in esecuzione sulla VM di backend
Se puoi connetterti a una VM di backend integro, ma non riesci a connetterti al carico
di bilanciamento del carico, è possibile che l'ambiente guest
(in precedenza ambiente guest Windows o ambiente guest Linux)
sulla VM non è in esecuzione o non è in grado di comunicare con i metadati
server (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 del
una VM di backend (
iptables
o Windows Firewall) non blocca l'accesso 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 inviati alle VM di backend è l'indirizzo IP del bilanciatore del carico. Nella maggior parte dei casi, questa operazione viene eseguita con un percorso locale.
Per le VM create da immagini Google Cloud, il campo Guest
dell'agente installa lo strumento
per l'indirizzo IP del bilanciatore del carico. Le istanze Google Kubernetes Engine basate su Container-Optimized OS implementano questa funzionalità utilizzando iptables
.
Su una VM di backend Linux, puoi verificare la presenza della route locale
eseguendo questo comando. 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 di porte nelle VM di backend
I pacchetti inviati a un bilanciatore del carico di rete passthrough interno arrivano alle VM di backend con all'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 di backend deve:
- Ascolto (associazione) sull'indirizzo IP del bilanciatore del carico o su qualsiasi indirizzo IP
(
0.0.0.0
o::
) - Ascolta (è associata a) una porta inclusa nella regola di forwarding del bilanciatore del carico
Per verificare, connettiti a una VM di backend utilizzando SSH o RDP. Poi esegui
i seguenti test utilizzando curl
, telnet
o uno strumento simile:
- Tentativo di raggiungere il servizio contattandolo utilizzando l'indirizzo IP interno
della VM backend stessa,
127.0.0.1
o localhost. - Prova a raggiungere il servizio contattandolo utilizzando l'indirizzo IP della regola di inoltro 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 globale accesso 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 logging del controllo di integrità e ricerca per le voci di log corrette.
Puoi anche verificare che la funzionalità del bilanciatore del carico sia integro visualizzando la "In salute" per il backend.
Se non sono presenti istanze integre nel backend, assicurati che sia configurato il controllo di integrità appropriato e che ogni VM nel backend sia in ascolto sulle porte di controllo di integrità configurate.
Da un client nella stessa rete VPC, esegui il seguente 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 di backend.
- PORT: la porta che hai configurato per il controllo di integrità.
Per impostazione predefinita, la porta del controllo di integrità è
80
.
In alternativa, puoi utilizzare SSH per connettere la VM di backend ed eseguire il seguente comando:
curl localhost:PORT
Sostituisci di nuovo PORT con la porta configurata per il controllo di stato.
Un altro modo per eseguire questo test è eseguire il seguente comando:
netstat -npal | grep LISTEN
Nell'output, controlla quanto segue:
<var>LB_IP_ADDRESS</var>:<var>PORT</var>
0.0.0.0:<var>PORT</var>
:::<var>PORT</var>
Ciò non determina se il routing è configurato correttamente per rispondere all'indirizzo IP del bilanciatore del carico. Si tratta di un problema diverso 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 accettano i pacchetti inviati al bilanciatore del carico.
Risolvere i problemi di prestazioni
Se noti problemi di prestazioni e un aumento della latenza, controlla se si verificano 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 c'è risposta o la risposta è molto più lento del normale, emetti la stessa richiesta HTTP su ciascuno dei server di backend e osservarne il comportamento.
Se uno dei singoli server di backend non si comporta correttamente quando dal server stesso, possiamo concludere che lo stack di applicazioni server non funziona correttamente. Puoi concentrarti ulteriormente la risoluzione dei problemi sull'applicazione stessa. Se tutti i server si comportano correttamente, il passaggio successivo consiste nell'esaminare il lato client e la rete.
Verificare la connettività e la latenza di rete
Se tutti i server di backend rispondono correttamente alle richieste, verifica latenza di rete. Dalla VM di un client, invia un comando ping costante a ciascuno dei server, come segue:
ping SERVER_IP_ADDRESS
Questo test mostra la latenza di rete integrata e se la rete perde pacchetti. In alcuni casi, le regole del firewall potrebbero bloccare il traffico ICMP. Se sì, questo test non restituisce alcun risultato. Rivolgiti all'amministratore delle regole del firewall per verificare se è così.
Se il comando ping
mostra una latenza notevolmente superiore al normale o una perdita di pacchetti significativa, apri una richiesta all'assistenza Google Cloud per effettuare ulteriori accertamenti.
Identificare le combinazioni client-server problematiche
Se il test della rete ping
suggerisce una bassa latenza e nessuna perdita di pacchetti,
il passaggio successivo consiste nell'identificare l'eventuale combinazione client-server specifica
produce risultati problematici. Per farlo, riduci la metà del numero di server di backend finché il numero di server non raggiunge 1, riproducendo contemporaneamente il comportamento problematico (ad esempio latenza elevata 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, vai ai test delle prestazioni.
Esegui acquisizione e analisi del traffico
Se identifichi una combinazione problematica specifica di client-server, puoi utilizzare l'acquisizione dei pacchetti per individuare la parte della comunicazione che causa ritardi o interruzioni. La cattura dei pacchetti può essere eseguita con tcpdump come segue:
- 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.
Esegui test di prestazioni
Se non identifichi combinazioni client-server problematiche e il rendimento aggregato di tutti i client e i server è inferiore alle aspettative, valuta i seguenti test:
- Un client e un server, senza bilanciamento del carico.
Un 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 client e più server, con bilanciamento del carico.
Risultato: identifica il limite di rendimento di un cliente.
Più client e un server con bilanciamento del carico.
Risultato: identifica il limite di rendimento di un server.
Più client e più server, senza bilanciamento del carico.
Risultato: identifica il limite di rendimento della rete.
Quando si esegue un test di stress con più client e server, client o server (CPU, memoria, I/O) potrebbero diventare colli di bottiglia e ridurre il numero che consentono di analizzare i dati e visualizzare i risultati. I risultati aggregati con degradazione possono verificarsi anche se ogni client e server si comporta correttamente.
Risoluzione dei problemi del VPC condiviso
Se utilizzi 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 o contatta l'amministratore della tua organizzazione. Per ulteriori informazioni, consulta la 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 integre
- Disattivare lo svuotamento delle connessioni in caso di failover
Problemi relativi ai gruppi di istanze gestite e al failover
- Sintomo: il pool attivo cambia avanti e indietro (flapping) tra il backend primari e di failover.
- Possibile causa: utilizzo di gruppi di istanze gestite con scalabilità automatica e potrebbe causare un failover e un failover ripetuti per il pool attivo tra il backend principale e quello di failover. Google Cloud non ti impedisce di configurare il failover con i gruppi di istanze gestite, perché il tuo deployment potrebbe trarre vantaggio da questa configurazione.
Disattivare la limitazione dello svuotamento delle connessioni per i gruppi di failover
La disabilitazione dello svuotamento della connessione funziona solo se il servizio di backend è configurato con TCP.
Se crei un servizio di backend con UDP, viene visualizzato il seguente messaggio di errore mentre lo svuotamento della connessione è disabilitato:
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, è il comportamento previsto che le connessioni abbiano inviato all'indirizzo IP alle regola di forwarding del bilanciatore del carico viene sempre inviata una risposta dalla VM di backend per trovare le regole. Per ulteriori informazioni, consulta la sezione relativa al test delle connessioni da un singolo client e all'invio di richieste da VM bilanciate in base al carico.
Se la VM client non è una VM di backend del bilanciatore del carico:
Per le richieste da un singolo client, consulta la sezione sul test delle connessioni da un singolo client client in modo da comprendere i limiti questo metodo.
Assicurati di aver configurato regole firewall di autorizzazione in entrata per consentire i controlli di integrità.
Per una configurazione di failover, assicurati di comprendere come funziona l'appartenenza il pool attivo funziona e quando Google Cloud esegue il failover e di failover. Controlla la configurazione del bilanciatore del carico:
Utilizza la console Google Cloud per verificare il numero di backend in stato integro VM in ogni gruppo di istanza di backend. La console Google Cloud mostra anche per identificare 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 pari a0.0
ha un significato speciale: Google Cloud esegue un failover quando nessuna VM primaria è integra.
Le connessioni esistenti vengono interrotte durante il failover o il failback
Modifica il criterio di failover del servizio di backend. Assicurati che lo svuotamento della connessione al failover sia abilitato.
Risolvi i problemi del bilanciatore del carico come problemi dell'hop successivo
Quando imposti un bilanciatore del carico di rete passthrough interno come successivo hop di una route statica personalizzata, i seguenti problemi che potrebbero verificarsi:
Problemi di connettività
Se non puoi inviare un ping a un indirizzo IP nell'intervallo di destinazione di una route l'hop successivo è una regola di forwarding per un bilanciatore del carico di rete passthrough interno. Tieni presente utilizzando 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 inoltreranno automaticamente tutto il traffico di protocollo (TCP, UDP e ICMP), indipendentemente da quando è stata creata una route. Se non vuoi attendere fino ad allora, puoi abilitare subito la funzionalità di ping creando nuovi percorsi precedenti ed eliminando quelli vecchi.
Quando si utilizza un bilanciatore del carico di rete passthrough interno come hop successivo per un una route statica, tutto il traffico viene inviato VM di backend integre, a prescindere dal protocollo configurato per il carico servizio di backend interno del bilanciatore e indipendentemente dalla porta o dalle porte configurato sulla regola di forwarding interno del bilanciatore del carico.
Assicurati di aver creato correttamente regole firewall di autorizzazione in entrata che identificare le origini di traffico da consegnare alle VM di backend tramite dell'hop successivo della route statica personalizzata. I pacchetti che arrivano nelle VM di backend vengono conservati i propri indirizzi IP di origine, anche quando vengono consegnati tramite una percorso.
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 subnet nella rete VPC. Se ricevi quanto segue 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 corrisponde a o è più specifico (con una maschera più lunga) rispetto a route subnet Per ulteriori informazioni, consulta la sezione relativa a applicabilità e ordine.
Se i pacchetti arrivano a una destinazione imprevista, rimuovi altre route nella tua rete VPC con destinazioni. Esamina l'ordine di routing per comprendere la selezione delle route di Google Cloud.
Risolvere i problemi di logging
Se configuri la registrazione per un bilanciatore del carico di rete passthrough interno, potrebbero verificarsi i seguenti problemi:
- Le misurazioni del RTT, come i valori in byte, potrebbero non essere presenti in alcuni log se non vengono campionati pacchetti sufficienti per acquisire il RTT. Questo accade più spesso per le connessioni a basso volume.
- I valori RTT sono disponibili solo per i flussi TCP.
- Alcuni pacchetti vengono inviati senza payload. Se vengono campionati pacchetti solo con intestazione,
il valore in byte è
0
.
Passaggi successivi
- Consulta: il logging del bilanciatore del carico di rete passthrough interno Monitoring per informazioni sulla configurazione Logging e monitoraggio per bilanciatori del carico di rete passthrough interni.
- Consulta la sezione Bilanciatori del carico di rete passthrough interni e reti connesse per informazioni su come accedere ai bilanciatori del carico di rete passthrough interni dalle reti peer connesse alla tua rete VPC.