Keďže Rook získava na popularite, rád by som prediskutoval jeho úskalia a výzvy, s ktorými sa môžete počas cesty stretnúť.
O mne: Skúsenosti s administráciou Cephu od verzie Hammer, zakladateľ komunity v Telegrame.
Aby som sa vyhol neopodstatneným tvrdeniam, budem odkazovať na príspevky o problémoch s Ceph, ktoré Habr akceptoval (na základe ich hodnotení). S väčšinou problémov v týchto príspevkoch som sa stretol aj ja sám. Odkazy na použité materiály sú na konci príspevku.
V príspevku o Rookovi spomíname Ceph z nejakého dôvodu – Rook je v podstate Ceph zabalený v Kubernetes, čo znamená, že zdedí všetky jeho problémy. Začnime s problémami Cephu.
Zjednodušenie správy klastrov
Jednou z výhod Rooku je pohodlie správy ceph cez kubernetes.
Ceph však obsahuje viac ako 1000 parametrov na konfiguráciu, zatiaľ čo cez rook môžeme upravovať iba malú časť z nich.
Príklad na Luminous
> zobraziť konfiguráciu démona ceph mon.a | wc -l
1401
Rook je umiestnený ako pohodlný spôsob inštalácie a aktualizácie Cephu.
Inštalácia Cephu bez Rooku nie je problém – Ansible playbook sa dá napísať za 30 minút – ale aktualizácia je poriadna komplikácia.
Citát z Krokovho príspevku
Príklad: Laditeľné prvky Crush nefungujú správne po upgrade z Hummeru na Jewel.
> ceph osd crush laditeľné zobrazenia
{
...
„verzia_straw_calc“: 1,
„povolené_algoritmy_vedra“: 22,
„profil“: „neznámy“,
„optimálne_laditeľné“: 0,
...
}
Ale aj v rámci menších verzií sa vyskytujú problémy.
Príklad: Aktualizácia 12.2.6 prevedie klaster do stavu „health err“ a podmienečne poškodeného PG.
Neaktualizovať, čakať a testovať? Ale myslím si, že Rook používame okrem iného aj kvôli pohodliu aktualizácií.
Zložitosť obnovy po havárii v Rook
Príklad: OSD padá a vyhadzuje chyby. Máte podozrenie, že problém je v jednom z konfiguračných parametrov a chcete zmeniť konfiguráciu pre konkrétneho démona, ale nemôžete, pretože používate Kubernetes a DaemonSet.
Neexistuje žiadna alternatíva. ceph tell osd.Num injectargs nefunguje – OSD je nefunkčné.
Zložitosť ladenia
Niektoré nastavenia a výkonnostné testy vyžadujú priame pripojenie k socketu démona OSD. S Rookom musíte najprv nájsť správny kontajner, potom sa doň prihlásiť, objaviť chýbajúce ladiace nástroje a byť veľmi frustrovaní.
Ťažkosti s konzistentným zvyšovaním OSD
Príklad: OSD klesá kvôli OOM, začína sa rebalancia, po ktorej klesajú nasledujúce.
Riešenie: Postupne spúšťajte OSD, počkajte, kým nebudú úplne integrované do klastra, a potom spúšťajte ďalšie. (Ďalšie podrobnosti nájdete v správe Ceph: Anatómia katastrofy.)
V prípade inštalácie bez použitia hardvéru sa to robí jednoducho manuálne; v prípade Rook a jedného OSD na uzol nie sú žiadne zvláštne problémy; problémy so sekvenčným zvyšovaním nastanú, ak je OSD > 1 na uzol.
Samozrejme, sú riešiteľné, ale pre zjednodušenie použijeme Rooka a dostaneme zložitosť.
Ťažkosti s výberom limitov pre démonov Ceph
Pre inštaláciu Ceph bez použitia operačného systému je pomerne jednoduché vypočítať požadované zdroje na klaster – existujú vzorce a štúdie. Ak používate slabé procesory, budete musieť spustiť sériu výkonnostných testov a naučiť sa niečo o Nume, ale stále je to jednoduchšie ako s Rookom.
V prípade Rook, okrem limitov pamäte, ktoré je možné vypočítať, čelíte aj otázke nastavenia limitu CPU.
A tu budete musieť tvrdo pracovať s testovaním výkonu. Ak znížite limity, získate pomalý klaster; ak nastavíte neobmedzené, počas vyvažovania uvidíte vysoké využitie CPU, čo negatívne ovplyvní vaše aplikácie Kubernetes.
Problémy so sieťou v1
Pre Ceph sa odporúča používať dve 10Gb siete. Jednu pre klientsku prevádzku, druhú pre potreby služieb Ceph (vyvažovanie). Ak používate Ceph na baremetale, toto oddelenie sa dá ľahko nakonfigurovať. Ak používate Rook, oddelenie sietí bude problematické, pretože nie každá konfigurácia klastra umožňuje obsluhovať dve rôzne siete v jednom pode.
Problémy so sieťou v2
Ak odmietnete oddeliť siete, prevádzka Ceph počas vyvažovania zahltí celý kanál a vaše aplikácie Kubernetes sa spomalia alebo dokonca zrútia. Môžete znížiť rýchlosť vyvažovania Ceph, ale potom kvôli dlhému času vyvažovania riskujete, že druhý uzol bude z klastra vyradený kvôli problémom s diskom alebo OOM, čo zaručuje prevádzku klastra iba na čítanie.
Dlhé vyvažovanie znamená dlhé spomalenia aplikácií
Citát z Cephovho príspevku: Anatómia katastrofy.
Výkon testovacieho klastra:
Operácia zápisu 4 KB trvá 1 ms s priepustnosťou 1 000 operácií za sekundu v 1 vlákne.
Operácia s veľkosťou 4 MB (objekt) trvá 22 ms, výkon je 45 operácií/sekundu.
Preto, keď zlyhá jedna z troch domén, klaster je nejaký čas v degradovanom stave a polovica horúcich objektov je rozptýlená medzi rôznymi verziami, potom polovica operácií zápisu začne s vynútenou obnovou.
Čas vynútenej obnovy vypočítame približne ako počet operácií zápisu do degradovaného objektu.
Najprv sme prečítali 4 MB za 22 ms, zapisali 22 ms a potom sme zapísali 4 KB skutočných dát za 1 ms. Výsledkom je celkovo 45 ms pre jednu operáciu zápisu na degradovaný SSD objekt v porovnaní s naším štandardným výkonom 1 ms – čo je 45-násobný pokles výkonu.
Čím vyššie percento degradovaných objektov máme, tým desivejšie sa všetko stáva.
Ukazuje sa, že rýchlosť vyvažovania je kritická pre správnu prevádzku klastra.
Nastavenia špecifické pre server pre Ceph
Ceph niekedy vyžaduje špecifické ladenie hostiteľa.
Príklad: nastavenia sysctl a rovnaký JumboFrame, niektoré z týchto nastavení môžu negatívne ovplyvniť vaše užitočné zaťaženie.
Skutočná potreba Rooka zostáva otázna
Ak ste v cloude, máte úložisko od svojho poskytovateľa cloudových služieb, čo je oveľa pohodlnejšie.
Ak prevádzkujete vlastné servery, správa Ceph bude jednoduchšia bez Kubernetes.
Prenajímate si servery od lacného poskytovateľa hostingu? Potom budete čeliť mnohým problémom so sieťou vrátane latencie a šírky pásma, čo jednoznačne negatívne ovplyvňuje Ceph.
Celkom: Implementácia Kubernetes a implementácia úložiska sú odlišné úlohy s rôznymi vstupmi a rôznymi možnosťami riešenia. Ich kombinovanie by bolo potenciálne nebezpečným kompromisom v prospech jedného alebo druhého. Kombinovanie týchto riešení bude veľmi ťažké už vo fáze návrhu a existuje aj prevádzková fáza.
Zoznam použitej literatúry:
Ale hovoríš, Ceph... je to naozaj také dobré?
Ceph. Anatómia katastrofy
Zdroj: hab.com
