🥇Quay.io mavjud emasligi haqida o'limdan keyin

Eslatma. tarjima.: avgust oyi boshida Red Hat o'z xizmati foydalanuvchilari oldingi oylarda duch kelgan mavjudlik muammolarini hal qilish haqida ochiq gapirdi. Quay.io (u kompaniya CoreOS sotib olish bilan birga olgan konteyner tasvirlari reestriga asoslangan). Ushbu xizmatga qiziqishingizdan qat'i nazar, kompaniyaning SRE muhandislari avariya sabablarini tashxislash va bartaraf etish uchun bosib o'tgan yo'l ibratli.

19-may kuni erta tongda (Sharqiy kunduz vaqti, EDT) quay.io xizmati ishlamay qoldi. Baxtsiz hodisa quay.io iste'molchilariga ham, dasturiy ta'minotni yaratish va tarqatish platformasi sifatida quay.io'dan foydalanadigan Open Source loyihalariga ham ta'sir ko'rsatdi. Red Hat ikkalasining ishonchini qadrlaydi.

SRE muhandislari jamoasi darhol ishga kirishdi va Quay xizmatini imkon qadar tezroq barqarorlashtirishga harakat qilishdi. Biroq, ular buni amalga oshirayotganda, mijozlar yangi tasvirlarni surish qobiliyatini yo'qotdilar va faqat vaqti-vaqti bilan mavjudlarini tortib olishlari mumkin edi. Noma'lum sabablarga ko'ra quay.io ma'lumotlar bazasi xizmatni to'liq quvvatga o'tkazgandan so'ng bloklandi.

«Nima o'zgargan?" - bu odatda bunday hollarda so'raladigan birinchi savol. Biz eʼtirof etdikki, muammodan biroz oldin OpenShift Dedicated klasteri (quay.io bilan ishlaydi) 4.3.19 versiyasiga yangilana boshlagan. Quay.io Red Hat OpenShift Dedicated (OSD) da ishlaganligi sababli, muntazam yangilanishlar muntazam edi va hech qachon muammo tug'dirmasdi. Bundan tashqari, so'nggi olti oy ichida biz Quay klasterlarini xizmat ko'rsatishda uzilishlarsiz bir necha bor yangiladik.

Xizmatni qayta tiklashga urinayotganimizda, boshqa muhandislar, agar biror narsa yuz bergan bo'lsa, unda hamma narsani o'rnatishi uchun dasturiy ta'minotning oldingi versiyasi bilan yangi OSD klasterini tayyorlashni boshladilar.

Ildiz sabablarini tahlil qilish

Muvaffaqiyatsizlikning asosiy belgisi o'n minglab ma'lumotlar bazasi ulanishlarining ko'chkisi edi, bu MySQL nusxasini samarali ravishda ishlamay qoldirdi. Bu muammoni tashxislashni qiyinlashtirdi. Biz SRE jamoasiga muammoni baholashda yordam berish uchun mijozlardan maksimal ulanishlar soniga cheklov o‘rnatdik. Maʼlumotlar bazasiga gʻayrioddiy trafikni sezmadik: aslida soʻrovlarning aksariyati oʻqildi, faqat bir nechtasi yozildi.

Shuningdek, biz ushbu ko'chkiga olib kelishi mumkin bo'lgan ma'lumotlar bazasi trafigidagi naqshni aniqlashga harakat qildik. Biroq, jurnallarda hech qanday naqsh topa olmadik. OSD 4.3.18 bilan yangi klaster tayyor bo'lishini kutar ekanmiz, biz quay.io podslarini ishga tushirishga harakat qildik. Har safar klaster to'liq quvvatga erishganida, ma'lumotlar bazasi muzlatib qo'yadi. Bu barcha quay.io podslariga qo'shimcha ravishda RDS nusxasini qayta ishga tushirish zarurligini anglatardi.

Kechqurun biz xizmatni faqat o'qish rejimida barqarorlashtirdik va ma'lumotlar bazasiga yukni kamaytirish uchun iloji boricha ko'proq muhim bo'lmagan funktsiyalarni (masalan, nomlar maydoni axlat yig'ish) o'chirib qo'ydik. Muzlashlar to'xtadi lekin sabab topilmadi. Yangi OSD klasteri tayyor edi va biz xizmatni ko‘chirdik, trafikni uladik va monitoringni davom ettirdik.

Quay.io yangi OSD klasterida barqaror ishladi, shuning uchun biz ma'lumotlar bazasi jurnallariga qaytdik, ammo blokirovkalarni tushuntirib beradigan korrelyatsiyani topa olmadik. OpenShift muhandislari Red Hat OpenShift 4.3.19-dagi o'zgarishlar Quay bilan bog'liq muammolarga olib kelishi mumkinligini tushunish uchun biz bilan ishladilar. Biroq, hech narsa topilmadi va Laboratoriya sharoitida muammoni takrorlash mumkin emas edi.

Ikkinchi muvaffaqiyatsizlik

28-may kuni, EDT kuni tushdan biroz oldin, quay.io xuddi shu alomat bilan yana qulab tushdi: ma'lumotlar bazasi bloklandi. Va yana bor kuchimizni tergovga sarfladik. Avvalo, xizmatni tiklash kerak edi. Biroq bu safar RDS-ni qayta ishga tushirish va quay.io podslarini qayta ishga tushirish hech narsa qilmadi: aloqalarning yana bir ko'chkisi bazani bosib oldi. Lekin nima uchun?

Quay Python-da yozilgan va har bir pod bitta monolit konteyner sifatida ishlaydi. Konteynerning ishlash vaqti bir vaqtning o'zida ko'plab parallel vazifalarni bajaradi. Biz kutubxonadan foydalanamiz gevent ostida gunicorn veb-so'rovlarni qayta ishlash uchun. Quayga so'rov kelganda (o'z APImiz orqali yoki Docker's API orqali), unga gevent ishchisi tayinlanadi. Odatda bu ishchi ma'lumotlar bazasiga murojaat qilishi kerak. Birinchi muvaffaqiyatsizlikdan so'ng, biz gevent ishchilari standart sozlamalardan foydalangan holda ma'lumotlar bazasiga ulanishini aniqladik.

Quay podlarining sezilarli soni va soniyada minglab kiruvchi so'rovlarni hisobga olsak, ko'p sonli ma'lumotlar bazasi ulanishlari MySQL misolini nazariy jihatdan to'ldirishi mumkin. Monitoring tufayli Quay sekundiga oʻrtacha 5 ming soʻrovni qayta ishlayotgani maʼlum boʻldi. Ma'lumotlar bazasiga ulanishlar soni taxminan bir xil edi. 5 ming ulanish bizning RDS misolimiz imkoniyatlariga to'g'ri keldi (buni o'n minglab aytish mumkin emas). Ba'zi sabablarga ko'ra ulanishlar sonida kutilmagan o'sish kuzatildi, ammo biz kiruvchi so'rovlar bilan hech qanday bog'liqlikni sezmadik.

Bu safar biz muammoning manbasini topishga va yo'q qilishga qaror qildik va o'zimizni qayta ishga tushirish bilan cheklamadik. Quay kod bazasiga har bir ishchi uchun ma'lumotlar bazasiga ulanishlar sonini cheklash uchun o'zgarishlar kiritildi gevent. Bu raqam konfiguratsiyadagi parametrga aylandi: uni yangi konteyner tasvirini yaratmasdan tezda o'zgartirish mumkin bo'ldi. Qanchalik ko'p ulanishlarni real tarzda boshqarish mumkinligini bilish uchun biz bosqichma-bosqich muhitda bir nechta sinovlarni o'tkazdik va bu yukni tekshirish stsenariylariga qanday ta'sir qilishini ko'rish uchun turli qiymatlarni o'rnatdik. Natijada, bu aniqlandi Quay ulanishlar soni 502 mingdan oshib ketganda 10 ta xatoni boshlaydi.

Biz ushbu yangi versiyani darhol ishlab chiqarishga joylashtirdik va ma'lumotlar bazasiga ulanish jadvalini kuzatishni boshladik. Ilgari, baza taxminan 20 daqiqadan so'ng qulflangan edi. 30 muammosiz daqiqadan so'ng bizda umid paydo bo'ldi va bir soatdan keyin bizda ishonch paydo bo'ldi. Biz saytga trafikni tikladik va o'limdan keyingi tahlilni boshladik.

Bloklashga olib keladigan muammoni chetlab o'tishga muvaffaq bo'lgach, biz uning asl sabablarini topa olmadik. Bu OpenShift 4.3.19-dagi hech qanday o'zgarishlarga aloqador emasligi tasdiqlandi, chunki xuddi shu narsa Quay bilan ilgari hech qanday muammosiz ishlagan 4.3.18 versiyasida sodir bo'lgan.

Klasterda yana bir narsa yashiringanligi aniq.

Batafsil o'rganish

Quay.io hech qanday muammosiz olti yil davomida ma'lumotlar bazasiga ulanish uchun standart sozlamalardan foydalangan. Nima o'zgardi? Shu vaqt davomida quay.io-da trafik barqaror ravishda o'sib borayotgani aniq. Bizning holatda, u qandaydir chegara qiymatiga erishilganga o'xshardi, bu ulanishlar ko'chkisi uchun tetik bo'lib xizmat qildi. Biz ikkinchi nosozlikdan keyin ma'lumotlar bazasi jurnallarini o'rganishni davom ettirdik, lekin hech qanday naqsh yoki aniq munosabatlarni topmadik.

