Kaugnay ng lumalagong katanyagan ng Rook, nais kong pag-usapan ang tungkol sa mga pitfalls at problema nito na naghihintay sa iyo sa daan.
Tungkol sa akin: Karanasan sa pangangasiwa ng ceph mula sa bersyon ng martilyo, tagapagtatag ng komunidad sa telegrama.
Para hindi maging unfounded, ire-refer ko ang mga post na tinanggap ni Habr (judging by the rating) about problems with ceph. Nakatagpo din ako ng karamihan sa mga problema sa mga post na ito. Ang mga link sa materyal na ginamit ay nasa dulo ng post.
Sa post tungkol sa Rook, binanggit namin ang ceph para sa isang dahilan - Ang Rook ay mahalagang ceph na nakabalot sa mga kubernetes, na nangangahulugang minana nito ang lahat ng mga problema nito. Magsimula tayo sa mga problema ni ceph.
Pasimplehin ang pamamahala ng cluster
Isa sa mga bentahe ng Rook ay ang kadalian ng pamamahala ng ceph sa pamamagitan ng kuberentes.
Gayunpaman, ang ceph ay naglalaman ng higit sa 1000 mga parameter para sa pagsasaayos, habang sa parehong oras, sa pamamagitan ng rook maaari lamang nating i-edit ang isang minorya sa kanila.
Halimbawa sa Luminous
> ceph daemon mon.a config show | wc -l
1401
Ang Rook ay nakaposisyon bilang isang maginhawang paraan upang i-install at i-update ang ceph
Walang problema sa pag-install ng ceph nang walang Rook - nakasulat ang ansible playbook sa loob ng 30 minuto, ngunit maraming problema sa pag-update.
Quote mula sa post ni Krok
Halimbawa: hindi gumagana nang tama ang crush tunables pagkatapos mag-update mula hummer hanggang jewel
> ceph osd crush show-tunables
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profile": "hindi alam",
"optimal_tunables": 0,
...
}
Ngunit kahit na sa loob ng mga menor de edad na bersyon ay may mga problema.
Halimbawa: I-update ang 12.2.6 na dinadala ang cluster sa estado ng error sa kalusugan at may kondisyong sirang PG
Huwag mag-update, maghintay at subukan? Ngunit tila ginagamit namin ang Rook para sa kaginhawaan ng mga update, bukod sa iba pang mga bagay.
Pagiging kumplikado ng disaster recovery cluster sa Rook
Halimbawa: Nahuhulog ang OSD na may pantal ng mga error sa paanan nito. Pinaghihinalaan mo na ang problema ay nasa isa sa mga parameter sa config, gusto mong baguhin ang config para sa isang partikular na daemon, ngunit hindi mo magawa dahil mayroon kang mga kubernetes at DaemonSet.
Walang alternatibo. ceph tell osd.Num injectargs ay hindi gumagana - ang OSD ay nagsisinungaling.
Kahirapan sa pag-debug
Ang ilang mga setup at pagsubok sa pagganap ay nangangailangan ng direktang pagkonekta sa osd socket ng daemon. Sa kaso ng Rook, kailangan mo munang hanapin ang nais na lalagyan, pagkatapos ay pumunta dito, hanapin ang tooling na nawawala para sa pag-debug at magalit nang labis.
Kahirapan sa patuloy na pagtaas ng OSD
Halimbawa: Bumagsak ang OSD sa OOM, magsisimula ang muling pagbabalanse, pagkatapos ay babagsak ang mga sumusunod.
Solusyon: Itaas ang OSD nang paisa-isa, maghintay hanggang sa ganap itong maisama sa cluster at itaas ang mga susunod. (Higit pang mga detalye sa ulat ni Ceph. Anatomy of a disaster).
Sa kaso ng pag-install ng baremetal, ito ay ginagawa sa pamamagitan lamang ng kamay; sa kaso ng Rook at isang OSD bawat node, walang partikular na problema; ang mga problema sa alternatibong pag-angat ay lilitaw kung OSD > 1 bawat node.
Siyempre, malulutas ang mga ito, ngunit ginagamit namin ang Rook upang pasimplehin ang mga bagay, ngunit maging mas kumplikado.
Kahirapan sa pagpili ng mga limitasyon para sa mga demonyong ceph
Para sa isang baremetal na pag-install ng ceph, medyo madaling kalkulahin ang mga kinakailangang mapagkukunan para sa isang kumpol - may mga formula at magagamit ang pananaliksik. Kung gumagamit ka ng mahinang CPU, kakailanganin mo pa ring magpatakbo ng ilang mga pagsubok sa pagganap upang malaman kung ano ang Numa, ngunit mas madali pa rin ito kaysa sa Rook.
Sa kaso ng Rook, bilang karagdagan sa mga limitasyon ng memorya na maaaring kalkulahin, mayroon kang tanong sa pagtatakda ng limitasyon ng CPU.
At dito kailangan mong magtrabaho nang husto sa mga pagsubok sa pagganap. Kung babaan mo ang mga limitasyon, makakakuha ka ng isang mabagal na kumpol; kung nagtakda ka ng unlim, makakakuha ka ng aktibong paggamit ng CPU sa panahon ng rebalancing, na magkakaroon ng masamang epekto sa iyong mga aplikasyon sa kubernetes.
Mga Isyu sa Networking v1
Para sa ceph inirerekomendang gumamit ng 2x10GB network. Isa para sa trapiko ng kliyente, ang isa para sa mga pangangailangan ng serbisyo ng ceph (rebalance). Kung nakatira ka sa ceph sa baremetal, kung gayon ang dibisyong ito ay madaling i-configure, kung nakatira ka kasama ang Rook, kung gayon ang paghahati sa pamamagitan ng mga network ay magdudulot sa iyo ng mga problema, dahil sa katotohanan na hindi lahat ng cluster config ay nagbibigay-daan sa iyo na magpakain ng dalawang magkaibang network sa pod .
Mga Isyu sa Networking v2
Kung tumanggi kang maghiwalay ng mga network, pagkatapos ay kapag nag-rebalancing, ang trapiko ng ceph ay magbara sa buong channel at ang iyong mga aplikasyon sa kubernetes ay bumagal o mag-crash. Maaari mong bawasan ang bilis ng pag-rebalancing ng ceph, ngunit pagkatapos ay dahil sa mahabang rebalancing makakakuha ka ng mas mataas na panganib ng pagbagsak ng pangalawang node mula sa cluster sa pamamagitan ng mga disk o OOM, at mayroon nang garantisadong read only para sa cluster.
Mahabang muling pagbabalanse - matagal na pagkahuli ng aplikasyon
Quote mula sa post ni Ceph. Anatomy ng isang kalamidad.
Pagsubok sa pagganap ng cluster:
Ang isang write operation na 4 KB ang laki ay tumatagal ng 1 ms, ang performance ay 1000 operations/second sa 1 thread.
Ang pagpapatakbo ng 4 MB (laki ng bagay) ay tumatagal ng 22 ms, ang pagganap ay 45 na operasyon/segundo.
Dahil dito, kapag ang isang domain sa tatlo ay nabigo, ang cluster ay nasa isang degraded na estado sa loob ng ilang panahon, at kalahati ng mga maiinit na bagay ay ipinamamahagi sa iba't ibang mga bersyon, pagkatapos ay kalahati ng mga operasyon sa pagsulat ay magsisimula sa isang sapilitang pagbawi.
Kinakalkula namin ang sapilitang oras ng pagbawi ng humigit-kumulang - sumulat ng mga operasyon sa isang nasira na bagay.
Una ay nagbabasa kami ng 4 MB sa 22 ms, sumulat ng 22 ms, at pagkatapos ay sa 1 ms nagsusulat kami ng 4 KB ng aktwal na data. Kabuuan ng 45 ms bawat write operation sa isang nasira na bagay sa isang SSD, kapag ang standard na performance ay 1 ms - isang 45-fold na pagbaba sa performance.
Kung mas mataas ang porsyento ng mga nasirang bagay na mayroon tayo, mas lumalala ang lahat.
Ito ay lumalabas na ang bilis ng rebalancing ay kritikal para sa tamang operasyon ng cluster.
Mga partikular na setting ng server para sa ceph
Ang ceph ay maaaring mangailangan ng partikular na host tuning.
Halimbawa: mga setting ng sysctl at ang parehong JumboFrame, ang ilan sa mga setting na ito ay maaaring negatibong makaapekto sa iyong payload.
Ang tunay na pangangailangan para sa Rook ay nananatiling pinag-uusapan
Kung ikaw ay nasa cloud mayroon kang storage mula sa iyong cloud provider, na mas maginhawa.
Kung ikaw ay nasa iyong sariling mga server, kung gayon ang pamamahala ng ceph ay magiging mas maginhawa nang walang kubernetes.
Nagrenta ka ba ng mga server mula sa ilang murang pagho-host? Pagkatapos ay magkakaroon ka ng labis na kasiyahan sa network, ang mga pagkaantala at bandwidth nito, na malinaw na negatibong nakakaapekto sa ceph.
Kabuuan: Ang pagpapatupad ng kuberentes at pagpapatupad ng storage ay magkakaibang gawain na may iba't ibang input at iba't ibang opsyon sa solusyon - ang paghahalo sa mga ito ay nangangahulugan ng paggawa ng posibleng mapanganib na trade-off para sa kapakanan ng isa o ng iba. Napakahirap pagsamahin ang mga solusyong ito kahit na sa yugto ng disenyo, at mayroon pa ring panahon ng operasyon.
Listahan ng ginamit na panitikan:
Pero sabi mo Ceph... ganun ba talaga siya kagaling?
Si Ceph. Anatomy ng isang kalamidad
Pinagmulan: www.habr.com