Intro #
Een proxyservice is software die is ontworpen om verbindingen tussen clients en een of meer services transparant te beheren en geavanceerde gegevens- of verbindingsafhandeling op applicatieniveau (laag 7 in het OSI-model) te leveren. Om dit te bereiken, maakt de proxyservice één verbinding met de client en één met de server, met als doel een naadloze verbinding tussen beide te garanderen.
Bij het implementeren van load balancing via een proxyservice (die effectief functioneert als een reverse proxy), is het essentieel om time-outs aan te passen om soepele verbindingen mogelijk te maken. Standaard time-outwaarden zijn mogelijk niet voldoende, afhankelijk van de kenmerken van clients of applicatieservices. Time-outgerelateerde fouten worden vastgelegd in de systeemlogboeken op / Var / log / syslogHet is daarom van groot belang om dit bestand te controleren op mogelijke problemen.
Dit artikel biedt inzicht in het analyseren en identificeren van veelvoorkomende time-outproblemen met proxyservers. De belangrijkste informatie die u moet onderzoeken, is of de time-outs zich voordoen aan de backend- of clientzijde. Zodra dit onderscheid is gemaakt, kunnen de juiste time-outaanpassingen worden toegepast.
Time-outs aan de backend-kant #
Als er time-outs optreden aan de backend-zijde, worden de bijbehorende berichten als volgt weergegeven:
21 aug. 09:23:06 noid-ee-01 pond: noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7ff830b85700) fout kopiëren server cont: verbinding is verlopen 21 aug. 09:23:06 noid-ee-01 pond: noid-proxy-farm-01, service noid-service-01, backend 10.100.200.11:443, (7ff832d8b700) fout kopiëren server cont: verbinding is verlopen 21 aug. 09:23:16 noid-ee-01 pond: noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7ff799926700) fout bij kopiëren server cont: verbinding is verlopen 21 aug. 09:23:18 noid-ee-01 pond: noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7ff830bc6700) fout bij kopiëren server cont: kapotte pijp 21 aug. 09:23:19 noid-ee-01 pond: noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:444, (7f15f5a8c700) connect_nb: poll is verlopen 21 aug. 09:23:24 noid-ee-01 pond: noid-proxy-farm-01, service noid-service-01, backend 10.100.200.11:443, (7ff79a9a7700) fout kopiëren server cont: verbinding is verlopen 21 aug 09:23:24 noid-ee-01 pond: noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7ff79a28b700) fout kopiëren server cont: verbinding is verlopen
Deze backend-time-outfouten specificeren de relevante boerderij, serviceen backend die verband houden met de fout. Deze informatie identificeert duidelijk de backend of backends die aan het probleem zijn gekoppeld. Als meerdere farms, services of backends betrokken zijn bij het time-outprobleem, moet mogelijk aanvullende informatie worden verzameld om mogelijke netwerkproblemen te onderzoeken.
Door farmlogs in te schakelen, kunt u gevallen ontdekken waarin een specifieke backend aanvankelijk snel reageert, maar plotseling een time-outprobleem ondervindt, zoals geïllustreerd in het onderstaande logfragment:
25 jan 19:57:04 noid-ee-01 pond: noid-proxy-farm-01, my.service.com 185.106.182.130 - - [25/jan/2024:19:57:04 +0000] "GET /myserv/ HTTP/1.1" 200 9 "" "Mozilla/3.0 (compatibel; ...)" (noid-service-01 -> 10.100.200.10:443) 0.039 seconden 25 jan 19:57:04 noid-ee-01 pond: noid-proxy-farm-01, my.service.com 88.111.111.111 - - [25/jan/2024:19:57:04 +0000] "GET /myserv/ HTTP/1.1" 200 9 "" "Mozilla/3.0 (compatibel; ...)" (noid-service-01 -> 10.100.200.10:443) 0.035 seconden 25 jan 19:57:04 noid-ee-01 pond: noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) connect_nb: poll is verlopen Jan 25 19:57:04 noid-ee-01 pond: noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) backend 10.100.200.10:443 verbinden: verbinding is verlopen Jan 25 19:57:04 noid-ee-01 pond: noid-proxy-farm-01, (7fcd8eb0f700) BackEnd 10.100.200.10:443 dood (gedood) in farm: 'noid-proxy-farm-01', service: 'ocp-ocuco-com' Jan 25 19:57:04 noid-ee-01 pond: noid-proxy-farm-01, service noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) BackEnd dood (gedood)
Dit gedrag kan erop wijzen dat de backend de verbindingslimiet heeft bereikt, waardoor er geen extra verbindingen mogelijk zijn. Het kan er ook op wijzen dat de backend de verbindingen niet snel genoeg vrijgeeft, wat leidt tot een bottleneck. Om dit probleem aan te pakken, is het raadzaam de backend te monitoren en optimalisaties te implementeren, zoals het toestaan van meer verbindingen of het opschalen van de service door extra backends toe te voegen.
Als alleen specifieke backends time-outproblemen binnen dezelfde service ervaren, betekent dit dat die specifieke backends mogelijk problemen hebben met trage applicatielevering of netwerkproblemen. Hieronder vindt u oplossingen of oplossingen voor deze fouten.
Time-outs aan de clientzijde #
Omgekeerd manifesteren client-time-outs zich in de syslog in het volgende formaat:
18 aug. 07:31:38 noid-ee-01 pond: noid-proxy-farm-01, (7f8862187700) fout bij het lezen van 12.91.1.78: verbinding is verlopen 18 aug. 07:31:43 noid-ee-01 pond: noid-proxy-farm-01, (7f8863c71700) fout bij het lezen van 12.2.1.105: verbinding is verlopen 18 aug. 07:32:03 noid-ee-01 pond: noid-proxy-farm-01, (7f886275e700) fout bij het lezen van 12.41.1.58: verbinding is verlopen 18 aug. 07:32:07 noid-ee-01 pond: noid-proxy-farm-01, (7f8880d84700) fout bij het lezen van 12.88.1.67: verbinding is verlopen 18 aug 07:32:16 noid-ee-01 pond: noid-proxy-farm-01, (7f8880933700) fout bij het lezen van 12.3.1.158: verbinding is verlopen
Als er geen farm- of service-informatie in de logs staat, geeft dit aan dat de aanvraag van de client de proxy niet correct heeft bereikt. De client heeft veel tijd nodig om de HTTP-aanvraag uit te voeren, waardoor de proxy de aanvragende service niet herkent. De reeks IP-adressen kan helpen bepalen of het probleem zich voordoet bij een intern netwerk, externe clients of clients die via een specifieke firewall binnenkomen.
Bovendien is het voor externe klanten cruciaal om hun legitimiteit vast te stellen. AbuseIP-diensten kunnen helpen bij het verzamelen van dergelijke informatie.
Om client-time-outproblemen op te lossen, is het bovendien cruciaal om te controleren of de proxy de verbindingen niet voortijdig verbreekt. Zorg ervoor dat de som van de verbindingstime-out en backend-time-outs kleiner is dan de client-time-out om te voorkomen dat de proxy voortijdig de verbinding verbreekt.
Hieronder vindt u inzichten over hoe u deze fouten kunt aanpakken of verminderen.
Het oplossen van time-outs aan de backend-kant #
Verificatie van de netwerklaag #
Om te beginnen is het essentieel om de stabiliteit van de netwerklaag te bevestigen en te controleren of er geen dubbele pakketten, verloren pakketten of significante latentieschommelingen zijn. Volg deze stappen om de netwerklaag te verifiëren:
1. Stuur een ping van de load balancer naar de backend en laat deze enkele minuten draaien.
root@noid-ee-01:~# ping 10.100.200.10
2. Observeer de pingreacties tijdens de uitvoering:
PING 10.100.200.10 (10.100.200.10) 56(84) bytes aan gegevens. 64 bytes van 10.100.200.10: icmp_seq=1 ttl=64 tijd=0.395 ms 64 bytes van 10.100.200.10: icmp_seq=2 ttl=64 tijd=0.626 ms 64 bytes van 10.100.200.10: icmp_seq=3 ttl=64 tijd=0.178 ms [...] 64 bytes van 10.100.200.10: icmp_seq=21 ttl=64 tijd=0.502 ms 64 bytes van 10.100.200.10: icmp_seq=22 ttl=64 tijd=0.638 ms 64 bytes van 10.100.200.10: icmp_seq=23 ttl=64 tijd=0.573 ms ^C --- 10.100.200.10 ping statistieken --- 23 pakketten verzonden, 23 ontvangen, 0% pakketverlies, tijd 140 ms rtt min/avg/max/mdev = 0.178/0.539/0.854/0.141 ms
Dit antwoord geeft aan dat het netwerk stabiel is, zonder verloren pakketten of latentieproblemen. Controleer of er geen afwijkingen zijn opgetreden tijdens de pingtest om de betrouwbaarheid van de netwerklaag te bevestigen.
Door een tcpdump uit te voeren wanneer het probleem zich voordoet, kunt u bovendien het netwerkverkeer analyseren om het specifieke moment te bepalen waarop de communicatie vertraging oploopt of bepaalde pakketten ontbreken. Gebruik de volgende opdracht:
root@noid-ee-01:~# tcpdump -i elke tcp-poort POORT en host BACKENDIP -w /tmp/capture.pcap
Met deze opdracht wordt een bestand gegenereerd met de naam /tmp/capture.pcap, die geanalyseerd kan worden met Wireshark. Wees voorzichtig, want dit bestand kan snel groeien als het een aanzienlijke hoeveelheid verkeer vastlegt.
Proxy-time-outs afstemmen #
Het aanpassen van verschillende time-outs in de Geavanceerde configuratie van de boerderij Hiermee kunnen we het proxygedrag afstemmen op de behoeften van onze applicatieservers, vooral wanneer deze extra tijd nodig hebben voor elke aanvraag of wanneer de netwerkprestaties traag zijn. Houd rekening met de volgende aanbevelingen:
Time-out voor backend-verbinding: Stel de maximale tijd in voor een aansluiten() bewerking tegen de geselecteerde backend. Als berichten zoals “connect_nb: poll is verlopen” Als er fouten worden gedetecteerd, overweeg dan om deze waarde te verhogen van de standaard 20 seconden naar 30 of 40 seconden. Verhoog de waarde geleidelijk op basis van de waargenomen resultaten, rekening houdend met het feit dat de time-out mogelijk een onderliggend probleem elders aanpakt.
Time-out voor back-endreactie: Pas deze waarde aan als het bericht “fout bij kopiëren server cont: verbinding is verlopen” wordt geïdentificeerd. Verhoog deze waarde geleidelijk totdat een afname van dergelijke berichten wordt waargenomen. Wees echter voorzichtig en verhoog deze waarde niet te veel, aangezien dit onderliggende problemen aan de backend kan maskeren. De standaardwaarde is 45 seconden, dus overweeg deze te verhogen naar 60 seconden of meer en controleer op de afwezigheid van fouten.
Frequentie om herstelde backends te controleren:In gevallen waarin hogere time-outs nodig zijn vanwege netwerk- of applicatieserverproblemen die intermitterende HTTP 503-fouten veroorzaken (wat aangeeft dat er geen servicebackend beschikbaar is), kunt u overwegen deze waarde te verlagen van 10 seconden naar 5. Deze aanpassing helpt bij het beperken van foutpositieve resultaten bij het markeren van backends als down als gevolg van time-outs. Analyseer of time-outs binnen de normale limieten vallen, aangezien de proxy-loadbalancer bepaalde problemen in deze context kan verhelpen.
Voer een grondige analyse uit om de normaliteit van time-outs te bepalen. De proxy load balancer kan bepaalde time-outgerelateerde problemen aanpakken en beperken.
Voor meer gedetailleerde informatie, zie het volgende artikel:
Configureer statuschecks #
Farm Guardian dient om backends te activeren of deactiveren op basis van hun beschikbaarheid. In dit scenario stelt Farm Guardian ons in staat om de daadwerkelijke beschikbaarheid van backends vast te stellen. Dit proces werkt onafhankelijk en parallel aan de proxy, waardoor we kunnen verifiëren of backend-problemen daadwerkelijk bijdragen aan een bottleneck aan de backend-kant. Door backend-statistieken te bekijken wanneer een backend als down wordt gemarkeerd, kunnen we bovendien het aantal verbindingen bepalen dat door die server wordt afgehandeld, waardoor we de verbindingslimieten van elke backend kunnen identificeren.
Door een FarmGuardian-check voor TCP te configureren, kunnen we problemen met de handshake met de backends identificeren, wat kan wijzen op een bottleneck op systeem- of webserverniveau. Aan de andere kant helpt het configureren van een FarmGuardian-check voor HTTP om problemen met de backends op applicatieniveau te identificeren, wat kan wijzen op mogelijke bottlenecks in de applicatie- of databaselaag.
Time-outs aan de clientzijde oplossen #
Verificatie van de netwerklaag #
Om de stabiliteit van het netwerk te valideren, voert u een pingtest uit vanaf een andere server of machine naar het IP-adres van het virtuele IP-adres dat is geconfigureerd voor de load balancing farm. Dit zorgt voor een extern perspectief en helpt de betrouwbaarheid van het netwerk te bevestigen.
Verificatie van legitieme klanten #
Gebruik veilige tools om te identificeren of time-outproblemen verband houden met legitieme clients, robots of potentiële aanvallers. Als de time-outs verband houden met ongeautoriseerde gebruikers, implementeer dan IPDS-blacklists en/of DoS-beveiliging om uw services te beschermen en ervoor te zorgen dat deze alleen aan geldige en legitieme gebruikers worden geleverd.
Proxy-time-outs afstemmen #
Overweeg bovendien de proxy-time-outs aan te passen aan de aard van clients die via de load balancer verbinding maken met uw services. Als bijvoorbeeld mobiele clients, firewallproblemen of trage netwerken bijdragen aan langere responstijden, kunt u de Time-out clientverzoek optie in het Geavanceerde instellingen van uw LSLB-boerderij. De standaardwaarde is 30 seconden; u kunt dit verhogen tot 60 seconden of meer, afhankelijk van uw specifieke vereisten. De client-time-outwaarde moet groter zijn dan de som van de verbindingstime-out en de backend-responstime-out.
Voor meer gedetailleerde informatie kunt u het volgende artikel raadplegen:
