Risolvere i problemi relativi ai bilanciatori del carico delle applicazioni esterni

Questa guida descrive come risolvere i problemi di configurazione per gli Application Load Balancer esterni. Prima di esaminare i problemi, consulta le seguenti pagine:

• Panoramica del bilanciatore del carico delle applicazioni esterno
• Logging e monitoraggio del bilanciatore del carico delle applicazioni esterno

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 i guasti di rete, fornisce informazioni sulle cause principali e suggerisce possibili soluzioni. Per scoprire i diversi scenari di configurazione errata rilevati automaticamente da Network Analyzer, consulta Insight 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:

• Limitazioni e indicazioni per i gruppi di istanze
• Modifica la modalità di bilanciamento di un bilanciatore del carico

Risolvere i problemi generali di connettività

Errori 5XX inspiegabili

Per le condizioni di errore causate da un problema di comunicazione tra il proxy del bilanciatore del carico e i suoi backend, il bilanciatore del carico genera un codice di risposta di errore HTTP (5XX) e restituisce tale codice al client. Non tutti gli errori HTTP 5XX vengono generati dal bilanciatore del carico: ad esempio, se un backend invia una risposta HTTP 5XX al bilanciatore del carico, il bilanciatore del carico inoltra la risposta al client. Per determinare se una risposta HTTP 5XX è stata inoltrata da un backend o se è stata generata dal proxy del bilanciatore del carico, fai riferimento al campo statusDetails dei log del bilanciatore del carico.

Se statusDetails restituisce una stringa di log response_sent_by_backend, il bilanciatore del carico si limita a inoltrare il codice di risposta inviato dal backend. In tal caso, dovrai risolvere i problemi relativi alle risposte di errore HTTP nei backend.

Per le risposte di errore HTTP con statusDetails non corrispondente alla stringa di log response_sent_by_backend:

• L'Application Load Balancer esterno globale e l'Application Load Balancer esterno regionale generano codici di errore significativi come risposte HTTP come 503 (Servizio non disponibile) e 504 (Timeout gateway).

• Il bilanciatore del carico delle applicazioni classico utilizza sempre il codice di errore della risposta HTTP 502.

Le modifiche alla configurazione del bilanciatore del carico delle applicazioni esterno globale, come l'aggiunta o la rimozione di un servizio di backend, possono comportare per un breve periodo di tempo la visualizzazione del codice di errore della risposta HTTP 502. Mentre queste modifiche alla configurazione si propagano ai GFE a livello globale, vedrai voci di log in cui il campo statusDetails corrisponde alla stringa di log failed_to_pick_backend.

Se gli errori HTTP 5XX persistono per più di qualche minuto dopo aver completato la configurazione del bilanciatore del carico, segui questi passaggi per risolvere i problemi relativi alle risposte HTTP 5XX:

1. Verifica che sia presente una regola firewall configurata per consentire i controlli di integrità. In assenza di tale valore, i log del bilanciatore del carico hanno in genere un valore failed_to_pick_backend corrispondente a statusDetails, che indica che il bilanciatore del carico non è riuscito a scegliere un backend integro per gestire la richiesta.

2. Verifica che il traffico del controllo di integrità raggiunga le VM di backend. A questo scopo, abilita il logging del controllo di integrità e cerca le voci di log riuscite.

   Per i nuovi bilanciatori del carico, la mancanza di voci di log per il controllo di integrità riuscito non significa che il traffico del controllo di integrità non raggiunge i backend. Potrebbe significare che lo stato di integrità iniziale del backend non è ancora cambiato da UNHEALTHY a uno stato diverso. Vedrai le voci di log del controllo di integrità riuscite solo dopo che il prober del controllo di integrità ha ricevuto una risposta HTTP 200 OK dal backend.

3. Verifica che il software nei backend sia in esecuzione. A questo scopo, controlla se la risposta 5xx viene gestita dal bilanciatore del carico o se viene generata dai backend. Svolgi i seguenti passaggi:

   1. Utilizza Cloud Logging per visualizzare i log del bilanciatore del carico. Puoi creare una query per cercare solo i codici di risposta 5xx.

   2. Controlla il valore del campo statusDetails:

      • Se statusDetails restituisce un messaggio riuscito, ad esempio response_sent_by_backend, è il backend che pubblica le risposte HTTP 502. Controllare i log sul backend e risolvere ulteriormente i problemi a seconda del servizio in esecuzione sul backend.
      • Se statusDetails restituisce un messaggio di errore, consulta il seguente elenco di soluzioni per alcuni errori comuni relativi alle risposte 5xx:

      Messaggio di errore statusDettagli	Potenziali cause e soluzioni
      failed_to_connect_to_backend	Il bilanciatore del carico non è riuscito a stabilire una connessione con il backend. Questo potrebbe significare che il servizio in esecuzione sul backend non è in ascolto sulla porta definita nel servizio di backend. Consigli: Imposta la porta del controllo di integrità in modo che utilizzi la porta di gestione. Ciò significa che il backend non sarà integro prima di essere idoneo a gestire il traffico reale. Usa il comando seguente per assicurarti che esista un servizio in esecuzione sulla porta denominata del servizio di backend: $ netstat -tnl | grep PORT
      failed_to_pick_backend	Il bilanciatore del carico non può scegliere un backend. Ciò potrebbe significare che tutti i backend sono in stato non integro. Assicurati di aver configurato le regole firewall corrette per i controlli di integrità.
      backend_connection_closed_before_data_sent_to_client	Il backend ha chiuso in modo imprevisto la connessione al bilanciatore del carico prima che la risposta venisse inviata al client tramite proxy. Questo può accadere se il bilanciatore del carico invia traffico a un'altra entità. L'altra entità potrebbe essere un bilanciatore del carico di terze parti con un timeout TCP più breve di quello del bilanciatore del carico. Per maggiori dettagli, consulta l'articolo Timeout e nuovi tentativi.
      backend_timeout	Il backend ha impiegato troppo tempo per rispondere. Il timeout del servizio di backend potrebbe essere impostato su un valore troppo basso per consentire al servizio specificato di rispondere. Valuta la possibilità di aumentare il timeout del servizio di backend o verifica perché il servizio impiega così tempo a rispondere.

4. Verifica che il parametro di configurazione keepalive per il software server HTTP in esecuzione sull'istanza di backend non sia inferiore al timeout keepalive del bilanciatore del carico, il cui valore è fisso su 10 minuti (600 secondi) e non è configurabile.

   Il bilanciatore del carico genera un codice di risposta HTTP 5XX quando la connessione al backend si è chiusa inaspettatamente durante l'invio della richiesta HTTP o prima che venga ricevuta la risposta HTTP completa. Ciò può accadere perché il parametro di configurazione keepalive per il software del server web in esecuzione sull'istanza di backend è inferiore al timeout keepalive fisso del bilanciatore del carico. Assicurati che la configurazione del timeout keepalive per il software del server HTTP su ogni backend sia impostata su un valore leggermente superiore a 10 minuti (il valore consigliato è 620 secondi).

Risoluzione degli errori HTTP 408

Con il traffico HTTP, il tempo massimo necessario al client per completare l'invio della sua richiesta è pari al timeout del servizio di backend. Se vedi le risposte HTTP 408 con il client_timed_out di jsonPayload.statusDetail, significa che non sono stati eseguiti avanzamenti sufficienti mentre la richiesta del client è stata inviata tramite proxy o la risposta del backend è stata inviata tramite proxy. Se il problema è dovuto a client che hanno problemi di prestazioni, puoi risolverlo aumentando il timeout del servizio di backend.

Il traffico con bilanciamento del carico non ha l'indirizzo di origine del client originale

L'indirizzo IP di origine per i pacchetti, come visto dai backend, non è l'indirizzo IP esterno del bilanciatore del carico. I bilanciatori del carico basati su proxy, come gli Application Load Balancer esterni, utilizzano due connessioni TCP per trasmettere il traffico dal client ai backend:

• Connessione 1, dal client originale al bilanciatore del carico (GFE o subnet solo proxy)
• Connessione 2, dal bilanciatore del carico (GFE o subnet solo proxy) alla VM o all'endpoint di backend

Gli indirizzi IP di origine e di destinazione per ogni connessione variano in base al tipo di Application Load Balancer esterno che stai utilizzando. Per maggiori dettagli, consulta Indirizzi IP di origine per i pacchetti client .

Compare un errore di autorizzazione quando provo a visualizzare un oggetto nel mio bucket Cloud Storage

Per gestire gli oggetti tramite il bilanciamento del carico, gli oggetti Cloud Storage devono essere accessibili pubblicamente. Assicurati di aggiornare le autorizzazioni degli oggetti pubblicati in modo che siano leggibili pubblicamente.

L'URL non gestisce l'oggetto Cloud Storage previsto

L'oggetto Cloud Storage da pubblicare è determinato in base alla mappa URL e all'URL richiesto. Se il percorso della richiesta è mappato a un bucket di backend nella mappa URL, l'oggetto Cloud Storage viene determinato aggiungendo il percorso di richiesta completo al bucket Cloud Storage specificato dalla mappa URL.

Ad esempio, se mappi /static/* a gs://[EXAMPLE_BUCKET], la richiesta a https://<GCLB IP or Host>/static/path/to/content.jpg proverà a essere pubblicata gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Se l'oggetto non esiste, al posto dell'oggetto viene visualizzato il seguente messaggio di errore:

NoSuchKey
The specified key does not exist.

La compressione non funziona

Un bilanciatore del carico delle applicazioni esterno non comprime né decomprime le risposte autonomamente, ma può fornire risposte generate dal servizio di backend che vengono compresse utilizzando strumenti come gzip o DEFLATE.

Se le risposte fornite dal bilanciatore del carico non sono compresse, ma dovrebbero esserlo, assicurati che il software del server web in esecuzione sulle tue istanze sia configurato in modo da comprimere le risposte. Per impostazione predefinita, alcuni software per server web disattivano automaticamente la compressione per le richieste che includono un'intestazione Via, a indicare che la richiesta è stata inoltrata da un proxy. Poiché si tratta di un proxy, l'Application Load Balancer esterno aggiunge un'intestazione Via a ogni richiesta come richiesto dalla specifica HTTP. Per attivare la compressione, potresti dover eseguire l'override della configurazione predefinita del server web per indicare di comprimere le risposte anche se la richiesta aveva un'intestazione Via.

Per configurare i backend nginx in modo che forniscano risposte compresse inviate tramite proxy tramite un bilanciatore del carico delle applicazioni esterno:

• Imposta la direttiva gzip_proxied in modo appropriato (ad esempio, su any) e
• Imposta l'istruzione gzip_vary su on.

Per configurare i backend Apache in modo da fornire risposte compresse inviate tramite proxy tramite un bilanciatore del carico delle applicazioni esterno:

• Usa il filtro DEFLATE e
• Aggiungi Vary Accept-Encoding all'intestazione della risposta utilizzando il modulo mod_headers.

Risolvere i problemi relativi ai backend in stato non integro

Risolvere i problemi relativi a HTTP/2 nei backend

Assicurati che l'istanza di backend sia integro e supporti il protocollo HTTP/2. Puoi verificarlo testando la connettività all'istanza di backend tramite HTTP/2. Assicurati che la VM utilizzi suite di crittografia conformi alle specifiche HTTP/2. Ad esempio, alcune suite di crittografia TLS 1.2 non sono consentite da HTTP/2. Consulta la lista nera TLS 1.2 Cipher Suite.

Dopo aver verificato che la VM utilizzi il protocollo HTTP/2, assicurati che la configurazione del firewall consenta il passaggio del controllo di integrità e del bilanciatore del carico.

Se non ci sono problemi con la configurazione del firewall, assicurati che il bilanciatore del carico sia configurato per comunicare con la porta corretta sulla VM.

Risolvere i problemi relativi a backend esterno e NEG internet

Prima di esaminare i problemi, consulta le seguenti pagine:

• Panoramica dei NEG internet
• Configura un bilanciatore del carico delle applicazioni esterno globale con un backend esterno (NEG internet)

Il traffico non raggiunge gli endpoint

Dopo aver configurato un servizio, il nuovo endpoint diventa raggiungibile tramite il bilanciatore del carico delle applicazioni esterno quando:

• L'endpoint è collegato al NEG internet.
• Il nome di dominio completo associato può essere risolto correttamente tramite DNS (se utilizzi il tipo di endpoint FQDN).
• L'endpoint è accessibile tramite internet.

Se il traffico non riesce a raggiungere l'endpoint, generando un codice di errore 502, esegui una query sul record TXT DNS di _cloud-eoips.googleusercontent.com utilizzando uno strumento come dig o nslookup. Prendi nota dei CIDR (seguenti a ip4:) e assicurati che questi intervalli siano consentiti dal firewall o dall'elenco di controllo dell'accesso (ACL) del cloud.

Dopo aver configurato un backend esterno, le richieste al backend esterno non sono riuscite con un errore 5xx

• Seleziona Logging.
• Verifica che il gruppo di endpoint di rete sia configurato con l'indirizzo IP:porta o FQDN:porta corretto per il backend esterno.
• Se utilizzi il nome di dominio completo, assicurati che sia risolvibile tramite Google Public DNS. Puoi verificare che il nome di dominio completo sia risolvibile tramite Google Public DNS seguendo questi passaggi o direttamente l'interfaccia web.
• Se accedi al bilanciatore del carico solo sul relativo IP esterno e il server web di origine richiede un nome host, assicurati di inviare un'intestazione host HTTP valida al tuo backend configurando un'intestazione della richiesta personalizzata.
• Se comunichi con un backend tramite HTTPS o HTTP2 (come impostato nel campo protocol del servizio di backend) configurato come endpoint di backend esterno INTERNET_FQDN_PORT, assicurati che la tua origine presenti un certificato TLS (SSL) valido e che il nome di dominio completo configurato corrisponda a una SAN (Subject Alternative Name) presente nell'elenco di SAN dei certificati. Per certificato valido si intende un certificato firmato da un'autorità di certificazione pubblica che non è scaduto.
• Quando utilizzi INTERNET_FQDN_PORT endpoint di backend esterni, i certificati autofirmati non sono accettati dal bilanciatore del carico e vengono rifiutati.
• Quando utilizzi HTTPS o HTTP/2 con endpoint di tipo INTERNET_IP_PORT, non viene eseguito alcun controllo SAN/convalida dei certificati SSL. Ciò significa che è possibile usare certificati autofirmati. Quando si utilizza il protocollo SSL, consigliamo di utilizzare endpoint INTERNET_FQDN_PORT per garantire la convalida dei certificati server e delle SAN.

Le risposte del mio backend esterno non vengono memorizzate nella cache da Cloud CDN

Assicurati che:

• Hai abilitato Cloud CDN sul servizio di backend contenente il NEG che punta al tuo backend esterno impostando enableCDN su true.
• Le risposte fornite dal tuo backend esterno soddisfano i requisiti di memorizzazione nella cache di Cloud CDN. Ad esempio, stai inviando intestazioni di risposta Cache-Control: public, max-age=3600 dall'origine.

Risolvere i problemi relativi ai NEG serverless

Prima di esaminare i problemi, consulta le seguenti pagine:

• Panoramica dei NEG serverless
• Configura un bilanciatore del carico delle applicazioni esterno globale con NEG serverless

Le richieste non vanno a buon fine con un errore 404

Assicurati che la risorsa serverless sottostante (ad esempio un servizio App Engine, Cloud Functions o Cloud Run) sia ancora in esecuzione. Se la risorsa serverless viene eliminata, ma il NEG serverless esiste ancora, l'Application Load Balancer esterno continuerà a tentare di instradare le richieste al servizio inesistente. Questo comporta una risposta 404.

In generale, un bilanciatore del carico delle applicazioni esterno non è in grado di rilevare se la risorsa serverless sottostante funziona come previsto. Ciò significa che se il tuo servizio in una regione restituisce errori, ma l'infrastruttura Cloud Run, Cloud Functions o App Engine complessiva di quella regione funziona normalmente, il bilanciatore del carico delle applicazioni esterno non indirizzerà automaticamente il traffico verso altre regioni. Assicurati di testare accuratamente le nuove versioni dei tuoi servizi prima di instradare il traffico degli utenti a queste ultime.

Gestione delle mancate corrispondenze delle maschere URL

Se l'applicazione della maschera URL configurata a un URL di richiesta di un utente non restituisce un nome di servizio o se restituisce un nome di servizio che non esiste, il bilanciatore del carico potrebbe gestire queste mancate corrispondenze in modo diverso a seconda della piattaforma di serverless computing in uso.

Cloud Run: in caso di mancata corrispondenza di una maschera URL, il bilanciatore del carico restituisce un errore HTTP 404 (Not Found).

Cloud Functions: in caso di mancata corrispondenza di una maschera URL, il bilanciatore del carico restituisce un errore HTTP 404 (Not Found).

App Engine: in caso di mancata corrispondenza di una maschera URL, App Engine utilizza dispatch.yaml e la logica di routing predefinita di App Engine per determinare a quale servizio inviare la richiesta.