🥇İş dövrlərini gətirən zəifliklərdən çəkinin. Hissə 1: FragmentSmack/SegmentSmack

Hamıya salam! Mənim adım Dmitri Samsonov, Odnoklassniki-də aparıcı sistem administratoru kimi işləyirəm. Bizim 7 mindən çox fiziki serverimiz, buludumuzda 11 min konteynerimiz və müxtəlif konfiqurasiyalarda 200 müxtəlif klaster təşkil edən 700 proqramımız var. Serverlərin böyük əksəriyyəti CentOS 7 ilə işləyir.
14 avqust 2018-ci ildə FragmentSmack zəifliyi haqqında məlumat dərc olundu.
(CVE-2018-5391) və SegmentSmack (CVE-2018-5390). Bunlar şəbəkə hücumu vektoru və kifayət qədər yüksək (7.5) balı olan zəifliklərdir ki, bu da resurs tükənməsi (CPU) səbəbindən xidmətdən imtina (DoS) təhlükəsi yaradır. FragmentSmack üçün kernel düzəlişi o zaman təklif edilməmişdi, üstəlik, bu, zəiflik haqqında məlumatın dərcindən çox gec ortaya çıxdı. SegmentSmack-i aradan qaldırmaq üçün nüvəni yeniləmək təklif edildi. Yeniləmə paketinin özü eyni gündə buraxıldı, qalan yalnız onu quraşdırmaq idi.
Xeyr, biz nüvənin yenilənməsinin qətiyyən əleyhinə deyilik! Ancaq nüanslar var ...

İstehsalda nüvəni necə yeniləyirik

Ümumiyyətlə, mürəkkəb bir şey yoxdur:

Paketləri yükləyin;
Onları bir sıra serverlərə quraşdırın (buludumuzu yerləşdirən serverlər də daxil olmaqla);
Heç bir şeyin pozulmadığından əmin olun;
Bütün standart nüvə parametrlərinin səhvsiz tətbiq olunduğundan əmin olun;
Bir neçə gün gözləyin;
Server performansını yoxlayın;
Yeni serverlərin yerləşdirilməsini yeni nüvəyə keçirin;
Bütün serverləri məlumat mərkəzinə görə yeniləyin (problemlər zamanı istifadəçilərə təsirini minimuma endirmək üçün hər dəfə bir məlumat mərkəzi);
Bütün serverləri yenidən başladın.

Bizdə olan ləpələrin bütün budaqları üçün təkrarlayın. Hazırda belədir:

Stock CentOS 7 3.10 - əksər adi serverlər üçün;
Vanil 4.19 - bizim üçün tək buludlu buludlar, çünki bizə BFQ, BBR və s. lazımdır;
Elrepo kernel-ml 5.2 - üçün yüksək yüklü distribyutorlar, çünki 4.19 əvvəllər qeyri-sabit davranırdı, lakin eyni xüsusiyyətlərə ehtiyac var.

Təxmin etdiyiniz kimi, minlərlə serverin yenidən işə salınması ən uzun vaxt tələb edir. Bütün boşluqlar bütün serverlər üçün kritik olmadığından, biz yalnız İnternetdən birbaşa istifadə edilə bilənləri yenidən işə salırıq. Buludda çevikliyi məhdudlaşdırmamaq üçün biz xaricdən əldə edilə bilən konteynerləri yeni kernellə fərdi serverlərə bağlamırıq, lakin istisnasız olaraq bütün hostları yenidən işə salırıq. Xoşbəxtlikdən, orada prosedur adi serverlərlə müqayisədə daha sadədir. Məsələn, vətəndaşlığı olmayan konteynerlər yenidən yükləmə zamanı sadəcə başqa serverə keçə bilər.

Bununla belə, hələ də çox iş var və bu, bir neçə həftə çəkə bilər, yeni versiya ilə bağlı hər hansı problem olarsa, bir neçə aya qədər. Hücumçular bunu çox yaxşı başa düşürlər, ona görə də onlara B planı lazımdır.

FragmentSmack/SegmentSmack. Çözüm

