{"id":92073,"date":"2020-08-22T19:41:56","date_gmt":"2020-08-22T17:41:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io"},"modified":"2020-08-22T19:41:56","modified_gmt":"2020-08-22T17:41:56","slug":"post-mortem-po-nedostupnosti-quay-io","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io","title":{"rendered":"Post Mortem Quay.io k\u00e4ttesaamatuse kohta","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

M\u00e4rkus t\u00f5lke kohta.<\/b>: augusti alguses teatas Red Hat avalikult, et on lahendanud probleemid k\u00e4ttesaadavusega, mis olid tekkinud selle teenuse kasutajatele eelnevatel kuudel Quay.io<\/a><\/noindex> (selle aluseks on konteinerite piltide register, mis tuli ettev\u00f5ttele koos CoreOSi ostmisega). Olenemata teie huvist selle teenuse vastu, on \u00f5petlik j\u00e4lgida, millist teed l\u00e4bisid ettev\u00f5tte SRE-insenerid, et diagnostika ja rikke p\u00f5hjused k\u00f5rvaldada.<\/i><\/p>\n

\"Post
\n
\n19. mail, varahommikul (suvisel P\u00f5hja-Ameerika idaosas, EDT), langes quay.io teenus. Rike m\u00f5jutas nii quay.io kliente kui ka avatud l\u00e4htekoodiga projekte, mis kasutasid quay.io platvormina tarkvara koostamiseks ja levitamiseks. Red Hat hindab usaldust nii \u00fche kui teise seas.<\/p>\n

SRE-inseneride meeskond hakkas kohe t\u00f6\u00f6le ja p\u00fc\u00fcdis Quay teenuse t\u00f6\u00f6d v\u00f5imalikult kiiresti stabiliseerida. Siiski, samal ajal, kui nad sellega tegelesid, kaotasid kliendid v\u00f5imaluse uusi pilte \u00fcles laadida ja nad suudsid vaid perioodiliselt olemasolevaid t\u00f5mmata. Tundmatu p\u00f5hjusel blokeerus quay.io andmebaas teenuse t\u00e4ielikul v\u00f5imsusel skaleerimise ajal.<\/a><\/noindex><\/p>\n

\u00abMis muutus?<\/b>\u00bb \u2014 see on esimene k\u00fcsimus, mida sellistes olukordades tavaliselt k\u00fcsitakse. Me m\u00e4rkisime, et vahetult enne probleemi hakkas OpenShift Dedicated klaster (millel quay.io t\u00f6\u00f6tab) uuendama versioonile 4.3.19. Kuna quay.io t\u00f6\u00f6tab Red Hat OpenShift Dedicated (OSD) peal, olid regulaarne uuendamine igap\u00e4evane toiming ja need ei ole kunagi probleeme tekitanud. Veelgi enam, eelneva kuue kuu jooksul uuendasime me mitmel korral Quay klaustreid ilma teeninduskatkestuseta.<\/p>\n

Samas, kui me p\u00fc\u00fcdsime teenuse t\u00f6\u00f6d taastada, hakkasid teised insenerid ette valmistama uut OSD klastrit varasema tarkvaraversiooniga, et h\u00e4daolukorras k\u00f5ik selle peale v\u00e4lja panna.<\/p>\n

P\u00f5hjuslik anal\u00fc\u00fcs<\/h2>\n

\nPeamine rikke s\u00fcmptom oli k\u00fcmnete tuhandete andmebaasi \u00fchenduste laviin, mis muutis MySQL eksemplari praktiliselt funktsionaalseteks. Sellega seoses oli probleemi diagnoosimine keeruline. Panime paika kliendi \u00fchenduste maksimaalse arvu piirangu, et aidata SRE meeskonnal probleemi hinnata. Andmebaasi ei t\u00e4heldatud erakordset liiklust: tegelikult olid enamus p\u00e4ringutest lugemise p\u00e4ringud, samas kui vaid v\u00e4hesed olid kirjutamise p\u00e4ringud.<\/p>\n

Me olime ka p\u00fc\u00fcdnud leida mustri andmebaasi liikluses, mis oleks v\u00f5inud seda laviini p\u00f5hjustada. Siiski ei \u00f5nnestunud logidest mingeid seadusp\u00e4ra leida. Oodates uue klastri valmimist OSD 4.3.18, j\u00e4tkasime katseid k\u00e4ivitada pod'e quay.io. Iga kord, kui klaster j\u00f5udis maksimaalse v\u00f5imsuseni, hangus andmebaas. See t\u00e4hendas, et RDS eksemplari tuli taask\u00e4ivitada koos k\u00f5igi quay.io pod'idega.<\/p>\n

Kell \u00f5htul stabiliseerisime teenuse read-only re\u017eiimis ja keelasime maksimaalselt ebaolulised funktsioonid (nt pr\u00fcgistamise nimel ruumis), et v\u00e4hendada andmebaasi koormust. Seisakud l\u00f5ppesid, kuid p\u00f5hjust ei leitud<\/b>. Uus OSD klaster oli valmis, ning me \u00fcle kandsime teenuse, \u00fchendasime liikluse ja j\u00e4tkasime j\u00e4lgimist.<\/p>\n

Quay.io t\u00f6\u00f6tas uue OSD klastril stabiilselt, seet\u00f5ttu naasime andmebaasi logide juurde, kuid ei suutnud tuvastada korrelatsiooni, mis seletaks blokeeringuid. OpenShift'i insenerid t\u00f6\u00f6tasid koos meiega, p\u00fc\u00fcdes m\u00f5ista, kas Red Hat OpenShift 4.3.19 muudatused v\u00f5isid p\u00f5hjustada Quay probleemid. Siiski ei leitud midagi, ja probleemi laboritingimustes ei \u00f5nnestunud paljundada<\/b>.<\/p>\n

Teine rike<\/h2>\n

\n28. mail, enne keskp\u00e4eva EDT, kukkus quay.io uuesti sama s\u00fcmptomi t\u00f5ttu: andmebaasi t\u00f6\u00f6 blokeerus. Ja j\u00e4lle suunasin k\u00f5ik j\u00f5ud uurimisele. Esiteks pidi teenuse t\u00f6\u00f6 taastama. Kuid Seekord RDS taask\u00e4ivitamine ja quay.io pod'ide taask\u00e4ivitamine ei toonud tulemusi.<\/b>: andmebaasi haaras j\u00e4lle \u00fchenduste laviin. Aga miks?<\/p>\n

Quay on kirjutatud Pythonis, ning iga pod t\u00f6\u00f6tab nagu \u00fchtne monoliitne konteiner. Konteinerikeskkonnas toimub samaaegselt palju paralleelseid \u00fclesandeid. Kasutame raamatukogu gevent<\/code> alla gunicorn<\/code> veebip\u00e4ringute t\u00f6\u00f6tlemiseks. Kui Quay saab p\u00e4ringu (kas meie enda API kaudu v\u00f5i Docker API kaudu), m\u00e4\u00e4ratakse sellele gevent worker. \u00dcldiselt peaks see worker \u00fchenduma andmebaasiga. P\u00e4rast esimest rikke avastasime, et gevent worker'id \u00fcritasid andmebaasiga \u00fchendust luua vaikeseadistustega.<\/p>\n

Arvestades suur hulk Quay pod'e ja tuhandete p\u00e4ringute voogu sekundis, v\u00f5is suur hulk andmebaasi \u00fchendusi teoreetiliselt koormata MySQL eksemplari. J\u00e4lgimise j\u00e4rgi teadis Quay, et keskmiselt t\u00f6\u00f6tleb see 5000 p\u00e4ringut sekundis. Umbes sama oli ka andmebaasi \u00fchenduste number. 5000 \u00fchendust mahtus h\u00e4sti meie RDS eksemplari v\u00f5imalustesse (mida ei saa \u00f6elda k\u00fcmnete tuhandete kohta). Mingil p\u00f5hjusel toimusid ootamatud \u00fchenduste arvu plahvatused.<\/b>, kuid me ei m\u00e4rganud mingit seost sisenevate p\u00e4ringutega.<\/p>\n

Seekord otsustasime kindlalt leida ja k\u00f5rvaldada probleemi allika, mitte piirduda lihtsalt taask\u00e4ivitamisega. Quay koodibaasi tehti muudatused, mis piirasid andmebaasi \u00fchenduste arvu iga worker'i jaoks.<\/b> gevent. See arv sai konfiguratsiooni parameetriks: seda oli v\u00f5imalik muuta \"re\u017eiimis\", ilma uue konteineri pildi keeramiseta. Selleks, et teada saada, kui palju \u00fchendusi on tegelikult v\u00f5imalik k\u00e4sitleda, viidi l\u00e4bi mitu katset staging-keskkonnas, kus m\u00e4\u00e4rati erinevaid v\u00e4\u00e4rtusi, et n\u00e4ha, kuidas see m\u00f5jutab koormustestide stsenaariume. L\u00f5puks selgus, et Quay hakkab andma 502 vigu, kui \u00fchenduste arv \u00fcletab 10 000.<\/b><\/p>\n

Me paigaldasime selle uue versiooni kohe tootmisse ja hakkasime j\u00e4lgima andmebaasi \u00fchenduste graafikut. Eelmine kord blokeerus andmebaas umbes 20 minuti p\u00e4rast. 30 probleemivaba minuti p\u00e4rast tekkis meil lootus, ja tunni p\u00e4rast \u2013 kindel tunne. Taastasime kirjutustrafiku saidil ja asusime postmortem-anal\u00fc\u00fcsi juurde.<\/p>\n

Olles probleemist m\u00f6\u00f6da p\u00e4\u00e4senud, ei selgitanud me selle tegelikke p\u00f5hjuseid<\/b>. Selgus, et see ei olnud seotud \u00fchegi muudatusega OpenShift 4.3.19, kuna sama oli juhtunud ka versioonis 4.3.18, mis t\u00f6\u00f6tas Quay\u2019ga varem probleemideta.<\/p>\n

Klastris peitus ilmselt veel midagi.<\/p>\n

Detailne uurimine<\/h2>\n

\nQuay.io on kuue aasta jooksul kasutanud vaike seadistusi andmebaasi \u00fchendamiseks ilma probleemideta. Mis muutus? Selge on, et selle aja jooksul on quay.io liiklus pidevalt kasvanud. Meie puhul n\u00e4is, et saavutati mingisugune l\u00e4vendi v\u00e4\u00e4rtus, mis k\u00e4ivitas \u00fchenduste laviini. J\u00e4tkasime andmebaasi logide uurimist p\u00e4rast teist riket, kuid ei leidnud mustreid ega ilmselgeid seoseid.<\/p>\n

Samal ajal t\u00f6\u00f6tas SRE meeskond Quay p\u00e4ringute j\u00e4lgimise ja teenuse \u00fcldise tervise parandamise kallal. K\u00e4ivitatud on uusi m\u00f5\u00f5dikuid ja j\u00e4lgimispaneele<\/b>, mis n\u00e4itavad, millised Quay osad saavad klientide seas k\u00f5ige rohkem n\u00f5udlust.<\/p>\n

Quay.io t\u00f6\u00f6tas normaalselt 9. juunini. Hommikul (EDT ajal) n\u00e4gime j\u00e4lle m\u00e4rkimisv\u00e4\u00e4rset andmebaasi \u00fchenduste arvu suurenemist. Seekord ei toimunud seisakut<\/b>, kuna uus parameeter piiras nende arvu ja ei lubanud \u00fcletada MySQL-i l\u00e4bilaskev\u00f5imet. Kuid umbes poole tunni jooksul m\u00e4rkisid paljud kasutajad quay.io aeglast toimimist. Kogusime kiiresti k\u00f5ik v\u00f5imalikud andmed, kasutades lisatud j\u00e4lgimisvahendeid. \u00c4kitselt ilmnes muster.<\/p>\n

Enne \u00fchenduste arvu h\u00fcpet tuli suur hulk p\u00e4ringuid App Registry API-le<\/b>. App Registry on quay.io v\u00e4hemtuntud funktsioon. See v\u00f5imaldab salvestada selliseid asju nagu Helm\u2019i graafikud ja rikkalike (rich) metaandmetega konteinerid. Enamik quay.io kasutajatest ei kasuta seda funktsiooni, kuid Red Hat OpenShift kasutab seda aktiivselt. OpenShifti osa OperatorHub salvestab k\u00f5ik operaatorid App Registry-s. Need operaatorid moodustavad aluse OpenShifti t\u00f6\u00f6koormuste \u00f6kos\u00fcsteemile ja partneritele suunatud operatsioonide (teise p\u00e4eva operatsioonid, Day 2) mudelile.<\/p>\n

Iga OpenShift 4 klaster kasutab sisseehitatud OperatorHub'i operaatorite levitamiseks, et pakkuda installimiseks saadaval olevate operaatorite katalooge ja pakkuda v\u00e4rskendusi juba paigaldatud operaatoritele. OpenShift 4 populaarsuse kasvades kasvas ka maailmas klastrite arv. Iga neist klastritest laadib operaatorite sisu, et k\u00e4ivitada sisseehitatud OperatorHub, kasutades quay.io's App Registryt tagaplaanina. Probleemi allika otsimisel j\u00e4tsime t\u00e4helepanuta, et koos OpenShift'i kasvava populaarsusega kasvas ka koormus \u00fchele harva kasutatud funktsioonile quay.io.<\/b>.<\/p>\n

Me tegime v\u00e4ikese anal\u00fc\u00fcsi App Registry p\u00e4ringute liiklusest ja vaatasime registri koodi. Koheselt ilmnesid puudused, mis tekitasid andmebaasi p\u00e4ringute ebaoptimaalset vormimist. Madala koormuse korral ei tekitanud need mingeid probleeme, kuid nende suurenedes said need probleemide allikaks. App Registry'l olid kaks probleemset l\u00f5pp-punkti, mis reageerisid halvasti koormuse suurenemisele: esimene andis v\u00e4lja k\u00f5igi pakettide loendi hoidlas, teine - k\u00f5ik blob'id paketi jaoks.<\/p>\n

Probleemide likvideerimine<\/h2>\n

\nJ\u00e4rgneva n\u00e4dala jooksul tegelesime App Registry koodi ja selle keskkonna optimeerimisega. \u00dcksikasjalikult ebaefektiivsed SQL-p\u00e4ringud viidi \u00fcle ning eemaldati tarbetud k\u00e4su kutsed (need k\u00e4ivitati iga blob\u2019i v\u00e4ljav\u00f5tte ajal), kanti sisse vahem\u00e4lu k\u00f5ikjal, kus see on v\u00f5imalik. Seej\u00e4rel viidi l\u00e4bi ulatuslik j\u00f5udlustestimine ja v\u00f5rreldi App Registry t\u00f6\u00f6 kiirus muutuste eel ja j\u00e4rel. tar<\/code> (ta k\u00e4ivitati iga kord, kui loodi blob'e), sinna on lisatud vahem\u00e4lu, kus see v\u00f5imalik. Seej\u00e4rel viidi l\u00e4bi ulatuslik j\u00f5udluse testimine ja v\u00f5rdleti App Registry t\u00f6\u00f6kiirus enne ja p\u00e4rast muudatusi.<\/p>\n

. J\u00e4rgmisel n\u00e4dalal v\u00f5tsime muudatused kasutusele tootmises ja p\u00e4rast seda on quay.io t\u00f6\u00f6tanud stabiilselt. Selle aja jooksul t\u00e4heldati mitmeid j\u00e4rske liikluspiike App Registry l\u00f5pp-punktis, kuid teostatud t\u00e4iustused v\u00e4ltisid andmebaasi katkemisi.<\/b>. J\u00e4rgmise n\u00e4dala jooksul juurutasime muudatused tootmisse ning sellest ajast alates t\u00f6\u00f6tab quay.io stabiilselt. Sel ajal toimus mitu j\u00e4rsku liikluse t\u00f5usu App Registry l\u00f5pp-punktis, kuid tehtud t\u00e4iustused takistasid andmebaasi katkemist.<\/p>\n

Selge on, et iga teenus p\u00fc\u00fcab v\u00e4ltida seisakuid. Meie puhul usume, et hiljutised katkestused aitasid teha quay.io paremaks. Meie jaoks t\u00f5ime v\u00e4lja mitmed peamised \u00f5ppetunnid, mida soovime jagada:<\/h2>\n

\nTeave selle kohta, kes ja kuidas teie teenust kasutab, ei ole kunagi \u00fcleliigne.<\/p>\n

    \n
  1. Kuna Quay \u201elihtsalt t\u00f6\u00f6tas\u201d, ei olnud meil kunagi vajadust kulutada aega liikluse optimeerimisele ja koormuse haldamisele. See tekitas vale turvatunde, et teenus suudab skaleeruda l\u00f5putult.<\/b>Kui teenus kukub,<\/li>\n
  2. siis selle t\u00f6\u00f6korda tagasi toomine on peamine prioriteet. tema t\u00f6\u00f6 taastamine on peamine prioriteet<\/b>. Kuna Quay j\u00e4tkas blokeeritud andmebaasist kannatamist esimese rikkumise ajal, ei avaldanud meie standardsed protseduurid oodatud m\u00f5ju ja me ei suutnud teenuse toimimist nende abil taastada. See viis olukorrani, kus pidime veetma aega anal\u00fc\u00fcsimiseks ja andmete kogumiseks lootuses leida p\u00f5hjus \u2014 selle asemel, et suunata k\u00f5ik j\u00f5upingutused teenuse taastamiseks.<\/li>\n
  3. Hinnake iga teenuse funktsiooni m\u00f5ju<\/b>. Klientide seas oli App Registry harva kasutusel, seet\u00f5ttu polnud see meie meeskonnale prioriteet. Kui m\u00f5ned toote funktsioonid on peaaegu kasutamata, siis ilmuvad nende vead harva ning arendajad l\u00f5petavad koodi j\u00e4lgimise. On lihtne langeda valearusaama k\u00fc\u00fcsi, et nii peabki olema \u2014 kuni see funktsioon \u00fcht\u00e4kki satub suurema kohaliku intsidenti keskmesse.<\/li>\n<\/ol>\n

    <\/p>\n

    Mis edasi?<\/h2>\n

    \nTeenuse stabiilsuse tagamise t\u00f6\u00f6 ei peatu kunagi ja me t\u00e4iustame seda pidevalt. Liiklus quay.io-l j\u00e4tkab kasvu, ja me oleme teadlikud, et peame tegema k\u00f5ik endast oleneva, et \u00f5igustada klientide usaldust. Seet\u00f5ttu t\u00f6\u00f6tame praegu j\u00e4rgmiste probleemide kallal:<\/p>\n

      \n
    1. Lugemisega andmebaasi koopiate juurutamine, et aidata teenusel probleemide korral vastavat liiklust t\u00f6\u00f6delda peamise RDS-instantsi puhul.<\/li>\n
    2. RDS-instantsi v\u00e4rskendamine. Praegune versioon iseenesest pole probleem. Pigem tahame lihtsalt k\u00f5rvaldada valej\u00e4lje (millele me esimese rikkumise ajal j\u00e4ime); tarkvara ajakohasena hoidmine v\u00e4ldib veel \u00fche teguri, mis v\u00f5iks tulevaste katkestuste korral muret tekitada.<\/li>\n
    3. Lisak\u00fcsimine kogu klastris. J\u00e4tkame piirkondade otsimist, kus k\u00fcsimise abil saab andmebaasi koormust v\u00e4hendada.<\/li>\n
    4. Veebirakenduste tulem\u00fc\u00fcri (WAF) lisamine, et n\u00e4ha, kes ja miks \u00fchendab quay.io-le.<\/li>\n
    5. Alates j\u00e4rgmisest versioonist loobuvad Red Hat OpenShift'i klastrid App Registry'st, eelistades konteinerite p\u00f5hiseid operaatorikatalooge (Operator Catalogs), mis on saadaval quay.io-l.<\/li>\n
    6. Pikaajaline asendaja App Registry jaoks v\u00f5ib olla Open Container Initiative'i (OCI) artefaktide spetsifikatsioonide tugi. See on praegu ellu viidud Quay natiivse funktsioonina ja on kasutajatele saadaval, kui spetsifikatsioon l\u00f5puks koosk\u00f5lastatakse.<\/li>\n<\/ol>\n

      \nK\u00f5ik eespool loetletud on osa Red Hati j\u00e4tkuvatest investeeringutest quay.io, kui liikume edasi v\u00e4ikesest \"start-up\"-stiilis meeskonnast k\u00fcpsesse platvormi, mida haldab SRE. Me teame, et paljud meie kliendid usaldavad quay.io oma igap\u00e4evaelus (sealhulgas Red Hat!) ja p\u00fc\u00fcame olla nii avatud kui v\u00f5imalik viimaste t\u00f5rgete ja j\u00e4tkuvate pingutuste osas, et paremaks saada.<\/p>\n

      P.S. t\u00f5lkijalt<\/h2>\n

      \nLugege ka meie blogist:<\/p>\n