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 Google Cloud . Prima di esaminare i problemi, acquisisci familiarità con 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 quelle errate. Identifica gli errori di rete, fornisce informazioni sulla causa principale e suggerisce possibili soluzioni. Per scoprire i diversi scenari di configurazione errata rilevati automaticamente 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.

Ciò si verifica quando tenti di 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 delle regole firewall

  • Assicurati che le regole firewall di autorizzazione in entrata siano definite per consentire 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 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 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 integra, ma non al bilanciatore del carico, è possibile che l'ambiente guest (in precedenza, l'ambiente guest Windows o 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 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 per accettare i pacchetti inviati al bilanciatore del carico. ovvero 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 da immagini Google Cloud , l'agente guest 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 invece 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'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 questo è il comportamento previsto.

Il software in esecuzione sulla VM di backend deve:

  • In ascolto (associato) all'indirizzo IP del bilanciatore del carico o a qualsiasi indirizzo IP (0.0.0.0 o ::)
  • In ascolto (associato) a una porta inclusa nella regola di forwarding del bilanciatore del carico

Per testare questa funzionalità, connettiti a una VM di backend utilizzando SSH o RDP. Quindi esegui i seguenti test utilizzando curl, telnet o uno strumento simile:

  • Tenta di raggiungere il servizio contattandolo utilizzando l'indirizzo IP interno della VM di backend stessa, 127.0.0.1 o localhost.
  • Tenta di raggiungere il servizio contattandolo utilizzando l'indirizzo IP della regola di forwarding 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"Integrità" per il backend.

Se non sono presenti istanze integre nel backend, assicurati che il controllo di integrità appropriato sia configurato 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 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 questo comando:

curl localhost:PORT

Anche in questo caso, sostituisci PORT con la porta che hai configurato per il controllo di integrità.

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>

Non determina se il routing è configurato correttamente per rispondere all'indirizzo IP del bilanciatore del carico. Si tratta di 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 Verifica che le VM di backend accettino i pacchetti inviati al bilanciatore del carico.

Risolvere i problemi di prestazioni

Se noti problemi di prestazioni e aumento della latenza, verifica la presenza dei 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 emesse direttamente sul server. Ad esempio, se il client invia richieste HTTP al server tramite il bilanciatore del carico e non riceve risposta o la risposta è molto più lenta del normale, invia la stessa richiesta HTTP a 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 stesso, puoi concludere che lo stack di applicazioni del server non funziona correttamente. Puoi concentrarti ulteriormente sulla risoluzione dei problemi dell'applicazione stessa. Se tutti i server si comportano correttamente, il passaggio successivo consiste nell'esaminare il lato client e la rete.

Verifica la connettività di rete e la latenza

Se tutti i server di backend rispondono correttamente alle richieste, verifica la latenza di rete. Da una VM 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 sta eliminando pacchetti. In alcuni casi, le regole del firewall potrebbero bloccare il traffico ICMP. In questo caso, il test non produce alcun risultato. Verifica con l'amministratore delle regole firewall se è così.

Se il comando ping mostra una latenza significativamente superiore al normale o una perdita di pacchetti significativa, apri una richiesta di assistenza Google Cloud per ulteriori indagini.

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 quale combinazione specifica client-server, se presente, produce risultati problematici. Puoi farlo riducendo il numero di server di backend della metà 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 l'acquisizione e l'analisi del traffico.

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

Eseguire l'acquisizione e l'analisi del traffico

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

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

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

    curl URL

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

Esegui test delle prestazioni

Se non identifichi combinazioni client-server problematiche e le prestazioni aggregate di tutti i client e server insieme sono inferiori al previsto, prendi in considerazione 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 esegui un test di stress con più client e server, le risorse client o server (CPU, memoria, I/O) potrebbero diventare colli di bottiglia e ridurre i risultati aggregati. I risultati aggregati degradati possono 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 bilanciamento del carico di rete pass-through interno in una subnet specifica, la causa potrebbe essere una policy dell'organizzazione. Nella policy 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, segui questi passaggi per verificare la configurazione:

  • Assicurati di aver configurato regole firewall di autorizzazione in entrata per consentire i controlli di integrità.
  • Assicurati di comprendere i concetti di selezione e monitoraggio della connessione backend e di failover.
  • Assicurati di aver designato almeno un backend di failover.
  • Esamina quali backend sono integri utilizzando la console Google Cloud o gcloud compute backend-services get-health per determinare quali VM sono backend idonei.
  • Assicurati che il rapporto di failover sia impostato correttamente.
  • Sconsigliamo di utilizzare gruppi di istanze gestite con la scalabilità automatica abilitata in combinazione con il failover, perché la scalabilità automatica modifica il numero di backend primari, backend di failover o entrambi. Ciò può comportare la modifica imprevista dell'insieme di backend idonei perché il rapporto di failover è fisso.
  • Se una VM client è anche una VM di backend con bilanciamento del carico, le connessioni all'indirizzo IP della regola di forwarding del bilanciatore del carico vengono inviate alla VM di backend stessa. Per maggiori informazioni, consulta Test da un singolo client.

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 riesci a eseguire il ping di 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 dalla data di creazione di una route. Se non vuoi attendere fino ad allora, puoi attivare subito la funzionalità ping 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 recapitato alle VM di backend integre 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 interna del bilanciatore del carico.

  • Assicurati di aver creato regole firewall di autorizzazione in entrata che identifichino correttamente le origini del traffico che deve essere inviato 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 consegnati 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 tua rete VPC. Se ricevi 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 corrisponda esattamente o sia più specifica (con una maschera più lunga) di una route subnet. Per ulteriori informazioni, consulta la sezione 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 Google Cloud la selezione del percorso.

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 RTT, come i valori dei byte, potrebbero mancare in alcuni log se non vengono campionati pacchetti sufficienti per acquisire l'RTT. È più probabile che ciò accada 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 di intestazione, il valore dei byte è 0.

Passaggi successivi