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 di Network Analyzer

Network Analyzer monitora automaticamente la configurazione di rete VPC e rileva sia le configurazioni non ottimali sia le configurazioni errate. Identifica gli errori della rete, fornisce informazioni sulla causa principale e suggerisce possibili soluzioni. Per informazioni sui diversi scenari di configurazione errata rilevati automaticamente da Network Analyzer, consulta Approfondimenti sui bilanciatori 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 di connettività generali

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

Verifica le regole del firewall

  • Assicurati che le regole firewall in entrata consentano i 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 le VM 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 riesci a connetterti a una VM di backend funzionante, ma non riesci a connetterti al bilanciatore del carico, è possibile che l'ambiente guest (in precedenza Ambiente guest Windows o Ambiente guest Linux) 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 del firewall nel sistema operativo guest della VM di backend (iptables o Windows Firewall) non blocchino l'accesso al server dei metadati.

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

Ogni VM di backend deve essere configurata per 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 una route locale.

Per le VM create dalle immagini Google Cloud, l'agente ospite installa la route locale 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 il seguente 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'associazione dell'indirizzo IP e della porta del servizio 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 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:

  • Ascolta (è associato) all'indirizzo IP del bilanciatore del carico o a 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:

  • 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 inoltro del bilanciatore del carico.

Controlla 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 integra visualizzando lo stato"Integro" 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 del 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 configurata per il controllo dell'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 accettino 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 tramite il bilanciatore del carico e non viene ricevuta alcuna risposta o la risposta è notevolmente 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 inviata dal server stesso, puoi concludere che lo stack delle applicazioni del server non funziona correttamente. Puoi concentrarti ulteriormente sulla risoluzione dei problemi relativi all'applicazione stessa. Se tutti i server si comportano correttamente, il passaggio successivo consiste nell'esaminare il lato client e la rete.

Verifica la connettività e la latenza della rete

Se tutti i server di backend rispondono correttamente alle richieste, verifica la latenza della rete. Da una VM client, emetti 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. In tal caso, il test non restituisce alcun risultato. Verifica con l'amministratore delle regole firewall 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.

Identifica le combinazioni client-server problematiche

Se il test ping della rete suggerisce una latenza bassa e nessuna perdita di pacchetti, il passaggio successivo consiste nell'identificare la combinazione client-server specifica, se presente, che produce risultati problematici. A questo scopo, puoi dimezzare il 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 la acquisizione e l'analisi del traffico.

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

Eseguire l'acquisizione e l'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:

  1. Installa tcpdump sul server.
  2. Avvia l'acquisizione tcpdump sul server.

  3. Da un client, emetti una richiesta di esempio, ad esempio la seguente:

    curl URL

  4. Analizza l'output di tcpdump per identificare il problema.

Eseguire 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:

  1. Un client e un server, senza bilanciamento del carico.

  2. Un client e un server con bilanciamento del carico.

    Risultato: la combinazione dei risultati dei test [1] e [2] consente di identificare se il problema è causato dal bilanciatore del carico.

  3. Un client e più server, con bilanciamento del carico.

    Risultato: identifica il limite di rendimento di un cliente.

  4. Più client e un server, con bilanciamento del carico.

    Risultato: identifica il limite di rendimento di un server.

  5. Più client e più server, senza bilanciamento del carico.

    Risultato: identifica il limite di rendimento della rete.

Quando esegui un test di stress con più client e server, le risorse del client o del server (CPU, memoria, I/O) potrebbero diventare colli di bottiglia e ridurre i risultati aggregati. I risultati aggregati con degradazione possono verificarsi anche se ogni client e server si comporta correttamente.

Risolvere i problemi relativi alla rete VPC condivisa

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 sottorete all'elenco delle sottoreti consentite o contatta l'amministratore dell'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 del criterio di failover:
    • Rapporto di failover
    • Eliminazione del traffico quando tutte le VM di backend non sono integre
    • Disattivare svuotamento della connessione in caso di failover

Problemi relativi ai gruppi di istanze gestite e al failover

  • Sintomo: il pool attivo passa da un backend principale a un backend di failover e viceversa (flapping).
  • Possibile motivo: l'utilizzo di gruppi di istanze gestite con la scalabilità automatica e il failover potrebbe causare ripetutamente il failover e il failback del pool attivo tra i backend principali e 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 svuotamento della connessione per i gruppi di failover

La disattivazione 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 svuotamento della connessione è disattivato, 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, è normale che le connessioni inviate all'indirizzo IP della regola di inoltro del bilanciatore del carico ricevano sempre una risposta dalla stessa VM di backend. 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 provenienti da un singolo client, consulta la sezione Testare le connessioni da un singolo client per comprendere le limitazioni di 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 il funzionamento dell'appartenenza al pool attivo e quando Google Cloud esegue il failover e il failback. Controlla la configurazione del bilanciatore del carico:

    • Utilizza la console Google Cloud per controllare 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 pari a 0.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 svuotamento della connessione al failover sia abilitato.

Risolvere 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 riesci a eseguire 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. 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 dal momento in cui è stata creata una route. Se non vuoi attendere, puoi attivare la funzionalità di ping ora creando nuovi percorsi ed eliminando quelli vecchi.

  • Quando utilizzi un bilanciatore del carico di rete passthrough interno come hop successivo per una route statica personalizzata, tutto il traffico viene inviato alle VM di backend in buono stato del bilanciatore del carico, indipendentemente dal protocollo configurato per il servizio di backend interno del bilanciatore del carico e dalle porte configurate nella regola di forwarding interna del bilanciatore del carico.

  • Assicurati di aver creato regole firewall di autorizzazione in entrata che identifichino correttamente le sorgenti di traffico da inviare alle VM di backend tramite l'hop successivo della route statica personalizzata. I pacchetti che arrivano sulle VM di backend mantengono i propri indirizzi IP di origine, anche se vengono inviati 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 subnet nella rete VPC. Se ricevi il seguente messaggio di errore quando crei 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, consulta la sezione relativa a applicabilità e ordine.

  • Se i pacchetti arrivano a una destinazione imprevista, rimuovi altre route nella rete VPC con destinazioni più specifiche. Esamina l'ordine di routing per comprendere la selezione delle route di Google Cloud.

Risolvere i problemi di registrazione

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 con volume ridotto.
  • 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