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 guida, acquisisci familiarità con quanto segue:

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. 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 carichi 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 inoltro 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 all'oggetto di un backend cloud. Di conseguenza, dal punto di vista del backend, l'origine di un pacchetto in arrivo è 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 per ricevere la richiesta in base a un matcher di percorso nella mappa URL del bilanciatore del carico. Se la mappa URL non ha un percorso matcher 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 Traffico in entrata dai proxy nella subnet solo proxy che hai allocato al tuo carico HTTP(S) interno della regione del bilanciatore del carico.

I proxy si connettono ai backend utilizzando le impostazioni di connessione specificate dalla configurazione del servizio di backend. Se questi valori non corrispondono dei server in esecuzione sui tuoi backend, il proxy non può inoltrare 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 logging del controllo di integrità e ricerca per le voci di log corrette.

I client non possono connettersi al bilanciatore del carico

I proxy restano in ascolto delle connessioni all'indirizzo IP e alla porta del bilanciatore del carico configurato nella regola di forwarding (ad esempio 10.1.2.3:80) e con specificato nella regola di forwarding (HTTP o HTTPS). Se i tuoi clienti non possono connettiti e assicurati di usare 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 la VPC condivisa

Se utilizzi la rete VPC condivisa 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, vedi 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. Ciò può accadere in particolare quando l'utilizzo della capacità di backend è ridotto (< 10%).

Tale comportamento può incidere sulla latenza complessiva dovuta al traffico inviato solo a pochi server in una zona.

Per uniformare la distribuzione del traffico tra le zone, puoi creare quanto segue: 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 è stata inoltrata una risposta HTTP 5xx da un backend o se è stato generato dal proxy del bilanciatore del carico, consulta Campo proxyStatus del bilanciatore del carico i log.

Le modifiche alla configurazione del 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 configurazione del bilanciatore del carico, segui questi passaggi per risolvere i problemi relativi 5xx risposte:

  1. Verifica che sia presente una regola firewall configurata per consentire l'integrità controlli. 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. it potrebbe significare che lo stato di integrità iniziale del backend non è ancora cambiato UNHEALTHY a un altro stato. 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 dall' di un backend cloud.

  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 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 HTTP il software server su ciascun backend è impostato 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 altri Funzionalità di networking di Google Cloud, tieni presente che l'attuale compatibilità limitazioni.