ProHoster > Blogs > Administrācija > Post Mortem vietnē Quay.io nav pieejams

Post Mortem vietnē Quay.io nav pieejams

PiezÄ«me. tulk.: augusta sākumā Red Hat publiski runāja par pieejamÄ«bas problēmu risināŔanu, ar kurām tā pakalpojuma lietotāji bija saskāruÅ”ies iepriekŔējos mēneÅ”os Quay.io (tas ir balstÄ«ts uz konteinera attēlu reÄ£istru, ko uzņēmums saņēma kopā ar CoreOS iegādi). NeatkarÄ«gi no jÅ«su intereses par Å”o pakalpojumu kā tādu, uzņēmuma SRE inženieru ceļŔ, lai diagnosticētu un novērstu negadÄ«juma cēloņus, ir pamācoÅ”s.

Post Mortem vietnē Quay.io nav pieejams

19. maijā agri no rÄ«ta (Austrumu vasaras laiks, EDT) quay.io pakalpojums avarēja. NegadÄ«jums skāra gan quay.io patērētājus, gan atvērtā koda projektus, izmantojot quay.io kā platformu programmatÅ«ras izveidei un izplatÄ«Å”anai. Red Hat augstu vērtē abu uzticÄ«bu.

SRE inženieru komanda nekavējoties iesaistÄ«jās un centās pēc iespējas ātrāk stabilizēt Quay pakalpojumu. Tomēr, kamēr viņi to darÄ«ja, klienti zaudēja iespēju nospiest jaunus attēlus un tikai reizēm varēja izvilkt esoÅ”os. Nezināma iemesla dēļ quay.io datubāze tika bloķēta pēc pakalpojuma mērogoÅ”anas lÄ«dz pilnai jaudai.

Ā«Kas ir mainÄ«jies?" - tas ir pirmais jautājums, kas parasti tiek uzdots Ŕādos gadÄ«jumos. Mēs pamanÄ«jām, ka neilgi pirms problēmas OpenShift Dedicated klasteris (kurā darbojas quay.io) sāka atjaunināt uz versiju 4.3.19. Tā kā quay.io darbojas ar Red Hat OpenShift Dedicated (OSD), regulāri atjauninājumi bija regulāri un nekad nav radÄ«juÅ”i problēmas. Turklāt pēdējo seÅ”u mēneÅ”u laikā mēs esam vairākas reizes jauninājuÅ”i Quay klasterus bez jebkādiem pakalpojumu pārtraukumiem.

Kamēr mēs mēģinājām atjaunot pakalpojumu, citi inženieri sāka sagatavot jaunu OSD klasteru ar iepriekŔējo programmatÅ«ras versiju, lai, ja kaut kas notiktu, viņi varētu tajā izvietot visu.

Pamatcēloņu analīze

Galvenais kļūmes simptoms bija desmitiem tÅ«kstoÅ”u datu bāzes savienojumu lavÄ«na, kas padarÄ«ja MySQL gadÄ«jumu faktiski nederÄ«gu. Tas apgrÅ«tināja problēmas diagnosticÄ“Å”anu. Mēs esam noteikuÅ”i ierobežojumu maksimālajam savienojumu skaitam no klientiem, lai palÄ«dzētu SRE komandai novērtēt problēmu. Mēs nepamanÄ«jām nekādu neparastu trafiku datu bāzē: patiesÄ«bā lielākā daļa pieprasÄ«jumu tika izlasÄ«ti un tikai daži tika rakstÄ«ti.

Mēs arÄ« mēģinājām identificēt datu bāzes trafika modeli, kas varētu izraisÄ«t Å”o lavÄ«nu. Tomēr mēs nevarējām atrast žurnālos nekādus rakstus. Gaidot, kad bÅ«s gatavs jaunais klasteris ar OSD 4.3.18, mēs turpinājām mēģināt palaist quay.io pods. Katru reizi, kad klasteris sasniedza pilnu jaudu, datubāze iesaldēs. Tas nozÄ«mēja, ka papildus visiem quay.io podiem bija jārestartē RDS instance.

LÄ«dz vakaram mēs stabilizējām pakalpojumu tikai lasÄ«Å”anas režīmā un atspējojām pēc iespējas vairāk nebÅ«tisku funkciju (piemēram, nosaukumvietas atkritumu savākÅ”anu), lai samazinātu datu bāzes slodzi. SaldÄ“Å”ana ir apstājusies bet iemesls tā arÄ« netika atrasts. Jaunais OSD klasteris bija gatavs, un mēs migrējām pakalpojumu, savienojām trafiku un turpinājām uzraudzÄ«bu.

