Përshëndetje të gjithëve! Quhem Dmitry Samsonov, punoj si administrator kryesor i sistemeve në 'Odnoklassniki'. Ne kemi mbi 7 mijë servera fizikë, 11 mijë kontejnerë në re dhe 200 aplikacione që në konfigurime të ndryshme formojnë 700 klasterë të ndryshëm. Shumica dërrmuese e serverëve punojnë nën administrimin e CentOS 7.
Më 14 gusht 2018 u publikua informacioni për një dobësi të FragmentSmack
() dhe SegmentSmack (). Këto janë dobësi me vektor sulmi rrjetor dhe një vlerësim mjaft të lartë (7.5), e cila rrezikon shërbimin (DoS) për shkak të shterimit të burimeve (CPU). Një rregullim në bërthamë për FragmentSmack në atë kohë nuk ishte propozuar, madje, ai doli shumë më vonë pas publikimit të informacionit për dobësinë. Për të adresuar SegmentSmack, ishte sugjeruar të bëhej përmirësimi i bërthamës. Paketa e përmirësimit u lëshua në të njëjtën ditë, mbetej vetëm ta instalonim.
Jo, ne nuk jemi aspak kundĂ«r pĂ«rmirĂ«simit tĂ« bĂ«rthamĂ«s! MegjithatĂ«, ka nuancaâŠ
Si e përmirësojmë bërthamën në prodhim
Në përgjithësi, nuk ka asgjë të komplikuar:
- Shkarkoni paketat;
- Instaloni ato në një sasi serverësh (përfshirë serverët që hostojnë re tonë);
- Sigurohuni që asgjë të mos ishte prishur;
- Kontrolloni që të gjitha cilësimet standarde të bërthamës të ishin aplikuar pa gabime;
- Prisni disa ditë;
- Kontrolloni parametrat e serverëve;
- Drejtoni vendosjen e serverëve të rinj në bërthamën e re;
- Përmirësoni të gjithë serverët sipas qendrave të të dhënave (një qendër të dhënash në një kohë, për të minimizuar efektin për përdoruesit në rast problemas);
- Rinisni të gjithë serverët.
Përsëritni këtë për të gjitha degët e bërthamave që kemi. Deri më tani, këto janë:
- BĂ«rthama standarde CentOS 7 3.10 â pĂ«r shumicĂ«n e serverĂ«ve tĂ« zakonshĂ«m;
- BĂ«rthama vanilla 4.19 â pĂ«r re , sepse na nevojitet BFQ, BBR etj.;
- Elrepo kernel-ml 5.2 â pĂ«r , sepse 4.19 mĂ« parĂ« tregonte sjellje tĂ« paqĂ«ndrueshme, ndĂ«rsa karakteristikat janĂ« tĂ« njĂ«jta.
Si e keni marrë me mend, kjo procedurë merr më së shumti kohë për të rinisur mijëra serverë. Duke qenë se jo të gjitha dobësitë janë kritike për të gjithë serverët, ne rinisemi vetëm ato që janë të aksesueshme drejtpërdrejt nga interneti. Në re, për të mos kufizuar fleksibilitetin, ne nuk lidhen kontejnerët e aksesueshëm nga jashtë me serverë të veçantë me bërthamë të re, por rinisim të gjitha hostet pa përjashtim. Për fat të mirë, atje procedura është më e thjeshtë se me serverë të zakonshëm. Për shembull, kontejnerët stateless mund thjesht të kalojnë në një server tjetër gjatë rinisjes.
MegjithatĂ«, ende ka shumĂ« punĂ«, dhe kjo mund tĂ« zgjasĂ« disa javĂ«, ose nĂ« rast se ndodhin ndonjĂ« problem me versionin e ri â deri nĂ« disa muaj. KriminelĂ«t e kuptojnĂ« kĂ«tĂ« mirĂ«, prandaj na nevojitet njĂ« plan âBâ.
FragmentSmack\/SegmentSmack. Zgjidhje alternative
PĂ«r fat tĂ« mirĂ«, pĂ«r disa dobĂ«si ekziston njĂ« plan âBâ, i cili quhet Zgjidhje alternative. MĂ« sĂ« shpeshti, kjo do tĂ« thotĂ« ndryshimi i cilĂ«simeve tĂ« bĂ«rthamĂ«s\/aplikacioneve, qĂ« lejojnĂ« minimalizimin e efektit tĂ« mundshĂ«m ose pĂ«rjashtimin e plotĂ« tĂ« shfrytĂ«zimeve tĂ« dobĂ«sive.
Në rastin e FragmentSmack\/SegmentSmack një zgjidhje alternative të tillë:
«ĂshtĂ« e mundur tĂ« ndryshoni vlerat e parazgjedhura 4MB dhe 3MB nĂ« net.ipv4.ipfrag_high_thresh dhe net.ipv4.ipfrag_low_thresh (dhe ekuivalentet e tyre pĂ«r ipv6 net.ipv6.ipfrag_high_thresh dhe net.ipv6.ipfrag_low_thresh) nĂ« 256 kB dhe 192 kB pĂ«rkatĂ«sisht, ose mĂ« poshtĂ«. Testet tregojnĂ« se ka njĂ« rĂ«nie tĂ« vogĂ«l deri nĂ« tĂ« konsiderueshme tĂ« pĂ«rdorimit tĂ« CPU gjatĂ« sulmeve, nĂ« varĂ«si tĂ« pajisjeve, cilĂ«simeve dhe kushteve. megjithatĂ«, mund tĂ« ketĂ« njĂ« ndikim nĂ« performancĂ« pĂ«r shkak tĂ« ipfrag_high_thresh=262144 bytes, pasi vetĂ«m dy 64K-fragmente mund tĂ« vendosen njĂ«kohĂ«sisht nĂ« radhĂ« pĂ«r rinisje. PĂ«r shembull, ekziston rreziku qĂ« aplikacionet qĂ« funksionojnĂ« me paketa tĂ« mĂ«dha UDP tĂ« dĂ«shtojnĂ«.».
Parametrat e vetë përshkruhen si:
ipfrag_high_thresh - NUMĂR TĂ GJATĂ
    Memoria maksimale e përdorur për të ribashkuar fragmentet IP.
