Баарына салам! Менин атым Дмитрий Самсонов, мен Одноклассникиде алдыңкы системалык администратор болуп иштейм. Бизде 7 миңден ашык физикалык серверлер, булуттагы 11 миң контейнер жана ар кандай конфигурацияларда 200 түрдүү кластерлерди түзгөн 700 тиркемелер бар. Серверлердин басымдуу көпчүлүгү CentOS 7 менен иштешет.
14-жылдын 2018-августунда FragmentSmack алсыздыгы тууралуу маалымат жарыяланган
() жана SegmentSmack (). Бул тармактык чабуул вектору жана ресурстун түгөнүп калышынан (CPU) кызмат көрсөтүүдөн баш тартууга (DoS) коркунуч туудурган жетишерлик жогорку баллга ээ (7.5) алсыздыктар. Ал убакта FragmentSmack үчүн ядрону оңдоо сунушталган эмес; анын үстүнө, ал аялуу жөнүндө маалымат жарыялангандан бир топ кечирээк чыккан. SegmentSmack жок кылуу үчүн, ядрону жаңылоо сунушталды. Жаңыртуу топтомунун өзү ошол эле күнү чыгарылды, аны орнотуу гана калды.
Жок, биз ядрону жаңылоого таптакыр каршы эмеспиз! Бирок, нюанстар бар ...
Өндүрүштөгү ядрону кантип жаңыртабыз
Жалпысынан алганда, татаал эч нерсе жок:
- Пакеттерди жүктөө;
- Аларды бир катар серверлерге орнотуңуз (анын ичинде биздин булутту жайгаштыруучу серверлер);
- Эч нерсе бузулбагандыгын текшериңиз;
- Бардык стандарттуу ядро орнотуулары катасыз колдонулушун текшериңиз;
- бир нече күн күтө тур;
- Сервердин иштешин текшерүү;
- Жаңы серверлерди жаңы ядрого жайылтуу;
- Бардык серверлерди маалымат борбору боюнча жаңыртуу (көйгөйлөр пайда болгон учурда колдонуучуларга таасирин азайтуу үчүн бирден бир маалымат борбору);
- Бардык серверлерди кайра жүктөө.
Бизде бар ядронун бардык бутактары үчүн кайталаъыз. Учурда бул:
- Stock CentOS 7 3.10 - көпчүлүк кадимки серверлер үчүн;
- Vanilla 4.19 - биздики , анткени бизге BFQ, BBR ж.б.у.с. керек;
- Elrepo ядро-мл 5.2 - үчүн , анткени 4.19 өзүн туруксуз алып жүрчү, бирок ошол эле өзгөчөлүктөр керек.
Сиз ойлогондой, миңдеген серверлерди кайра жүктөө эң көп убакытты талап кылат. Бардык эле кемчиликтер бардык серверлер үчүн маанилүү болбогондуктан, биз Интернеттен түздөн-түз жеткиликтүү болгондорду гана кайра жүктөйбүз. Булутта, ийкемдүүлүктү чектебеш үчүн, биз жаңы ядросу бар жеке серверлерге сырттан жеткиликтүү контейнерлерди байлап койбойбуз, бирок бардык хостторду өчүрбөй кайра жүктөйбүз. Бактыга жараша, ал жерде процедура кадимки серверлерге караганда жөнөкөй. Мисалы, жарандыгы жок контейнерлер кайра жүктөө учурунда башка серверге жыла алышат.
Бирок, дагы эле көп иш бар, ал бир нече жумага созулушу мүмкүн, ал эми жаңы версияда кандайдыр бир көйгөйлөр жаралса, бир нече айга чейин созулушу мүмкүн. Чабуулчулар муну абдан жакшы түшүнүшөт, ошондуктан аларга Б планы керек.
FragmentSmack/SegmentSmack. Чечим
Бактыга жараша, кээ бир алсыздыктар үчүн мындай В планы бар жана ал убактылуу чечүү деп аталат. Көбүнчө, бул мүмкүн болуучу эффектти азайта турган же алсыздыктын эксплуатациясын толугу менен жок кыла турган ядро/колдонмо жөндөөлөрүндөгү өзгөртүү.
FragmentSmack/SegmentSmack учурда Бул сыяктуу убактылуу чечүү:
«Сиз net.ipv4.ipfrag_high_thresh жана net.ipv3.ipfrag_low_thresh (жана алардын ipv4 net.ipv4.ipfrag_high_thresh жана net.ipv6.ipfrag_low_thresh үчүн окшоштору) 6МБ жана 6МБ демейки маанилерин жана тиешелүүлүгүнө жараша 256 кБга өзгөртө аласыз. төмөн. Сыноолор аппараттык камсыздоого, жөндөөлөргө жана шарттарга жараша чабуул учурунда CPU колдонуусунун кичинеден олуттуу төмөндөшүн көрсөтөт. Бирок, ipfrag_high_thresh=192 байттан улам өндүрүмдүүлүккө кандайдыр бир таасир тийгизиши мүмкүн, анткени бир эле учурда эки 262144К фрагмент кайра чогултуу кезегине туура келет. Мисалы, чоң UDP пакеттери менен иштеген тиркемелер бузулуп калуу коркунучу бар«.
Параметрлер өздөрү төмөнкүчө сүрөттөлгөн:
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.
Бизде өндүрүш кызматтары боюнча чоң UDP жок. LANда фрагменттүү трафик жок; WANда фрагменттүү трафик бар, бирок маанилүү эмес. Эч кандай белгилер жок - сиз Чечүүнү чыгара аласыз!
FragmentSmack/SegmentSmack. Биринчи кан
Биз жолуккан биринчи көйгөй, булут контейнерлери жаңы жөндөөлөрдү кээде жарым-жартылай гана колдонушкан (ipfrag_low_thresh гана), ал эми кээде аларды такыр колдонушкан эмес - алар жөн гана башында кыйрап калышты. Көйгөйдү туруктуу түрдө кайра чыгаруу мүмкүн болгон жок (бардык орнотуулар эч кандай кыйынчылыксыз кол менен колдонулган). Контейнер эмне үчүн башында кыйрап калганын түшүнүү да оңой эмес: эч кандай ката табылган жок. Бир нерсе анык болду: орнотууларды артка жылдыруу контейнердин бузулушу менен көйгөйдү чечет.
Эмне үчүн хостто Sysctl колдонуу жетишсиз? Контейнер өзүнүн атайын тармактык Namespace тармагында жашайт, ошондуктан жок дегенде контейнердегилер хосттон айырмаланышы мүмкүн.
Sysctl жөндөөлөрү контейнерде кантип так колдонулат? Биздин контейнерлер артыкчылыксыз болгондуктан, контейнердин өзүнө кирип, эч кандай Sysctl жөндөөлөрүн өзгөртө албайсыз - сизде жетиштүү укуктар жок. Контейнерлерди иштетүү үчүн ошол убакта биздин булут Docker (азыр ). Жаңы контейнердин параметрлери Dockerге API аркылуу, анын ичинде зарыл болгон Sysctl жөндөөлөрү өткөрүлүп берилди.
Версияларды издөө учурунда Docker API бардык каталарды кайтарып бербегени белгилүү болду (жок дегенде 1.10 версиясында). Контейнерди "докердик иштетүү" аркылуу баштоого аракет кылганда, акыры, жок дегенде бир нерсени көрдүк:
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.
Параметрдин мааниси жараксыз. Бирок эмне үчүн? Анан эмне үчүн кээде гана жарабайт? Докер Sysctl параметрлеринин колдонулуш тартибине кепилдик бербей турганы белгилүү болду (акыркы сыналган версиясы 1.13.1), ошондуктан кээде ipfrag_high_thresh дагы 256M болгон учурда ipfrag_high_thresh 3Кга коюуга аракет кылышкан, башкача айтканда, жогорку чек төмөн болгон. катага алып келген төмөнкү чекке караганда.
Ошол учурда биз контейнерди ишке киргизгенден кийин конфигурациялоо үчүн өзүбүздүн механизмибизди колдончубуз (контейнерди тоңдургандан кийин аркылуу контейнердин аталыш мейкиндигинде буйруктарды аткаруу ), ошондой эле бул бөлүккө Sysctl жазуу параметрлерин коштук. Маселе чечилди.
FragmentSmack/SegmentSmack. Биринчи кан 2
Булуттагы Workaround колдонууну түшүнүүгө үлгүрө электе, колдонуучулардан биринчи сейрек даттануулар келе баштады. Ошол убакта биринчи серверлерде Workaround колдонула баштагандан бери бир нече жума өткөн. Алгачкы иликтөө көрсөткөндөй, даттануулар бул кызматтардын бардык серверлерине эмес, айрым кызматтарга да түшкөн. Маселе кайрадан өтө белгисиз болуп калды.
Биринчиден, биз, албетте, Sysctl орнотууларын артка кайтарууга аракет кылдык, бирок бул эч кандай натыйжа берген жок. Сервер жана тиркеме орнотуулары менен ар кандай манипуляциялар да жардам берген жок. Кайра жүктөө жардам берди. Linux'ту кайра жүктөө эски күндөрдө Windows үчүн кадимкидей табигый эмес. Бирок, бул жардам берди жана биз аны Sysctlде жаңы орнотууларды колдонууда "ядро катасы" деп атадык. Кандай жеңил ойлуу эле...
Үч жумадан кийин көйгөй кайталанды. Бул серверлердин конфигурациясы абдан жөнөкөй эле: Nginx прокси/баланстыргыч режиминде. Трафик көп эмес. Жаңы кириш сөз: кардарлардын 504 катасынын саны күн сайын көбөйүүдө (). График бул кызмат үчүн күнүнө 504 ката санын көрсөтөт:
Бардык каталар бир эле серверде - булуттагы каталар жөнүндө. Бул сервердеги пакет фрагменттери үчүн эстутум керектөө графиги төмөнкүдөй болду:
Бул операциялык системанын графиктериндеги көйгөйдүн эң айкын көрүнүштөрүнүн бири. Булутта, ошол эле учурда, QoS (Traffic Control) орнотуулары менен дагы бир тармак көйгөйү чечилди. Пакет фрагменттери үчүн эстутум керектөө графигинде дал ушундай көрүндү:
Болжолдоо жөнөкөй эле: эгерде алар графиктерде бирдей көрүнсө, анда аларда бир эле себеп бар. Мындан тышкары, эс бул түрү менен ар кандай көйгөйлөр өтө сейрек кездешет.
Түзүлгөн маселенин маңызы биз fq пакет пландоочусун QoS демейки жөндөөлөрү менен колдондук. Демейки боюнча, бир туташуу үчүн ал кезекке 100 пакетти кошууга мүмкүндүк берет, ал эми кээ бир байланыштар, каналдын жетишсиздигинен улам, кезекти сыйымдуулукка жабыштыра баштады. Бул учурда, пакеттер түшүрүлөт. tc статистикасында (tc -s qdisc) муну төмөнкүдөй көрүүгө болот:
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” – бул бир туташуунун кезек чегинен ашкандыгына байланыштуу алынып салынган пакеттер, ал эми “түшүрүлгөн 464545” бул пландаштыргычтын бардык түшүрүлгөн пакеттеринин суммасы. Кезектин узундугун 1 миңге чейин көбөйтүп, контейнерлерди кайра иштеткенден кийин, көйгөй токтоду. Сиз отуруп алып, смузи ичсеңиз болот.
FragmentSmack/SegmentSmack. Акыркы Кан
Биринчиден, ядродогу алсыздыктар жарыялангандан бир нече ай өткөндөн кийин, акыры FragmentSmack үчүн оңдоо пайда болду (эске сала кетейин, августтагы жарыя менен бирге SegmentSmack үчүн гана оңдоо чыгарылган), бул бизге Workaroundтен баш тартууга мүмкүнчүлүк берди, бул бизге бир топ кыйынчылык жаратты. Бул убакыттын ичинде биз серверлердин бир бөлүгүн жаңы ядрого өткөрүүгө жетиштик, эми биз башынан баштоого туура келди. Эмне үчүн биз FragmentSmack оңдоосун күтпөстөн ядрону жаңырттык? Чындыгында, бул алсыздыктардан коргоо процесси CentOSтун өзүн жаңылоо процесси менен дал келген (жана бириктирилген) (бул өзөктү гана жаңыртуудан да көп убакытты талап кылат). Мындан тышкары, SegmentSmack бир кыйла кооптуу аялуу болуп саналат жана аны оңдоо дароо пайда болду, андыктан баары бир мааниси бар. Бирок, биз CentOS'тун ядросун жөн эле жаңырта алган жокпуз, анткени CentOS 7.5 учурунда пайда болгон FragmentSmack аялуулугу 7.6 версиясында гана оңдолгон, андыктан 7.5ке жаңыртууну токтотуп, 7.6га жаңыртуу менен баарын башынан баштоого туура келди. Жана бул да болот.
Экинчиден, көйгөйлөр боюнча сейрек колдонуучу даттануулар бизге кайтып келди. Эми биз алардын бардыгы кардарлардан биздин серверлерибизге файлдарды жүктөө менен байланыштуу экенин так билебиз. Мындан тышкары, бул серверлер аркылуу жалпы массадан өтө аз сандагы жүктөөлөр өттү.
Жогорудагы окуядан эстегендей, Sysctl артка жылдыруу жардам берген жок. Кайра жүктөө жардам берди, бирок убактылуу.
Sysctlге байланыштуу шектенүүлөр жок кылынган жок, бирок бул жолу мүмкүн болушунча көбүрөөк маалымат чогултуу керек болчу. Ошондой эле, эмне болуп жатканын так изилдөө үчүн кардардагы жүктөө көйгөйүн кайра чыгаруу мүмкүнчүлүгүнүн жетишсиздиги болгон.
Бардык колдо болгон статистиканы жана журналдарды талдоо бизди эмне болуп жатканын түшүнүүгө жакындата алган жок. Белгилүү бир байланышты "сезүү" үчүн көйгөйдү кайра жаратуу жөндөмүнүн кескин жетишсиздиги болгон. Акыр-аягы, иштеп чыгуучулар, тиркеменин атайын версиясын колдонуу менен, Wi-Fi аркылуу туташкан тесттик түзүлүштөгү көйгөйлөрдүн туруктуу репродукциясына жетише алышты. Бул тергөөдөгү жылыш болду. Кардар Nginx'ке туташты, ал серверге прокси менен байланышты, ал биздин Java тиркемеси болгон.
Көйгөйлөрдүн диалогу ушундай болгон (Nginx прокси тарабында бекитилген):
- Кардар: файлды жүктөө жөнүндө маалымат алууну суранат.
- Java сервери: жооп.
- Кардар: файл менен POST.
- Java сервери: ката.
Ошол эле учурда, Java сервери журналга кардардан 0 байт маалымат алынганын жазат, ал эми Nginx проксиси суроо-талап 30 секунддан ашык убакытка созулганын жазат (30 секунд - кардар тиркемесинин тайм-ауту). Эмне үчүн тайм-аут жана эмне үчүн 0 байт? HTTP көз карашынан алганда, баары каалагандай иштейт, бирок файлы бар POST тармактан жок болуп жаткандай. Мындан тышкары, ал кардар менен Nginx ортосунда жок болот. Tcpdump менен куралданууга убакыт келди! Бирок адегенде тармактын конфигурациясын түшүнүшүңүз керек. Nginx прокси L3 балансынын артында турат . Туннелдөө пакеттерди L3 баланстоочусунан серверге жеткирүү үчүн колдонулат, ал пакеттерге өз аталыштарын кошот:
Бул учурда, тармак бул серверге Vlan-тегдүү трафик түрүндө келет, ал дагы пакеттерге өзүнүн талааларын кошот:
Жана бул трафик да фрагменттелиши мүмкүн (кире турган фрагменттелген трафиктин ошол эле аз пайызы, биз Workaround тобокелдиктерин баалоодо айткан), бул дагы баш аталыштардын мазмунун өзгөртөт:
Дагы бир жолу: пакеттер Vlan теги менен капталган, туннел менен капталган, фрагменттелген. Мунун кантип болорун жакшыраак түшүнүү үчүн, келгиле, кардардан Nginx проксиге чейинки пакеттик маршрутту карап көрөлү.
- Пакет L3 баланстоочуга жетет. Маалымат борборунун ичинде туура багыттоо үчүн пакет туннелге капсулдалат жана тармактык картага жөнөтүлөт.
- Пакет + туннель баштары MTUга туура келбегендиктен, пакет фрагменттерге бөлүнүп, тармакка жөнөтүлөт.
- L3 баланстоочусунан кийинки которгуч пакетти кабыл алууда ага Vlan тегин кошуп, аны жөнөтөт.
- Nginx проксисинин алдындагы которгуч (порттун жөндөөлөрүнүн негизинде) сервер Vlan-инкапсуляцияланган пакетти күтүп жатканын көрүп, аны Vlan тэгин алып салбастан, ошол бойдон жөнөтөт.
- Linux жеке пакеттердин фрагменттерин алып, аларды бир чоң пакетке бириктирет.
- Андан кийин пакет Vlan интерфейсине жетет, анда андан биринчи катмар алынып салынат - Vlan инкапсуляциясы.
- Андан кийин Linux аны туннель интерфейсине жөнөтөт, ал жерден дагы бир катмар алынып салынат - туннель инкапсуляциясы.
Кыйынчылык - мунун баарын tcpdump үчүн параметр катары өткөрүү.
Акырынан баштайлы: vlan жана туннель инкапсуляциясы алынып салынган кардарлардын таза (керексиз аталыштары жок) IP пакеттери барбы?
tcpdump host <ip клиента>
Жок, серверде мындай пакеттер болгон эмес. Демек, маселе эртерээк болушу керек. Vlan инкапсуляциясы алынып салынган пакеттер барбы?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx - hex форматындагы кардар IP дареги.
32:4 — Туннел пакетинде SCR IP жазылган талаанын дареги жана узундугу.
Талаанын дарегин катаал күч менен тандоо керек болчу, анткени Интернетте 40, 44, 50, 54 деп жазышат, бирок ал жерде IP дареги жок болчу. Сиз ошондой эле он алтылык пакеттердин бирин карап (tcpdump ичиндеги -xx же -XX параметри) жана сиз билген IP даректи эсептей аласыз.
Vlan жана туннель инкапсуляциясы жок пакет фрагменттери барбы?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Бул сыйкыр бизге бардык фрагменттерди, анын ичинде акыркысын көрсөтөт. Балким, ошол эле нерсени IP чыпкалап алса болот, бирок мен аракет кылган жокмун, анткени мындай пакеттер өтө көп эмес жана мага керектүү пакеттер жалпы агымда оңой табылды. Бул жерде алар:
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 ..............
Бул бир пакеттин эки фрагменттери (ошол эле ID 53652) сүрөтү бар (биринчи пакетте Exif сөзү көрүнүп турат). Бул денгээлде пакеттер бар экенине байланыштуу, бирок таштандыларда бириктирилген түрдө эмес, көйгөй монтажда ачык. Акыры мунун документалдуу далилдери бар!
Пакет декодери курууга тоскоол боло турган көйгөйлөрдү көрсөткөн жок. Бул жерде аракет кылдым: . Башында, сиз ал жерге бир нерсени толтурууга аракет кылганыңызда, декодерге пакет форматы жакпайт. Srcmac менен Ethertype ортосунда кошумча эки октет бар экени белгилүү болду (фрагмент маалыматына тиешеси жок). Аларды алып салгандан кийин декодер иштей баштады. Бирок, ал эч кандай көйгөйлөрдү көрсөттү.
Ким эмне десе да, ошол Sysctlден башка эч нерсе табылган жок. Масштабды түшүнүү жана андан аркы аракеттерди чечүү үчүн көйгөйлүү серверлерди аныктоонун жолун табуу гана калды. Керектүү эсептегич тез эле табылды:
netstat -s | grep "packet reassembles failed”
Ал ошондой эле snmpd ичинде OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"IP кайра монтаждоо алгоритми тарабынан аныкталган мүчүлүштүктөрдүн саны (кандайдыр бир себептерден улам: убакыттын өтүшү, каталар ж.б.)."
Көйгөй изилденген серверлердин тобунун ичинен экөөндө бул эсептегич тезирээк өстү, экөөсүндө жайыраак, дагы экөөсүндө такыр көбөйгөн жок. Бул эсептегичтин динамикасын Java сервериндеги HTTP каталарынын динамикасы менен салыштыруу корреляцияны аныктады. Башкача айтканда, эсептегичти көзөмөлдөп турса болмок.
Көйгөйлөрдүн ишенимдүү индикаторуна ээ болуу абдан маанилүү, ошондуктан сиз Sysctl артка кайтаруу жардам береби же жокпу, аны так аныктай аласыз, анткени мурунку окуядан биз муну колдонмодон дароо түшүнүү мүмкүн эмес экенин билебиз. Бул көрсөткүч колдонуучулар аны ачканга чейин өндүрүштүн бардык көйгөйлөрүн аныктоого мүмкүндүк берет.
Sysctl артка кайтарылгандан кийин, мониторинг каталары токтоп калды, ошентип көйгөйлөрдүн себеби далилденди, ошондой эле артка кайтаруу жардам берет.
Биз башка серверлердеги фрагментациянын жөндөөлөрүн артка кайтардык, анда жаңы мониторинг пайда болду жана кайсы бир жерде биз фрагменттерге мурда демейкиге караганда көбүрөөк эстутумду бөлдүк (бул UDP статистикасы болчу, анын жарым-жартылай жоготуусу жалпы фондо байкалган эмес) .
Эң маанилүү суроолор
Эмне үчүн пакеттер биздин L3 баланстоочубузга бөлүнгөн? Колдонуучулардан баланстоочуларга келген пакеттердин көбү SYN жана ACK. Бул пакеттердин өлчөмдөрү кичинекей. Бирок мындай пакеттердин үлүшү өтө чоң болгондуктан, алардын фонунда биз майдалана баштаган чоң пакеттердин бар экенин байкаган жокпуз.
Мунун себеби бузулган конфигурация сценарийи болгон Vlan интерфейстери бар серверлерде (ал кезде өндүрүштө теги трафиги бар серверлер өтө аз болчу). Advmss кардарга биздин багыт боюнча пакеттер көлөмү кичине болушу керек деген маалыматты жеткирүүгө мүмкүндүк берет, андыктан туннель баштарын тирккенден кийин алар фрагменттүү болбошу керек.
Эмне үчүн Sysctl артка кайтаруу жардам берген жок, бирок кайра жүктөө жардам берди? Sysctl артка кайтаруу пакеттерди бириктирүү үчүн жеткиликтүү эстутумдун көлөмүн өзгөрттү. Ошол эле учурда, сыягы, фрагменттердин эс тутумунун толуп кетүү фактысынын өзү байланыштардын басаңдашына алып келди, бул фрагменттердин кезекте көпкө кармалып калышына алып келди. Башкача айтканда, процесс циклдар менен жүрдү.
Кайра жүктөө эстутумду тазалап, баары өз ордуна келди.
Убактылуу чарасыз жасоо мүмкүнбү? Ооба, бирок чабуул болгон учурда колдонуучуларды тейлөөсүз калтыруу коркунучу жогору. Албетте, Workaround колдонуу ар кандай көйгөйлөргө алып келди, анын ичинде колдонуучулар үчүн кызматтардын биринин басаңдашы, бирок ошентсе да биз иш-аракеттерди актады деп эсептейбиз.
Андрей Тимофеевге чоң рахмат () тергөө иштерин жүргүзүүгө көмөк көрсөткөндүгү үчүн, ошондой эле Алексей Креневге () - серверлердеги Centos жана ядролорду жаңыртуу боюнча титаникалык иш үчүн. Бул учурда бир нече жолу башынан баштоого туура келген процесс, ошондуктан ал көп айга созулду.
Source: www.habr.com