Pastaba. vert.: rugpjūčio pradžioje „Red Hat“ viešai kalbėjo apie prieinamumo problemų, su kuriomis jos paslaugos vartotojai susidūrė ankstesniais mėnesiais, sprendimą. (jis pagrįstas konteinerio vaizdų registru, kurį įmonė gavo kartu su CoreOS pirkimu). Nepriklausomai nuo jūsų susidomėjimo šia paslauga, kelias, kuriuo įmonės SRE inžinieriai diagnozavo ir pašalino avarijos priežastis, yra pamokantis.
Gegužės 19 d., anksti ryte (Eastern Daylight Time, EDT), quay.io paslauga sudužo. Nelaimė palietė ir quay.io vartotojus, ir atvirojo kodo projektus, kuriuose quay.io buvo naudojama kaip programinės įrangos kūrimo ir platinimo platforma. Red Hat vertina abiejų pasitikėjimą.
Nedelsiant įsitraukė SRE inžinierių komanda ir stengėsi kuo greičiau stabilizuoti Quay paslaugą. Tačiau tai darydami klientai prarado galimybę stumti naujus vaizdus ir tik retkarčiais galėjo ištraukti esamus. Dėl nežinomos priežasties quay.io duomenų bazė buvo užblokuota po to, kai paslauga buvo padidinta iki pilno pajėgumo.
«Kas pasikeitė?“ – toks yra pirmasis klausimas, kuris dažniausiai užduodamas tokiais atvejais. Pastebėjome, kad prieš pat problemą, OpenShift Dedicated klasteris (kuriame veikia quay.io) buvo pradėtas atnaujinti į 4.3.19 versiją. Kadangi quay.io veikia naudojant „Red Hat OpenShift Dedicated“ (OSD), reguliarūs atnaujinimai buvo įprasti ir niekada nesukėlė problemų. Be to, per pastaruosius šešis mėnesius kelis kartus atnaujinome „Quay“ grupes be jokių paslaugų pertrūkių.
Kol mes bandėme atkurti paslaugą, kiti inžinieriai pradėjo ruošti naują OSD klasterį su ankstesne programinės įrangos versija, kad, jei kas nutiktų, galėtų joje įdiegti viską.
Pagrindinės priežasties analizė
Pagrindinis gedimo požymis buvo dešimčių tūkstančių duomenų bazių jungčių lavina, dėl kurios MySQL egzempliorius buvo veiksmingai neveikiantis. Dėl to buvo sunku diagnozuoti problemą. Siekdami padėti SRE komandai įvertinti problemą, nustatėme maksimalaus klientų prisijungimų skaičiaus apribojimą. Nepastebėjome neįprasto srauto į duomenų bazę: iš tikrųjų dauguma užklausų buvo perskaitytos ir tik kelios buvo parašytos.
Taip pat bandėme nustatyti duomenų bazės srauto modelį, galintį sukelti šią laviną. Tačiau rąstuose neradome jokių raštų. Laukdami, kol bus paruoštas naujas klasteris su OSD 4.3.18, toliau bandėme paleisti quay.io podius. Kiekvieną kartą, kai klasteris pasiekia visą pajėgumą, duomenų bazė užšąla. Tai reiškė, kad reikėjo iš naujo paleisti RDS egzempliorių, be visų quay.io rinkinių.
Iki vakaro stabilizavome paslaugą tik skaitymo režimu ir išjungėme kuo daugiau neesminių funkcijų (pavyzdžiui, vardų erdvės šiukšlių surinkimą), kad sumažintume duomenų bazės apkrovą. Užšalimai sustojo bet priežasties taip ir nepavyko rasti. Naujasis OSD klasteris buvo paruoštas, mes perkėlėme paslaugą, prijungėme srautą ir tęsėme stebėjimą.
Quay.io stabiliai veikė su naujuoju OSD klasteriu, todėl grįžome į duomenų bazės žurnalus, bet negalėjome rasti koreliacijos, kuri paaiškintų užsikimšimus. „OpenShift“ inžinieriai dirbo su mumis siekdami suprasti, ar „Red Hat OpenShift 4.3.19“ pakeitimai gali sukelti „Quay“ problemų. Tačiau nieko nerasta, ir Laboratorinėmis sąlygomis problemos atkurti nepavyko.
Antroji nesėkmė
Gegužės 28 d., prieš pat vidurdienį EDT, quay.io vėl sudužo su tuo pačiu simptomu: duomenų bazė buvo užblokuota. Ir vėl atidavėme visas pastangas į tyrimą. Pirmiausia reikėjo atkurti paslaugą. Tačiau šį kartą iš naujo paleidus RDS ir paleidus quay.io pods nieko nepadarė: dar viena ryšių lavina užgriuvo bazę. Bet kodėl?
„Quy“ parašyta „Python“ kalba, o kiekvienas pods veikia kaip vienas monolitinis konteineris. Sudėtinio rodinio vykdymo laikas vienu metu vykdo daug lygiagrečių užduočių. Naudojamės biblioteka gevent pagal gunicorn apdoroti žiniatinklio užklausas. Kai užklausa patenka į „Quay“ (per mūsų pačių API arba per „Docker“ API), jai priskiriamas „gevent“ darbuotojas. Paprastai šis darbuotojas turėtų susisiekti su duomenų baze. Po pirmosios nesėkmės nustatėme, kad „gevent“ darbuotojai jungiasi prie duomenų bazės naudodami numatytuosius nustatymus.
Atsižvelgiant į didelį „Quay“ blokų skaičių ir tūkstančius gaunamų užklausų per sekundę, daugybė duomenų bazių jungčių teoriškai gali priblokšti „MySQL“ egzempliorių. Stebėjimo dėka buvo žinoma, kad Quay vidutiniškai apdoroja 5 tūkst. užklausų per sekundę. Prisijungimų prie duomenų bazės skaičius buvo maždaug toks pat. 5 tūkstančiai jungčių tikrai neviršijo mūsų RDS egzemplioriaus galimybių (to negalima pasakyti apie dešimtis tūkstančių). Kažkodėl netikėtai išaugo jungčių skaičius, tačiau nepastebėjome jokio ryšio su gaunamomis užklausomis.
Šį kartą buvome pasiryžę surasti ir pašalinti problemos šaltinį, o ne apsiriboti perkrovimu. Į Quay kodų bazę buvo atlikti pakeitimai, siekiant apriboti kiekvieno darbuotojo prisijungimų prie duomenų bazės skaičių geventas. Šis skaičius tapo konfigūracijos parametru: tapo įmanoma jį pakeisti skrydžio metu nekuriant naujo konteinerio vaizdo. Norėdami sužinoti, kiek ryšių galima realiai apdoroti, atlikome kelis bandymus sustojimo aplinkoje, nustatydami skirtingas vertes, kad pamatytume, kaip tai paveiks apkrovos testavimo scenarijus. Dėl to buvo nustatyta, kad Quay pradeda mesti 502 klaidas, kai prisijungimų skaičius viršija 10 tūkst.
Nedelsdami įdiegėme šią naują versiją gamybinėje versijoje ir pradėjome stebėti duomenų bazės prisijungimo grafiką. Anksčiau bazė buvo užrakinta maždaug po 20 minučių. Po 30 minučių be problemų turėjome vilties, o po valandos – pasitikėjimo. Atkūrėme srautą į svetainę ir pradėjome pomirtinę analizę.
Pavykus apeiti problemą, sukeliančią blokavimą, nesužinojome tikrųjų jo priežasčių. Patvirtinta, kad tai nesusiję su jokiais OpenShift 4.3.19 pakeitimais, nes tas pats nutiko 4.3.18 versijoje, kuri anksčiau veikė su Quay be jokių problemų.
Aišku, kad klasteryje slypėjo dar kažkas.
Išsamus tyrimas
Quay.io naudojo numatytuosius nustatymus, kad prisijungtų prie duomenų bazės šešerius metus be jokių problemų. Kas pasikeitė? Akivaizdu, kad visą šį laiką eismas quay.io nuolat augo. Mūsų atveju atrodė, kad buvo pasiekta tam tikra slenkstinė reikšmė, kuri buvo ryšių lavinos paleidiklis. Po antrosios nesėkmės toliau tyrinėjome duomenų bazės žurnalus, bet neradome jokių šablonų ar akivaizdžių ryšių.
Tuo tarpu SRE komanda tobulino Quay užklausų stebėjimą ir bendrą paslaugų būklę. Buvo įdiegta nauja metrika ir prietaisų skydeliai, rodantis, kurios krantinės dalys yra paklausiausios iš klientų.
Quay.io puikiai veikė iki birželio 9 d. Šį rytą (EDT) vėl pastebėjome reikšmingą duomenų bazių prisijungimų skaičiaus padidėjimą. Šį kartą prastovų nebuvo, nes naujasis parametras apribojo jų skaičių ir neleido viršyti MySQL pralaidumo. Tačiau maždaug pusvalandį daugelis vartotojų pastebėjo lėtą quay.io veikimą. Greitai surinkome visus įmanomus duomenis naudodami pridėtus stebėjimo įrankius. Staiga atsirado modelis.
Prieš pat išaugusį ryšiams, App Registry API buvo pateikta daug užklausų. Programų registras yra mažai žinoma quay.io funkcija. Tai leidžia saugoti tokius dalykus kaip Helm diagramos ir konteineriai su daugybe metaduomenų. Dauguma quay.io vartotojų neveikia su šia funkcija, tačiau Red Hat OpenShift ja aktyviai naudojasi. „OperatorHub“, kaip „OpenShift“ dalis, visus operatorius saugo programų registre. Šie operatoriai sudaro „OpenShift“ darbo krūvio ekosistemos ir į partnerį orientuoto veikimo modelio pagrindą (2 dienos operacijos).
Kiekviename OpenShift 4 klasteryje naudojami operatoriai iš integruoto OperatorHub, kad paskelbtų galimų įdiegti operatorių katalogą ir pateiktų jau įdiegtų operatorių naujinimus. Augant OpenShift 4 populiarumui, jame esančių grupių skaičius visame pasaulyje taip pat išaugo. Kiekviena iš šių grupių atsisiunčia operatoriaus turinį, kad paleistų įtaisytąjį OperatorHub, naudodami programų registrą, esantį quay.io kaip užpakalinę programą. Ieškodami problemos šaltinio, pasigedome fakto, kad pamažu populiarėjant OpenShift, padidėjo ir vienos iš retai naudojamų quay.io funkcijų apkrova..
Atlikome tam tikrą programų registro užklausų srauto analizę ir pažvelgėme į registro kodą. Iš karto buvo atskleisti trūkumai, dėl kurių užklausos į duomenų bazę nebuvo suformuotos optimaliai. Kai krūvis buvo mažas, bėdų jie nepridarė, o padidėjus krūviui tapo problemų šaltiniu. Paaiškėjo, kad programų registre yra du probleminiai galiniai taškai, kurie netinkamai reagavo į didėjančią apkrovą: pirmasis pateikė visų saugykloje esančių paketų sąrašą, antrasis grąžino visus paketo blobus.
Priežasčių šalinimas
Kitą savaitę optimizavome paties programų registro kodą ir jo aplinką. Aiškiai neveiksmingos SQL užklausos buvo perdirbtos ir nereikalingi komandų iškvietimai buvo pašalinti tar (jis buvo paleistas kiekvieną kartą, kai buvo nuskaitomos dėmės), buvo pridėtas talpyklos saugojimas, kur įmanoma. Tada atlikome išsamų našumo testavimą ir palyginome programų registro greitį prieš ir po pakeitimų.
API užklausos, kurios anksčiau užtrukdavo iki pusės minutės, dabar atliekamos per milisekundes. Kitą savaitę įdiegėme pakeitimus gamyboje ir nuo tada quay.io veikia stabiliai. Per tą laiką buvo keli staigūs srauto šuoliai programų registro galutiniame taške, tačiau atlikti patobulinimai užkirto kelią duomenų bazės gedimams.
Ko mes išmokome?
Akivaizdu, kad bet kuri paslauga stengiasi išvengti prastovų. Mūsų atveju manome, kad pastarieji gedimai padėjo pagerinti quay.io. Išmokome keletą pagrindinių pamokų, kuriomis norėtume pasidalinti:
- Duomenys apie tai, kas ir kaip naudojasi jūsų paslauga, niekada nėra nereikalingi. Kadangi „Quy“ „tiesiog dirbo“, mums niekada nereikėjo praleisti laiko optimizuodami eismą ir valdydami apkrovą. Visa tai sukūrė klaidingą saugumo jausmą, kurį paslauga galėjo išplėsti neribotą laiką.
- Kai paslauga nutrūksta, jo atkūrimas ir paleidimas yra pagrindinis prioritetas.. Kadangi „Quay“ ir toliau kentėjo dėl užrakintos duomenų bazės pirmojo gedimo metu, mūsų standartinės procedūros neturėjo norimo efekto ir negalėjome atkurti paslaugos naudojant jas. Dėl to susidarė situacija, kai reikėjo skirti laiko analizuojant ir renkant duomenis, tikintis rasti pagrindinę priežastį – užuot sutelkus visas pastangas į funkcionalumo atkūrimą.
- Įvertinkite kiekvienos paslaugos funkcijos poveikį. Klientai retai naudojosi programų registru, todėl mūsų komandai tai nebuvo prioritetas. Kai kai kurios produkto funkcijos beveik nenaudojamos, jų klaidos atsiranda retai, o kūrėjai nustoja stebėti kodą. Nesunku tapti klaidingo supratimo, kad taip ir turi būti, auku – kol staiga ši funkcija atsiduria didelio incidento centre.
Kas toliau?
Darbas siekiant užtikrinti paslaugos stabilumą niekada nesiliauja ir nuolat jį tobuliname. Kadangi eismo apimtys quay.io ir toliau auga, pripažįstame, kad esame įsipareigoję padaryti viską, ką galime, kad pateisintume klientų pasitikėjimą. Todėl šiuo metu atliekame šias užduotis:
- Įdiekite tik skaitomas duomenų bazių kopijas, kad padėtų tarnybai tvarkyti atitinkamą srautą iškilus problemoms dėl pirminio RDS egzemplioriaus.
- RDS egzemplioriaus atnaujinimas. Pati dabartinė versija nėra problema. Atvirkščiai, mes tiesiog norime pašalinti klaidingą pėdsaką (kuriuo sekėme nesėkmės metu); Programinės įrangos atnaujinimas pašalins kitą veiksnį būsimų gedimų atveju.
- Papildomas talpyklos kaupimas visame klasteryje. Mes ir toliau ieškome sričių, kuriose talpyklos talpinimas gali sumažinti duomenų bazės apkrovą.
- Pridėkite žiniatinklio programos užkardą (WAF), kad sužinotumėte, kas ir kodėl jungiasi prie quay.io.
- Nuo kito leidimo „Red Hat OpenShift“ klasteriai atsisakys programų registro ir pakeis operatorių katalogus, pagrįstus konteinerio vaizdais, esančiais quay.io.
- Ilgalaikis programų registro pakaitalas galėtų būti Open Container Initiative (OCI) artefaktų specifikacijų palaikymas. Šiuo metu ji įdiegta kaip vietinė Quay funkcija ir bus pasiekiama vartotojams, kai bus baigta pati specifikacija.
Visa tai, kas išdėstyta pirmiau, yra nuolatinių „Red Hat“ investicijų į „quay.io“ dalis, nes mes pereiname nuo mažos „startup“ stiliaus komandos prie brandžios SRE valdomos platformos. Žinome, kad daugelis mūsų klientų savo kasdieniame darbe (įskaitant Red Hat!) pasitiki quay.io, todėl stengiamės kuo skaidresni informuoti apie naujausius gedimus ir nuolatines pastangas tobulėti.
PS iš vertėjo
Taip pat skaitykite mūsų tinklaraštyje:
- «»;
- «»;
- «".
Šaltinis: www.habr.com