Notu. transl.: komence de aŭgusto, Red Hat publike parolis pri solvado de problemoj de alirebleco, kiujn uzantoj de ĝia servo renkontis en antaŭaj monatoj. (ĝi baziĝas sur registro por ujbildoj, kiujn la kompanio ricevis kune kun la aĉeto de CoreOS). Sendepende de via intereso pri ĉi tiu servo kiel tia, la vojo, kiun la SRE-inĝenieroj de la kompanio prenis por diagnozi kaj forigi la kaŭzojn de la akcidento, estas instrua.
La 19-an de majo, frumatene (Eastern Daylight Time, EDT), la servo quay.io kraŝis. La akcidento influis kaj quay.io-konsumantojn kaj Open Source-projektojn uzante quay.io kiel platformon por konstrui kaj distribui softvaron. Red Hat aprezas la fidon de ambaŭ.
Teamo de SRE-inĝenieroj tuj enmiksiĝis kaj provis stabiligi la Quay-servon kiel eble plej baldaŭ. Tamen, dum ili faris tion, klientoj perdis la kapablon puŝi novajn bildojn, kaj nur foje ili povis tiri ekzistantajn. Pro iu nekonata kialo, la datumbazo quay.io estis blokita post grimpi la servon al plena kapablo.
«Kio ŝanĝiĝis?"- jen la unua demando, kiun oni kutime faras en tiaj kazoj. Ni rimarkis, ke baldaŭ antaŭ la afero, la OpenShift Dedicated areto (kiu kuras quay.io) komencis ĝisdatigi al versio 4.3.19. Ĉar quay.io funkcias per Red Hat OpenShift Dedicated (OSD), regulaj ĝisdatigoj estis rutinaj kaj neniam kaŭzis problemojn. Plie, dum la antaŭaj ses monatoj, ni plurfoje ĝisdatigis Quay-grupojn sen interrompo de servo.
Dum ni provis restarigi la servon, aliaj inĝenieroj komencis prepari novan OSD-grupon kun la antaŭa versio de la programaro, por ke se io okazus, ili povus disfaldi ĉion sur ĝi.
Analizo de Radika Kaŭzo
La ĉefa simptomo de la fiasko estis lavango de dekoj de miloj da datumbazaj konektoj, kiuj igis la MySQL-instancon efike nefunkciebla. Ĉi tio malfaciligis diagnozon de la problemo. Ni starigis limon pri la maksimuma nombro da konektoj de klientoj por helpi la SRE-teamo taksi la problemon. Ni ne rimarkis nekutiman trafikon al la datumbazo: fakte, la plej multaj petoj estis legitaj, kaj nur kelkaj estis skribitaj.
Ni ankaŭ provis identigi ŝablonon en la datumbaza trafiko, kiu povus kaŭzi ĉi tiun lavangon. Tamen, ni ne povis trovi ajnajn ŝablonojn en la protokoloj. Atendante ke la nova areto kun OSD 4.3.18 estos preta, ni daŭre provis lanĉi quay.io pods. Ĉiufoje kiam la areto atingis plenan kapaciton, la datumbazo frostiĝus. Ĉi tio signifis, ke estis necese rekomenci la RDS-instancon krom ĉiuj quay.io pods.
Vespere, ni stabiligis la servon en nurlegebla reĝimo kaj malŝaltis kiel eble plej multajn neesencajn funkciojn (ekzemple, nomspaca rubkolekto) por redukti la ŝarĝon sur la datumbazo. Frostoj ĉesis sed la kialo neniam estis trovita. La nova OSD-areto estis preta, kaj ni migris la servon, konektis trafikon kaj daŭrigis monitoradon.
Quay.io stabile funkciis pri la nova OSD-areto, do ni revenis al la datumbazaj protokoloj, sed ankoraŭ ne povis trovi korelacion, kiu klarigus la blokadon. OpenShift-inĝenieroj laboris kun ni por kompreni ĉu ŝanĝoj en Red Hat OpenShift 4.3.19 povus kaŭzi problemojn kun Quay. Tamen nenio estis trovita, kaj Ne eblis reprodukti la problemon en laboratoriokondiĉoj.
Dua fiasko
La 28-an de majo, iom antaŭ tagmezo EDT, quay.io denove kraŝis kun la sama simptomo: la datumbazo estis blokita. Kaj denove ni ĵetis ĉiujn niajn klopodojn en la esploron. Antaŭ ĉio, estis necese restarigi la servon. Tamen ĉi-foje rekomenci RDS kaj rekomenci quay.io pods faris nenion: alia lavango de ligoj superfortis la bazon. Sed kial?
Kajo estas skribita en Python kaj ĉiu balgo funkcias kiel ununura monolita ujo. La ujo rultempo ruligas multajn paralelajn taskojn samtempe. Ni uzas la bibliotekon gevent sub gunicorn por prilabori retpetojn. Kiam peto venas en Quay (per nia propra API, aŭ per la API de Docker), ĝi estas asignita gevent-laboristo. Tipe ĉi tiu laboristo devus kontakti la datumbazon. Post la unua malsukceso, ni malkovris, ke gevent-laboristoj konektas al la datumbazo uzante defaŭltajn agordojn.
Konsiderante la signifan nombron da Quay-kapsoj kaj miloj da envenantaj petoj sekundo, granda nombro da datumbazaj konektoj povus teorie superforti la MySQL-instancon. Danke al monitorado, oni sciis, ke Quay prilaboras averaĝe 5 mil petojn sekundo. La nombro da konektoj al la datumbazo estis proksimume la sama. 5 mil konektoj estis bone en la kapabloj de nia RDS-instanco (kio ne povas esti dirita pri dekoj da miloj). Ial estis neatenditaj pikiloj en la nombro da konektoj, tamen, ni ne rimarkis ajnan korelacion kun alvenantaj petoj.
Ĉi-foje ni decidis trovi kaj forigi la fonton de la problemo, kaj ne limigi nin al rekomenco. Al la kodbazo de Quay ŝanĝoj estis faritaj por limigi la nombron da konektoj al la datumbazo por ĉiu laboristo gevent. Ĉi tiu nombro fariĝis parametro en la agordo: eblis ŝanĝi ĝin sur la flugo sen konstrui novan ujan bildon. Por ekscii kiom da konektoj povus esti realisme pritraktataj, ni faris plurajn provojn en sursceniga medio, fiksante malsamajn valorojn por vidi kiel tio influus ŝarĝajn testajn scenarojn. Kiel rezulto, estis malkovrite ke Kajo komencas ĵeti 502 erarojn kiam la nombro da konektoj superas 10 mil.
Ni tuj deplojis ĉi tiun novan version al produktado kaj komencis monitori la datumbazan konekton. En la pasinteco, la bazo estis ŝlosita malsupren post ĉirkaŭ 20 minutoj. Post 30 senpagaj minutoj ni havis esperon, kaj unu horon poste ni havis konfidon. Ni restarigis trafikon al la retejo kaj komencis postmortan analizon.
Sukcesinte preteriri la problemon kondukantan al blokado, ni ne eltrovis ĝiajn verajn kialojn. Estis konfirmite, ke ĝi ne rilatas al iuj ŝanĝoj en OpenShift 4.3.19, ĉar la sama afero okazis ĉe versio 4.3.18, kiu antaŭe funkciis kun Quay senprobleme.
Klare estis io alia kaŝatendita en la areto.
Detala Studo
Quay.io uzis la defaŭltajn agordojn por konekti al la datumbazo dum ses jaroj sen problemoj. Kio ŝanĝiĝis? Estas klare, ke dum ĉi tiu tempo trafiko sur quay.io konstante kreskis. En nia kazo, ĝi aspektis kvazaŭ iu sojla valoro estis atingita, kiu funkciis kiel ellasilo por lavango de rilatoj. Ni daŭre studis la datumbazajn protokolojn post la dua fiasko, sed ne trovis iujn ajn ŝablonojn aŭ evidentajn rilatojn.
Intertempe, la SRE-teamo laboris pri plibonigoj al la peto-observebleco de Quay kaj entuta serva sano. Novaj metrikoj kaj paneloj estis deplojitaj, montrante kiuj partoj de la Kajo estas plej postulataj de klientoj.
Quay.io bone funkciis ĝis la 9-a de junio. Ĉi-matene (EDT) ni denove vidis signifan pliiĝon en la nombro da datumbazaj konektoj. Ĉi-foje ne estis malfunkcio, ĉar la nova parametro limigis ilian nombron kaj ne permesis al ili superi MySQL-trairon. Tamen, dum ĉirkaŭ duonhoro, multaj uzantoj notis malrapidan agadon de quay.io. Ni rapide kolektis ĉiujn eblajn datumojn per la aldonitaj monitoraj iloj. Subite aperis ŝablono.
Ĵus antaŭ la pliiĝo de konektoj, granda nombro da petoj estis faritaj al la App Registry API. App Registry estas malmulte konata trajto de quay.io. Ĝi permesas vin stoki aferojn kiel Helm-diagramojn kaj ujojn kun riĉaj metadatenoj. Plej multaj uzantoj de quay.io ne funkcias kun ĉi tiu funkcio, sed Red Hat OpenShift aktive uzas ĝin. OperatorHub kiel parto de OpenShift stokas ĉiujn funkciigistojn en la App Registry. Ĉi tiuj funkciigistoj formas la bazon por la OpenShift laborŝarĝa ekosistemo kaj partner-centra operacia modelo (Tago 2-operacioj).
Ĉiu OpenShift 4-areto uzas funkciigistojn de la enkonstruita OperatorHub por publikigi katalogon de funkciigistoj disponeblaj por instalo kaj disponigi ĝisdatigojn al tiuj jam instalitaj. Kun la kreskanta populareco de OpenShift 4, la nombro da aretoj sur ĝi tra la mondo ankaŭ pliiĝis. Ĉiu el ĉi tiuj aretoj elŝutas enhavon de operaciisto por ruli la enkonstruitan OperatorHub, uzante la App Registry ene de quay.io kiel la backend. En nia serĉo pri la fonto de la problemo, ni maltrafis la fakton, ke kiam OpenShift iom post iom kreskis en populareco, la ŝarĝo sur unu el la malofte uzataj funkcioj de quay.io ankaŭ pliiĝis..
Ni faris iom da analizo de la petotrafiko de App Registry kaj rigardis la registran kodon. Tuj estis malkaŝitaj mankoj, pro kiuj demandoj al la datumbazo ne estis optimume formitaj. Kiam la ŝarĝo estis malalta, ili ne kaŭzis problemojn, sed kiam la ŝarĝo pliiĝis, ili fariĝis fonto de problemoj. App Registry montriĝis havi du problemajn finpunktojn, kiuj ne bone respondis al kreskanta ŝarĝo: la unua disponigis liston de ĉiuj pakaĵoj en la deponejo, la dua resendis ĉiujn blobojn por la pakaĵo.
Forigo de kaŭzoj
Dum la venonta semajno ni elspezis optimumigante la kodon de la App Registry mem kaj ĝia medio. Klare neefikaj SQL-demandoj estis reverkitaj kaj nenecesaj komandvokoj estis eliminitaj tar (ĝi estis rulita ĉiufoje kiam blobs estis prenitaj), kaŝmemoro estis aldonita kie ajn ebla. Ni tiam faris ampleksajn agadotestojn kaj komparis la rapidecon de la Aplika Registro antaŭ kaj post la ŝanĝoj.
API-petoj, kiuj antaŭe daŭris ĝis duona minuto, nun estas plenumitaj en milisekundoj. La venontan semajnon ni deplojis la ŝanĝojn al produktado, kaj ekde tiam quay.io funkcias stabile. Dum ĉi tiu tempo, estis pluraj akraj pikiloj en trafiko sur la App Registry finpunkto, sed la plibonigoj faritaj malhelpis datumbazinterrompojn.
Kion ni lernis?
Estas klare, ke iu ajn servo provas eviti malfunkcion. En nia kazo, ni kredas, ke la lastatempaj malfunkcioj helpis plibonigi quay.io. Ni lernis kelkajn ĉefajn lecionojn, kiujn ni ŝatus dividi:
- Datumoj pri kiu uzas vian servon kaj kiel neniam estas superfluaj. Ĉar Quay "nur funkciis", ni neniam devis pasigi tempon optimumigante trafikon kaj administrante ŝarĝon. Ĉio ĉi kreis malveran senton de sekureco, kiun la servo povis grimpi senfine.
- Kiam la servo malfunkcias, refunkciigi ĝin estas ĉefa prioritato.. Ĉar Quay daŭre suferis de ŝlosita datumbazo dum la unua malfunkcio, niaj normaj proceduroj ne havis la celitan efikon kaj ni ne povis restarigi la servon uzante ilin. Ĉi tio kondukis al situacio, kie oni devis pasigi tempon por analizi kaj kolekti datumojn kun la espero trovi la radikan kaŭzon - anstataŭ enfokusigi ĉiujn klopodojn por restarigi funkciecon.
- Taksi la efikon de ĉiu serva trajto. Klientoj malofte uzis App Registry, do ĝi ne estis prioritato por nia teamo. Kiam iuj produktaj funkcioj estas apenaŭ uzataj, iliaj eraroj malofte aperas, kaj programistoj ĉesas monitori la kodon. Estas facile fali predon de la miskompreno, ke tiel ĝi devus esti—ĝis subite tiu funkcio troviĝas en la centro de grava okazaĵo.
Kio sekvas?
La laboro por certigi la stabilecon de la servo neniam ĉesas kaj ni konstante plibonigas ĝin. Ĉar trafikaj volumoj daŭre kreskas sur quay.io, ni rekonas, ke ni havas respondecon fari ĉion, kion ni povas por vivi laŭ la konfido de niaj klientoj. Tial ni nuntempe laboras pri la sekvaj taskoj:
- Deploji nurlegeblajn datumbazajn kopiojn por helpi la servon pritrakti taŭgan trafikon en okazo de problemoj kun la ĉefa RDS-instanco.
- Ĝisdatigante RDS-instancon. La nuna versio mem ne estas la problemo. Prefere, ni simple volas forigi la falsan spuron (kiun ni sekvis dum la fiasko); Teni la programaron ĝisdatigita forigos alian faktoron en la okazo de estontaj malfunkcioj.
- Plia kaŝmemoro tra la tuta areto. Ni daŭre serĉas areojn kie kaŝmemoro povas redukti la ŝarĝon sur la datumbazo.
- Aldonante TTT-aplikaĵan fajroŝirmilon (WAF) por vidi kiu konektas al quay.io kaj kial.
- Komencante kun la venonta eldono, Red Hat OpenShift-aretoj forlasos App Registry en favoro de Operatoraj Katalogoj bazitaj sur ujbildoj haveblaj ĉe quay.io.
- Longperspektiva anstataŭaĵo por App Registry povus esti subteno por Open Container Initiative (OCI) artefaktospecifoj. Ĝi estas nuntempe efektivigita kiel denaska Quay-funkcio kaj estos havebla al uzantoj kiam la specifo mem estos finpretigita.
Ĉio ĉi-supra estas parto de la daŭra investo de Red Hat en quay.io dum ni moviĝas de malgranda "start-stila" teamo al matura SRE-movita platformo. Ni scias, ke multaj el niaj klientoj fidas je quay.io en sia ĉiutaga laboro (inkluzive de Red Hat!) kaj ni provas esti kiel eble plej travideblaj pri lastatempaj malfunkcioj kaj daŭraj klopodoj por plibonigi.
PS de tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «".
fonto: www.habr.com