Dina sambungan jeung popularitas tumuwuh tina Rook, Abdi hoyong ngobrol ngeunaan pitfalls sarta masalah anu ngantosan anjeun sapanjang jalan.
Ngeunaan kuring: Pangalaman dina administrasi ceph tina versi palu, pangadeg komunitas dina telegram.
Dina raraga teu jadi unfounded, abdi bakal ngarujuk kana tulisan ditarima ku Habr (ditilik ku rating) ngeunaan masalah jeung ceph. Kuring ogé mendakan seueur masalah dina tulisan ieu. Tumbu ka bahan dipaké aya dina tungtung pos.
Dina tulisan ngeunaan Rook, urang nyebut ceph pikeun alesan - Rook dasarna ceph dibungkus kubernetes, nu hartina eta inherits sagala masalah na. Hayu urang mimitian ku masalah ceph.
Nyederhanakeun manajemén klaster
Salah sahiji kaunggulan Rook nyaéta gampangna ngatur ceph ngaliwatan kuberentes.
Sanajan kitu, ceph ngandung leuwih ti 1000 parameter pikeun konfigurasi, bari dina waktos anu sareng, ngaliwatan rook urang ngan bisa ngédit minoritas di antarana.
Conto dina Luminous
> ceph daemon mon.a config acara | wc -l
1401
Rook diposisikan salaku cara anu merenah pikeun masang sareng ngapdet ceph
Teu aya masalah sareng masang ceph tanpa Rook - playbook ansible ditulis dina 30 menit, tapi aya seueur masalah sareng pembaruan.
Kutipan tina tulisan Krok
Conto: naksir tunables henteu jalan leres saatos ngamutahirkeun tina hummer ka permata
> ceph osd naksir acara-tunables
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profile": "teu kanyahoan",
"optimal_tunables": 0,
...
}
Tapi sanajan dina versi minor aya masalah.
Conto: Update 12.2.6 bringing klaster kana kaayaan err kaséhatan sarta conditionally rusak PG
Tong update, antosan sareng uji? Tapi sigana urang ngagunakeun Rook pikeun genah apdet, diantara hal séjén.
Pajeulitna klaster recovery musibah di Rook
Conto: OSD ragrag kalawan ruam kasalahan dina suku na. Anjeun curiga yén masalahna aya dina salah sahiji parameter di config nu, rék ngarobah config pikeun daemon husus, tapi anjeun teu bisa sabab boga kubernetes na DaemonSet.
Teu aya alternatif. ceph ngabejaan osd.Num injectargs teu dianggo - OSD bohong.
Kasesahan debug
Sababaraha setelan sareng tes kinerja ngabutuhkeun nyambungkeun langsung kana soket osd daemon. Dina kasus Rook, anjeun mimiti kedah milarian wadah anu dipikahoyong, teras lebet kana éta, milarian alat anu leungit pikeun debug sareng kesel pisan.
Kasesahan naékkeun OSD sacara konsisten
Conto: OSD ragrag dina OOM, rebalance dimimitian, sanggeus nu handap ragrag.
Solusi: Angkat OSD hiji-hiji, antosan dugi lengkep kalebet kana kluster sareng angkat anu salajengna. (Leuwih rinci dina laporan Ceph. Anatomi musibah).
Dina kasus pamasangan baremetal, ieu dilakukeun ngan ukur ku tangan; dina kasus Rook sareng hiji OSD per node, teu aya masalah khusus; masalah sareng angkat alternatif bakal timbul upami OSD> 1 per node.
Tangtosna, aranjeunna tiasa direngsekeun, tapi kami nganggo Rook pikeun nyederhanakeun hal, tapi janten langkung rumit.
Kasesahan dina milih wates pikeun setan ceph
Pikeun pamasangan baremetal ceph, cukup gampang ngitung sumber daya anu diperyogikeun pikeun klaster - aya rumus sareng panalungtikan anu sayogi. Upami Anjeun keur make CPU lemah, Anjeun masih kudu ngajalankeun sababaraha tés kinerja pikeun manggihan naon Numa, tapi masih gampang ti Rook.
Dina kasus Rook, sajaba wates memori nu bisa diitung, anjeun boga sual nyetel wates CPU.
Sareng di dieu anjeun kedah kerja keras sareng tés kinerja. Upami anjeun nurunkeun watesna, anjeun bakal nampi klaster anu laun; upami anjeun nyetél unlim, anjeun bakal nampi pamakean CPU anu aktip salami rebalancing, anu bakal ngagaduhan pangaruh anu goréng dina aplikasi anjeun dina kubernetes.
Masalah Jaringan v1
Pikeun ceph dianjurkeun ngagunakeun jaringan 2x10GB. Hiji pikeun lalu lintas klien, anu sanés pikeun kabutuhan jasa ceph (rebalance). Upami anjeun cicing sareng ceph on baremetal, maka division ieu gampang dikonpigurasikeun, upami anjeun cicing sareng Rook, maka pembagian ku jaringan bakal nyababkeun masalah anjeun, kusabab kanyataan yén henteu unggal konfigurasi klaster ngamungkinkeun anjeun pikeun nyayogikeun dua jaringan anu béda kana pod. .
Masalah Jaringan v2
Upami anjeun nolak pikeun misahkeun jaringan, teras nalika ngimbangan deui, lalu lintas ceph bakal macet sadayana saluran sareng aplikasi anjeun dina kubernetes bakal ngalambatkeun atanapi nabrak. Anjeun tiasa ngurangan laju rebalancing ceph, tapi lajeng alatan rebalancing lila anjeun meunang hiji résiko ngaronjat tina titik kadua ragrag kaluar tina klaster via disk atawa OOM, tur aya geus dijamin dibaca ukur keur kluster.
Rebalance panjang - lags aplikasi panjang
Dicutat tina tulisan Ceph. Anatomi musibah.
Uji kinerja klaster:
Operasi nulis 4 KB dina ukuran butuh 1 mdet, kinerja 1000 operasi/detik dina 1 thread.
Operasi 4 MB (ukuran objék) butuh 22 mdet, kinerja 45 operasi/detik.
Akibatna, nalika salah sahiji domain tina tilu gagal, klaster dina kaayaan didegradasi pikeun sawatara waktu, sarta satengah tina objék panas disebarkeun di versi béda, lajeng satengah tina operasi nulis bakal dimimitian ku recovery kapaksa.
Urang ngitung waktu recovery kapaksa kira - nulis operasi ka obyék didegradasi.
Mimiti urang maca 4 MB dina 22 mdet, nyerat 22 mdet, teras dina 1 mdet urang nyerat 4 KB data aktual. Jumlahna aya 45 ms per operasi nulis ka obyék didegradasi dina SSD, lamun kinerja baku éta 1 ms - a serelek 45-melu dina kinerja.
Nu leuwih luhur persentase objék didegradasi kami boga, nu jadi goréng sagalana.
Tétéla yén laju rebalancing kritis pikeun operasi bener tina klaster.
Setélan server husus pikeun ceph
ceph bisa merlukeun tuning host husus.
Conto: setélan sysctl sareng JumboFrame anu sami, sababaraha setélan ieu tiasa mangaruhan négatif payload anjeun.
Kabutuhan nyata pikeun Rook tetep ditaroskeun
Upami anjeun dina méga anjeun gaduh panyimpen ti panyadia awan anjeun, anu langkung saé.
Upami anjeun dina server anjeun nyalira, maka ngatur ceph bakal langkung merenah tanpa kubernetes.
Naha anjeun nyéwa server tina sababaraha hosting béaya rendah? Lajeng anjeun bakal boga loba senang jeung jaringan, Nepi na rubakpita, nu jelas négatip mangaruhan ceph.
total: Ngalaksanakeun kuberentes sareng ngalaksanakeun panyimpen mangrupikeun tugas anu béda-béda kalayan input anu béda sareng pilihan solusi anu béda - nyampur aranjeunna hartosna ngadamel trade-off anu mungkin bahaya pikeun hiji atanapi anu sanés. Bakal sesah pisan pikeun ngagabungkeun solusi ieu bahkan dina tahap desain, sareng masih aya periode operasi.
Daptar pustaka anu dianggo:
Tapi anjeun nyarios Ceph ... anjeunna leres-leres saé?
Ceph. Anatomi musibah
sumber: www.habr.com