ipfrag_low_thresh - NUMĂR I GJATĂ
    Memoria maksimale e përdorur për të rindërtuar fragmente IP para se bërthama
    të fillojë të heqë radhët e paplota të fragmenteve për të çliruar burimet.
    Bërthama ende pranon fragmente të reja për defragmentim.
NĂ« shĂ«rbimet e prodhimit nuk kemi UDP tĂ« mĂ«dhenj. NĂ« LAN, trafik i frakturĂ«suar nuk ekziston, nĂ« WAN ka, por jo nĂ« pĂ«rmasa tĂ« mĂ«dha. AsgjĂ« nuk parashikon â ne mund tĂ« implementojmĂ« zgjidhjen alternative!
FragmentSmack\/SegmentSmack. Gjakimi i parë
Problemi i parĂ« me tĂ« cilin u pĂ«rballĂ«m ishte se kontejnerĂ«t e mjeteve nĂ« cloud shpesh i aplikonin konfigurimet e reja vetĂ«m pjesĂ«risht (vetĂ«m ipfrag_low_thresh), dhe ndonjĂ«herĂ« nuk i aplikonin fare â thjesht dĂ«shtonin nĂ« nisje. Nuk arritĂ«m ta riprodhojmĂ« problemin me stabilitet (ndĂ«rsa manualisht tĂ« gjitha konfigurimet aplikohej pa asnjĂ« vĂ«shtirĂ«si). TĂ« kuptosh pse kontejneri dĂ«shton nĂ« nisje, gjithashtu, nuk Ă«shtĂ« aq e lehtĂ«: nuk u gjetĂ«n ndonjĂ« gabim. NjĂ« gjĂ« ishte e sigurt: rikthimi i konfigurimeve zgjidhte problemin me dĂ«shtimin e kontejnerĂ«ve.
Pse nuk mjafton të aplikosh Sysctl në host? Kontejneri jeton në Namespace-in e tij të pavarur të rrjetit, prandaj të paktën në kontejner mund të jetë e ndryshme nga hosti.
Si aplikohet saktĂ«sisht konfigurimi i Sysctl nĂ« kontejner? Duke qenĂ« se kontejnerĂ«t tanĂ« janĂ« tĂ« pa privilegjuar, nuk mund tĂ« ndryshosh ndonjĂ« konfigurim Sysctl duke hyrĂ« brenda kontejnerit â thjesht nuk ka mjaft tĂ« drejta. PĂ«r nisjen e kontejnerĂ«ve, cloud-i ynĂ« nĂ« atĂ« kohĂ« pĂ«rdorte Docker (tani tashmĂ« ). Dokkerit i kaloheshin parametrat e kontejnerit tĂ« ri pĂ«rmes API-sĂ«, duke pĂ«rfshirĂ« konfigurimet e nevojshme Sysctl.
Gjatë shqyrtimit të versioneve u zbulua se API Docker nuk jepte të gjitha gabimet (të paktën në versionin 1.10). Në përpjekjen për të nisur kontejnerin përmes 'docker run', përfundimisht pamë diçka:
write /proc/sys/net/ipv4/ipfrag_high_thresh: argument i pavlefshëm docker: Përgjigja e gabimit nga daemoni: Nuk mund të nisi kontejnerin <...>: [9] Gabim sistemi: nuk mund të sinkronizohej me procesin e kontejnerit.
Vlera e parametrave nuk Ă«shtĂ« e vlefshme. Por pse? Dhe pse ajo nuk Ă«shtĂ« e vlefshme vetĂ«m ndonjĂ«herĂ«? U zbulua se Docker nuk garanton rendin e aplikimit tĂ« parametrave Sysctl (versioni mĂ« i fundit i verifikuar â 1.13.1), kĂ«shtu qĂ« ndonjĂ«herĂ« ipfrag_high_thresh pĂ«rpiqej tĂ« vendoseshin nĂ« 256K, kur ipfrag_low_thresh ishte ende 3M, qoftĂ« edhe kufiri superior ishte mĂ« i ulĂ«t se ai inferior, gjĂ« qĂ« çonte nĂ« gabimin.
Në atë kohë, ne tashmë kishim një mekanizëm të vetin për konfiguruar sërish kontejnerin pas nisjes (ndalimi i kontejnerit përmes dhe ekzekutimi i komandave në namespace-in e kontejnerit përmes ), dhe ne e shtuam këtë pjesë me shkrimin e parametrave Sysctl. Problemi u zgjidh.
FragmentSmack/SegmentSmack. Gjakderdhja e Parë 2
Nuk e arritëm të kuptojmë përdorimin e Workaround në re, sapo filluan të vijnë ankesat e para të rralla nga përdoruesit. Në atë kohë kishin kaluar disa javë nga fillimi i përdorimit të Workaround në serverët e parë. Hetimi fillestar tregoi se ankesat vinin për shkak të shërbimeve të veçanta, dhe jo për të gjithë serverët e këtyre shërbimeve. Problemi e mori përsëri një karakter të paqartë.
Në radhë të parë, natyrisht, ne provuam të kthejmë cilësimet e Sysctl, por kjo nuk pati asnjë efekt. Manovra të ndryshme me cilësimet e serverit dhe aplikacionit gjithashtu nuk ndihmuan. Ndihmoi reboot. Reboot për Linux është po aq i kundërt siç ishte një kusht normal për të punuar me Windows në ditët e kaluara. Megjithatë, ai ndihmoi dhe ne e trajtuam gjithçka si një 'defekt në bërthamë' gjatë përdorimit të cilësimeve të reja në Sysctl. Sa e lehtë ishte kjo...
Pas tre javësh, problemi u përsërit. Konfigurimi i këtyre serverëve ishte mjaft i thjeshtë: Nginx në mënyrën proxy/balancues. Nuk kishte shumë trafik. Një informacion i ri: numri i gabimeve 504-ësh po rritet çdo ditë te klientët (). Grafikoni tregon numrin e gabimeve 504 në ditë për këtë shërbim:
TĂ« gjitha gabimet bĂ«hen pĂ«r tĂ« njĂ«jtin backend â pĂ«r atĂ« qĂ« ndodhet nĂ« re. Grafikoni i konsumit tĂ« memorjes pĂ«r fraksionet e paketeve nĂ« kĂ«tĂ« backend dukej si mĂ« poshtĂ«:
Ky është një nga manifestimet më të dukshme të problemit në grafikët e sistemit operativ. Në re, pikërisht në atë kohë, u rregullua një problem tjetër rrjetëor me cilësimet QoS (Kontrolli i Trafikut). Grafikoni i konsumit të memorjes për fraksionet e paketeve dukej pikërisht ashtu si më parë:
Supozimi ishte i thjeshtë: nëse në grafikët ato duken të njëjta, atëherë edhe arsyeja është e njëjtë. Më shumë, pasi që ndodhin shumë rrallë probleme me këtë lloj memorjeje.
Thelbi i problemit të rregulluar ishte se ne përdornim në QoS programin e planifikimit të paketave fq me cilësimet e paracaktuara. Në mënyrë të paracaktuar, për një lidhje ai lejon të shtohen në radhë 100 paketa dhe disa lidhje në situatën e mungesës së kanalit filluan të mbushnin radhën deri në kufi. Në këtë rast, paketat hidhen. Në statistikën tc (tc -s qdisc) kjo duket ashtu:
qdisc fq 2c6c: prind 1:2c6c kufizim 10000p fluksi_kufizim 100p kanistra 1024 orphan_mask 1023 quantum 3028 quantum_fillest 15140 refill_delay 40.0ms
 Dërguar 454701676345 byte 491683359 pkt (të hequra 464545, mbi kufijtë 0, rikthime 0)
 backlog 0b 0p rikthime 0
  1024 flukset (1021 inaktive, 0 të kufizuara)
  0 gc, 0 prioritet të lartë, 0 të kufizuara, 464545 flukset_plimit
