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

Obs. overs.<\/b>: i begynnelsen av august offentliggjorde Red Hat l\u00f8sningen p\u00e5 tilgjengelighetsproblemene som hadde oppst\u00e5tt de foreg\u00e5ende m\u00e5nedene for brukerne av deres tjeneste. Quay.io<\/a><\/noindex> (med en containerbilderegister som kom til selskapet med oppkj\u00f8pet av CoreOS). Uansett hvor interessert man er i denne tjenesten som s\u00e5dan, er veien som SRE-ingeni\u00f8rene i selskapet har tatt for \u00e5 diagnostisere og l\u00f8se \u00e5rsakene til krasjet, l\u00e6rerik.<\/i><\/p>\n

\"Post
\n
\n19. mai, tidlig om morgenen (if\u00f8lge sommertiden i Nord-Amerika, EDT), falt tjenesten quay.io. Ulykken p\u00e5virket b\u00e5de brukerne av quay.io og Open Source-prosjektene som bruker quay.io som plattform for bygging og distribusjon av programvare. Red Hat verdsetter tilliten fra begge parter.<\/p>\n

SRE-ingeni\u00f8rteamet grep straks inn for \u00e5 stabilisere tjenesten Quay s\u00e5 raskt som mulig. Imidlertid mens de gjorde dette, mistet kundene muligheten til \u00e5 pushe nye bilder, og de klarte bare sporadisk \u00e5 pull\u2019e eksisterende. Av en ukjent grunn ble databasen quay.io blokkert etter at tjenesten ble skalert opp til full kapasitet.<\/a><\/noindex><\/p>\n

\u00abHva har endret seg?<\/b>\u00bb \u2014 dette er det f\u00f8rste sp\u00f8rsm\u00e5let som vanligvis stilles i slike tilfeller. Vi la merke til at kort tid f\u00f8r problemet begynte, begynte OpenShift Dedicated-klyngen (som quay.io opererer p\u00e5) \u00e5 oppdatere til versjon 4.3.19. Siden quay.io kj\u00f8rer p\u00e5 Red Hat OpenShift Dedicated (OSD), var regelmessige oppdateringer en vanlig operasjon og hadde aldri f\u00f8rt til problemer. Dessuten hadde vi flere ganger oppdatert Quay-klyngene de siste seks m\u00e5nedene uten noen nedetid.<\/p>\n

Mens vi fors\u00f8kte \u00e5 gjenopprette tjenesten, begynte andre ingeni\u00f8rer \u00e5 forberede en ny OSD-klynge med en tidligere versjon av programvaren, slik at de kunne rulle ut alt p\u00e5 den om n\u00f8dvendig.<\/p>\n

Analyse av rot\u00e5rsaken<\/h2>\n

\nDet prim\u00e6re symptomet p\u00e5 feilen var en flom av tiotusener av tilkoblinger til databasen, som gjorde at MySQL-instansen faktisk ble unyttbar. Dette gjorde det vanskelig \u00e5 diagnostisere problemet. Vi satte en grense for det maksimale antallet tilkoblinger fra klientene for \u00e5 hjelpe SRE-teamet med \u00e5 vurdere problemet. Ingen uvanlig trafikk til databasen ble lagt merke til: faktisk var de fleste foresp\u00f8rslene leseforesp\u00f8rsel, og bare noen f\u00e5 var skriveforesp\u00f8rsel.<\/p>\n

Vi har ogs\u00e5 fors\u00f8kt \u00e5 finne et m\u00f8nster i databasetrafikken som kunne ha for\u00e5rsaket denne b\u00f8lgen. Imidlertid klarte vi ikke \u00e5 finne noen m\u00f8nstre i loggene. Mens vi ventet p\u00e5 at den nye klyngen med OSD 4.3.18 skulle bli klar, fortsatte vi \u00e5 fors\u00f8ke \u00e5 starte pod-er fra quay.io. Hver gang klyngen n\u00e5dde full kapasitet, hang databasen seg opp. Dette betydde at vi m\u00e5tte starte RDS-instansen p\u00e5 nytt i tillegg til alle pod-er fra quay.io.<\/p>\n

Om kvelden stabiliserte vi tjenesten i read-only-modus og slo av s\u00e5 mange un\u00f8dvendige funksjoner som mulig (for eksempel s\u00f8ppeloppsamling i navnerommet) for \u00e5 redusere belastningen p\u00e5 databasen. Frysingene opph\u00f8rte, men \u00e5rsaken ble aldri funnet.<\/b>. Den nye OSD-klyngen var klar, og vi flyttet tjenesten, koblet trafikken, og fortsatte overv\u00e5kningen.<\/p>\n

Quay.io fungerte stabilt p\u00e5 den nye OSD-klyngen, s\u00e5 vi gikk tilbake til databaseloggene, men klarte ikke \u00e5 finne noen korrelasjon som forklarte blokkeringen. Ingeni\u00f8rer fra OpenShift jobbet sammen med oss for \u00e5 fors\u00f8ke \u00e5 forst\u00e5 om endringene i Red Hat OpenShift 4.3.19 kunne ha for\u00e5rsaket problemene med Quay. Imidlertid ble det ikke oppdaget noe, og det var ikke mulig \u00e5 gjenskape problemet i laboratorium.<\/b>.<\/p>\n

Det andre feiltrinnet<\/h2>\n

\n28. mai, rett f\u00f8r middagstid EDT, falt quay.io igjen med samme symptom: databasen fr\u00f8s. N igjen satte vi inn all v\u00e5r innsats p\u00e5 etterforskning. F\u00f8rst og fremst var det n\u00f8dvendig \u00e5 gjenopprette drift av tjenesten. Imidlertid denne gangen f\u00f8rte omstart av RDS og omstart av pod-er fra quay.io ikke til noe resultat<\/b>Quay er skrevet i Python, og hver pod fungerer som en enhetlig monolittisk beholder. I containerens kj\u00f8remilj\u00f8 kj\u00f8res mange samtidige oppgaver samtidig. Vi bruker biblioteket<\/p>\n

gevent gunicorn<\/code> under til \u00e5 h\u00e5ndtere webforesp\u00f8rslene. N\u00e5r Quay mottar en foresp\u00f8rsel (via v\u00e5rt eget API eller gjennom Docker API), tildeles det en gevent-arbeider. Vanligvis m\u00e5 denne arbeideren kontakte databasen. Etter det f\u00f8rste feilet oppdaget vi at gevent-arbeiderne koblet seg til databasen ved \u00e5 bruke standardinnstillingene.<\/code> for \u00e5 h\u00e5ndtere webforesp\u00f8rslene. N\u00e5r Quay f\u00e5r en foresp\u00f8rsel (via v\u00e5r egen API eller via Docker API), tildeles den en gevent-worker. Vanligvis m\u00e5 denne workeren koble til databasen. Etter den f\u00f8rste krasjingen oppdaget vi at gevent-workers koblet seg til databasen ved \u00e5 bruke standardinnstillingene.<\/p>\n

Gitt det betydelige antallet Quay-pod-er og tusenvis av foresp\u00f8rslene per sekund, kunne det h\u00f8ye antallet databaskoblinger teoretisk overbelaste MySQL-instansen. Gjennom overv\u00e5king var vi klar over at Quay i gjennomsnitt h\u00e5ndterer 5000 foresp\u00f8rslene per sekund. Omtrent det samme gjaldt for antallet databaskoblinger. 5000 tilkoblinger var innenfor kapasiteten til v\u00e5r RDS-instans (noe som ikke kunne sies om titusenvis). Av en eller annen grunn skjedde det uventede utbrudd av antall forbindelser<\/b>, men vi la ikke merke til noen korrelasjon med innkommende foresp\u00f8rselen.<\/p>\n

