Qeyd. tərcümə.: avqustun əvvəlində Red Hat, xidmət istifadəçilərinin əvvəlki aylarda qarşılaşdıqları əlçatanlıq problemlərinin həlli haqqında açıq danışdı. (şirkətin CoreOS alması ilə birlikdə aldığı konteyner şəkilləri üçün reyestrə əsaslanır). Bu xidmətə olan marağınızdan asılı olmayaraq, şirkətin SRE mühəndislərinin qəzanın səbəblərini diaqnoz etmək və aradan qaldırmaq üçün tutduqları yol ibrətamizdir.
Mayın 19-da, səhər tezdən (Şərq Gün işığı vaxtı, EDT) quay.io xidməti qəzaya uğradı. Qəza həm quay.io istehlakçılarına, həm də proqram təminatının yaradılması və yayılması üçün platforma kimi quay.io-dan istifadə edən Açıq Mənbə layihələrinə təsir etdi. Red Hat hər ikisinin etibarını yüksək qiymətləndirir.
SRE mühəndislərindən ibarət qrup dərhal işə qoşuldu və Quay xidmətini mümkün qədər tez sabitləşdirməyə çalışdı. Ancaq bunu edərkən, müştərilər yeni şəkilləri itələmək qabiliyyətini itirdilər və yalnız bəzən mövcud olanları çəkə bildilər. Naməlum səbəblərdən quay.io verilənlər bazası xidmətin tam gücünə qədər genişləndirildikdən sonra bloklandı.
«Nə dəyişdi?" - belə hallarda adətən verilən ilk sual budur. Biz qeyd etdik ki, məsələdən bir qədər əvvəl OpenShift Dedicated klaster (quay.io ilə işləyir) 4.3.19 versiyasına yenilənməyə başladı. Quay.io Red Hat OpenShift Dedicated (OSD) üzərində işlədiyi üçün müntəzəm yeniləmələr rutin idi və heç vaxt problem yaratmırdı. Bundan əlavə, əvvəlki altı ay ərzində biz Quay klasterlərini xidmətdə heç bir fasilə olmadan bir neçə dəfə təkmilləşdirmişik.
Biz xidməti bərpa etməyə çalışarkən digər mühəndislər proqramın əvvəlki versiyası ilə yeni OSD klasteri hazırlamağa başladılar ki, nəsə baş verərsə, hər şeyi onun üzərində yerləşdirə bilsinlər.
Kök Səbəb Təhlili
Uğursuzluğun əsas əlaməti MySQL instansiyasını effektiv şəkildə işlək vəziyyətə gətirən on minlərlə verilənlər bazası bağlantılarının uçqunu idi. Bu, problemin diaqnozunu çətinləşdirdi. SRE komandasına problemi qiymətləndirməkdə kömək etmək üçün müştərilərdən gələn bağlantıların maksimum sayına məhdudiyyət qoymuşuq. Biz verilənlər bazasına qeyri-adi trafik müşahidə etmədik: əslində sorğuların əksəriyyəti oxundu, yalnız bir neçəsi yazıldı.
Biz həmçinin verilənlər bazası trafikində bu uçquna səbəb ola biləcək nümunəni müəyyən etməyə çalışdıq. Lakin loglarda heç bir naxış tapa bilmədik. OSD 4.3.18 ilə yeni klasterin hazır olmasını gözləyərkən biz quay.io podlarını işə salmağa davam etdik. Hər dəfə klaster tam gücə çatanda verilənlər bazası donurdu. Bu o demək idi ki, bütün quay.io podlarına əlavə olaraq RDS instansiyasını yenidən işə salmaq lazım idi.
Axşama qədər biz xidməti yalnız oxumaq rejimində sabitləşdirdik və verilənlər bazasına yükü azaltmaq üçün mümkün qədər çox vacib olmayan funksiyaları (məsələn, ad sahəsinin zibilinin toplanması) söndürdük. Donmalar dayandı lakin səbəbi heç vaxt tapılmadı. Yeni OSD klasteri hazır idi və biz xidməti köçürdük, trafiki birləşdirdik və monitorinqi davam etdirdik.
Quay.io yeni OSD klasterində stabil işləyirdi, ona görə də verilənlər bazası qeydlərinə qayıtdıq, lakin tıxanmaları izah edəcək bir əlaqə tapa bilmədik. OpenShift mühəndisləri Red Hat OpenShift 4.3.19-da dəyişikliklərin Quay ilə bağlı problemlərə səbəb olub-olmadığını anlamaq üçün bizimlə işlədilər. Ancaq heç nə tapılmadı və Laboratoriya şəraitində problemi təkrarlamaq mümkün olmadı.
İkinci uğursuzluq
Mayın 28-də, günorta EDT-dən bir qədər əvvəl, quay.io eyni simptomla yenidən çökdü: verilənlər bazası bloklandı. Və yenə də bütün gücümüzü istintaqa sərf etdik. İlk növbədə xidməti bərpa etmək lazım idi. Lakin bu dəfə RDS-i yenidən yükləmək və quay.io podlarını yenidən işə salmaq heç nə etmədi: daha bir uçqun bazanı basıb. Bəs niyə?
Quay Python-da yazılmışdır və hər bir pod tək monolit konteyner kimi fəaliyyət göstərir. Konteynerin işləmə müddəti eyni vaxtda bir çox paralel tapşırıqları yerinə yetirir. Kitabxanadan istifadə edirik gevent altında gunicorn veb sorğularını emal etmək üçün. Quay-a sorğu daxil olduqda (öz API və ya Docker-in API vasitəsilə) ona gevent işçisi təyin olunur. Adətən bu işçi verilənlər bazası ilə əlaqə saxlamalıdır. Birinci uğursuzluqdan sonra biz aşkar etdik ki, gevent işçiləri standart parametrlərdən istifadə edərək verilənlər bazasına qoşulurlar.
Quay podlarının əhəmiyyətli sayını və saniyədə minlərlə daxil olan sorğuları nəzərə alsaq, çoxlu sayda verilənlər bazası əlaqələri nəzəri olaraq MySQL instansiyasını alt-üst edə bilər. Monitorinq sayəsində Quay-ın saniyədə orta hesabla 5 min sorğu emal etdiyi məlum olub. Verilənlər bazasına qoşulmaların sayı təxminən eyni idi. 5 min əlaqə RDS instansiyamızın imkanları daxilində idi (on minlərlə haqqında danışmaq olmaz). Nədənsə bağlantıların sayında gözlənilməz sıçrayışlar oldu, lakin daxil olan sorğularla heç bir əlaqə müşahidə etmədik.
Bu dəfə problemin mənbəyini tapmaq və aradan qaldırmaq qərarına gəldik və özümüzü yenidən yükləmə ilə məhdudlaşdırmırıq. Quay kod bazasına hər bir işçi üçün verilənlər bazasına qoşulma sayını məhdudlaşdırmaq üçün dəyişikliklər edildi gevent. Bu nömrə konfiqurasiyada parametrə çevrildi: yeni konteyner təsviri yaratmadan onu tez bir zamanda dəyişdirmək mümkün oldu. Nə qədər əlaqənin real şəkildə idarə oluna biləcəyini öyrənmək üçün biz bir quruluş mühitində bir neçə sınaq keçirdik və bunun yük testi ssenarilərinə necə təsir edəcəyini görmək üçün müxtəlif dəyərlər təyin etdik. Nəticədə məlum olub ki Quay qoşulma sayı 502 mini keçdikdə 10 səhv atmağa başlayır.
Biz dərhal bu yeni versiyanı istehsala yerləşdirdik və verilənlər bazası əlaqə cədvəlinə nəzarət etməyə başladıq. Əvvəllər baza təxminən 20 dəqiqədən sonra bağlanmışdı. Problemsiz 30 dəqiqədən sonra ümidimiz, bir saatdan sonra isə inamımız yarandı. Biz sayta trafiki bərpa etdik və postmortem analizə başladıq.
Bloklanmaya səbəb olan problemdən yan keçməyi bacararaq, onun əsl səbəblərini öyrənə bilməmişik. Bunun OpenShift 4.3.19-da heç bir dəyişikliklə əlaqəli olmadığı təsdiqləndi, çünki əvvəllər Quay ilə heç bir problem olmadan işləyən 4.3.18 versiyasında eyni şey baş verdi.
Çoxluqda gizlənən başqa bir şey aydın idi.
Ətraflı Tədqiqat
Quay.io heç bir problem olmadan altı il ərzində verilənlər bazasına qoşulmaq üçün standart parametrlərdən istifadə etdi. Nə dəyişdi? Bütün bu müddət ərzində quay.io-da trafikin durmadan artdığı aydındır. Bizim vəziyyətimizdə, bağlantıların uçqunları üçün tətik rolunu oynayan hansısa həddi çatmış kimi görünürdü. İkinci uğursuzluqdan sonra verilənlər bazası qeydlərini öyrənməyə davam etdik, lakin heç bir nümunə və ya aşkar əlaqələr tapmadıq.
Bu vaxt, SRE komandası Quay sorğusunun müşahidə oluna bilməsi və ümumi xidmət sağlamlığının təkmilləşdirilməsi üzərində işləyir. Yeni ölçülər və idarə panelləri yerləşdirilib, Quayın hansı hissələrinin müştərilər tərəfindən daha çox tələb olunduğunu göstərir.
Quay.io iyunun 9-na qədər yaxşı işləyirdi. Bu səhər (EDT) biz yenidən verilənlər bazası bağlantılarının sayında əhəmiyyətli artım gördük. Bu dəfə heç bir fasilə olmadı, çünki yeni parametr onların sayını məhdudlaşdırdı və MySQL ötürmə qabiliyyətini keçməyə imkan vermədi. Bununla belə, təxminən yarım saat ərzində bir çox istifadəçi quay.io-nun yavaş işləməsini qeyd etdi. Biz əlavə monitorinq alətlərindən istifadə edərək bütün mümkün məlumatları tez topladıq. Birdən bir nümunə ortaya çıxdı.
Bağlantıların artmasından bir qədər əvvəl Tətbiq Registri API-yə çoxlu sayda sorğu göndərildi. Tətbiq Qeydiyyatı quay.io-nun az tanınan xüsusiyyətidir. Bu sizə Helm diaqramları və zəngin metadata ilə konteynerlər kimi şeyləri saxlamağa imkan verir. Quay.io istifadəçilərinin əksəriyyəti bu funksiya ilə işləmir, lakin Red Hat OpenShift ondan aktiv şəkildə istifadə edir. OpenShift-in bir hissəsi kimi OperatorHub bütün operatorları Tətbiq Reyestrində saxlayır. Bu operatorlar OpenShift iş yükü ekosistemi və tərəfdaş mərkəzli əməliyyat modelinin əsasını təşkil edir (2-ci gün əməliyyatları).
Hər bir OpenShift 4 klaster quraşdırma üçün mövcud olan operatorların kataloqunu dərc etmək və artıq quraşdırılmışlara yeniləmələr təqdim etmək üçün daxili OperatorHub operatorlarından istifadə edir. OpenShift 4-ün artan populyarlığı ilə bütün dünyada onun üzərindəki klasterlərin sayı da artıb. Bu klasterlərin hər biri daxili OperatorHub-ı işə salmaq üçün operator məzmununu yükləyir, Quay.io daxilindəki Tətbiq Reyestrindən backend kimi istifadə edir. Problemin mənbəyini axtararkən, OpenShift-in getdikcə populyarlıq qazanması ilə yanaşı, nadir hallarda istifadə olunan quay.io funksiyalarından birinə yüklənmənin də artdığını qaçırdıq..
Biz Tətbiq Qeydiyyatı sorğusu trafikinin bir qədər təhlilini etdik və reyestr koduna nəzər saldıq. Dərhal nöqsanlar aşkar edildi, buna görə məlumat bazasına sorğular optimal şəkildə formalaşmadı. Yük az olanda heç bir problem yaratmırdılar, yük artdıqda isə problem mənbəyinə çevrilirdilər. Tətbiq Reyestrində artan yükə yaxşı cavab verməyən iki problemli son nöqtə olduğu ortaya çıxdı: birincisi depodakı bütün paketlərin siyahısını təqdim etdi, ikincisi paket üçün bütün blobları qaytardı.
Səbəblərin aradan qaldırılması
Növbəti həftə biz Tətbiq Reyestrinin özünün və onun mühitinin kodunu optimallaşdırmağa sərf etdik. Aydındır ki, səmərəsiz SQL sorğuları yenidən işlənmiş və lazımsız əmr çağırışları aradan qaldırılmışdır. tar (hər dəfə bloblar götürüldükdə işə salınırdı), mümkün olan yerlərdə keşləmə əlavə edildi. Daha sonra biz geniş performans testi keçirdik və dəyişikliklərdən əvvəl və sonra Tətbiq Reyestrinin sürətini müqayisə etdik.
Əvvəllər yarım dəqiqəyə qədər vaxt aparan API sorğuları indi millisaniyələrlə tamamlanır. Növbəti həftə biz istehsala dəyişiklikləri tətbiq etdik və o vaxtdan quay.io stabil işləyir. Bu müddət ərzində Tətbiq Reyestrinin son nöqtəsində trafikdə bir neçə kəskin sıçrayış oldu, lakin edilən təkmilləşdirmələr verilənlər bazası kəsilməsinin qarşısını aldı.
Biz nə öyrəndik?
Aydındır ki, istənilən xidmət fasilədən qaçmağa çalışır. Bizim vəziyyətimizdə inanırıq ki, son fasilələr quay.io-nun daha yaxşı olmasına kömək etdi. Paylaşmaq istədiyimiz bir neçə əsas dərsi öyrəndik:
- Xidmətinizdən kimin və necə istifadə etdiyinə dair məlumatlar heç vaxt artıq olmaz. Quay "sadəcə işlədiyi" üçün biz heç vaxt trafiki optimallaşdırmağa və yükü idarə etməyə vaxt sərf etməməli olduq. Bütün bunlar xidmətin qeyri-müəyyən müddətə genişlənə biləcəyi saxta təhlükəsizlik hissi yaratdı.
- Xidmət sönəndə, onun yenidən işə salınması əsas prioritetdir.. Quay ilk fasilə zamanı bağlanmış verilənlər bazasından əziyyət çəkməyə davam etdiyi üçün standart prosedurlarımız nəzərdə tutulan effekti vermədi və biz onlardan istifadə edərək xidməti bərpa edə bilmədik. Bu, elə bir vəziyyətə gətirib çıxardı ki, bütün səyləri funksionallığın bərpasına yönəltmək əvəzinə, əsas səbəbi tapmaq ümidi ilə məlumatları təhlil etmək və toplamaq üçün vaxt sərf etmək lazım idi.
- Hər bir xidmət xüsusiyyətinin təsirini qiymətləndirin. Müştərilər Tətbiq Reyestrindən nadir hallarda istifadə edirdilər, ona görə də bu, komandamız üçün prioritet deyildi. Bəzi məhsul xüsusiyyətləri çətinliklə istifadə edildikdə, onların səhvləri nadir hallarda görünür və tərtibatçılar kodun monitorinqini dayandırırlar. Bunun belə olması lazım olduğuna dair yanlış təsəvvürün qurbanı olmaq asandır - birdən-birə bu funksiya özünü böyük bir hadisənin mərkəzində tapana qədər.
Növbəti nədir?
Xidmətin dayanıqlığını təmin etmək üçün işlər heç vaxt dayanmır və biz onu daim təkmilləşdiririk. Quay.io-da trafikin həcmi artmağa davam etdikcə, müştərilərimizin etimadını doğrultmaq üçün əlimizdən gələni etməyə borclu olduğumuzu anlayırıq. Buna görə də biz hazırda aşağıdakı vəzifələr üzərində işləyirik:
- Əsas RDS nümunəsi ilə bağlı problemlər zamanı xidmətə müvafiq trafiki idarə etməkdə kömək etmək üçün yalnız oxunan verilənlər bazası replikalarını yerləşdirin.
- RDS nümunəsi yenilənir. Mövcud versiyanın özü problem deyil. Əksinə, biz sadəcə olaraq saxta izi (uğursuzluq zamanı izlədiyimiz) aradan qaldırmaq istəyirik; Proqram təminatının güncəl saxlanması gələcək fasilələr zamanı başqa amili aradan qaldıracaq.
- Bütün klaster üzrə əlavə keşləmə. Keşləmənin verilənlər bazasına yükü azalda biləcəyi sahələri axtarmağa davam edirik.
- Quay.io-ya kimin və niyə qoşulduğunu görmək üçün veb tətbiqi təhlükəsizlik divarı (WAF) əlavə edilir.
- Növbəti buraxılışdan başlayaraq Red Hat OpenShift klasterləri Tətbiq Reyestrindən imtina edərək quay.io-da mövcud konteyner şəkillərinə əsaslanan Operator Kataloqlarının xeyrinə olacaq.
- Tətbiq Reyestrinin uzunmüddətli əvəzi Açıq Konteyner Təşəbbüsü (OCI) artefakt spesifikasiyasına dəstək ola bilər. O, hazırda yerli Quay funksionallığı kimi həyata keçirilir və spesifikasiyanın özü tamamlandıqdan sonra istifadəçilər üçün əlçatan olacaq.
Yuxarıda göstərilənlərin hamısı Red Hat-ın quay.io-da davam edən sərmayəsinin bir hissəsidir, çünki biz kiçik “startup-stil” komandasından yetkin SRE-yə əsaslanan platformaya keçid edirik. Biz bilirik ki, bir çox müştərilərimiz gündəlik işlərində (o cümlədən Red Hat!) quay.io-dan istifadə edirlər və biz son fasilələr və təkmilləşdirmək üçün davam edən səylər barədə mümkün qədər şəffaf olmağa çalışırıq.
Tərcüməçidən PS
Bloqumuzda da oxuyun:
- «";
- «";
- «.
Mənbə: www.habr.com