Hammaga salom! Mening ismim Dmitriy Samsonov, men Odnoklassniki-da yetakchi tizim administratori bo'lib ishlayman. Bizda 7 mingdan ortiq jismoniy serverlar, bulutimizda 11 ming konteyner va turli xil konfiguratsiyalarda 200 xil klasterlarni tashkil etuvchi 700 ta ilova mavjud. Serverlarning katta qismi CentOS 7 da ishlaydi.
14 yil 2018 avgustda FragmentSmack zaifligi haqida ma'lumot e'lon qilindi
() va SegmentSmack (). Bular tarmoq hujumi vektori va ancha yuqori ball (7.5) bo'lgan zaifliklar bo'lib, resurslarning tugashi (CPU) tufayli xizmat ko'rsatishni rad etish (DoS) bilan tahdid qiladi. O'sha paytda FragmentSmack uchun yadro tuzatish taklif qilinmagan, bundan tashqari, u zaiflik haqidagi ma'lumotlar nashr etilgandan ancha kechroq paydo bo'lgan. SegmentSmack-ni yo'q qilish uchun yadroni yangilash taklif qilindi. Yangilanish paketining o'zi xuddi shu kuni chiqarildi, qolgani uni o'rnatish edi.
Yo'q, biz yadroni yangilashga umuman qarshi emasmiz! Biroq, nuanslar bor ...
Ishlab chiqarishda yadroni qanday yangilaymiz
Umuman olganda, hech qanday murakkab narsa yo'q:
- Paketlarni yuklab olish;
- Ularni bir qator serverlarga o'rnating (jumladan, bizning bulutli serverlarga);
- Hech narsa buzilmaganligiga ishonch hosil qiling;
- Barcha standart yadro sozlamalari xatosiz qo'llanilishiga ishonch hosil qiling;
- Bir necha kun kuting;
- Server ish faoliyatini tekshirish;
- Yangi serverlarni yangi yadroga joylashtirish;
- Barcha serverlarni ma'lumotlar markazi bo'yicha yangilang (muammolar yuzaga kelganda foydalanuvchilarga ta'sirini kamaytirish uchun bir vaqtning o'zida bitta ma'lumot markazi);
- Barcha serverlarni qayta ishga tushiring.
Bizda mavjud bo'lgan yadrolarning barcha shoxlari uchun takrorlang. Ayni paytda u:
- Stock CentOS 7 3.10 - eng oddiy serverlar uchun;
- Vanilla 4.19 - biz uchun , chunki bizga BFQ, BBR va boshqalar kerak;
- Elrepo yadrosi-ml 5.2 - uchun , chunki 4.19 o'zini beqaror tutgan, ammo bir xil xususiyatlar kerak.
Siz taxmin qilganingizdek, minglab serverlarni qayta ishga tushirish eng uzoq vaqtni oladi. Barcha zaifliklar barcha serverlar uchun muhim emasligi sababli, biz faqat Internetdan to'g'ridan-to'g'ri kirish mumkin bo'lganlarni qayta ishga tushiramiz. Bulutda, moslashuvchanlikni cheklamaslik uchun, biz tashqi kirish mumkin bo'lgan konteynerlarni alohida serverlarga yangi yadro bilan bog'lamaymiz, lekin istisnosiz barcha xostlarni qayta ishga tushiramiz. Yaxshiyamki, u erda protsedura oddiy serverlarga qaraganda osonroq. Misol uchun, fuqaroligi bo'lmagan konteynerlar qayta yuklash paytida boshqa serverga o'tishi mumkin.
Biroq, hali ko'p ish bor va bu bir necha hafta davom etishi mumkin va agar yangi versiyada muammolar mavjud bo'lsa, bir necha oygacha. Hujumchilar buni juda yaxshi tushunadilar, shuning uchun ularga B rejasi kerak.
FragmentSmack/SegmentSmack. Vaqtinchalik yechim
Yaxshiyamki, ba'zi zaifliklar uchun bunday B rejasi mavjud va u vaqtinchalik yechim deb ataladi. Ko'pincha, bu mumkin bo'lgan ta'sirni kamaytirish yoki zaifliklardan foydalanishni butunlay yo'q qilish mumkin bo'lgan yadro/ilova sozlamalaridagi o'zgarish.
FragmentSmack/SegmentSmack misolida bu vaqtinchalik yechim:
«Siz net.ipv4.ipfrag_high_thresh va net.ipv3.ipfrag_low_thresh (va ularning ipv4 net.ipv4.ipfrag_high_thresh va net.ipv6.ipfrag_low_thresh uchun oʻxshashlari) da 6MB va 6MB standart qiymatlarini mos ravishda 256 kB ga oʻzgartirishingiz mumkin. pastroq. Sinovlar apparat, sozlamalar va sharoitlarga qarab hujum paytida protsessordan foydalanishda kichik va sezilarli pasayishlarni ko'rsatadi. Biroq, ipfrag_high_thresh=192 bayt tufayli ba'zi ishlash ta'siri bo'lishi mumkin, chunki bir vaqtning o'zida faqat ikkita 262144K fragment qayta yig'ish navbatiga sig'ishi mumkin. Misol uchun, katta UDP paketlari bilan ishlaydigan ilovalarning buzilishi xavfi mavjud".
Parametrlarning o'zi quyidagicha tasvirlangan:
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.
Bizda ishlab chiqarish xizmatlarida katta UDP yo'q. LAN tarmog'ida parchalangan trafik yo'q, WAN tarmog'ida parchalangan trafik mavjud, ammo ahamiyatli emas. Hech qanday belgilar yo'q - siz vaqtinchalik echimni ishga tushirishingiz mumkin!
FragmentSmack/SegmentSmack. Birinchi qon
Biz duch kelgan birinchi muammo shundaki, bulutli konteynerlar ba'zida yangi sozlamalarni faqat qisman qo'llagan (faqat ipfrag_low_thresh), ba'zan esa ularni umuman qo'llamagan - ular boshidayoq qulab tushgan. Muammoni barqaror ravishda qayta ishlab chiqarish mumkin emas edi (barcha sozlamalar hech qanday qiyinchiliksiz qo'lda qo'llanilgan). Nima uchun konteyner boshida qulab tushishini tushunish ham unchalik oson emas: hech qanday xato topilmadi. Bir narsa aniq edi: sozlamalarni orqaga qaytarish konteyner ishdan chiqishi bilan bog'liq muammoni hal qiladi.
Nima uchun Sysctl-ni xostda qo'llash etarli emas? Konteyner o'zining maxsus nom maydonida yashaydi, shuning uchun hech bo'lmaganda konteynerdagi uy egasidan farq qilishi mumkin.
Sysctl sozlamalari konteynerda qanday qo'llaniladi? Konteynerlarimiz imtiyozsiz bo'lgani uchun konteynerning o'ziga kirib, hech qanday Sysctl sozlamalarini o'zgartira olmaysiz - sizda yetarlicha huquqlar yo'q. Konteynerlarni ishga tushirish uchun bizning bulutimiz o'sha paytda Dockerdan foydalangan (hozir ). Yangi konteyner parametrlari API orqali Docker-ga uzatildi, shu jumladan kerakli Sysctl sozlamalari.
Versiyalarni qidirishda Docker API barcha xatolarni qaytarmaganligi ma'lum bo'ldi (hech bo'lmaganda 1.10 versiyada). Biz konteynerni "docker run" orqali ishga tushirishga harakat qilganimizda, nihoyat, hech bo'lmaganda bir narsani ko'rdik:
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.
Parametr qiymati noto'g'ri. Lekin nima uchun? Va nima uchun u faqat ba'zan amal qilmaydi? Ma'lum bo'lishicha, Docker Sysctl parametrlarini qo'llash tartibini kafolatlamaydi (so'nggi sinovdan o'tgan versiya 1.13.1), shuning uchun ba'zida ipfrag_low_thresh hali 256M bo'lganida ipfrag_high_thresh 3K ga o'rnatishga harakat qilgan, ya'ni yuqori chegara pastroq bo'lgan. pastki chegaradan ko'ra, bu xatoga olib keldi.
O'sha paytda biz allaqachon konteynerni ishga tushirgandan so'ng (konteynerni muzlatib qo'ygandan keyin) qayta sozlash uchun o'z mexanizmimizni ishlatgan edik. orqali konteyner nomlar maydonidagi buyruqlarni bajarish ) va biz ushbu qismga Sysctl parametrlarini yozishni ham qo'shdik. Muammo hal qilindi.
FragmentSmack/SegmentSmack. Birinchi qon 2
Bulutda vaqtinchalik echimdan foydalanishni tushunishga vaqtimiz bo'lishidan oldin, foydalanuvchilardan birinchi nodir shikoyatlar kela boshladi. O'sha paytda, birinchi serverlarda vaqtinchalik echimdan foydalanish boshlanganidan beri bir necha hafta o'tdi. Dastlabki tergov shuni ko'rsatdiki, shikoyatlar ushbu xizmatlarning barcha serverlariga emas, balki alohida xizmatlarga nisbatan kelib tushgan. Muammo yana nihoyatda noaniq bo'lib qoldi.
Birinchidan, biz, albatta, Sysctl sozlamalarini orqaga qaytarishga harakat qildik, ammo bu hech qanday ta'sir ko'rsatmadi. Server va dastur sozlamalari bilan turli xil manipulyatsiyalar ham yordam bermadi. Qayta ishga tushirish yordam berdi. Linuxni qayta ishga tushirish eski kunlarda Windows uchun odatdagidek g'ayritabiiydir. Biroq, bu yordam berdi va biz Sysctl-da yangi sozlamalarni qo'llashda uni "yadrodagi nosozlik" deb belgiladik. Bu qanchalik bema'ni edi ...
Uch hafta o'tgach, muammo yana takrorlandi. Ushbu serverlarning konfiguratsiyasi juda oddiy edi: Nginx proksi/balanser rejimida. Trafik ko'p emas. Yangi kirish eslatmasi: mijozlarda 504 ta xatolik soni kundan-kunga ortib bormoqda (). Grafikda ushbu xizmat uchun kuniga 504 ta xatolik ko'rsatilgan:
Barcha xatolar taxminan bir xil backend - bulutdagi xato haqida. Ushbu backenddagi paket fragmentlari uchun xotira iste'moli grafigi quyidagicha ko'rinish oldi:
Bu operatsion tizim grafikalaridagi muammoning eng aniq ko'rinishlaridan biridir. Bulutda, xuddi shu vaqtda, QoS (Traffic Control) sozlamalari bilan bog'liq yana bir tarmoq muammosi tuzatildi. Paket fragmentlari uchun xotira iste'moli grafigida u xuddi shunday ko'rinardi:
Taxmin oddiy edi: agar ular grafiklarda bir xil ko'rinsa, unda bir xil sabab bor. Bundan tashqari, ushbu turdagi xotira bilan bog'liq har qanday muammolar juda kam uchraydi.
Ruxsat etilgan muammoning mohiyati shundan iboratki, biz QoS da standart sozlamalari bilan fq paketlarni rejalashtiruvchisidan foydalanganmiz. Odatiy bo'lib, bitta ulanish uchun u navbatga 100 ta paket qo'shish imkonini beradi va ba'zi ulanishlar, kanal etishmovchiligi holatlarida, navbatni sig'imga to'sib qo'yishni boshladi. Bunday holda, paketlar tushiriladi. Tc statistikasida (tc -s qdisc) buni quyidagicha ko'rish mumkin:
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" - bu bitta ulanishning navbat chegarasidan oshib ketganligi sababli o'chirilgan paketlar va "tushgan 464545" - bu rejalashtiruvchining barcha o'chirilgan paketlarining yig'indisi. Navbat uzunligini 1 mingga oshirib, konteynerlarni qayta ishga tushirgandan so'ng, muammo yuzaga kelmadi. Siz orqaga o'tirib, smeti ichishingiz mumkin.
FragmentSmack/SegmentSmack. Oxirgi qon
Birinchidan, yadrodagi zaifliklar e'lon qilinganidan bir necha oy o'tgach, nihoyat FragmentSmack uchun tuzatish paydo bo'ldi (sizga eslatib o'tamanki, avgust oyida e'lon bilan bir qatorda faqat SegmentSmack uchun tuzatish chiqarilgan), bu bizga vaqtinchalik echimdan voz kechish imkoniyatini berdi, bu bizga juda ko'p muammo tug'dirdi. Bu vaqt ichida biz ba'zi serverlarni yangi yadroga o'tkazishga muvaffaq bo'ldik va endi biz boshidan boshlashimiz kerak edi. Nima uchun biz FragmentSmack tuzatishni kutmasdan yadroni yangiladik? Gap shundaki, ushbu zaifliklardan himoya qilish jarayoni CentOS-ni yangilash jarayoniga to'g'ri keldi (va birlashtirildi) (bu faqat yadroni yangilashdan ko'ra ko'proq vaqt talab etadi). Bundan tashqari, SegmentSmack - bu yanada xavfli zaiflik va uni tuzatish darhol paydo bo'ldi, shuning uchun baribir mantiqiy edi. Biroq, biz CentOS-da yadroni oddiygina yangilay olmadik, chunki CentOS 7.5 paytida paydo bo'lgan FragmentSmack zaifligi faqat 7.6 versiyasida tuzatilgan, shuning uchun biz 7.5-ga yangilanishni to'xtatib, 7.6-ga yangilash bilan hammasini qaytadan boshlashimiz kerak edi. Va bu ham sodir bo'ladi.
Ikkinchidan, nodir foydalanuvchilarning muammolar haqida shikoyatlari bizga qaytib keldi. Endi biz ularning barchasi mijozlardan ba'zi serverlarimizga fayllarni yuklash bilan bog'liqligini aniq bilamiz. Bundan tashqari, ushbu serverlar orqali umumiy massadan juda oz miqdordagi yuklamalar o'tdi.
Yuqoridagi voqeadan eslaganimizdek, Sysctl-ni orqaga qaytarish yordam bermadi. Qayta ishga tushirish yordam berdi, lekin vaqtinchalik.
Sysctl bilan bog'liq shubhalar olib tashlanmadi, ammo bu safar iloji boricha ko'proq ma'lumot to'plash kerak edi. Shuningdek, nima sodir bo'layotganini aniqroq o'rganish uchun mijozga yuklash muammosini ko'paytirish qobiliyatining katta etishmasligi mavjud edi.
Mavjud bo'lgan barcha statistik ma'lumotlar va jurnallarni tahlil qilish bizni nima bo'layotganini tushunishga yaqinlashtirmadi. Muayyan aloqani "his qilish" uchun muammoni takrorlash qobiliyatining keskin etishmasligi mavjud edi. Va nihoyat, ishlab chiquvchilar dasturning maxsus versiyasidan foydalanib, Wi-Fi orqali ulanganda sinov qurilmasida muammolarni barqaror ko'paytirishga erishdilar. Bu tergovda yutuq bo'ldi. Mijoz Nginx-ga ulangan, u bizning Java ilovamiz bo'lgan backend-ga proksi-server orqali ulangan.
Muammolar bo'yicha dialog shunday edi (Nginx proksi-server tomonida o'rnatilgan):
- Mijoz: faylni yuklab olish haqida ma'lumot olishni so'rash.
- Java serveri: javob.
- Mijoz: fayl bilan POST.
- Java serveri: xato.
Shu bilan birga, Java-server jurnalga mijozdan 0 bayt ma'lumot olinganligini yozadi va Nginx proksi-serveri so'rov 30 soniyadan ko'proq vaqtni olganini yozadi (30 soniya - mijoz ilovasining kutish vaqti). Nima uchun kutish vaqti tugadi va nima uchun 0 bayt? HTTP nuqtai nazaridan, hamma narsa kerak bo'lganidek ishlaydi, lekin fayl bilan POST tarmoqdan yo'qolib ketganga o'xshaydi. Bundan tashqari, u mijoz va Nginx o'rtasida yo'qoladi. Tcpdump bilan qurollanish vaqti keldi! Lekin avval siz tarmoq konfiguratsiyasini tushunishingiz kerak. Nginx proksi-serveri L3 balanslagichining orqasida . Tunnellash L3 balanslagichidan paketlarni serverga etkazib berish uchun ishlatiladi, bu esa paketlarga sarlavhalarini qo'shadi:
Bunday holda, tarmoq ushbu serverga Vlan-belgilangan trafik ko'rinishida keladi, u ham paketlarga o'z maydonlarini qo'shadi:
Va bu trafik parchalanishi ham mumkin (kelishuvdan kelib chiqadigan xavflarni baholashda biz gaplashgan kiruvchi parchalangan trafikning bir xil kichik foizi), bu ham sarlavhalar mazmunini o'zgartiradi:
Yana bir bor: paketlar Vlan yorlig'i bilan qoplangan, tunnel bilan qoplangan, parchalangan. Bu qanday sodir bo'lishini yaxshiroq tushunish uchun keling, mijozdan Nginx proksi-serveriga paket yo'nalishini kuzatamiz.
- Paket L3 balanslagichiga etib boradi. Ma'lumotlar markazida to'g'ri marshrutlash uchun paket tunnelga o'raladi va tarmoq kartasiga yuboriladi.
- Paket + tunnel sarlavhalari MTU ga to'g'ri kelmaganligi sababli, paket bo'laklarga bo'linadi va tarmoqqa yuboriladi.
- L3 balanslagichidan keyingi kalit, paketni qabul qilganda, unga Vlan tegini qo'shadi va uni yuboradi.
- Nginx proksi-serverining oldidagi kalit (port sozlamalari asosida) server Vlan-kapsullangan paketni kutayotganini ko'radi, shuning uchun uni Vlan tegini olib tashlamasdan yuboradi.
- Linux alohida paketlarning bo'laklarini oladi va ularni bitta katta paketga birlashtiradi.
- Keyinchalik, paket Vlan interfeysiga etib boradi, u erda undan birinchi qatlam chiqariladi - Vlan inkapsulyatsiyasi.
- Keyin Linux uni Tunnel interfeysiga yuboradi, u erda undan boshqa qatlam olib tashlanadi - Tunnel inkapsulyatsiyasi.
Qiyinchilik bularning barchasini tcpdump-ga parametr sifatida o'tkazishdir.
Oxiridan boshlaylik: vlan va tunnel inkapsulyatsiyasi olib tashlangan mijozlardan toza (keraksiz sarlavhalarsiz) IP-paketlar bormi?
tcpdump host <ip клиента>
Yo'q, serverda bunday paketlar yo'q edi. Shunday qilib, muammo avvalroq bo'lishi kerak. Faqat Vlan inkapsulyatsiyasi olib tashlangan paketlar bormi?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx - hex formatidagi mijoz IP-manzili.
32:4 - Tunnel paketida SCR IP yozilgan maydonning manzili va uzunligi.
Maydon manzilini qo'pol kuch bilan tanlash kerak edi, chunki Internetda ular 40, 44, 50, 54 haqida yozadilar, ammo u erda IP-manzil yo'q edi. Shuningdek, siz hexdagi paketlardan biriga (tcpdump-dagi -xx yoki -XX parametri) qarashingiz va o'zingiz bilgan IP-manzilni hisoblashingiz mumkin.
Vlan va Tunnel inkapsulyatsiyasi olib tashlanmagan paket parchalari bormi?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Bu sehr bizga barcha qismlarni, shu jumladan oxirgisini ham ko'rsatadi. Ehtimol, xuddi shu narsa IP tomonidan filtrlanishi mumkin, lekin men sinab ko'rmadim, chunki bunday paketlar juda ko'p emas va menga kerak bo'lganlar umumiy oqimda osongina topilgan. Mana ular:
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 ..............
Bular bitta to'plamning ikkita bo'lagi (bir xil ID 53652) fotosurati bilan (birinchi paketda Exif so'zi ko'rinadi). Ushbu darajadagi paketlar mavjudligi sababli, lekin axlatxonalarda birlashtirilgan shaklda emas, muammo yig'ilishda aniq. Nihoyat, buning hujjatli dalillari bor!
Paket dekoderi qurilishga to'sqinlik qiladigan hech qanday muammolarni aniqlamadi. Bu erda sinab ko'rdim: . Avvaliga, u erda biror narsani to'ldirishga harakat qilganingizda, dekoder paket formatini yoqtirmaydi. Srcmac va Ethertype o'rtasida qo'shimcha ikkita oktet borligi ma'lum bo'ldi (parcha ma'lumotlariga aloqador emas). Ularni olib tashlaganingizdan so'ng, dekoder ishlay boshladi. Biroq, u hech qanday muammo ko'rsatmadi.
Kim nima desa bo'ladi, o'sha Sysctl-dan boshqa hech narsa topilmadi. Qolgan narsa o'lchovni tushunish va keyingi harakatlar to'g'risida qaror qabul qilish uchun muammoli serverlarni aniqlash yo'lini topish edi. Kerakli hisoblagich tezda topildi:
netstat -s | grep "packet reassembles failed”
Shuningdek, u snmpd da OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"IPni qayta yig'ish algoritmi tomonidan aniqlangan nosozliklar soni (har qanday sababga ko'ra: vaqt tugashi, xatolar va boshqalar)."
Muammo o'rganilgan serverlar guruhidan ikkitasida bu hisoblagich tezroq, ikkitasida sekinroq o'sdi va yana ikkitasida umuman ko'tarilmadi. Ushbu hisoblagichning dinamikasini Java serveridagi HTTP xatolar dinamikasi bilan solishtirish korrelyatsiyani aniqladi. Ya'ni, hisoblagichni kuzatish mumkin edi.
Muammolarning ishonchli ko'rsatkichiga ega bo'lish juda muhim, shuning uchun Sysctl-ni orqaga qaytarish yordam beradimi yoki yo'qligini aniq aniqlashingiz mumkin, chunki oldingi hikoyadan biz buni dasturdan darhol anglab bo'lmasligini bilamiz. Ushbu ko'rsatkich ishlab chiqarishdagi barcha muammoli joylarni foydalanuvchilar kashf qilishdan oldin aniqlash imkonini beradi.
Sysctl-ni orqaga qaytargandan so'ng, monitoring xatolar to'xtatildi, shuning uchun muammolarning sababi, shuningdek, orqaga qaytarish yordam berishi isbotlandi.
Biz boshqa serverlardagi parchalanish sozlamalarini qaytarib oldik, bu erda yangi monitoring o'ynadi va biron bir joyda biz fragmentlar uchun avvalgidan ko'ra ko'proq xotira ajratdik (bu UDP statistikasi edi, uning qisman yo'qolishi umumiy fonda sezilmadi). .
Eng muhim savollar
Nima uchun paketlar L3 balanslagichimizda bo'lingan? Foydalanuvchilardan balanschilarga keladigan paketlarning aksariyati SYN va ACK hisoblanadi. Ushbu paketlarning o'lchamlari kichik. Ammo bunday paketlarning ulushi juda katta bo'lganligi sababli, ularning fonida biz parchalana boshlagan katta paketlarning mavjudligini sezmadik.
Buning sababi buzilgan konfiguratsiya skripti edi Vlan interfeysli serverlarda (o'sha paytda ishlab chiqarishda yorliqli trafikka ega serverlar juda kam edi). Advmss mijozga bizning yo'nalishimizdagi paketlar hajmi kichikroq bo'lishi kerakligi haqidagi ma'lumotni etkazishga imkon beradi, shunda ularga tunnel sarlavhalarini biriktirgandan so'ng ular parchalanib ketmasligi kerak.
Nima uchun Sysctl ortga qaytarish yordam bermadi, lekin qayta ishga tushirish yordam berdi? Sysctl-ni orqaga qaytarish paketlarni birlashtirish uchun mavjud xotira hajmini o'zgartirdi. Shu bilan birga, fragmentlar uchun xotiraning to'lib ketishi haqiqati ulanishlarning sekinlashishiga olib keldi, bu esa fragmentlarning navbatda uzoq vaqt davomida kechiktirilishiga olib keldi. Ya'ni, jarayon tsikllarda o'tdi.
Qayta ishga tushirish xotirani tozaladi va hamma narsa tartibda bo'ldi.
Vaqtinchalik hal qilmasdan qilish mumkinmi? Ha, lekin hujum sodir bo'lgan taqdirda foydalanuvchilarni xizmatsiz qoldirish xavfi yuqori. Albatta, vaqtinchalik yechimdan foydalanish turli muammolarga, jumladan, foydalanuvchilar uchun xizmatlardan biri sekinlashishiga olib keldi, ammo shunga qaramay, biz harakatlarni oqladi deb hisoblaymiz.
Andrey Timofeevga katta rahmat () tergov o'tkazishda yordam uchun, shuningdek, Aleksey Krenev () - serverlardagi Centos va yadrolarni yangilash bo'yicha titanik ish uchun. Bu holda bir necha marta boshidan boshlanishi kerak bo'lgan jarayon, shuning uchun u ko'p oylar davom etdi.
Manba: www.habr.com