Denne gangen bestemte vi oss for \u00e5 finne og l\u00f8se \u00e5rsaken til problemet, i stedet for bare \u00e5 begrense oss til omstart. Det ble gjort endringer i Quay-koden det ble gjort endringer for \u00e5 begrense antall tilkoblinger til databasen for hver worker<\/b> gevent. Dette tallet ble en parameter i konfigurasjonen: det ble mulig \u00e5 endre det \"on-the-fly\", uten \u00e5 m\u00e5tte bygge et nytt containerbilde. For \u00e5 finne ut hvor mange forbindelse som faktisk kunne h\u00e5ndteres, ble det gjennomf\u00f8rt flere tester med staging-milj\u00f8et, hvor ulike verdier ble satt for \u00e5 se hvordan dette ville p\u00e5virke belastningstestscenariene. Til slutt ble det oppdaget at Quay begynte \u00e5 gi feilmeldinger 502 n\u00e5r antallet forbindelser oversteg 10 000.<\/b><\/p>\n

Vi rullet straks ut denne nye versjonen i produksjon og begynte \u00e5 overv\u00e5ke grafen for databaseforbindelser. Tidligere ble databasen l\u00e5st omtrent etter 20 minutter. Etter 30 problemfrie minutter hadde vi h\u00e5p, og etter en time \u2013 selvtillit. Vi gjenopprettet skrive trafikken p\u00e5 nettstedet og begynte p\u00e5 post-mortem analysen.<\/p>\n

Ved \u00e5 omg\u00e5 problemet som f\u00f8rte til l\u00e5singen, fikk vi ikke klarlagt de reelle \u00e5rsakene<\/b>. Det ble bekreftet at det ikke var relatert til noen endringer i OpenShift 4.3.19, da det samme skjedde i versjon 4.3.18, som tidligere hadde fungert med Quay uten problemer.<\/p>\n

Det var \u00e5penbart noe annet som var skjult i klyngen.<\/p>\n

En grundig unders\u00f8kelse<\/h2>\n

\nQuay.io har brukt standardinnstillinger for tilkobling til databasen uten problemer i seks \u00e5r. Hva har endret seg? Det er tydelig at trafikken til quay.io har \u00f8kt jevnt i hele denne tiden. I v\u00e5rt tilfelle s\u00e5 det ut som om vi n\u00e5dde et terskelverdi som utl\u00f8ste en lavine av tilkoblinger. Vi fortsatte \u00e5 unders\u00f8ke database-loggene etter det andre krasjet, men vi fant ingen m\u00f8nstre eller \u00e5penbare sammenhenger.<\/p>\n

I mellomtiden arbeidet SRE-teamet med forbedringer innen observasjon av foresp\u00f8rslene i Quay og den generelle helsen til tjenesten. Nye metrikker og overv\u00e5kningsdashbord<\/b>, som viser hvilke deler av Quay som er mest etterspurt av kundene.<\/p>\n

Quay.io fungerte normalt frem til 9. juni. Om morgenen (i EDT) s\u00e5 vi igjen en betydelig \u00f8kning i antall tilkoblinger til databasen. Denne gangen oppstod det ikke noen nedetid<\/b>, ettersom den nye parameteren begrenset antallet og hindret det i \u00e5 overstige MySQLs kapasitet. Imidlertid rapporterte mange brukere om treghet p\u00e5 quay.io i omtrent en halvtime. Vi samlet raskt s\u00e5 mye data som mulig, ved hjelp av de nye overv\u00e5kingsverkt\u00f8yene. Plutselig viste det seg \u00e5 v\u00e6re et m\u00f8nster.<\/p>\n

