Intro #
En proxytjeneste er software designet til transparent at administrere forbindelser for klienter til en eller flere tjenester, og dermed levere avanceret data- eller forbindelseshåndtering på applikationsniveau (lag 7 i OSI-modellen). For at opnå dette etablerer proxytjenesten én forbindelse med klienten og en anden med serveren med det formål at sikre problemfri forbindelse mellem dem.
Når man implementerer Load Balancing via en proxytjeneste (og fungerer effektivt som en reverse proxy), er det vigtigt at tilpasse timeouts for at muliggøre problemfri forbindelser. Standard timeout-værdier er muligvis ikke tilstrækkelige, afhængigt af klienternes eller applikationstjenesternes egenskaber. Eventuelle timeout-relaterede fejl vil blive logget i systemloggene på / Var / log / syslog, hvilket gør det afgørende at gennemgå denne fil for potentielle problemer.
Denne artikel giver indsigt i at analysere og identificere almindelige timeout-problemer med proxyservere. Den vigtigste information at undersøge er, om timeouts forekommer på backend-siden eller klientsiden. Når denne sondring er foretaget, kan passende timeout-justeringer anvendes.
Backends side timeouts #
Hvis der opstår timeouts på backend-siden, vises de tilsvarende meddelelser som følger:
21. aug. 09:23:06 noid-ee-01 pund: noid-proxy-farm-01, tjeneste noid-service-01, backend 10.100.200.10:443, (7ff830b85700) fejl kopier server indhold: Forbindelse timeout 21. aug. 09:23:06 noid-ee-01 pund: noid-proxy-farm-01, tjeneste noid-service-01, backend 10.100.200.11:443, (7ff832d8b700) fejl kopier server indhold: Forbindelse timeout 21. aug. 09:23:16 noid-ee-01 pund: noid-proxy-farm-01, tjeneste noid-service-01, backend 10.100.200.10:443, (7ff799926700) fejl kopier server indhold: Forbindelsen fik timeout 21. aug. 09:23:18 noid-ee-01 pund: noid-proxy-farm-01, tjeneste noid-service-01, backend 10.100.200.10:443, (7ff830bc6700) fejl kopier server indhold: Ødelagt rør 21. aug. 09:23:19 noid-ee-01 pund: noid-proxy-farm-01, tjeneste noid-service-01, backend 10.100.200.10:444, (7f15f5a8c700) connect_nb: poll fik timeout 21. aug. 09:23:24 noid-ee-01 pund: noid-proxy-farm-01, tjeneste noid-service-01, backend 10.100.200.11:443, (7ff79a9a7700) fejl kopier server indhold: Forbindelse timeout 21. aug. 09:23:24 noid-ee-01 pund: noid-proxy-farm-01, tjeneste noid-service-01, backend 10.100.200.10:443, (7ff79a28b700) fejl kopier server indhold: Forbindelse timeout
Disse backend timeout-fejl angiver de relevante gård, serviceog backend forbundet med fejlen. Disse oplysninger identificerer tydeligt den eller de backends, der er knyttet til problemet. Hvis flere farms, tjenester eller backends er involveret i timeout-problemet, kan det være nødvendigt at indsamle yderligere oplysninger for at undersøge eventuelle netværksproblemer.
Aktivering af farmlogfiler kan afsløre tilfælde, hvor en specifik backend i første omgang reagerer hurtigt, men pludselig støder på et timeout-problem, som illustreret i loguddraget nedenfor:
25. jan. 19:57:04 noid-ee-01 pund: 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 (kompatibel; ...)" (noid-service-01 -> 10.100.200.10:443) 0.039 sek 25. jan. 19:57:04 noid-ee-01 pund: 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 (kompatibel; ...)" (noid-service-01 -> 10.100.200.10:443) 0.035 sek 25. jan. 19:57:04 noid-ee-01 pund: noid-proxy-farm-01, tjeneste noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) connect_nb: afstemning udløb 25. jan. 19:57:04 noid-ee-01 pund: noid-proxy-farm-01, tjeneste noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) backend 10.100.200.10:443 connect: Forbindelsen fik timeout 25. jan. 19:57:04 noid-ee-01 pund: noid-proxy-farm-01, (7fcd8eb0f700) BackEnd 10.100.200.10:443 død (dræbt) i farm: 'noid-proxy-farm-01', tjeneste: 'ocp-ocuco-com' 25. jan. 19:57:04 noid-ee-01 pund: noid-proxy-farm-01, tjeneste noid-service-01, backend 10.100.200.10:443, (7fcd8eb0f700) BackEnd død (afbrudt)
Denne adfærd kan indikere, at backend'en har nået sin forbindelsesgrænse, hvilket forhindrer yderligere forbindelser. Alternativt kan det tyde på, at backend'en ikke frigiver forbindelser hurtigt nok, hvilket fører til en flaskehals. For at løse dette problem anbefales det at overvåge backend'en og implementere optimeringer, såsom at tillade flere forbindelser eller skalere tjenesten ved at tilføje yderligere backends.
Hvis kun specifikke backends oplever timeout-problemer inden for den samme tjeneste, betyder det, at disse specifikke backends kan have problemer relateret til langsom applikationslevering eller netværksproblemer. Løsninger eller afhjælpningsforanstaltninger for disse fejl er beskrevet nedenfor.
Timeouts på klientsiden #
Omvendt manifesterer klienttimeouts sig i syslog i følgende format:
18. aug. 07:31:38 noid-ee-01 pund: noid-proxy-farm-01, (7f8862187700) fejl læst fra 12.91.1.78: Forbindelse timeout 18. aug. 07:31:43 noid-ee-01 pund: noid-proxy-farm-01, (7f8863c71700) fejl læst fra 12.2.1.105: Forbindelse timeout 18. aug. 07:32:03 noid-ee-01 pund: noid-proxy-farm-01, (7f886275e700) fejl læst fra 12.41.1.58: Forbindelse timeout 18. aug. 07:32:07 noid-ee-01 pund: noid-proxy-farm-01, (7f8880d84700) fejl læst fra 12.88.1.67: Forbindelse timeout 18. aug. 07:32:16 noid-ee-01 pund: noid-proxy-farm-01, (7f8880933700) fejl læst fra 12.3.1.158: Forbindelse timeout
Hvis logfilerne mangler oplysninger om gården eller tjenesten, indikerer det, at klientens anmodning ikke nåede frem korrekt til proxyen. Klienten bruger lang tid på at udføre HTTP-anmodningen, hvilket gør proxyen uvidende om den anmodende tjeneste. Opstillingen af IP-adresser kan hjælpe med at afgøre, om problemet vedrører et internt netværk, eksterne klienter eller dem, der ankommer gennem en bestemt firewall.
Derudover er det afgørende for eksterne klienter at fastslå deres legitimitet. Brug af AbuseIP-tjenester kan hjælpe med at indsamle sådanne oplysninger.
Derudover er det afgørende at kontrollere, at proxyen ikke afbryder forbindelser for tidligt, for at løse problemer med klienttimeout. Sørg for, at summen af forbindelsestimeout og backend-timeout er mindre end klienttimeouten for at undgå for tidlig afbrydelse fra proxyen.
Se nedenfor for indsigt i, hvordan du kan adressere eller afhjælpe disse fejl.
Rettelse af side timeouts i backends #
Verifikation af netværkslag #
Til at begynde med er det vigtigt at bekræfte netværkslagets stabilitet og sikre fraværet af duplikerede pakker, mistede pakker eller betydelige udsving i latenstid. Følg disse trin for at udføre verifikation af netværkslaget:
1. Udfør en ping fra load balancer til backend og lad den køre i flere minutter.
root@noid-ee-01:~# ping 10.100.200.10
2. Observer ping-svarene under udførelsen:
PING 10.100.200.10 (10.100.200.10) 56(84) bytes data. 64 bytes fra 10.100.200.10: icmp_seq=1 ttl=64 tid=0.395 ms 64 bytes fra 10.100.200.10: icmp_seq=2 ttl=64 tid=0.626 ms 64 bytes fra 10.100.200.10: icmp_seq=3 ttl=64 tid=0.178 ms [...] 64 bytes fra 10.100.200.10: icmp_seq=21 ttl=64 tid=0.502 ms 64 bytes fra 10.100.200.10: icmp_seq=22 ttl=64 tid=0.638 ms 64 bytes fra 10.100.200.10: icmp_seq=23 ttl=64 tid=0.573 ms ^C --- 10.100.200.10 ping statistik --- 23 pakker sendt, 23 modtaget, 0% pakketab, tid 140ms rtt min/gns./maks./mdev = 0.178/0.539/0.854/0.141 ms
Dette svar indikerer, at netværket er stabilt uden tabte pakker eller latensproblemer. Sørg for, at der ikke er nogen uregelmæssigheder under ping-testen for at bekræfte netværkslagets pålidelighed.
Derudover kan du ved at udføre en tcpdump, når problemet replikeres, analysere netværkstrafikken for at præcist finde det tidspunkt, hvor kommunikationen oplever forsinkelser, eller hvornår bestemte pakker mangler. Brug følgende kommando:
root@noid-ee-01:~# tcpdump -i enhver tcp-port PORT og vært BACKENDIP -w /tmp/capture.pcap
Denne kommando vil generere en fil med navnet /tmp/capture.pcap, som kan analyseres ved hjælp af Wireshark. Vær forsigtig, da denne fil kan vokse hurtigt, hvis den opfanger en betydelig mængde trafik.
Justering af proxy-timeouts #
Justering af forskellige timeouts i Avanceret konfiguration af gård giver os mulighed for at skræddersy proxyens adfærd til vores applikationsserveres behov, især når de kræver ekstra tid til hver anmodning, eller når netværkets ydeevne er træg. Overvej følgende anbefalinger:
Timeout for backend-forbindelse: Indstil den maksimale tid for en forbinde () handling mod den valgte backend. Hvis meddelelser som "connect_nb: afstemning udløb" opdages, bør du overveje at øge denne værdi fra standardværdien på 20 sekunder til 30 eller 40 sekunder. Øg værdien gradvist baseret på observerede resultater, og husk at timeout muligvis løser et underliggende problem et andet sted.
Backend Respons Timeout: Juster denne værdi, hvis meddelelsen "fejl ved kopiering af serverindhold: Forbindelsen udløb" er identificeret. Tilsvarende skal denne værdi øges trinvist, indtil der observeres et fald i sådanne meddelelser. Vær dog forsigtig med ikke at øge denne værdi for meget, da det kan maskere underliggende problemer på backend-siden. Standardværdien er 45 sekunder, så overvej at øge den til 60 sekunder eller mere, og overvåg for fravær af fejl.
Hyppighed for at kontrollere genopstandne backendsI tilfælde hvor højere timeouts er nødvendige på grund af netværks- eller applikationsserverproblemer, der forårsager periodiske HTTP 503-fejl (hvilket indikerer, at der ikke er nogen tilgængelig service-backend), bør du overveje at reducere denne værdi fra 10 sekunder til 5. Denne justering hjælper med at afbøde falske positiver ved at markere backends som nede på grund af timeouts. Analyser, om timeouts er inden for normale grænser, da proxy-belastningsbalanceren kan afhjælpe visse problemer i denne sammenhæng.
Udfør venligst en grundig analyse for at fastslå normaliteten af timeouts. Proxy-belastningsbalanceren har evnen til at håndtere og afhjælpe visse timeout-relaterede problemer.
For mere detaljerede oplysninger, se følgende artikel:
Konfigurer sundhedstjek #
Farm Guardian har til formål at aktivere eller deaktivere backends baseret på deres tilgængelighed. I dette scenarie giver Farm Guardian os mulighed for at fastslå den faktiske tilgængelighed af backends. Denne proces fungerer uafhængigt og parallelt med proxyen, hvilket giver en måde at verificere, om backend-problemer reelt bidrager til en flaskehals på backend-siden. Derudover kan vi ved at undersøge backend-statistikker, når en backend er markeret som nede, bestemme antallet af forbindelser, der håndteres af den pågældende server, hvilket gør det muligt for os at identificere forbindelsesgrænserne for hver backend.
Konfiguration af en FarmGuardian-kontrol til TCP giver os mulighed for at identificere eventuelle problemer med handshake med backends, hvilket kan indikere en flaskehals på system- eller webserverlaget. På den anden side hjælper konfiguration af en FarmGuardian-kontrol til HTTP med at identificere problemer på applikationslaget med backends, hvilket peger på potentielle flaskehalse i applikations- eller databaselaget.
Rettelse af timeouts på klientsiden #
Verifikation af netværkslag #
For at validere netværkets stabilitet skal du udføre en pingtest fra en anden server eller maskine til IP-adressen for den virtuelle IP, der er konfigureret til load balancing farmen. Dette sikrer et eksternt perspektiv og hjælper med at bekræfte netværkets pålidelighed.
Verifikation af legitime klienter #
Brug sikre værktøjer til at identificere, om timeout-problemer er forbundet med legitime klienter, robotter eller potentielle angribere. Hvis timeouts er knyttet til uautoriserede brugere, skal du implementere IPDS-sortlister og/eller DoS-beskyttelse for at beskytte dine tjenester og sikre levering kun til gyldige og ægte brugere.
Justering af proxy-timeouts #
Overvej desuden at justere proxy-timeouts for at imødekomme arten af klienter, der opretter forbindelse til dine tjenester via load balancer. Hvis f.eks. mobilbaserede klienter, firewallproblemer eller langsomme netværk bidrager til forlængede svartider, skal du finjustere Timeout for klientanmodning valgmulighed i Avancerede indstillinger af din LSLB-gård. Standardværdien er 30 sekunderDu kan øge den til 60 sekunder eller mere afhængigt af dine specifikke krav. Klientens timeout-værdi skal overstige summen af forbindelsestimeout og backend-responstimeout.
For mere detaljerede oplysninger henvises til følgende artikel:
