Helo pawb! Fy enw i yw Dmitry Samsonov, rwy'n gweithio fel gweinyddwr system blaenllaw yn Odnoklassniki. Mae gennym fwy na 7 mil o weinyddion ffisegol, 11 mil o gynwysyddion yn ein cwmwl a 200 o gymwysiadau, sydd mewn gwahanol ffurfweddiadau yn ffurfio 700 o glystyrau gwahanol. Mae mwyafrif helaeth y gweinyddwyr yn rhedeg CentOS 7.
Ar Awst 14, 2018, cyhoeddwyd gwybodaeth am fregusrwydd FragmentSmack
() a SegmentSmack (). Mae'r rhain yn wendidau gyda fector ymosodiad rhwydwaith a sgôr eithaf uchel (7.5), sy'n bygwth gwrthod gwasanaeth (DoS) oherwydd lludded adnoddau (CPU). Ni chynigiwyd atgyweiriad cnewyllyn ar gyfer FragmentSmack bryd hynny; ar ben hynny, daeth allan yn llawer hwyrach na chyhoeddi gwybodaeth am y bregusrwydd. Er mwyn dileu SegmentSmack, awgrymwyd diweddaru'r cnewyllyn. Rhyddhawyd y pecyn diweddaru ei hun ar yr un diwrnod, y cyfan oedd ar ôl oedd ei osod.
Na, nid ydym yn erbyn diweddaru'r cnewyllyn o gwbl! Fodd bynnag, mae yna arlliwiau ...
Sut rydym yn diweddaru'r cnewyllyn ar gynhyrchu
Yn gyffredinol, dim byd cymhleth:
- Lawrlwytho pecynnau;
- Gosodwch nhw ar nifer o weinyddion (gan gynnwys gweinyddwyr sy'n cynnal ein cwmwl);
- Gwnewch yn siŵr nad oes dim wedi torri;
- Sicrhewch fod pob gosodiad cnewyllyn safonol yn cael ei gymhwyso heb wallau;
- Aros ychydig ddyddiau;
- Gwirio perfformiad gweinydd;
- Newid y defnydd o weinyddion newydd i'r cnewyllyn newydd;
- Diweddaru pob gweinydd yn ôl canolfan ddata (un ganolfan ddata ar y tro i leihau'r effaith ar ddefnyddwyr rhag ofn y bydd problemau);
- Ailgychwyn pob gweinydd.
Ailadroddwch ar gyfer pob cangen o'r cnewyllyn sydd gennym. Ar hyn o bryd mae'n:
- Stoc CentOS 7 3.10 - ar gyfer y rhan fwyaf o weinyddion rheolaidd;
- Fanila 4.19 - ar gyfer ein un ni , oherwydd mae angen BFQ, BBR, ac ati;
- Elrepo cnewyllyn-ml 5.2 - ar gyfer , oherwydd roedd 4.19 yn arfer ymddwyn yn ansefydlog, ond mae angen yr un nodweddion.
Fel y gallech fod wedi dyfalu, mae ailgychwyn miloedd o weinyddion yn cymryd yr amser hiraf. Gan nad yw pob bregusrwydd yn hanfodol i bob gweinydd, dim ond y rhai sy'n hygyrch yn uniongyrchol o'r Rhyngrwyd y byddwn yn ailgychwyn. Yn y cwmwl, er mwyn peidio â chyfyngu ar hyblygrwydd, nid ydym yn clymu cynwysyddion sy'n hygyrch yn allanol i weinyddion unigol gyda chnewyllyn newydd, ond yn ailgychwyn pob gwesteiwr yn ddieithriad. Yn ffodus, mae'r weithdrefn yno yn symlach na gyda gweinyddwyr rheolaidd. Er enghraifft, gall cynwysyddion heb wladwriaeth symud i weinydd arall yn ystod ailgychwyn.
Fodd bynnag, mae llawer o waith o hyd, a gall gymryd sawl wythnos, ac os oes unrhyw broblemau gyda'r fersiwn newydd, hyd at sawl mis. Mae ymosodwyr yn deall hyn yn dda iawn, felly mae angen cynllun B arnynt.
FragmentSmack/SegmentSmack. Gweithiwch o gwmpas
Yn ffodus, ar gyfer rhai gwendidau, mae cynllun B o'r fath yn bodoli, a'i enw yw Workaround. Yn fwyaf aml, mae hwn yn newid mewn gosodiadau cnewyllyn/cymhwysiad a all leihau'r effaith bosibl neu ddileu'r camfanteisio ar wendidau yn llwyr.
Yn achos FragmentSmack/SegmentSmack y Datrysiad hwn:
«Gallwch newid y gwerthoedd rhagosodedig o 4MB a 3MB yn net.ipv4.ipfrag_high_thresh a net.ipv4.ipfrag_low_thresh (a'u cymheiriaid ar gyfer ipv6 net.ipv6.ipfrag_high_thresh a net.ipv6.ipfrag_low_thresh) i 256 kB a yn y drefn honno is. Mae profion yn dangos gostyngiadau bach i sylweddol yn y defnydd o CPU yn ystod ymosodiad yn dibynnu ar galedwedd, gosodiadau ac amodau. Fodd bynnag, efallai y bydd rhywfaint o effaith perfformiad oherwydd ipfrag_high_thresh=192 beit, gan mai dim ond dau ddarn 262144K all ffitio i mewn i'r ciw ail-osod ar y tro. Er enghraifft, mae risg y bydd ceisiadau sy'n gweithio gyda phecynnau CDU mawr yn torri'.
Y paramedrau eu hunain a ddisgrifir fel a ganlyn:
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.
Nid oes gennym CDUau mawr ar wasanaethau cynhyrchu. Nid oes traffig tameidiog ar y LAN; mae traffig darniog ar y WAN, ond nid yw’n arwyddocaol. Nid oes unrhyw arwyddion - gallwch gyflwyno Workaround!
FragmentSmack/SegmentSmack. Gwaed cyntaf
Y broblem gyntaf y daethom ar ei thraws oedd bod cynwysyddion cwmwl weithiau'n cymhwyso'r gosodiadau newydd yn rhannol yn unig (dim ond ipfrag_low_thresh), ac weithiau nid oeddent yn eu cymhwyso o gwbl - fe wnaethant chwalu ar y dechrau. Nid oedd yn bosibl atgynhyrchu'r broblem yn sefydlog (cymhwyswyd pob gosodiad â llaw heb unrhyw anawsterau). Nid yw deall pam mae'r cynhwysydd yn damwain ar y cychwyn hefyd mor hawdd: ni chanfuwyd unrhyw wallau. Roedd un peth yn sicr: mae rholio'r gosodiadau yn ôl yn datrys y broblem gyda damweiniau cynhwysydd.
Pam nad yw'n ddigon cymhwyso Sysctl ar y gwesteiwr? Mae'r cynhwysydd yn byw yn ei rwydwaith pwrpasol ei hun Namespace, felly o leiaf yn y cynhwysydd gall fod yn wahanol i'r gwesteiwr.
Sut yn union mae gosodiadau Sysctl yn cael eu cymhwyso yn y cynhwysydd? Gan fod ein cynwysyddion yn ddi-freintiedig, ni fyddwch yn gallu newid unrhyw osodiad Sysctl trwy fynd i mewn i'r cynhwysydd ei hun - yn syml, nid oes gennych ddigon o hawliau. I redeg cynwysyddion, roedd ein cwmwl bryd hynny yn defnyddio Docker (nawr ). Trosglwyddwyd paramedrau'r cynhwysydd newydd i Docker trwy'r API, gan gynnwys y gosodiadau Sysctl angenrheidiol.
Wrth chwilio trwy'r fersiynau, daeth i'r amlwg na ddychwelodd API Docker yr holl wallau (yn fersiwn 1.10 o leiaf). Pan wnaethom geisio cychwyn y cynhwysydd trwy “docker run”, gwelsom o leiaf rywbeth o'r diwedd:
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.
Nid yw gwerth y paramedr yn ddilys. Ond pam? A pham nad yw'n ddilys dim ond weithiau? Daeth i'r amlwg nad yw Docker yn gwarantu'r drefn y mae paramedrau Sysctl yn cael eu cymhwyso (y fersiwn brofedig ddiweddaraf yw 1.13.1), felly weithiau ceisiodd ipfrag_high_thresh gael ei osod i 256K pan oedd ipfrag_low_thresh yn dal i fod yn 3M, hynny yw, roedd y terfyn uchaf yn is na'r terfyn isaf, a arweiniodd at y gwall.
Bryd hynny, rydym eisoes wedi defnyddio ein mecanwaith ein hunain ar gyfer ad-drefnu'r cynhwysydd ar ôl cychwyn (rhewi'r cynhwysydd ar ôl hynny a gweithredu gorchmynion yn gofod enw'r cynhwysydd trwy ), ac fe wnaethom hefyd ychwanegu paramedrau ysgrifennu Sysctl at y rhan hon. Cafodd y broblem ei datrys.
FragmentSmack/SegmentSmack. Gwaed Cyntaf 2
Cyn i ni gael amser i ddeall y defnydd o Workaround yn y cwmwl, dechreuodd y cwynion prin cyntaf gan ddefnyddwyr gyrraedd. Bryd hynny, roedd sawl wythnos wedi mynd heibio ers dechrau defnyddio Workaround ar y gweinyddwyr cyntaf. Dangosodd yr ymchwiliad cychwynnol y derbyniwyd cwynion yn erbyn gwasanaethau unigol, ac nid holl weinyddion y gwasanaethau hyn. Mae'r broblem wedi dod yn hynod ansicr eto.
Yn gyntaf oll, fe wnaethom ni, wrth gwrs, geisio treiglo'r gosodiadau Sysctl yn ôl, ond ni chafodd hyn unrhyw effaith. Nid oedd triniaethau amrywiol gyda gosodiadau'r gweinydd a'r rhaglen yn helpu chwaith. Helpodd ailgychwyn. Mae ailgychwyn Linux mor annaturiol ag yr oedd yn arferol i Windows yn yr hen ddyddiau. Fodd bynnag, fe helpodd, a gwnaethom ei siapio hyd at “glitch cnewyllyn” wrth gymhwyso'r gosodiadau newydd yn Sysctl. Pa mor wamal ydoedd...
Dair wythnos yn ddiweddarach fe ddaeth y broblem eto. Roedd cyfluniad y gweinyddwyr hyn yn eithaf syml: Nginx yn y modd dirprwy / cydbwysedd. Dim llawer o draffig. Nodyn rhagarweiniol newydd: mae nifer y 504 o wallau ar gleientiaid yn cynyddu bob dydd (). Mae'r graff yn dangos nifer y gwallau 504 y dydd ar gyfer y gwasanaeth hwn:
Mae'r gwallau i gyd tua'r un backend - tua'r un sydd yn y cwmwl. Roedd y graff defnydd cof ar gyfer darnau pecyn ar y pen ôl hwn yn edrych fel hyn:
Dyma un o'r amlygiadau mwyaf amlwg o'r broblem mewn graffiau system weithredu. Yn y cwmwl, dim ond ar yr un pryd, gosodwyd problem rhwydwaith arall gyda gosodiadau QoS (Rheoli Traffig). Ar y graff o ddefnydd cof ar gyfer darnau pecyn, roedd yn edrych yn union yr un fath:
Roedd y rhagdybiaeth yn syml: os ydyn nhw'n edrych yr un peth ar y graffiau, yna mae ganddyn nhw'r un rheswm. Ar ben hynny, mae unrhyw broblemau gyda'r math hwn o gof yn hynod o brin.
Hanfod y broblem sefydlog oedd ein bod wedi defnyddio'r trefnydd pecyn fq gyda gosodiadau diofyn yn QoS. Yn ddiofyn, ar gyfer un cysylltiad, mae'n caniatáu ichi ychwanegu 100 o becynnau i'r ciw, a dechreuodd rhai cysylltiadau, mewn sefyllfaoedd o brinder sianel, glocsio'r ciw i gapasiti. Yn yr achos hwn, caiff pecynnau eu gollwng. Mewn ystadegau tc (tc -s qdisc) gellir ei weld fel hyn:
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” yw’r pecynnau a ollyngwyd oherwydd eu bod yn mynd dros derfyn y ciw o un cysylltiad, a “gostyngwyd 464545” yw cyfanswm yr holl becynnau a ollyngwyd yn y rhaglennydd hwn. Ar ôl cynyddu hyd y ciw i 1 mil ac ailgychwyn y cynwysyddion, stopiodd y broblem ddigwydd. Gallwch eistedd yn ôl ac yfed smwddi.
FragmentSmack/SegmentSmack. Gwaed Diweddaf
Yn gyntaf, sawl mis ar ôl cyhoeddi gwendidau yn y cnewyllyn, ymddangosodd atgyweiriad ar gyfer FragmentSmack o'r diwedd (gadewch imi eich atgoffa, ynghyd â'r cyhoeddiad ym mis Awst, bod atgyweiriad yn unig ar gyfer SegmentSmack wedi'i ryddhau), a roddodd gyfle i ni roi'r gorau i Workaround, a achosodd dipyn o drafferth inni. Yn ystod yr amser hwn, roeddem eisoes wedi llwyddo i drosglwyddo rhai o'r gweinyddwyr i'r cnewyllyn newydd, ac yn awr roedd yn rhaid i ni ddechrau o'r dechrau. Pam wnaethom ni ddiweddaru'r cnewyllyn heb aros am yr atgyweiriad FragmentSmack? Y ffaith yw bod y broses o amddiffyn rhag y gwendidau hyn yn cyd-daro (ac yn uno) â'r broses o ddiweddaru CentOS ei hun (sy'n cymryd hyd yn oed mwy o amser na diweddaru'r cnewyllyn yn unig). Yn ogystal, mae SegmentSmack yn agored i niwed mwy peryglus, ac ymddangosodd atgyweiriad ar ei gyfer ar unwaith, felly roedd yn gwneud synnwyr beth bynnag. Fodd bynnag, ni allem ddiweddaru'r cnewyllyn ar CentOS yn syml oherwydd bod y bregusrwydd FragmentSmack, a ymddangosodd yn ystod CentOS 7.5, yn sefydlog yn fersiwn 7.6 yn unig, felly bu'n rhaid i ni atal y diweddariad i 7.5 a dechrau eto gyda'r diweddariad i 7.6. Ac mae hyn hefyd yn digwydd.
Yn ail, mae cwynion defnyddwyr prin am broblemau wedi dychwelyd atom. Nawr rydym eisoes yn gwybod yn sicr eu bod i gyd yn gysylltiedig â llwytho ffeiliau gan gleientiaid i rai o'n gweinyddwyr. At hynny, aeth nifer fach iawn o uwchlwythiadau o gyfanswm y màs trwy'r gweinyddwyr hyn.
Fel y cofiwn oddiwrth yr hanes uchod, nid oedd treiglo yn ol Sysctl yn help. Helpodd ailgychwyn, ond dros dro.
Ni ddilëwyd amheuon ynghylch Sysctl, ond y tro hwn bu'n rhaid casglu cymaint o wybodaeth â phosibl. Roedd diffyg gallu enfawr hefyd i atgynhyrchu'r broblem uwchlwytho ar y cleient er mwyn astudio'n fwy manwl gywir beth oedd yn digwydd.
Ni ddaeth dadansoddiad o'r holl ystadegau a logiau a oedd ar gael â ni yn nes at ddeall beth oedd yn digwydd. Roedd diffyg gallu dybryd i atgynhyrchu’r broblem er mwyn “teimlo” cysylltiad penodol. Yn olaf, llwyddodd y datblygwyr, gan ddefnyddio fersiwn arbennig o'r cais, i gyflawni atgynhyrchu sefydlog o broblemau ar ddyfais brawf wrth gysylltu trwy Wi-Fi. Roedd hyn yn ddatblygiad arloesol yn yr ymchwiliad. Cysylltodd y cleient â Nginx, a oedd yn ddirprwy i'r backend, sef ein cymhwysiad Java.
Roedd y ddeialog am broblemau fel hyn (yn sefydlog ar ochr ddirprwy Nginx):
- Cleient: cais i dderbyn gwybodaeth am lawrlwytho ffeil.
- Gweinydd Java: ymateb.
- Cleient: POST gyda ffeil.
- Gweinydd Java: gwall.
Ar yr un pryd, mae'r gweinydd Java yn ysgrifennu at y log bod 0 bytes o ddata wedi'u derbyn gan y cleient, ac mae'r dirprwy Nginx yn ysgrifennu bod y cais wedi cymryd mwy na 30 eiliad (30 eiliad yw terfyn amser y cais cleient). Pam y terfyn amser a pham 0 beit? O safbwynt HTTP, mae popeth yn gweithio fel y dylai, ond mae'n ymddangos bod y POST gyda'r ffeil yn diflannu o'r rhwydwaith. Ar ben hynny, mae'n diflannu rhwng y cleient a Nginx. Mae'n bryd arfogi'ch hun gyda Tcpdump! Ond yn gyntaf mae angen i chi ddeall cyfluniad y rhwydwaith. Mae dirprwy Nginx y tu ôl i'r balancer L3 . Defnyddir twnelu i ddosbarthu pecynnau o'r balancer L3 i'r gweinydd, sy'n ychwanegu ei benawdau at y pecynnau:
Yn yr achos hwn, mae'r rhwydwaith yn dod i'r gweinydd hwn ar ffurf traffig tag Vlan, sydd hefyd yn ychwanegu ei feysydd ei hun at y pecynnau:
A gall y traffig hwn fod yn dameidiog hefyd (yr un ganran fach honno o draffig tameidiog sy'n dod i mewn y buom yn siarad amdani wrth asesu'r risgiau o Workaround), sydd hefyd yn newid cynnwys y penawdau:
Unwaith eto: mae pecynnau wedi'u hamgáu â thag Vlan, wedi'u hamgáu â thwnnel, yn dameidiog. Er mwyn deall yn well sut mae hyn yn digwydd, gadewch i ni olrhain llwybr y pecyn o'r cleient i ddirprwy Nginx.
- Mae'r pecyn yn cyrraedd y balancer L3. Ar gyfer llwybro cywir o fewn y ganolfan ddata, caiff y pecyn ei grynhoi mewn twnnel a'i anfon at y cerdyn rhwydwaith.
- Gan nad yw'r pecyn + penawdau twnnel yn ffitio i'r MTU, mae'r pecyn yn cael ei dorri'n ddarnau a'i anfon i'r rhwydwaith.
- Mae'r switsh ar ôl y balancer L3, wrth dderbyn pecyn, yn ychwanegu tag Vlan ato ac yn ei anfon ymlaen.
- Mae'r switsh o flaen y dirprwy Nginx yn gweld (yn seiliedig ar y gosodiadau porthladd) bod y gweinydd yn disgwyl pecyn wedi'i amgáu gan Vlan, felly mae'n ei anfon fel y mae, heb dynnu'r tag Vlan.
- Mae Linux yn cymryd darnau o becynnau unigol ac yn eu huno i mewn i un pecyn mawr.
- Nesaf, mae'r pecyn yn cyrraedd rhyngwyneb Vlan, lle mae'r haen gyntaf yn cael ei thynnu ohono - amgapsiwleiddio Vlan.
- Yna mae Linux yn ei anfon i ryngwyneb y Twnnel, lle mae haen arall yn cael ei thynnu ohono - amgapsiwleiddio Twnnel.
Yr anhawster yw trosglwyddo hyn i gyd fel paramedrau i tcpdump.
Gadewch i ni ddechrau o'r diwedd: a oes pecynnau IP glân (heb benawdau diangen) gan gleientiaid, ac mae amgáu vlan a thwnnel wedi'i dynnu?
tcpdump host <ip клиента>
Na, nid oedd unrhyw becynnau o'r fath ar y gweinydd. Felly mae'n rhaid i'r broblem fod yno yn gynharach. A oes unrhyw becynnau ag amgáu Vlan yn unig wedi'u tynnu?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx yw cyfeiriad IP y cleient mewn fformat hecs.
32:4 — cyfeiriad a hyd y maes lle mae'r SCR IP wedi'i ysgrifennu yn y pecyn Twnnel.
Roedd yn rhaid dewis y cyfeiriad maes trwy rym 'n Ysgrublaidd, oherwydd ar y Rhyngrwyd maent yn ysgrifennu tua 40, 44, 50, 54, ond nid oedd cyfeiriad IP yno. Gallwch hefyd edrych ar un o'r pecynnau mewn hecs (y paramedr -xx neu -XX yn tcpdump) a chyfrifo'r cyfeiriad IP rydych chi'n ei wybod.
A oes darnau pecyn heb amgáu Vlan a Thwnnel wedi'u tynnu?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Bydd yr hud hwn yn dangos yr holl ddarnau i ni, gan gynnwys yr un olaf. Yn ôl pob tebyg, gall yr un peth gael ei hidlo gan IP, ond wnes i ddim ceisio, oherwydd nid oes llawer iawn o becynnau o'r fath, ac roedd y rhai yr oedd eu hangen arnaf i'w cael yn hawdd yn y llif cyffredinol. Dyma nhw:
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 ..............
Mae'r rhain yn ddau ddarn o un pecyn (yr un ID 53652) gyda ffotograff (mae'r gair Exif i'w weld yn y pecyn cyntaf). Oherwydd y ffaith bod pecynnau ar y lefel hon, ond nid yn y ffurf gyfun yn y tomenni, mae'r broblem yn amlwg gyda'r cynulliad. Yn olaf mae tystiolaeth ddogfennol o hyn!
Ni ddatgelodd y datgodiwr pecyn unrhyw broblemau a fyddai'n atal y gwaith adeiladu. Wedi rhoi cynnig arni yma: . Ar y dechrau, pan geisiwch stwffio rhywbeth yno, nid yw'r datgodiwr yn hoffi fformat y pecyn. Daeth i'r amlwg bod rhyw ddau wythawd ychwanegol rhwng Srcmac ac Ethertype (ddim yn gysylltiedig â gwybodaeth dameidiog). Ar ôl cael gwared arnynt, dechreuodd y datgodiwr weithio. Fodd bynnag, ni ddangosodd unrhyw broblemau.
Beth bynag a ddywedo un, ni chafwyd dim arall ond y Sysctl hyny. Y cyfan oedd ar ôl oedd dod o hyd i ffordd o adnabod gweinyddwyr problemus er mwyn deall y raddfa a phenderfynu ar gamau pellach. Canfuwyd y cownter gofynnol yn ddigon cyflym:
netstat -s | grep "packet reassembles failed”
Mae hefyd mewn snmpd o dan OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
“Nifer y methiannau a ganfuwyd gan yr algorithm ail-gydosod IP (am ba bynnag reswm: terfyn amser, gwallau, ac ati).”
Ymhlith y grŵp o weinyddion yr astudiwyd y broblem arnynt, ar ddau cynyddodd y rhifydd hwn yn gyflymach, ar ddau yn arafach, ac ar ddau arall ni chynyddodd o gwbl. Roedd cymharu deinameg y rhifydd hwn â deinameg gwallau HTTP ar weinydd Java yn datgelu cydberthynas. Hynny yw, gellid monitro'r mesurydd.
Mae cael dangosydd dibynadwy o broblemau yn bwysig iawn fel y gallwch chi benderfynu'n gywir a yw rholio'n ôl Sysctl yn helpu, oherwydd o'r stori flaenorol rydym yn gwybod na ellir deall hyn ar unwaith o'r cais. Byddai'r dangosydd hwn yn ein galluogi i nodi'r holl feysydd problem wrth gynhyrchu cyn i ddefnyddwyr ei ddarganfod.
Ar ôl treiglo'n ôl Sysctl, daeth y gwallau monitro i ben, felly profwyd achos y problemau, yn ogystal â'r ffaith bod y dychweliad yn helpu.
Fe wnaethon ni rolio'n ôl y gosodiadau darnio ar weinyddion eraill, lle daeth monitro newydd i rym, ac yn rhywle fe wnaethom ddyrannu hyd yn oed mwy o gof ar gyfer darnau nag oedd yn flaenorol (ystadegau'r CDU oedd hyn, ac nid oedd eu colled rannol yn amlwg yn erbyn y cefndir cyffredinol) .
Y cwestiynau pwysicaf
Pam mae pecynnau'n dameidiog ar ein balancer L3? SYN ac ACK yw'r rhan fwyaf o'r pecynnau sy'n cyrraedd o ddefnyddwyr i falanswyr. Mae meintiau'r pecynnau hyn yn fach. Ond gan fod y gyfran o becynnau o'r fath yn fawr iawn, yn erbyn eu cefndir ni wnaethom sylwi ar bresenoldeb pecynnau mawr a ddechreuodd ddarnio.
Y rheswm oedd sgript ffurfweddu wedi'i dorri ar weinyddion gyda rhyngwynebau Vlan (ychydig iawn o weinyddion â thraffig wedi'u tagio oedd yn cael eu cynhyrchu bryd hynny). Mae Advmss yn caniatáu inni gyfleu i'r cleient y wybodaeth y dylai pecynnau yn ein cyfeiriad fod yn llai o ran maint fel nad oes rhaid iddynt fod yn dameidiog ar ôl cysylltu penawdau twnnel arnynt.
Pam na wnaeth dychweliad Sysctl helpu, ond gwnaeth ailgychwyn? Newidiodd treiglo'n ôl Sysctl faint o gof oedd ar gael ar gyfer uno pecynnau. Ar yr un pryd, mae'n debyg bod y ffaith bod cof yn gorlifo ar gyfer darnau wedi arwain at arafu cysylltiadau, a arweiniodd at ohirio darnau am amser hir yn y ciw. Hynny yw, aeth y broses mewn cylchoedd.
Fe wnaeth yr ailgychwyn glirio'r cof a dychwelodd popeth i drefn.
Oedd hi'n bosibl gwneud heb Workaround? Oes, ond mae risg uchel o adael defnyddwyr heb wasanaeth pe bai ymosodiad. Wrth gwrs, arweiniodd y defnydd o Workaround at broblemau amrywiol, gan gynnwys arafu un o’r gwasanaethau i ddefnyddwyr, ond serch hynny credwn fod cyfiawnhad dros y camau gweithredu.
Diolch yn fawr i Andrey Timofeev () am gymorth i gynnal yr ymchwiliad, yn ogystal ag Alexey Krenev () - am y gwaith titanig o ddiweddaru Centos a chnewyllyn ar weinyddion. Proses y bu'n rhaid ei chychwyn sawl gwaith yn yr achos hwn o'r dechrau sawl gwaith, a dyna pam y bu'n llusgo ymlaen am fisoedd lawer.
Ffynhonnell: hab.com