Quay.io stabili strādāja pie jaunā OSD klastera, tāpēc mēs atgriezāmies datu bāzes žurnālos, taču nevarējām atrast korelāciju, kas izskaidrotu aizsprostojumus. OpenShift inženieri sadarbojās ar mums, lai saprastu, vai Red Hat OpenShift 4.3.19 izmaiņas var radīt problēmas ar Quay. Tomēr nekas netika atrasts, un Problēmu nebija iespējams reproducēt laboratorijas apstākļos.

Otrā neveiksme

28. maijā, Ä«si pirms pusdienlaika EDT, quay.io atkal avarēja ar tādu paÅ”u simptomu: datubāze tika bloķēta. Un atkal mēs pielikām visas pÅ«les izmeklÄ“Å”anai. Pirmkārt, bija nepiecieÅ”ams atjaunot servisu. Tomēr Å”oreiz rebooting RDS un restartējot quay.io pods neko nedarÄ«ja: kārtējā savienojumu lavÄ«na ir pārņēmusi bāzi. Bet kāpēc?

Quay ir rakstÄ«ts Python valodā, un katrs pods darbojas kā viens monolÄ«ts konteiners. Konteinera izpildlaikā vienlaikus tiek izpildÄ«ti daudzi paralēli uzdevumi. Mēs izmantojam bibliotēku gevent saskaņā ar gunicorn lai apstrādātu tÄ«mekļa pieprasÄ«jumus. Kad pieprasÄ«jums nonāk Quay (izmantojot mÅ«su paÅ”u API vai Docker API), tam tiek pieŔķirts gevent darbinieks. Parasti Å”im darbiniekam jāsazinās ar datu bāzi. Pēc pirmās kļūmes mēs atklājām, ka programmas darbinieki izveido savienojumu ar datu bāzi, izmantojot noklusējuma iestatÄ«jumus.

Ņemot vērā ievērojamo Quay podziņu skaitu un tÅ«kstoÅ”iem ienākoÅ”o pieprasÄ«jumu sekundē, liels skaits datu bāzes savienojumu teorētiski varētu pārslogot MySQL gadÄ«jumu. Pateicoties monitoringam, bija zināms, ka Quay apstrādā vidēji 5 tÅ«kstoÅ”us pieprasÄ«jumu sekundē. Savienojumu skaits ar datu bāzi bija aptuveni vienāds. 5 tÅ«kstoÅ”i savienojumu bija mÅ«su RDS instances iespēju robežās (ko nevar teikt par desmitiem tÅ«kstoÅ”u). Kādu iemeslu dēļ bija negaidÄ«ti pieslēgumu skaita pieaugumstomēr mēs nepamanÄ«jām nekādu korelāciju ar ienākoÅ”ajiem pieprasÄ«jumiem.

Å oreiz mēs bijām apņēmÄ«bas pilni atrast un novērst problēmas avotu, nevis aprobežoties ar pārstartÄ“Å”anu. Uz Quay kodu bāzi tika veiktas izmaiņas, lai ierobežotu savienojumu skaitu ar datu bāzi katram darbiniekam gevent. Å is numurs kļuva par parametru konfigurācijā: kļuva iespējams to mainÄ«t lidojuma laikā, neveidojot jaunu konteinera attēlu. Lai noskaidrotu, cik savienojumus var reāli apstrādāt, mēs veicām vairākus testus iestudējuma vidē, iestatot dažādas vērtÄ«bas, lai redzētu, kā tas ietekmēs slodzes testÄ“Å”anas scenārijus. Rezultātā tika atklāts, ka Quay sāk mest 502 kļūdas, kad pieslēgumu skaits pārsniedz 10 tÅ«kstoÅ”us.

Mēs nekavējoties izvietojām Å”o jauno versiju ražoÅ”anā un sākām uzraudzÄ«t datu bāzes savienojuma grafiku. Agrāk bāze tika bloķēta apmēram pēc 20 minÅ«tēm. Pēc 30 bezproblēmām minÅ«tēm mums bija cerÄ«ba, un stundu vēlāk mums bija pārliecÄ«ba. Mēs atjaunojām vietnes trafiku un sākām pēcnāves analÄ«zi.

Kad izdevās apiet problēmu, kas noveda pie bloÄ·Ä“Å”anas, mēs neesam noskaidrojuÅ”i tās patiesos iemeslus. Tika apstiprināts, ka tas nav saistÄ«ts ar izmaiņām OpenShift 4.3.19, jo tas pats notika ar versiju 4.3.18, kas iepriekÅ” strādāja ar Quay bez problēmām.

Klasterī nepārprotami slēpās kaut kas cits.

Detalizēts pētījums

