Med den ökande populariteten av Rook Àr det vÀrt att diskutera dess fallgropar och problem som kan vÀntar pÄ vÀgen.
Om mig: Erfarenhet av att administrera ceph sedan versionen hammer, grundare av communityn pÄ Telegram.
För att inte vara bara pÄstÄenden kommer jag att referera till vÀl accepterade inlÀgg pÄ Habr (enligt betyg) om problem med ceph. Jag har ocksÄ stött pÄ de flesta av problemen i dessa inlÀgg. LÀnkar till materialet i slutet av inlÀgget.
I inlĂ€gget om Rook nĂ€mner vi ceph av en anledning â Rook Ă€r i grunden ceph insvept i kubernetes, vilket innebĂ€r att det Ă€rver alla dess problem. Vi börjar med problemen i ceph.
Förenkling av klusterhantering
En av fördelarna med Rook Àr enkelheten att hantera ceph genom kubernetes.
Men ceph har mer Àn 1000 konfigurationsalternativ, medan vi genom Rook endast kan Àndra en mindre del av dem.
Exempel pÄ Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook positionerar sig som ett bekvÀmt sÀtt att installera och uppdatera ceph
Det finns inga problem med att installera ceph utan Rook â en ansible playbook kan skrivas pĂ„ 30 minuter, men problemet med att uppdatera Ă€r stort.
Citat frÄn Krok-inlÀgget
Exempel: Felaktig funktion av crush tunables efter uppdatering frÄn hummer till jewel
> ceph osd crush show-tunables
{
âŠ
«straw_calc_version»: 1,
«allowed_bucket_algs»: 22,
«profile»: «unknown»,
«optimal_tunables»: 0,
âŠ
}
Men Àven inom minorversioner kan det uppstÄ problem.
Exempel: Uppdatering 12.2.6 som sÀtter klustret i tillstÄndet health err och förmodligen skadad PG
Skulle vi inte uppdatera, vÀnta och testa? Men vi anvÀnder ju Rook för bekvÀmligheten med uppdateringar ocksÄ.
SvÄrigheter med katastrofÄterstÀllning av klustret i Rook
Exempel: OSD kraschar och spottar fel under processen. Du misstÀnker att problemet ligger i nÄgot av parametrarna i konfigurationen, vill Àndra konfigurationen för en specifik demon, men kan inte eftersom du har kubernetes och DaemonSet.
Det finns inget alternativ. ceph tell osd.Num injectargs fungerar inte â OSD Ă€r nere.
SvÄrigheter med debuggning
För vissa instÀllningar och prestandatest mÄste man ansluta direkt till OSD-demonens socket. I Rook mÄste man först hitta rÀtt container, sedan gÄ in i den, upptÀcka att den saknar debug-verktyg och bli mycket besviken.
SvÄrigheter med successiv start av OSD
Exempel: OSD kraschar pÄ OOM, ombalanseringen börjar, och sedan kraschar nÀsta.
Lösning: Höj OSD en och en, vÀnta tills den Àr helt ansluten till klustret och lyft nÀsta. (Mer i rapporten Ceph. Katastrofans anatomi).
Vid baremetal-installation görs detta enkelt för hand. Vid Rook och en OSD per nod finns det inga större problem, problemet med sekventiell upplysning uppstÄr om OSD > 1 per nod.
SjÀlvklart Àr de lösbara, men vi strÀvar ju efter att förenkla med Rook, inte komplicera.
SvÄrigheter med att stÀlla in begrÀnsningar för Ceph-demoner.
För baremetal-installation Ă€r det ganska lĂ€tt att berĂ€kna nödvĂ€ndiga resurser för klustret â formler och forskning finns. Vid anvĂ€ndning av svaga CPU:er mĂ„ste du Ă€ndĂ„ göra en mĂ€ngd prestandatester, förstĂ„ vad Numa Ă€r, men det Ă€r fortfarande enklare Ă€n med Rook.
I fallet med Rook, förutom minnesbegrÀnsningarna som gÄr att berÀkna, uppstÄr frÄgan om att stÀlla in CPU-begrÀnsningar.
Och hÀr mÄste du kÀmpa med prestandatester. Om du sÀtter för lÄga begrÀnsningar fÄr du en lÄngsam kluster, om du sÀtter unlimit fÄr du aktiv CPU-anvÀndning vid ombalansering, vilket kommer att pÄverka dina applikationer i Kubernetes negativt.
Problem med nÀtverksinteraktion v1.
För Ceph rekommenderas att anvÀnda ett 2x10Gb-nÀtverk. Ett för klienttrafik, det andra för Ceph:s interna behov (ombalans). Om du har Ceph pÄ baremetal Àr det lÀtt att konfigurera denna uppdelning, men om du anvÀnder Rook kan nÀtverksuppdelningen orsaka problem, eftersom inte varje klusterkonfiguration tillÄter att skicka olika nÀtverk till en pod.
Problem med nÀtverksinteraktion v2.
Om du vÀljer att inte dela nÀtverken kommer Ceph:s trafik att blockera hela kanalen under ombalansering, och dina applikationer i Kubernetes kommer att bromsa eller krascha. Du kan minska hastigheten pÄ Ceph:s ombalansering, men dÄ riskerar du att en andra nod faller ur klustret pÄ grund av diskar eller OOM, och dÀr blir det garanterad read-only för klustret.
LĂ„ngsam ombalansering â lĂ„ngsamma bromsar i applikationerna.
Citat frÄn inlÀgget Ceph. Katastrofans anatomi.
Prestanda för testklustret:
Skrivoperationen pÄ 4 KB tar 1 ms, prestanda 1000 operationer/sekund i 1 trÄd.
Operationen pÄ 4 MB (objektstorlek) tar 22 ms, prestanda 45 operationer/sekund.
DÀrför, nÀr en av tre domÀner misslyckas, befinner sig klustret en tid i ett försÀmrat tillstÄnd, och hÀlften av de aktiva objekten sprids över olika versioner, kommer hÀlften av skrivoperationerna att börja med en tvingad ÄterstÀllning.
Tiden för tvingad Ă„terstĂ€llning uppskattas ungefĂ€r â skrivoperationer i det försĂ€mrade objektet.
Först lĂ€ser vi 4 MB pĂ„ 22 ms, skriver 22 ms, och sedan skriver vi 4 KB egna data pĂ„ 1 ms. Totalt tar det 45 ms för en skrivoperation i det försĂ€mrade objektet pĂ„ SSD, medan den normala prestandan var 1 ms â en prestandaförlust pĂ„ 45 gĂ„nger.
Ju högre procentandel av försÀmrade objekt, desto mer skrÀmmande blir det.
Det visar sig att hastigheten pÄ ombalansering Àr kritiskt viktig för klustrets korrekta funktion.
Specifika serverinstÀllningar för ceph
ceph kan behöva specifik host-tuning.
Exempel: sysctl-instÀllningar och samma JumboFrame, vissa av dessa instÀllningar kan negativt pÄverka din payload.
Det verkliga behovet av Rook kvarstÄr en frÄga
Om du Àr i molnet har du lagring frÄn din molnleverantör, vilket Àr mycket bekvÀmare.
Om du Àr pÄ dina egna servrar kommer hanteringen av ceph att vara enklare utan kubernetes.
Hyra servrar pÄ nÄgon lÄgprishosting? DÄ vÀntar dig mycket roligt med nÀtverket, dess latens och bandbredd, vilket uppenbart negativt pÄverkar ceph.
Totalt: Implementering av kubernetes och implementering av lagring Ă€r olika uppgifter med olika ingĂ„ngar och olika lösningar â att blanda dem innebĂ€r att göra en potentiellt farlig trade-off till förmĂ„n för den ena eller den andra. Att kombinera dessa lösningar kommer att bli mycket svĂ„rt Ă€ven under designfasen, och det finns fortfarande en driftsperiod.
Lista över referenser:
Men ni pratar om Ceph⊠Àr den verkligen sÄ bra?
Ceph. Katastrofens anatomi
KĂ€lla: habr.com
