Risolvere i problemi relativi ai bilanciatori del carico delle applicazioni interni

Questa guida descrive come risolvere i problemi di configurazione per un bilanciatore del carico delle applicazioni interno di Google Cloud. Prima di seguire questa guida, acquisisci familiarità con quanto segue:

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:

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

Questo è un comportamento previsto. Un bilanciatore del carico delle applicazioni interno funziona come un proxy inverso(gateway) HTTP (S). Quando un programma client apre una connessione all'indirizzo IP di una regola di forwarding INTERNAL_MANAGED, la connessione termina in un proxy. Il proxy elabora le richieste che arrivano tramite questa connessione. Per ogni richiesta, il proxy seleziona un backend da ricevere in base alla mappa URL e ad altri fattori. Il proxy invia quindi la richiesta al backend selezionato. Di conseguenza, dal punto di vista del backend, l'origine di un pacchetto in entrata è un indirizzo IP della subnet solo proxy della regione.

Le richieste vengono rifiutate dal bilanciatore del carico

Per ogni richiesta, il proxy seleziona un backend da cui ricevere la richiesta in base a un comparatore di percorsi nella mappa di URL del bilanciatore del carico. Se la mappa URL non ha un parametro di corrispondenza del percorso definito per una richiesta, non può selezionare un servizio di backend, quindi restituisce un codice di risposta HTTP 404 (Non trovato).

Il bilanciatore del carico non si connette ai backend

I firewall che proteggono i server di backend devono essere configurati per consentire il traffico in entrata dai proxy nell'intervallo della subnet solo proxy che hai allocato alla regione del bilanciatore del carico HTTP(S) interno.

I proxy si connettono ai backend utilizzando le impostazioni di connessione specificate dalla configurazione del servizio di backend. Se questi valori non corrispondono alla configurazione dei server in esecuzione sui tuoi backend, il proxy non può inoltrare le richieste ai backend.

I probe del controllo di integrità non riescono a raggiungere i 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.

I client non riescono a connettersi al bilanciatore del carico

I proxy ascoltano le connessioni all'indirizzo IP e alla porta del bilanciatore del carico configurati nella regola di forwarding (ad esempio 10.1.2.3:80) e con il protocollo specificato nella regola di forwarding (HTTP o HTTPS). Se i clienti non riescono a collegarsi, assicurati che stiano utilizzando l'indirizzo, la porta e il protocollo corretti.

Assicurati che un firewall non blocchi il traffico tra le istanze client e l'indirizzo IP bilanciato in base al carico.

Assicurati che i client si trovino nella stessa regione del bilanciatore del carico. Il bilanciamento del carico HTTP(S) interno è un prodotto regionale, pertanto tutti i client (e i backend) devono trovarsi nella stessa regione della risorsa del bilanciatore del carico.

Limitazione dei criteri dell'organizzazione per VPC condiviso

Se utilizzi la rete VPC condiviso e non riesci a creare un nuovo bilanciatore del carico delle applicazioni 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 constraints/compute.restrictSharedVpcSubnetworks.

Il bilanciatore del carico non distribuisce il traffico in modo uniforme tra le zone

Potresti notare uno squilibrio nel traffico del bilanciatore del carico delle applicazioni interno tra le zone. Questo può accadere in particolare quando l'utilizzo della capacità di backend è ridotto (< 10%).

Questo comportamento può influire sulla latenza complessiva a causa del fatto che il traffico viene inviato solo a pochi server in una zona.

Per uniformare la distribuzione del traffico tra le zone, puoi apportare le seguenti modifiche alla configurazione:

Errori 5xx inspiegabili

Per le condizioni di errore causate da un problema di comunicazione tra il proxy del bilanciatore del carico e i relativi backend, il bilanciatore del carico genera un codice di stato HTTP (5xx) e lo restituisce 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, quest'ultimo la inoltra 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, consulta il campo proxyStatus dei log del bilanciatore del carico.

Le modifiche di configurazione al bilanciatore del carico delle applicazioni interno, 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 stato HTTP 503. Mentre queste modifiche alla configurazione si propagano ai Envoy a livello globale, visualizzi le voci di log in cui il campo proxyStatus corrisponde alla stringa di log connection_refused.

Se i codici di stato HTTP 5xx persistono per più di qualche minuto dopo il completamento della configurazione del bilanciatore del carico, segui questi passaggi per risolvere i problemi relativi alle risposte HTTP5xx:

  1. Verifica che sia presente una regola firewall configurata per consentire i controlli di integrità. In assenza di un valore, i log del bilanciatore del carico in genere hanno un valore proxyStatus corrispondente a destination_unavailable, che indica che il bilanciatore del carico considera il backend non disponibile.

  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à risposte 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. Le voci di log del controllo di integrità riuscite sono visibili solo dopo che il prober del controllo di integrità riceve una risposta HTTP 200 OK dal backend.

  3. 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 stato HTTP 5xx quando la connessione al backend si è chiusa in modo imprevisto durante l'invio della richiesta HTTP o prima della ricezione della 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).

Limitazioni

Se hai difficoltà a utilizzare un bilanciatore del carico delle applicazioni interno con altre funzionalità di rete di Google Cloud, tieni presente le attuali limitazioni di compatibilità.