Ayni paytda, SRE jamoasi Quay so'rovini kuzatish va umumiy xizmat ko'rsatish holatini yaxshilash ustida ishlamoqda. Yangi ko'rsatkichlar va asboblar paneli o'rnatildi, Quayning qaysi qismlari mijozlar tomonidan ko'proq talab qilinayotganini ko'rsatadi.

Quay.io 9 iyungacha yaxshi ishladi. Bugun ertalab (EDT) biz yana ma'lumotlar bazasi ulanishlari sonining sezilarli o'sishini ko'rdik. Bu safar uzilishlar bo'lmadi, chunki yangi parametr ularning sonini cheklab qo'ydi va MySQL o'tkazuvchanligini oshirishga ruxsat bermadi. Biroq, taxminan yarim soat davomida ko'plab foydalanuvchilar quay.io ning sekin ishlashini qayd etdilar. Qo'shilgan monitoring vositalaridan foydalanib, biz tezda barcha mumkin bo'lgan ma'lumotlarni to'pladik. To'satdan naqsh paydo bo'ldi.

Ulanishlar kuchayishidan oldin, App Registry API-ga juda ko'p so'rovlar yuborildi. Ilovalar registri quay.io ning kam ma'lum xususiyatidir. Bu sizga Helm diagrammalari va boy metama'lumotlarga ega konteynerlar kabi narsalarni saqlash imkonini beradi. Quay.io foydalanuvchilarining aksariyati bu xususiyat bilan ishlamaydi, ammo Red Hat OpenShift undan faol foydalanadi. OpenShift-ning bir qismi sifatida OperatorHub barcha operatorlarni ilovalar registrida saqlaydi. Ushbu operatorlar OpenShift ish yuki ekotizimining asosini tashkil qiladi va hamkorga asoslangan operatsion modeli (2-kun operatsiyalari).

Har bir OpenShift 4 klasteri o'rnatish uchun mavjud bo'lgan operatorlar katalogini nashr etish va allaqachon o'rnatilganlarga yangilanishlarni taqdim etish uchun o'rnatilgan OperatorHub operatorlaridan foydalanadi. OpenShift 4 ning mashhurligi ortib borishi bilan butun dunyo bo'ylab undagi klasterlar soni ham ortdi. Ushbu klasterlarning har biri o'rnatilgan OperatorHub-ni ishga tushirish uchun operator tarkibini quay.io ichidagi ilovalar registrini backend sifatida yuklab oladi. Muammoning manbasini izlaganimizda, OpenShift asta-sekin ommalashib borishi bilan kamdan-kam ishlatiladigan quay.io funksiyalaridan biriga yuklanish ham ortib borayotganini o'tkazib yubordik..

Biz ilovalar registriga so'rovlar trafigini tahlil qildik va ro'yxatga olish kitobi kodini ko'rib chiqdik. Darhol ma'lumotlar bazasiga so'rovlar maqbul shakllantirilmagan kamchiliklar aniqlandi. Yuk kam bo'lganda, ular hech qanday muammo tug'dirmagan, lekin yuk ko'tarilgach, ular muammolar manbai bo'lib qolgan. Ilovalar registrida yukning oshishiga yaxshi javob bermagan ikkita muammoli so‘nggi nuqta borligi ma’lum bo‘ldi: birinchisi ombordagi barcha paketlar ro‘yxatini taqdim etdi, ikkinchisi paket uchun barcha bloblarni qaytardi.

Sabablarni bartaraf etish

Keyingi haftada biz ilovalar registrining o'zi va uning muhiti kodini optimallashtirishga sarfladik. Aniq samarasiz SQL so'rovlari qayta ishlandi va keraksiz buyruq chaqiruvlari olib tashlandi. tar (har safar bloblar olinganda ishga tushirildi), iloji boricha keshlash qo'shildi. Keyin biz keng qamrovli ishlash testlarini o'tkazdik va o'zgarishlardan oldin va keyin ilovalar registrining tezligini solishtirdik.

Ilgari yarim daqiqagacha davom etgan API so‘rovlari endi millisekundlarda bajariladi. Keyingi hafta biz ishlab chiqarishga o'zgarishlar kiritdik va o'shandan beri quay.io barqaror ishlamoqda. Shu vaqt ichida ilovalar registrining so‘nggi nuqtasida trafikda bir necha keskin o‘sish kuzatildi, biroq amalga oshirilgan yaxshilanishlar ma’lumotlar bazasidagi uzilishlarning oldini oldi.

Biz nimani o'rgandik?