"464545 flows_plimit" është paketa e hedhur për shkak të tejkalimit të limitit të radhës së një lidhjeje, ndërsa "dropped 464545" është shuma e të gjitha paketave të hedhura nga ky planifikues. Pas rritjes së gjatësi së radhës deri në 1 mijë dhe rinisjes së kontejnerëve, problemi nuk u shfaq më. Mund të kthehesh në karrige dhe të pijë një smoothie.
FragmentSmack/SegmentSmack. Gjakët e fundit.
Së pari, pas disa muajsh nga njoftimi i dobësive në bërthamë, më në fund u shfaq një rregullim për FragmentSmack (të kujtojmë se bashkë me njoftimin në gusht doli vetëm një rregullim për SegmentSmack), e cila na dha një mundësi për t'u hequr nga Workaround, që na ka dhënë shumë shqetësime. Disa nga serverët e tanishëm i kemi kaluar në bërthamën e re dhe tani duhet të fillojmë nga e para. Pse e përmirësuam bërthamën pa pritur rregullimin për FragmentSmack? Arsyeja është se procesi i mbrojtjes nga këto dobësi përputhej (dhe u bashkua) me procesin e përditësimit të CentOS-it (cili zë shumë më shumë kohë se përditësimi vetëm i bërthamës). Për më tepër, SegmentSmack është më i rrezikshëm, dhe rregullimi për të u shfaq menjëherë, kështu që kishte arsye për veprim në çdo rast. Megjithatë, nuk mundëm thjesht të përmirësojmë bërthamën në CentOS sepse dobësia FragmentSmack, e cila u shfaq gjatë CentOS 7.5, u rregullua vetëm në versionin 7.6, prandaj na duhej të ndalonim përditësimin në 7.5 dhe të fillonim gjithçka nga e para me përditësimin në 7.6. Edhe kjo ndodh.
Së dyti, na janë kthyer disa ankesa të rralla nga përdoruesit për probleme. Tani e dimë me siguri se të gjitha janë të lidhura me ngarkimin e skedarëve nga klientët në disa nga serverët tanë. Ndërkohë, përmes këtyre serverëve kalonte një numër shumë të vogël ngarkimesh nga masa totale.
Siç e mbajmë mend nga përshkrimi më sipër, rikthimi i Sysctl-it nuk ndihmoi. Ndihmoi Rinisi, por përkohësisht.
Dyshimet mbi Sysctl-in nuk u hoqën, por kësaj here ishte e nevojshme të mblidheshin sa më shumë informata. Gjithashtu, na mungonte jashtëzakonisht mundësia për të riprodhuar problemin me ngarkimin te klienti, për të studiuar më saktë se çfarë po ndodhte.
Analiza e gjithë statistikave dhe logjeve të disponibile nuk na afroi me një kuptim të situatës. Mungonte ndjeshëm mundësia për të riprodhuar problemin, për të "prekur" një lidhje specifike. Së fundi, zhvilluesit në versionin special të aplikacionit arritën të sigurojnë një riprodhim të qëndrueshëm të problemeve në pajisjen e testimit kur ishin të lidhur përmes Wi-Fi. Kjo ishte një përparësi në hetim. Klienti u lidh me Nginx, i cili e riprosesoronte në backend, që ishte aplikacioni ynë në Java.
Dialogu në rast probleme ishte njëlloj (i regjistruar nga Nginx-proksi):
- Klienti: kërkesë për informacion mbi vazhdimin e skedarit.
- Java-server: përgjigje.
- Klienti: POST me skedarin.
- Java-server: gabim.
Java-server, nga ana tjetĂ«r, shkruan nĂ« log qĂ« ka marrĂ« 0 byte tĂ« dhĂ«nash nga klienti, ndĂ«rsa Nginx-proksi thotĂ« se kĂ«rkesa zgjati mĂ« shumĂ« se 30 sekonda (30 sekonda Ă«shtĂ« koha e skadimit nĂ« aplikacionin e klientit). Pse ndodhi skadimi dhe pse 0 byte? Nga pikĂ«pamja e HTTP-sĂ«, gjithçka funksionon siç duhet, por POST me skedarin duket se humbet nĂ« rrjet. Dhe humbet ndĂ«rmjet klientit dhe Nginx. ĂshtĂ« koha tĂ« armatosemi me Tcpdump! Por pĂ«rpara se gjithçka, duhet tĂ« kuptojmĂ« konfigurimin e rrjetit. Nginx-proksi ndodhet pas njĂ« balancuesi L3 . PĂ«rdoret tunelizimi pĂ«r dĂ«rgimin e paketave nga balancuesi L3 nĂ« server, e cila shton headerat e saj nĂ« paketa:
Njëkohësisht, rrjeti në këtë server vjen në formën e trafikut të tag-uar Vlan, e cila gjithashtu shton fushat e saj në paketa:
Dhe po ashtu, ky trafik mund të fragmentizohet (ai përqindje e vogël e trafikut të fragmentizuar që kemi përmendur në vlerësimin e rreziqeve nga Workaround), që gjithashtu e ndryshon përmbajtjen e headerave:
Këtu, paketat janë të inkapsuluara me tag-un e Vlan, janë të inkapsuluara me tunelin, janë të fragmentizuara. Për të kuptuar më saktë se si ndodh këtë, do të ndjekim rrugën e paketës nga klienti deri te Nginx-proksi.
- Paketa arrin te balancuesi L3. Për të siguruar një rrugëzim të saktë brenda qendrës të të dhënave, paketa inkapsulohet në një tunel dhe dërgohet në kartën rrjetësore.
- Pasi që paketa + headerat e tunelit nuk i përshtaten MTU-së, paketa ndahen në fragmente dhe dërgohen në rrjet.
- Switch-i pas balancuesit L3, kur merr paketën, i shton tag-un e Vlan dhe e dërgon më tej.
- Switchi para Nginx-proksi sheh (sipas konfigurimeve të portit) se serveri pret një paketë të inkapsuluar Vlan, prandaj e dërgon atë ashtu siç është, pa e hequr etiketën Vlan.
- Linux merr fragmente të paketave të veçanta dhe i bashkon ato në një paketë të madhe.
- Pastaj paketa arrin nĂ« ndĂ«rfaqen Vlan, ku hiqet shtresa e parĂ« â inkapsulimi Vlan.
- MĂ« pas, Linux e dĂ«rgon atĂ« nĂ« ndĂ«rfaqen Tunnel, ku hiqet edhe njĂ« shtresĂ« â inkapsulimi Tunnel.
Sfidimi është ta kalosh të gjitha këto si parametra në tcpdump.
Le të fillojmë nga fundi: a ka paketat e pastra (pa tituj të panevojshëm) IP nga klientët, me inkapsulim të hequr vlan dhe tunnel?
tcpdump host
Jo, nuk kishte paketa të tilla në server. Pra, problemi duhet të jetë më herët. A ka paketa me inkapsulim të hequr vetëm Vlan?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx â kjo Ă«shtĂ« adresa IP e klientit nĂ« formatin hex.
32:4 â adresa dhe gjatĂ«sia e fushĂ«s ku Ă«shtĂ« regjistruar IP SCR nĂ« paketĂ«n Tunnel.
Adresa e fushës duhej të merren përmes provave, pasi në internet shkruhen për 40, 44, 50, 54, por atje nuk kishte adresa IP. Gjithashtu, mund të shihni një nga paketat në hex (parametri -xx ose -XX në tcpdump) dhe të llogaritni se në cilën adresë është IP e njohur.
A ka fragmente paketash pa hequr inkapsulimin Vlan dhe Tunnel?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Kjo magji do të na tregojë të gjitha fragmentet, duke përfshirë të fundit. Sigurisht, gjithashtu mund të filtrohet sipas IP, por unë nuk kam provuar, pasi nuk ka shumë paketa të tilla, dhe në fluksin e përgjithshëm u gjetën lehtësisht ato që më duheshin. Ja ato:
14:02:58.471063 Në 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), gjatësi 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), gjatësi 1500)
    11.11.11.11 > 22.22.22.22: truncated-ip - 20 byte të munguar! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), gjatësi 1500)
    33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], gjatësi 1448
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
        0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 .faEE.....@.2.m.
        0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
        0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.......
        0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx
        0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 nëse..MM.*........
