Ņemot vērā Rook pieaugošo popularitāti, ir vērts apspriest tā slēptos akmeņus un problēmas, kas gaida jūs ceļā.
Par mani: Ceph administrēšanas pieredze kopš versijas hammer, kopienas dibinātājs Telegramā.
Lai nebūtu bez pamata, es atsaukšos uz populāriem Habrā (balstoties uz vērtējumiem) rakstiem par problēmām ar ceph. Ar lielāko daļu problēmu šajos rakstos es arī esmu saskāries. Saites uz izmantotajiem materiāliem raksta beigās.
Rakstā par Rook mēs pieminam ceph ne bez iemesla — Rook būtībā ir ceph, kas ietērpts Kubernetes, tādējādi mantojot visas tā problēmas. Sāksim ar ceph problēmām.
Klastra pārvaldības vienkāršošana
Viena no Rook priekšrocībām ir ērta ceph pārvaldība caur Kubernetes.
Tomēr ceph satur vairāk nekā 1000 iestatījumu, bet caur Rook mēs varam mainīt tikai mazāko daļu no tiem.
Piemērs uz Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook tiek pozicionēts kā ērts veids, kā instalēt un atjaunināt ceph
Nav nekādu problēmu ar ceph uzstādīšanu bez Rook — ansible playbook var uzrakstīt 30 minūšu laikā, bet ar atjaunināšanu problēmu ir daudz.
Citāts no Krok raksta
Piemērs: nepareiza crush tunables darbība pēc atjaunināšanas no hummer uz jewel
> ceph osd crush show-tunables
{
…
«straw_calc_version»: 1,
«allowed_bucket_algs»: 22,
«profile»: «unknown»,
«optimal_tunables»: 0,
…
}
Tomēr pat nelielu versiju ietvaros rodas problēmas.
Piemērs: Atjauninājums 12.2.6 noved klasteri līdz health err stāvoklim un nosacīti bojātiem PG
Neatjaunināt, gaidīt un testēt? Taču mēs it kā izmantojam Rook arī ērtu atjauninājumu dēļ.
Rook klastera katastrofāles atveseļošanas sarežģītība
Piemērs: OSD avarē ar kļūdu lavīnu. Jūs aizdomājaties, ka problēma ir kādā no konfigurācijas iestatījumiem, vēlaties mainīt konfigurāciju konkrētam demonam, bet nevarat, jo jums ir Kubernetes un DaemonSet.
Alternatīvas nav. ceph tell osd.Num injectargs nedarbojas — OSD taču ir bezdarbīgs.
Debug sarežģītība
Dažiem iestatījumiem un veiktspējas testiem ir nepieciešams tieši piekļūt OSD demona ligzdai. Rook gadījumā vispirms jāatrod pareizais konteineris, pēc tam tajā jāpiekļūst, jāatrod trūkstošie debug rīki un ļoti jānožēlo.
OSD secīgas pacelšanas sarežģītība
Piemērs: OSD avarē dēļ OOM, sākas pārdale, pēc tam avarē nākamie.
Risinājums: Paceliet OSD vienu pa vienai, gaidot, līdz tā pilnībā ievienojas klasterī, un paceliet nākamo. (Sīkāk skatiet ziņojumā Ceph. Katastrofu anatomija).
Baremetal uzstādīšanā tas tiek izdarīts vienkārši rokas, ja runājam par Rook un vienu OSD uz mezglu, problēmu īpaši nav, bet problēmas ar secīgu pacelšanu radīsies, ja OSD > 1 uz mezglu.
Protams, tās ir risināmas, bet mēs jau nesam Rook, lai atvieglotu, bet iegūstam sarežģījumus.
Sarežģītība, izvēloties ceph dēmoniem ierobežojumus.
Baremetal ceph instalācijai ir viegli aprēķināt nepieciešamos resursus klasterim — ir formulas un pētījumi. Izmantojot vājus CPU, jums joprojām būs jāveic virkni veiktspējas testu, jāzina, kas ir Numa, bet tas tomēr ir vieglāk nekā Rook gadījumā.
Rook gadījumā jums, papildus atmiņas ierobežojumiem, kas ir aprēķināmi, ir jautājums par CPU ierobežojumu noteikšanu.
Un šeit jums nāksies daudz strādāt ar veiktspējas testiem. Ja ierobežojumi ir pārāk zemi, jūs saņemsiet lēnu klasteri, savukārt, ja nosakāt neierobežotus, jūs iegūsiet aktīvu CPU izmantošanu pārdalē, kas negatīvi ietekmēs jūsu lietojumprogrammas Kubernetes.
Tīkla mijiedarbības problēmas v1.
Ceph ieteicams izmantot 2x10gb tīklu. Vienu klientu trafikam, otru ceph pakalpojumiem (pārdale). Ja jūs dzīvojat ar ceph baremetal, tad šī sadalīšana ir viegli iestatāma, ja jūs dzīvojat ar Rook, tad šāda sadalīšana pa tīkliem radīs jums problēmas, jo ne katrs klastera konfigurācija ļauj piegādāt podam divus dažādus tīklus.
Tīkla mijiedarbības problēmas v2.
Ja jūs atteiksieties no tīklu sadalīšanas, tad pārdales laikā ceph trafiks noslogos visu kanālu un jūsu lietojumprogrammas Kubernetes tiks bremzētas vai avarēs. Jūs varat samazināt ceph pārdales ātrumu, bet tad ilga pārdale rada paaugstinātu riska iespēju, ka otra mezgla diskus vai OOM izkristu no klastera, un tad jau garantēts lasīšanas tikai režīms klasterim.
Ilga pārdale — ilgas programmu bremzes.
Citāts no ziņas Ceph. Katastrofu anatomija.
Testa klastera veiktspēja:
4 Kb rakstīšanas operācija aizņem 1 ms, veiktspēja 1000 operācijas/sekundē 1 plūsmā.
4 Mb (objekta izmērs) operācija aizņem 22 ms, veiktspēja 45 operācijas/sekundē.
Tādējādi, kad viens no trim domēniem atteicās, klasteris kādu brīdi atrodas degradētā stāvoklī, un puse karsto objektu izplatīsies starp dažādām versijām, tad puse rakstīšanas operāciju tiks uzsākta ar piespiedu atjaunošanu.
Piespiedu atjaunošanas laiku aprēķinām aptuveni — rakstīšanas operācijas degradētajā objektā.
Vispirms mēs lasām 4 MB 22 ms, rakstām 22 ms, un pēc tam 1 ms mēs rakstām 4 KB faktisko datu. Kopumā 45 ms uz vienu rakstīšanas operāciju degradētajā objektā SSD, kad normālā veiktspēja bija 1 ms — veiktspējas samazinājums 45 reizes.
Jo lielāks ir degradēto objektu procents, jo viss kļūst nopietnāk.
Izrādās, ka pārbilances ātrums ir kritiski svarīgs klastera pareizai darbībai.
Specifiski serveru iestatījumi Ceph
Ceph var prasīt specifisku hosta pielāgošanu.
Piemērs: sysctl iestatījumi un tāds pats JumboFrame, daži no šiem iestatījumiem var negatīvi ietekmēt jūsu payload.
Reālā Rook nepieciešamība ir zem jautājuma
Ja jūs atrodaties mākoņos un jums ir uzglabāšana no jūsu mākoņu pakalpojumu sniedzēja, tas ir daudz ērtāk.
Ja jūs esat uz saviem serveriem, tad Ceph pārvaldība būs ērtāka bez Kubernetes.
Vai jūs īrējat serverus kādā low cost hostinga pakalpojumā? Tad jūs gaida daudz jautrības ar tīklu, tā aizkavi un caurlaidspēju, kas acīmredzami negatīvi ietekmē Ceph.
Kopā: Kubernetes ieviešana un uzglabāšanas ieviešana ir dažādas uzdevumu kopas ar dažādiem sākumiem un dažādiem risinājumu variantiem — tās sajaucot, ir iespējams veikt potenciāli bīstamu trade-off par labu vienam vai otram. Saskaņot šos risinājumus būs ļoti grūti pat projektēšanas posmā, un ir vēl eksploatācijas periods.
Izmantotā literatūra:
Bet jūs sakāt Ceph… vai tas tiešām ir tik labs?
Ceph. Katastrofu anatomija
Avots: habr.com
