Risolvere i problemi relativi ai bilanciatori del carico delle applicazioni esterni

Questa guida descrive come risolvere i problemi di configurazione per i bilanciatori del carico delle applicazioni esterni. 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. 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 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

Errori 5XX inspiegabili

Per le condizioni di errore causate da un problema di comunicazione tra il bilanciatore del carico proxy e i relativi backend, il bilanciatore del carico genera un codice di risposta di errore HTTP (5XX) e restituisce questo codice di risposta di errore al client. Non tutte le richieste HTTP 5XX vengono generati dal bilanciatore del carico, ad esempio se un backend invia una risposta HTTP 5XX al bilanciatore del carico, quest'ultimo inoltra che la risposta al suo 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 carico semplicemente inoltra qualsiasi codice di risposta inviato dal backend, In questo caso, dovrai risolvere i problemi relativi alle risposte di errore HTTP sui tuoi backend.

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

  • Il bilanciatore del carico delle applicazioni esterno globale e il bilanciatore del carico delle applicazioni esterno regionale Generare codici di errore significativi di risposta 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 un breve periodo di tempo in cui gli utenti visualizzano il codice di errore della risposta HTTP 502. Anche se queste configurazioni cambiano propaga GFE a livello globale, vengono visualizzate le voci di log in cui il campo statusDetails corrisponde Stringa di log failed_to_pick_backend.

Se gli errori HTTP 5XX persistono dopo qualche minuto dal completamento della 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 l'integrità controlli. Nella In assenza di uno, i log del bilanciatore del carico in genere hanno una corrispondenza di statusDetails failed_to_pick_backend, che indica che il bilanciatore del carico non è riuscito a e scegli un backend integro per gestire la richiesta.

  2. Verifica che il traffico del controllo di integrità raggiunga le VM di backend. Per farlo, 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 del controllo di integrità riuscite non significa che il traffico del controllo di integrità non raggiunga i backend. Potrebbe significare che lo stato di integrità iniziale del backend non è ancora cambiato da UNHEALTHY a uno diverso. Vengono visualizzate voci di log del controllo di integrità riuscite solo dopo che il prober del controllo di integrità riceve una risposta HTTP 200 OK di un backend cloud.

  3. Verifica che il software dei backend sia in esecuzione. A questo scopo, controlla se la risposta 5xx viene fornita dal bilanciatore del carico o se generati dai backend. Procedi nel seguente modo:

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

    2. Verifica il valore del campo statusDetails:

      • Se statusDetails restituisce un messaggio di operazione riuscita, ad esempio response_sent_by_backend, è il backend che fornisce le risposte HTTP 502. Controlla i log sul backend e risolvi ulteriormente i problemi a seconda del in esecuzione sul backend.
      • Se statusDetails restituisce un errore messaggio, Fai riferimento al seguente elenco di soluzioni per alcuni errori comuni correlato alle risposte 5xx:
      Messaggio di errore statusDettagli Possibili cause e soluzioni
      failed_to_connect_to_backend

      Il bilanciatore del carico non è riuscito a stabilire una connessione con il backend. Ciò 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 da utilizzare la porta in uso. Ciò significa che il backend verrà considerato non in stato di salute prima di essere idoneo a gestire il traffico reale.
      • Utilizza il seguente comando per assicurarti che sia in esecuzione un servizio sulla porta denominata del servizio di backend: 
        $ netstat -tnl | grep PORT
      failed_to_pick_backend

      Il bilanciatore del carico non è riuscito a scegliere un backend. Ciò potrebbe significare che tutti i backend non sono integri. 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 inaspettatamente la connessione al bilanciatore del carico prima che la risposta venisse proxy al client. 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 ha un timeout TCP inferiore a quello del bilanciatore del carico. Per maggiori dettagli, vedi Timeout e tentativi di nuovo invio.
      backend_timeout Il backend ha impiegato troppo tempo per rispondere. La il timeout del servizio di backend potrebbe essere impostato su un valore troppo basso per per rispondere. Valuta la possibilità di aumentare il timeout del servizio di backend o di scoprire perché il servizio impiega così tanto tempo a rispondere.

  4. Verifica che il parametro di configurazione keepalive per il software del server HTTP in esecuzione nell'istanza di backend non sia inferiore al timeout keepalive del bilanciatore del carico, il cui valore è fissato a 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 in modo imprevisto durante l'invio della richiesta HTTP o prima che sia stata ricevuta la risposta HTTP completa. Questo 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).

Risolvere gli errori HTTP 408

Con il traffico HTTP, il tempo massimo necessario al client per completare l'invio della richiesta è uguale al timeout del servizio di backend. Se vedi Risposte HTTP 408 con jsonPayload.statusDetail client_timed_out, ciò significa che l'avanzamento della richiesta da parte di è stato inviato tramite proxy o la risposta dal backend è stata inviata tramite proxy. Se il problema è causato da client che riscontrano 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 dei pacchetti, come visto dai backend, non è l'indirizzo IP esterno del bilanciatore del carico. 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 solo proxy subnet)
  • Connessione 2, dal bilanciatore del carico (GFE o subnet solo proxy) all'endpoint o alla VM di backend

Gli indirizzi IP di origine e di destinazione per ogni connessione variano in base al tipo di bilanciatore del carico delle applicazioni esterno in uso. Per maggiori dettagli, vedi Indirizzi IP di origine per di 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 pubblica l'oggetto Cloud Storage previsto