Xoşbəxtlikdən, bəzi zəifliklər üçün belə bir B planı mövcuddur və bu, Çözüm adlanır. Çox vaxt bu, mümkün effekti minimuma endirən və ya zəifliklərin istismarını tamamilə aradan qaldıra bilən nüvə/tətbiq parametrlərində dəyişiklikdir.

FragmentSmack/SegmentSmack vəziyyətində təklif edildi bu Çözüm:

«Siz net.ipv4.ipfrag_high_thresh və net.ipv3.ipfrag_low_thresh (və onların ipv4 net.ipv4.ipfrag_high_thresh və net.ipv6.ipfrag_low_thresh üçün analoqları) proqramlarında 6MB və 6MB standart dəyərlərini müvafiq olaraq 256 kB-a dəyişə bilərsiniz. aşağı. Testlər aparat, parametrlər və şərtlərdən asılı olaraq hücum zamanı CPU istifadəsində kiçikdən əhəmiyyətli dərəcədə azalma göstərir. Bununla belə, ipfrag_high_thresh=192 bayt səbəbindən performansa müəyyən təsirlər ola bilər, çünki eyni anda yalnız iki 262144K fraqment yenidən yığma növbəsinə sığa bilər. Məsələn, böyük UDP paketləri ilə işləyən proqramların pozulma riski var.

Parametrlərin özləri nüvə sənədlərində aşağıdakı kimi təsvir edilmişdir:

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.

İstehsal xidmətlərində böyük UDP-lərimiz yoxdur. LAN-da parçalanmış trafik yoxdur; WAN-da parçalanmış trafik var, lakin əhəmiyyətli deyil. Heç bir əlamət yoxdur - Çözüm yollarını işə sala bilərsiniz!

FragmentSmack/SegmentSmack. Birinci qan

Qarşılaşdığımız ilk problem, bulud konteynerlərinin bəzən yeni parametrləri yalnız qismən tətbiq etməsi (yalnız ipfrag_low_thresh), bəzən isə ümumiyyətlə tətbiq etməməsi idi - sadəcə başlanğıcda qəzaya uğradılar. Problemi sabit şəkildə təkrarlamaq mümkün olmadı (bütün parametrlər heç bir çətinlik olmadan əl ilə tətbiq olundu). Konteynerin başlanğıcda niyə qəzaya uğradığını anlamaq da o qədər də asan deyil: heç bir səhv tapılmadı. Bir şey dəqiq idi: parametrlərin geri qaytarılması konteyner qəzaları ilə bağlı problemi həll edir.

Niyə hostda Sysctl tətbiq etmək kifayət deyil? Konteyner öz xüsusi şəbəkə Ad məkanında yaşayır, buna görə də ən azı şəbəkə Sysctl parametrlərinin bir hissəsidir konteynerdə olanlar ev sahibindən fərqli ola bilər.

Sysctl parametrləri konteynerdə tam olaraq necə tətbiq olunur? Konteynerlərimiz imtiyazsız olduğundan, konteynerin özünə daxil olmaqla heç bir Sysctl parametrini dəyişə bilməyəcəksiniz - sadəcə olaraq kifayət qədər hüquqlarınız yoxdur. Konteynerləri işə salmaq üçün o vaxt buludumuz Docker-dən (indi podman). Yeni konteynerin parametrləri lazımi Sysctl parametrləri daxil olmaqla API vasitəsilə Docker-ə ötürüldü.
Versiyaları araşdırarkən məlum oldu ki, Docker API bütün xətaları qaytarmayıb (ən azı 1.10 versiyasında). Konteyneri “docker run” vasitəsilə işə salmağa çalışarkən nəhayət, heç olmasa bir şey gördük:

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 dəyəri etibarlı deyil. Bəs niyə? Və niyə yalnız bəzən keçərli deyil? Məlum oldu ki, Docker Sysctl parametrlərinin tətbiq olunma qaydasına zəmanət vermir (ən son sınaqdan keçmiş versiya 1.13.1-dir), buna görə də bəzən ipfrag_low_thresh hələ 256M olanda ipfrag_high_thresh 3K-a təyin olunmağa çalışırdı, yəni yuxarı hədd daha aşağı idi. səhvə səbəb olan aşağı hədddən artıqdır.

O zaman biz artıq işə başladıqdan sonra konteyneri yenidən konfiqurasiya etmək üçün öz mexanizmimizdən istifadə edirdik (konteyneri dondurduqdan sonra). qrup dondurucu vasitəsilə konteynerin ad məkanında əmrlərin yerinə yetirilməsi ip netns) və biz bu hissəyə Sysctl yazı parametrlərini də əlavə etdik. Problem həll olundu.

FragmentSmack/SegmentSmack. İlk qan 2

Buludda Workaround istifadəsini başa düşməyə vaxtımız olmamışdan əvvəl istifadəçilərdən ilk nadir şikayətlər gəlməyə başladı. O zaman ilk serverlərdə Workaround istifadə etməyə başlamasından bir neçə həftə keçmişdi. İlkin araşdırma göstərib ki, şikayətlər bu xidmətlərin bütün serverləri deyil, ayrı-ayrı xidmətlər üzrə daxil olub. Problem yenidən son dərəcə qeyri-müəyyənləşdi.

İlk növbədə, biz, əlbəttə ki, Sysctl parametrlərini geri qaytarmağa çalışdıq, lakin bunun heç bir təsiri olmadı. Server və proqram parametrləri ilə müxtəlif manipulyasiyalar da kömək etmədi. Yenidən yükləmə kömək etdi. Linux-u yenidən yükləmək köhnə günlərdə Windows üçün normal olduğu kimi qeyri-təbiidir. Bununla belə, bu kömək etdi və biz Sysctl-də yeni parametrləri tətbiq edərkən onu “ləpə xətası” adlandırdıq. Nə qədər mənasız idi...

Üç həftə sonra problem təkrarlandı. Bu serverlərin konfiqurasiyası olduqca sadə idi: Nginx proxy/balanslaşdırıcı rejimində. Çox trafik yoxdur. Yeni giriş qeydi: müştərilərlə bağlı 504 səhvin sayı hər gün artır (Gateway Timeout). Qrafik bu xidmət üçün gündə 504 səhvin sayını göstərir:

Bütün səhvlər təxminən eyni backenddir - buludda olan haqqında. Bu arxa tərəfdəki paket fraqmentləri üçün yaddaş istehlakı qrafiki belə görünürdü:

Bu, əməliyyat sistemi qrafiklərində problemin ən bariz təzahürlərindən biridir. Buludda, eyni zamanda, QoS (Traffic Control) parametrləri ilə bağlı başqa bir şəbəkə problemi həll edildi. Paket fraqmentləri üçün yaddaş istehlakı qrafikində tamamilə eyni görünürdü:

Fərziyyə sadə idi: əgər onlar qrafiklərdə eyni görünürsə, deməli, onların da səbəbi eynidir. Üstəlik, bu tip yaddaşla bağlı hər hansı problem olduqca nadirdir.

Sabit problemin mahiyyəti ondan ibarət idi ki, biz QoS-də standart parametrlərlə fq paket planlaşdırıcısından istifadə etdik. Varsayılan olaraq, bir əlaqə üçün növbəyə 100 paket əlavə etməyə imkan verir və bəzi bağlantılar, kanal çatışmazlığı vəziyyətlərində növbəni tutumla bağlamağa başladı. Bu vəziyyətdə paketlər atılır. tc statistikasında (tc -s qdisc) bunu belə görmək olar:

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” bir əlaqənin növbə limitini aşdığına görə atılan paketlərdir və “düşmüş 464545” bu planlaşdırıcının bütün buraxılmış paketlərinin cəmidir. Növbə uzunluğunu 1 minə qədər artırdıqdan və konteynerləri yenidən işə saldıqdan sonra problem baş vermədi. Arxaya oturub smoothie içə bilərsiniz.

FragmentSmack/SegmentSmack. Son Qan

