Hamınız salut! Mənim adım Dmitri Samsonov, mən «İnstaqram»da baş sistem administratoru olaraq çalışıram. Bizim 7 mindən çox fiziki serverimiz, 11 min konteynerimiz var və 200 proqram müxtəlif konfiqurasiyada 700 fərqli klaster təşkil edir. Serverlərin əksəriyyəti CentOS 7 altında işləyir.
2018-ci il avqustun 14-dən, FragmentSmack zəifliyi haqqında məlumat dərc edilib
() və SegmentSmack (). Bu, şəbəkə hücum vektoru ilə bağlı zəifliklərdir və kifayət qədər yüksək reytinqə (7.5) sahibdir, bu da resursların (CPU) tükənməsi səbəbindən xidmətin dayandırılması (DoS) təhlükəsi yaradır. O vaxt üçün FragmentSmack üçün nüvədə düzəliş təklif edilməmişdi, hətta bu zəiflik haqqında məlumat dərc edildikdən xeyli sonra yayımlandı. SegmentSmackı aradan qaldırmaq üçün nüvənin yenilənməsi tövsiyə edilmişdi. Yenilənmə paketi eyni gün təqdim edildi, sadəcə quraşdırmaq lazım idi.
Xeyr, biz nüvənin yenilənməsi əleyhinə deyilik! Lakin bəzi məsələlər var...
İstehsalda nüvəni necə yeniləyirik
Bütün bunlar asandır:
- Paketləri yükləmək;
- Onları bir neçə serverə (buludumuzu hosting edən serverlər də daxil olmaqla) quraşdırmaq;
- Heç nəyin sındığını yoxlamaq;
- Bütün standart nüvə parametrlərinin səhvsiz tətbiq olunduğuna əmin olmaq;
- Bir neçə gün gözləmək;
- Serverlərin göstəricilərini yoxlamaq;
- Yeni serverlərin yerləşdirilməsini yeni nüvəyə keçirmək;
- Bütün datacenterlərdə (bir datacenter bir dəfə) serverləri yeniləmək, istifadəçilər üçün problemlər yarandığı halda təsiri minimuma endirmək üçün;
- Bütün serverləri yenidən başlatmaq.
Bizim olan nüvələrin bütün budaqları üçün təkrarlamaq. Hal-hazırda bunlardır:
- Standard CentOS 7 3.10 - əksər adi serverlər üçün;
- Vanilla 4.19 - bizim çünki bizə BFQ, BBR və s. lazımdır;
- Elrepo kernel-ml 5.2 - çünki 4.19 əvvəllər qeyri-sabit davranırdı, lakin eyni xüsusiyyətlər lazım idi.
Təxmin etdiyiniz kimi, minlərlə serverin yenidən başladılması ən çox vaxt alır. Bütün zəifliklər hər bir server üçün kritik olmadığından, yalnız İnternetə birbaşa bağlı olanları yenidən başladırıq. Buludda, elastikliyi məhdudlaşdırmamaq üçün xaricdən əlçatan konteynerləri yeni kernel ilə ayrı serverlərə bağlamırıq, bütün ev sahiblərini istisnasız olaraq yenidən başlayırıq. Xoşbəxtlikdən, orada prosedur adi serverlərdən daha asandır. Məsələn, stateless-konteynerlər reboot zamanı sadəcə olaraq başqa serverə köçürülə bilər.
Bununla belə, iş hələ də çoxdur və bu, bir neçə həftə çəkə bilər, yeni versiyada hər hansı bir problem yaranarsa, bir neçə aya qədər uzana bilər. Zərərli istifadəçilər bunu yaxşı başa düşür, buna görə də «B planı» lazımdır.
FragmentSmack/SegmentSmack. İş əvəzləməsi
Xoşbəxtlikdən, bəzi zəifliklər üçün belə bir «B planı» mövcuddur və buna İş əvəlizməsi (Workaround) deyilir. Çox vaxt bu, zəifliklərin təsirini minimuma endirmək və ya tamamilə istismarını istisna etmək üçün kernel/tətbiq tənzimləmələrinin dəyişdirilməsidir.
FragmentSmack/SegmentSmack halında belə bir İş əvəlizməsi:
«İlk 4MB və 3MB dəyərlərini net.ipv4.ipfrag_high_thresh və net.ipv4.ipfrag_low_thresh (və onların ipv6 analoqları net.ipv6.ipfrag_high_thresh və net.ipv6.ipfrag_low_thresh) 256 kB və 192 kB ilə müvafiq olaraq dəyişdirmək olar. Testlər, avadanlıq, tənzimləmələr və şərtlərə görə hücum zamanı CPU istifadəsinin azaldığına dair azdan çoxa qədər dəyişən nəticələri göstərir. Lakin, ipfrag_high_thresh=262144 bayt olduğu üçün, yalnız iki 64K-fragmentin eyni anda yenidən qurma növbəsində yerləşə biləcəyi üçün performansa müəyyən təsir ola bilər. Məsələn, böyük UDP paketləri ilə işləyən tətbiqlərin sıradan çıxma riski var.».
Öz parametrləri belə izah edilir:
ipfrag_high_thresh - UZUN TAM ədədi
IP parçalarını yenidən birləşdirmək üçün maksimum istifadə olunan yaddaş.
ipfrag_low_thresh - UZUN TAM ədəd
Kernel-dən əvvəl IP parçamalarının bərpa edilməsi üçün maksimum istifadə olunan yaddaş
resursları sərbəst buraxmaq üçün tamamlanmamış parçaların növbələrini silməyə başlayır.
Kernel hələ də defragmentasiya üçün yeni parçaları qəbul edir.
Böyük UDP-prodüksiyalarımız yoxdur. LAN-da fraksiyalaşdırılmış trafik yoxdur, WAN-da var, amma əhəmiyyətli deyil. Heç bir təhlükə görünmür - İş əvəlizməsini tətbiq etmək olar!
FragmentSmack/SegmentSmack. İlk qan
İlk problem, bulut kapsayıcılarının bazen yeni ayarları yalnızca kısmen (sadece ipfrag_low_thresh) uygulaması, bazen ise hiç uygulamamasıydı — başlangıçta çökmekteydi. Problemi sürekli olarak yeniden üretmek mümkün olmadı (tüm ayarlar elle sorunsuz bir şekilde uygulanıyordu). Kapsayıcının başlangıçta neden çöktüğünü anlamak da o kadar kolay değildi: hiçbir hata tespit edilmedi. Kesin olarak bilinen bir şey vardı: ayarların geri alınması, kapsayıcıların çökme problemini çözüyordu.
Neden hostta Sysctl uygulamak yeterli değil? Kapsayıcı, kendi ayrılmış ağ Namespace'inde yaşadığı için, en azından kapsayıcıda hosttan farklı olabilir.
Kapsayıcıda Sysctl ayarları nasıl uygulanır? Kapsayıcılarımız ayrıcalıksız olduğundan, kapsayıcıya girerek herhangi bir Sysctl ayarını değiştirmek mümkün değil — haklar yeterli değildir. O dönemde kapsayıcıları başlatmak için bulutumuz Docker kullanıyordu (şimdi artık ). Docker'a API üzerinden yeni kapsayıcının parametreleri, gereken Sysctl ayarları da dahil olmak üzere, iletiliyordu.
Sürümleri gözden geçirirken, Docker API'sinin tüm hataları geri vermediği anlaşıldı (en azından 1.10 sürümünde). “docker run” ile kapsayıcıyı başlatmaya çalıştığımızda, nihayet bir şey gördük:
write /proc/sys/net/ipv4/ipfrag_high_thresh: geçersiz argüman docker: Daemon'dan hata yanıtı: Kapsayıcı başlatılamadı <...>: [9] Sistem hatası: kapsayıcı süreciyle senkronize olamıyor.
Parametre değeri geçersiz. Ama neden? Ve neden sadece bazen geçersiz? Docker, Sysctl parametrelerinin uygulama sırasını garanti etmemektedir (son kontrol edilen sürüm — 1.13.1), bu nedenle bazen ipfrag_high_thresh, ipfrag_low_thresh hala 3M iken 256K olarak ayarlanmaya çalışıyordu, yani üst sınır alt sınırdan daha düşük olduğu için hata meydana geliyordu.
O dönemde zaten kapsayıcının başlatma sonrası konfigürasyonu için kendi mekanizmamız vardı (kapsayıcının dondurulması aracılığıyla ve kapsayıcı namespace'inde komutların yürütülmesi aracılığıyla ), ve bu bölüme Sysctl parametrelerini yazmayı da ekledik. Problem çözüldü.
FragmentSmack/SegmentSmack. İlk kan 2
Biz Workaround-in buludakı tətbiqi ilə məşğul olmamışdıq ki, istifadəçilərdən ilk nadir şikayətlər gəldi. Həmin vaxt Workaround-ın ilk serverlərdə tətbiq olunmasının üzündən bir neçə həftə keçmişdi. İlk araşdırma göstərdi ki, şikayətlər ayrı-ayrı xidmətlərə gəlib, bu xidmətlərin bütün serverlərinə deyil. Problemin mahiyyəti yenidən olduqca qeyri-müəyyən xarakter aldı.
Hər şeydən əvvəl, əlbəttə, Sysctl parametrlərini geri qaytarmağı sınadıq, amma bunun heç bir effekti olmadı. Server və tətbiq parametrləri ilə fərqli manipulyasiyalar da kömək etmədi. Yenidən başlatma kömək etdi. Linux üçün yenidən başlatma, Windows ilə işləmə şərti olduğu dövrlərdə olduğu qədər əksinədir. Buna baxmayaraq, bu, kömək etdi və biz bunu Sysctl-da yeni parametrlərin tətbiqi zamanı «nüvədəki səhv» ilə əlaqələndirdik. Bu, nə qədər yüngül başa gəlmişdi...
Üç həftədən sonra problem yenidən təkrarlandı. Bu serverlərin konfiqurasiyası olduqca sadə idi: Nginx proxy/balanser rejimində. Trafik azdır. Yeni bir məlumat: müştərilərdə günbəgün 504 səhvlərinin sayı artır.). Qrafikdə bu xidmətlə bağlı gündəlik 504 səhv sayını göstərir:
Bütün səhvlər eyni backend-ə aiddir — buludda olan backend-ə. Bu backend üzrə paket fraksiyaları üçün yaddaş istehlakının qrafiki aşağıdakı kimidir:
Bu, əməliyyat sisteminin qrafiklərində problemin ən parlak təzahürlərindən biridir. Buludda eyni zamanda QoS (Traffic Control) parametrlərində digər şəbəkə probleminin həlli olunmuşdu. Paket fraksiyaları üçün yaddaş istehlakının qrafiki də belə görünürdü:
Təxmin sadə idi: əgər qrafiklər eyni görünürsə, o zaman səbəbləri də eyni olmalıdır. Üstəlik, bu tip yaddaşla bağlı problemlər olduqca nadir baş verir.
Həll olunan problemin mahiyyəti, biz QoS-da defolt parametrlərlə fq paket cədvəlindən istifadə etdiyimizdir. Defolt olaraq, bir əlaqə üçün 100 paketin növbəyə daxil edilməsinə icazə verir və bəzi əlaqələr kanal çatışmazlığı vəziyyətində sıxlığı artırıb növbəni doldururlar. Bu halda paketlər atılır. Statistikada tc (tc -s qdisc) bunu belə göstərir:
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
Göndərildi 454701676345 bayt 491683359 pkt (kəsilmiş 464545, hədd aşılması 0, yenidən sıralama 0)
geri qalmış 0b 0p yenidən sıralama 0
1024 axın (1021 qeyri-aktiv, 0 məhdudlaşdırılmış)
0 gc, 0 yüksək prioritet, 0 məhdudlaşdırılmış, 464545 axın_plimit
«464545 flows_plimit» — bu, bir əlaqənin sıradakı həddi aşdığı üçün ixrac edilmiş paketlərdir, «dropped 464545» isə bu şedulerin ixrac etdiyi bütün paketlərin cəmini nəzərdə tutur. Növbənin uzunluğunu 1 minə artırdıqdan və konteynerləri yenidən başladıqdan sonra problem tamamilə aradan qaldırıldı. İndi oturub smuzi içmək olar.
FragmentSmack/SegmentSmack. Son qan
Birincisi, kernel-dəki zəifliklərin açıqlanmasından bir neçə ay sonra, nəhayət ki, FragmentSmack üçün bir düzəliş ortaya çıxdı (avqustda təqdim olunan SegmentSmack üçün yalnız bir düzəliş çıxdığını xatırladaq), bu da bizə bizə bir sıra narahatlıqlara səbəb olan Workaround-dan imtina etməyə imkan verdi. Bu müddətdə bəzi serverləri artıq yeni kernelə keçirdik və indi hər şeyi yenidən başlamaq lazım idi. Niyə FragmentSmack düzəlişini gözləmədən kernelimizi yenilədik? Məsələ burasındadır ki, bu zəifliklərdən qorunma prosesi (və birləşdi) CentOS-un özünün yeniləmə prosesi ilə üst-üstə düşdü (bu da yalnız kernel yeniləməsindən daha çox vaxt aparır). Üstəlik, SegmentSmack daha təhlükəli bir zəiflikdir, düzəlişi də dərhal ortaya çıxdı, bu səbəbdən bu vəziyyətdə mənası var idi. Lakin, CentOS-da sadəcə kernel yeniləməsi edə bilmədik, çünki CentOS 7.5 dövründə meydana gələn FragmentSmack zəifliyi yalnız 7.6 versiyasında düzəldilib, buna görə 7.5-ə yeniləməni dayandırmalı və 7.6-ya yeniləməyə yenidən başlamalı olduq. Bunun da baş verməsi mümkündür.
İkincisi, istifadəçilərdən nadir şikayətlər geri döndü. İndi məlumdur ki, bunların hamısı müştərilərin bəzi serverlərimizə fayl yükləmələri ilə bağlıdır. Üstəlik, bu serverlərdən yalnız az miqdarda yükləmə olub.
Yuxarıda verdiyimiz hekayədən xatırladığımız kimi, Sysctl-in geri qaytarılması kömək etmədi. Reboot kömək etdi, lakin müvəqqəti.
Sysctl ilə bağlı şübhələr aradan qaldırılmadı, lakin bu dəfə daha çox məlumat toplamaq lazım idi. Həmçinin, müştəridə yükləmə problemini təkrarlama imkanının olmaması olduqca narahat edirdi, beləliklə, baş verənləri daha dəqiq öyrənmək üçün daha yaxşı bir mühit yaratmaq mümkün olsaydı.
Mövcud bütün statistikalar və loqlarla analiz edilməsi başa düşməyimizi irəlilətmədi. Problemi yenidən yaratmaq, konkret əlaqəni "hiss etmək" imkanı sərt şəkildə çatışmadı. Nəhayət, tətbiqin xüsusi versiyasındakı inkişafçılar Wi-Fi ilə qoşulma zamanı test cihazında problemlərin sabit şəkildə təkrarlanmasını bacardılar. Bu, araşdırmada bir irəliləyiş oldu. Müştəri Nginx-ə qoşulmuşdu, Nginx isə backend olaraq bizim Java tətbiqini proksiləşdirdi.
Problemlər zamanı dialoq belə oldu (Nginx-proksi tərəfində qeydə alınmışdır):
- Müştəri: dosyanın yüklənməsi haqqında məlumat müraciəti.
- Java-server: cavab.
- Müştəri: fayl ilə POST.
- Java-server: xəta.
Java-server bu zaman loga 0 bayt məlumat aldığına dair yazır, Nginx-proksi isə sorğunun 30 saniyədən çox davam etdiyini bildirir (30 saniyə müştəri tətbiqi üçün zaman aşımıdır). Bəs niyə zaman aşımı və niyə 0 bayt? HTTP nöqteyi-nəzərindən hər şey doğru çalışır, lakin fayl ilə POST sanki şəbəkədən itir. Üstəlik, müştəri ilə Nginx arasında itir. Tcpdump ilə silahlanmağın vaxtıdır! Ancaq əvvəlcə şəbəkə konfiqurasiyasını başa düşmək lazımdır. Nginx-proksi L3-balanslaşdırıcısının arxasındadır. . Paketin L3 balanslaşdırıcısından serverə çatdırılması üçün tunel istifadə olunur və bu tunel paketlərə öz başlıqlarını əlavə edir:
Eyni zamanda, bu serverə yönəldilən şəbəkə VLAN-təhlükəsiz trafiki şəklində gəlir, bu da paketlərə öz sahələrini əlavə edir:
Həm də bu trafik fraksiyalaşır (Riskləri qiymətləndirərkən qeyd etdiyimiz o kiçik fraksiyalaşmış trafik faizi), bu da başlıqların içəriklərini dəyişdirir:
Bir daha: paketlər VLAN-tags, tunel tərəfindən encapsulated, fraksiyalaşdırılmış. Bu prosesin necə baş verdiyini daha dəqiq anlamaq üçün paketin müştəridən Nginx-proksiyə qədər marşrutunu izləyək.
- Paket L3-balanslaşdırıcısına daxil olur. Məlumat mərkəzinin daxilində düzgün marşrutlaşdırma üçün paket tunelə əlavə olunur və şəbəkə kartına göndərilir.
- Paket + tunel başlıqları MTU-nun içərisinə sığmır, ona görə də paket fraksiyalara bölünür və şəbəkəyə göndərilir.
- L3-balanslaşdırıcısının ardından switch paket alanda ona VLAN-dəqiqlik əlavə edir və onu irəliləyir.
- Nginx-proxy qarşısında switch (portun konfiqurasiyasına əsasən) serverin Vlan-encapsulation paketi gözlədiyini görür, buna görə onu olduğu kimi göndərir, Vlan etiketi silinmir.
- Linux ayrı-ayrı paketlərin hissələrini alır və bunları bir böyük pakətdə birləşdirir.
- Daha sonra paket Vlan-interfeysinə daxil olur, burada ilk qat — Vlan-encapsulation çıxarılır.
- Sonra Linux onu Tunnel-interfeysinə göndərir, burada daha bir qat — Tunnel-encapsulation çıxarılır.
Çətinlik ondadır ki, bütün bunları tcpdump-da parametrler şəklində ötürmək lazımdır.
Sondan başlayaq: müştərilərdən təmiz (əlavə başlıqlardan tamamilə azad) IP paketləri, Vlan- və tunnel-encapsulation çıxarılmış mı?
tcpdump host
Xeyr, serverdə belə paketlər olmayıb. Beləliklə, problem daha əvvəldir. Yalnız Vlan-encapsulation çıxarılmış paketlər varmı?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx — bu, müştərinin hex-formatda IP ünvanıdır.
32:4 — Tunnel-paketində SCR IP yazılmış sahənin adresi və uzunluğudur.
Sahənin adresini tapmaq üçün sınaq vasitəsi ilə axtarış etməli olduq, çünki internetdə 40, 44, 50, 54 ilə bağlı yazılar var, amma orada IP ünvanları yox idi. Eyni zamanda, tcpdump-da paketlərin birini hex formatında (parametr -xx və ya -XX) baxaraq tanıdığınız IP-yə uyğun olan adresi hesablaya bilərsiniz.
Vlan- və Tunnel-encapsulation çıxarılmamış paketlərin hissələri varmı?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Bu magiya bizə, o cümlədən sonuncunu, bütün hissələri göstərəcək. Yəqin ki, IP üzrə filtrasiya da edilə bilər, amma mən cəhd etməmişəm, çünki belə paketlər çox deyil və ümumi axında mənim üçün lazım olanlar asanlıqla tapıldı. Budur onlar:
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 .faEE.....@.2.m.
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 Bütün kubelet’lərdə..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 ......
Bu, eyni paketin (eyni ID 53652) iki hissəsidir, bir şəkil ilə (ilk paketin içində Exif sözü görünür). Bu səviyyədə paketlər olsa da, birləşdirilmiş formada dump-larda yoxdur, buna görə problem açıq-aydın yazılışdədir. Nəhayət, bunun sənədli bir təsdiqi var!
Paket decoder-i birləşməyə mane olan heç bir problem aşkar etmədi. Burada cəhd etdim: . İlk olarak, oraya bir şey koymaya çalıştığımızda, dekodere paket formatı pek hoş gelmedi. Görünüşe göre Srcmac ile Ethertype arasında bilgiyi ilgilendirmeyen iki fazladan oktet vardı. Onları sildikten sonra dekoder çalıştı. Ancak herhangi bir sorun bildirmedi.
İster inanın, ister inanmayın, o Sysctl dışında başka bir şey bulunmadı. Sorunlu sunucuları belirlemenin bir yolunu bulmamız gerekti ki, sorunun büyüklüğünü anlayabilelim ve sonraki adımlarımızı belirleyelim. İhtiyacımız olan sayacı yeterince hızlı buldum:
netstat -s | grep "packet reassembles failed”
Bu SNMP'de OID=1.3.6.1.2.1.4.31.1.1.16.1 altında mevcut ().
«IP yeniden birleştirme algoritması tarafından tespit edilen başarısızlık sayısı (her ne sebeple olursa olsun: zaman aşımı, hatalar vb.)».
Sorun üzerinde çalışılan sunucu grubu arasında, iki sunucuda bu sayacın artışı daha hızlıydı, iki sunucuda daha yavaş, diğer iki sunucuda ise hiç artış gözlemlenmedi. Bu sayacın dinamiklerinin Java sunucusundaki HTTP hatalarının dinamikleriyle karşılaştırılması bir korelasyon ortaya çıkardı. Yani, bu sayacı izleme için yerleştirmek mümkün oldu.
Sorunların güvenilir bir göstergesinin varlığı çok önemlidir, Sysctl geri alma işleminin gerçekten işe yarayıp yaramadığını kesin bir şekilde belirlemek için. Önceki anlatımdan bildiğimiz gibi bu uygulamadan hemen anlaşılamaz. Bu gösterge, kullanıcılar tarafından keşfedilmeden önce, üretim ortamındaki tüm sorunlu noktaları ortaya çıkarmamıza olanak tanıyacaktır.
Sysctl geri alındıktan sonra izleme hataları durdu, bu nedenle sorunların nedeni kanıtlanmış oldu ve geri almanın yardımcı olduğu da gösterildi.
Yeni izleme belirlendikten sonra diğer sunuculardaki parçalama ayarlarını geri aldık, bazı yerlerde parçalar için varsayılan ayardan daha fazla bellek bile ayırdık (bu UDP istatistikleri, kaybı genel görüntüde fark edilmeden yapılan bir işlemdi).
En önemli sorular
L3 yük dengeleyicimizde paketlerin neden parçalandığını anlamak çok önemli. Yük dengeleyicilere gelen paketlerin çoğunluğu SYN ve ACK'dir. Bu paketlerin boyutları küçüktür. Ancak bu tür paketlerin yüksek oranda olması nedeniyle, büyük paketlerin parçalandığını fark edemedik.
Sebep bozulmuş bir yapılandırma betiği oldu Vlan interfeysi olan serverlərdə (təsadüfi trafik etiketlənməsi olan serverlərin istehsalda sayı çox az idi). Advmss müştəriyə paketlərin bizim tərəfə daha kiçik ölçüdə olmalı olduğunu çatdırmağa imkan tanıyır ki, tunel başlıqları yapışdırıldıqda onları parçalara ayırmağa ehtiyac yaranmasın.
Niyə Sysctl-dan geri qayıtma kömək etmirdi, amma yenidən işə salma kömək edirdi? Sysctl-dan geri qayıtma paketlərin yığılması üçün mövcud olan yaddaş həcmini dəyişdirirdi. Bununla yanaşı, görünən odur ki, parça üçün yaddaşın dolması, əlaqələrin yavaşlamasına səbəb olurdu ki, bu da parçaların uzun müddət növbədə gecikməsinə gətirib çıxarırdı. Yəni proses öz-özünə təkrar olunurdu.
Yenidən işə salma yaddaşı sıfırlayırdı və hər şey qaydasına düşürdü.
Workaround olmadan mümkündümü? Bəli, amma hücum zamanı istifadəçiləri xidmətlərdən məhrum etmə riski var idi. Əlbəttə ki, Workaround istifadəsi nəticəsində müxtəlif problemlərin, o cümlədən istifadəçilərdəki xidmətlərdən birinin yavaşlamasının ortaya çıxmasına səbəb oldu, lakin hər halda, etdiyimiz hərəkətlərin düzgün olduğunu düşünürük.
Andrey Timofeyevə () araşdırma aparmaqda kömək etdiyi üçün böyük təşəkkürlər, eləcə də Aleksey Krenyova () — serverlərdə Centos və nüvələrin yenilənməsi üzrə titanika bərabər iş üçün. Bu proses bir neçə dəfə sıfırdan başlamaq zərurəti ilə uzandığı üçün çox il sürdü.
Mənbə: habr.com
