Noat. transl.: begjin augustus spruts Red Hat iepenbier oer it oplossen fan tagonklikheidsproblemen dy't brûkers fan har tsjinst yn 'e foargeande moannen tsjinkamen (it is basearre op in register foar kontenerôfbyldings, dy't it bedriuw krige tegearre mei de oankeap fan CoreOS). Nettsjinsteande jo belangstelling foar dizze tsjinst as sadanich, is it paad dat de SRE-yngenieurs fan it bedriuw namen om de oarsaken fan it ûngelok te diagnostearjen en te eliminearjen, ynstruktyf.
Op 19 maaie, moarns betiid (Eastern Daylight Time, EDT), stoarte de quay.io tsjinst. It ûngelok hat ynfloed op sawol quay.io-konsuminten as Open Source-projekten dy't quay.io brûke as platfoarm foar it bouwen en fersprieden fan software. Red Hat wurdearret it fertrouwen fan beide.
In team fan SRE-yngenieurs rekke der daliks by belutsen en besocht de Kaaitsjinst sa gau mooglik te stabilisearjen. Wylst se dit lykwols diene, ferlearen kliïnten de mooglikheid om nije ôfbyldings te triuwen, en mar soms koene se besteande lûke. Om ien of oare ûnbekende reden waard de quay.io-database blokkearre nei it skaaljen fan de tsjinst nei folsleine kapasiteit.
«Wat is feroare?" - dit is de earste fraach dy't yn sokke gefallen normaal steld wurdt. Wy hawwe opmurken dat koart foar it probleem it OpenShift Dedicated kluster (dat rint quay.io) begon te aktualisearjen nei ferzje 4.3.19. Sûnt quay.io rint op Red Hat OpenShift Dedicated (OSD), wiene reguliere updates routine en hawwe nea problemen feroarsake. Boppedat hawwe wy de foargeande seis moannen ferskate kearen Quay-klusters opwurdearre sûnder ûnderbrekking yn tsjinst.
Wylst wy besochten de tsjinst te restaurearjen, begûnen oare yngenieurs in nij OSD-kluster ta te rieden mei de foarige ferzje fan 'e software, sadat as der wat barde, se alles derop koene ynsette.
Root Cause Analysis
It wichtichste symptoom fan 'e mislearring wie in lawine fan tsientûzenen databankferbiningen, dy't de MySQL-eksimplaar effektyf ynoperabel makke. Dit makke it dreech om it probleem te diagnostizen. Wy hawwe in limyt ynsteld foar it maksimale oantal ferbiningen fan kliïnten om it SRE-team te helpen it probleem te evaluearjen. Wy hawwe gjin ûngewoan ferkear opmurken nei de database: yn feite waarden de measte oanfragen lêzen, en mar in pear waarden skreaun.
Wy hawwe ek besocht in patroan te identifisearjen yn it databankferkear dat dizze lawine kin feroarsaakje. Wy koenen lykwols gjin patroanen fine yn 'e logs. Wylst wy wachtsje op it nije kluster mei OSD 4.3.18 om klear te wêzen, bleaunen wy besykje quay.io pods te lansearjen. Elke kear as it kluster folsleine kapasiteit berikte, soe de databank befrieze. Dit betsjutte dat it nedich wie om de RDS-eksimplaar opnij te starten neist alle quay.io-pods.
Tsjin 'e jûn stabilisearren wy de tsjinst yn allinich-lêsmodus en hawwe safolle mooglik net-essensjele funksjes útskeakele (bygelyks nammeromte-garbage collection) om de lading op 'e databank te ferminderjen. Friezen binne stoppe mar de reden waard nea fûn. De nije OSD-kluster wie klear, en wy migrearre de tsjinst, ferbûn ferkear en fuortset tafersjoch.
Quay.io wurke stabyl oan it nije OSD-kluster, dus wy gongen werom nei de database-logs, mar koene gjin korrelaasje fine dy't de blokkades ferklearje soe. OpenShift-yngenieurs wurken mei ús om te begripen oft feroaringen yn Red Hat OpenShift 4.3.19 problemen kinne feroarsaakje mei Quay. Lykwols, neat fûn, en It wie net mooglik om it probleem te reprodusearjen yn laboratoariumomstannichheden.
Twadde mislearring
Op 28 maaie, koart foar middei EDT, crashte quay.io wer mei itselde symptoom: de databank waard blokkearre. En wer hawwe wy al ús ynspanningen yn it ûndersyk smiten. Earst wie it nedich om te herstellen de tsjinst. lykwols dizze kear hat it opnij opstarten fan RDS en it opnij starte fan quay.io-pods neat dien: in oare lawine fan ferbinings hat de basis oerweldige. Wêrom?
Quay is skreaun yn Python en elke pod wurket as ien monolityske kontener. De kontener runtime rint in protte parallelle taken tagelyk. Wy brûke de bibleteek gevent ûnder de gunicorn om weboanfragen te ferwurkjen. Wannear't in fersyk komt yn Quay (fia ús eigen API, of fia Docker's API), wurdt it in jaant wurker tawiisd. Typysk moat dizze arbeider kontakt opnimme mei de databank. Nei de earste mislearring, wy ûntdutsen dat gevent arbeiders ferbine mei de databank mei help fan standert ynstellings.
Sjoen it signifikante oantal Quay-pods en tûzenen ynkommende oanfragen per sekonde, koe in grut oantal databaseferbiningen teoretysk de MySQL-eksimplaar oerweldigje. Mei tank oan tafersjoch wie it bekend dat Quay gemiddeld 5 tûzen oanfragen per sekonde ferwurket. It oantal ferbinings mei de databank wie likernôch itselde. 5 tûzen ferbiningen wiene goed binnen de mooglikheden fan ús RDS-eksimplaar (wat kin net sein wurde oer tsientûzenen). Om ien of oare reden wiene d'r ûnferwachte piken yn it oantal ferbinings, wy hawwe lykwols gjin korrelaasje mei ynkommende oanfragen opmurken.
Dizze kear wiene wy besletten om de boarne fan it probleem te finen en te eliminearjen, en ússels net te beheinen ta in trochstart. Nei de Quay codebase wizigingen waarden makke om it oantal ferbiningen mei de databank foar elke arbeider te beheinen gevent. Dit nûmer waard in parameter yn 'e konfiguraasje: it waard mooglik om it op 'e flecht te feroarjen sûnder in nije kontenerôfbylding te bouwen. Om út te finen hoefolle ferbiningen realistysk koene wurde behannele, hawwe wy ferskate tests útfierd yn in staging-omjouwing, wêrby't ferskate wearden ynstelde om te sjen hoe't dit ynfloed op senario's foar loadtesten soe. Dêrtroch waard dat ûntdutsen Quay begjint te smiten 502 flaters as it oantal ferbinings grutter is as 10 tûzen.
Wy hawwe dizze nije ferzje fuortendaliks ynset foar produksje en begon it skema fan 'e databaseferbining te kontrolearjen. Yn it ferline waard de basis nei sa'n 20 minuten ôfsletten. Nei 30 minuten sûnder problemen hienen wy hoop, en in oere letter hienen wy fertrouwen. Wy restaurearre ferkear nei de side en begûn postmortem analyze.
Nei it slagge om it probleem te omgean dat liedt ta blokkearjen, wy hawwe de echte redenen net fûn. It waard befêstige dat it net relatearre is oan feroaringen yn OpenShift 4.3.19, om't itselde ding barde op ferzje 4.3.18, dy't earder sûnder problemen mei Quay wurke.
Der lei dúdlik wat oars yn it kluster.
Detaillearre stúdzje
Quay.io brûkte de standertynstellingen om seis jier sûnder problemen te ferbinen mei de databank. Wat feroare? It is dúdlik dat al dy tiid it ferkear op quay.io stadichoan groeit. Yn ús gefal like it as wie der in drompelwearde berikt, dy't tsjinne as oanlieding foar in lawine oan ferbinings. Wy bleauwen de databanklogboeken te studearjen nei de twadde mislearring, mar fûnen gjin patroanen of dúdlike relaasjes.
Yn 'e tuskentiid hat it SRE-team wurke oan ferbetteringen fan Quay's fersykberensberens en algemiene tsjinstsûnens. Nije metriken en dashboards binne ynset, toant hokker dielen fan 'e Kade binne meast yn fraach fan klanten.
Quay.io wurke goed oant 9 juny. Fan 'e moarn (EDT) hawwe wy wer in signifikante taname sjoen yn it oantal databaseferbiningen. Dizze kear wie der gjin downtime, om't de nije parameter har oantal beheine en har net tastean om MySQL-trochput te oerwinnen. Lykwols, foar sawat in heal oere, notearre in protte brûkers trage prestaasjes fan quay.io. Wy sammele fluch alle mooglike gegevens mei help fan de tafoege monitoring ark. Ynienen ûntstie der in patroan.
Krekt foar de tanimming fan ferbiningen waarden in grut oantal oanfragen dien oan de App Registry API. App Registry is in bytsje bekende funksje fan quay.io. It lit jo dingen lykas Helm-diagrammen en konteners opslaan mei rike metadata. De measte quay.io-brûkers wurkje net mei dizze funksje, mar Red Hat OpenShift brûkt it aktyf. OperatorHub as ûnderdiel fan OpenShift bewarret alle operators yn 'e App Registry. Dizze operators foarmje de basis foar it OpenShift workload-ekosysteem en partner-sintraal bestjoeringsmodel (operaasjes op dei 2).
Elk OpenShift 4-kluster brûkt operators fan 'e ynboude OperatorHub om in katalogus fan operators te publisearjen dy't beskikber binne foar ynstallaasje en fernijings te leverjen oan dyjingen dy't al ynstallearre binne. Mei de tanimmende populariteit fan OpenShift 4 is it oantal klusters dêrop rûn de wrâld ek tanommen. Elk fan dizze klusters downloadt operatorynhâld om de ynboude OperatorHub út te fieren, mei it App Registry binnen quay.io as de efterkant. Yn ús sykjen nei de boarne fan it probleem miste wy it feit dat as OpenShift stadichoan yn populariteit groeide, de lading op ien fan 'e selden brûkte quay.io-funksjes ek tanommen..
Wy hawwe wat analyse dien fan App Registry-ferkearferkear en sjoch nei de registerkoade. Fuortendaliks waarden tekoartkommingen ûntdutsen, wêrtroch't fragen nei de databank net optimaal foarme waarden. Doe't de lading leech wie, makken se gjin problemen, mar doe't de lading tanaam, waarden se in boarne fan problemen. App Registry die bliken twa problematyske einpunten te hawwen dy't net goed reagearren op tanimmende lading: de earste levere in list fan alle pakketten yn 'e repository, de twadde joech alle blobs foar it pakket werom.
Eliminaasje fan oarsaken
De kommende wike hawwe wy bestege oan it optimalisearjen fan de koade fan it App Registry sels en har omjouwing. Dúdlik net-effektive SQL-fragen waarden opnij bewurke en ûnnedige kommando-oproppen waarden elimineare tar (it waard útfierd eltse kear blobs waarden ophelle), caching waard tafoege wêr mooglik. Wy hawwe doe wiidweidige prestaasjestesten útfierd en de snelheid fan 'e App Registry fergelike foar en nei de wizigingen.
API-oanfragen dy't earder oant in heale minút namen, wurde no foltôge yn millisekonden. De folgjende wike hawwe wy de feroarings ynset yn produksje, en sûnt dy tiid wurket quay.io stabyl. Yn dizze tiid wiene d'r ferskate skerpe piken yn ferkear op it einpunt fan 'e App Registry, mar de makke ferbetteringen foarkommen databankûnderbrekken.
Wat hawwe wy leard?
It is dúdlik dat elke tsjinst besiket downtime te foarkommen. Yn ús gefal leauwe wy dat de resinte ûnderbrekkingen holpen hawwe om quay.io better te meitsjen. Wy hawwe in pear wichtige lessen leard dy't wy graach diele wolle:
- Gegevens oer wa't jo tsjinst brûkt en hoe is nea oerstallich. Om't Quay "krekt wurke", hawwe wy noait tiid hoege te besteegjen oan it optimalisearjen fan ferkear en it behearen fan lading. Dit alles makke in falsk gefoel fan feiligens dat de tsjinst foar ûnbepaalde skaal koe.
- As de tsjinst delkomt, it wer op en rinne litte is in topprioriteit.. Om't Quay by de earste ûnderbrekking noch lêst hie fan in beskoattele databank, hienen ús standertprosedueres net it bedoelde effekt en koenen wy de tsjinst dêrmei net werstelle. Dit late ta in situaasje wêrby't tiid moast wurde bestege oan it analysearjen en sammeljen fan gegevens yn 'e hoop om de oarsaak te finen - ynstee fan alle ynspanningen te rjochtsjen op it werstellen fan funksjonaliteit.
- Evaluearje de ynfloed fan elke tsjinstfunksje. Klanten brûkten komselden App Registry, dus it wie gjin prioriteit foar ús team. As guon produktfunksjes amper brûkt wurde, ferskine har bugs selden, en ûntwikkelders stopje mei it kontrolearjen fan de koade. It is maklik om te fallen oan de misfetting dat dit sa moat wêze - oant ynienen dy funksje him yn it sintrum fan in grut ynsidint fynt.
Wat is folgjende?
It wurk om de stabiliteit fan 'e tsjinst te garandearjen hâldt noait op en wy ferbetterje it konstant. As ferkearsvoluminten trochgean te groeien op quay.io, erkenne wy dat wy in ferantwurdlikens hawwe om alles te dwaan wat wy kinne om it fertrouwen fan ús klanten te libjen. Dêrom wurkje wy op it stuit oan de folgjende taken:
- Ynsette allinich-lês-database-replika's om de tsjinst te helpen passend ferkear te behanneljen yn gefal fan problemen mei de primêre RDS-eksimplaar.
- It bywurkjen fan in RDS-eksimplaar. De hjoeddeistige ferzje sels is net it probleem. Leaver wolle wy gewoan it falske spoar fuortsmite (dy't wy folge hawwe tidens it mislearjen); It bywurkjen fan de software sil in oare faktor eliminearje yn it gefal fan takomstige ûnderbrekkings.
- Oanfoljende caching oer it heule kluster. Wy sykje fierder nei gebieten wêr't caching de lading op 'e databank kin ferminderje.
- In firewall foar webapplikaasje (WAF) tafoegje om te sjen wa't ferbining makket mei quay.io en wêrom.
- Begjin mei de folgjende release sille Red Hat OpenShift-klusters App Registry ferlitte yn it foardiel fan Operator Catalogs basearre op kontenerôfbyldings beskikber op quay.io.
- In ferfanging op lange termyn foar App Registry kin stipe wêze foar artefaktspesifikaasjes fan Open Container Initiative (OCI). It wurdt op it stuit ymplementearre as native Quay-funksjonaliteit en sil beskikber wêze foar brûkers as de spesifikaasje sels is finalisearre.
Al it boppesteande binne diel fan Red Hat's oanhâldende ynvestearring yn quay.io as wy ferhúzje fan in lyts "startup-styl" team nei in folwoeksen SRE-oandreaune platfoarm. Wy witte dat in protte fan ús klanten fertrouwe op quay.io yn har deistich wurk (ynklusyf Red Hat!) En wy besykje sa transparant mooglik te wêzen oer resinte útfallen en trochgeande ynspanningen om te ferbetterjen.
PS fan oersetter
Lês ek op ús blog:
- «";
- «";
- «".
Boarne: www.habr.com