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 gli argomenti seguenti:

Risolvere i problemi comuni di Network Analyzer

Network Analyzer monitora automaticamente la configurazione di rete VPC e rileva sia le configurazioni non ottimali sia quelle errate. Identifica gli errori di rete, fornisce informazioni sulla causa principale e suggerisce possibili soluzioni. Per scoprire i diversi scenari di configurazione errata rilevati automaticamente 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.

Ciò si verifica quando tenti di 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 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 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 matcher di 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 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 backend, il proxy non può inoltrare le richieste ai backend.

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

I proxy sono in attesa di 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 tuoi 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 bilanciato del carico.

Assicurati che i client si trovino nella stessa regione del bilanciatore del carico. Il bilanciamento del carico HTTP(S) interno è un prodotto regionale, quindi 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 una policy dell'organizzazione. Nella policy dell'organizzazione, aggiungi la subnet all'elenco delle subnet consentite o contatta l'amministratore dell'organizzazione. Per saperne di più, 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 soprattutto quando l'utilizzo della capacità di backend è basso (< 10%).

Questo comportamento può influire sulla latenza complessiva perché 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 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, 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 visualizzano il codice di stato HTTP 503. Mentre queste modifiche alla configurazione si propagano agli Envoys a livello globale, vengono visualizzate 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 aver completato la configurazione del bilanciatore del carico, segui questi passaggi per risolvere i problemi relativi alle risposte HTTP 5xx:

  1. Verifica che esista una regola firewall configurata per consentire i controlli di integrità. In assenza di uno, i log del bilanciatore del carico in genere hanno un proxyStatus corrispondente a destination_unavailable, il 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à 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. 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 sull'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 inaspettatamente durante l'invio della richiesta HTTP o prima che sia stata ricevuta la risposta HTTP completa. Ciò può accadere perché il parametro di configurazione keepalive per il software del server web in esecuzione sullistanza di backend è inferiore al timeout keepalive fisso del bilanciatore del carico. Assicurati che la configurazione del timeout keepalive per il software 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 Google Cloud funzionalità di rete, tieni presente le attuali limitazioni di compatibilità.