Intro #
Un servizio proxy è un software progettato per gestire in modo trasparente le connessioni dei client a uno o più servizi, fornendo dati avanzati o gestione della connessione a livello di applicazione (livello 7 nel modello OSI). Per raggiungere questo obiettivo, il servizio proxy stabilisce una connessione con il client e un'altra con il server, con l'obiettivo di garantire una connettività senza interruzioni tra di loro.
Quando si implementa il bilanciamento del carico tramite un servizio proxy (che funziona effettivamente come proxy inverso), è essenziale personalizzare i timeout per facilitare le connessioni fluide. I valori di timeout predefiniti potrebbero non essere sufficienti, a seconda delle caratteristiche dei client o dei servizi applicativi. Eventuali errori relativi al timeout verranno registrati nei registri di sistema all'indirizzo / Var / log / syslog, rendendo fondamentale esaminare questo file per individuare potenziali problemi.
Questo articolo fornisce approfondimenti sull'analisi e l'identificazione dei problemi comuni di timeout con i server proxy. L'informazione chiave da indagare è se i timeout si verificano sul lato back-end o sul lato client. Una volta effettuata questa distinzione, è possibile applicare le opportune regolazioni del timeout.
Timeout laterali del backend #
Se si verificano timeout sul lato backend, i messaggi corrispondenti vengono visualizzati come segue:
21 agosto 09:23:06 noid-ee-01 pound: noid-proxy-farm-01, servizio noid-service-01, backend 10.100.200.10:443, (7ff830b85700) errore server di copia cont: Connessione scaduta 21 agosto 09 :23:06 noid-ee-01 pound: noid-proxy-farm-01, servizio noid-service-01, backend 10.100.200.11:443, (7ff832d8b700) errore server di copia cont: Connessione scaduta 21 agosto 09:23: 16 noid-ee-01 pound: noid-proxy-farm-01, servizio noid-service-01, backend 10.100.200.10:443, (7ff799926700) errore server di copia cont: Connessione scaduta 21 agosto 09:23:18 noid- ee-01 pound: noid-proxy-farm-01, servizio noid-service-01, backend 10.100.200.10:443, (7ff830bc6700) errore server di copia cont: pipe rotta 21 agosto 09:23:19 noid-ee-01 pound : noid-proxy-farm-01, servizio noid-service-01, backend 10.100.200.10:444, (7f15f5a8c700) connect_nb: sondaggio scaduto il 21 agosto 09:23:24 noid-ee-01 pound: noid-proxy-farm -01, servizio noid-service-01, backend 10.100.200.11:443, (7ff79a9a7700) errore copia server cont: Connessione scaduta 21 agosto 09:23:24 noid-ee-01 pound: noid-proxy-farm-01, servizio noid-service-01, backend 10.100.200.10:443, (7ff79a28b700) errore server di copia cont: connessione scaduta
Questi errori di timeout del backend specificano il file rilevante fattoria, INSTALLAZIONEe backend associato all'errore. Queste informazioni identificano chiaramente il backend o i backend collegati al problema. Se nel problema del timeout sono implicati più farm, servizi o backend, potrebbe essere necessario raccogliere ulteriori informazioni per indagare su eventuali potenziali problemi di rete.
L'abilitazione dei log della farm può rivelare istanze in cui un backend specifico inizialmente risponde rapidamente, ma improvvisamente riscontra un problema di timeout, come illustrato nell'estratto del log di seguito:
25 gennaio 19:57:04 noid-ee-01 pound: noid-proxy-farm-01, my.service.com 185.106.182.130 - - [25/gen/2024:19:57:04 +0000] "OTTIENI / myserv/ HTTP/1.1" 200 9 "" "Mozilla/3.0 (compatibile; ...)" (noid-service-01 -> 10.100.200.10:443) 0.039 secondi 25 gennaio 19:57:04 noid-ee-01 pound: noid-proxy-farm-01, my.service.com 88.111.111.111 - - [25/gen/2024:19:57:04 +0000] "OTTIENI / myserv/ HTTP/1.1" 200 9 "" "Mozilla/3.0 (compatibile; ...)" (noid-service-01 -> 10.100.200.10:443) 0.035 secondi 25 gennaio 19:57:04 noid-ee-01 pound: noid-proxy-farm-01, servizio noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) connect_nb: sondaggio scaduto 25 gennaio 19:57:04 noid-ee-01 pound: noid-proxy-farm-01, servizio noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) backend 10.100.200.10:443 connessione: Connessione scaduta 25 gennaio 19:57:04 noid-ee-01 pound: noid-proxy-farm-01, (7fcd8eb0f700) BackEnd 10.100.200.10:443 morto (ucciso) nella farm: 'noid-proxy-farm-01', servizio: 'ocp-ocuco-com' 25 gennaio 19:57:04 noid-ee-01 pound: noid-proxy-farm-01, servizio noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) BackEnd morto (ucciso )
Questo comportamento potrebbe indicare che il backend ha raggiunto il limite di connessioni, impedendo ulteriori connessioni. In alternativa, potrebbe suggerire che il backend non rilascia le connessioni abbastanza velocemente, provocando un collo di bottiglia. Per risolvere questo problema, si consiglia di monitorare il backend e implementare ottimizzazioni come consentire più connessioni o ridimensionare il servizio aggiungendo ulteriori backend.
Se solo backend specifici riscontrano problemi di timeout all'interno dello stesso servizio, ciò implica che quei backend particolari potrebbero avere problemi legati alla consegna lenta delle applicazioni o a problemi di rete. Le soluzioni o le soluzioni per questi errori sono descritte di seguito.
Timeout lato client #
Al contrario, i timeout del client si manifestano nel file syslog nel seguente formato:
18 agosto 07:31:38 noid-ee-01 pound: noid-proxy-farm-01, (7f8862187700) errore letto da 12.91.1.78: connessione scaduta 18 agosto 07:31:43 noid-ee-01 pound: noid -proxy-farm-01, (7f8863c71700) errore letto da 12.2.1.105: connessione scaduta 18 agosto 07:32:03 noid-ee-01 pound: noid-proxy-farm-01, (7f886275e700) errore letto da 12.41.1.58. 18: Connessione scaduta 07 agosto 32:07:01 noid-ee-01 pound: noid-proxy-farm-7, (8880f84700d12.88.1.67) errore letto da 18: Connessione scaduta 07 agosto 32:16:01 noid-ee -01 pound: noid-proxy-farm-7, (8880933700f12.3.1.158) errore letto da XNUMX: connessione scaduta
Se nei log mancano informazioni sulla farm o sul servizio, significa che la richiesta del client non ha raggiunto correttamente il proxy. Il client impiega molto tempo per eseguire la richiesta HTTP, rendendo il proxy inconsapevole del servizio richiedente. L'array di indirizzi IP può aiutare a discernere se il problema riguarda una rete interna, client esterni o quelli che arrivano attraverso un firewall specifico.
Inoltre, per i clienti esterni, è fondamentale accertarne la legittimità. L'utilizzo dei servizi AbuseIP può aiutare a raccogliere tali informazioni.
Inoltre, per risolvere i problemi di timeout del client, è fondamentale verificare che il proxy non termini prematuramente le connessioni. Assicurarsi che la somma del timeout della connessione e dei timeout del backend sia inferiore al timeout del client per evitare qualsiasi disconnessione prematura da parte del proxy.
Fare riferimento di seguito per approfondimenti su come affrontare o mitigare questi errori.
Correzione dei timeout laterali dei backend #
Verifica del livello di rete #
Per cominciare, è essenziale confermare la stabilità dello strato di rete e garantire l'assenza di pacchetti duplicati, pacchetti persi o fluttuazioni significative nella latenza. Seguire questi passaggi per eseguire la verifica del livello di rete:
1. Esegui un ping dal sistema di bilanciamento del carico al backend e consentirne l'esecuzione per diversi minuti.
root@noid-ee-01:~# ping 10.100.200.10
2. Osservare le risposte del ping durante l'esecuzione:
PING 10.100.200.10 (10.100.200.10) 56(84) byte di dati. 64 byte da 10.100.200.10: icmp_seq=1 ttl=64 time=0.395 ms 64 byte da 10.100.200.10: icmp_seq=2 ttl=64 time=0.626 ms 64 byte da 10.100.200.10: icmp_seq=3 ttl=64 time= 0.178 ms [...] 64 byte da 10.100.200.10: icmp_seq=21 ttl=64 time=0.502 ms 64 byte da 10.100.200.10: icmp_seq=22 ttl=64 time=0.638 ms 64 byte da 10.100.200.10: icmp_seq=23 ttl=64 tempo=0.573 ms ^C --- 10.100.200.10 statistiche ping --- 23 pacchetti trasmessi, 23 ricevuti, 0% di perdita di pacchetti, tempo 140 ms rtt min/avg/max/mdev = 0.178/0.539/0.854/0.141 ms
Questa risposta indica che la rete è stabile, senza pacchetti persi o problemi di latenza. Garantire l'assenza di eventuali anomalie durante il ping test per confermare l'affidabilità del livello di rete.
Inoltre, eseguendo un tcpdump quando il problema viene replicato, è possibile analizzare il traffico di rete per individuare il momento specifico in cui la comunicazione subisce ritardi o quando mancano determinati pacchetti. Utilizza il seguente comando:
root@noid-ee-01:~# tcpdump -i qualsiasi porta tcp PORT e host BACKENDIP -w /tmp/capture.pcap
Questo comando genererà un file denominato /tmp/capture.pcap, che può essere analizzato utilizzando Wireshark. Sii cauto, poiché questo file potrebbe crescere rapidamente se cattura una notevole quantità di traffico.
Ottimizzazione dei timeout proxy #
Regolazione di vari timeout nel file Configurazione avanzata dell'azienda agricola ci consente di adattare il comportamento del proxy alle esigenze dei nostri server delle applicazioni, soprattutto quando richiedono tempo aggiuntivo per ciascuna richiesta o quando le prestazioni della rete sono lente. Considera le seguenti raccomandazioni:
Timeout della connessione back-end: imposta il tempo massimo per a Collegare() operazione sul backend selezionato. Se i messaggi piacciono “connect_nb: sondaggio scaduto” vengono rilevati, valutare la possibilità di aumentare questo valore dai 20 secondi predefiniti a 30 o 40 secondi. Aumentare gradualmente il valore in base ai risultati osservati, tenendo presente che il timeout potrebbe risolvere un problema di fondo altrove.
Timeout della risposta del backend: modificare questo valore se il messaggio "errore copia server cont: connessione scaduta" è identificato. Allo stesso modo, aumentare in modo incrementale questo valore finché non si osserva una diminuzione di tali messaggi. Tuttavia, fai attenzione a non aumentare eccessivamente questo valore, poiché potrebbe mascherare problemi di fondo sul lato back-end. Il valore predefinito è 45 secondi, quindi valuta la possibilità di aumentarlo a 60 secondi o più, monitorando l'assenza di errori.
Frequenza per controllare i backend ripristinati: nei casi in cui sono necessari timeout più elevati a causa di problemi di rete o del server applicazioni che causano errori HTTP 503 intermittenti (che indicano l'assenza di backend del servizio disponibile), valutare la possibilità di ridurre questo valore da 10 secondi a 5. Questa regolazione aiuta a mitigare i falsi positivi nel contrassegnare i backend come inattivi per timeout. Analizza se i timeout rientrano nei limiti normali, poiché il bilanciatore del carico proxy può alleviare alcuni problemi in questo contesto.
Si prega di condurre un'analisi approfondita per determinare la normalità dei timeout. Il sistema di bilanciamento del carico proxy ha la capacità di affrontare e mitigare alcuni problemi relativi al timeout.
Per informazioni più dettagliate fare riferimento al seguente articolo:
Configura i controlli di integrità #
Farm Guardian ha lo scopo di attivare o disattivare i backend in base alla loro disponibilità. In questo scenario, sfruttare Farm Guardian ci consente di accertare l'effettiva disponibilità dei backend. Questo processo opera in modo indipendente e parallelo al proxy, fornendo un mezzo per verificare se i problemi di backend contribuiscono realmente a creare un collo di bottiglia sul lato backend. Inoltre, esaminando le statistiche del backend quando un backend è contrassegnato come inattivo, possiamo determinare il numero di connessioni gestite da quel server, consentendoci di identificare i limiti di connessione di ciascun backend.
La configurazione di un controllo FarmGuardian per TCP ci consente di identificare eventuali problemi con l'handshake con i backend, che potrebbero indicare un collo di bottiglia a livello di sistema o server web. D'altra parte, la configurazione di un controllo FarmGuardian per HTTP aiuta a identificare i problemi a livello di applicazione con i backend, indicando potenziali colli di bottiglia a livello di applicazione o database.
Correzione dei timeout lato client #
Verifica del livello di rete #
Per convalidare la stabilità della rete, eseguire un test ping da un altro server o macchina all'indirizzo IP dell'IP virtuale configurato per la farm di bilanciamento del carico. Ciò garantisce una prospettiva esterna e aiuta a confermare l'affidabilità della rete.
Verifica dei clienti legittimi #
Utilizza strumenti sicuri per identificare se i problemi di timeout sono associati a client legittimi, robot o potenziali aggressori. Se i timeout sono collegati a utenti non autorizzati, implementa liste nere IPDS e/o protezioni DoS per salvaguardare i tuoi servizi e garantire la consegna solo a utenti validi e autentici.
Ottimizzazione dei timeout proxy #
Inoltre, valuta la possibilità di modificare i timeout del proxy per adattarli alla natura dei client che si connettono ai tuoi servizi tramite il sistema di bilanciamento del carico. Se, ad esempio, client basati su dispositivi mobili, problemi del firewall o reti lente contribuiscono a tempi di risposta prolungati, ottimizzare il Timeout richiesta del cliente opzione nel Impostazioni avanzate della tua fattoria LSLB. Il valore predefinito è 30 secondi; puoi aumentarlo a 60 secondi o più in base alle tue esigenze specifiche. Il valore di timeout del client deve superare la somma del timeout della connessione e del timeout della risposta del backend.
Per informazioni più dettagliate fare riferimento al seguente articolo:
