Салом ба ҳама! Номи ман Дмитрий Самсонов, ман ҳамчун мудири пешбари система дар Одноклассники кор мекунам. Мо зиёда аз 7 ҳазор серверҳои физикӣ, 11 ҳазор контейнер дар абр ва 200 барнома дорем, ки дар конфигуратсияҳои гуногун 700 кластери гуногунро ташкил медиҳанд. Аксарияти серверҳо CentOS 7-ро идора мекунанд.
14 августи соли 2018 маълумот дар бораи осебпазирии FragmentSmack нашр шуд
() ва SegmentSmack (). Инҳо осебпазирӣ бо вектори ҳамлаи шабакавӣ ва баҳои хеле баланд (7.5) мебошанд, ки бо сабаби тамом шудани захираҳо (CPU) радди хидмат (DoS) таҳдид мекунад. Ислоҳи ядро барои FragmentSmack он вақт пешниҳод карда нашуда буд; илова бар ин, он хеле дертар аз нашри маълумот дар бораи осебпазирӣ пайдо шуд. Барои нест кардани SegmentSmack, пешниҳод карда шуд, ки ядро навсозӣ карда шавад. Худи бастаи навсозӣ дар ҳамон рӯз бароварда шуд, танҳо насб кардани он буд.
Не, мо умуман зидди навсозии ядро нестем! Бо вуҷуди ин, нозукиҳо вуҷуд доранд ...
Чӣ тавр мо ядроро дар истеҳсолот навсозӣ мекунем
Умуман, ҳеҷ чиз мураккаб нест:
- Бастаҳоро зеркашӣ кунед;
- Онҳоро дар як қатор серверҳо насб кунед (аз ҷумла серверҳое, ки абри моро ҷойгир мекунанд);
- Боварӣ ҳосил кунед, ки ҳеҷ чиз вайрон нашудааст;
- Боварӣ ҳосил кунед, ки ҳама танзимоти ядрои стандартӣ бе хатогӣ истифода мешаванд;
- Чанд рӯз интизор шавед;
- Санҷиши иҷрои сервер;
- Гузаронидани ҷобаҷогузории серверҳои нав ба ядрои нав;
- Ҳама серверҳоро аз рӯи маркази додаҳо навсозӣ кунед (як маркази додаҳо дар як вақт барои кам кардани таъсир ба корбарон дар ҳолати мушкилот);
- Ҳама серверҳоро бозоғоз намоед.
Барои ҳамаи шохаҳои ядроҳое, ки мо дорем, такрор кунед. Дар айни замон он аст:
- Stock CentOS 7 3.10 - барои аксари серверҳои муқаррарӣ;
- Vanilla 4.19 - барои мо , зеро ба мо BFQ, BBR ва ғайра лозим аст;
- Elrepo ядро-мл 5.2 - барои , зеро 4.19 пештар ноустувор рафтор мекард, аммо ҳамон хусусиятҳо лозиманд.
Тавре ки шумо тахмин кардаед, бозоғозкунии ҳазорҳо серверҳо тӯлонитарин вақтро мегирад. Азбаски на ҳама осебпазириҳо барои ҳама серверҳо муҳиманд, мо танҳо онҳоеро, ки мустақиман аз Интернет дастрасанд, аз нав оғоз мекунем. Дар абр, барои маҳдуд накардани чандирӣ, мо контейнерҳои аз берун дастрасро ба серверҳои инфиродӣ бо ядрои нав намепайвандем, балки ҳама ҳостҳоро бидуни истисно аз нав оғоз мекунем. Хушбахтона, тартиби он ҷо нисбат ба серверҳои муқаррарӣ соддатар аст. Масалан, контейнерҳои бидуни шаҳрвандӣ метавонанд ҳангоми бозсозӣ ба сервери дигар гузаранд.
Бо вуҷуди ин, ҳанӯз ҳам кор зиёд аст ва он метавонад якчанд ҳафта тӯл кашад ва агар дар версияи нав ягон мушкилот вуҷуд дошта бошад, то чанд моҳ. Ҳамлагарон инро хуб мефаҳманд, бинобар ин ба онҳо нақшаи Б лозим аст.
FragmentSmack/SegmentSmack. Роҳи ҳал
Хушбахтона, барои баъзе осебпазириҳо чунин нақшаи B мавҷуд аст ва он ҳалли мушкилот номида мешавад. Аксар вақт, ин тағирот дар танзимоти ядро/барнома мебошад, ки метавонад таъсири эҳтимолиро кам кунад ё истифодаи осебпазириро комилан аз байн барад.
Дар мавриди FragmentSmack/SegmentSmack ин роҳи ҳалли:
«Шумо метавонед арзишҳои пешфарзии 4МБ ва 3МБ дар net.ipv4.ipfrag_high_thresh ва net.ipv4.ipfrag_low_thresh (ва ҳамтоёни онҳо барои ipv6 net.ipv6.ipfrag_high_thresh ва net.ipv6.ipfrag_low_thresh) ва мутаносибан ба 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 дар мизбон кофӣ нест? Контейнер дар шабакаи махсуси номии худ зиндагӣ мекунад, бинобар ин ҳадди аққал дар контейнер метавонад аз мизбон фарқ кунад.
Танзимоти 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.
Қимати параметр дуруст нест. Аммо барои чӣ? Ва чаро он танҳо баъзан эътибор надорад? Маълум шуд, ки Docker тартиби татбиқи параметрҳои Sysctl-ро кафолат намедиҳад (версияи охирини санҷидашуда 1.13.1), бинобар ин баъзан ipfrag_high_thresh кӯшиш мекард, ки ба 256K муқаррар карда шавад, вақте ки ipfrag_low_thresh ҳанӯз 3M буд, яъне маҳдудияти болоӣ камтар буд аз хадди поёнй, ки боиси хатой гардид.
Он вақт мо аллакай механизми худро барои аз нав танзим кардани контейнер пас аз оғоз истифода мебурдем (ях кардани контейнер пас аз он). ва иҷрои фармонҳо дар фазои номи контейнер тавассути ) ва мо инчунин ба ин қисм параметрҳои навиштани Sysctl илова кардем. Масъала хал карда шуд.
FragmentSmack/SegmentSmack. Хуни аввал 2
Пеш аз он ки мо барои фаҳмидани истифодаи Workaround дар абр вақт пайдо кунем, аввалин шикоятҳои нодир аз корбарон ворид шудан гирифтанд. Дар он вақт аз оғози истифодаи Workaround дар серверҳои аввал чанд ҳафта гузашта буд. Тафтишоти аввалия нишон дод, ки шикоятҳо нисбати хидматҳои инфиродӣ ворид шудаанд, на ҳама серверҳои ин хидматҳо. Проблема боз нихоят номуайян гардид.
Пеш аз ҳама, мо, албатта, кӯшиш кардем, ки танзимоти Sysctl-ро баргардонем, аммо ин ҳеҷ таъсире надошт. Манипуляцияҳои гуногун бо танзимоти сервер ва барномаҳо низ кӯмак накарданд. Бозсозӣ кӯмак кард. Бозоғозкунии Linux ҳамчун ғайритабиӣ аст, зеро он дар рӯзҳои пеш барои Windows муқаррарӣ буд. Бо вуҷуди ин, он кӯмак кард ва мо ҳангоми татбиқи танзимоти нав дар Sysctl онро ба "нобудии ядро " табдил додем. Чӣ қадар бемаънӣ буд...
Пас аз се ҳафта мушкилот боз такрор шуд. Конфигуратсияи ин серверҳо хеле содда буд: Nginx дар реҷаи прокси/балансер. Трафики зиёд нест. Эзоҳҳои нави муқаддимавӣ: шумораи 504 хатогиҳо дар муштариён ҳар рӯз зиёд мешавад (). График шумораи 504 хатогиро дар як рӯз барои ин хидмат нишон медиҳад:
Ҳама хатогиҳо тақрибан як қафо мебошанд - дар бораи хатое, ки дар абр аст. Графикаи истеъмоли хотира барои порчаҳои бастаҳо дар ин пуштибонӣ чунин менамуд:
Ин яке аз равшантарин зуҳуроти мушкилот дар графикҳои системаи оператсионӣ мебошад. Дар абр, дар айни замон, мушкилоти дигари шабака бо танзимоти QoS (Назорати трафик) ҳал карда шуд. Дар графики истеъмоли хотира барои порчаҳои бастаҳо он комилан якхела буд:
Фарзия оддӣ буд: агар онҳо дар графикҳо якхела бошанд, пас онҳо як сабаб доранд. Ғайр аз он, ҳама гуна мушкилот бо ин намуди хотира хеле каманд.
Моҳияти мушкилоти ҳалшуда дар он буд, ки мо нақшаи бастаи fq-ро бо танзимоти пешфарз дар QoS истифода кардем. Бо нобаёнӣ, барои як пайвастшавӣ, он ба шумо имкон медиҳад, ки 100 бастаро ба навбат илова кунед ва баъзе пайвастҳо, дар ҳолатҳои нарасидани канал, навбатро ба иқтидор мебанданд. Дар ин ҳолат, бастаҳо партофта мешаванд. Дар tc statistics (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 танҳо навсозӣ кунем, зеро осебпазирии FragmentSmack, ки дар давоми CentOS 7.5 пайдо шуд, танҳо дар версияи 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 интиқол дода шавад.
Биёед аз охир сар кунем: оё пакетҳои IP-и пок (бе сарлавҳаҳои нолозим) аз муштариён бо инкапсуляцияи vlan ва туннел хориҷ карда шудаанд?
tcpdump host <ip клиента>
Не, дар сервер чунин бастаҳо вуҷуд надоштанд. Пас, мушкилот бояд пештар дар он ҷо бошад. Оё ягон бастаҳое вуҷуд доранд, ки танҳо инкапсуляцияи Vlan хориҷ карда шудаанд?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx суроғаи IP муштарӣ дар формати шонздаҳӣ мебошад.
32:4 — суроға ва дарозии майдоне, ки дар он рамзи SCR IP дар бастаи туннел навишта шудааст.
Суроғаи майдонро бо зӯри бераҳмона интихоб кардан лозим буд, зеро дар Интернет онҳо дар бораи 40, 44, 50, 54 менависанд, аммо дар он ҷо суроғаи IP вуҷуд надошт. Шумо инчунин метавонед ба яке аз бастаҳо дар шонздаҳӣ (параметри -xx ё -XX дар tcpdump) назар кунед ва суроғаи IP-ро, ки шумо медонед, ҳисоб кунед.
Оё порчаҳои бастаҳо бе инкапсуляцияи Vlan ва Tunnel нест карда шудаанд?
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 муайян карда шудааст (бо ҳар сабаб: ба охир расидани вақт, хатогиҳо ва ғайра)."
Дар байни гурўњи серверњое, ки масъала тањќиќ карда шуд, дар дуто ин њисобкунак тезтар, дар дутоаш оњистатар ва дар дуи дигар умуман зиёд нашуд. Муқоисаи динамикаи ин ҳисобкунак бо динамикаи хатогиҳои HTTP дар сервери Java таносубро ошкор кард. Яъне, ҳисобкунакро назорат кардан мумкин буд.
Доштани нишондиҳандаи боэътимоди мушкилот хеле муҳим аст, то шумо дақиқ муайян кунед, ки оё баргардонидани Sysctl кӯмак мекунад, зеро аз достони қаблӣ мо медонем, ки инро аз барнома фавран фаҳмидан мумкин нест. Ин нишондиҳанда ба мо имкон медиҳад, ки ҳама соҳаҳои мушкили истеҳсолотро пеш аз кашф кардани истифодабарандагон муайян кунем.
Пас аз баргардонидани Sysctl, хатогиҳои мониторинг қатъ шуданд, аз ин рӯ сабаби мушкилот ва инчунин далели он, ки баргашт кӯмак мекунад, исбот карда шуд.
Мо танзимоти фрагментатсияро дар серверҳои дигар баргардондем, ки дар он ҷо мониторинги нав ба кор даромад ва дар ҷое мо барои фрагментҳо хотираи бештаре ҷудо кардем, ки қаблан пешфарз буд (ин омори UDP буд, ки қисман талафоти онҳо дар заминаи умумӣ намоён набуд) .
Муҳимтарин саволҳо
Чаро бастаҳо дар мувозинати L3 мо тақсим карда шудаанд? Аксари бастаҳое, ки аз корбарон ба балансчиён меоянд, SYN ва ACK мебошанд. Андозаи ин бастаҳо хурд аст. Аммо азбаски ҳиссаи чунин бастаҳо хеле калон аст, дар пасманзари онҳо мо мавҷудияти бастаҳои калонеро, ки ба пораҳо шурӯъ кардаанд, мушоҳида накардаем.
Сабаб скрипти конфигуратсияи вайроншуда буд дар серверҳое, ки интерфейси Vlan доранд (дар он вақт серверҳои дорои трафики барчасп дар истеҳсолот хеле кам буданд). Advmss ба мо имкон медиҳад, ки ба муштарӣ маълумоте расонем, ки пакетҳо дар самти мо бояд андозаи хурдтар бошанд, то пас аз пайваст кардани сарлавҳаҳои нақб ба онҳо пора-пора нашаванд.
Чаро бозгашти Sysctl кӯмак накард, аммо бозоғозӣ кард? Бозгашти Sysctl ҳаҷми хотираро барои якҷоя кардани бастаҳо тағйир дод. Дар баробари ин, аз афташ, худи факти пур шудани хотираи фрагментхо боиси суст шудани алокахо гардид, ки ин боиси дар навбат ба таъхир афтодани порахо гардид. Яъне ин раванд дар давраҳо мерафт.
Бозоғозӣ хотираро аз нав барқарор кард ва ҳама чиз ба тартиб омад.
Оё бе ҳалли мушкилот имконпазир буд? Бале, аммо хатари бе хидмат мондани корбарон дар сурати ҳамла вуҷуд дорад. Албатта, истифодаи Муваффақият боиси мушкилоти гуногун, аз ҷумла суст шудани яке аз хидматҳо барои корбарон гардид, аммо бо вуҷуди ин мо боварӣ дорем, ки амалҳо асоснок буданд.
Ташаккури зиёд ба Андрей Тимофеев () барои мусоидат дар гузаронидани тафтишот, инчунин Алексей Кренев () - барои кори титаники навсозии Centos ва ядроҳо дар серверҳо. Равандеро, ки дар ин маврид чанд маротиба аз аввал оғоз кардан лозим омад, бинобар ин он моҳҳои зиёд кашол ёфт.
Манбаъ: will.com