14:02:58.471103 Në 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), gjatësi 62: (tos 0x0, ttl 63, id 53652, offset 1480, flamuj [asnjë], proto IPIP (4), gjatësi 40)
    11.11.11.11 > 22.22.22.22: ip-proto-4
        0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
        0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
        0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
        0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
        0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............
Këto janë dy fragmente të një pakete (ID i njëjtë 53652) me fotografi (duket fjala Exif në paketën e parë). Për shkak se në këtë nivel paketat janë, dhe në formën e bashkuar në dump nuk ka, problemi është qartë me montimin. Në fund, ka një dokumentim për këtë!
Dekoderi i paketave nuk zbuloi asnjë problem që pengon montimin. Kam provuar këtu: . Në fillim, kur u përpoqëm të dërgojmë diçka atje, dekoduesi nuk e pëlqente formatin e paketës. Doli se kishte dy oktete shtesë mes Srcmac dhe Ethertype (të papërfshira në informacionin mbi fraksionet). Pas heqjes së tyre, dekoduesi filloi të funksiononte. Megjithatë, nuk tregoi asnjë problem.
Sikur të mos ishte kështu, nuk gjeta asgjë përveç atyre Sysctl. Duhej të gjeja një mënyrë për të identifikuar serverët e problematik, për të kuptuar shkallën dhe për të marrë një vendim për veprimet e dukshme. Mjaft shpejt u gjet numri i duhur:
netstat -s | grep "packet reassembles failedâ
Ai është gjithashtu në snmpd nën OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
âNumri i dĂ«shtimeve tĂ« konstatuara nga algoritmi i rishikimit tĂ« IP (pĂ«r çfarĂ«do arsye: skadimi, gabime, etj.)â.
Në mes të grupit të serverëve, ku problemi u studiuar, në dy ky numër u rrit më shpejt, në dy të tjerë u rrit ngadalë, ndërsa në dy të tjerë nuk u rrit fare. Krahasimi i dinamikës së këtij numri me dinamikën e gabimeve HTTP në serverin Java zbuloi një korelacion. Pra, numri mund të ishte vendosur për monitorim.
Prania e një treguesi të besueshëm të problemeve është shumë e rëndësishme, për të qenë në gjendje të përcaktojmë saktësisht nëse rikthimi i Sysctl ndihmon, pasi nga tregimi i mëparshëm e dimë që nuk mund ta kuptojmë menjëherë nga aplikacioni. Ky tregues do të lejonte identifikimin e të gjitha pikave problematike në prodhim përpara se ta zbulojnë përdoruesit.
Pas rikthimit të Sysctl, gabimet nga monitorimi u ndalën, kështu që arsyeja e problemeve u provua, ashtu si dhe se rikthimi ndihmon.
Ne rikthyem cilësimet e fraksionimit në serverët e tjerë, ku u ndez një monitorim i ri, dhe diku për fragmente u ndan edhe më shumë memorie se sa ishte më parë si standard (kjo ishte statistika e udp, humbja e pjesore e të cilës nuk ishte e dukshme në kontekstin e përgjithshëm).
Pyetjet më të rëndësishme
Pse paketat fraksionohen në balancuesin tonë L3? Shumica e paketave që vijnë nga përdoruesit në balancuesit janë SYN dhe ACK. Madhësitë e këtyre paketave janë të vogla. Por, pasi pjesa e tillë e paketave është shumë e madhe, ne nuk e vërejmë praninë e paketave më të mëdha që filluan të fraksionohen.
Arsyeja ishte një skenar konfigurimi që u prish në serverat me ndërfaqe Vlan (atëherë në prodhim kishte shumë pak servera me trafik etiketuar). Advmss lejon që të përcjellim informacion te klienti se paketat që vijnë nga ana jonë duhet të jenë më të vogla, në mënyrë që pas ngjitjes së titujve të tunelit, ato të mos duhet të fragmentohen.
Pse rikthimi i Sysctl nuk ndihmoi, ndërsa rinisja ndihmoi? Rikthimi i Sysctl ndryshonte sasinë e memories në dispozicion për bashkimin e paketimeve. Në të njëjtën kohë, duket se vetë fakti i mbushjes së memories për fragmentet shkaktonte ngadalësim të lidhjeve, që çonte në një vonesë të gjatë të fragmenteve në radhë. Kështu që, procesi ishte i bllokuar.
Rinisja e fshinte memorien dhe gjithçka kthehej në rregull.
A mund të kishte qenë pa Workaround? Po, por rreziku ishte i madh për të lënë përdoruesit pa shërbim në rast sulmi. Sigurisht, aplikimi i Workaround përfundimisht shkaktoi probleme të ndryshme, duke përfshirë ngadalësimin e një nga shërbimet për përdoruesit, por gjithsesi ne besojmë se veprimet ishin të justifikuara.
Faleminderit shumĂ« Andrey Timofeyev () pĂ«r ndihmĂ«n nĂ« zhvillimin e hetimit, si dhe Alexey Krenyev () â pĂ«r punĂ«n titanike mbi pĂ«rditĂ«simin e Centos dhe kernelit nĂ« servera. Procesi, i cili nĂ« kĂ«tĂ« rast u desh tĂ« fillohej disa herĂ« nga e para, pĂ«r shkak tĂ« cilit zgjati pĂ«r shumĂ« muaj.
Burimi: habr.com
