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

Bem. overs.<\/b>: I begyndelsen af august offentliggjorde Red Hat l\u00f8sningen p\u00e5 tilg\u00e6ngelighedsproblemerne, som havde v\u00e6ret til stede i de foreg\u00e5ende m\u00e5neder for brugerne af deres service. Quay.io<\/a><\/noindex> (det er baseret p\u00e5 et register til containerbilleder, som virksomheden fik med k\u00f8bet af CoreOS). Uanset din interesse i denne service som s\u00e5dan, er vejen, som virksomhedens SRE-ingeni\u00f8rer har taget for at diagnosticere og l\u00f8se \u00e5rsagerne til nedbruddet, l\u00e6rerigt.<\/i><\/p>\n

\"Post
\n
\nDen 19. maj, tidligt om morgenen (if\u00f8lge sommerens nordamerikanske \u00f8stlige tidszone, EDT), gik tjenesten quay.io ned. Nedbruddet p\u00e5virkede b\u00e5de brugerne af quay.io og open source-projekter, der bruger quay.io som platform til at bygge og distribuere software. Red Hat v\u00e6rds\u00e6tter tilliden fra b\u00e5de den ene og den anden side.<\/p>\n

SRE-ingeni\u00f8rteamet gik straks i gang med at arbejde og fors\u00f8gte at stabilisere driften af Quay s\u00e5 hurtigt som muligt. Men mens de gjorde dette, mistede kunderne muligheden for at push\u2019e nye billeder, og de kunne kun periodisk pull\u2019e eksisterende. Af en ukendt \u00e5rsag blev databasen quay.io l\u00e5st efter at tjenesten blev skaleret til fuld kapacitet.<\/a><\/noindex><\/p>\n

\u00abHvad er \u00e6ndret?<\/b>\u00bb \u2014 det er det f\u00f8rste sp\u00f8rgsm\u00e5l, der plejer at blive stillet i s\u00e5danne tilf\u00e6lde. Vi bem\u00e6rkede, at kort f\u00f8r problemet begyndte, blev OpenShift Dedicated-klusteret (hvor quay.io k\u00f8rer) opdateret til version 4.3.19. Da quay.io k\u00f8rer p\u00e5 Red Hat OpenShift Dedicated (OSD), var regelm\u00e6ssige opdateringer en almindelig operation og havde aldrig f\u00f8rt til problemer. Desuden havde vi i l\u00f8bet af de sidste seks m\u00e5neder opdateret Quay-klusteret flere gange uden nogen driftsafbrydelser.<\/p>\n

Mens vi fors\u00f8gte at genoprette tjenestens drift, begyndte andre ingeni\u00f8rer at forberede et nyt OSD-kluster med den tidligere version af softwaren, s\u00e5 de kunne deployere alt p\u00e5 det, hvis det skulle blive n\u00f8dvendigt.<\/p>\n

\u00c5rsagsanalyser<\/h2>\n

\nDet prim\u00e6re symptom p\u00e5 nedbruddet var en lavine af titusindvis af forbindelser til databasen, hvilket gjorde MySQL-instansen praktisk talt ubrugelig. Dette gjorde det sv\u00e6rt at diagnosticere problemet. Vi satte en gr\u00e6nse for det maksimale antal forbindelser fra klienter for at hj\u00e6lpe SRE-teamet med at vurdere problemet. Der blev ikke observeret nogen us\u00e6dvanlig trafik til databasen: faktisk var de fleste foresp\u00f8rgsler l\u00e6seforesp\u00f8rgsler, mens kun f\u00e5 var skriveforesp\u00f8rgsler.<\/p>\n

