Shën. përkth.: në fillim të gushtit, Red Hat publikisht njoftoi për zgjidhjen e problemeve të disponueshmërisë që kishin ndodhur gjatë muajve të kaluar për përdoruesit e shërbimit të saj. (në themel të tij është një regjistër për imazhet e kontejnerëve, që i ka kaluar kompanisë me blerjen e CoreOS). Pavarësisht interesit tuaj në këtë shërbim si i tillë, rruga që kanë ndjekur inxhinierët SRE të kompanisë për diagnostikimin dhe zgjidhjen e arsyeve të aksidentit është mësuese.
Në 19 maj, në mëngjesin e hershëm (sipër orës verore të Shteteve të Bashkuara, EDT), shërbimi quay.io ra. Aksidenti preku si konsumatorët e quay.io ashtu edhe projektet Open Source që përdorin quay.io si platformë për ndërtimin dhe shpërndarjen e softuerit. Red Hat e vlerëson besimin e të dyve.
Ekipi i inxhinierĂ«ve SRE menjĂ«herĂ« u angazhua nĂ« punĂ« dhe u pĂ«rpoq tĂ« stabilizonte sa mĂ« shpejt shĂ«rbimin Quay. MegjithatĂ«, derisa ata merreshin me kĂ«tĂ«, klientĂ«t humbĂ«n mundĂ«sinĂ« pĂ«r tĂ« pushâuar imazhe tĂ« reja, dhe vetĂ«m herĂ« pas here u arrin tĂ« pullâojnĂ« ato ekzistuese. PĂ«r njĂ« arsye tĂ« panjohur, baza e tĂ« dhĂ«nave tĂ« quay.io u bllokua pas shkallĂ«zimit tĂ« shĂ«rbimit nĂ« kapacitet tĂ« plotĂ«.
«ĂfarĂ« ka ndryshuar?» â Ă«shtĂ« pyetja e parĂ« qĂ« pranohet tĂ« bĂ«het nĂ« raste tĂ« tilla. VĂ«rejtĂ«m se disa kohĂ« pĂ«rpara problemit, klasteri OpenShift Dedicated (nĂ« tĂ« cilin funksionon quay.io) filloi tĂ« pĂ«rditĂ«sohej nĂ« versionin 4.3.19. Duke qenĂ« se quay.io funksionon nĂ« Red Hat OpenShift Dedicated (OSD), pĂ«rditĂ«simet e rregullta ishin njĂ« operacion i zakonshĂ«m dhe kurrĂ« nuk kishin sjellĂ« probleme. PĂ«r mĂ« tepĂ«r, gjatĂ« gjashtĂ« muajve tĂ« kaluar kemi pĂ«rditĂ«suar disa herĂ« klasterĂ«t Quay pa pauses nĂ« shĂ«rbim.
Ndërsa ne përpiqeshim të rregullonim shërbimin, inxhinierë të tjerë filluan të përgatitin një klaster të ri OSD me versionin e mëparshëm të softuerit, në mënyrë që në rast nevoje të mund të rikthenin gjithçka aty.
Analiza e arsyeve kryesore
Simptomë kryesore e dështimit ishte një valë e dhjetëra mijëra lidhjeve me DB, për shkak të së cilës ekzemplari MySQL u bë praktikisht i paaftë. Për këtë shkak, ishte e vështirë të diagnostikohej problemi. Ne vendosëm një kufizim në numrin maksimal të lidhjeve nga klientët për të ndihmuar ekipin SRE të vlerësojë problemin. Nuk u vunë re ndonjë trafik të pazakontë në bazën e të dhënave: në të vërtetë, shumica e kërkesave ishin për lexim, ndërsa vetëm disa për shkrim.
Ne pĂ«rpiqemi gjithashtu tĂ« identifikojmĂ« njĂ« model nĂ« trafikun e DB-sĂ« qĂ« mund tĂ« kishte shkaktuar kĂ«tĂ« cunami. SidoqoftĂ«, nuk arritĂ«m tĂ« gjenim asnjĂ« rregullsi nĂ« logĂ«t. Duke pritur gatishmĂ«rinĂ« e klasterit tĂ« ri me OSD 4.3.18, vazhduam pĂ«rpjekjet pĂ«r tĂ« nisur podâĂ«t e quay.io. Ădo herĂ« qĂ« klasteri arrinte kapacitetin e tij maksimal, baza e tĂ« dhĂ«nave ngeciste. Kjo nĂ«nkuptonte se ishte e nevojshme tĂ« rinisnim instancĂ«n RDS pĂ«rveç tĂ« gjithĂ« podâĂ«ve tĂ« quay.io.
Më në fund, ne stabilizuam shërbimin në modin read-only dhe çaktivizuam shumicën e funksioneve jo të rëndësishme (siç është mbledhja e mbetjeve në hapësirën e emrave) për të ulur ngarkesën në DB. Ngecjet ndaluan, por arsyeja as nuk u gjet. Klasteri i ri OSD ishte gati, dhe ne e transferuam shërbimin, lidhëm trafikun dhe vazhduam monitorimin.
Quay.io funksionoi stabilisht në klasterin e ri OSD, kështu që u kthyem në logët e bazës së të dhënave, por sërish nuk arritëm të zbulonim ndonjë korelacion që shpjegonte bllokimet. Inxhinierët e OpenShift punuan ngushtë me ne, duke përpiqur të kuptonin nëse ndryshimet në Red Hat OpenShift 4.3.19 mund të ishin shkaku i problemeve me Quay. Sidoqoftë, nuk gjetëm asgjë dhe nuk arritëm të riprodhonim problemin në kushte laboratorike.
Dështimi i dytë
MĂ« 28 maj, pak para mesditĂ«s sipas EDT, quay.io sĂ«rish ra me tĂ« njĂ«jtin simptomĂ«: funksionimi i bazĂ«s sĂ« tĂ« dhĂ«nave ishte bllokuar. Dhe sĂ«rish hodhĂ«m tĂ« gjitha forcat tona nĂ« hetim. Para sĂ« gjithash, duhej tĂ« rikthenim funksionimin e shĂ«rbimit. MegjithatĂ« nĂ« kĂ«tĂ« rast rinisja e RDS dhe rinisja e podâĂ«ve tĂ« quay.io nuk sollĂ«n asnjĂ« rezultat: njĂ« tjetĂ«r cunami lidhjesh pĂ«rmbyti bazĂ«n. Por pse?
Quay është shkruar në Python, dhe çdo pod funksionon si një enë monolitike. Në ambientin e funksionimit të kontejnerit, shumë detyra përparësore ekzekutohen në të njëjtën kohë. Ne përdorim bibliotekën gevent me gunicorn për të trajtuar kërkesat e web-it. Kur Quay merr një kërkesë (nëpërmjet API-së tonë ose nëpërmjet API-së së Docker), i caktohet një punëtor gevent. Zakonisht, ky punëtor duhet të lidhet me bazën e të dhënave. Pas dështimit të parë, zbuluam se punëtorët gevent po lidhen me bazën e të dhënave duke përdorur cilësimet e parazgjedhura.
Duke pasur njĂ« numĂ«r tĂ« konsiderueshĂ«m podâash Quay dhe mijĂ«ra kĂ«rkesa tĂ« pranuara nĂ« sekondĂ«, njĂ« numĂ«r i madh lidhjesh me bazĂ«n e tĂ« dhĂ«nave teoriisht mund tĂ« kishte mbingarkuar instancĂ«n MySQL. Duke u monitoruar, u zbulua se Quay, nĂ« mesatare, trajtonte 5,000 kĂ«rkesa nĂ« sekondĂ«. Numri i lidhjeve me bazĂ«n e tĂ« dhĂ«nave ishte rreth tĂ« njĂ«jtĂ«s vlerĂ«. 5,000 lidhje ishin brenda kapaciteteve tĂ« instancĂ«s sonĂ« RDS (ndryshe nga dhjetĂ«ra mijĂ«ra). PĂ«r njĂ« arsye, ndodhnin shpĂ«rthime tĂ« papritura nĂ« numrin e lidhjeve., megjithatĂ« ne nuk vĂ«zhguam ndonjĂ« korelacion me kĂ«rkesat e ardhshme.
Tani, ne e vendosëm veten të gjenim dhe të eliminonim burimin e problemit, dhe jo të mjaftoheshim me rindezjen. Në kodin e bazës Quay u bënë ndryshime që kufizojnë numrin e lidhjeve me DB për çdo punëtor gevent. Ky numër u bë një parametër në konfigurim: tani ishte e mundur ta ndryshonim "në flakë", pa ndërtuar një imazh të ri kontejneri. Për të mësuar se sa lidhje mund të trajtonte realisht, u zhvilluan disa teste me ambientin staging, ku u vendosën vlera të ndryshme për të parë se si do të përkonte me skenarët e testeve të ngarkesës. Në fund u zbulua se Quay fillon të japë gabime 502 kur numri i lidhjeve kalon 10,000.
MenjĂ«herĂ« e disa variantĂ« e re e kĂ«saj versioni nĂ« prodhim dhe filluam tĂ« monitoronim grafikĂ«n e lidhjeve me bazĂ«n e tĂ« dhĂ«nave. NĂ« tĂ« kaluarĂ«n, baza ishte bllokuar rreth 20 minuta. Pas 30 minutash pa probleme, kishim shpresĂ«, dhe pas njĂ« ore â siguri. RindĂ«rtuam trafikun pĂ«r shkrim nĂ« sit dhe filluam analizĂ«n postmortem.
Duke arritur të anashkalojmë problemin që shkaktonte bllokimin, ne nuk zbuluam shkaqet e saj të vërteta. U konfirmua se nuk ishte e lidhur me ndonjë ndryshim në OpenShift 4.3.19, pasi e njëjta gjë ndodhi edhe në versionin 4.3.18, i cili kishte punuar me Quay pa ndonjë problem.
Në klaster qartë se kishte diçka tjetër të fshehur.
Studimi i detajuar
Quay.io ka pĂ«rdorur pĂ«r gjashtĂ« vjet cilĂ«simet e paracaktuara pĂ«r t'u lidhur me DB pa asnjĂ« problem. ĂfarĂ« ka ndryshuar? ĂshtĂ« e qartĂ« se gjatĂ« gjithĂ« kĂ«tij kohĂ«, trafiku nĂ« quay.io Ă«shtĂ« rritur nĂ« mĂ«nyrĂ« tĂ« pandĂ«rprerĂ«. NĂ« rastin tonĂ«, gjithçka dukej sikur ishte arritur njĂ« kuotĂ« e caktuar, e cila shĂ«rbente si nxitĂ«s pĂ«r njĂ« valĂ« lidhjesh. Ne vazhduam tĂ« shqyrtonim logĂ«t e DB pas dĂ«shtimit tĂ« dytĂ«, por nuk gjetĂ«m asnjĂ« model ose lidhje tĂ« dukshme.
Ndërkohë ekipi SRE ishte angazhuar në përmirësime në fushën e monitorimit të kërkesave në Quay dhe shëndetit të përgjithshëm të shërbimit. Iu vendosën metrika dhe panele të reja monitorimi, duke treguar se cilat pjesë të Quay shfrytëzoheshin më shumë nga klientët.
Quay.io ka punuar normalisht deri më 9 qershor. Në mëngjes (sipër EDT) ne përsëri ishim dëshmitarë të një rritjeje të konsiderueshme të numrit të lidhjeve me bazën e të dhënave. Këtë herë nuk ndodhi asnjë ndërprerje, pasi parametri i ri kufizonte numrin e tyre dhe nuk lejonte të kalonte kapacitetin e MySQL. Megjithatë, për një periudhë prej rreth gjysmë ore, shumë përdorues raportuan për ngarkesë të ngadalta në quay.io. Ne shpejt mblodhëm të gjitha të dhënat e mundshme, duke shfrytëzuar mjetet e monitorimit të shtuar. Papritmas, një model u bë i dukshëm.
Para saktësisht shkarkimit të numrit të lidhjeve, një sasi e madhe kërkesash kishte ardhur në API-në e Regjistrit të Aplikacioneve. Regjistri i Aplikacioneve është një funksion pak i njohur në quay.io. Ai lejon ruajtjen e gjërave si grafikat Helm dhe kontejnerët me meta të pasura. Shumica e përdoruesve të quay.io nuk punojnë me këtë funksion, megjithatë ai shfrytëzohet aktivisht nga Red Hat OpenShift. OperatorHub në OpenShift ruan të gjithë operatorët në Regjistrin e Aplikacioneve. Këta operatorë formojnë bazën e ekosistemit të ngarkesave të punës OpenShift dhe modelit operativ (në kuadër të operacioneve të 'ditës së dytë', Day 2), të orientuar ndaj partnerëve.
Ădo klaster OpenShift 4 pĂ«rdor operatorĂ« nga OperatorHub i integruar pĂ«r tĂ« publikuar njĂ« katalog operatorĂ«sh, tĂ« disponueshĂ«m pĂ«r instalim, dhe pĂ«r tĂ« ofruar pĂ«rditĂ«sime pĂ«r ato qĂ« janĂ« instaluar. Me rritjen e popullaritetit tĂ« OpenShift 4, Ă«shtĂ« rritur gjithashtu numri i klastereve mbi tĂ« nĂ« tĂ« gjithĂ« botĂ«n. Ădo njĂ«ri prej kĂ«tyre klastereve ngarkon pĂ«rmbajtjen e operatorĂ«ve pĂ«r tĂ« aktivizuar OperatorHub-in e integruar, duke pĂ«rdorur Regjistrin e Aplikacioneve brenda quay.io si backend. NĂ« kĂ«rkimin e burimit tĂ« problemit, ne lamĂ« pas atĂ« qĂ«, me rritjen e gradualshme tĂ« popullaritetit tĂ« OpenShift, rriteshin edhe ngarkesat nĂ« njĂ« nga funksionet e rralla tĂ« pĂ«rdorura quay.io..
Kemi kryer një analizë të trafikut të kërkesave të App Registry dhe kemi kontrolluar kodin e regjistrit. Menjëherë dolën në pah mangësi, për shkak të të cilave kërkesat në bazën e të dhënave formoheshin në mënyrë jo optimale. Në ngarkesë të vogël ato nuk shkaktonin ndonjë shqetësim, por me rritjen e saj bëheshin burim problemesh. App Registry kishte dy endpoint të problematikë që nuk reagojnë mirë ndaj rritjes së ngarkesës: i pari jepte një listë të të gjitha pakove në depo, i dyti ktheu të gjitha blob-et për paketën.
Eliminimi i shkakut
Gjatë javës pasuese, ne u angazhuam në optimizimin e kodit të vetë App Registry dhe mjedisit të tij. U rishikuan SQL-query-të që ishin qartë të paefektshme, u hoqën thirrjet e panevojshme të komandës tar (ajo aktivizohej gjatë çdo nxjerrjeje blob-esh), u shtua caching kudo që ishte e mundur. Më pas u krye një testim i gjerë i performancës dhe u krahasua shpejtësia e punës së App Registry para dhe pas ndryshimeve.
Kërkesat API, që më parë merrnin deri në gjysmë minute, tani u ekzekutuan në milisekonda.. Javën e ardhshme ne e shpërndamë ndryshimin në production, dhe që atëherë quay.io funksionon me stabilitet. Gjatë këtij kohë, ishin vërejtur disa shpërthime të papritura në trafikun në endpoint-in e App Registry, por përmirësimet e bëra parandaluan ndërprerjet në funksionimin e databazës.
ĂfarĂ« mĂ«suam?
ĂshtĂ« e qartĂ« qĂ« çdokĂ«rkush mundohet tĂ« shmangĂ« ndalesat. NĂ« rastin tonĂ«, ne besojmĂ« se prishjet e fundit ndihmuan nĂ« pĂ«rmirĂ«simin e quay.io. PĂ«r vete nxorĂ«m disa mĂ«sime tĂ« rĂ«ndĂ«sishme qĂ« duam tĂ« ndajmĂ«:
- Të dhënat se kush dhe si përdor shërbimin tuaj nuk janë kurrë të panevojshme.. Pasi Quay "thjesht funksiononte", kurrë nuk na erdhi në mendje të harxhonim kohë në optimizimin e trafikëve dhe menaxhimin e ngarkesës. E gjithë kjo krijoi një ndjenjë të rreme të sigurisë, që shërbimi mund të shkallëzohej pafundësisht.
- Kur shĂ«rbimi bie, rikthimi nĂ« funksionim Ă«shtĂ« prioriteti kryesor.. NdĂ«rsa Quay vazhdoi tĂ« vuajĂ« nga njĂ« bazĂ« tĂ« dhĂ«nash tĂ« bllokuar gjatĂ« dĂ«shtimit tĂ« parĂ«, procedurat tona standarde nuk kishin efektin e pritur dhe ne nuk arritĂ«m ta rikthejmĂ« funksionimin e shĂ«rbimit me ndihmĂ«n e tyre. Kjo çoi nĂ« njĂ« situatĂ« ku duhej tĂ« harxhonim kohĂ« nĂ« analizĂ« dhe mbledhje tĂ« tĂ« dhĂ«nave me shpresĂ«n pĂ«r tĂ« gjetur shkakun themelor â nĂ« vend qĂ« tĂ« pĂ«rqendrohemi nĂ« rikthimin e funksionalitetit.
- VlerĂ«soni ndikimin e çdo funksioni tĂ« shĂ«rbimit. KlientĂ«t rrallĂ« e pĂ«rdornin Regjistrin e Aplikacioneve, kĂ«shtu qĂ« ai nuk ishte prioritet pĂ«r ekipin tonĂ«. Kur disa funksione tĂ« produktit zakonisht nuk pĂ«rdoren, defektet e tyre 'shfaqen' rrallĂ«, dhe zhvilluesit ndalojnĂ« sĂ« mbikĂ«qyruri kodin. ĂshtĂ« e lehtĂ« tĂ« bĂ«hesh viktimĂ« e njĂ« iluzioni se kĂ«shtu duhet tĂ« jetĂ« â derisa papritmas ky funksion tĂ« pĂ«rfshihet nĂ« njĂ« incident tĂ« madh.
ĂfarĂ« ndodh mĂ« tej?
Puna për të siguruar stabilitetin e shërbimit nuk ndalon kurrë dhe ne po e përmirësojmë vazhdimisht atë. Volumet e trafikut në quay.io vazhdojnë të rriten, dhe ne e kuptojmë se jemi të detyruar të bëjmë gjithçka të mundshme për të justifikuar besimin e klientëve. Prandaj, aktualisht kemi si detyra:
- Zhvillimi i replika të bazave të dhënash vetëm për lexim, për të ndihmuar shërbimin të përballojë trafikun përkatës në rast se ndodhin probleme me ekzemplarët kryesorë të RDS.
- Përditësimi i ekzemplarit RDS. Versioni aktual vetë nuk është një problem. Më tepër, thjesht duam të heqim ndjekjen e rreme (në të cilën shkuam gjatë dështimit); mbajtja e softuerit në gjendje të përditësuar do të eliminojë një tjetër faktor në rast të çlirimeve të ardhshme.
- Caching të shtuar në të gjithë klasterin. Ne vazhdojmë të kërkojmë fusha ku caching mund të ndihmojë për të ulur ngarkesën në bazën e të dhënave.
- Shtimi i një firewall-i për aplikacione web (WAF), për të parë kush dhe pse lidhet me quay.io.
- Nga rilizimi i ardhshëm, klasterët Red Hat OpenShift do të përjashtojnë Regjistrin e Aplikacioneve në favor të katalogëve të operatorëve (Operator Catalogs), të bazuar në imazhe kontejnerësh të disponueshme në quay.io.
- Zëvendësimi afatgjatë i Regjistrit të Aplikacioneve mund të jetë mbështetja për specifikimet e artefakteve të Iniciativës së Kontejnerëve Open (OCI). Aktualisht, kjo po realizohet si një funksionalitet vendas i Quay dhe do të jetë në dispozicion për përdoruesit, kur specifikimi vetë të miratohet përfundimisht.
Gjitha ato qĂ« pĂ«rmenden mĂ« sipĂ«r janĂ« pjesĂ« e investimeve tĂ« vazhdueshme tĂ« Red Hat nĂ« quay.io ndĂ«rsa kalojmĂ« nga njĂ« ekip i vogĂ«l "nĂ« stilin e njĂ« startupi" nĂ« njĂ« platformĂ« tĂ« zhvilluar, tĂ« menaxhuar nga SRE. E dimĂ« se shumĂ« nga klientĂ«t tanĂ« mbĂ«shteten nĂ« quay.io pĂ«r punĂ«n e tyre tĂ« pĂ«rditshme (pĂ«rfshirĂ« Red Hat!) dhe pĂ«rpiqemi tĂ« jemi sa mĂ« tĂ« hapur nĂ« rrugĂ«n tonĂ« pĂ«r tĂ« adresuar çështjet e fundit dhe pĂ«rpjekjet tona pĂ«r tâu bĂ«rĂ« mĂ« tĂ« mirĂ«.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «».
Burimi: habr.com