L'oggetto Cloud Storage da gestire è determinato in base alla mappa URL e l'URL richiesto. Se il percorso della richiesta viene mappato a un bucket di backend in la mappa URL, l'oggetto Cloud Storage viene determinato aggiungendo il percorso di richiesta completo sul 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 pubblicare gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Se l'oggetto non viene visualizzato il seguente messaggio di errore al posto dell'oggetto:


NoSuchKey
The specified key does not exist.

La compressione non funziona

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

Se le risposte fornite dal bilanciatore del carico non sono compresse, ma dovrebbero esserlo, e verifica che il software del server web in esecuzione sulle istanze configurate per comprimere le risposte. Per impostazione predefinita, alcuni software per server web disattivano automaticamente la compressione per le richieste che includono un'intestazione Via, che indica che la richiesta è stata inoltrata da un proxy. Poiché si tratta di un proxy, il bilanciatore del carico delle applicazioni esterno aggiunge un'intestazione Via a ogni richiesta come richiesto dall'HTTP la specifica del prodotto. Per attivare la compressione, potrebbe essere necessario eseguire l'override delle impostazioni predefinite 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 servano risposte compresse sottoposte a proxy tramite un bilanciatore del carico delle applicazioni esterno:

Per configurare i backend Apache per fornisci risposte compresse inviate tramite proxy tramite un bilanciatore del carico delle applicazioni esterno:

Risolvere i problemi relativi ai backend in stato non integro

Risolvere i problemi relativi a HTTP/2 per i backend

Assicurati che l'istanza di backend sia in stato attivo e supporti il protocollo HTTP/2. Puoi verificarlo testando la connettività all'istanza di backend utilizzando HTTP/2. Assicurati che la VM utilizzi suite di crittografia conformi alle specifiche HTTP/2. Ad esempio, determinate suite di crittografia TLS 1.2 non sono consentite da HTTP/2. Consulta le Lista nera della suite di crittografia TLS 1.2.

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 al backend esterno e al NEG internet

Prima di esaminare i problemi, acquisisci familiarità con le seguenti pagine:

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 sei utilizzando 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 il record TXT DNS _cloud-eoips.googleusercontent.com usando uno strumento come dig o nslookup. Prendi nota dei CIDR (che seguono ip4:) e assicurati che questi intervalli siano consentiti dal firewall o dall'elenco di controllo dell'accesso (ACL) cloud.

Dopo aver configurato un backend esterno, le richieste al backend esterno non sono andate a buon fine con un errore 5xx

  • Seleziona Logging.
  • Verifica che il gruppo di endpoint di rete sia configurato con l'IP:porta o FQDN:porta corretto per il tuo backend esterno.
  • Se utilizzi un FQDN, assicurati che sia risolvibile tramite Google Public DNS. Puoi verificare che l'FQDN sia risolvibile tramite Google Public DNS seguendo questi passaggi o direttamente tramite l'interfaccia web.
  • Se accedi al bilanciatore del carico dal suo server esterno e il server web di origine si aspetta un nome host, assicurati che stai inviando un'intestazione host HTTP valida al tuo backend configurazione di una richiesta personalizzata intestazione.
  • Se comunichi con un backend tramite HTTPS o HTTP2 (come impostato nel protocol campo del servizio di backend) configurato come INTERNET_FQDN_PORT endpoint di backend esterno, assicurati che l'origine sia in grado di presentare un certificato TLS (SSL) valido e che il FQDN configurato corrisponda a un SAN (Subject Alternative Name) nell'elenco di protocol SAN dei certificati. Un certificato valido è definito come un certificato firmato da un dell'autorità di certificazione e che non sia scaduta.
  • Quando utilizzi INTERNET_FQDN_PORT endpoint di backend esterni, con firma automatica non sono accettati dal bilanciatore del carico e vengono rifiutato.
  • Quando utilizzi HTTPS o HTTP/2 con endpoint di tipo INTERNET_IP_PORT, non viene eseguito alcun controllo di convalida/SAN del certificato SSL. Ciò significa che è possibile utilizzare certificati autofirmati. Quando utilizzi SSL, ti consigliamo di utilizzare gli endpointINTERNET_FQDN_PORT per assicurarti che i certificati del server e i SAN possano essere convalidati.

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

Assicurati che:

  • Hai attivato 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, acquisisci familiarità con le seguenti pagine:

Le richieste non riescono con un errore 404

Assicurati che la risorsa serverless sottostante (come App Engine, funzioni Cloud Run, o servizio Cloud Run) è ancora in esecuzione. Se la risorsa serverless viene eliminata ma il NEG serverless esiste ancora, il bilanciatore del carico delle applicazioni esterno continuerà a tentare di instradare le richieste a dispositivi non esistenti completamente gestito di Google Cloud. Il risultato è una risposta 404.

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

Gestione delle mancate corrispondenze delle maschere degli URL

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

Cloud Run: in caso di mancata corrispondenza della maschera dell'URL, il bilanciatore del carico restituisce un errore HTTP 404 (non trovato).

Funzioni di Cloud Run: in caso di mancata corrispondenza della maschera URL, il bilanciatore del carico restituisce un errore HTTP 404 (non trovato).

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