Vi fors\u00f8gte ogs\u00e5 at identificere et m\u00f8nster i databasen, der kunne have for\u00e5rsaget denne lavine. Men vi kunne ikke finde nogen m\u00f8nstre i logfilerne. Mens vi ventede p\u00e5, at det nye cluster med OSD 4.3.18 blev klar, fortsatte vi med at fors\u00f8ge at starte pod'erne fra quay.io. Hver gang clustret n\u00e5ede fuld kapacitet, fr\u00f8s databasen. Det bet\u00f8d, at det var n\u00f8dvendigt at genstarte RDS-instansen ud over alle pod'erne fra quay.io.<\/p>\n

Ved aftenstid stabiliserede vi servicen i read-only tilstand og deaktiverede maksimalt ikke-kritiske funktioner (f.eks. affaldssamling i navnerummet) for at reducere belastningen p\u00e5 databasen. L\u00e5sningerne stoppede, men \u00e5rsagen blev aldrig fundet<\/b>. Den nye OSD-klynge var klar, og vi flyttede servicen, tilsluttede trafikken og fortsatte overv\u00e5gningen.<\/p>\n

Quay.io fungerede stabilt p\u00e5 den nye OSD-klynge, s\u00e5 vi gik tilbage til database-loggene, men kunne stadig ikke finde en korrelation, der kunne forklare l\u00e5sningerne. Ingeni\u00f8rerne fra OpenShift arbejdede sammen med os for at forst\u00e5, om \u00e6ndringer i Red Hat OpenShift 4.3.19 kunne have for\u00e5rsaget problemer med Quay. Men vi fandt ikke noget, og det lykkedes ikke at reproducere problemet i laboratoriet<\/b>.<\/p>\n

Den anden fejl<\/h2>\n

\n28. maj, kort f\u00f8r middag EDT, kollapsede quay.io igen med de samme symptomer: databasen blev l\u00e5st. Og igen kastede vi alt vores kr\u00e6fter ind i efterforskningen. F\u00f8rst og fremmest var det n\u00f8dvendigt at genskabe servicefunktionen. Men Denne gang f\u00f8rte genstart af RDS og genstart af pod'erne fra quay.io ikke til noget resultat.<\/b>: endnu en lavine af forbindelser skyllede ind over databasen. Men hvorfor?<\/p>\n