Har qanday xizmat uzilishlardan qochishga harakat qilishi aniq. Bizning holatlarimizda, so'nggi uzilishlar quay.io-ni yaxshilashga yordam berganiga ishonamiz. Biz baham ko'rmoqchi bo'lgan bir nechta asosiy saboqlarni oldik:

Sizning xizmatingizdan kim va qanday foydalanishi haqidagi ma'lumotlar hech qachon ortiqcha bo'lmaydi. Quay "shunchaki ishlagan"ligi sababli biz hech qachon trafikni optimallashtirish va yukni boshqarish uchun vaqt sarflashimiz shart emas edi. Bularning barchasi xizmat cheksiz ravishda kengayishi mumkin bo'lgan noto'g'ri xavfsizlik hissini yaratdi.
Xizmat yopilganda, uni qayta tiklash va ishga tushirish eng muhim vazifadir.. Quay birinchi uzilish paytida ma'lumotlar bazasi bloklanganidan azob chekishda davom etganligi sababli, bizning standart protseduralarimiz kutilgan samarani bermadi va biz ulardan foydalangan holda xizmatni tiklay olmadik. Bu shunday vaziyatga olib keldiki, barcha sa'y-harakatlarni funksionallikni tiklashga qaratish o'rniga, asosiy sababni topish umidida ma'lumotlarni tahlil qilish va yig'ish uchun vaqt sarflash kerak edi.
Har bir xizmat xususiyatining ta'sirini baholang. Mijozlar ilovalar registrini kamdan-kam ishlatishgan, shuning uchun bu bizning jamoamiz uchun ustuvor emas edi. Ba'zi mahsulot xususiyatlari deyarli ishlatilmaganda, ularning xatolari kamdan-kam hollarda paydo bo'ladi va ishlab chiquvchilar kodni kuzatishni to'xtatadilar. Bu shunday bo'lishi kerak degan noto'g'ri tushunchaning qurboni bo'lish oson - to'satdan bu funktsiya katta voqea markazida bo'lmaguncha.

Keyin nima?

Xizmat barqarorligini ta'minlash borasidagi ishlar hech qachon to'xtamaydi va biz uni doimiy ravishda takomillashtirib boramiz. Quay.io'da trafik hajmi o'sishda davom etar ekan, biz mijozlarimiz ishonchini oqlash uchun qo'limizdan kelgan barcha ishni qilishga mas'uliyatli ekanligimizni tushunamiz. Shuning uchun biz hozirda quyidagi vazifalar ustida ishlamoqdamiz:

Asosiy RDS nusxasi bilan bog'liq muammolar yuzaga kelganda xizmatga tegishli trafikni boshqarishga yordam berish uchun faqat o'qish uchun ma'lumotlar bazasi replikalarini o'rnating.
RDS namunasi yangilanmoqda. Hozirgi versiyaning o'zi muammo emas. Aksincha, biz yolg'on izni olib tashlashni xohlaymiz (muvaffaqiyatsizlik paytida biz unga ergashdik); Dasturiy ta'minotni yangilab turish kelajakda uzilishlar sodir bo'lganda yana bir omilni yo'q qiladi.
Butun klaster bo'ylab qo'shimcha keshlash. Biz keshlash ma'lumotlar bazasidagi yukni kamaytirishi mumkin bo'lgan joylarni izlashda davom etamiz.
Quay.io-ga kim va nima uchun ulanayotganini ko'rish uchun veb-ilovaning xavfsizlik devori (WAF) qo'shiladi.
Keyingi nashrdan boshlab, Red Hat OpenShift klasterlari quay.io saytida mavjud bo'lgan konteyner tasvirlari asosida Operator Kataloglari foydasiga ilovalar registrini tark etadi.
Ilovalar registrini uzoq muddatli almashtirish Open Container Initiative (OCI) artefakt spetsifikatsiyalarini qo'llab-quvvatlashi mumkin. Hozirda u mahalliy Quay funksiyasi sifatida tatbiq etilmoqda va spetsifikatsiyaning o‘zi yakunlangach, foydalanuvchilar uchun mavjud bo‘ladi.

Yuqorida aytilganlarning barchasi Red Hat kompaniyasining quay.io-ga davom etayotgan sarmoyasining bir qismidir, chunki biz kichik “start-up uslubidagi” jamoadan etuk SRE-ga asoslangan platformaga o'tamiz. Biz bilamizki, ko‘plab mijozlarimiz kundalik ishlarida quay.io ga tayanadilar (jumladan, Red Hat!) va biz yaqinda sodir bo‘lgan uzilishlar va yaxshilash bo‘yicha davom etayotgan sa’y-harakatlar haqida iloji boricha shaffof bo‘lishga harakat qilamiz.