Tandaan. transl.: noong unang bahagi ng Agosto, pampublikong nagsalita ang Red Hat tungkol sa paglutas ng mga problema sa accessibility na naranasan ng mga user ng serbisyo nito sa mga nakaraang buwan (ito ay batay sa isang registry para sa mga imahe ng lalagyan, na natanggap ng kumpanya kasama ng pagbili ng CoreOS). Anuman ang iyong interes sa serbisyong ito, ang landas na tinahak ng mga inhinyero ng SRE ng kumpanya upang masuri at maalis ang mga sanhi ng aksidente ay nakapagtuturo.
Noong Mayo 19, madaling araw (Eastern Daylight Time, EDT), bumagsak ang serbisyo ng quay.io. Ang aksidente ay nakaapekto sa parehong quay.io consumer at Open Source na mga proyekto gamit ang quay.io bilang isang platform para sa pagbuo at pamamahagi ng software. Pinahahalagahan ng Red Hat ang tiwala ng dalawa.
Agad na nasangkot ang isang pangkat ng mga inhinyero ng SRE at sinubukang patatagin ang serbisyo ng Quay sa lalong madaling panahon. Gayunpaman, habang ginagawa nila ito, nawalan ng kakayahan ang mga kliyente na mag-push ng mga bagong larawan, at paminsan-minsan lang sila nakakakuha ng mga dati nang larawan. Para sa hindi kilalang dahilan, ang database ng quay.io ay na-block pagkatapos i-scale ang serbisyo sa buong kapasidad.
Β«Ano ang nagbago?" - ito ang unang tanong na karaniwang itinatanong sa mga ganitong pagkakataon. Napansin namin na ilang sandali bago ang isyu, nagsimulang mag-update ang OpenShift Dedicated cluster (na tumatakbo sa quay.io) sa bersyon 4.3.19. Dahil ang quay.io ay tumatakbo sa Red Hat OpenShift Dedicated (OSD), ang mga regular na update ay nakagawian at hindi kailanman nagdulot ng mga problema. Higit pa rito, sa nakaraang anim na buwan, ilang beses naming in-upgrade ang mga cluster ng Quay nang walang anumang pagkaantala sa serbisyo.
Habang sinusubukan naming ibalik ang serbisyo, nagsimulang maghanda ang ibang mga inhinyero ng bagong OSD cluster kasama ang nakaraang bersyon ng software, upang kung may mangyari, mai-deploy nila ang lahat dito.
Pagsusuri sa Root Cause
Ang pangunahing sintomas ng pagkabigo ay isang avalanche ng sampu-sampung libong mga koneksyon sa database, na naging epektibong hindi nagagamit ang MySQL instance. Ito ay naging mahirap na masuri ang problema. Nagtakda kami ng limitasyon sa maximum na bilang ng mga koneksyon mula sa mga kliyente upang matulungan ang SRE team na suriin ang isyu. Hindi namin napansin ang anumang hindi pangkaraniwang trapiko sa database: sa katunayan, karamihan sa mga kahilingan ay binasa, at iilan lamang ang sumulat.
Sinubukan din naming tumukoy ng pattern sa trapiko ng database na maaaring magdulot ng avalanche na ito. Gayunpaman, wala kaming mahanap na anumang pattern sa mga log. Habang naghihintay na maging handa ang bagong cluster na may OSD 4.3.18, ipinagpatuloy namin ang pagsubok na maglunsad ng mga quay.io pod. Sa bawat oras na ang kumpol ay umabot sa buong kapasidad, ang database ay mag-freeze. Nangangahulugan ito na kinakailangang i-restart ang RDS instance bilang karagdagan sa lahat ng quay.io pods.
Pagsapit ng gabi, pinatatag namin ang serbisyo sa read-only na mode at hindi pinagana ang pinakamaraming hindi mahahalagang function hangga't maaari (halimbawa, pagkolekta ng basura sa namespace) upang bawasan ang pagkarga sa database. Huminto ang pagyeyelo ngunit hindi nahanap ang dahilan. Handa na ang bagong cluster ng OSD, at inilipat namin ang serbisyo, nakakonekta ang trapiko at patuloy na pagsubaybay.
Ang Quay.io ay gumana nang matatag sa bagong cluster ng OSD, kaya bumalik kami sa mga log ng database, ngunit hindi makahanap ng ugnayan na magpapaliwanag sa mga pagbara. Ang mga inhinyero ng OpenShift ay nakipagtulungan sa amin upang maunawaan kung ang mga pagbabago sa Red Hat OpenShift 4.3.19 ay maaaring magdulot ng mga problema sa Quay. Gayunpaman, walang natagpuan, at Hindi posible na muling gawin ang problema sa mga kondisyon ng laboratoryo.
Pangalawang kabiguan
Noong Mayo 28, bago magtanghali ng EDT, nag-crash muli ang quay.io na may parehong sintomas: na-block ang database. At muli naming itinapon ang lahat ng aming pagsisikap sa pagsisiyasat. Una sa lahat, ito ay kinakailangan upang ibalik ang serbisyo. Gayunpaman sa pagkakataong ito, ang pag-reboot ng RDS at pag-restart ng quay.io pods ay walang nagawa: isa pang avalanche ng mga koneksyon ang bumagsak sa base. Pero bakit?
Ang Quay ay nakasulat sa Python at ang bawat pod ay gumagana bilang isang solong monolitik na lalagyan. Ang runtime ng container ay nagpapatakbo ng maraming magkakatulad na gawain nang sabay-sabay. Ginagamit namin ang library gevent sa ilalim gunicorn upang iproseso ang mga kahilingan sa web. Kapag ang isang kahilingan ay dumating sa Quay (sa pamamagitan ng aming sariling API, o sa pamamagitan ng Docker's API), ito ay itatalaga ng isang gevent worker. Karaniwan ang manggagawang ito ay dapat makipag-ugnayan sa database. Pagkatapos ng unang pagkabigo, natuklasan namin na ang mga manggagawang gevent ay kumokonekta sa database gamit ang mga default na setting.
Dahil sa malaking bilang ng mga Quay pod at libu-libong mga papasok na kahilingan sa bawat segundo, ang isang malaking bilang ng mga koneksyon sa database ay maaaring theoretically madaig ang MySQL halimbawa. Salamat sa pagsubaybay, nalaman na ang Quay ay nagpoproseso ng average na 5 libong mga kahilingan bawat segundo. Ang bilang ng mga koneksyon sa database ay humigit-kumulang pareho. 5 libong mga koneksyon ay nasa loob ng mga kakayahan ng aming halimbawa ng RDS (na hindi masasabing tungkol sa sampu-sampung libo). Sa ilang kadahilanan, nagkaroon ng mga hindi inaasahang pagtaas sa bilang ng mga koneksyon, gayunpaman, hindi namin napansin ang anumang ugnayan sa mga papasok na kahilingan.
Sa pagkakataong ito, determinado kaming hanapin at alisin ang pinagmulan ng problema, at hindi limitahan ang aming sarili sa pag-reboot. Sa Quay codebase ginawa ang mga pagbabago upang limitahan ang bilang ng mga koneksyon sa database para sa bawat manggagawa gevent. Ang numerong ito ay naging isang parameter sa pagsasaayos: naging posible na baguhin ito nang mabilisan nang hindi gumagawa ng bagong imahe ng lalagyan. Upang malaman kung gaano karaming mga koneksyon ang maaaring makatotohanang pangasiwaan, nagpatakbo kami ng ilang mga pagsubok sa isang kapaligiran ng pagtatanghal, na nagtatakda ng iba't ibang mga halaga upang makita kung paano ito makakaapekto sa mga senaryo ng pagsubok sa pagkarga. Bilang isang resulta, ito ay natuklasan na Ang Quay ay nagsimulang maghagis ng 502 na mga error kapag ang bilang ng mga koneksyon ay lumampas sa 10 libo.
Agad naming inilagay ang bagong bersyon na ito sa produksyon at nagsimulang subaybayan ang iskedyul ng koneksyon sa database. Noong nakaraan, ang base ay naka-lock pagkatapos ng humigit-kumulang 20 minuto. Pagkatapos ng 30 minutong walang problema ay nagkaroon kami ng pag-asa, at pagkaraan ng isang oras nagkaroon kami ng kumpiyansa. Ibinalik namin ang trapiko sa site at sinimulan ang pagsusuri sa postmortem.
Ang pagkakaroon ng pinamamahalaang laktawan ang problema na humahantong sa pagharang, hindi namin nalaman ang tunay na dahilan nito. Nakumpirma na hindi ito nauugnay sa anumang mga pagbabago sa OpenShift 4.3.19, dahil ang parehong bagay ay nangyari sa bersyon 4.3.18, na dating nagtrabaho sa Quay nang walang anumang mga problema.
Malinaw na may iba pang nakaabang sa kumpol.
Detalyadong Pag-aaral
Ginamit ng Quay.io ang mga default na setting para kumonekta sa database sa loob ng anim na taon nang walang anumang problema. Ano ang nagbago? Malinaw na sa lahat ng oras na ito ang trapiko sa quay.io ay patuloy na lumalaki. Sa aming kaso, mukhang naabot na ang ilang halaga ng threshold, na nagsilbing trigger para sa isang avalanche ng mga koneksyon. Ipinagpatuloy namin ang pag-aaral ng mga log ng database pagkatapos ng pangalawang kabiguan, ngunit wala kaming nakitang anumang mga pattern o malinaw na mga relasyon.
Pansamantala, ang SRE team ay gumagawa ng mga pagpapabuti sa kahilingan ng Quay na obserbasyon at pangkalahatang kalusugan ng serbisyo. Na-deploy na ang mga bagong sukatan at dashboard, na nagpapakita kung aling mga bahagi ng Quay ang pinaka-in demand mula sa mga customer.
Naging maayos ang Quay.io hanggang ika-9 ng Hunyo. Ngayong umaga (EDT) muli naming nakita ang isang makabuluhang pagtaas sa bilang ng mga koneksyon sa database. Sa pagkakataong ito ay walang downtime, dahil nilimitahan ng bagong parameter ang kanilang bilang at hindi pinahintulutan silang lumampas sa MySQL throughput. Gayunpaman, sa loob ng halos kalahating oras, napansin ng maraming user ang mabagal na performance ng quay.io. Mabilis naming nakolekta ang lahat ng posibleng data gamit ang mga karagdagang tool sa pagsubaybay. Biglang lumitaw ang isang pattern.
Bago ang pagdami ng mga koneksyon, maraming kahilingan ang ginawa sa App Registry API. Ang App Registry ay isang hindi kilalang feature ng quay.io. Nagbibigay-daan ito sa iyong mag-imbak ng mga bagay tulad ng mga Helm chart at container na may rich metadata. Karamihan sa mga gumagamit ng quay.io ay hindi gumagana sa tampok na ito, ngunit aktibong ginagamit ito ng Red Hat OpenShift. Ang OperatorHub bilang bahagi ng OpenShift ay nag-iimbak ng lahat ng mga operator sa App Registry. Ang mga operator na ito ay bumubuo ng batayan para sa OpenShift workload ecosystem at partner-centric na operating model (Day 2 operations).
Gumagamit ang bawat cluster ng OpenShift 4 ng mga operator mula sa built-in na OperatorHub upang mag-publish ng catalog ng mga operator na magagamit para sa pag-install at magbigay ng mga update sa mga naka-install na. Sa lumalagong katanyagan ng OpenShift 4, tumaas din ang bilang ng mga kumpol dito sa buong mundo. Ang bawat isa sa mga cluster na ito ay nagda-download ng nilalaman ng operator upang patakbuhin ang built-in na OperatorHub, gamit ang App Registry sa loob ng quay.io bilang backend. Sa aming paghahanap para sa pinagmulan ng problema, hindi namin nakuha ang katotohanan na habang unti-unting lumalago ang OpenShift sa katanyagan, tumaas din ang pag-load sa isa sa mga bihirang ginagamit na function ng quay.io..
Gumawa kami ng ilang pagsusuri sa trapiko ng kahilingan sa App Registry at tiningnan ang registry code. Kaagad, ang mga pagkukulang ay ipinahayag, dahil sa kung aling mga query sa database ay hindi nabuo nang mahusay. Kapag mababa ang load, hindi sila nagdulot ng anumang gulo, ngunit kapag tumaas ang load, ito ay pinagmumulan ng mga problema. Ang App Registry ay nagkaroon ng dalawang may problemang endpoint na hindi tumugon nang maayos sa pagtaas ng load: ang una ay nagbigay ng listahan ng lahat ng mga package sa repository, ang pangalawa ay nagbalik ng lahat ng mga blobs para sa package.
Pag-aalis ng mga sanhi
Sa susunod na linggo, ginugol namin ang pag-optimize ng code ng App Registry mismo at ang kapaligiran nito. Ang malinaw na hindi epektibong mga query sa SQL ay muling ginawa at inalis ang mga hindi kinakailangang command call tar (ito ay pinapatakbo sa tuwing kukunin ang mga blobs), idinagdag ang pag-cache hangga't maaari. Pagkatapos ay nagsagawa kami ng malawak na pagsubok sa pagganap at inihambing ang bilis ng App Registry bago at pagkatapos ng mga pagbabago.
Ang mga kahilingan sa API na dating tumagal ng hanggang kalahating minuto ay nakumpleto na ngayon sa mga millisecond. Sa susunod na linggo, inilagay namin ang mga pagbabago sa produksyon, at mula noon ang quay.io ay gumagana nang matatag. Sa panahong ito, nagkaroon ng ilang matalim na pagtaas sa trapiko sa endpoint ng App Registry, ngunit napigilan ng mga pagpapahusay na ginawa ang mga pagkawala ng database.
Ano ang natutunan natin?
Malinaw na sinusubukan ng anumang serbisyo na maiwasan ang downtime. Sa aming kaso, naniniwala kami na ang mga kamakailang pagkawala ay nakatulong na gawing mas mahusay ang quay.io. Natutunan namin ang ilang mahahalagang aral na nais naming ibahagi:
- Ang data tungkol sa kung sino ang gumagamit ng iyong serbisyo at kung paano ay hindi kailanman kalabisan. Dahil "nagtrabaho lang" ang Quay, hindi na namin kinailangan pang gumastos ng oras sa pag-optimize ng trapiko at pamamahala ng load. Ang lahat ng ito ay lumikha ng isang maling pakiramdam ng seguridad na maaaring sukatin ng serbisyo nang walang katiyakan.
- Kapag bumaba ang serbisyo, ang pagbabalik at pagpapatakbo nito ay isang pangunahing priyoridad.. Dahil ang Quay ay patuloy na nagdusa mula sa isang naka-lock na database noong unang pagkawala, ang aming mga karaniwang pamamaraan ay walang nilalayong epekto at hindi namin naibalik ang serbisyo gamit ang mga ito. Ito ay humantong sa isang sitwasyon kung saan kailangang gumugol ng oras sa pagsusuri at pagkolekta ng data sa pag-asang mahanap ang ugat - sa halip na ituon ang lahat ng pagsisikap sa pagpapanumbalik ng functionality.
- Suriin ang epekto ng bawat feature ng serbisyo. Bihirang gumamit ang mga kliyente ng App Registry, kaya hindi ito priority para sa aming team. Kapag halos hindi na ginagamit ang ilang feature ng produkto, bihirang lumabas ang kanilang mga bug, at huminto ang mga developer sa pagsubaybay sa code. Madaling mabiktima ng maling kuru-kuro na ito ang dapat na paraanβhanggang sa biglang nahanap ng function na iyon ang sarili sa gitna ng isang malaking insidente.
Ano ang susunod?
Ang gawain upang matiyak ang katatagan ng serbisyo ay hindi tumitigil at patuloy naming pinapabuti ito. Habang patuloy na lumalaki ang dami ng trapiko sa quay.io, kinikilala namin na mayroon kaming responsibilidad na gawin ang lahat ng aming makakaya upang matupad ang tiwala ng aming mga customer. Samakatuwid, kasalukuyang ginagawa namin ang mga sumusunod na gawain:
- I-deploy ang read-only na mga replika ng database upang matulungan ang serbisyo na pangasiwaan ang naaangkop na trapiko sa kaganapan ng mga problema sa pangunahing halimbawa ng RDS.
- Pag-update ng isang halimbawa ng RDS. Ang kasalukuyang bersyon mismo ay hindi ang problema. Sa halip, gusto lang naming alisin ang maling tugaygayan (na sinundan namin sa panahon ng kabiguan); Ang pagpapanatiling napapanahon ng software ay mag-aalis ng isa pang kadahilanan kung sakaling magkaroon ng outage sa hinaharap.
- Karagdagang pag-cache sa buong cluster. Patuloy kaming naghahanap ng mga lugar kung saan ang pag-cache ay maaaring mabawasan ang pagkarga sa database.
- Pagdaragdag ng web application firewall (WAF) para makita kung sino ang kumokonekta sa quay.io at bakit.
- Simula sa susunod na release, aabandonahin ng mga cluster ng Red Hat OpenShift ang App Registry pabor sa Mga Operator Catalog batay sa mga larawan ng container na available sa quay.io.
- Ang isang pangmatagalang kapalit para sa App Registry ay maaaring suporta para sa mga detalye ng artifact ng Open Container Initiative (OCI). Kasalukuyan itong ipinapatupad bilang native Quay functionality at magiging available sa mga user kapag na-finalize na ang mismong detalye.
Ang lahat ng nasa itaas ay bahagi ng patuloy na pamumuhunan ng Red Hat sa quay.io habang lumilipat tayo mula sa isang maliit na "startup-style" na koponan patungo sa isang mature na platform na hinimok ng SRE. Alam namin na marami sa aming mga customer ang umaasa sa quay.io sa kanilang pang-araw-araw na trabaho (kabilang ang Red Hat!) at sinisikap naming maging malinaw hangga't maaari tungkol sa mga kamakailang pagkawala at patuloy na pagsisikap na mapabuti.
PS mula sa tagasalin
Basahin din sa aming blog:
- Β«";
- Β«";
- Β«'.
Pinagmulan: www.habr.com