F\u00f8r hoppen i antall tilkoblinger, kom et stort antall foresp\u00f8rslene til App Registry API<\/b>. App Registry er en lite kjent funksjon p\u00e5 quay.io. Den gj\u00f8r det mulig \u00e5 lagre ting som Helm-diagrammer og containere med rike metadata. De fleste brukere av quay.io arbeider ikke med denne funksjonen, men den benyttes aktivt av Red Hat OpenShift. OperatorHub som er en del av OpenShift lagrer alle operatorene i App Registry. Disse operatorene danner grunnlaget for OpenShift arbeidsbelastnings\u00f8kosystem og operasjonsmodellen (i forhold til \"andre driftsdag\" operasjoner, Day 2), fokusert p\u00e5 partnere.<\/p>\n

Hver OpenShift 4-klynge bruker operat\u00f8rer fra den innebygde OperatorHub for \u00e5 publisere en katalog over tilgjengelige operat\u00f8rer for installasjon og for \u00e5 gi oppdateringer for allerede installerte. Med den \u00f8kende populariteten til OpenShift 4 har antallet klynger over hele verden ogs\u00e5 \u00f8kt. Hver av disse klyngene laster inn operat\u00f8rinnhold for \u00e5 starte den innebygde OperatorHub, ved \u00e5 bruke App Registry innen quay.io som backend. I jakta etter \u00e5rsaken til problemet, mistet vi faktumet at med den gradvise \u00f8kningen i popularitet for OpenShift, \u00f8kte ogs\u00e5 belastningen p\u00e5 en av de sjeldent brukte funksjonene quay.io.<\/b>.<\/p>\n

Vi har utf\u00f8rt en analyse av foresp\u00f8rselstrafikken til App Registry og tok en titt p\u00e5 koden til registeret. Umiddelbart avdekket vi mangler som gjorde at foresp\u00f8rslene til databasen ble dannet suboptimalt. Under liten belastning for\u00e5rsaket de ikke noe problem, men ved \u00f8kt belastning ble de en kilde til problemer. App Registry hadde to problematiske endepunkter som ikke reagerte godt p\u00e5 \u00f8kt belastning: den f\u00f8rste ga en liste over alle pakker i depotet, den andre returnerte alle blobs for en pakke.<\/p>\n

\u00c5rsaksbekjempelse<\/h2>\n

\nHele den p\u00e5f\u00f8lgende uken jobbet vi med \u00e5 optimalisere koden til App Registry og omgivelsene. \u00c5penbart ineffektive SQL-foresp\u00f8rslene ble omarbeidet, un\u00f8dvendige kall til kommandoen ble fjernet curl<\/code> (det ble aktivert ved hver uttrekking av blob'er), og caching ble lagt til der det var mulig. Deretter ble det gjennomf\u00f8rt omfattende ytelsestesting og hastighet p\u00e5 App Registry ble sammenlignet f\u00f8r og etter endringene.<\/p>\n

API-foresp\u00f8rslene som tidligere tok opptil et halvt minutt, ble n\u00e5 utf\u00f8rt p\u00e5 millisekunder.<\/b>. Neste uke rullet vi ut endringene i produksjon, og siden da har quay.io v\u00e6rt stabilt. I l\u00f8pet av denne tiden har det v\u00e6rt noen br\u00e5 trafikk\u00f8kninger p\u00e5 endpoint'en til App Registry, men de utf\u00f8rte forbedringene har forhindret databaseavbrudd.<\/p>\n

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

\nDet er klart at enhver tjeneste pr\u00f8ver \u00e5 unng\u00e5 nedetid. I v\u00e5rt tilfelle tror vi at de nylige avbruddene har gjort quay.io bedre. Vi har l\u00e6rt flere viktige lekser som vi \u00f8nsker \u00e5 dele:<\/p>\n

    \n
  1. Data om hvem og hvordan folk bruker tjenesten din er aldri overfl\u00f8dige.<\/b>Siden Quay \"bare fungerte\", hadde vi aldri behov for \u00e5 bruke tid p\u00e5 \u00e5 optimalisere trafikken og administrere belastningen. Alt dette skapte en falsk f\u00f8lelse av sikkerhet, at tjenesten kunne skaleres uendelig.<\/li>\n
  2. N\u00e5r en tjeneste g\u00e5r ned, \u00e5 gjenopprette dens funksjon er v\u00e5r hovedprioritet.<\/b>. Sidan Quay fortsatte att lida av en blockerad databas under det f\u00f6rsta felet hade v\u00e5ra standardprocedurer inte den f\u00f6rv\u00e4ntade effekten och vi kunde inte \u00e5terst\u00e4lla tj\u00e4nsten med dem. Det ledde till en situation d\u00e4r vi tvingades spendera tid p\u00e5 att analysera och samla in data i hopp om att hitta den grundl\u00e4ggande orsaken \u2013 ist\u00e4llet f\u00f6r att rikta all v\u00e5r anstr\u00e4ngning mot att \u00e5terst\u00e4lla funktionaliteten.<\/li>\n
  3. Utv\u00e4rdera p\u00e5verkan av varje funktion i tj\u00e4nsten<\/b>. Kunder anv\u00e4nde s\u00e4llan App Registry, s\u00e5 det var inte en prioritet f\u00f6r v\u00e5rt team. N\u00e4r vissa produktfunktioner n\u00e4stan inte anv\u00e4nds, dyker buggar s\u00e4llan upp, och utvecklarna slutar att \u00f6vervaka koden. Det \u00e4r l\u00e4tt att bli offer f\u00f6r missuppfattningen att det \u00e4r som det borde vara \u2013 tills pl\u00f6tsligt den funktionen hamnar i centrum f\u00f6r en stor incident.<\/li>\n<\/ol>\n

    <\/p>\n

    Hva skjer videre?<\/h2>\n

    \nArbetet f\u00f6r att s\u00e4kerst\u00e4lla tj\u00e4nstens stabilitet p\u00e5g\u00e5r st\u00e4ndigt och vi f\u00f6rb\u00e4ttrar den hela tiden. Trafikm\u00e4ngderna p\u00e5 quay.io forts\u00e4tter att v\u00e4xa, och vi \u00e4r medvetna om att vi m\u00e5ste g\u00f6ra allt vi kan f\u00f6r att f\u00f6rtj\u00e4na kundernas f\u00f6rtroende. D\u00e4rf\u00f6r arbetar vi f\u00f6r n\u00e4rvarande med f\u00f6ljande uppgifter:<\/p>\n

      \n
    1. Distribution av skrivskyddade databas-repliker f\u00f6r att hj\u00e4lpa tj\u00e4nsten att hantera relevant trafik vid problem med huvudinstansen RDS.<\/li>\n
    2. Uppdatering av RDS-instansen. Den nuvarande versionen \u00e4r inte i sig ett problem. Snarare vill vi bara ta bort en falsk ledtr\u00e5d (som vi f\u00f6ljde under felet); att h\u00e5lla mjukvaran uppdaterad hj\u00e4lper till att eliminera \u00e4nnu en faktor f\u00f6r framtida avbrott.<\/li>\n
    3. Ytterligare caching \u00f6ver hela klustret. Vi forts\u00e4tter att leta efter omr\u00e5den d\u00e4r caching kan minska belastningen p\u00e5 databasen.<\/li>\n
    4. Till\u00e4gg av en webbapplikationsbrandv\u00e4gg (WAF) f\u00f6r att se vem och varf\u00f6r som ansluter till quay.io.<\/li>\n
    5. Fr\u00e5n och med n\u00e4sta release kommer Red Hat OpenShift-kluster att \u00f6verge App Registry till f\u00f6rm\u00e5n f\u00f6r operatorkataloger baserade p\u00e5 containerbilder som \u00e4r tillg\u00e4ngliga p\u00e5 quay.io.<\/li>\n
    6. En l\u00e5ngsiktig ers\u00e4ttning f\u00f6r App Registry kan vara st\u00f6d f\u00f6r specifikationerna f\u00f6r artefakter fr\u00e5n Open Container Initiative (OCI). F\u00f6r n\u00e4rvarande implementeras det som en inbyggd funktionalitet i Quay och kommer att vara tillg\u00e4nglig f\u00f6r anv\u00e4ndare n\u00e4r specifikationen slutgiltigt godk\u00e4nns.<\/li>\n<\/ol>\n

      \nAlt dette er en del av de p\u00e5g\u00e5ende investeringene fra Red Hat i quay.io, ettersom vi g\u00e5r fra et lite \u00abspirende\u00bb team til en moden plattform drevet av SRE. Vi vet at mange av v\u00e5re kunder, inkludert Red Hat selv, er avhengige av quay.io i sitt daglige arbeid, og vi jobber hardt for \u00e5 v\u00e6re s\u00e5 \u00e5pne som mulig om nylige avbrudd og p\u00e5g\u00e5ende innsats for \u00e5 bli bedre.<\/p>\n

      P.S. from the translator<\/h2>\n

      \nAlso read in our blog:<\/p>\n