Birincisi, nüvədəki zəifliklərin elanından bir neçə ay sonra, nəhayət, FragmentSmack üçün bir düzəliş ortaya çıxdı (xatırlatmaq istərdim ki, avqustda elanla yanaşı, yalnız SegmentSmack üçün bir düzəliş buraxıldı), bu da bizə Workaround-dan imtina etmək şansı verdi, bu bizə kifayət qədər problem yaratdı. Bu müddət ərzində biz artıq serverlərin bir hissəsini yeni nüvəyə köçürməyə nail olmuşduq və indi əvvəldən başlamaq lazım idi. FragmentSmack düzəltməsini gözləmədən nüvəni niyə yenilədik? Fakt budur ki, bu zəifliklərdən qorunma prosesi CentOS-un özünü yeniləmək prosesi ilə üst-üstə düşdü (və birləşdi) (bu, yalnız nüvəni yeniləməkdən daha çox vaxt aparır). Bundan əlavə, SegmentSmack daha təhlükəli zəiflikdir və bunun üçün bir düzəliş dərhal ortaya çıxdı, buna görə də hər halda məna kəsb etdi. Bununla belə, biz CentOS-da nüvəni sadəcə olaraq yeniləyə bilmədik, çünki CentOS 7.5 zamanı ortaya çıxan FragmentSmack zəifliyi yalnız 7.6 versiyasında düzəldilmişdi, ona görə də biz 7.5-ə yeniləməni dayandırmalı və 7.6-ya yenilənmə ilə yenidən başlamalı olduq. Və bu da olur.

İkincisi, problemlərlə bağlı nadir istifadəçi şikayətləri bizə qayıtdı. İndi biz əminik ki, onların hamısı müştərilərdən bəzi serverlərimizə faylların yüklənməsi ilə bağlıdır. Üstəlik, ümumi kütlədən çox az sayda yükləmə bu serverlərdən keçdi.

Yuxarıdakı hekayədən xatırladığımız kimi, Sysctl-i geri çəkmək kömək etmədi. Yenidən yükləmə kömək etdi, lakin müvəqqəti.
Sysctl ilə bağlı şübhələr aradan qaldırılmadı, lakin bu dəfə mümkün qədər çox məlumat toplamaq lazım idi. Nə baş verdiyini daha dəqiq öyrənmək üçün müştəridə yükləmə problemini təkrarlamaq qabiliyyətinin böyük çatışmazlığı da var idi.

Bütün mövcud statistik məlumatların və qeydlərin təhlili bizi nə baş verdiyini anlamağa yaxınlaşdırmadı. Müəyyən bir əlaqəni "hiss etmək" üçün problemi təkrarlamaq qabiliyyətinin kəskin çatışmazlığı var idi. Nəhayət, tərtibatçılar proqramın xüsusi versiyasından istifadə edərək, Wi-Fi vasitəsilə qoşulduqda test cihazında problemlərin stabil şəkildə bərpasına nail ola biliblər. Bu, istintaqda bir irəliləyiş oldu. Müştəri bizim Java proqramımız olan backend-ə proxy olan Nginx-ə qoşuldu.

Problemlər üçün dialoq belə idi (Nginx proxy tərəfində sabitlənmişdir):

Müştəri: faylın endirilməsi haqqında məlumat almaq üçün sorğu.
Java server: cavab.
Müştəri: fayl ilə POST.
Java server: xəta.

Eyni zamanda, Java serveri loga müştəridən 0 bayt məlumatın alındığını yazır, Nginx proksi isə sorğunun 30 saniyədən çox çəkdiyini yazır (30 saniyə müştəri tətbiqinin fasiləsidir). Niyə vaxt aşımı və niyə 0 bayt? HTTP nöqteyi-nəzərindən hər şey lazım olduğu kimi işləyir, lakin faylı olan POST şəbəkədən yoxa çıxır. Üstəlik, müştəri ilə Nginx arasında yox olur. Özünüzü Tcpdump ilə silahlandırmağın vaxtı gəldi! Ancaq əvvəlcə şəbəkə konfiqurasiyasını başa düşməlisiniz. Nginx proksi L3 balanslaşdırıcısının arxasındadır NFware. Tunelləmə, paketləri L3 balanslaşdırıcısından serverə çatdırmaq üçün istifadə olunur, bu da paketlərə başlıqlarını əlavə edir:

Bu halda, şəbəkə bu serverə Vlan etiketli trafik şəklində gəlir, bu da paketlərə öz sahələrini əlavə edir:

Və bu trafik həm də parçalana bilər (Çalışma yolu ilə bağlı riskləri qiymətləndirərkən danışdığımız daxil olan parçalanmış trafikin eyni kiçik faizi), bu da başlıqların məzmununu dəyişir:

Bir daha: paketlər Vlan etiketi ilə əhatə olunub, tunellə əhatə olunub, parçalanıb. Bunun necə baş verdiyini daha yaxşı başa düşmək üçün müştəridən Nginx proxy-yə paket marşrutunu izləyək.

Paket L3 balanslaşdırıcısına çatır. Məlumat mərkəzi daxilində düzgün marşrutlaşdırma üçün paket tuneldə əhatə olunur və şəbəkə kartına göndərilir.
Paket + tunel başlıqları MTU-ya uyğun gəlmədiyi üçün paket parçalara kəsilir və şəbəkəyə göndərilir.
L3 balanslaşdırıcısından sonrakı keçid paketi qəbul edərkən ona Vlan etiketi əlavə edir və onu göndərir.
Nginx proksisinin qarşısındakı keçid (port parametrlərinə əsasən) serverin Vlan-inkapsullaşdırılmış paket gözlədiyini görür, ona görə də Vlan teqini çıxarmadan onu olduğu kimi göndərir.
Linux fərdi paketlərin fraqmentlərini götürür və onları bir böyük paketdə birləşdirir.
Sonra, paket Vlan interfeysinə çatır, burada birinci təbəqə ondan çıxarılır - Vlan kapsulyasiyası.
Daha sonra Linux onu Tunel interfeysinə göndərir, oradan başqa bir təbəqə çıxarılır - Tunel inkapsulyasiyası.

Çətinlik bütün bunları tcpdump-a parametr kimi ötürməkdir.
Sondan başlayaq: vlan və tunel inkapsulyasiyası silinmiş müştərilərdən təmiz (lazımsız başlıqlar olmadan) IP paketləri varmı?

tcpdump host <ip клиента>

Xeyr, serverdə belə paketlər yox idi. Beləliklə, problem daha əvvəl olmalıdır. Yalnız Vlan inkapsulyasiyası silinmiş paketlər varmı?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx hex formatında müştəri IP ünvanıdır.
32:4 — Tunel paketində SCR IP-nin yazıldığı sahənin ünvanı və uzunluğu.

Sahə ünvanı kobud güclə seçilməli idi, çünki İnternetdə 40, 44, 50, 54 haqqında yazırlar, lakin orada IP ünvanı yox idi. Siz həmçinin hex-dəki paketlərdən birinə (tcpdump-da -xx və ya -XX parametri) baxa və bildiyiniz IP ünvanını hesablaya bilərsiniz.

Vlan və Tunel inkapsulyasiyası silinməyən paket fraqmentləri varmı?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Bu sehr bizə bütün fraqmentləri, o cümlədən sonuncunu göstərəcək. Yəqin ki, eyni şey IP tərəfindən süzülə bilər, amma cəhd etmədim, çünki belə paketlər çox deyil və mənə lazım olanlar ümumi axında 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 [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 ..............

Bunlar fotoşəkili olan bir paketin iki fraqmentidir (eyni ID 53652) (birinci paketdə Exif sözü görünür). Zibilliklərdə birləşdirilmiş formada deyil, bu səviyyədə paketlərin olması səbəbindən problem aydın şəkildə montajla bağlıdır. Nəhayət, bunun sənədli sübutu var!

Paket dekoderi qurmağa mane olacaq heç bir problem aşkar etmədi. Burada cəhd etdim: hpd.gasmi.net. Əvvəlcə orada bir şey doldurmağa çalışdığınız zaman dekoder paket formatını bəyənmir. Məlum oldu ki, Srcmac və Ethertype arasında əlavə iki oktet var (fraqment məlumatı ilə əlaqəli deyil). Onları çıxardıqdan sonra dekoder işləməyə başladı. Bununla belə, heç bir problem göstərmədi.
Kim nə deyə bilərsə, o Sysctl-dən başqa heç nə tapılmadı. Qaldı ki, miqyasını başa düşmək və sonrakı hərəkətlərə qərar vermək üçün problemli serverləri müəyyən etmək üçün bir yol tapmaq idi. Lazım olan sayğac kifayət qədər tez tapıldı:

netstat -s | grep "packet reassembles failed”

O, həmçinin OID=1.3.6.1.2.1.4.31.1.1.16.1 altında snmpd-dədir.ipSystemStatsReasmFails).

