Risolvere i problemi relativi agli Application Load Balancer interni

Questa guida descrive come risolvere i problemi di configurazione per un Application Load Balancer interno di Google Cloud. Prima di seguire questa guida, acquisisci familiarità con i seguenti documenti:

Risolvere i problemi comuni relativi a 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 di più sui diversi scenari di configurazione errata che vengono rilevati automaticamente da Network Analyzer, vedi 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:

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 opera come 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 su un proxy. Il proxy elabora le richieste che arrivano su quella connessione. Per ogni richiesta, il proxy seleziona un backend per ricevere la richiesta 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 arrivo è un indirizzo IP della subnet solo proxy dell'area geografica.

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 matcher percorso definito per una richiesta, non può selezionare un servizio di backend, quindi restituisce un codice di risposta HTTP 404 (Not Found).

Il bilanciatore del carico non si connette ai backend

I firewall che proteggono i server di backend devono essere configurati in modo da consentire il traffico in entrata dai proxy nell'intervallo di subnet solo proxy allocato nella 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 backend, il proxy non può inoltrare le richieste ai backend.

I probe del controllo di integrità non possono 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 possono connettersi al bilanciatore del carico

I proxy restano in ascolto delle connessioni all'indirizzo IP e alla porta configurata nella regola di forwarding (ad esempio 10.1.2.3:80) del bilanciatore del carico e con il protocollo specificato nella regola di forwarding (HTTP o HTTPS). Se i client non riescono a connettersi, assicurati che utilizzino l'indirizzo, la porta e il protocollo corretti.

Assicurati che un firewall non blocchi il traffico tra le istanze client e l'indirizzo IP con bilanciamento del carico.

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

Limitazione dei criteri dell'organizzazione per il VPC condiviso

Se utilizzi un 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 subnet all'elenco delle subnet consentite o contatta l'amministratore dell'organizzazione. Per maggiori 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 dell'Application Load Balancer interno tra le zone. Questo può accadere soprattutto in caso di utilizzo ridotto (< 10%) della capacità di backend.

Questo comportamento può influenzare la latenza complessiva dovuta al traffico inviato solo a pochi server in una zona.

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

5xx errori 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 inoltra questa risposta al proprio 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 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 vedono il codice di stato HTTP 503. Anche se queste modifiche alla configurazione si propagano a Envoys a livello globale, vedrai 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 alcuni minuti 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 questo valore, in genere i log del bilanciatore del carico hanno proxyStatus che corrisponde 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. 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 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 stato 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 di timeout keepalive per il software del server HTTP in 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 networking di Google Cloud, fai attenzione alle limitazioni attuali relative alla compatibilità.