{"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\/sl\/blog\/administrirovanie\/post-mortem-po-nedostupnosti-quay-io","title":{"rendered":"Post Mortem o nedostopnosti Quay.io","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Op. prev.<\/b>: v za\u010detku avgusta je Red Hat javno sporo\u010dil o re\u0161itvi te\u017eav z dostopnostjo, ki so se v preteklih mesecih pojavljale uporabnikom njihove storitve. Quay.io<\/a><\/noindex> (v osnovi gre za register za slike kontejnerjev, ki ga je podjetje pridobilo s prevzemom CoreOS). Ne glede na va\u0161o zainteresiranost za to storitev kot tako, je pou\u010den sam pot, po katerem so \u0161li SRE-in\u017eenirji podjetja, da bi diagnosticirali in odpravili vzroke za okvaro.<\/i><\/p>\n

\"Post
\n
\n19. maja, zgodaj zjutraj (po poletnem vzhodnoameri\u0161kem \u010dasu, EDT), je storitev quay.io propadla. Okvara je prizadela tako uporabnike quay.io, kot tudi projekte odprte kode, ki uporabljajo quay.io kot platformo za zbiranje in distribucijo programske opreme. Red Hat ceni zaupanje tako uporabnikov kot tudi skupnosti.<\/p>\n

Ekipa SRE-in\u017eenirjev se je takoj vklju\u010dila v delo in posku\u0161ala \u010dim prej stabilizirati delovanje storitve Quay. Vendar pa so med tem, ko so to po\u010deli, stranke izgubile mo\u017enost nalaganja novih slik, in le ob\u010dasno so lahko prena\u0161ale obstoje\u010de. Iz neznanega razloga se je baza podatkov quay.io blokirala po raz\u0161iritvi storitve na polno zmogljivost.<\/a><\/noindex><\/p>\n

\u00abKaj se je spremenilo?<\/b>\u00bb \u2014 to je prvo vpra\u0161anje, ki ga navadno postavimo v takih primerih. Opazili smo, da je kmalu pred te\u017eavami klaster OpenShift Dedicated (na katerem deluje quay.io) za\u010del posodabljati na razli\u010dico 4.3.19. Ker quay.io deluje na Red Hat OpenShift Dedicated (OSD), so redne posodobitve predstavljale obi\u010dajno operacijo in nikoli niso povzro\u010dale te\u017eav. Poleg tega smo v zadnjih \u0161estih mesecih ve\u010dkrat posodobili klastre Quay brez prekinitev v servisiranju.<\/p>\n

Medtem ko smo posku\u0161ali obnoviti delovanje storitve, so drugi in\u017eenirji za\u010deli pripravljati nov klaster OSD s prej\u0161njo razli\u010dico programske opreme, da bi v primeru te\u017eav lahko vse vzpostavili nanj.<\/p>\n

Analiza osnovnih vzrokov<\/h2>\n

\nGlavni simptom okvare je bila plaz iz desetih tiso\u010d povezav na BDP, zaradi \u010desar je bil primer MySQL dejansko nefunkcionalen. Zaradi tega je bilo te\u017eko diagnosticirati problem. Uvedli smo omejitev na najve\u010dje \u0161tevilo povezav od strank, da smo ekipi SRE pomagali oceniti te\u017eavo. Nobenega nenavadnega prometa na bazo podatkov nismo opazili: v resnici so bili ve\u010dinoma vsi poizvedbe za branje, le redki so bili za pisanje.<\/p>\n

Posku\u0161ali smo ugotoviti vzorec v prometu zbirke podatkov, ki bi lahko povzro\u010dil to plaz. Vendar pa nismo mogli najti nobenih zakonitosti v dnevnikih. Medtem ko smo \u010dakali na pripravo novega prostora z OSD 4.3.18, smo nadaljevali z poskusi zagon jate quay.io. Vsaki\u010d, ko je prostor dosegel polno mo\u010d, se je zbirka podatkov ustavila. To je pomenilo, da je bilo treba znova zagnati primer RDS poleg vseh jat quay.io.<\/p>\n

Do ve\u010dera smo stabilizirali storitev v na\u010dinu le za branje in onemogo\u010dili \u010dim ve\u010d nepomembnih funkcij (na primer \u010di\u0161\u010denje prostorov imen), da bi zmanj\u0161ali obremenitev baze podatkov. Zastoji so prenehali, a vzrok ni bil nikoli ugotovljen<\/b>. Nov klaster OSD je bil pripravljen, prenesli smo storitev, povezali promet in nadaljevali s spremljanjem.<\/p>\n

Quay.io je stabilno deloval na novem OSD klastru, zato smo se vrnili k dnevnikom baze podatkov, vendar nismo uspeli odkriti korelacije, ki bi razlo\u017eila zaklepe. In\u017eenirji OpenShift so sodelovali z nami, da bi posku\u0161ali razumeti, ali so lahko spremembe v Red Hat OpenShift 4.3.19 povzro\u010dile te\u017eave s Quay. Vendar ni\u010d ni bilo odkrita, in ni bilo mogo\u010de reproducirati problema v laboratorijskih razmerah<\/b>.<\/p>\n

Druga napaka<\/h2>\n

\n28. maja, kmalu pred poldnevom po EDT, se je quay.io znova zru\u0161il s istimi simptomi: delovanje baze podatkov je bilo zaklenjeno. In ponovno smo usmerili vse sile v raziskovanje. Najprej je bilo treba obnoviti delovanje storitve. Vendar Tokrat ponovni zagon RDS in ponovni zagon jat quay.io nista prinesla rezultatov.<\/b>: nova poplava povezav je preplavila bazo. Ampak zakaj?<\/p>\n

Quay je napisan v Pythonu, in vsak pod deluje kot enoten monolitni kontejner. V okolju kontejnerja se hkrati izvaja ve\u010d vzporednih nalog. Uporabljamo knji\u017enico gevent<\/code> pod gunicorn<\/code> za obdelavo spletnih zahtev. Ko Quay prejme zahtevo (prek na\u0161ega lastnega API-ja ali prek API-ja Docker), ji je dodeljen gevent delavec. Obi\u010dajno se mora ta delavec povezati z zbirko podatkov. Po prvem zastoju smo ugotovili, da so se gevent delavci povezovali z zbirko podatkov z uporabo privzetih nastavitev.<\/p>\n

Ob upo\u0161tevanju velikega \u0161tevila jat Quay in tiso\u010dih prejetih zahtev na sekundo, je lahko veliko \u0161tevilo povezav z zbirko podatkov teoreti\u010dno preobremenilo primer MySQL. S spremljanjem je bilo znano, da Quay povpre\u010dno obravnava 5000 zahtev na sekundo. Podobno je bilo tudi \u0161tevilo povezav z zbirko podatkov. 5000 povezav se je obilo prilegalo zmogljivosti na\u0161ega primera RDS (kar ne velja za desetine tiso\u010d). Iz nekega razloga so se dogajali nepri\u010dakovani skoki v \u0161tevilu povezav<\/b>, vendar nismo opazili nobene korelacije s prihajajo\u010dimi zahtevki.<\/p>\n

Tokrat smo se odlo\u010dili, da najdemo in odpravimo vir problema, namesto da se zadovoljimo zgolj s ponovnim zagonom. V kodo Quay bila so uvedena nekatera spremembe, ki omejujejo \u0161tevilo povezav z zbirko podatkov za vsakega delavca.<\/b> gevent. To \u0161tevilo je postalo parameter v konfiguraciji: bilo je mogo\u010de spreminjati ga 'v teku', brez potrebe po ponovnem sestavljanju slike kontejnerja. Da bi ugotovili, koliko povezav lahko dejansko obdelamo, smo izvedli ve\u010d testiranj v staging okolju, kjer smo nastavljali razli\u010dne vrednosti in opazovali, kako se odra\u017ea na scenarijih obremenitvenega testiranja. Na koncu se je izkazalo, da Quay za\u010dne izdajati napake 502, ko \u0161tevilo povezav prese\u017ee 10 tiso\u010d.<\/b><\/p>\n

Takoj smo razporedili to novo razli\u010dico v produkcijo in za\u010deli spremljati graf povezav z bazo podatkov. V preteklosti se je baza blokirala pribli\u017eno po 20 minutah. Po 30 minutah brez te\u017eav smo imeli upanje, po eni uri pa prepri\u010danje. Obnovili smo pisno prometa na strani in se lotili postmortem analize.<\/p>\n

Uspe\u0161no smo ob\u0161li problem, ki je vodil do blokade, nismo pa odkrili njegovih pravih vzrokov.<\/b>Potrdilo se je, da ni povezan s kakr\u0161nimi koli spremembami v OpenShift 4.3.19, saj se je enako zgodilo tudi v razli\u010dici 4.3.18, ki je prej delala s Quay brez kakr\u0161nih koli te\u017eav.<\/p>\n

V grozdu se je o\u010ditno skrivala \u0161e kaj drugega.<\/p>\n

Podrobna preiskava<\/h2>\n

\nQuay.io je \u0161est let pou\u017e\u00edval v\u00fdchoz\u00ed nastaven\u00ed pro p\u0159ipojen\u00ed k datab\u00e1zi bez jak\u00fdchkoli probl\u00e9m\u016f. Co se zm\u011bnilo? Je jasn\u00e9, \u017ee po celou tuto dobu neust\u00e1le rostl provoz na quay.io. V na\u0161em p\u0159\u00edpad\u011b to vypadalo, jako by bylo dosa\u017eeno ur\u010dit\u00e9 prahov\u00e9 hodnoty, kter\u00e1 spustila lavinu p\u0159ipojen\u00ed. Pokra\u010dovali jsme ve zkoum\u00e1n\u00ed log\u016f datab\u00e1ze po druh\u00e9m v\u00fdpadku, ale \u017e\u00e1dn\u00e9 vzorce nebo z\u0159ejm\u00e9 souvislosti jsme nenalezli.<\/p>\n

Mezit\u00edm se t\u00fdm SRE v\u011bnoval zlep\u0161ov\u00e1n\u00ed oblasti sledovatelnosti dotaz\u016f na Quay a celkov\u00e9 zdrav\u00ed slu\u017eby. Byly nasazeny nov\u00e9 metriky a monitoringov\u00e9 panely<\/b>, kter\u00e9 ukazuj\u00ed, kter\u00e9 \u010d\u00e1sti Quay jsou ze strany z\u00e1kazn\u00edk\u016f nejv\u00edce popt\u00e1v\u00e1ny.<\/p>\n

Quay.io fungoval norm\u00e1ln\u011b a\u017e do 9. \u010dervna. R\u00e1no (podle EDT) jsme op\u011bt byli sv\u011bdky v\u00fdznamn\u00e9ho n\u00e1r\u016fstu po\u010dtu p\u0159ipojen\u00ed k datab\u00e1zi. Tentokr\u00e1t nedo\u0161lo k \u017e\u00e1dn\u00e9mu v\u00fdpadku<\/b>, proto\u017ee nov\u00fd parametr omezoval jejich po\u010det a neumo\u017e\u0148oval p\u0159ekro\u010dit kapacitu MySQL. P\u0159ibli\u017en\u011b po dobu p\u016fl hodiny mnoho u\u017eivatel\u016f zaznamenalo pomal\u00fd v\u00fdkon quay.io. Rychle jsme shrom\u00e1\u017edili v\u0161echny dostupn\u00e9 \u00fadaje za pou\u017eit\u00ed p\u0159idan\u00fdch monitorovac\u00edch n\u00e1stroj\u016f. N\u00e1hle se objevila vzorce.<\/p>\n

P\u0159ed samotn\u00fdm skokem v po\u010dtu p\u0159ipojen\u00ed do\u0161lo k mnoha dotaz\u016fm na App Registry API<\/b>. App Registry je m\u00e1lo zn\u00e1m\u00e1 funkce quay.io. Umo\u017e\u0148uje uchov\u00e1vat v\u011bci jako Helm chart a kontejnery s bohat\u00fdmi metadaty. V\u011bt\u0161ina u\u017eivatel\u016f quay.io s touto funkc\u00ed nepracuje, ale je aktivn\u011b vyu\u017e\u00edv\u00e1na Red Hat OpenShift. OperatorHub v r\u00e1mci OpenShift uchov\u00e1v\u00e1 v\u0161echny oper\u00e1tory v App Registry. Tito oper\u00e1to\u0159i tvo\u0159\u00ed z\u00e1klad pro ekosyst\u00e9m pracovn\u00edch z\u00e1t\u011b\u017e\u00ed OpenShift a opera\u010dn\u00ed model (v r\u00e1mci operac\u00ed \"druh\u00e9ho dne\", Day 2), orientovan\u00fd na partnery.<\/p>\n

Vsak OpenShift 4 prostor uporablja operaterje iz vgrajenega OperatorHub-a za objavo kataloga operaterjev, ki so na voljo za namestitev, in za zagotavljanje posodobitev za \u017ee name\u0161\u010dene. S pove\u010danjem priljubljenosti OpenShift 4 se je pove\u010dalo tudi \u0161tevilo prostorov po vsem svetu. Vsak od teh prostorov nalaga vsebino operaterjev, da za\u017eene vgrajen OperatorHub, z uporabo App Registry znotraj quay.io kot zadnjo to\u010dko. Pri iskanju izvora te\u017eave smo spregledali, da se je z nara\u0161\u010danjem priljubljenosti OpenShifta pove\u010dalo tudi obremenitev ene redko uporabljene funkcije quay.io.<\/b>.<\/p>\n

Opravili smo analizo prometa zahtev App Registry in pogledali kodo registra. Takoj so se pokazale pomanjkljivosti, zaradi katerih so zahteve za zbirko podatkov nastajale neoptimizirano. Pri majhnem obremenu niso povzro\u010dale te\u017eav, vendar pa so postale vir te\u017eav ob pove\u010danju obremenitve. App Registry je imel dva problemati\u010dna kon\u010dna to\u010dke, ki slabo reagirata na pove\u010dano obremenitev: prva je vra\u010dala seznam vseh paketov v repozitoriju, druga pa je vrnila vse blob-e za paket.<\/p>\n

Odprava vzrokov<\/h2>\n

\nVso naslednjo tednu smo se ukvarjali z optimizacijo kode samega App Registry in njene okolice. Preoblikovali smo o\u010ditno neu\u010dinkovite SQL-naro\u010dila, odpravili odve\u010dne klice ukaza (ki se je izvajal pri vsakem izvleku blob-ov), dodali predpomnjenje povsod, kjer je to bilo mogo\u010de. Nato je bilo izvedeno obse\u017eno testiranje zmogljivosti in primerjana hitrost delovanja App Registry pred in po spremembah. tar<\/code> (ona se je zagnala ob vsakem pridobivanju blobov), dodano je predpomnjenje povsod, kjer je mo\u017eno. Nato je bilo izvedeno obse\u017eno testiranje zmogljivosti in primerjana hitrost delovanja App Registry pred in po spremembah.<\/p>\n

. Naslednji teden smo uvedli spremembe v produkcijo in od takrat quay.io deluje stabilno. V tem \u010dasu smo opazili ve\u010d ostrih vrhov prometa na endpointu App Registry, vendar so izbolj\u0161ave prepre\u010dile motnje v delovanju baze podatkov.<\/b>. Naslednji teden smo uvedli spremembe v produkcijo in od takrat quay.io deluje stabilno. V tem \u010dasu smo opazili ve\u010d ostrih vrhov prometa na endpointu App Registry, vendar so izvedene izbolj\u0161ave prepre\u010dile prekinitev delovanja baze podatkov.<\/p>\n

Jasno je, da si vsak servis prizadeva prepre\u010diti izpade. V na\u0161em primeru verjamemo, da so nedavni izpadi pripomogli k izbolj\u0161anju quay.io. Izpostavili smo nekaj klju\u010dnih lekcij, ki jih \u017eelimo deliti:<\/h2>\n

\nPodatki o tem, kdo in kako uporablja va\u0161 servis, nikoli niso odve\u010d.<\/p>\n

    \n
  1. Ker je Quay ''preprosto deloval'', nismo nikoli imeli potrebe nameniti \u010dasa optimizaciji prometa in upravljanju obremenitve. Vse to je ustvarilo la\u017een ob\u010dutek varnosti, da se servis lahko neskon\u010dno \u0161iri.<\/b>Ko servis odpove,<\/li>\n
  2. je obnova njegovega delovanja glavni prioritet. obnovitev njegovega delovanja je glavni prioritet<\/b>. Ker Quay \u0161e vedno trpi zaradi blokirane baze podatkov med prvim incidentom, na\u0161i standardni postopki niso imeli pri\u010dakovanega u\u010dinka in v njihovih okvirih nismo mogli obnoviti delovanja storitve. To je pripeljalo do situacije, ko smo porabili \u010das za analizo in zbiranje podatkov v upanju, da ugotovimo prvotni vzrok \u2014 namesto da bi vse sile usmerili v obnovitev delovanja.<\/li>\n
  3. Ocenjujte vpliv posameznih funkcij storitve<\/b>. Stranke redko uporabljajo App Registry, zato za na\u0161o ekipo ni bila prioritetna. Ko se nekatere funkcije izdelka skoraj nikoli ne uporabljajo, se njihovi hro\u0161\u010di redko pojavijo in razvijalci prenehajo spremljati kodo. Enostavno je postati \u017ertev zablode, da tako pa\u010d mora biti \u2014 dokler ta funkcija nenadoma ne pride v sredi\u0161\u010de obse\u017enega incidenta.<\/li>\n<\/ol>\n

    <\/p>\n

    Kaj zdaj?<\/h2>\n

    \nDelo na zagotavljanju stabilnosti storitve nikoli ne miruje in nenehno jo izbolj\u0161ujemo. Obseg prometa na quay.io \u0161e naprej nara\u0161\u010da in zavedamo se, da smo dol\u017eni storiti vse, kar je v na\u0161i mo\u010di, da upravi\u010dimo zaupanje strank. Zato trenutno delamo na naslednjih nalogah:<\/p>\n

      \n
    1. Implementacija replik baz podatkov samo za branje, da bi pomagala storitvi obvladovati ustrezen promet v primeru te\u017eav z glavnim primerkom RDS.<\/li>\n
    2. Posodobitev primerka RDS. Trenutna razli\u010dica sama po sebi ni te\u017eava. Raje \u017eelimo le odpraviti la\u017eni sledi (po katerih smo \u0161li med okvaro); vzdr\u017eevanje programske opreme posodobljene bo odpravilo \u0161e en dejavnik v primeru prihodnjih izpadov.<\/li>\n
    3. Dodatno predpomnjenje po celotnem grozdu. \u0160e naprej i\u0161\u010demo podro\u010dja, kjer bi predpomnjenje lahko zmanj\u0161alo obremenitev baze podatkov.<\/li>\n
    4. Dodajanje po\u017earnega zidu za spletne aplikacije (WAF), da vidimo, kdo in zakaj se povezuje na quay.io.<\/li>\n
    5. Z naslednjo razli\u010dico bosta grozdi Red Hat OpenShift opustila App Registry v prid katalogom operaterjev (Operator Catalogs), ki temeljijo na slikah kontejnerjev, dostopnih na quay.io.<\/li>\n
    6. Dolgoro\u010dna zamenjava za App Registry lahko postane podpora specifikacijam artefaktov Open Container Initiative (OCI). Ta se trenutno izvaja kot doma\u010da funkcionalnost Quay in bo na voljo uporabnikom, ko bo sama specifikacija dokon\u010dno potrjena.<\/li>\n<\/ol>\n

      \nVse zgoraj navedeno je del na\u0161ih stalnih nalo\u017eb Red Hat v quay.io, ko prehajamo od majhne ekipe v duhu zagonskega podjetja k zreli platformi, ki jo upravlja SRE. Zavedamo se, da se mnogi na\u0161i odjemalci zana\u0161ajo na quay.io v svojem vsakdanjem delu (vklju\u010dno z Red Hat!) in si prizadevamo biti kar se da odprti glede nedavnih motenj in stalnih prizadevanj, da postanemo bolj\u0161i.<\/p>\n

      P.S. od prevajalca<\/h2>\n

      \nPreberite tudi na na\u0161em blogu:<\/p>\n