Quay.io izmantoja noklusējuma iestatÄ«jumus, lai seÅ”us gadus bez problēmām izveidotu savienojumu ar datubāzi. Kas mainÄ«jās? Ir skaidrs, ka visu Å”o laiku satiksme uz quay.io ir nepārtraukti pieaugusi. MÅ«su gadÄ«jumā izskatÄ«jās, ka ir sasniegta kāda sliekŔņa vērtÄ«ba, kas kalpoja par savienojumu lavÄ«nas izraisÄ«tāju. Mēs turpinājām pētÄ«t datu bāzes žurnālus pēc otrās neveiksmes, taču neatradām nekādus modeļus vai acÄ«mredzamas attiecÄ«bas.

Pa to laiku SRE komanda ir strādājusi pie Quay pieprasījuma novērojamības un vispārējā pakalpojuma stāvokļa uzlabojumiem. Ir izvietoti jauni rādītāji un informācijas paneļi, kas parāda, kuras piestātnes daļas ir visvairāk pieprasītas no klientiem.

Quay.io darbojās labi lÄ«dz 9. jÅ«nijam. Å orÄ«t (EDT) atkal novērojām ievērojamu datu bāzes savienojumu skaita pieaugumu. Å oreiz dÄ«kstāves nebija, jo jaunais parametrs ierobežoja to skaitu un neļāva tiem pārsniegt MySQL caurlaidspēju. Tomēr apmēram pusstundu daudzi lietotāji atzÄ«mēja quay.io lēnu darbÄ«bu. Mēs ātri savācām visus iespējamos datus, izmantojot pievienotos uzraudzÄ«bas rÄ«kus. PēkŔņi parādÄ«jās modelis.

TieÅ”i pirms savienojumu pieauguma App Registry API tika iesniegts liels skaits pieprasÄ«jumu. Lietotņu reÄ£istrs ir maz zināma quay.io funkcija. Tas ļauj saglabāt tādas lietas kā Helm diagrammas un konteinerus ar bagātÄ«giem metadatiem. Lielākā daļa quay.io lietotāju nedarbojas ar Å”o funkciju, bet Red Hat OpenShift to aktÄ«vi izmanto. OperatorHub kā daļa no OpenShift visus operatorus saglabā lietotņu reÄ£istrā. Å ie operatori veido pamatu OpenShift darba slodzes ekosistēmai un uz partneri orientētam darbÄ«bas modelim (2. dienas operācijas).

Katrā OpenShift 4 klasterÄ« tiek izmantoti operatori no iebÅ«vētā OperatorHub, lai publicētu instalÄ“Å”anai pieejamo operatoru katalogu un nodroÅ”inātu jau instalēto operatoru atjauninājumus. Pieaugot OpenShift 4 popularitātei, ir palielinājies arÄ« klasteru skaits tajā visā pasaulē. Katrs no Å”iem klasteriem lejupielādē operatora saturu, lai palaistu iebÅ«vēto OperatorHub, kā aizmugursistēmu izmantojot lietotņu reÄ£istru, kas atrodas quay.io. Meklējot problēmas avotu, mēs palaidām garām faktu, ka, OpenShift pakāpeniski augot popularitātei, palielinājās arÄ« vienas no reti izmantotajām quay.io funkcijām slodze..

Mēs veicām lietotņu reÄ£istra pieprasÄ«jumu trafika analÄ«zi un apskatÄ«jām reÄ£istra kodu. TÅ«lÄ«t tika atklātas nepilnÄ«bas, kuru dēļ vaicājumi datu bāzei netika veidoti optimāli. Kad slodze bija zema, tie nesagādāja nekādas nepatikÅ”anas, bet, slodzei palielinoties, kļuva par problēmu avotu. Lietojumprogrammu reÄ£istram izrādÄ«jās divi problemātiski galapunkti, kas slikti reaģēja uz pieaugoÅ”o slodzi: pirmais sniedza visu repozitorijā esoÅ”o pakotņu sarakstu, otrais atgrieza visus pakotnes blokus.

Cēloņu likvidÄ“Å”ana

Nākamās nedēļas laikā mēs optimizējām paÅ”a lietotņu reÄ£istra kodu un tā vidi. AcÄ«mredzami neefektÄ«vie SQL vaicājumi tika pārstrādāti un nevajadzÄ«gi komandu izsaukumi tika novērsti tar (tas tika palaists katru reizi, kad tika izgÅ«ti blobi), keÅ”atmiņa tika pievienota, kur vien iespējams. Pēc tam mēs veicām plaÅ”u veiktspējas pārbaudi un salÄ«dzinājām lietotņu reÄ£istra ātrumu pirms un pēc izmaiņām.

API pieprasÄ«jumi, kas iepriekÅ” ilga lÄ«dz pusminÅ«tei, tagad tiek izpildÄ«ti milisekundēs. Nākamajā nedēļā mēs izvietojām izmaiņas ražoÅ”anā, un kopÅ” tā laika quay.io darbojas stabili. Å ajā laikā lietotņu reÄ£istra galapunktā bija vairāki krasi trafika pieaugumi, taču veiktie uzlabojumi novērsa datu bāzes pārtraukumus.