Quay er skrevet i Python, og hver pod fungerer som en monolitisk container. I containerens k\u00f8retidsmilj\u00f8 k\u00f8rer mange parallelle opgaver samtidigt. Vi bruger biblioteket gevent<\/code> under gunicorn<\/code> til behandling af webanmodninger. N\u00e5r Quay modtager en anmodning (via vores egen API eller gennem Docker's API), tildeles den en gevent worker. Normalt skal denne worker oprette forbindelse til databasen. Efter det f\u00f8rste nedbrud opdagede vi, at gevent worker'ne tilsluttede sig databasen ved at bruge standardindstillingerne.<\/p>\n

I betragtning af det betydelige antal pod'er i Quay og tusinder af indkommende anmodninger per sekund kunne et stort antal forbindelser til databasen teoretisk overbelaste MySQL-instansen. Overv\u00e5gning viste, at Quay i gennemsnit h\u00e5ndterede 5.000 anmodninger per sekund. Antallet af forbindelser til databasen var omtrent det samme. 5.000 forbindelser var inden for kapaciteten af vores RDS-instans (hvilket ikke kunne siges om titusinder). Af en eller anden grund opstod der uventede stigninger i antallet af forbindelser<\/b>, men vi bem\u00e6rkede ikke nogen korrelation med de indkommende foresp\u00f8rgsler.<\/p>\n

Denne gang besluttede vi os for at finde og l\u00f8se kilden til problemet i stedet for blot at genstarte. Der blev \u00e6ndringer blev foretaget for at begr\u00e6nse antallet af forbindelser til databasen for hver worker.<\/b> gevent. Dette nummer blev en parameter i konfigurationen: det blev muligt at \u00e6ndre det \"on-the-fly\" uden at skulle kompilere et nyt containerbillede. For at finde ud af, hvor mange forbindelser der reelt kunne h\u00e5ndteres, blev der udf\u00f8rt adskillige tests med et staging-milj\u00f8, hvor forskellige v\u00e6rdier blev sat for at se, hvordan det ville p\u00e5virke belastningstestscenarierne. Resultatet viste, at Quay begynder at returnere 502-fejl, n\u00e5r antallet af forbindelser overstiger 10.000.<\/b><\/p>\n

Vi deployerede straks denne nye version i produktionen og begyndte at overv\u00e5ge grafen for forbindelser til databasen. Tidligere blev databasen blokeret efter cirka 20 minutter. Efter 30 problemfrie minutter havde vi h\u00e5b, og efter en time - sikkerhed. Vi genoptog skrive-trafikken p\u00e5 hjemmesiden og begyndte p\u00e5 postmortem-analysen.<\/p>\n

Ved at omg\u00e5 problemet, der f\u00f8rte til blokeringen, fik vi ikke afklaret de sande \u00e5rsager<\/b>. Det blev bekr\u00e6ftet, at det ikke var relateret til nogen \u00e6ndringer i OpenShift 4.3.19, da det samme skete med version 4.3.18, som tidligere havde fungeret med Quay uden problemer.<\/p>\n

Der gemte sig tydeligvis noget andet i klyngen.<\/p>\n

En detaljeret unders\u00f8gelse<\/h2>\n

\nQuay.io har i seks \u00e5r brugt standardindstillingerne til at tilslutte til databasen uden problemer. Hvad er \u00e6ndret? Det er tydeligt, at trafikken til quay.io hele tiden er steget. I vores tilf\u00e6lde s\u00e5 det ud til, at der var n\u00e5et en t\u00e6rskel, som fungerede som en udl\u00f8ser for et v\u00e6ld af forbindelser. Vi fortsatte med at unders\u00f8ge database-logfilerne efter det andet nedbrud, men fandt ingen m\u00f8nstre eller \u00e5benlyse sammenh\u00e6nge.<\/p>\n

I mellemtiden arbejdede SRE-teamet p\u00e5 forbedringer inden for overv\u00e5gelser af anmodninger i Quay og den generelle sundhed af tjenesten. Nye m\u00e5linger og overv\u00e5gningspaneler blev implementeret<\/b>, der viser, hvilke dele af Quay der er mest efterspurgte af kunderne.<\/p>\n

Quay.io fungerede normalt indtil 9. juni. Om morgenen (EDT) blev vi igen vidner til et betydeligt stigning i antallet af forbindelse til databasen. Der var ingen nedetid denne gang<\/b>, da en ny parameter begr\u00e6nsede deres antal og forhindrede dem i at overstige MySQL's kapacitet. I cirka en halv time rapporterede mange brugere dog langsom drift af quay.io. Vi indsamlede hurtigt alle tilg\u00e6ngelige data ved at bruge de nye overv\u00e5gningsv\u00e6rkt\u00f8jer. Pludselig dukkede der et m\u00f8nster op.<\/p>\n

F\u00f8r selve stigningen i forbindelserne kom der et stort antal anmodninger til App Registry API<\/b>. App Registry er en mindre kendt funktion i quay.io. Den g\u00f8r det muligt at gemme ting som Helm-diagrammer og containere med rige metadata. De fleste brugere af quay.io arbejder ikke med denne funktion, men den bruges aktivt af Red Hat OpenShift. OperatorHub i OpenShift gemmer alle operat\u00f8rer i App Registry. Disse operat\u00f8rer danner grundlaget for OpenShift's arbejdsbelastnings\u00f8kosystem og driftsmodel (i forbindelse med 'anden dags' operationer, Day 2), der er rettet mod partnere.<\/p>\n

Hver OpenShift 4 cluster bruger operatorer fra den indbyggede OperatorHub til at offentligg\u00f8re et katalog over tilg\u00e6ngelige operatorer til installation og til at give opdateringer til allerede installerede. I takt med at OpenShift 4 blev mere popul\u00e6rt, voksede antallet af clustre globalt. Hver af disse clustre downloader indholdet af operatorer for at starte den indbyggede OperatorHub ved at bruge App Registry inden for quay.io som backend. I jagter efter problemet glemte vi, at den stigende popularitet af OpenShift ogs\u00e5 \u00f8gede belastningen p\u00e5 en af de sj\u00e6ldent anvendte funktioner quay.io.<\/b>.<\/p>\n

Vi gennemf\u00f8rte en analyse af App Registrys anmodningstrafik og kiggede p\u00e5 koden til registreringen. Mangler blev straks afsl\u00f8ret, hvilket f\u00f8rte til, at anmodningerne til databasen blev dannet suboptimalt. Under lav belastning for\u00e5rsagede de ingen problemer, men ved h\u00f8jere belastning blev de kilden til problemer. App Registry havde to problematiske endpoints, der ikke reagerede godt p\u00e5 stigende belastning: den f\u00f8rste returnerede en liste over alle pakker i arkivet, den anden returnerede alle blobs for en pakke.<\/p>\n

\u00c5rsagsafhj\u00e6lpning<\/h2>\n

\nHele den f\u00f8lgende uge arbejdede vi p\u00e5 at optimere koden i App Registry og dets milj\u00f8. \u00c5benlyst ineffektive SQL-foresp\u00f8rgsler blev omarbejdet, un\u00f8dvendige kald til kommandoen blev elimineret (den blev udf\u00f8rt ved hver hentning af blobber), og caching blev tilf\u00f8jet, hvor det var muligt. Derefter blev der udf\u00f8rt omfattende ydelsestest og hastigheden af App Registry blev sammenlignet f\u00f8r og efter \u00e6ndringerne. tar<\/code> (den blev aktiveret ved hver hentning af blobs), caching blev tilf\u00f8jet overalt, hvor det var muligt. Derefter blev der udf\u00f8rt omfattende ydeevnetest og hastigheden af App Registry blev sammenlignet f\u00f8r og efter \u00e6ndringerne.<\/p>\n

. I n\u00e6ste uge udrullede vi \u00e6ndringerne i produktion, og siden da har quay.io fungeret stabilt. I denne periode blev der observeret flere skarpe trafikstigninger p\u00e5 endepunktet for App Registry, men de forbedringer, vi havde lavet, forhindrede nedbrud i databasen.<\/b>. I n\u00e6ste uge implementerede vi \u00e6ndringerne i produktion, og siden da har quay.io v\u00e6ret stabilt. I l\u00f8bet af denne tid har der v\u00e6ret nogle markante spidser i trafikken p\u00e5 App Registry-endpointet, men de forbedringer, der blev foretaget, forhindrede databaseproblemer.<\/p>\n

Hvad har vi l\u00e6rt?<\/h2>\n

\nData om hvem og hvordan man bruger din tjeneste er aldrig overfl\u00f8dige.<\/p>\n

    \n
  1. Da Quay \"bare fungerede\", havde vi aldrig behov for at bruge tid p\u00e5 at optimere trafikken og styre belastningen. Alt dette skabte en falsk f\u00f8lelse af sikkerhed, at tjenesten kunne skaleres ubegribeligt.<\/b>N\u00e5r en tjeneste g\u00e5r ned,<\/li>\n
  2. er det at f\u00e5 den op at k\u00f8re igen den h\u00f8jeste prioritet. at genoprette dets funktion er den h\u00f8jeste prioritet<\/b>. Da Quay fortsatte med at lide af en blokeret database under det f\u00f8rste nedbrud, havde vores standardprocedurer ikke den forventede effekt, og vi kunne ikke genoprette tjenesten ved hj\u00e6lp af dem. Dette f\u00f8rte til en situation, hvor vi m\u00e5tte bruge tid p\u00e5 at analysere og indsamle data i h\u00e5bet om at finde \u00e5rsagen \u2014 i stedet for at fokusere alle vores kr\u00e6fter p\u00e5 at genoprette funktionaliteten.<\/li>\n
  3. Vurder indflydelsen af hver funktion i tjenesten<\/b>. Kunderne brugte sj\u00e6ldent App Registry, s\u00e5 det var ikke en prioritet for vores team. N\u00e5r visse produktfunktioner n\u00e6sten ikke bliver brugt, opst\u00e5r deres fejl sj\u00e6ldent, og udviklerne stopper med at overv\u00e5ge koden. Det er nemt at falde for misforst\u00e5elsen om, at det er som det skal v\u00e6re \u2014 indtil denne funktion pludselig st\u00e5r i centrum af en stor h\u00e6ndelse.<\/li>\n<\/ol>\n

    <\/p>\n

    Hvad nu?<\/h2>\n

    \nArbejdet med at sikre tjenestens stabilitet stopper aldrig, og vi forbedrer konstant den. Trafikm\u00e6ngden p\u00e5 quay.io forts\u00e6tter med at stige, og vi er klar over, at vi skal g\u00f8re alt, hvad vi kan, for at leve op til kundernes tillid. Derfor arbejder vi i \u00f8jeblikket p\u00e5 f\u00f8lgende opgaver:<\/p>\n

      \n
    1. Udrulning af kun-l\u00e6se database-replikaer for at hj\u00e6lpe tjenesten med at h\u00e5ndtere den relevante trafik i tilf\u00e6lde af problemer med den prim\u00e6re RDS-instans.<\/li>\n
    2. Opdatering af RDS-instansen. Den nuv\u00e6rende version er ikke i sig selv et problem. Snarere \u00f8nsker vi blot at fjerne et falsk spor (som vi fulgte under nedbruddet); at holde softwaren opdateret vil fjerne endnu en faktor for fremtidige nedbrud.<\/li>\n
    3. Yderligere caching p\u00e5 tv\u00e6rs af klyngen. Vi forts\u00e6tter med at s\u00f8ge efter omr\u00e5der, hvor caching kan reducere belastningen p\u00e5 databasen.<\/li>\n
    4. Tilf\u00f8jelse af en webapplikationsfirewall (WAF) for at se, hvem der tilslutter sig quay.io, og hvorfor.<\/li>\n
    5. Fra n\u00e6ste release vil Red Hat OpenShift-klyngerne opgive App Registry til fordel for operator kataloger baseret p\u00e5 containerbilleder tilg\u00e6ngelige p\u00e5 quay.io.<\/li>\n
    6. En langsigtet erstatning for App Registry kan v\u00e6re underst\u00f8ttelse af Open Container Initiative (OCI) artefakt specifikationer. Dette implementeres i \u00f8jeblikket som en indbygget funktion i Quay og vil v\u00e6re tilg\u00e6ngeligt for brugerne, n\u00e5r specifikationen er endeligt aftalt.<\/li>\n<\/ol>\n

      \nAlt det ovenst\u00e5ende er en del af Red Hats fortsatte investeringer i quay.io, efterh\u00e5nden som vi g\u00e5r fra et lille \"startup-agtigt\" team til en moden platform drevet af SRE. Vi er klar over, at mange af vores kunder, inklusive Red Hat, er afh\u00e6ngige af quay.io i deres daglige arbejde, og vi str\u00e6ber efter at v\u00e6re s\u00e5 \u00e5bne som muligt om de seneste driftsforstyrrelser og vores fortsatte bestr\u00e6belser p\u00e5 at forbedre os.<\/p>\n

      P.S. fra overs\u00e6tteren<\/h2>\n

      \nL\u00e6s ogs\u00e5 p\u00e5 vores blog:<\/p>\n