Vzhledem k rostoucí popularitě Rook bych chtěl mluvit o jeho úskalích a problémech, které vás na cestě čekají.
O sobě: Zkušenosti s administrací ceph od verze hammer, zakladatel komunity na Telegramu.
Abych nebyl bez důkazů, budu odkazovat na přijaté příspěvky na Habr (soudě podle hodnocení) o problémech s ceph. S většinou problémů v těchto příspěvcích jsem se také setkal. Odkazy na použitý materiál na konci příspěvku.
V příspěvku o Rook zmiňujeme ceph nikoli náhodou — Rook je v podstatě ceph zabalený do kubernetes, a tím pádem dědí všechny jeho problémy. S problémy ceph i začneme.
Zjednodušení správy klastru
Jednou z výhod Rook je snadnost správy ceph přes kubernetes.
Nicméně ceph obsahuje více než 1000 parametrů pro nastavení, a zároveň skrze rook můžeme upravit pouze menší část z nich.
Příklad na Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook je prezentován jako pohodlný způsob installace a aktualizace ceph
S instalací ceph bez Rook nejsou žádné problémy — ansible playbook se napíše za 30 minut, ale s aktualizacemi je problémů spousta.
Citace z příspěvku Krok
Příklad: nesprávná práce crush tunables po aktualizaci z hummer na jewel
> ceph osd crush show-tunables
{
…
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profile": "unknown",
"optimal_tunables": 0,
…
}
Ale i mezi minoritními verzemi se mohou vyskytnout problémy.
Příklad: Aktualizace 12.2.6 vedoucí k tomu, že klastr se dostane do stavu health err a podmíněně poškozeného PG
Neaktualizovat, čekat a testovat? Ale přece používáme Rook právě kvůli pohodlí aktualizací.
Složitost disaster recovery klastru v Rook
Příklad: OSD padá a hází chyby pod sebe. Podezříváte, že problém je v jednom z parametrů v konfigu, chcete změnit konfiguraci pro konkrétní démon, ale nemůžete, protože máte kubernetes a DaemonSet.
Není alternativa. ceph tell osd.Num injectargs nefunguje — OSD je přece dole.
Složitost debugování
Pro některá nastavení a testy výkonu je třeba se připojit přímo k socketu démonu osd. V případě Rook je nejprve nutné najít potřebný kontejner, poté se do něj dostat, zjistit, že debug tool chybí, a velmi se rozčílit.
Složitost sekvenčního zvedání OSD
Příklad: OSD padá kvůli OOM, začíná rebalance a poté padají další.
Řešení: Zvedejte OSD jednu po druhé, počkejte, až se plně připojí ke clustru, a poté zvedněte další. (Více v reportu Ceph. Anatomie katastrofy).
V případě baremetal instalace to děláte jednoduše ručně, v případě Rook a jedné OSD na uzlu nejsou prakticky žádné problémy. Problémy s postupným zvedáním nastanou, pokud je OSD > 1 na uzlu.
Samozřejmě, že jsou řešitelné, ale přece jen nasazujeme Rook pro zjednodušení, a přitom získáváme složitost.
Složitost stanovení limitů pro ceph démony
Pro baremetal instalaci ceph je poměrně snadné vypočítat potřebné zdroje pro cluster — existují vzorce a výzkumy. Při používání slabých CPU budete přesto muset provést řadu testů výkonu, zjistit, co je Numa, ale i tak je to jednoduchější než v Rook.
V případě Rook vedle limitů paměti, které lze vypočítat, nastává otázka stanovení limitu CPU.
A tady se budete muset potrápit s testy výkonu. Při podcenění limitů obdržíte pomalý cluster, při nastavení unlim budete mít aktivní využití CPU během rebalance, což negativně ovlivní vaše aplikace v kubernetes.
Problémy se síťovou interakcí v1
Pro ceph se doporučuje použít síť 2x10Gb. Jednu pro klientský provoz, druhou pro služební potřeby ceph (rebalance). Pokud žijete s ceph na baremetal, lze toto oddělení snadno nastavit, pokud žijete s Rook, pak vám rozdělení mezi sítěmi způsobí problémy, protože ne každý konfigurace clusteru umožňuje zadat do podu dvě různé sítě.
Problémy se síťovou interakcí v2
Pokud se vzdáte dělení sítí, pak při rebalance provoz ceph zaplní celé spojení a vaše aplikace v kubernetes budou zpomalovat nebo zkolabují. Rychlost rebalance ceph lze snížit, ale pak za cenu dlouhé rebalancování získáte zvýšené riziko vypadnutí druhého uzlu z clusteru kvůli diskům nebo OOM, a pak už je zaručený read only na cluster.
Dlouhý rebalance — dlouhé zpomalení aplikací
Citát z příspěvku Ceph. Anatomie katastrofy.
Výkon testovacího clusteru:
Operace zápisu velikosti 4 Kbyte trvá 1 ms, výkon 1000 operací/sekundu v 1 vlákně.
Operace velikosti 4 Mbyte (velikosti objektu) trvá 22 ms, výkon 45 operací/sekundu.
Když tedy selže jedna z tří domén, cluster se nějakou dobu nachází ve degraduje stavu, a polovina aktivních objektů se rozptýlí po různých verzích, polovina zapisovacích operací začne s nuceným obnovením.
Čas nuceného obnovení odhadujeme přibližně — operace zápisu do degraduje objektu.
Nejprve čteme 4 MB za 22 ms, zapisujeme 22 ms, a poté 1 ms zapisujeme 4 KB vlastních dat. Celkem tedy 45 ms na jednu zápisovou operaci do degraduje objektu na SSD, když máme pracovní výkon 1 ms — pokles výkonu o 45násobek.
Čím vyšší je procento degraduje objektů, tím horší je situace.
Rychlost rebalance je tedy kriticky důležitá pro správnou funkci clusteru.
Specifická nastavení serverů pro Ceph
Pro Ceph může být potřeba specifické ladění hostitele.
Příklad: nastavení sysctl a stejné JumboFrame, některá z těchto nastavení mohou negativně ovlivnit váš přenos dat.
Skutečná potřeba Rook zůstává otázkou
Pokud jste v cloudu, máte úložiště od svého poskytovatele cloudu, což je mnohem pohodlnější.
Pokud máte své servery, bude správa Ceph pohodlnější bez Kubernetes.
Pronajímáte servery v nějakém low-cost hostingu? Pak vás čeká spousta zábavy sítěmi, jejich latencí a propustností, což zjevně negativně ovlivňuje Ceph.
Celkem: Implementace Kubernetes a implementace úložiště jsou různé úkoly s různými vstupy a různými možnostmi řešení — míchat je znamená udělat možná nebezpečný trade-off ve prospěch jednoho nebo druhého. Ucelit tato řešení bude velmi obtížné i v projektové fázi, a je tu ještě období provozu.
Seznam použité literatury:
A co říkáte na Ceph… je opravdu tak dobrý?
Ceph. Anatomie katastrofy
Zdroj: habr.com
