V súvislosti s rastúcou popularitou Rook sa chcem porozprávať o jeho skrytých problémoch a výzvach, ktoré na vás čakajú.
O sebe: Skúsenosti s administráciou Ceph od verzie Hammer, zakladateľ komunity na Telegrame.
Aby som nebol bez dôkazov, budem sa odvolávať na články z Habr, ktoré sa zaoberajú problémami s Ceph (podľa hodnotenia). S väčšinou týchto problémov som sa tiež stretol. Odkazy na použité materiály sú na konci článku.
V článku o Rooku spomíname Ceph nie náhodou — Rook je v podstate Ceph zabalený do Kubernetes, a preto zdedil všetky jeho problémy. Začneme problémami Ceph.
Zjednodušenie správy klastra
Jedným z výhod Rooku je pohodlné riadenie Ceph cez Kubernetes.
Ceph však obsahuje viac ako 1000 parametrov na konfiguráciu, z ktorých cez Rook môžeme upravovať len menšiu časť.
Príklad na Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook je pozicionovaný ako pohodlný spôsob inštalácie a aktualizácie Ceph.
S inštaláciou Ceph bez Rooku nie sú žiadne problémy — Ansible playbook sa napíše za 30 minút, ale s aktualizáciou sú veľké problémy.
Citát z článku Krok
Príklad: nesprávna funkcia Crush tunables po aktualizácii z Hammer na Jewel
> ceph osd crush show-tunables
{
…
«straw_calc_version»: 1,
«allowed_bucket_algs»: 22,
«profile»: «unknown»,
«optimal_tunables»: 0,
…
}
Ale aj v rámci menších verzií sa môžu vyskytnúť problémy.
Príklad: Aktualizácia 12.2.6 vedie klaster do stavu health err a podmienečne poškodený PG.
Neaktualizovať, čakať a testovať? Ale predsa len používame Rook predovšetkým kvôli pohodlnosti aktualizácií.
Zložitosti disaster recovery klastra v Rooku
Príklad: OSD zlyháva s chybami, ktoré sám vytvára. Podozrievate, že problém je v jednom z parametrov v konfigurácii, chcete zmeniť konfiguráciu pre konkrétny démon, ale nemôžete, pretože máte Kubernetes a DaemonSet.
Alternatívy nie sú. Ceph tell osd.Num injectargs nefunguje — OSD je predsa mimo prevádzky.
Zložitosti debugovania
Pre niektoré nastavenia a testy výkonu je potrebné sa pripojiť priamo k socketu démonu OSD. V prípade Rooku je najprv potrebné nájsť správny kontajner, potom sa doň dostať, objaviť chýbajúce debugovacie nástroje a veľmi sa sklamať.
Zložitosti sekvenčného spúšťania OSD
Príklad: OSD zlyháva pri OOM, začína rebalance, a potom zlyhávajú ďalšie.
Riešenie: Spustiť OSD jednotku po jednej, čakať na jej úplné pripojenie do klastru a potom spustiť nasledujúce. (Viac v správe Ceph. Anatomia katastrofy).
V prípade baremetal inštalácie sa to robí jednoducho manuálne, v prípade Rook a jednej OSD na uzol nie sú problémy, komplikácie so sekvenčným spúšťaním vzniknú, ak OSD > 1 na uzol.
Samozrejme, sú riešiteľné, ale veď prinášame Rook na zjednodušenie, a dostávame komplikácie.
Zložitosti pri nastavovaní limitov pre ceph démonov.
Pre baremetal inštaláciu ceph je dosť jednoduché vypočítať potrebné zdroje na klastru — existujú vzorce a štúdie. Pri použití slabých CPU aj tak budete musieť vykonať niekoľko testov výkonnosti, zistiť, čo je Numa, ale stále je to jednoduchšie ako v Rook.
V prípade Rook sa okrem limitov pamäte, ktoré sa dajú vypočítať, objaví otázka nastavenia limitu CPU.
A tu sa budete musieť potrápiť s testami výkonnosti. Pri nastavení nízkych limitov dostanete pomalý klaster, pri nastavení unlim dostanete aktívne využitie CPU pri rebalance, čo zle vplýva na vaše aplikácie v kubernetes.
Problémy so sieťovou interakciou v1.
Pre ceph sa odporúča používať 2x10gb sieť. Jednu pre klientsky traffic, druhú pre správne potreby ceph (rebalance). Ak žijete s ceph na baremetal, táto separácia sa ľahko nastavuje, ak žijete s Rook, separácia podľa sietí spôsobí problémy, pretože nie každý konfigurácia klastru umožňuje poskytnúť do podu dve rôzne siete.
Problémy so sieťovou interakciou v2.
Ak sa vzdáte separácie sietí, pri rebalance traffic ceph zaplní celý kanál a vaše aplikácie v kubernetes sa budú spomaliť alebo spadnú. Rýchlosť rebalance ceph sa dá znížiť, ale za cenu dlhšej doby rebalance zvýšite riziko výpadku druhého uzla z klastru kvôli diskom alebo OOM, a tam už je garantovaný iba read only na klaster.
Dlhý rebalance — dlhé spomalenia aplikácií.
Citát z príspevku Ceph. Anatomia katastrofy.
Výkon testovacieho klastru:
Operácia zápisu veľkosti 4 KByte trvá 1 ms, výkon 1000 operácií/sekundu v 1 vlákne.
Operácia veľkosti 4 MByte (veľkosť objektu) trvá 22 ms, výkon 45 operácií/sekundu.
Keď jeden z troch domén zlyhá, klaster je na istý čas v degradovanom stave, pričom polovica horúcich objektov sa rozšíri po rôznych verziách, takže polovica zápisových operácií sa začne núteným obnovením.
Čas núteného obnovenia odhadujeme približne — zápisové operácie na degradovaný objekt.
Najprv čítame 4 MB za 22 ms, zapisujeme 22 ms, a potom 1 ms zapisujeme 4 kB skutočných dát. Celkovo 45 ms na jednu zápisovú operáciu na degradovaný objekt na SSD, keď bežná výkon bola 1 ms — pokles výkonu o 45-násobok.
Čím väčší je percentuálny podiel degradovaných objektov, tým horšie sa to stáva.
Rýchlosť rebalancovania je kriticky dôležitá pre správnu funkciu klastra.
Špecifické nastavenia serverov pre ceph
ceph môže vyžadovať špecifické ladenie hostiteľa.
Príklad: nastavenia sysctl a JumboFrame, niektoré z týchto nastavení môžu negatívne ovplyvniť váš payload.
Skutočná potreba Rook zostáva otázna
Ak máte v cloude úložisko od vášho cloudového poskytovateľa, je to oveľa pohodlnejšie.
Ak ste na svojich serveroch, správa ceph bude jednoduchšia bez kubernetes.
Prenajímate si servery v nejakom low cost hostingu? Potom vás čaká mnoho zábavy so sieťou, jej oneskoreniami a šírkou pásma, čo jasne negatívne ovplyvňuje ceph.
Celkovo: Implementácia kuberentes a implementácia úložiska sú rôzne úlohy s rôznymi vstupmi a rôznymi možnosťami riešení — miešať ich znamená robiť potenciálne nebezpečný trade-off v prospech jedného alebo druhého. Spojiť tieto riešenia bude veľmi ťažké aj v etape projektovania, a je tu ešte obdobie prevádzky.
Zoznam použitej literatúry:
Hovoríte Ceph... je naozaj taký dobrý?
Ceph. Anatomia katastrofy
Zdroj: habr.com
