Cathetan. nerjemahake.: ing awal Agustus, Red Hat kanthi umum ngomong babagan ngrampungake masalah aksesibilitas sing dialami pangguna layanan ing wulan sadurunge (iku adhedhasar registri kanggo gambar wadhah, sing ditampa perusahaan bebarengan karo tuku CoreOS). Preduli saka kapentingan ing layanan iki minangka kuwi, path sing engineers SRE perusahaan njupuk kanggo diagnosa lan ngilangi nimbulaké saka kacilakan punika instruktif.
Tanggal 19 Mei, esuk (Eastern Daylight Time, EDT), layanan quay.io ambruk. Kacilakan kasebut mengaruhi konsumen quay.io lan proyek Open Source nggunakake quay.io minangka platform kanggo mbangun lan nyebarake piranti lunak. Red Hat ngurmati kapercayan saka loro kasebut.
Tim insinyur SRE langsung melu lan nyoba nyetabilake layanan Quay sanalika bisa. Nanging, nalika lagi nindakake iki, klien ilang kemampuan kanggo push gambar anyar, lan mung sok-sok padha bisa narik sing wis ana. Kanggo sawetara alasan sing ora dingerteni, database quay.io diblokir sawise skala layanan kanthi kapasitas penuh.
«Apa wis diganti?"- iki pitakonan pisanan sing biasane takon ing kasus kaya mengkono. Kita weruh yen sakcepete sadurunge masalah kasebut, kluster OpenShift Dedicated (sing nganggo quay.io) wiwit nganyari menyang versi 4.3.19. Wiwit quay.io mlaku ing Red Hat OpenShift Dedicated (OSD), nganyari biasa dadi rutin lan ora nate nyebabake masalah. Kajaba iku, sajrone nem wulan kepungkur, kita wis nganyarke kluster Quay kaping pirang-pirang tanpa gangguan ing layanan.
Nalika kita nyoba kanggo mulihake layanan, engineers liyane wiwit nyiapake kluster OSD anyar karo versi sadurungé saka piranti lunak, supaya yen soko kedaden, padha bisa masang kabeh ing.
Analisis Root Panyebab
Gejala utama kegagalan kasebut yaiku longsoran puluhan ewu sambungan database, sing ndadekake conto MySQL ora bisa digunakake kanthi efektif. Iki nggawe angel diagnosa masalah kasebut. Kita wis nyetel watesan ing jumlah maksimum sambungan saka klien kanggo bantuan tim SRE ngira-ngira masalah. Kita ora weruh lalu lintas sing ora biasa menyang database: nyatane, akeh panjaluk diwaca, lan mung sawetara sing nulis.
Kita uga nyoba ngenali pola ing lalu lintas database sing bisa nyebabake longsor iki. Nanging, kita ora bisa nemokake pola ing log. Nalika nunggu kluster anyar karo OSD 4.3.18 siap, kita terus nyoba kanggo miwiti pods quay.io. Saben kluster tekan kapasitas penuh, database bakal beku. Iki tegese kudu miwiti maneh conto RDS saliyane kabeh pods quay.io.
Ing wayah sore, kita nyetabilake layanan ing mode mung diwaca lan mateni akeh fungsi sing ora penting (contone, koleksi sampah namespace) kanggo nyuda beban ing database. Beku wis mandheg nanging alesane ora ketemu. Kluster OSD anyar wis siyap, lan kita migrasi layanan kasebut, lalu lintas sing disambungake lan terus ngawasi.
Quay.io makarya stably ing kluster OSD anyar, supaya kita bali menyang log database, nanging ora bisa nemokake korélasi sing bakal nerangake blockages. Insinyur OpenShift makarya karo kita kanggo mangerteni apa owah-owahan ing Red Hat OpenShift 4.3.19 bisa nimbulaké masalah karo Quay. Nanging, boten ketemu, lan Ora bisa ngasilake masalah ing kahanan laboratorium.
Gagal kapindho
Tanggal 28 Mei, sakcepete sadurunge awan EDT, quay.io nabrak maneh kanthi gejala sing padha: database diblokir. Lan maneh kita mbuwang kabeh upaya kanggo investigasi. Kaping pisanan, perlu kanggo mulihake layanan kasebut. Nanging wektu iki rebooting RDS lan miwiti maneh quay.io pods ora nindakake apa-apa: longsoran liyane sambungan wis kepunjulen basa. Nanging kenapa?
Quay ditulis ing Python lan saben pod makaryakke minangka wadhah monolithic siji. Runtime wadhah mbukak akeh tugas paralel bebarengan. Kita nggunakake perpustakaan gevent ing gunicorn kanggo ngolah panjalukan web. Nalika panjalukan teka menyang Quay (liwat API kita dhewe, utawa liwat Docker kang API), iku diutus buruh gevent. Biasane buruh iki kudu ngubungi database. Sawise gagal pisanan, kita nemokake manawa buruh gevent nyambung menyang database nggunakake setelan gawan.
Amarga jumlah polong Quay sing signifikan lan ewonan panjaluk sing mlebu saben detik, akeh sambungan database kanthi teori bisa ngatasi conto MySQL. Thanks kanggo ngawasi, dikenal manawa Quay ngolah rata-rata 5 ewu panjaluk saben detik. Jumlah sambungan menyang database kira-kira padha. 5 ewu sambungan uga ana ing kemampuan conto RDS kita (sing ora bisa dikandhakake babagan puluhan ewu). Kanggo sawetara alesan ana spike sing ora dikarepke ing jumlah sambungan, Nanging, kita ora sok dong mirsani korélasi karo panjalukan mlebu.
Wektu iki kita ditemtokake kanggo nemokake lan ngilangi sumber masalah, lan ora mbatesi urip maneh. Kanggo basis kode Quay owah-owahan digawe kanggo matesi jumlah sambungan kanggo database kanggo saben buruh gevent. Nomer iki dadi parameter ing konfigurasi: bisa diganti kanthi cepet tanpa nggawe gambar wadhah anyar. Kanggo ngerteni pirang-pirang sambungan sing bisa ditangani kanthi realistis, kita nindakake sawetara tes ing lingkungan pementasan, nyetel nilai sing beda-beda kanggo ndeleng kepiye pengaruh skenario pengujian beban. Akibaté, ditemokake yen Quay wiwit mbuwang 502 kasalahan nalika jumlah sambungan ngluwihi 10 ewu.
Kita langsung masang versi anyar iki kanggo produksi lan wiwit ngawasi jadwal sambungan database. Ing jaman kepungkur, pangkalan kasebut dikunci sawise udakara 20 menit. Sawise 30 menit tanpa masalah, kita duwe pangarep-arep, lan sejam sabanjure kita duwe kapercayan. Kita mulihake lalu lintas menyang situs kasebut lan miwiti analisis postmortem.
Sawise bisa ngatasi masalah sing nyebabake pamblokiran, kita durung nemokake alasan nyata. Iki dikonfirmasi manawa ora ana hubungane karo owah-owahan ing OpenShift 4.3.19, amarga kedadeyan sing padha ing versi 4.3.18, sing sadurunge kerja karo Quay tanpa masalah.
Cetha ana barang liya sing ngumpet ing kluster.
Sinau rinci
Quay.io nggunakake setelan gawan kanggo nyambung menyang database sajrone nem taun tanpa masalah. Apa sing diganti? Cetha yen kabeh wektu lalu lintas ing quay.io saya tambah ajeg. Ing kasus kita, katon kaya sawetara nilai ambang wis tekan, sing dadi pemicu kanggo longsor sambungan. Kita terus sinau log database sawise kegagalan kapindho, nanging ora nemokake pola utawa hubungan sing jelas.
Ing sawetoro wektu, tim SRE wis nggarap perbaikan kanggo observasi panjalukan Quay lan kesehatan layanan sakabèhé. Metrik lan dashboard anyar wis disebarake, nuduhake bagean Quay sing paling dikarepake saka pelanggan.
Quay.io makarya kanthi apik nganti 9 Juni. Esuk iki (EDT) kita maneh weruh Tambah pinunjul ing nomer sambungan database. Wektu iki ora ana downtime, amarga parameter anyar mbatesi jumlahe lan ora ngidini ngluwihi throughput MySQL. Nanging, kira-kira setengah jam, akeh pangguna nyathet kinerja alon saka quay.io. Kita kanthi cepet ngumpulake kabeh data sing bisa digunakake kanthi nggunakake alat pemantauan sing ditambahake. Dumadakan ana pola.
Sadurunge mundhak sambungan, akeh panjaluk digawe menyang App Registry API. App Registry minangka fitur sing ora dingerteni saka quay.io. Ngidini sampeyan nyimpen barang kaya denah Helm lan wadhah kanthi metadata sing sugih. Umume pangguna quay.io ora bisa nggunakake fitur iki, nanging Red Hat OpenShift aktif nggunakake. OperatorHub minangka bagéan saka OpenShift nyimpen kabeh operator ing App Registry. Operator iki dadi basis kanggo ekosistem beban kerja OpenShift lan model operasi partner-centric (operasi Dina 2).
Saben kluster OpenShift 4 nggunakake operator saka OperatorHub sing dibangun kanggo nerbitake katalog operator sing kasedhiya kanggo instalasi lan menehi nganyari kanggo sing wis diinstal. Kanthi popularitas OpenShift 4 sing saya tambah akeh, jumlah klompok ing saindenging jagad uga saya tambah. Saben kluster kasebut ndownload konten operator kanggo mbukak OperatorHub sing dibangun, nggunakake Registry Aplikasi ing quay.io minangka backend. Ing panelusuran kita kanggo sumber masalah, kita ora kejawab kasunyatan sing OpenShift mboko sithik tuwuh ing popularitas, mbukak ing salah siji fungsi quay.io arang digunakake uga tambah..
Kita nindakake sawetara analisis lalu lintas panjalukan App Registry lan mriksa kode pendaptaran. Sanalika, kekurangan dicethakaké, amarga pitakon menyang basis data ora dibentuk kanthi optimal. Nalika beban kurang, ora nyebabake alangan, nanging nalika beban saya tambah, mula dadi masalah. Registry App ternyata duwe rong titik pungkasan masalah sing ora nanggapi kanthi apik kanggo nambah beban: sing pertama nyedhiyakake dhaptar kabeh paket ing repositori, sing nomer loro ngasilake kabeh blobs kanggo paket kasebut.
Ngilangi sabab
Sajrone minggu sabanjure, kita nggunakake ngoptimalake kode Registry App dhewe lan lingkungane. Cetha pitakon SQL sing ora efektif digarap maneh lan panggilan perintah sing ora perlu diilangi tar (iki mbukak saben wektu blobs dijupuk), caching ditambahake ing ngendi wae. Kita banjur nindakake testing kinerja ekstensif lan mbandhingaké kacepetan App Registry sadurunge lan sawise owah-owahan.
Panjaluk API sing sadurunge njupuk nganti setengah menit saiki wis rampung ing milidetik. Minggu ngarep kita nyebarake owah-owahan ing produksi, lan wiwit iku quay.io wis bisa digunakake kanthi stabil. Sajrone wektu kasebut, ana sawetara lonjakan lalu lintas ing titik pungkasan App Registry, nanging dandan kasebut nyegah gangguan database.
Apa sing wis kita sinau?
Cetha manawa layanan apa wae nyoba ngindhari downtime. Ing kasus kita, kita yakin manawa pemadaman anyar wis mbantu nggawe quay.io luwih apik. Kita wis sinau sawetara piwulang penting sing arep kita bareng-bareng:
- Data babagan sapa sing nggunakake layanan sampeyan lan kepiye carane ora perlu. Amarga Quay "mung kerja," kita ora nate ngentekake wektu kanggo ngoptimalake lalu lintas lan ngatur muatan. Kabeh iki nggawe rasa aman palsu sing layanan bisa ukuran tanpa wates.
- Nalika layanan mudhun, njupuk maneh lan mlaku iku prioritas ndhuwur.. Amarga Quay terus nandhang sangsara saka database sing dikunci nalika mati pisanan, prosedur standar kita ora duwe efek sing dikarepake lan kita ora bisa mulihake layanan kasebut. Iki nyebabake kahanan sing kudu ditindakake wektu kanggo nganalisa lan ngumpulake data kanthi pangarep-arep nemokake sababe - tinimbang fokus kabeh upaya kanggo mulihake fungsi.
- Evaluasi pengaruh saben fitur layanan. Klien arang banget nggunakake Registry Aplikasi, mula ora dadi prioritas kanggo tim kita. Nalika sawetara fitur produk meh ora digunakake, kewan omo sing arang katon, lan pangembang mandheg ngawasi kode kasebut. Iku gampang kanggo tiba memangsan kanggo misconception sing iki cara iku kudu-nganti dumadakan sing fungsi ketemu dhewe ing tengah saka kedadean utama.
Apa sabanjuré?
Pakaryan kanggo njamin stabilitas layanan ora mandheg lan kita terus-terusan nambah. Nalika volume lalu lintas terus tuwuh ing quay.io, kita ngerti manawa kita duwe tanggung jawab kanggo nindakake kabeh sing kita bisa kanggo nggayuh kapercayan para pelanggan. Mulane, saiki kita nggarap tugas ing ngisor iki:
- Nyebarake replika database mung diwaca kanggo mbantu layanan nangani lalu lintas sing cocog yen ana masalah karo conto RDS utama.
- Nganyari conto RDS. Versi saiki dhewe ora dadi masalah. Nanging, kita mung pengin mbusak jejak palsu (sing kita tindakake nalika gagal); Nganyari piranti lunak bakal ngilangi faktor liya yen ana gangguan ing mangsa ngarep.
- Caching tambahan ing kabeh kluster. Kita terus nggoleki wilayah ing ngendi caching bisa nyuda beban ing database.
- Nambahake firewall aplikasi web (WAF) kanggo ndeleng sapa sing nyambung menyang quay.io lan ngapa.
- Miwiti rilis sabanjure, kluster Red Hat OpenShift bakal ninggalake App Registry kanggo milih Katalog Operator adhedhasar gambar wadhah sing kasedhiya ing quay.io.
- Panggantos jangka panjang kanggo App Registry bisa dadi dhukungan kanggo spesifikasi artefak Open Container Initiative (OCI). Saiki dileksanakake minangka fungsi Quay asli lan bakal kasedhiya kanggo pangguna nalika spesifikasi kasebut wis rampung.
Kabeh ing ndhuwur minangka bagean saka investasi Red Hat ing quay.io nalika kita pindhah saka tim "gaya wiwitan" cilik menyang platform sing didorong SRE sing diwasa. Kita ngerti manawa akeh pelanggan sing ngandelake quay.io ing karya saben dinane (kalebu Red Hat!)
PS saka penerjemah
Waca uga ing blog kita:
- «";
- «";
- «".
Source: www.habr.com