PĂ«rshĂ«ndetje tĂ« gjithĂ«ve! Emri im Ă«shtĂ« Dmitry Samsonov, jam administrator sistemi nĂ« «ĐĐŽĐœĐŸĐșлаŃŃĐœĐžĐșĐ°Ń
». Kemi më shumë se 7,000 servera fizikë, 11,000 kontejnerë në cloud tonë dhe 200 aplikacione që në konfiguracione të ndryshme formojnë 700 klastere të ndryshme. Shumica dërrmuese e serverave punojnë nën menaxhimin e CentOS 7.
Më 14 gusht 2018, u publikua informacion mbi një vulnerabilitet FragmentSmack
() dhe SegmentSmack (). Këto janë vulnerabilitete me një vektor sulmi në rrjet dhe një vlerësim mjaft të lartë (7.5), që rrezikon shërbimin (DoS) për shkak të shterimit të burimeve (CPU). Në atë kohë, një rregullim në kernel për FragmentSmack nuk ishte propozuar, madje doli shumë pas publikimit të informacionit për vulnerabilitetin. Për të eliminuar SegmentSmack, u sugjerua të përmbylleshin kernelin. Paketa e përditësimit u publikua atë ditë, vetëm duhej të instalohej.
Jo, ne nuk jemi kundër përditësimit të kernelit! Megjithatë, ka disa nuanca...
Si e përditësojmë kernelin në prodhim
Në përgjithësi, nuk ka asgjë të komplikuar:
- Shkarkoni paketat;
- Instaloni ato në një numër serverash (duke përfshirë serverat që hostojnë cloudin tonë);
- Sigurohuni që asgjë nuk është prishur;
- Kontrolloni që të gjitha parametrat standard të kernelit janë aplikuar pa gabime;
- Pritni disa ditë;
- Kontrolloni parametrat e serverave;
- Ăaktivizoni implementimin e serverĂ«ve tĂ« rinj nĂ« kernelin e ri;
- Përditësoni të gjithë serverat sipas qendrave të të dhënave (një qendër të dhënash në një kohë, për të minimalizuar efektin për përdoruesit në rast të problemeve);
- Rinisni të gjithë serverat.
Përsëritni për të gjitha degët e kernelëve që kemi. Aktualisht, këto janë:
- Stoku CentOS 7 3.10 â pĂ«r shumicĂ«n e serverave tĂ« zakonshĂ«m;
- Vanilla 4.19 â pĂ«r cloudin tonĂ« one-cloud, , sepse na duhen BFQ, BBR etj.;
- Elrepo kernel-ml 5.2 â pĂ«r sepse 4.19 mĂ« parĂ« kishte sjellje tĂ« papĂ«rshtatshme dhe na duhen tĂ« njĂ«jtat karakteristika.
Siç mund ta keni kuptuar, më shumë kohë merr rinisja e mijëra serverave. Duke qenë se jo të gjitha vulnerabilitetet janë kritike për të gjithë serverat, ne rinisim vetëm ata që janë direkt të arritshëm nga interneti. Në cloud, për të mos kufizuar fleksibilitetin, nuk i lidhim kontejnerët e arritshëm jashtë me servera të veçantë me kernel të ri, por rinisim të gjithë hostet pa përjashtim. Me fat, procedura atje është më e thjeshtë se në serverat e zakonshëm. Për shembull, kontejnerët stateless mund të kalojnë thjesht në një server tjetër gjatë rinisjes.
MegjithatĂ«, puna Ă«shtĂ« ende shumĂ«, dhe mund tĂ« zgjasĂ« disa javĂ«, dhe nĂ« rast tĂ« ndonjĂ« problemi me versionin e ri â deri nĂ« disa muaj. KriminelĂ«t e kuptojnĂ« kĂ«tĂ« shumĂ« mirĂ«, pĂ«r kĂ«tĂ« arsye na nevojitet njĂ« plan 'B'.
FragmentSmack/SegmentSmack. Workaround
Me fat, për disa vulnerabilitete ka një plan 'B' të tillë, që quhet Workaround. Shpesh herë, kjo është një ndryshim i parametrave të kernelit/aplikacioneve, të cilat lejojnë minimizimin e efektit të mundshëm ose përjashtimin e plotë të shfrytëzimit të vulnerabiliteteve.
Në rastin e FragmentSmack/SegmentSmack një Workaround të tillë:
«Mund të ndryshoni vlerat e paracaktuara 4MB dhe 3MB në net.ipv4.ipfrag_high_thresh dhe net.ipv4.ipfrag_low_thresh (dhe ekuivalente të 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ë pak. Testet tregojnë rënie të vogël deri në të konsiderueshme të përdorimit të CPU gjatë sulmit, në varësi të pajisjeve, konfigurimeve dhe kushteve. Megjithatë, mund të ketë disa ndikim në performancë për shkak të ipfrag_high_thresh=262144 bytes, pasi vetëm dy fragmente 64K mund të përshtaten në radhën për ricilësim. Për shembull, ka rrezik që aplikacionet që punojnë me paketa të mëdha UDP mund të prishen.».
Parametrat vetë përshkruhen si:
ipfrag_high_thresh - NUMĂR I GJATĂ
    Kufiri maksimal i memories së përdorur për të ribërë fragmentet IP.
ipfrag_low_thresh - NUMĂR TĂ GJATĂ
    Memoria maksimale e përdorur për të rindërtuar fragmentet IP para se bërthama
    të fillojë të heqë radhët e paplota të fragmenteve për të liruar burime.
    Bërthama ende pranon fragmente të reja për defragmendimin.
NĂ« shĂ«rbimet e prodhimit nuk kemi trafik tĂ« madh UDP. NĂ« LAN, trafiku i fragmentuar mungon, nĂ« WAN ka, por jo nĂ« masĂ« tĂ« madhe. AsgjĂ« nuk paralajmĂ«ron â mund tĂ« aplikojmĂ« Workaround!
FragmentSmack/SegmentSmack. Gjaku i parë
Problemi i parĂ« qĂ« u pĂ«rballĂ«m ishte qĂ« kontejnerĂ«t e cloud-it ndonjĂ«herĂ« aplikonin konfigurimet e reja vetĂ«m pjesĂ«risht (vetĂ«m ipfrag_low_thresh), dhe ndonjĂ«herĂ« nuk aplikoheshin fare â thjesht binin nga fillimi. Nuk arritĂ«m tĂ« riprodhonim problemin nĂ« mĂ«nyrĂ« tĂ« qĂ«ndrueshme (manualisht, tĂ« gjitha konfigurimet aplikuar pa ndonjĂ« vĂ«shtirĂ«si). TĂ« kuptuarit se pĂ«rse kontenieri bie nga fillimi, nuk Ă«shtĂ« aq e lehtĂ«: nuk u zbulua asnjĂ« gabim. NjĂ« gjĂ« ishte e sigurt: rikthimi i konfigurimeve zgjidh problemin e binjes sĂ« konteinerĂ«ve.
Pse nuk është e mjaftueshme të aplikohet Sysctl në host? Kontenieri jeton në hapësirën e tij të dedikuar rrjetore, kështu që të paktën në kontenier mund të ndryshojë nga hosti.
Si po pĂ«rdoren ndayarjet e Sysctl nĂ« kontejner? Duke qenĂ« se kontejnerĂ«t tanĂ« janĂ« tĂ« papĂ«rjashtuar, nuk Ă«shtĂ« e mundur tĂ« ndryshosh ndonjĂ« çështje tĂ« Sysctl, duke hyrĂ« nĂ« vetĂ« kontejnerin â thjesht nuk ka tĂ« drejta. NĂ« atĂ« kohĂ«, pĂ«r tĂ« filluar kontejnerĂ«t, infrastruktura jonĂ« pĂ«rdorte Docker (tani Ă«shtĂ« tashmĂ« ). Parametrat e kontejnerit tĂ« ri dĂ«rgoheshin nĂ« Docker pĂ«rmes API-sĂ«, pĂ«rfshirĂ« ndayarjet e nevojshme tĂ« Sysctl.
GjatĂ« kontrollimit tĂ« versioneve, u zbulua se API Docker nuk e ktheu tĂ« gjitha gabimet (tĂ« paktĂ«n nĂ« versionin 1.10). Kur u pĂ«rpoqĂ«m tĂ« nisnim kontejnerin pĂ«rmes âdocker runâ, mĂ« nĂ« fund pamĂ« diçka:
write /proc/sys/net/ipv4/ipfrag_high_thresh: argument i pavlefshëm docker: Gabim përgjigje nga demon: Nuk mund të nisni kontejnerin : [9] Gabimi i sistemit: nuk mund të sinkronizohej me procesin e kontejnerit.
Vlera e parametrave Ă«shtĂ« e pavlefshme. Por pse? Dhe pse Ă«shtĂ« e pavlefshme vetĂ«m ndonjĂ«herĂ«? U zbulua se Docker nuk garanton rendin e aplikimit tĂ« parametrave tĂ« Sysctl (versioni mĂ« i fundit tĂ« kontrolluar â 1.13.1), kĂ«shtu qĂ« ndonjĂ«herĂ« ipfrag_high_thresh pĂ«rpiqej tĂ« vendosej nĂ« 256K, kur ipfrag_low_thresh ishte ende 3M, pra kufiri i sipĂ«rm ishte mĂ« i ulĂ«t se ai i poshtĂ«m, duke sjellĂ« gabimin.
Në atë moment, ne tashmë kishim përdorur mekanizmin tonë për konfigurinë e kontejnerit pas nisjes (ngrirja e kontejnerit përmes dhe ekzekutimi i komandave në namespace të kontejnerit përmes ), dhe ne e shtuam gjithashtu shkruarjen e parametrave Sysctl në këtë pjesë. Problemi u zgjidh.
FragmentSmack/SegmentSmack. Gjaku i parë 2
Ende pa u marrë vesh me aplikimin e Workaround në cloud, filluan të vijnë ankesat e para të rralla nga përdoruesit. Në atë kohë kishin kaluar disa javë që nga fillimi i aplikimit të Workaround në serverat e parë. Hetimi fillestar tregoi se ankesat ishin për shërbime të veçanta dhe jo për të gjitha serverët e atyre shërbimeve. Problemi përsëri kishte fituar një natyrë shumë të paqartë.
Së pari, sigurisht që provuam të kthenim ndayarjet e Sysctl, por kjo nuk dha asnjë efekt. Manipulime të ndryshme me ndayarjet e serverit dhe aplikacionit gjithashtu nuk ndihmuan. Kthehu ndihmoi. Kthehu për Linux është po aq i pavolitshëm sa ishte një kusht normal për të punuar me Windows në ditët e kaluara. Megjithatë, ndihmoi, dhe ne e lashë gjithçka në «një defekt në bërthamë» gjatë aplikimit të ndayarjeve të reja në Sysctl. Sa e lehtë ishte kjo...
Pas tre javësh, problemi u përsëriti. Konfigurimi i këtyre serverëve ishte mjaft i thjeshtë: Nginx në modalitetin proxy/balancues. Ka pak trafik. Një informacion i ri: me kalimin e ditëve, numri i gabimeve 504 () po rritej te klientët. Në grafik shikohet numri i gabimeve 504 në ditë për këtë shërbim:
TĂ« gjitha gabimet i referoheshin backend-it tĂ« njĂ«jtĂ« â atij qĂ« ndodhet nĂ« cloud. Grafiku i konsumit tĂ« memories pĂ«r fragmente paketash nĂ« kĂ«tĂ« backend dukej si nĂ« vijim:
Ky është një nga manifestimet më të dukshme të problemit në grafikat e sistemit operativ. Në cloud pikërisht në atë kohë u fik një tjetër problem rrjetor me ndayarjet QoS (Traffic Control). Në grafikun e konsumit të memories për fragmente paketash duket saktësisht ashtu si kjo:
Hipoteza ishte e thjeshtë: nëse në grafikat ato duken njësoj, atëherë edhe shkaku i tyre është i njëjtë. Sidomos sepse ndodhin shumë rrallë probleme me këtë lloj memorie.
Thelbi i problemit të zgjidhur ishte se ne përdorim në QoS programin e planifikimit fq me ndayarjet e defautit. Në mënyrë të paracaktuar për një lidhje ai lejon të shtohen në radhë 100 paketa dhe disa lidhje në situata mungese të kanalit filluan të mbushnin radhën deri në tejkalim. Në këtë rast paketat e hodhura. Në statistikën tc (tc -s qdisc) kjo duket kështu:
qdisc fq 2c6c: prindi 1:2c6c kufizimi 10000p fluksi_limit 100p zona 1024 maska_orfane 1023 quantum 3028 quantum_fillese 15140 vonde_delay 40.0ms
 Dërguar 454701676345 byte 491683359 pkt (të braktisur 464545, mbi limite 0 rikthime 0)
 backlog 0b 0p rikthime 0
  1024 flukse (1021 jo aktive, 0 të ngadaltë)
  0 gc, 0 prioritet të lartë, 0 të ngadaltë, 464545 flukset_plimit
«464545 flows_plimit» â kjo Ă«shtĂ« paketa qĂ« u hodhĂ«n pĂ«r shkak tĂ« tejkalimit tĂ« kufirit tĂ« radhĂ«s sĂ« njĂ« lidhjeje, ndĂ«rsa «dropped 464545» â kjo Ă«shtĂ« shuma e gjithsej paketave tĂ« hedhura nga ky planifikues. Pas rritjes sĂ« gjatĂ« tĂ« radhĂ«s nĂ« 1000 dhe rinisjes sĂ« kontejnerĂ«ve, problemi nuk u shfaq mĂ«. Mund tĂ« shtrihesh nĂ« karrigen dhe tĂ« pish njĂ« smoothie.
FragmentSmack/SegmentSmack. Gjaku i fundit
Së pari, pas disa muajsh që nga njoftimi i dobësive në kernel, përfundimisht doli një rregullim për FragmentSmack (kujtojmë se me njoftimin në gusht doli një rregullim vetëm për SegmentSmack), çka na dha mundësinë për të hequr dorë nga Workaround-i, i cili na ka shkaktuar shumë shqetësime. Disa serverë gjatë kësaj kohe i çuam në kernelin e ri, dhe tani duhej të fillonim nga e para. Pse i përditësuam kernelët, pa pritur rregullimin për FragmentSmack? E vërteta është se procesi i mbrojtjes nga këto dobësi përputhej (dhe bashkohej) me procesin e përditësimit të vetë CentOS (gjë që zgjat edhe më shumë se përditësimi vetëm i kernelit). Për më tepër, SegmentSmack është një dobësi më e rrezikshme, dhe rregullimi për të doli menjëherë, prandaj kishte një sens në çdo rast. Megjithatë, thjesht nuk mund të përditësonim kernelin në CentOS sepse dobësia e FragmentSmack, e cila ka lindur gjatë CentOS 7.5, u rregullua vetëm në versionin 7.6, kështu që na duhej të ndalonim përditësimin deri në 7.5 dhe të fillonim gjithçka nga e para me përditësimin në 7.6. Dhe kështu ndodhin gjërat.
Së dyti, na janë rikthyer ankesa të rralla nga përdoruesit për probleme. Tani e dimë për siguri se të gjitha ato lidhen me ngarkimin e skedarëve nga klientët në disa nga serverët tanë. Për më tepër, përmes këtyre serverëve kalonin një numër shumë i vogël ngarkimesh nga masa e përgjithshme.
Siç e mbajmë mend nga tregimi më sipër, kthimi i Sysctl nuk ndihmonte. Pjesërisht ndihmonte Rindizja, por përkohësisht.
Dyshimet për Sysctl nuk ishin shuar, por kësaj radhe kërkohej të grumbullohej sa më shumë informacion. Po ashtu, na mungonte shumë mundësia për të riprodhuar problemin me ngarkim në klient, për të studiuar më në detaje se çfarë po ndodhte.
Analiza e të gjitha statistikave dhe logeve të disponueshme nuk na afroi asgjë në kuptimin e asaj që po ndodhte. Mungonte ashpër mundësia për të riprodhuar problemin, për të "kontrolluar" njësinë specifike të lidhjes. Së fundmi, zhvilluesve në versionin special të aplikacionit iu arrit të riprodhojnë problemet në një pajisje testuese gjatë lidhjes përmes Wi-Fi. Kjo ishte një përparësi në hetim. Klienti u lidh me Nginx, i cili e proksoi në backend, që ishte aplikacioni ynë në Java.
Dialozi gjatë problemeve ishte kështu (i regjistruar në anën e Nginx-proxyt):
- Klienti: kërkesë për informacione mbi rikuperimin e skedarëve.
- Java-server: përgjigje.
- Klienti: POST me skedarin.
- Java-server: gabim.
Java-server në këtë rast shkruan në log se ka marrë 0 byte të dhënash nga klienti, ndërsa Nginx-proxyt thotë se kërkesa zgjati më shumë se 30 sekonda (30 sekonda është koha e skadimit për aplikacionin e klientit). Pse skadimi dhe pse 0 byte? Nga pikëpamja e HTTP-së, gjithçka po funksionon siç duhet, por POST-i me skedar si duket zhduket nga rrjeti. Madje, zhduket mes klientit dhe Nginx. Ka ardhur koha për t'u armatosur me Tcpdump! Por fillimisht duhet të kuptojmë konfigurimin e rrjetit. Nginx-proxyt qëndron pas një balancuesi L3. . Përdoret tunelimi për të dërguar paketat nga balancuesi L3 në server, i cili shton header-at e tij në paketa:
Ndërsa rrjeti në këtë server vjen në formën e trafikut të etiketuar Vlan, i cili gjithashtu shton fushat e tij në paketa:
Dhe ky trafik gjithashtu mund të fragmetizohet (ai përqindje e vogël e trafikut të pranuar të fragmentuar, për të cilin kemi folur në vlerësimin e risqeve nga Workaround), çka gjithashtu ndryshon përmbajtjen e header-ave:
Për një herë tjetër: paketat janë inkapsuluar me etiketa Vlan, janë inkapsuluar në tunel, janë fragmentizuar. Për të kuptuar saktë si ndodh kjo, do të ndjekim rrugën e paketës nga klienti deri te Nginx-proxy.
- Paketat arrijnë në balancuesin L3. Për një ruter të saktë brenda qendrës së të dhënave, paketa inkapsulohet në tunel dhe dërgohet në kartelën rrjetë.
- Duke qenë se paketa + header-at e tunelit nuk ngjiten në MTU, paketa pritet në fragmente dhe dërgohet në rrjetë.
- Switchi pas balancuesit L3, kur merr paketën, i shton një etiketë Vlan dhe e dërgon më tej.
- Switchi përpara Nginx-proxyt sheh (sipërfaqet e portit) se serveri po pret një paketë të inkapsuluar Vlan, prandaj e dërgon ashtu siç është, pa hequr etiketën Vlan.
- Linux merr fragmentet e paketimeve individuale 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 e Tunelit, ku hiqet njĂ« shtresĂ« tjetĂ«r â inkapsulimi i Tunelit.
Vështirësia është ta kalosh të gjithë këtë si parametra në tcpdump.
Të fillojmë me fundin: a ka paketa të pastra (pa header-at e tepërt) IP nga klientët, me heqjen e inkapsulimit vlan dhe tunel?
tcpdump host
Jo, nuk kishte paketash të tilla në server. Prandaj, problemi duhet të jetë përpara. A ka paketa me vetëm heqjen e inkapsulimit 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, nĂ« tĂ« cilĂ«n shkruhet SCR IP nĂ« paketĂ«n Tunnel.
Adresa e fushës duhet të merret përmes provës, pasi në internet shkruhet 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ë llogarisni, për cilën adresë është adresa IP e njohur për ju.
A ka fragmente paketash pa hequr Vlan- dhe Tunnel-inkapsulimin?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Kjo magji do të na tregojë të gjithë fragmentet, duke përfshirë të fundit. Ndoshta mund të filtrohet dhe sipas IP-së, por unë nuk kam provuar, pasi paketa të tilla nuk ka shumë, dhe në rrjedhën e përgjithshme u gjetën lehtësisht ato që më duheshin. Ja ato:
14:02:58.471063 Në 00:de:ff:1a:94:11 eter IPv4 (0x0800), gjatësi 1516: (tos 0x0, ttl 63, id 53652, offset 0, flamuj [+], proto IPIP (4), gjatësi 1500)
    11.11.11.11 > 22.22.22.22: ip i prishur - 20 bajte mungojnë! (tos 0x0, ttl 50, id 57750, offset 0, flamuj [DF], proto TCP (6), gjatësi 1500)
    33.33.33.33.33333 > 44.44.44.44.80: Flamuj [.], sek 0:1448, ak 1, fitim 343, opsione [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 ethetipy 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 (me ID të njëjtë 53652) me fotografinë (shihet fjala Exif në paketën e parë). Për shkak se në këtë nivel paketat ekzistojnë, ndërsa në formën e mbledhur në dump, nuk ka, problemi është qartë me montimin. Më në fund, ka një konfirmim dokumentar për këtë!
Dekoderi i paketave nuk zbuloi asnjë problem që pengon montimin. Provova këtu: . Në fillim, gjatë përpjekjes për të vendosur diçka atje, dekoderit nuk i pëlqente formati i paketës. Doli që kishte disa oktete të tepërta midis Srcmac dhe Ethertype (të cilat nuk kishin lidhje me informacionin rreth fragmenteve). Pasi i fshiva ato, dekoderi funksionoi. Megjithatë, nuk zbuloi asnjë problem.
Pavarësisht si e kthen, përveç atyre Sysctl nuk u gjet ndonjë gjë tjetër. Duhej të gjeje një mënyrë për të identifikuar serverat problematikë, për të kuptuar përmasën dhe për të marrë një vendim për veprimet e ardhshme. Mjaft shpejt u gjet paketa e nevojshme:
netstat -s | grep "paketë ripërpunimi dështoi"
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ë zbuluara nga algoritmi i ripërpunimit IP (për çfarëdo arsye: skadimi, gabime, etj.)».
Mes grupit të serverëve, ku u studiua problemi, në dy ky numër rritej më shpejt, në dy të tjerë më ngadalë, ndërsa në dy të tjerë nuk rritej 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ë monitorohet.
Prania e një treguesi të besueshëm të problemeve është shumë e rëndësishme për të përcaktuar saktësisht nëse rikthimi i Sysctl ndihmon, pasi nga tregimi i mëparshëm e dimë se nuk mund ta kuptojmë menjëherë nga aplikacioni. Ky tregues do të ndihmonte në identifikimin e të gjitha vendeve problematike në prodhim para se t'i zbulojnë përdoruesit.
Pas rikthimit të Sysctl, gabimet në monitorim u ndalën, kështu që shkaku i problemeve u provua, ashtu siç dëshmua se rikthimi ndihmon.
Ne rikthyem cilësimet e fragmentimit në servera të tjerë, ku filloi një monitorim i ri, dhe diku ndamë më shumë memorie për fragmentet sesa kishte qenë deri atëherë si parazgjedhje (kjo kishte të bënte me statistikat udp, humbja e pjesore e të cilave nuk ishte e dukshme në kontekstin e përgjithshëm).
Pyetjet kryesore
Përse paketat fragmentohen në balancuesin tonë L3? Shumica e paketave që vijnë nga përdoruesit në balancues janë SYN dhe ACK. Këto paketa janë të vogla. Por, pasi pjesa e këtyre paketave është shumë e madhe, ne nuk e vëmë re praninë e paketave të mëdha që filluan të fragmentohen.
Shkaku ishte një skenar konfigurimi që ishte prishur në serverët me ndërfaqe Vlan (në atë moment kishte shumë pak serverë me trafik të etiketuar në prodhim). Advmss lejon që informatat në lidhje me paketat në drejtimin tonë të jetë më të vogla, për të përjashtuar fragmentimin pas ngjitjes së titujve të tunelit.
Përse rikthimi i Sysctl nuk ndihmoi, ndërsa ribashkimi ndihmoi? Rikthimi i Sysctl ndryshoi sasinë e memories në dispozicion për ngjitjen e paketave. Sidoqoftë, dukshëm vetë fakti i mbushjes së memories për fragmentet shkaktonte ngadalësim të lidhjeve, çka çonte në bllokimin e fragmentëve në radhë për një kohë të gjatë. Do të thotë se procesi bllokohej.
Ribashkimi e resetoi memorinë dhe gjithçka u rregullua.
A kishte mundësi të ishim pa Workaround? Po, por rreziku i lënies së përdoruesve pa shërbim në rast sulmi është i madh. Sigurisht, aplikimi i Workaround rezultoi në shfaqjen e problemeve të ndryshme, përfshirë ngadalësimin e një prej shërbimeve për përdoruesit, por megjithatë mendojmë se veprimet ishin të justifikuara.
Faleminderit shumĂ« Andrey Timofeyev () pĂ«r ndihmĂ«n nĂ« hetim, si dhe Alexey Krenyov () â pĂ«r punĂ«n titanike tĂ« azhurnimit tĂ« Centos dhe bĂ«rthamave nĂ« servera. NjĂ« proces qĂ« pĂ«r kĂ«tĂ« rast disa herĂ« duhej tĂ« fillonte nga e para, çka e zgjati pĂ«r disa muaj.
Burimi: habr.com
