🥇Pagbantay sa mga kahuyangan nga nagdala sa mga hugna sa trabaho. Bahin 1: FragmentSmack/SegmentSmack

Kumusta tanan! Ang akong ngalan mao si Dmitry Samsonov, nagtrabaho ko isip nanguna nga tigdumala sa sistema sa Odnoklassniki. Kami adunay labaw pa sa 7 ka libo nga pisikal nga mga server, 11 ka libo nga mga sudlanan sa among panganod ug 200 nga mga aplikasyon, nga sa lainlaing mga pag-configure nagporma sa 700 nga lainlaing mga kumpol. Ang kadaghanan sa mga server nagpadagan sa CentOS 7.
Niadtong Agosto 14, 2018, ang impormasyon bahin sa pagkahuyang sa FragmentSmack gipatik
(CVE-2018-5391) ug SegmentSmack (CVE-2018-5390). Kini ang mga kahuyangan nga adunay vector sa pag-atake sa network ug medyo taas nga marka (7.5), nga naghulga sa pagdumili sa serbisyo (DoS) tungod sa pagkahurot sa kapanguhaan (CPU). Ang usa ka pag-ayo sa kernel alang sa FragmentSmack wala gisugyot niadtong panahona; dugang pa, kini migawas sa ulahi kay sa pagmantala sa impormasyon mahitungod sa kahuyang. Aron mawagtang ang SegmentSmack, gisugyot nga i-update ang kernel. Ang update nga pakete mismo gipagawas sa samang adlaw, ang nahabilin mao ang pag-instalar niini.
Dili, dili gyud kami supak sa pag-update sa kernel! Bisan pa, adunay mga nuances ...

Giunsa namo pag-update ang kernel sa produksyon

Sa kinatibuk-an, walay komplikado:

Pag-download sa mga pakete;
I-install kini sa daghang mga server (lakip ang mga server nga nag-host sa among panganod);
Siguroha nga walay maguba;
Siguruha nga ang tanan nga sukaranan nga mga setting sa kernel gipadapat nga wala’y mga sayup;
Paghulat pipila ka adlaw;
Susihon ang performance sa server;
Ibalhin ang deployment sa bag-ong mga server ngadto sa bag-ong kernel;
I-update ang tanan nga mga server pinaagi sa data center (usa ka data center matag higayon aron maminusan ang epekto sa mga tiggamit kung adunay mga problema);
I-reboot ang tanan nga mga server.

Balika alang sa tanan nga mga sanga sa mga lugas nga naa kanato. Sa pagkakaron kini mao ang:

Stock CentOS 7 3.10 - alang sa kadaghanan sa mga regular nga server;
Vanilla 4.19 - para sa atoa usa ka panganod nga panganod, tungod kay gikinahanglan nato ang BFQ, BBR, ug uban pa;
Elrepo kernel-ml 5.2 - alang sa daghan kaayog mga distributor, tungod kay ang 4.19 kaniadto naglihok nga dili lig-on, apan gikinahanglan ang parehas nga mga bahin.

Sama sa imong nahunahunaan, ang pag-reboot sa libu-libo nga mga server nagkinahanglag labing taas nga oras. Tungod kay dili tanan nga mga kahuyangan kritikal alang sa tanan nga mga server, gi-reboot ra namon ang mga direkta nga ma-access gikan sa Internet. Sa panganod, aron dili limitahan ang pagka-flexible, dili namo ihigot ang mga sudlanan nga ma-access sa gawas ngadto sa indibidwal nga mga server nga adunay bag-ong kernel, apan i-reboot ang tanan nga mga host nga walay eksepsiyon. Maayo na lang, ang pamaagi didto mas simple kaysa sa mga regular nga server. Pananglitan, ang walay estado nga mga sudlanan mahimo ra nga mobalhin sa lain nga server sa panahon sa pag-reboot.

Bisan pa, adunay daghan pa nga trabaho, ug mahimo’g daghang mga semana, ug kung adunay bisan unsang mga problema sa bag-ong bersyon, hangtod sa daghang mga bulan. Ang mga tig-atake nakasabot kaayo niini, busa nagkinahanglan sila og plano B.

FragmentSmack/SegmentSmack. Pagsulbad

Maayo na lang, alang sa pipila ka mga kahuyangan adunay ingon nga plano B, ug kini gitawag nga Workaround. Kasagaran, kini usa ka pagbag-o sa mga setting sa kernel/aplikasyon nga makapamenos sa posible nga epekto o hingpit nga mawala ang pagpahimulos sa mga kahuyangan.

Sa kaso sa FragmentSmack/SegmentSmack gisugyot kini nga Workaround:

«Mahimo nimong usbon ang default values sa 4MB ug 3MB sa net.ipv4.ipfrag_high_thresh ug net.ipv4.ipfrag_low_thresh (ug ang ilang mga katugbang alang sa ipv6 net.ipv6.ipfrag_high_thresh ug net.ipv6.ipfrag_low_thresh) ngadto sa 256 kB ug 192 kB. ubos. Gipakita sa mga pagsulay ang gamay hangtod sa hinungdanon nga pag-ubos sa paggamit sa CPU sa panahon sa pag-atake depende sa hardware, setting, ug kondisyon. Bisan pa, mahimo nga adunay pipila nga epekto sa pasundayag tungod sa ipfrag_high_thresh=262144 bytes, tungod kay duha ra ka 64K nga mga tipik ang mahimong mohaum sa reassembly queue sa usa ka higayon. Pananglitan, adunay peligro nga ang mga aplikasyon nga nagtrabaho uban ang dagkong mga pakete sa UDP maguba".

Ang mga parameter mismo sa dokumentasyon sa kernel gihulagway ingon sa mosunod:

ipfrag_high_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments before the kernel begins to remove incomplete fragment queues to free up resources. The kernel still accepts new fragments for defragmentation.

Wala kami daghang mga UDP sa mga serbisyo sa produksiyon. Walay tipik nga trapiko sa LAN; adunay tipik nga trapiko sa WAN, apan dili mahinungdanon. Walay mga timailhan - mahimo nimong ilunsad ang Workaround!

FragmentSmack/SegmentSmack. Unang dugo

Ang una nga problema nga among nasugatan mao nga ang mga sulud sa panganod usahay magamit ang bag-ong mga setting sa partially (lamang ipfrag_low_thresh), ug usahay wala gyud magamit - nahulog ra sila sa pagsugod. Dili mahimo nga mabag-o ang problema nga lig-on (ang tanan nga mga setting gigamit nga mano-mano nga wala’y mga kalisud). Ang pagsabut kung ngano nga ang sudlanan nahagsa sa pagsugod dili usab kadali: wala’y nakit-an nga mga sayup. Usa ka butang ang sigurado: ang pagpabalik sa mga setting makasulbad sa problema sa mga pagkahagsa sa sudlanan.

Ngano nga dili igo ang paggamit sa Sysctl sa host? Ang sudlanan nagpuyo sa kaugalingon nga gipahinungod nga network Namespace, busa labing menos bahin sa network Sysctl parameters sa sudlanan mahimong lahi gikan sa host.

Unsa man gyud ang mga setting sa Sysctl nga gipadapat sa sulud? Tungod kay walay pribilihiyo ang among mga sudlanan, dili nimo mabag-o ang bisan unsang setting sa Sysctl pinaagi sa pagsulod sa sudlanan mismo - wala kay igong katungod. Sa pagpadagan sa mga sudlanan, ang among panganod niadtong panahona naggamit sa Docker (karon podman). Ang mga parameter sa bag-ong sudlanan gipasa sa Docker pinaagi sa API, lakip ang gikinahanglan nga mga setting sa Sysctl.
Samtang nangita sa mga bersyon, nahimo nga ang Docker API wala ibalik ang tanan nga mga sayup (labing menos sa bersyon 1.10). Sa diha nga kami misulay sa pagsugod sa sudlanan pinaagi sa "docker run", kami sa katapusan nakakita sa usa ka butang:

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

Ang bili sa parameter dili balido. Pero ngano man? Ug nganong dili kini balido usahay? Nahibal-an nga ang Docker dili garantiya sa pagkasunud-sunod kung diin gipadapat ang mga parameter sa Sysctl (ang pinakabag-o nga nasulayan nga bersyon mao ang 1.13.1), mao nga usahay ang ipfrag_high_thresh gisulayan nga itakda sa 256K kung ang ipfrag_low_thresh 3M pa, nga mao, ang taas nga limitasyon mas ubos. kay sa ubos nga limitasyon, nga misangpot sa sayop.

Nianang panahona, gigamit na namo ang among kaugalingong mekanismo sa pag-configure pag-usab sa sudlanan human sa pagsugod (pagyelo sa sudlanan pagkahuman grupo nga freezer ug pagpatuman sa mga sugo sa namespace sa sudlanan pinaagi sa ip netns), ug gidugang usab namo ang pagsulat sa mga parameter sa Sysctl niini nga bahin. Nasulbad ang problema.

FragmentSmack/SegmentSmack. Unang Dugo 2

Sa wala pa kami adunay panahon aron masabtan ang paggamit sa Workaround sa panganod, ang una nga talagsaon nga mga reklamo gikan sa mga tiggamit nagsugod sa pag-abut. Nianang panahona, pipila ka semana ang milabay sukad sa pagsugod sa paggamit sa Workaround sa unang mga server. Gipakita sa inisyal nga imbestigasyon nga ang mga reklamo nadawat batok sa indibidwal nga mga serbisyo, ug dili tanan nga mga server sa kini nga mga serbisyo. Ang problema nahimo na usab nga dili sigurado.

Una sa tanan, kami, siyempre, misulay sa pagpabalik sa mga setting sa Sysctl, apan kini wala'y epekto. Ang lainlaing mga manipulasyon sa mga setting sa server ug aplikasyon wala usab makatabang. Nakatabang ang pag-reboot. Ang pag-reboot sa Linux dili natural sama sa naandan sa Windows sa karaang mga adlaw. Bisan pa, nakatabang kini, ug among gi-chalk kini sa usa ka "kernel glitch" kung gipadapat ang bag-ong mga setting sa Sysctl. Unsa ka walay pulos kini...

Paglabay sa tulo ka semana nibalik ang problema. Ang pag-configure sa kini nga mga server yano ra: Nginx sa proxy / balancer mode. Dili kaayo traffic. Bag-ong nota sa pasiuna: ang gidaghanon sa 504 nga mga sayup sa mga kliyente nagkadaghan matag adlaw (Oras sa Gateway). Gipakita sa graph ang gidaghanon sa 504 nga mga sayup kada adlaw alang niini nga serbisyo:

Ang tanan nga mga sayup hapit sa parehas nga backend - bahin sa usa nga naa sa panganod. Ang graph sa konsumo sa memorya alang sa mga tipik sa pakete niini nga backend ingon niini:

Kini usa sa labing klaro nga pagpakita sa problema sa mga graph sa operating system. Sa panganod, sa samang higayon, laing problema sa network sa mga setting sa QoS (Traffic Control) ang naayo. Sa graph sa konsumo sa panumduman alang sa mga tipik sa pakete, parehas ra kini tan-awon:

Ang pangagpas yano ra: kung parehas sila tan-awon sa mga graph, nan parehas sila nga hinungdan. Dugang pa, ang bisan unsang mga problema sa kini nga matang sa panumduman talagsa ra.

Ang esensya sa naayos nga problema mao nga gigamit namon ang fq packet scheduler nga adunay mga default nga setting sa QoS. Sa kasagaran, alang sa usa ka koneksyon, kini nagtugot kanimo sa pagdugang sa 100 ka mga pakete sa pila, ug ang pipila ka mga koneksyon, sa mga sitwasyon sa kakulang sa channel, nagsugod sa pagbara sa pila ngadto sa kapasidad. Sa kini nga kaso, ang mga pakete gihulog. Sa tc statistics (tc -s qdisc) kini makita nga sama niini:

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0) backlog 0b 0p requeues 0 1024 flows (1021 inactive, 0 throttled) 0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

Ang "464545 flows_plimit" mao ang mga packet nga nahulog tungod sa pagsobra sa queue limit sa usa ka koneksyon, ug ang "drop 464545" mao ang sum sa tanan nga nahulog nga mga packet niini nga scheduler. Human madugangan ang gitas-on sa pila ngadto sa 1 ka libo ug i-restart ang mga sudlanan, mihunong ang problema. Mahimo kang molingkod ug moinom ug smoothie.

FragmentSmack/SegmentSmack. Katapusan nga Dugo

Una, pipila ka bulan pagkahuman sa pagpahibalo sa mga kahuyangan sa kernel, usa ka pag-ayo alang sa FragmentSmack sa katapusan mitungha (pahinumdoman ko ikaw nga kauban ang pahibalo kaniadtong Agosto, usa ka pag-ayo alang lamang sa SegmentSmack ang gipagawas), nga naghatag kanamo usa ka higayon nga biyaan ang Workaround, nga nakahatag kanamo ug daghang kasamok. Niini nga panahon, nakahimo na kami sa pagbalhin sa pipila ka mga server ngadto sa bag-ong kernel, ug karon kinahanglan na kaming magsugod gikan sa sinugdanan. Ngano nga gi-update namon ang kernel nga wala maghulat sa pag-ayo sa FragmentSmack? Ang tinuod mao nga ang proseso sa pagpanalipod batok niini nga mga kahuyangan nagdungan (ug gihiusa) sa proseso sa pag-update sa CentOS mismo (nga nagkinahanglag daghang oras kaysa pag-update lamang sa kernel). Dugang pa, ang SegmentSmack usa ka mas delikado nga pagkahuyang, ug ang usa ka pag-ayo niini nagpakita dayon, busa kini makatarunganon gihapon. Bisan pa, dili lang namo ma-update ang kernel sa CentOS tungod kay ang pagkahuyang sa FragmentSmack, nga nagpakita sa panahon sa CentOS 7.5, naayo ra sa bersyon 7.6, mao nga kinahanglan namon nga ihunong ang pag-update sa 7.5 ug magsugod pag-usab sa pag-update sa 7.6. Ug kini usab mahitabo.

Ikaduha, ang talagsaong mga reklamo sa tiggamit bahin sa mga problema mibalik kanamo. Karon nahibal-an na namon nga sigurado nga silang tanan adunay kalabotan sa pag-upload sa mga file gikan sa mga kliyente ngadto sa pipila sa among mga server. Dugang pa, gamay kaayo nga gidaghanon sa mga pag-upload gikan sa kinatibuk-ang masa ang miagi sa kini nga mga server.

Sama sa atong nahinumduman gikan sa istorya sa ibabaw, ang pagpabalik sa Sysctl wala makatabang. Nakatabang ang pag-reboot, apan temporaryo.
Ang mga pagduda bahin sa Sysctl wala makuha, apan niining higayona gikinahanglan ang pagkolekta sa daghang impormasyon kutob sa mahimo. Adunay usab usa ka dako nga kakulang sa abilidad sa pagkopya sa problema sa pag-upload sa kliyente aron matun-an ang mas tukma kung unsa ang nahitabo.

Ang pag-analisa sa tanan nga magamit nga estadistika ug mga troso wala magdala kanamo nga mas duol sa pagsabut kung unsa ang nahitabo. Adunay usa ka grabe nga kakulang sa abilidad sa pagkopya sa problema aron "mabati" ang usa ka piho nga koneksyon. Sa katapusan, ang mga nag-develop, gamit ang usa ka espesyal nga bersyon sa aplikasyon, nakahimo sa pagkab-ot sa lig-on nga pagpadaghan sa mga problema sa usa ka aparato sa pagsulay kung konektado pinaagi sa Wi-Fi. Kini usa ka breakthrough sa imbestigasyon. Ang kliyente konektado sa Nginx, nga nag-proxy sa backend, nga mao ang among aplikasyon sa Java.

Ang dayalogo alang sa mga problema sama niini (giayo sa Nginx proxy nga bahin):

Kliyente: hangyo nga makadawat og impormasyon bahin sa pag-download sa usa ka file.
Java server: tubag.
Kliyente: POST nga adunay file.
Java server: sayop.

Sa samang higayon, ang Java server nagsulat sa log nga 0 bytes sa data ang nadawat gikan sa kliyente, ug ang Nginx proxy misulat nga ang hangyo mikuha ug labaw sa 30 segundos (30 segundos ang timeout sa aplikasyon sa kliyente). Ngano nga timeout ug nganong 0 bytes? Gikan sa usa ka panglantaw sa HTTP, ang tanan molihok sama sa kinahanglan, apan ang POST nga adunay file daw nawala gikan sa network. Dugang pa, nawala kini sa taliwala sa kliyente ug Nginx. Panahon na aron masangkapan ang imong kaugalingon sa Tcpdump! Apan una kinahanglan nimo nga masabtan ang configuration sa network. Ang Nginx proxy anaa sa luyo sa L3 balancer NFware. Ang tunneling gigamit sa paghatud sa mga packet gikan sa L3 balancer ngadto sa server, nga nagdugang sa mga header niini ngadto sa mga packet:

Sa kini nga kaso, ang network moabut sa kini nga server sa porma sa trapiko nga na-tag sa Vlan, nga nagdugang usab sa kaugalingon nga mga umahan sa mga pakete:

Ug kini nga trapiko mahimo usab nga mabahin (kanang gamay nga porsyento sa umaabot nga nabahin nga trapiko nga among gihisgutan kung gisusi ang mga peligro gikan sa Workaround), nga nagbag-o usab sa sulud sa mga ulohan:

Sa makausa pa: ang mga pakete gi-encapsulated sa usa ka Vlan tag, gi-encapsulated sa usa ka tunnel, fragmented. Aron mas masabtan kung giunsa kini mahitabo, atong isubay ang ruta sa packet gikan sa kliyente ngadto sa Nginx proxy.

Ang pakete nakaabot sa L3 balancer. Alang sa husto nga pag-ruta sulod sa data center, ang pakete gisulod sa usa ka tunel ug gipadala ngadto sa network card.
Tungod kay ang mga packet + tunnel header dili mohaum sa MTU, ang pakete giputol sa mga tipik ug gipadala ngadto sa network.
Ang switch pagkahuman sa L3 balancer, kung makadawat usa ka pakete, nagdugang usa ka Vlan tag niini ug ipadala kini.
Ang switch sa atubangan sa Nginx proxy nakakita (base sa mga setting sa port) nga ang server nagpaabot sa usa ka Vlan-encapsulated packet, mao nga kini nagpadala niini sa unsa nga paagi, nga walay pagtangtang sa Vlan tag.
Gikuha sa Linux ang mga tipik sa indibidwal nga mga pakete ug gihiusa kini sa usa ka dako nga pakete.
Sunod, ang pakete makaabot sa Vlan interface, diin ang unang layer gikuha gikan niini - Vlan encapsulation.
Gipadala kini sa Linux ngadto sa interface sa Tunnel, diin ang laing layer gikuha gikan niini - Tunnel encapsulation.

Ang kalisud mao ang pagpasa sa tanan niini isip mga parameter sa tcpdump.
Magsugod kita gikan sa katapusan: aduna bay limpyo (nga walay wala kinahanglana nga mga ulohan) nga mga IP packet gikan sa mga kliyente, nga gikuha ang vlan ug tunnel encapsulation?

tcpdump host <ip клиента>

Dili, walay ingon nga mga pakete sa server. Busa ang problema kinahanglan nga anaa sa sayo pa. Aduna bay bisan unsang mga pakete nga ang Vlan encapsulation ra ang gikuha?

tcpdump ip[32:4]=0xx390x2xx

Ang 0xx390x2xx mao ang kliyente nga IP address sa hex nga format.
32:4 — adres ug gitas-on sa field diin ang SCR IP gisulat sa Tunnel packet.

Ang field address kinahanglang pilion pinaagi sa brute force, tungod kay sa Internet sila nagsulat mahitungod sa 40, 44, 50, 54, apan walay IP address didto. Mahimo usab nimo tan-awon ang usa sa mga pakete sa hex (ang -xx o -XX parameter sa tcpdump) ug kuwentaha ang IP address nga imong nahibal-an.

Adunay ba mga packet fragment nga wala gikuha ang Vlan ug Tunnel encapsulation?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Kini nga salamangka magpakita kanato sa tanan nga mga tipik, lakip na ang katapusan. Tingali, ang parehas nga butang mahimong ma-filter sa IP, apan wala nako gisulayan, tungod kay dili kaayo daghan ang ingon nga mga pakete, ug ang mga kinahanglan nako dali nga makit-an sa kinatibuk-ang dagan. Ania sila:

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500) 11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 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], length 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 [email protected]. 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 if..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 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 ..............

Kini ang duha ka tipik sa usa ka pakete (sama nga ID 53652) nga adunay litrato (ang pulong nga Exif makita sa unang pakete). Tungod sa kamatuoran nga adunay mga pakete niini nga lebel, apan dili sa gihiusa nga porma sa mga dumps, ang problema klaro sa asembliya. Sa katapusan adunay dokumentaryo nga ebidensya niini!

Ang packet decoder wala magpadayag sa bisan unsang mga problema nga makapugong sa pagtukod. Gisulayan kini dinhi: hpd.gasmi.net. Sa sinugdan, kung mosulay ka nga magbutang usa ka butang didto, ang decoder dili ganahan sa pormat sa pakete. Kini nahimo nga adunay pipila ka dugang nga duha ka octet tali sa Srcmac ug Ethertype (walay kalabotan sa impormasyon sa tipik). Human sa pagtangtang kanila, ang decoder nagsugod sa pagtrabaho. Bisan pa, wala kini nagpakita nga mga problema.
Bisan unsa ang isulti sa usa, wala’y lain nga nakit-an gawas sa mga Sysctl. Ang nahabilin mao ang pagpangita usa ka paagi aron mahibal-an ang mga server sa problema aron masabtan ang sukod ug makadesisyon sa dugang nga mga aksyon. Ang gikinahanglan nga counter nakit-an dayon:

netstat -s | grep "packet reassembles failed”

Anaa usab kini sa snmpd ubos sa OID=1.3.6.1.2.1.4.31.1.1.16.1 (ipSystemStatsReasmFails).

"Ang gidaghanon sa mga kapakyasan nga nakit-an sa IP re-assembly algorithm (sa bisan unsang hinungdan: natapos ang oras, mga sayup, ug uban pa)."

Taliwala sa grupo sa mga server diin ang problema gitun-an, sa duha kini nga counter misaka nga mas paspas, sa duha nga mas hinay, ug sa duha pa wala kini misaka. Ang pagtandi sa dynamics niini nga counter uban sa dynamics sa HTTP errors sa Java server nagpadayag sa usa ka correlation. Sa ato pa, mahimong ma-monitor ang metro.

Ang pagbaton ug kasaligan nga timailhan sa mga problema hinungdanon kaayo aron tukma nimong mahibal-an kung makatabang ba ang pagpabalik sa Sysctl, tungod kay gikan sa miaging istorya nahibal-an namon nga dili kini masabtan dayon gikan sa aplikasyon. Kini nga timailhan magtugot kanamo nga mailhan ang tanan nga mga lugar nga adunay problema sa produksiyon sa wala pa kini madiskobrehan sa mga tiggamit.
Human sa pagpabalik sa Sysctl, ang mga sayop sa pag-monitor mihunong, sa ingon ang hinungdan sa mga problema napamatud-an, ingon man ang kamatuoran nga ang rollback makatabang.

Gibalik namo ang mga setting sa fragmentation sa ubang mga server, diin ang bag-ong pag-monitor nagsugod, ug sa usa ka dapit nga gigahin namo ang mas daghang panumduman alang sa mga tipik kay sa kaniadto nga default (kini ang mga istatistika sa UDP, ang partial nga pagkawala niini dili mamatikdan batok sa kinatibuk-ang background) .

Ang labing importante nga mga pangutana

Ngano nga ang mga pakete gibahin sa among L3 balancer? Kadaghanan sa mga pakete nga moabut gikan sa mga tiggamit ngadto sa mga balanse mao ang SYN ug ACK. Ang mga gidak-on niini nga mga pakete gamay ra. Apan tungod kay ang bahin sa ingon nga mga pakete dako kaayo, batok sa ilang background wala kami makamatikod sa presensya sa dagkong mga pakete nga nagsugod sa pagkabahin.

Ang hinungdan mao ang usa ka guba nga script sa pag-configure advmss sa mga server nga adunay mga interface sa Vlan (diyutay ra kaayo ang mga server nga adunay tag nga trapiko sa produksiyon niadtong panahona). Gitugotan kami sa Advmss nga ipaabot sa kliyente ang impormasyon nga ang mga pakete sa among direksyon kinahanglan nga mas gamay sa gidak-on aron human sa paglakip sa mga ulohan sa tunnel ngadto kanila dili na kinahanglan nga mabahin.

Ngano nga ang Sysctl rollback wala makatabang, apan reboot ang gibuhat? Ang pagpabalik sa Sysctl nagbag-o sa gidaghanon sa memorya nga magamit alang sa paghiusa sa mga pakete. Sa samang higayon, dayag nga ang kamatuoran sa pag-awas sa memorya alang sa mga tipik mitultol sa paghinay sa mga koneksyon, nga misangpot sa mga tipik nga nalangan sa dugay nga panahon sa pila. Sa ato pa, ang proseso nagpadayon sa mga siklo.
Ang pag-reboot nagtangtang sa panumduman ug ang tanan mibalik sa order.

Posible ba nga buhaton nga wala ang Workaround? Oo, apan adunay taas nga peligro nga biyaan ang mga tiggamit nga wala’y serbisyo kung adunay pag-atake. Siyempre, ang paggamit sa Workaround miresulta sa lainlaing mga problema, lakip ang paghinay sa usa sa mga serbisyo alang sa mga tiggamit, apan bisan pa niana kami nagtuo nga ang mga aksyon gipakamatarung.

Daghang salamat kay Andrey Timofeev (atimofeyev) alang sa tabang sa pagpahigayon sa imbestigasyon, ingon man usab si Alexey Krenev (devicex) - alang sa titanic nga buhat sa pag-update sa Centos ug kernels sa mga server. Usa ka proseso nga sa kini nga kaso kinahanglan nga sugdan gikan sa sinugdanan sa daghang mga higayon, mao nga kini giguyod sa daghang mga bulan.

Source: www.habr.com

Pagbantay sa mga kahuyangan nga nagdala sa mga hugna sa trabaho. Bahin 1: FragmentSmack/SegmentSmack