Silav hemû! Navê min Dmitry Samsonov e, ez wekî rêveberê pergalê yê sereke li Odnoklassniki dixebitim. Zêdetirî 7 hezar pêşkêşkerên laşî, 11 hezar konteynir di ewrê me de û 200 serîlêdanên me hene, ku di veavakirinên cihêreng de 700 komên cûda pêk tînin. Pirraniya mezin a servers CentOS 7 dimeşînin.
Di 14ê Tebaxa 2018-an de, agahdarî di derbarê qelsiya FragmentSmack de hate weşandin
() û SegmentSmack (). Vana qelsiyên bi vektorek êrîşa torê û jimareyek pir zêde (7.5) ne, ku ji ber westandina çavkaniyê (CPU) înkarkirina karûbarê (DoS) tehdîd dike. Di wê demê de ji bo FragmentSmack sererastkirinek kernel nehat pêşniyar kirin; ji bilî vê, ew ji weşana agahdariya di derbarê qelsbûnê de pir dereng derket. Ji bo rakirina SegmentSmack, hate pêşniyar kirin ku kernel nûve bike. Pakêta nûvekirinê bixwe di heman rojê de hate berdan, ya ku mabû sazkirina wê bû.
Na, em qet ne li dijî nûvekirina kernelê ne! Lêbelê, nuans hene ...
Em çawa kernelê li ser hilberînê nûve dikin
Bi gelemperî, tiştek tevlihev e:
- Daxistina pakêtan;
- Wan li ser hejmarek serveran saz bikin (tevî serverên ku ewrê me mêvandar dikin);
- Bawer bikin ku tiştek neşikestî ye;
- Bawer bikin ku hemî mîhengên kernelê yên standard bêyî xeletî têne sepandin;
- Çend rojan bisekine;
- Performansa serverê kontrol bikin;
- Veguheztina pêşkêşkerên nû li kernelê nû;
- Hemî pêşkêşkeran ji hêla navenda daneyê ve nûve bikin (yek navendek daneyê her carê da ku di bûyera pirsgirêkan de bandora li ser bikarhêneran kêm bike);
- Hemî pêşkêşkeran ji nû ve bidin destpêkirin.
Ji bo hemî şaxên kernelên ku me hene dubare bikin. Di vê demê de ev e:
- Stock CentOS 7 3.10 - ji bo piraniya serverên birêkûpêk;
- Vanilla 4.19 - ji bo ya me , ji ber ku em hewceyê BFQ, BBR, hwd.
- Elrepo kernel-ml 5.2 - ji bo , ji ber ku 4.19 berê bêhêz tevdigeriya, lê heman taybetmendî hewce ne.
Wekî ku we texmîn kir, ji nû ve destpêkirina bi hezaran serveran wextê herî dirêj digire. Ji ber ku ne hemî qelsî ji bo hemî pêşkêşkeran krîtîk in, em tenê yên ku rasterast ji Înternetê têne gihîştin ji nû ve saz dikin. Di ewr de, ji bo ku nermbûnek sînordar nebe, em konteynerên gihîştî yên derveyî bi kernelek nû ve bi serverên kesane ve girê nadin, lê hemî mêvandar bêyî îstîsna ji nû ve dest pê dikin. Xwezî, prosedur li wir ji serverên birêkûpêk hêsantir e. Mînakî, konteynerên bêdewlet dikarin di dema ji nû ve destpêkirinê de bi hêsanî biçin serverek din.
Lêbelê, hîn jî gelek kar heye, û ew dikare çend hefteyan bigire, û heke di guhertoya nû de pirsgirêk hebin, heya çend mehan. Êrîşkar vê yekê pir baş fêm dikin, ji ber vê yekê ji wan re planek B hewce ye.
FragmentSmack/SegmentSmack. Workaround
Xweşbextane, ji bo hin qelsiyan planek wusa B heye, û jê re Workaround tê gotin. Bi gelemperî, ev guhertinek di mîhengên kernel / serîlêdanê de ye ku dikare bandora gengaz kêm bike an jî bi tevahî karanîna qelsbûnê ji holê rake.
Di doza FragmentSmack/SegmentSmack de ev Rêbaz:
«Hûn dikarin nirxên xwerû yên 4MB û 3MB di net.ipv4.ipfrag_high_thresh û net.ipv4.ipfrag_low_thresh (û hevpîşeyên wan ji bo ipv6 net.ipv6.ipfrag_high_thresh û net.ipv6.ipfrag_low_thresh) û bi rêzdarî bi 256 kB192 an kB262144 kêmkirin. Testên di dema êrîşê de li gorî hardware, mîheng û şertan ve girêdayî kêm û girîng di karanîna CPU de nîşan didin. Lêbelê, dibe ku ji ber ipfrag_high_thresh=64 bytes hin bandorek performansê hebe, ji ber ku tenê du perçeyên XNUMXK dikarin di yek carê de bikevin rêza ji nû ve berhevkirinê. Mînakî, metirsî heye ku sepanên ku bi pakêtên UDP yên mezin re dixebitin bişkînin".
Parametreyên xwe wiha tê vegotin:
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.
Li ser karûbarên hilberînê UDP-yên me yên mezin tune. Li ser LAN-ê seyrûsefera perçebûyî tune; li ser WAN-ê seyrûsefera perçebûyî heye, lê ne girîng e. Nîşan tune - hûn dikarin Workaround derxînin!
FragmentSmack/SegmentSmack. Xwîna yekem
Pirsgirêka yekem a ku me pê re rû bi rû ma ev bû ku konteynerên ewr carinan mîhengên nû tenê bi qismî sepandin (tenê ipfrag_low_thresh), û carinan jî wan qet bicîh neanîn - ew di destpêkê de bi hêsanî têk çûn. Ne gengaz bû ku pirsgirêk bi îstîqrar ji nû ve were hilberandin (hemî mîheng bi destan bêyî dijwarî hatine sepandin). Fêmkirina çima konteynir di destpêkê de diqelişe jî ne ew çend hêsan e: tu xelet nehatin dîtin. Tiştek teqez bû: vegerandina mîhengan pirsgirêka têkçûna konteynerê çareser dike.
Çima ne bes e ku meriv Sysctl li ser mêvandarê bicîh bike? Konteynir di nav navên tora xweya taybetî de dijî, lewra bi kêmanî di konteynerê de dibe ku ji mêvandar cûda bibe.
Mîhengên Sysctl bi rastî di konteynerê de çawa têne sepandin? Ji ber ku konteynerên me bê îmtiyaz in, hûn ê nikaribin bi ketina nav konteynerê bixwe mîhengên Sysctl-ê biguhezînin - hûn tenê têra mafên we nakin. Ji bo meşandina konteyneran, ewrê me wê demê Docker bikar anî (niha ). Parametreyên konteynera nû bi navgîniya API-yê, tevî mîhengên Sysctl yên pêwîst, ji Docker re hatin şandin.
Dema ku li guhertoyan geriya, derket holê ku Docker API hemî xeletiyan venegerîne (qet nebe di guhertoya 1.10 de). Dema ku me hewl da ku konteynerê bi "docker run" dest pê bikin, me di dawiyê de bi kêmanî tiştek dît:
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.
Nirxa parametreyê ne derbasdar e. Lê çima? Û çima ew tenê carinan ne derbasdar e? Derket holê ku Docker rêza ku parametreyên Sysctl têne sepandin garantî nake (guhertoya herî dawî ya ceribandin 1.13.1 e), ji ber vê yekê carinan ipfrag_high_thresh hewl da ku li 256K were danîn dema ku ipfrag_low_thresh hîn jî 3M bû, yanî sînorê jorîn kêmtir bû. ji sînorê jêrîn, ku bû sedema xeletiyê.
Di wê demê de, me jixwe mekanîzmaya xwe bikar anî ji bo ji nû ve veavakirina konteynerê piştî destpêkirinê (cemidkirina konteynerê piştî û pêkanîna fermanan di nav qada navan de bi rêya ), û me pîvanên nivîsandina Sysctl jî li vê beşê zêde kir. Pirsgirêk çareser bû.
FragmentSmack/SegmentSmack. Xwîna yekem 2
Berî ku me wexta fêmkirina karanîna Workaround di ewr de hebe, yekem giliyên kêm kêm ji bikarhêneran dest pê kirin. Wê demê, çend hefte ji destpêka karanîna Workaround li ser serverên yekem re derbas bûn. Lêkolîna destpêkê destnîşan kir ku gilî li ser karûbarên kesane hatine wergirtin, û ne hemî serverên van karûbaran. Pirsgirêk dîsa bûye pir nediyar.
Berî her tiştî, me, bê guman, hewl da ku mîhengên Sysctl paşde vegerînin, lê ev yek bandorek nekir. Manîpulasyonên cihêreng ên bi mîhengên server û serîlêdanê re jî nebûn alîkar. Reboot alîkarî kir. Rebootkirina Linux-ê bi qasî ku di rojên berê de ji bo Windows-ê normal bû nesirûştî ye. Lêbelê, ew arîkar bû, û dema ku mîhengên nû di Sysctl de sepandin, me ew bi "xera kernelê" vekir. Çiqas bêaqil bû...
Piştî sê hefteyan pirsgirêk dubare bû. Veavakirina van serveran pir hêsan bû: Nginx di moda proxy/balansek de. Ne zêde trafîkê. Nîşeya nû ya destpêkê: hejmara 504 xeletiyên li ser xerîdar her roj zêde dibe (). Grafîk ji bo vê karûbarê rojane 504 xeletiyan nîşan dide:
Hemî xeletî li ser heman paşengê ne - li ser ya ku di ewr de ye. Grafika mezaxtina bîranînê ji bo perçeyên pakêtê yên li ser vê paşîn bi vî rengî xuya bû:
Ev yek ji diyardeyên herî eşkere yên pirsgirêkê di grafikên pergala xebitandinê de ye. Di ewr de, di heman demê de, pirsgirêkek din a torê ya bi mîhengên QoS (Kontrola Trafîkê) hate rast kirin. Li ser grafiya xerckirina bîranînê ji bo perçeyên pakêtê, ew tam heman xuya bû:
Texmîn hêsan bû: heke ew li ser grafikan heman xuya bikin, wê hingê heman sedem hene. Digel vê yekê, pirsgirêkên bi vî rengî bîranînê pir kêm in.
Esasê pirsgirêka rast ev bû ku me nexşerêya pakêtê ya fq bi mîhengên xwerû di QoS de bikar anî. Bi xwerû, ji bo yek pêwendiyê, ew dihêle hûn 100 pakêtan li dorê zêde bikin, û hin girêdan, di rewşên kêmbûna kanalê de, dest pê kirin ku dorê li ser kapasîteyê bigire. Di vê rewşê de, pakêt têne avêtin. Di statîstîkên tc de (tc -s qdisc) ew dikare bi vî rengî were dîtin:
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
"464545 flows_plimit" pakêtên ku ji ber derbaskirina sînorê dorê ya yek pêwendiyê hatine avêtin e, û "464545 daketiye" berhevoka hemî pakêtên daketî yên vê plansazkerê ye. Piştî ku dirêjahiya dorê bû 1 hezar û konteyniran ji nû ve dest pê kir, pirsgirêk rawestiya. Hûn dikarin li pişt xwe rûnin û şilavek vexwin.
FragmentSmack/SegmentSmack. Xwîna Dawî
Pêşîn, çend meh piştî ragihandina qelsiyên di kernelê de, di dawiyê de rastkirinek ji bo FragmentSmack xuya bû (bihêle ez bi bîr bînim ku ligel ragihandina meha Tebaxê, rastkirinek tenê ji bo SegmentSmack hate berdan), ku şansek da me ku em dev ji Workaround berdin. ku ji me re gelek tengasiyan derxist. Di vê demê de, me berê xwe dabû ku hin pêşkêşkeran veguhezînin kernelê nû, û naha diviyabû ku em ji destpêkê ve dest pê bikin. Çima me kernel nûve kir bêyî ku li benda rastkirina FragmentSmack bin? Rastî ev e ku pêvajoya parastina li hember van qelsiyan bi pêvajoya nûvekirina CentOS-ê bixwe re hevaheng bû (û yekbûyî) (ku ji nûvekirina tenê kernelê bêtir wext digire). Wekî din, SegmentSmack qelsiyek xeternaktir e, û sererastkirinek ji bo wê tavilê xuya bû, ji ber vê yekê ew jî watedar bû. Lêbelê, me nekarî bi hêsanî kernelê li ser CentOS nûve bikin ji ber ku qelsiya FragmentSmack, ku di dema CentOS 7.5 de xuya bû, tenê di guhertoya 7.6 de hate rast kirin, ji ber vê yekê me neçar ma ku nûvekirina 7.5-ê rawestand û ji nûve bi nûvekirina 7.6-ê re dest pê bike. Û ev jî dibe.
Ya duyemîn, giliyên kêm kêm bikarhêneran di derbarê pirsgirêkan de li me vegeriyan. Naha em jixwe bi guman dizanin ku ew hemî bi barkirina pelan ji xerîdar li hin serverên me ve girêdayî ne. Digel vê yekê, hejmareke pir hindik barkirinên ji girseya giştî bi van serveran re derbas bûn.
Wekî ku em ji çîroka li jor bi bîr tînin, paşdexistina Sysctl ne alîkar bû. Reboot alîkarî kir, lê bi demkî.
Gumanên di derbarê Sysctl de nehatin rakirin, lê vê carê hewce bû ku bi qasî ku pêkan agahdarî were berhev kirin. Di heman demê de kêmasiyek mezin hebû ku pirsgirêka barkirinê li ser xerîdar ji nû ve hilberîne da ku bi hûrgulî tiştê ku diqewime lêkolîn bike.
Analîzkirina hemî statîstîk û têketinên berdest me nêziktir nekir ku em fam bikin ka çi diqewime. Kêmasiyek tûj a şiyana ji nû ve hilberandina pirsgirêkê ji bo "hestkirina" pêwendiyek taybetî hebû. Di dawiyê de, pêşdebiran, bi karanîna guhertoyek taybetî ya serîlêdanê, karîbûn ku gava ku bi Wi-Fi ve girêdayî ye, hilberandina aram a pirsgirêkan li ser amûrek ceribandinê bi dest bixin. Ev di lêpirsînê de serkeftinek bû. Xerîdar bi Nginx-ê ve girêdayî ye, ku bi paşverû, ku serîlêdana meya Java-yê bû proxy kir.
Diyaloga ji bo pirsgirêkan bi vî rengî bû (li aliyê proxy Nginx hate rast kirin):
- Xerîdar: Daxwaza wergirtina agahdariya li ser dakêşana pelê.
- server Java: bersiv.
- Xerîdar: POST bi pelê.
- Server Java: xeletî.
Di heman demê de, servera Java-yê ji têketinê re dinivîse ku 0 byte daneyan ji xerîdar hatine wergirtin, û proxy Nginx dinivîse ku daxwaz ji 30 çirkeyan zêdetir girt (30 çirke dema derbasbûna serîlêdana xerîdar e). Çima dem û çima 0 byte? Ji perspektîfek HTTP, her tişt wekî ku divê dixebite, lê POST bi pelê re xuya dike ku ji torê winda dibe. Wekî din, ew di navbera xerîdar û Nginx de winda dibe. Wext e ku hûn xwe bi Tcpdump çekdar bikin! Lê pêşî hûn hewce ne ku veavakirina torê fam bikin. Nginx proxy li pişt balansa L3 ye . Tunnelkirin ji bo radestkirina pakêtan ji balansa L3 ber bi serverê ve tê bikar anîn, ku sernavên xwe li pakêtan zêde dike:
Di vê rewşê de, torê di forma seyrûsefera bi Vlan-tagkirî de tê ser vê serverê, ku di heman demê de zeviyên xwe jî li pakêtan zêde dike:
Û ev seyrûsefer di heman demê de dikare perçe bibe (ew heman rêjeya piçûk a seyrûsefera perçebûyî ya hatî ya ku me dema ku metirsiyên ji Workaround dinirxînin behs kir), ev jî naveroka sernivîsan diguhezîne:
Careke din: pakêt bi tagek Vlan ve têne qewirandin, bi tunelekê ve têne qewirandin, perçe dibin. Ji bo ku em çêtir fam bikin ka ev çawa diqewime, bila em riya pakêtê ji xerîdar berbi proxy Nginx bişopînin.
- Paket digihîje balansa L3. Ji bo rêveçûna rast di nav navenda daneyê de, pakêt di tunelekê de tê girtin û ji qerta torê re tê şandin.
- Ji ber ku sernavên pakêt + tunelê di MTU-yê de cih nagirin, pakêt perçe perçe dibe û dişîne torê.
- Veguheztina piştî balansa L3, dema ku pakêtek distîne, etîketek Vlan lê zêde dike û dişîne.
- Guhestina li ber proxy Nginx dibîne (li ser bingeha mîhengên portê) ku server li benda pakêtek vegirtî ya Vlan e, ji ber vê yekê ew wekî ku ye, bêyî rakirina nîşana Vlan-ê dişîne.
- Linux perçeyên pakêtên kesane digire û wan di pakêtek mezin de dike yek.
- Dûv re, pakêt digihîje navbeynkariya Vlan, ku li wir qata yekem jê tê rakirin - Vlan encapsulation.
- Dûv re Linux wê dişîne navrûya Tunnelê, li wir qatek din jê tê rakirin - Tunnel encapsulation.
Zehmetî ev e ku meriv van hemîyan wekî parameteran ji tcpdump re derbas bike.
Ka em ji dawiyê dest pê bikin: gelo pakêtên IP-ya paqij (bê sernavên nehewce) ji xerîdar hene, bi vegirtina vlan û tunelê hatine rakirin?
tcpdump host <ip клиента>
Na, li ser serverê pakêtên weha tune bûn. Ji ber vê yekê divê pirsgirêk berê hebe. Ma pakêtên ku tenê encapsulasyona Vlan jêbirin hene?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx navnîşana IP-ya muwekîlê di forma hex de ye.
32:4 - Navnîşan û dirêjahiya qada ku tê de IP-ya SCR di pakêta Tunnelê de hatî nivîsandin.
Navnîşana zeviyê neçar bû ku bi hêza hovane were hilbijartin, ji ber ku li ser Înternetê ew li ser 40, 44, 50, 54 dinivîsin, lê navnîşana IP-ê li wir tune bû. Her weha hûn dikarin li yek ji pakêtên di hex (parametreya -xx an -XX li tcpdump) binêrin û navnîşana IP-ya ku hûn dizanin hesab bikin.
Ma perçeyên pakêtê yên bêyî dorpêçkirina Vlan û Tunelê hatine rakirin hene?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Ev sêrbaz dê hemî perçeyan, tevî ya paşîn, nîşanî me bide. Belkî, heman tişt dikare ji hêla IP-ê ve were fîlter kirin, lê min ceriband, ji ber ku pir pakêtên weha tune ne, û yên ku ji min re hewce bûn bi hêsanî di herikîna gelemperî de hatin dîtin. Li vir ew in:
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 ..............
Ev du perçeyên yek pakêtê ne (eynî ID 53652) bi wêneyek (peyva Exif di pakêta yekem de xuya ye). Ji ber ku di vê astê de pakêt hene, lê ne bi şiklê hevgirtî di nav çolan de, pirsgirêk eşkere bi meclîsê re ye. Di dawiyê de belgeyên vê yekê hene!
Dekodera pakêtê ti pirsgirêkek ku pêşî li çêkirinê bigire eşkere nekir. Li vir ceribandin: . Di destpêkê de, gava ku hûn hewl didin ku tiştek li wir bixin, dekoder ji formata pakêtê hez nake. Derket holê ku di navbera Srcmac û Ethertype de du oktetên zêde hene (bi agahdariya perçeyê ve girêdayî ne). Piştî rakirina wan, dekoder dest bi xebatê kir. Lêbelê, wê ti pirsgirêk nîşan neda.
Mirov çi bibêje jî, ji bilî wan Sysctl tiştek din nehat dîtin. Tiştê ku mabû ev bû ku meriv rêyek bibîne ku serverên pirsgirêkê nas bike da ku pîvanê fam bike û li ser kiryarên din biryar bide. Hejmara pêwîst bi têra xwe zû hate dîtin:
netstat -s | grep "packet reassembles failed”
Ew di bin OID=1.3.6.1.2.1.4.31.1.1.16.1 de jî di snmpd de ye ().
"Hejmara têkçûnên ku ji hêla algorîtmaya ji nû ve komkirina IP-yê ve hatine tespît kirin (ji ber çi sedemê be: dem derbas bûye, xeletî, hwd.)
Di nav koma serverên ku pirsgirêk li ser hatine lêkolîn kirin de, li ser duyan ev hejmar zûtir, li duyan hêdîtir, û li ser du serverên din jî qet zêde nebû. Berawirdkirina dînamîkên vê hejmarê bi dînamîkên xeletiyên HTTP-ê yên li ser servera Java-yê re têkiliyek eşkere kir. Ango metre dikare were şopandin.
Hebûna nîşanek pêbawer a pirsgirêkan pir girîng e ji ber vê yekê hûn dikarin bi rast diyar bikin ka paşdexistina Sysctl dibe alîkar, ji ber ku ji çîroka berê em dizanin ku ev tavilê ji serîlêdanê nayê fêm kirin. Ev nîşanker dê rê bide me ku em hemî deverên pirsgirêkê di hilberînê de nas bikin berî ku bikarhêner wê kifş bikin.
Piştî vegerandina Sysctl, xeletiyên çavdêriyê sekinîn, bi vî rengî sedema pirsgirêkan hate îsbat kirin, û her weha rastiya ku vegerê jî dibe alîkar.
Me mîhengên perçebûnê li ser serverên din, ku li wir çavdêriya nû ket leyiztinê, paşde vekir, û li cîhek me ji ya berê hê bêtir bîranîn ji bo perçeyan veqetand (ev statîstîkên UDP bû, windabûna qismî ya ku li hember paşxaneya gelemperî ne diyar bû) .
Pirsên herî girîng
Çima pakêt li ser balansa meya L3 perçe dibin? Piraniya pakêtên ku ji bikarhêneran digihîjin balansan SYN û ACK in. Mezinahiya van pakêtan piçûk in. Lê ji ber ku para pakêtên bi vî rengî pir mezin e, li hember paşperdeya wan me ferq nekir ku pakêtên mezin dest bi perçebûnê kirin.
Sedem skrîptek veavakirina şikestî bû li ser serverên bi navgînên Vlan (wê demê di hilberînê de pir hindik serverên bi seyrûsefera nîşankirî hebûn). Advmss destûrê dide me ku em agahdarî ji xerîdar re ragihînin ku pakêtên di rêça me de divê bi mezinahî piçûktir bin, da ku piştî ku sernavên tunelê bi wan ve girêdin, ew neçarin perçe bibin.
Çima vegerandina Sysctl ne alîkar bû, lê ji nû ve dest pê kir? Vegerandina Sysctl mîqdara bîra berdest a ji bo yekkirina pakêtan guhert. Di heman demê de, xuya ye ku rastiya zêdebûna bîranînê ji bo perçeyan bû sedema hêdîbûna girêdanan, ku bû sedema ku perçe ji bo demek dirêj di rêzê de dereng bimînin. Ango pêvajo di çerçoveyê de çû.
Reboot bîranîn paqij kir û her tişt vegeriya rêzê.
Ma gengaz bû ku bêyî Workaround were kirin? Erê, lê rîskek mezin heye ku di bûyera êrîşê de bikarhêneran bê karûbar bihêlin. Bê guman, karanîna Workaround bû sedema pirsgirêkên cihêreng, di nav de hêdîbûna yek ji karûbaran ji bo bikarhêneran, lê dîsa jî em bawer dikin ku kiryar rastdar bûn.
Gelek spas ji Andrey Timofeev () ji bo arîkariya di pêkanîna lêpirsînê de, û her weha Alexey Krenev () - ji bo xebata tîtanîkî ya nûvekirina Centos û kernelên li ser serveran. Pêvajoyek ku di vê rewşê de çend caran ji destpêkê ve dest pê kir, ji ber vê yekê jî bi mehan dirêj kir.
Source: www.habr.com