Obs. övers.: I början av augusti meddelade Red Hat offentligt att de hade löst tillgÀnglighetsproblem som hade drabbat anvÀndare av deras tjÀnst under de föregÄende mÄnaderna. (baserat pÄ ett register för containeravbilder som företaget fick med köpet av CoreOS). Oavsett ditt intresse för sjÀlva tjÀnsten, Àr vÀgen som SRE-ingengörer gÄtt för att diagnostisera och ÄtgÀrda orsakerna till kraschen lÀrorik.
Den 19 maj, tidigt pÄ morgonen (enligt sommartid för nordamerikanska östkusten, EDT), föll tjÀnsten quay.io. Kraschningen pÄverkade bÄde anvÀndarna av quay.io och Open Source-projekt som anvÀnde quay.io som plattform för att bygga och sprida mjukvara. Red Hat vÀrdesÀtter förtroendet hos bÄde grupper.
SRE-teamet kopplade omedelbart in sig i arbetet och försökte sĂ„ snabbt som möjligt stabilisera quay-tjĂ€nsten. Medan de jobbade med detta, förlorade kunderna möjligheten att pushâa nya avbilder, och de kunde endast sporadiskt pullâa befintliga. Av nĂ„gon okĂ€nd anledning blockerades databasen quay.io efter att tjĂ€nsten skalades upp till full kapacitet.
«Vad har förĂ€ndrats?» â det hĂ€r Ă€r den första frĂ„gan som anges i sĂ„dana fall. Vi mĂ€rkte att kort före problemet började klustret OpenShift Dedicated (dĂ€r quay.io körs) uppgraderas till version 4.3.19. Eftersom quay.io körs pĂ„ Red Hat OpenShift Dedicated (OSD), var de regelbundna uppgraderingarna en vardagsoperation och hade aldrig lett till problem. Dessutom hade vi under de senaste sex mĂ„naderna uppgraderat Quay-klustren flera gĂ„nger utan nĂ„gra driftstopp.
Medan vi försökte ÄterstÀlla tjÀnsten började andra ingenjörer förbereda ett nytt OSD-kluster med den tidigare versionen av programvaran, sÄ att de snabbt kunde rulla ut allt pÄ det om det skulle behövas.
Analys av grundorsaken
Huvudsymptomet pÄ kraschen var en vÄg av tiotusentals anslutningar till databasen, vilket gjorde att MySQL-instansen blev praktiskt taget obrukbar. Detta gjorde det svÄrt att diagnosticera problemet. Vi satte ett tak för det maximala antalet anslutningar frÄn kunder för att hjÀlpa SRE-teamet att bedöma problemet. Inga ovanliga trafikmönster till databasen observerades: i sjÀlva verket var de flesta förfrÄgningar lÀsningar, medan endast nÄgra var skrivningar.
Vi försökte ocksÄ identifiera ett mönster i databastrafiken som skulle kunna ha orsakat denna lavin. TyvÀrr lyckades vi inte hitta nÄgra mönster i loggarna. Medan vi vÀntade pÄ att den nya klustern med OSD 4.3.18 skulle bli redo fortsatte vi att försöka starta poddar frÄn quay.io. Varje gÄng klustret nÄdde full kapacitet hÀngde databasen sig. Detta innebar att det var nödvÀndigt att starta om RDS-instansen utöver alla poddar frÄn quay.io.
Vid kvÀllningen stabiliserade vi tjÀnsten i read-only-lÀge och stÀngde av maximalt antal ovÀsentliga funktioner (t.ex. skrÀpsamling i namnutrymmet) för att minska belastningen pÄ databasen. HÀngningarna upphörde, men orsaken förblev oklar. Den nya OSD-klustern var klar, och vi flyttade tjÀnsten, kopplade in trafiken och fortsatte övervakningen.
Quay.io fungerade stabilt pÄ den nya OSD-klustern, sÄ vi ÄtervÀnde till databasen loggar, men lyckades fortfarande inte upptÀcka nÄgon korrelation som förklarade lÄsningarna. Ingenjörer frÄn OpenShift arbetade tillsammans med oss för att försöka förstÄ om Àndringarna i Red Hat OpenShift 4.3.19 kunde ha orsakat problem med Quay. Men vi kunde inte hitta nÄgot och det gick inte att reproducera problemet under laboratorieförhÄllanden.
Den andra kraschen
Den 28 maj, strax före middagstid EDT, föll quay.io igen med samma symptom: databasens funktion hÀngdes. à terigen satte vi all kraft pÄ att undersöka. Först och frÀmst var det nödvÀndigt att ÄterstÀlla tjÀnsten. Men denna gÄng ledde omstarten av RDS och omstarten av poddar frÄn quay.io ingenstans: Àn en gÄng övervÀldigades databasen av en lavin av anslutningar. Men varför?
Quay Ă€r skrivet i Python, och varje pod fungerar som en enhetlig monolitiskt container. I containerens körmiljö körs mĂ„nga parallella uppgifter samtidigt. Vi anvĂ€nder biblioteket gevent under gunicorn för att hantera webbförfrĂ„gningar. NĂ€r en förfrĂ„gan nĂ„r Quay (via vĂ„rt eget API eller via Dockerâs API) tilldelas en gevent-arbetare. Normalt sett ska denna arbetare koppla upp sig mot databasen. Efter den första kraschen upptĂ€ckte vi att gevent-arbetarna kopplade till databasen med standardinstĂ€llningarna.
Med tanke pÄ det stora antalet poddar i Quay och de tusentals inkommande förfrÄgningarna per sekund, kunde det teoretiskt sÀtt stora antalet databasanslutningar överbelasta MySQL-instansen. Genom övervakning visste vi att Quay i genomsnitt hanterar 5 000 förfrÄgningar per sekund. Cirka samma antal var det Àven för databasanslutningarna. 5 000 anslutningar fick lÀtt plats inom kapaciteten för vÄr RDS-instans (vilket inte kan sÀgas om tiotusentals). Av nÄgon anledning intrÀffade ovÀntade toppar i antalet anslutningar., men vi sÄg ingen korrelation med de inkommande förfrÄgningarna.
Denna gÄng bestÀmde vi oss för att hitta och ÄtgÀrda kÀlla till problemet istÀllet för att bara begrÀnsa oss till att göra en omstart. I kodbasen för Quay gjordes Àndringar som begrÀnsade antalet databasanslutningar för varje worker gevent. Detta antal blev en parameter i konfigurationen: det blev möjligt att Àndra det "under körning", utan att behöva bygga en ny containerbild. För att ta reda pÄ hur mÄnga anslutningar som verkligen kunde hanteras genomfördes flera tester med staging-miljön, dÀr olika vÀrden angavs för att se hur detta skulle pÄverka belastningstestscenarierna. Resultatet visade att Quay började ge 502-fel nÀr antalet anslutningar översteg 10 000.
Vi rullade omedelbart ut denna nya version i produktion och började övervaka Ätkomsten till databasanslutningarna. Tidigare Àr databasen lÄst efter ungefÀr 20 minuter. Efter 30 problemfria minuter började vi fÄ hopp, och efter en timme - övertygelse. Vi ÄterstÀllde skrivtrafiken pÄ webbplatsen och pÄbörjade postmortem-analysen.
Genom att kringgÄ problemet som ledde till lÄsning, fick vi inte veta dess verkliga orsaker.Det bekrÀftades att det inte var relaterat till nÄgra förÀndringar i OpenShift 4.3.19, eftersom samma sak intrÀffade i version 4.3.18, som tidigare fungerade med Quay utan problem.
Det dolde sig uppenbart nÄgot mer i klustret.
En detaljerad granskning
Quay.io har i sex Är anvÀnt standardinstÀllningar för att ansluta till databasen utan nÄgra problem. Vad har förÀndrats? Det Àr uppenbart att trafiken till quay.io har ökat stadigt under hela denna tid. I vÄrt fall sÄg det ut som att en viss tröskel hade nÄtts, vilket utlöste en lavin av anslutningar. Vi fortsatte att undersöka databasloggarna efter det andra avbrottet, men upptÀckte inga mönster eller uppenbara samband.
Under tiden arbetade SRE-teamet med förbÀttringar inom observabiliteten av förfrÄgningar i Quay och den övergripande hÀlsan hos tjÀnsten. Nya metrik och övervakningspaneler, visade vilka delar av Quay som var mest efterfrÄgade av kunderna.
Quay.io fungerade normalt fram till den 9 juni. PÄ morgonen (EDT) blev vi Äter vittnen till en betydande ökning av antalet anslutningar till databasen. Den hÀr gÄngen intrÀffade inget avbrott, eftersom en ny parameter begrÀnsade antalet anslutningar och inte tillÀt att MySQL:s kapacitet överskreds. Under ungefÀr en halvtimme rapporterade mÄnga anvÀndare att quay.io var lÄngsamt. Vi samlade snabbt in sÄ mycket data som möjligt med hjÀlp av de nyare övervakningsverktygen. Plötsligt framkom ett mönster.
Strax innan sprÄnget i antalet anslutningar kom ett stort antal förfrÄgningar till App Registry API. App Registry Àr en mindre kÀnd funktion i quay.io. Den gör det möjligt att lagra saker som Helm-diagram och containrar med rika metadatan. De flesta anvÀndare av quay.io arbetar inte med den hÀr funktionen, men den anvÀnds flitigt av Red Hat OpenShift. OperatorHub inom OpenShift lagrar alla operatörer i App Registry. Dessa operatörer utgör grunden för ekosystemet av arbetsbelastningar i OpenShift och driftsmodellen (inom ramverket av "day two"-operationer), inriktad pÄ partner.
Varje OpenShift 4-kluster anvÀnder operatörer frÄn den inbyggda OperatorHub för att publicera en katalog över operatörer som Àr tillgÀngliga för installation och för att tillhandahÄlla uppdateringar för redan installerade. Med ökningen av OpenShift 4:s popularitet har Àven antalet kluster pÄ det ökat runt om i vÀrlden. Varje av dessa kluster laddar innehÄll frÄn operatörerna för att köra den inbyggda OperatorHub, med App Registry inuti quay.io som backend. I jakten pÄ problemet missade vi att med den gradvisa ökningen av popularitet för OpenShift ökade ocksÄ belastningen pÄ en av de sÀllan anvÀnda funktionerna quay.io.
Vi gjorde en viss analys av trafikfrÄgor till App Registry och granskade koden för registret. Det blev omedelbart uppenbart att det fanns brister som gjorde att frÄgor till databasen bildades ineffektivt. Vid lÄg belastning orsakade de inga problem, men nÀr belastningen ökade blev de en kÀlla till problem. App Registry hade tvÄ problematiska slutpunkter som reagerade dÄligt pÄ ökad belastning: den första gav en lista över alla paket i förrÄdet, den andra returnerade alla blobbar för paketet.
à tgÀrda orsakerna
Under hela nÀsta vecka arbetade vi med att optimera koden för App Registry och dess omgivning. Vi omarbetade uppenbart ineffektiva SQL-frÄgor, eliminerade onödiga anrop av kommandot tar (det kördes vid varje uthÀmtning av blobbar), lade till caching dÀr det var möjligt. Sedan genomfördes omfattande prestandatestning och hastigheten för App Registry jÀmfördes före och efter Àndringarna.
API-anrop som tidigare tog upp till en halv minut, utfördes nu pÄ millisekunder. Under nÀsta vecka rullade vi ut Àndringarna i produktion, och sedan dess har quay.io fungerat stabilt. Under denna tid har vi sett flera skarpa trafiktoppar pÄ slutpunkten App Registry, men de förbÀttringar som gjordes förhindrade störningar i databasen.
Vad har vi lÀrt oss?
Det Àr sjÀlvklart att varje tjÀnst försöker undvika driftstopp. I vÄrt fall tror vi att de senaste felen har hjÀlpt till att göra quay.io bÀttre. Vi har dragit nÄgra grundlÀggande lÀrdomar som vi vill dela med oss av:
- Information om vem som anvÀnder din tjÀnst och hur de anvÀnder den Àr aldrig överflödig. Eftersom Quay "bara fungerade" hade vi aldrig behov av att spendera tid pÄ att optimera trafik och hantera belastning. Allt detta skapade en falsk kÀnsla av sÀkerhet i att tjÀnsten kunde skalas oÀndligt.
- NÀr en tjÀnst gÄr ner, Àr ÄterstÀllande av dess funktionalitet högsta prioritet. Eftersom Quay fortsatte att lida av en blockerad databas under den första incidenten, hade vÄra standardprocedurer inte den avsedda effekten och vi kunde inte ÄterfÄ tjÀnstens funktionalitet med deras hjÀlp. Detta ledde till en situation dÀr vi var tvungna att spendera tid pÄ analys och insamling av data i hopp om att hitta grundorsaken istÀllet för att fokusera alla anstrÀngningar pÄ att ÄterstÀlla funktionaliteten.
- Bedöm inverkan av varje funktion i tjĂ€nsten. Kunderna anvĂ€nde sĂ€llan App Registry, sĂ„ det var inte en prioritet för vĂ„rt team. NĂ€r vissa produktfunktioner nĂ€stan inte anvĂ€nds, dyker deras buggar sĂ€llan upp och utvecklarna slutar övervaka koden. Det Ă€r lĂ€tt att falla offer för missuppfattningen att allt Ă€r som det ska â tills denna funktion plötsligt hamnar i centrum för en stor incident.
Vad hÀnder hÀrnÀst?
Arbetet med att sÀkerstÀlla tjÀnstens stabilitet pÄgÄr stÀndigt och vi förbÀttrar den kontinuerligt. Trafikvolymerna pÄ quay.io fortsÀtter att vÀxa och vi inser att vi mÄste göra allt för att förtjÀna kundernas förtroende. DÀrför arbetar vi för nÀrvarande med följande uppgifter:
- Utrullning av lÀsbara databaskluster för att hjÀlpa tjÀnsten att hantera relevant trafik om det uppstÄr problem med den primÀra RDS-instansen.
- Uppdatering av RDS-instansen. Den nuvarande versionen Àr i sig inget problem. Snarare vill vi bara ta bort en falsk ledtrÄd (som vi följde under incidenten); att hÄlla programvaran uppdaterad kommer att eliminera en faktor vid framtida avbrott.
- Ytterligare cachning över hela klustret. Vi fortsÀtter att söka efter omrÄden dÀr cachning kan minska belastningen pÄ databasen.
- TillÀgg av en webbapplikationsbrandvÀgg (WAF) för att se vem och varför som ansluter till quay.io.
- FrÄn och med nÀsta release kommer Red Hat OpenShift-kluster att avveckla App Registry till förmÄn för operatorkataloger (Operator Catalogs) baserade pÄ containerbilder tillgÀngliga pÄ quay.io.
- En lÄngsiktig ersÀttning för App Registry kan vara stöd för specifikationerna av artefakter frÄn Open Container Initiative (OCI). Detta implementeras för nÀrvarande som inbyggd funktion i Quay och kommer att vara tillgÀngligt för anvÀndare nÀr specifikationen slutgiltigt godkÀnns.
All of the above is part of Red Hat's ongoing investments in quay.io as we transition from a small "startup-like" team to a mature platform managed by SRE. We know that many of our customers rely on quay.io in their daily operations (including Red Hat!) and we strive to be as transparent as possible regarding recent outages and our ongoing efforts to improve.
P.S. frÄn översÀttaren
LÀs Àven i vÄr blogg:
- «»;
- «»;
- «».
KĂ€lla: habr.com