Ko mēs esam iemācÄ«juÅ”ies?

Ir skaidrs, ka jebkurÅ” pakalpojums cenÅ”as izvairÄ«ties no dÄ«kstāves. MÅ«su gadÄ«jumā mēs uzskatām, ka nesenie pārtraukumi ir palÄ«dzējuÅ”i uzlabot vietni quay.io. Mēs esam guvuÅ”i dažas galvenās atziņas, ar kurām vēlamies dalÄ«ties:

  1. Dati par to, kas un kā izmanto jÅ«su pakalpojumu, nekad nav lieki. Tā kā Quay ā€œtikai strādājaā€, mums nekad nebija jātērē laiks satiksmes optimizÄ“Å”anai un slodzes pārvaldÄ«bai. Tas viss radÄ«ja maldÄ«gu droŔības sajÅ«tu, ko pakalpojums varēja mērogot bezgalÄ«gi.
  2. Kad pakalpojums pazÅ«d, tā atjaunoÅ”ana un darbÄ«ba ir galvenā prioritāte.. Tā kā pirmā pārtraukuma laikā Quay turpināja ciest no bloķētas datu bāzes, mÅ«su standarta procedÅ«rām nebija paredzētā efekta, un mēs nevarējām atjaunot pakalpojumu, izmantojot tās. Tas noveda pie situācijas, kad laiks bija jāpavada, analizējot un apkopojot datus, cerot atrast galveno cēloni, nevis koncentrēt visus spēkus uz funkcionalitātes atjaunoÅ”anu.
  3. Novērtējiet katra pakalpojuma funkcijas ietekmi. Klienti reti izmantoja App Registry, tāpēc tā nebija mÅ«su komandas prioritāte. Ja dažas produkta funkcijas tiek tik tikko izmantotas, to kļūdas parādās reti, un izstrādātāji pārtrauc koda uzraudzÄ«bu. Ir viegli kļūt par upuri maldÄ«gam priekÅ”statam, ka tā tam vajadzētu bÅ«t, lÄ«dz pēkŔņi Ŕī funkcija nonāk liela incidenta centrā.

Ko tālāk?

Darbs, lai nodroÅ”inātu pakalpojuma stabilitāti, neapstājas, un mēs to pastāvÄ«gi pilnveidojam. Tā kā satiksmes apjoms vietnē quay.io turpina pieaugt, mēs atzÄ«stam, ka esam atbildÄ«gi par visu iespējamo, lai attaisnotu mÅ«su klientu uzticÄ«bu. Tāpēc Å”obrÄ«d strādājam pie Ŕādiem uzdevumiem:

  1. Izvietojiet tikai lasāmas datu bāzes replikas, lai palÄ«dzētu pakalpojumam apstrādāt atbilstoÅ”u trafiku, ja rodas problēmas ar primāro RDS gadÄ«jumu.
  2. RDS instances atjaunināŔana. PaÅ”reizējā versija pati par sevi nav problēma. DrÄ«zāk mēs vienkārÅ”i vēlamies noņemt viltus pēdas (kurai mēs sekojām neveiksmes laikā); ProgrammatÅ«ras atjaunināŔana nākotnē novērsÄ«s citu faktoru.
  3. Papildu keÅ”atmiņa visā klasterÄ«. Mēs turpinām meklēt apgabalus, kur keÅ”atmiņa var samazināt datu bāzes slodzi.
  4. TÄ«mekļa lietojumprogrammu ugunsmÅ«ra (WAF) pievienoÅ”ana, lai redzētu, kurÅ” un kāpēc izveido savienojumu ar quay.io.
  5. Sākot ar nākamo laidienu, Red Hat OpenShift kopas atteiksies no lietotņu reģistra par labu operatoru katalogiem, pamatojoties uz konteineru attēliem, kas pieejami vietnē quay.io.
  6. Ilgtermiņa lietotņu reÄ£istra aizstājējs varētu bÅ«t Open Container Initiative (OCI) artefaktu specifikāciju atbalsts. PaÅ”laik tā ir ieviesta kā vietējā Quay funkcionalitāte un bÅ«s pieejama lietotājiem, kad pati specifikācija bÅ«s pabeigta.

Viss iepriekÅ” minētais ir daļa no Red Hat pastāvÄ«gajiem ieguldÄ«jumiem quay.io, jo mēs pārejam no nelielas "startÄ“Å”anas stila" komandas uz nobrieduÅ”u SRE virzÄ«tu platformu. Mēs zinām, ka daudzi mÅ«su klienti savā ikdienas darbā (tostarp Red Hat!) paļaujas uz quay.io, un mēs cenÅ”amies pēc iespējas pārskatāmāk runāt par nesenajiem pārtraukumiem un paÅ”reizējiem centieniem uzlabot.

PS no tulka

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru