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:
- Panoramica del bilanciatore del carico delle applicazioni interno
- Subnet solo proxy
- Logging e monitoraggio del bilanciatore del carico delle applicazioni interno
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 AnalyzerI 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:
- Limitazioni e indicazioni per i gruppi di istanze
- Modificare la modalità di bilanciamento di un bilanciatore del carico
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 arrivo è un indirizzo IP proveniente dalla 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:
- Utilizza la
RATE
modalità di bilanciamento con una capacità targetmax-rate-per-instance
ridotta. - Utilizza il piano di gestione del traffico
LocalityLbPolicy
di backend con un algoritmo di bilanciamento del carico diLEAST_REQUEST
.
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
:
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 adestination_unavailable
, che indica che il bilanciatore del carico considera il backend non disponibile.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 HTTP200 OK
dal backend.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 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à.