"İP-nin yenidən yığılması alqoritmi tərəfindən aşkar edilən uğursuzluqların sayı (hər hansı səbəbdən: vaxtı bitdi, səhvlər və s.)."

Problemin araşdırıldığı serverlər qrupu arasında ikisində bu sayğac daha sürətli, ikisində daha yavaş, daha ikisində isə heç artmadı. Bu sayğacın dinamikasını Java serverində HTTP xətalarının dinamikası ilə müqayisə etdikdə korrelyasiya üzə çıxdı. Yəni sayğaca nəzarət etmək olardı.

Problemlərin etibarlı göstəricisinin olması çox vacibdir ki, Sysctl-in geri qaytarılmasının kömək edib-etmədiyini dəqiq müəyyən edə biləsiniz, çünki əvvəlki hekayədən bunun tətbiqdən dərhal başa düşülə bilməyəcəyini bilirik. Bu göstərici bizə istehsaldakı bütün problem sahələrini istifadəçilər aşkar etməzdən əvvəl müəyyən etməyə imkan verəcəkdi.
Sysctl-i geri qaytardıqdan sonra monitorinq xətaları dayandı, beləliklə problemlərin səbəbi, həmçinin geri qaytarmanın kömək etdiyi sübut edildi.

Yeni monitorinqin işə düşdüyü digər serverlərdə fraqmentasiya parametrlərini geri qaytardıq və haradasa fraqmentlər üçün əvvəlki standartdan daha çox yaddaş ayırdıq (bu, ümumi fonda qismən itkisi nəzərə çarpmayan UDP statistikası idi) .

Ən vacib suallar

Nə üçün paketlər L3 balanslaşdırıcımızda parçalanır? İstifadəçilərdən balanslaşdırıcılara gələn paketlərin əksəriyyəti SYN və ACK-dır. Bu paketlərin ölçüləri kiçikdir. Lakin bu cür paketlərin payı çox böyük olduğundan, onların fonunda parçalanmağa başlayan böyük paketlərin mövcudluğunu görmədik.

Səbəb pozulmuş konfiqurasiya skripti idi advmss Vlan interfeysləri olan serverlərdə (o vaxt istehsalda etiketli trafikə malik çox az server var idi). Advmss bizə müştəriyə məlumatı çatdırmağa imkan verir ki, istiqamətimizdəki paketlər daha kiçik ölçüdə olmalıdır ki, onlara tunel başlıqlarını əlavə etdikdən sonra onların parçalanmasına ehtiyac olmasın.

Niyə Sysctl-in geri qaytarılması kömək etmədi, amma yenidən başladın? Sysctl-in geri qaytarılması paketləri birləşdirmək üçün mövcud yaddaşın miqdarını dəyişdi. Eyni zamanda, yəqin ki, fraqmentlər üçün yaddaşın daşması faktı əlaqələrin yavaşlamasına gətirib çıxardı ki, bu da fraqmentlərin uzun müddət növbədə gecikməsinə səbəb oldu. Yəni, proses tsikllərlə gedirdi.
Yenidən yükləmə yaddaşı təmizlədi və hər şey qaydasına düşdü.

Çözüm olmadan etmək mümkün idimi? Bəli, lakin hücum zamanı istifadəçilərin xidmətsiz qalma riski yüksəkdir. Əlbəttə ki, Çözümdən istifadə istifadəçilər üçün xidmətlərdən birinin ləngiməsi də daxil olmaqla müxtəlif problemlərlə nəticələndi, lakin buna baxmayaraq, hərəkətlərin haqlı olduğuna inanırıq.

Andrey Timofeyevə çox təşəkkür edirəm (atimofeyev) istintaqın aparılmasında köməklik göstərdiyinə görə, həmçinin Aleksey Krenevə (cihazx) - serverlərdə Centos və nüvələrin yenilənməsinin titanik işi üçün. Belə olan halda bir neçə dəfə əvvəldən başlamalı olan proses aylarla uzandı.

Mənbə: www.habr.com

İş raundları gətirən zəifliklərdən çəkinin. 1-ci hissə: FragmentSmack/SegmentSmack