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

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

  3. Da un client, invia una richiesta di esempio, come la seguente:

    curl URL

  4. 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:

  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] identifica 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 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 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 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