Shën. përk.: në fillim të gushtit, Red Hat publikoi informacion në lidhje me zgjidhjet për problemet e aksesit që ishin paraqitur gjatë muajve të fundit për përdoruesit e shërbimit të saj (në themel ka një regjistër për imazhe kontejnerësh, i ardhur nga blerja e CoreOS). Pavarësisht interesit tuaj për këtë shërbim, rruga që ndjekin inxhinierët SRE të kompanisë për diagnostikimin dhe zgjidhjen e shkaqeve të aksidenteve është edukative.
Më 19 maj, në mëngjesin e hershëm (sipër orarit veror të Amerikës Veriore, EDT), shërbimi quay.io ra. Aksidenti ndikoi si në konsumatorët e quay.io, ashtu edhe në projektet Open Source që përdorin quay.io si platformë për ndërtimin dhe shpërndarjen e softuerit. Red Hat vlerëson besimin e të dyve.
Skeda e inxhinierëve SRE u angazhua menjëherë dhe përpiqeshin të stabilizonin shërbimin Quay sa më shpejt të ishte e mundur. Megjithatë, ndërsa ishin në këtë proces, klientët humbën mundësinë për të dërguar imazhe të reja, dhe vetëm nganjëherë arritën të tërhiqnin të ekzistueshmet. Për shkak të një shkaku të panjohur, baza e të dhënave të quay.io u bllokua pas shkallëzimit të shërbimit në kapacitet të plotë.
«ĂfarĂ« ndryshoi?» â Ă«shtĂ« pyetja e parĂ« qĂ« pritet tĂ« bĂ«het nĂ« rastet e tilla. VĂ«rejtĂ«m se pak para problemeve, klasteri OpenShift Dedicated (ku funksionon quay.io) filloi tĂ« pĂ«rmirĂ«sohej nĂ« versionin 4.3.19. MeqenĂ«se quay.io funksionon mbi Red Hat OpenShift Dedicated (OSD), pĂ«rmirĂ«simet e rregullta kanĂ« qenĂ« njĂ« operacion i zakonshĂ«m dhe kurrĂ« nuk kanĂ« shkaktuar probleme. PĂ«r mĂ« tepĂ«r, gjatĂ« gjashtĂ« muajve tĂ« fundit kemi pĂ«rmirĂ«suar disa herĂ« klasterĂ«t Quay pa ndonjĂ« ndĂ«rprerje nĂ« shĂ«rbim.
Ndërsa po përpiqeshim të rikthenim shërbimin, inxhinierë të tjerë filluan të përgatisin një klaster të ri OSD me versionin e mëparshëm të softuerit, për t'u implementuar në rast nevoje.
Analiza e shkakut të parë
Simptoma kryesore e dështimit ishte një avalanxha e dhjetëra mijëra lidhjeve me bazën e të dhënave, që e bëri ekzemplarin MySQL në fakt të papërdorshëm. Për këtë arsye, ishte e vështirë të diagnostikohej problemi. Vendosëm një kufizim në numrin maksimal të lidhjeve nga klientët, për të ndihmuar ekipin SRE të vlerësojë problemin. Nuk vërejtëm asnjë trafik të pazakontë në bazën e të dhënave: në fakt, shumica e kërkesave ishin për lexim, dhe vetëm disa për shk writing.
Ne pĂ«rpoqĂ«m gjithashtu tĂ« identifikonim njĂ« model nĂ« trafikun e DB-sĂ« qĂ« mund tĂ« kishte shkaktuar kĂ«tĂ« pĂ«rmbytje. MegjithatĂ«, nuk arritĂ«m tĂ« gjejmĂ« asnjĂ« lidhje nĂ« log-et. Duke pritur gatishmĂ«rinĂ« e grupit tĂ« ri me OSD 4.3.18, vazhduam pĂ«rpjekjet pĂ«r tĂ« nisur podâĂ«t quay.io. Ădo herĂ« qĂ« grupi arrinte kapacitetin e plotĂ«, baza e tĂ« dhĂ«nave ngjiste. Kjo do tĂ« thoshte se ishte e nevojshme tĂ« ripaguhej njĂ« instancĂ« RDS pĂ«rveç tĂ« gjitha podâĂ«ve quay.io.
Në mbrëmje, ne stabilizuam shërbimin në modalitetin read-only dhe çuam jashtë maksimumin e funksioneve të pavlerë (p.sh., grumbullimin e mbetjeve në hapësirën e emrave) për të ulur ngarkesën në DB. Ngritjet u ndalën, por shkaku nuk u gjet asnjëherë. Klasa e re OSD ishte gati, dhe ne transferuam shërbimin, lidhëm trafikun dhe vazhduam monitorimin.
Quay.io funksionoi stabilisht në klasën e re OSD, prandaj ne u kthyem në log-et e bazës së të dhënave, por nuk arritëm të zbulojmë një korelacion që shpjegonte bllokime. Inxhinierët e OpenShift punuan së bashku me ne, duke u munduar të kuptonin nëse ndryshimet në Red Hat OpenShift 4.3.19 mund të kishin sjellë probleme me Quay. Megjithatë, nuk u zbulua asgjë. nuk nuk arritëm të riprodhojmë problemin në kushte laboratorik.
Dështimi i dytë
MĂ« 28 maj, pak para mesditĂ«s sipas EDT, quay.io pĂ«soi sĂ«rish rĂ«nie me simptomat e njĂ«jta: funksionimi i bazĂ«s sĂ« tĂ« dhĂ«nave u bllokua. SĂ«rish, ne vendosĂ«m tĂ« hedhim tĂ« gjitha forcat nĂ« hetim. E para, duhej tĂ« rikthenim funksionimin e shĂ«rbimit. SidoqoftĂ« kĂ«tĂ« herĂ« ripagesa e RDS dhe rinisja e podâĂ«ve quay.io nuk kishin rezultat: njĂ« valĂ« tjetĂ«r lidhjesh pĂ«rmbyti bazĂ«n. Por pse?
Quay është shkruar në Python, dhe çdo pod funksionon si një enë monolitike. Në mjedisin e ekzekutimit të enës, shumë detyra të shumta ekzekutohen paralelisht. Ne përdorim bibliotekën gevent nën gunicorn për të trajtuar kërkesat në web. Kur në Quay mbërrin një kërkesë (përmes API tonë, ose përmes API të Docker-it), 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 që punëtorët gevent po lidhen me bazën e të dhënave duke përdorur konfigurimet e paracaktuar.
Duke marrĂ« parasysh numrin e konsiderueshĂ«m tĂ« podâave Quay dhe mijĂ«ra kĂ«rkesave qĂ« mbĂ«rrijnĂ« çdo sekondĂ«, njĂ« numĂ«r i madh lidhjesh nĂ« bazĂ«n e tĂ« dhĂ«nave teoretikisht mund ta tepronte instancĂ«n MySQL. FalĂ« monitorimit, ishte e njohur se Quay, nĂ« mesatare, pĂ«rpunonte 5 mijĂ« kĂ«rkesa nĂ« sekondĂ«. Numri i lidhjeve nĂ« bazĂ«n e tĂ« dhĂ«nave ishte afĂ«rsisht i njĂ«jtĂ«. 5 mijĂ« lidhje me qetĂ«si pĂ«rputheshin me kapacitetet e instancĂ«s sonĂ« RDS (çfarĂ« nuk mund tĂ« thuhet pĂ«r dhjetĂ«ra mijĂ«ra). PĂ«r njĂ« arsye tĂ« caktuar ndodhnin shpĂ«rthime tĂ« papritura tĂ« numrit tĂ« lidhjeve, megjithatĂ« ne nuk vĂ«mĂ« re ndonjĂ« korrelacion me kĂ«rkesat qĂ« arrinin.
Këtë herë ne vendosëm të gjejmë dhe eliminojmë burimin e problemit, dhe jo thjesht të kufizohemi me rindezjen. Në kodin bazë të Quay u bënë ndryshime, që kufizojnë numrin e lidhjeve në DB për çdo worker gevent. Ky kyç u bë një parametër në konfigurim: tani ishte e mundur ta ndryshonit "në fluks", pa ndërtuar një imazh të ri të konteinerit. Për të mësuar se sa lidhje mund të trajtohen në të vërtetë, u zhvilluan disa eksperimente me ambientin staging, ku u caktuan vlera të ndryshme për të parë se si do të ndikonte në skenarët e testimit të ngarkesës. Si rezultat, u zbulua se Quay fillon të jepë gabime 502 kur numri i lidhjeve kalon 10 mijë.
Ne menjĂ«herĂ« e zgjodhĂ«m kĂ«tĂ« version tĂ« ri nĂ« production dhe filluam tĂ« ndiqnim grafikĂ«n e lidhjeve me bazĂ«n e tĂ« dhĂ«nave. NĂ« tĂ« kaluarĂ«n, baza u bllokua afĂ«rsisht pas 20 minutash. Pas 30 minutash pa probleme, kishim shpresĂ«, dhe pas njĂ« ore â siguri. Ne rikthyem trafikun pĂ«r shkruar nĂ« faqen e internetit dhe filluam analizĂ«n postmortem.
Duke arritur të shmangim problemin që çonte në bllokim, nuk zbuluam shkaqet e vërteta të tij. U konfirmua se ajo nuk kishte lidhje me ndonjë ndryshim në OpenShift 4.3.19, pasi e njëjta gjë ndodhi edhe në versionin 4.3.18, i cili deri atëherë kishte funksionuar me Quay pa ndonjë problem.
Në klaster kishte diçka tjetër të fshehur.
Hetimi i hollësishëm
Quay.io pĂ«rdori pĂ«r gjashtĂ« vjetĂ« parametrat e paracaktuar pĂ«r lidhjen me DB pa ndonjĂ« problem. ĂfarĂ« ka ndryshuar? E qartĂ«, gjatĂ« gjithĂ« kĂ«tij kohĂ«, trafiku nĂ« quay.io ka vazhduar tĂ« rritet. NĂ« rastin tonĂ«, gjithçka dukej si tĂ« kishte arritur njĂ« pikĂ« prag qĂ« shĂ«rbeu si njĂ« triger pĂ«r njĂ« lavinĂ« lidhjesh. Ne vazhduam tĂ« shqyrtonim logĂ«t e DB pas dĂ«shtimit tĂ« dytĂ«, por nuk gjetĂ«m ndonjĂ« tĂ« dhĂ«nĂ« ose lidhje tĂ« dukshme.
Ndërkohë, ekipi SRE ishte duke u angazhuar në përmirësime në fushën e vëzhgueshmërisë së kërkesave në Quay dhe shëndetit të përgjithshëm të shërbimit. U implementuan metrika të reja dhe panele monitorimi, që tregojnë se cilat pjesë të Quay po kërkohen më shumë nga klientët.
Quay.io funksionoi normal deri më 9 Qershor. Në mëngjes (sipër EDT) sërish u përballëm me një rritje të konsiderueshme të numrit të lidhjeve në bazën e të dhënave. Këtë herë nuk kishte ndonjë ndërprerje, pasi parametri i ri kufizonte numrin e tyre dhe nuk lejonte tejkalimin e kapacitetit të MySQL. Megjithatë, për rreth një gjysmë ore shumë përdorues raportuan ngadalësimin e punës së quay.io. Ne mbledhëm shpejt të gjitha të dhënat e mundshme, duke përdorur mjetet e reja të monitorimit. Papritur u shfaq një model.
Para shpejtimit tĂ« numrit tĂ« lidhjeve, njĂ« numĂ«r i madh kĂ«rkesash mbĂ«rriti nĂ« App Registry API. App Registry Ă«shtĂ« njĂ« funksion i panjohur shumĂ« nĂ« quay.io. Ai lejon ruajtjen e gjĂ«rave si chartet Helm dhe kontejnerĂ«t me metadatat e pasura. Shumica e pĂ«rdoruesve tĂ« quay.io nuk punojnĂ« me kĂ«tĂ« funksion, megjithatĂ«, ajo pĂ«rdoret gjerĂ«sisht nga Red Hat OpenShift. OperatorHub nĂ« kuadĂ«r tĂ« OpenShift ruan tĂ« gjithĂ« operatorĂ«t nĂ« App Registry. KĂ«ta operatorĂ« formojnĂ« bazĂ«n pĂ«r ekosistemin e ngarkesave tĂ« punĂ«s OpenShift dhe modelin operativ (nĂ« kuadĂ«r tĂ« operacioneve âtĂ« ditĂ«s sĂ« dytĂ«â, Day 2) tĂ« orientuar nga partnerĂ«t.
Ădo kluster OpenShift 4 pĂ«rdor operatorĂ«t nga OperatorHub i integruar pĂ«r tĂ« publikuar katalogun e operatorĂ«ve, tĂ« cilĂ«t janĂ« tĂ« disponueshĂ«m pĂ«r instalim, dhe pĂ«r tĂ« ofruar pĂ«rditĂ«sime pĂ«r ato qĂ« janĂ« instaluar tashmĂ«. Me rritjen e popullaritetit tĂ« OpenShift 4, numri i klustereve nĂ« tĂ« Ă«shtĂ« rritur gjithashtu nĂ« mbarĂ« botĂ«n. Ădo njĂ« nga kĂ«to klustere ngarkon pĂ«rmbajtjen e operatorĂ«ve pĂ«r tĂ« nisur OperatorHub-in e integruar, duke pĂ«rdorur App Registry brenda quay.io si backend. NĂ« kĂ«rkim tĂ« burimit tĂ« problemit ne humbĂ«m faktin se me rritjen graduale tĂ« popullaritetit tĂ« OpenShift, po rritej gjithashtu edhe ngarkesa nĂ« njĂ« nga funksionet e pĂ«rdorura rrallĂ« nĂ« quay.io..
Ne kemi kryer një analizë të trafikut të kërkesave në App Registry dhe kemi shqyrtuar kodin e regjistrit. Menjëherë janë shfaqur disavantazhe që kishin si rezultat formimin jo optimal të kërkesave ndaj bazës së të dhënave. Në ngarkesa të vogla, ato nuk shkaktuan asnjë problem, por me rritjen e ngarkesës, ato u bënë burim i vështirësive. App Registry kishte dy endpoint-e problematike që reagojnë keq ndaj rritjes së ngarkesës: i pari jepte një listë të të gjitha pakove në repositor, i dyti kthenin të gjithë blob-at për paketën.
Eliminimi i shkakut
GjatĂ« javĂ«s sĂ« ardhshme ne punuam nĂ« optimizimin e kodit tĂ« App Registry dhe ambientit tĂ« tij. U rishikuan qartazi tĂ« pasuksesshme SQL kĂ«rkesat, u eliminuan thirrjet e tepĂ«rta tĂ« komandĂ«s (ajo aktivizohej me çdo nxjerrje blobâesh), dhe u shtua caching kudo qĂ« ishte e mundur. tar (ajo aktivizohej me çdo nxjerrje blob-ash), Ă«shtĂ« shtuar caching kudo qĂ« ishte e mundur. MĂ« pas, Ă«shtĂ« kryer njĂ« testim i rĂ«ndĂ«sishĂ«m i performancĂ«s dhe Ă«shtĂ« krahasuar shpejtĂ«sia e punĂ«s sĂ« App Registry para dhe pas ndryshimeve.
Kërkesat API, që më parë zinin deri në gjysmëminute, tani përfundonin për milisekonda.. Javën e ardhshme ne implementuam ndryshimet në production, dhe që atëherë quay.io funksionon stabilisht. Gjatë kësaj periudhe, janë vërejtur disa shpërthime të papritura të trafikut në endpoint-in e App Registry, por përmirësimet e bëra parandaluan ndalimet në funksionimin e bazës së të dhënave.
ĂfarĂ« mĂ«suam?
ĂshtĂ« e qartĂ« se çdo shĂ«rbim pĂ«rpiqet tĂ« shmangĂ« ndalesat. NĂ« rastin tonĂ«, besojmĂ« se defektet e fundit ndihmuan pĂ«r ta bĂ«rĂ« quay.io mĂ« tĂ« mirĂ«. Ne nxorrĂ«m disa mĂ«sime tĂ« rĂ«ndĂ«sishme qĂ« dĂ«shirojmĂ« t'i ndajmĂ«:
- TĂ« dhĂ«nat mbi se kush dhe si e pĂ«rdor shĂ«rbimin tuaj kurrĂ« nuk janĂ« tĂ« tepĂ«rta.. Duke qenĂ« se Quay âthjesht funksiononteâ, ne kurrĂ« nuk patĂ«m nevojĂ« tĂ« shpenzonim kohĂ« pĂ«r optimizimin e trafikut dhe menaxhimin e ngarkesĂ«s. E gjithĂ« kjo krijoi njĂ« ndjenjĂ« tĂ« rreme sigurie se shĂ«rbimi mund tĂ« shkallĂ«zohej pafundĂ«sisht.
- Kur shĂ«rbimi bie, rikthimi tij nĂ« funksion â Ă«shtĂ« pĂ«rparĂ«sia kryesore. Duke qenĂ« se Quay vazhdoi tĂ« vuante nga njĂ« bazĂ« tĂ« dhĂ«nash tĂ« bllokuar gjatĂ« rĂ«nies sĂ« parĂ«, procedurat tona standarde nuk patĂ«n efektin e pritur dhe ne nuk arritĂ«m ta rikthenim shĂ«rbimin me ndihmĂ«n e tyre. Kjo çoi nĂ« njĂ« situatĂ« ku duhet tĂ« shpenzonim kohĂ« pĂ«r analizĂ«n dhe mbledhjen e tĂ« dhĂ«nave nĂ« shpresĂ«n se do tĂ« gjenim shkakun e parĂ« â nĂ« vend qĂ« tĂ« pĂ«rqendronim tĂ« gjitha pĂ«rpjekjet nĂ« rikthimin e funksionalitetit.
- VlerĂ«soni ndikimin e secilĂ«s nga funksionet e shĂ«rbimit. KlientĂ«t rrallĂ« pĂ«rdorĂ«n App Registry, prandaj ai nuk ishte prioritet pĂ«r ekipin tonĂ«. Kur disa funksione tĂ« produktit pĂ«rdoren shumĂ« pak, defektet e tyre dalin rrallĂ«, dhe zhvilluesit ndalojnĂ« sĂ« ndjekuri kodin. ĂshtĂ« e lehtĂ« tĂ« bĂ«hesh viktimĂ« e keqkuptimit se kjo Ă«shtĂ« normale - derisa papritmas ky funksion tĂ« dalĂ« nĂ« qendĂ«r tĂ« njĂ« incidenti tĂ« madh.
ĂfarĂ« ndodh mĂ« tej?
Puna për të siguruar stabilitetin e shërbimit kurrë nuk ndalon dhe ne vazhdimisht e përmirësojmë atë. Volume 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 po punojmë në detyrat e mëposhtme:
- Implementimi i replikave të bazës së të dhënave vetëm për lexim, për të ndihmuar shërbimin të përballojë trafikun përkatës në rast të problemeve me shembullin kryesor RDS.
- Përditësimi i shembullit RDS. Versioni aktual nuk është një problem në vetvete. Përkundrazi, ne thjesht duam të eliminojmë një gjurmë false (në të cilën patëm kaluar gjatë ndërprerjes); mbajtja e softuerit në gjendje të përditësuar do të ndihmojë për të eliminuar një tjetër faktor në rast të ndërprerjeve të ardhshme.
- Kastrimi shtesë në të gjithë klasterin. Ne vazhdojmë të kërkojmë fusha ku caching mund të reduktojë ngarkesën në bazën e të dhënave.
- Shtimi i firewall-it për aplikacionet web (WAF) për të parë kush dhe përse lidhet me quay.io.
- Duke filluar nga versioni i ardhshëm, klasteret Red Hat OpenShift do të braktisin App Registry në favor të katalogëve të operatorëve (Operator Catalogs), të bazuar në imazhet e kontejnerëve të disponueshme në quay.io.
- Zëvendësimi afatgjatë i App Registry mund të jetë mbështetje për specifikimet e artefakteve Open Container Initiative (OCI). Ajo aktualisht realizohet si funksionalitet natyror i Quay dhe do të jetë e disponueshme për përdoruesit kur specifikimi përfundimisht të miratohet.
Të gjitha të mësipërmet janë pjesë e investimeve të vazhdueshme të Red Hat në quay.io ndërsa ne kalojmë nga një ekip i vogël 'në stil start-up' në një platformë të pjekur, të menaxhuar nga SRE. Ne e dimë se shumë nga klientët tanë mbështeten në quay.io për punën e tyre të përditshme (duke përfshirë Red Hat!) dhe po bëjmë përpjekje maksimale për të qenë të hapur në lidhje me dështimet e fundit dhe përpjekjet e vazhdueshme për të përmirësuar.
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «».
Burimi: habr.com
