Hei kaikki! Nimeni on Dmitry Samsonov, työskentelen johtavana järjestelmänvalvojana Odnoklassnikissa. Meillä on yli 7 tuhatta fyysistä palvelinta, 11 tuhatta konttia pilvessämme ja 200 sovellusta, jotka eri kokoonpanoissa muodostavat 700 erilaista klusteria. Suurin osa palvelimista käyttää CentOS 7:ää.
14. elokuuta 2018 julkaistiin tiedot FragmentSmack-haavoittuvuudesta
() ja SegmentSmack (). Nämä ovat verkkohyökkäysvektorin ja melko korkean pistemäärän (7.5) haavoittuvuuksia, jotka uhkaavat palvelunestolla (DoS) resurssien loppuun kulumisen (CPU) vuoksi. Ytimen korjausta FragmentSmackille ei tuolloin ehdotettu, vaan se julkaistiin paljon myöhemmin kuin haavoittuvuudesta tiedotettiin. SegmentSmackin poistamiseksi ehdotettiin ytimen päivittämistä. Itse päivityspaketti julkaistiin samana päivänä, jäljellä oli vain sen asentaminen.
Ei, emme vastusta ytimen päivittämistä ollenkaan! On kuitenkin vivahteita...
Kuinka päivitämme ytimen tuotannossa
Yleensä ei mitään monimutkaista:
- Lataa paketteja;
- Asenna ne useille palvelimille (mukaan lukien palvelimet, jotka isännöivät pilviämme);
- Varmista, että mikään ei ole rikki;
- Varmista, että kaikki ytimen vakioasetukset on otettu käyttöön virheettömästi;
- Odota muutama päivä;
- Tarkista palvelimen suorituskyky;
- Vaihda uusien palvelimien käyttöönotto uuteen ytimeen;
- Päivitä kaikki palvelimet datakeskuksen mukaan (yksi palvelinkeskus kerrallaan minimoimaan ongelmien aiheuttamat vaikutukset käyttäjiin);
- Käynnistä kaikki palvelimet uudelleen.
Toista sama kaikille olemassa olevien ytimien haareille. Tällä hetkellä se on:
- Kanta CentOS 7 3.10 - useimmille tavallisille palvelimille;
- Vanilja 4.19 - meille , koska tarvitsemme BFQ:ta, BBR:ää jne.;
- Elrepo kernel-ml 5.2 - varten , koska 4.19 käyttäytyi aiemmin epävakaasti, mutta samoja ominaisuuksia tarvitaan.
Kuten saatat arvata, tuhansien palvelimien uudelleenkäynnistys kestää pisimpään. Koska kaikki haavoittuvuudet eivät ole kriittisiä kaikille palvelimille, käynnistämme uudelleen vain ne, joihin pääsee suoraan Internetistä. Joustavuuden rajoittamiseksi pilvessä emme sido ulkoisesti saatavilla olevia säiliöitä yksittäisiin palvelimiin uudella ytimellä, vaan käynnistämme kaikki isännät poikkeuksetta uudelleen. Onneksi menettely on siellä yksinkertaisempi kuin tavallisilla palvelimilla. Esimerkiksi tilattomat säilöt voivat yksinkertaisesti siirtyä toiselle palvelimelle uudelleenkäynnistyksen aikana.
Työtä on kuitenkin vielä paljon, ja se voi kestää useita viikkoja, ja jos uudessa versiossa ilmenee ongelmia, jopa useita kuukausia. Hyökkääjät ymmärtävät tämän erittäin hyvin, joten he tarvitsevat suunnitelman B.
FragmentSmack/SegmentSmack. Ratkaisu
Onneksi joillekin haavoittuvuuksille tällainen suunnitelma B on olemassa, ja sitä kutsutaan nimellä Workaround. Useimmiten tämä on ytimen/sovelluksen asetusten muutos, joka voi minimoida mahdollisen vaikutuksen tai poistaa kokonaan haavoittuvuuksien hyödyntämisen.
Jos kyseessä on FragmentSmack/SegmentSmack Ratkaisu näin:
«Voit muuttaa net.ipv4.ipfrag_high_thresh- ja net.ipv3.ipfrag_low_thresh-oletusarvot 4 Mt ja 4 Mt (ja niiden vastineet ipv6:lle net.ipv6.ipfrag_high_thresh ja net.ipv6.ipfrag_low_thresh) arvoon 256 tai 192 kB alempi. Testit osoittavat pieniä tai merkittäviä pudotuksia suorittimen käytössä hyökkäyksen aikana riippuen laitteistosta, asetuksista ja olosuhteista. Kuitenkin ipfrag_high_thresh=262144 tavulla saattaa olla jonkin verran vaikutusta suorituskykyyn, koska vain kaksi 64 XNUMX fragmenttia mahtuu kokoamisjonoon kerrallaan. On esimerkiksi olemassa riski, että suuria UDP-paketteja käyttävät sovellukset hajoavat'.
Itse parametrit kuvataan seuraavasti:
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.
Meillä ei ole suuria UDP:itä tuotantopalveluissa. Lähiverkossa ei ole hajanaista liikennettä; WAN-verkossa on hajanaista liikennettä, mutta ei merkittävää. Ei ole merkkejä – voit ottaa käyttöön kiertotavan!
FragmentSmack/SegmentSmack. Ensimmäinen veri
Ensimmäinen ongelma, jonka kohtasimme, oli se, että pilvisäilöt käyttivät joskus uusia asetuksia vain osittain (vain ipfrag_low_thresh) ja joskus eivät käyttäneet niitä ollenkaan - ne yksinkertaisesti kaatui alussa. Ongelmaa ei voitu toistaa vakaasti (kaikki asetukset käytettiin manuaalisesti ilman vaikeuksia). Ei myöskään ole niin helppoa ymmärtää, miksi kontti kaatuu alussa: virheitä ei löytynyt. Yksi asia oli varma: asetusten palauttaminen ratkaisee kontin kaatumisongelman.
Miksi Sysctl:n käyttäminen isännässä ei riitä? Säiliö asuu omassa verkkonsa nimiavaruudessa, joten ainakin säiliössä voi poiketa isännästä.
Kuinka tarkalleen Sysctl-asetuksia käytetään säilössä? Koska säilöillämme ei ole etuoikeuksia, et voi muuttaa mitään Sysctl-asetuksia menemällä itse säilöön - sinulla ei yksinkertaisesti ole tarpeeksi oikeuksia. Konttien ajamiseen pilvessämme käytettiin tuolloin Dockeria (nyt ). Uuden säilön parametrit välitettiin Dockerille API:n kautta, mukaan lukien tarvittavat Sysctl-asetukset.
Versioita haettaessa kävi ilmi, että Docker API ei palauttanut kaikkia virheitä (ainakaan versiossa 1.10). Kun yritimme käynnistää konttia "docker run" kautta, näimme vihdoin ainakin jotain:
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.
Parametrin arvo ei kelpaa. Mutta miksi? Ja miksi se ei ole voimassa vain joskus? Kävi ilmi, että Docker ei takaa Sysctl-parametrien käyttöjärjestystä (viimeisin testattu versio on 1.13.1), joten joskus ipfrag_high_thresh yritettiin asettaa arvoon 256K, kun ipfrag_low_thresh oli vielä 3M, eli yläraja oli alempi kuin alaraja, mikä johti virheeseen.
Käytimme tuolloin jo omaa mekanismiamme kontin uudelleenkonfigurointiin käynnistyksen jälkeen (kontin jäädyttäminen jälkeen ja komentojen suorittaminen säilön nimiavaruudessa kautta ), ja lisäsimme myös Sysctl-parametrien kirjoittamisen tähän osaan. Ongelma ratkesi.
FragmentSmack/SegmentSmack. Ensimmäinen veri 2
Ennen kuin ehtimme ymmärtää Workaroundin käyttöä pilvessä, ensimmäiset harvinaiset valitukset käyttäjiltä alkoivat saapua. Tuolloin oli kulunut useita viikkoja Workaroundin käytön alkamisesta ensimmäisillä palvelimilla. Alkututkimus osoitti, että valituksia on vastaanotettu yksittäisistä palveluista, ei kaikkien näiden palvelujen palvelimista. Ongelma on jälleen muuttunut erittäin epävarmaksi.
Ensinnäkin yritimme tietysti palauttaa Sysctl-asetukset, mutta tällä ei ollut mitään vaikutusta. Myöskään erilaiset palvelimen ja sovellusasetusten käsittelyt eivät auttaneet. Reboot auttoi. Linuxin uudelleenkäynnistys on yhtä luonnotonta kuin se oli normaalia Windowsille vanhaan aikaan. Se kuitenkin auttoi, ja määritimme sen "ytimen häiriöksi", kun otettiin käyttöön uusia asetuksia Sysctlissä. Kuinka kevytmielistä se olikaan...
Kolme viikkoa myöhemmin ongelma toistui. Näiden palvelimien konfigurointi oli melko yksinkertaista: Nginx välityspalvelin/balancer-tilassa. Ei paljon liikennettä. Uusi johdantohuomautus: asiakkaiden 504-virheiden määrä kasvaa joka päivä (). Kaavio näyttää tämän palvelun 504 virheen määrän päivässä:
Kaikki virheet koskevat samaa taustaa - pilvessä olevaa taustaa. Tämän taustajärjestelmän pakettien fragmenttien muistinkulutuskaavio näytti tältä:
Tämä on yksi ilmeisimpiä ilmenemismuotoja ongelmasta käyttöjärjestelmäkaavioissa. Pilvessä samaan aikaan korjattiin toinen verkko-ongelma QoS (Traffic Control) -asetuksissa. Pakettifragmenttien muistinkulutuksen kaaviossa se näytti täsmälleen samalta:
Oletus oli yksinkertainen: jos ne näyttävät samalta kaavioissa, niillä on sama syy. Lisäksi tämäntyyppisten muistien ongelmat ovat erittäin harvinaisia.
Korjatun ongelman ydin oli, että käytimme QoS:n oletusasetuksella fq-pakettien ajoitinta. Oletusarvoisesti yhdelle yhteydelle se mahdollistaa 100 paketin lisäämisen jonoon, ja jotkin yhteydet alkoivat kanavapulatilanteissa tukkia jonon kapasiteettiin. Tässä tapauksessa paketit pudotetaan. Tc-tilastoissa (tc -s qdisc) se näkyy näin:
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" on paketit, jotka on pudonnut yhden yhteyden jonorajan ylittämisen vuoksi, ja "pudotettu 464545" on tämän ajoittajan kaikkien hylättyjen pakettien summa. Kun jonon pituutta oli kasvatettu 1:een ja kontit käynnistettiin uudelleen, ongelma lakkasi esiintymästä. Voit rentoutua ja juoda smoothien.
FragmentSmack/SegmentSmack. Viimeinen veri
Ensinnäkin, useita kuukausia ytimen haavoittuvuuksista ilmoittamisen jälkeen, FragmentSmackille ilmestyi vihdoin korjaus (muistutan, että elokuussa julkaistun ilmoituksen ohella julkaistiin korjaus vain SegmentSmackille), mikä antoi meille mahdollisuuden luopua kiertotavan, mikä aiheutti meille paljon vaivaa. Tänä aikana olimme jo onnistuneet siirtämään osan palvelimista uuteen ytimeen, ja nyt oli aloitettava alusta. Miksi päivitimme ytimen odottamatta FragmentSmack-korjausta? Tosiasia on, että näiltä haavoittuvuuksilta suojautumisprosessi osui (ja sulautui) itse CentOS:n päivitysprosessiin (joka vie jopa enemmän aikaa kuin pelkän ytimen päivittäminen). Lisäksi SegmentSmack on vaarallisempi haavoittuvuus, ja korjaus siihen ilmestyi heti, joten se oli järkevää joka tapauksessa. Emme kuitenkaan voineet vain päivittää CentOS:n ydintä, koska CentOS 7.5:n aikana ilmaantunut FragmentSmack-haavoittuvuus korjattiin vain versiossa 7.6, joten meidän piti pysäyttää päivitys versioon 7.5 ja aloittaa alusta päivityksellä 7.6:een. Ja tätä myös tapahtuu.
Toiseksi harvinaiset käyttäjien valitukset ongelmista ovat palanneet meille. Nyt tiedämme jo varmasti, että ne kaikki liittyvät tiedostojen lataamiseen asiakkailta joillekin palvelimillemme. Lisäksi hyvin pieni määrä latauksia kokonaismassasta kulki näiden palvelimien kautta.
Kuten yllä olevasta tarinasta muistamme, Sysctlin palauttaminen ei auttanut. Uudelleenkäynnistys auttoi, mutta väliaikaisesti.
Sysctliä koskevia epäilyksiä ei poistettu, mutta tällä kertaa oli tarpeen kerätä mahdollisimman paljon tietoa. Oli myös valtava puute kyvystä toistaa latausongelma asiakkaalla, jotta voitaisiin tutkia tarkemmin, mitä tapahtuu.
Kaikkien saatavilla olevien tilastojen ja lokien analyysi ei tuonut meitä lähemmäksi ymmärtämistä, mitä tapahtui. Akuutti kyvyttömyys toistaa ongelmaa tietyn yhteyden "tuntemiseksi". Lopuksi kehittäjät onnistuivat sovelluksen erityisversion avulla saavuttamaan ongelmien vakaan toiston testilaitteessa, kun se oli yhdistetty Wi-Fi-yhteyden kautta. Tämä oli läpimurto tutkinnassa. Asiakas yhdisti Nginxiin, joka välityspalvelinta backendille, joka oli Java-sovelluksemme.
Dialogi ongelmista oli tällainen (korjattu Nginx-välityspalvelimen puolelle):
- Asiakas: pyytää tietoja tiedoston lataamisesta.
- Java-palvelin: vastaus.
- Asiakas: POST tiedostolla.
- Java-palvelin: virhe.
Samanaikaisesti Java-palvelin kirjoittaa lokiin, että asiakkaalta vastaanotettiin 0 tavua dataa, ja Nginx-välityspalvelin kirjoittaa, että pyyntö kesti yli 30 sekuntia (30 sekuntia on asiakassovelluksen aikakatkaisu). Miksi aikakatkaisu ja miksi 0 tavua? HTTP-näkökulmasta katsottuna kaikki toimii niin kuin pitääkin, mutta tiedoston sisältävä POST näyttää katoavan verkosta. Lisäksi se katoaa asiakkaan ja Nginxin välillä. On aika aseistaa itsesi Tcpdumpilla! Mutta ensin sinun on ymmärrettävä verkon kokoonpano. Nginx-välityspalvelin on L3-tasapainottimen takana . Tunnelointia käytetään pakettien toimittamiseen L3-tasapainottimesta palvelimelle, joka lisää otsikot paketteihin:
Tässä tapauksessa verkko tulee tälle palvelimelle Vlan-merkityn liikenteen muodossa, joka myös lisää omat kentänsä paketeihin:
Ja tämä liikenne voi myös olla pirstoutunut (sama pieni prosenttiosuus saapuvasta hajanaisesta liikenteestä, josta puhuimme, kun arvioimme kiertotavan riskejä), mikä muuttaa myös otsikoiden sisältöä:
Jälleen kerran: paketit on kapseloitu Vlan-tunnisteeseen, kapseloitu tunneliin, pirstoutunut. Ymmärtääksemme paremmin, kuinka tämä tapahtuu, jäljitetään pakettireitti asiakkaalta Nginx-välityspalvelimeen.
- Paketti saavuttaa L3-tasapainottimen. Oikeaa reititystä varten datakeskuksen sisällä paketti kapseloidaan tunneliin ja lähetetään verkkokortille.
- Koska paketti + tunneliotsikot eivät mahdu MTU:hun, paketti leikataan fragmenteiksi ja lähetetään verkkoon.
- L3-tasapainottimen jälkeinen kytkin, kun se vastaanottaa paketin, lisää siihen Vlan-tunnisteen ja lähettää sen päälle.
- Nginx-välityspalvelimen edessä oleva kytkin näkee (porttiasetusten perusteella), että palvelin odottaa Vlan-kapseloitua pakettia, joten se lähettää sen sellaisenaan poistamatta Vlan-tunnistetta.
- Linux ottaa yksittäisten pakettien fragmentteja ja yhdistää ne yhdeksi suureksi paketiksi.
- Seuraavaksi paketti saavuttaa Vlan-rajapinnan, jossa siitä poistetaan ensimmäinen kerros - Vlan-kapselointi.
- Linux lähettää sen sitten Tunnelirajapintaan, jossa siitä poistetaan toinen kerros - Tunnelikapselointi.
Vaikeus on siirtää tämä kaikki parametreina tcpdumpille.
Aloitetaan lopusta: onko asiakkailta puhtaita (ilman tarpeettomia otsikoita) IP-paketteja, joista vlan ja tunnelikapselointi on poistettu?
tcpdump host <ip клиента>
Ei, palvelimella ei ollut tällaisia paketteja. Joten ongelman täytyy olla olemassa aikaisemmin. Onko olemassa paketteja, joista on poistettu vain Vlan-kapselointi?
tcpdump ip[32:4]=0xx390x2xx
0xx390x2xx on asiakkaan IP-osoite hex-muodossa.
32:4 — sen kentän osoite ja pituus, johon SCR IP kirjoitetaan tunnelipaketissa.
Kentän osoite oli valittava raa'alla voimalla, koska Internetissä kirjoitetaan noin 40, 44, 50, 54, mutta siellä ei ollut IP-osoitetta. Voit myös katsoa yhtä paketeista hex-muodossa (parametri -xx tai -XX tcpdumpissa) ja laskea tuntemasi IP-osoitteen.
Onko pakettien fragmentteja ilman Vlan- ja Tunnel-kapselointia poistettua?
tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
Tämä taika näyttää meille kaikki palaset, mukaan lukien viimeinen. Todennäköisesti sama asia voidaan suodattaa IP: n mukaan, mutta en yrittänyt, koska sellaisia paketteja ei ole kovin montaa, ja tarvitsemani löytyi helposti yleisestä virtauksesta. Täällä he ovat:
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 ..............
Nämä ovat kaksi fragmenttia yhdestä paketista (sama ID 53652), joissa on valokuva (sana Exif näkyy ensimmäisessä paketissa). Johtuen siitä, että tällä tasolla on paketteja, mutta ei yhdistetyssä muodossa kaatopaikoilla, ongelma on selkeästi kokoonpanossa. Vihdoinkin tästä on dokumentaalista näyttöä!
Pakettidekooderi ei paljastanut ongelmia, jotka estäisivät rakentamisen. Kokeiltu täällä: . Aluksi, kun yrität laittaa sinne jotain, dekooderi ei pidä pakettimuodosta. Kävi ilmi, että Srcmacin ja Ethertypen välillä oli kaksi ylimääräistä oktettia (ei liity fragmenttitietoihin). Niiden poistamisen jälkeen dekooderi alkoi toimia. Se ei kuitenkaan osoittanut ongelmia.
Mitä tahansa voi sanoa, mitään muuta ei löytynyt kuin ne Sysctl. Jäljelle jäi vain tapa tunnistaa ongelmapalvelimet, jotta voidaan ymmärtää mittakaava ja päättää jatkotoimenpiteistä. Tarvittava laskuri löytyi riittävän nopeasti:
netstat -s | grep "packet reassembles failed”
Se on myös snmpd:ssä OID=1.3.6.1.2.1.4.31.1.1.16.1 ().
"IP-uudelleenkokoamisalgoritmin havaitsemien vikojen määrä (joskin syystä: aikakatkaisu, virheet jne.)."
Palvelinryhmästä, jolla ongelmaa tutkittiin, kahdella tämä laskuri kasvoi nopeammin, kahdella hitaammin ja kahdella muulla se ei kasvanut ollenkaan. Tämän laskurin dynamiikan vertaaminen Java-palvelimen HTTP-virheiden dynamiikkaan paljasti korrelaation. Eli mittaria voisi valvoa.
Luotettava osoitin ongelmista on erittäin tärkeää, jotta voit määrittää tarkasti, auttaako Sysctl:n palauttaminen, koska tiedämme edellisestä jutusta, että tätä ei voi heti ymmärtää sovelluksesta. Tämän indikaattorin avulla voimme tunnistaa kaikki tuotannon ongelmakohdat ennen kuin käyttäjät huomaavat ne.
Sysctl-palautuksen jälkeen valvontavirheet loppuivat, joten ongelmien syy selvitettiin sekä se, että palautus auttaa.
Purimme pirstoutumisasetukset muilla palvelimilla, joissa tuli käyttöön uutta valvontaa, ja jossain osoitimme fragmenteille jopa enemmän muistia kuin aiemmin oletusarvo (tämä oli UDP-tilasto, jonka osittaista häviämistä ei ollut havaittavissa yleistä taustaa vasten) .
Tärkeimmät kysymykset
Miksi paketit ovat pirstoutuneita L3-tasapainottimessamme? Suurin osa käyttäjiltä tasapainottajille saapuvista paketeista on SYN ja ACK. Näiden pakkausten koot ovat pieniä. Mutta koska tällaisten pakettien osuus on erittäin suuri, emme havainneet niiden taustaa vasten suuria paketteja, jotka alkoivat pirstoutua.
Syynä oli rikkinäinen asetusskripti palvelimilla, joissa on Vlan-liitännät (tuotannossa oli tuolloin hyvin vähän palvelimia, joissa oli tunnisteliikennettä). Advmss:n avulla voimme välittää asiakkaalle tiedon, että meidän suunnassamme olevien pakettien tulee olla kooltaan pienempiä, jotta tunneliotsikoiden liittämisen jälkeen niitä ei tarvitse pilkkoa.
Miksi Sysctl-palautus ei auttanut, mutta uudelleenkäynnistys auttoi? Sysctlin palauttaminen muutti pakettien yhdistämiseen käytettävissä olevan muistin määrää. Samaan aikaan ilmeisesti itse fragmenttien muistin ylivuoto johti yhteyksien hidastumiseen, mikä johti fragmenttien viivästymiseen pitkään jonossa. Eli prosessi eteni sykleissä.
Uudelleenkäynnistys tyhjensi muistin ja kaikki palasi järjestykseen.
Oliko mahdollista tehdä ilman kiertotapaa? Kyllä, mutta on suuri riski jättää käyttäjät ilman palvelua hyökkäyksen sattuessa. Tietysti Workaroundin käyttö johti erilaisiin ongelmiin, kuten yhden palvelun hidastumiseen käyttäjille, mutta uskomme kuitenkin, että toimenpiteet olivat perusteltuja.
Suuri kiitos Andrey Timofejev () avusta tutkinnan suorittamisessa sekä Aleksei Krenev () - titaaniseen työhön Centosin ja palvelimien ytimien päivittämiseksi. Prosessi, joka tässä tapauksessa jouduttiin aloittamaan alusta useita kertoja, minkä vuoksi se kesti monta kuukautta.
Lähde: will.com