U vezi sa rastućom popularnošću Rooka, želio bih govoriti o njegovim zamkama i problemima koji vas čekaju na tom putu.
O meni: Iskustvo u administraciji ceph-a iz hammer verzije, osnivač zajednice u telegramu.
Da ne bih bio neosnovan, osvrnuću se na postove koje prihvata Habr (sudeći po rejtingu) o problemima sa ceph-om. Također sam naišao na većinu problema u ovim objavama. Linkovi do korišćenog materijala nalaze se na kraju posta.
U postu o Rooku spominjemo ceph s razlogom - Rook je u suštini ceph umotan u kubernetes, što znači da nasljeđuje sve svoje probleme. Počnimo sa ceph problemima.
Pojednostavite upravljanje klasterima
Jedna od prednosti Rooka je lakoća upravljanja ceph-om kroz kuberentes.
Međutim, ceph sadrži više od 1000 parametara za konfiguraciju, dok u isto vrijeme, preko topa možemo urediti samo manji dio njih.
Primjer na Luminous
> ceph daemon mon.a config show | wc -l
1401
Rook je pozicioniran kao zgodan način za instaliranje i ažuriranje ceph-a
Nema problema sa instaliranjem ceph-a bez Rooka - ansible playbook se napiše za 30 minuta, ali ima dosta problema sa ažuriranjem.
Citat iz Krokove objave
Primjer: crush tunables ne radi ispravno nakon ažuriranja sa hummer na dragulj
> ceph osd crush show-tunables
{
...
"straw_calc_version": 1,
"allowed_bucket_algs": 22,
"profil": "nepoznat",
"optimal_tunables": 0,
...
}
Ali čak i unutar manjih verzija postoje problemi.
Primjer: Ažuriranje 12.2.6 dovodi klaster u stanje zdravstvene greške i uslovno pokvaren PG
Ne ažurirati, čekati i testirati? Ali čini se da koristimo Rook za praktičnost ažuriranja, između ostalog.
Složenost klastera za oporavak od katastrofe u Rooku
Primer: OSD pada sa osipom grešaka u nogama. Sumnjate da je problem u jednom od parametara u konfiguraciji, želite promijeniti konfiguraciju za određeni demon, ali ne možete jer imate kubernetes i DaemonSet.
Nema alternative. ceph tell osd.Num injectargs ne radi - OSD laže.
Difficulty debug
Neka podešavanja i testovi performansi zahtevaju direktno povezivanje na osd socket demona. U slučaju Rooka, prvo morate pronaći željeni kontejner, zatim ući u njega, pronaći alat koji nedostaje za otklanjanje grešaka i biti jako uznemiren.
Poteškoće s uzastopnim podizanjem OSD-a
Primjer: OSD pada u OOM, počinje rebalans, nakon čega padaju sljedeći.
Rješenje: Podignite OSD jedan po jedan, pričekajte dok se potpuno ne uključi u klaster i podignite sljedeće. (Više detalja u izvještaju Ceph. Anatomija katastrofe).
U slučaju baremmetalne instalacije, to se radi jednostavno ručno; u slučaju topa i jednog OSD-a po čvoru, nema posebnih problema; problemi s naizmjeničnim podizanjem će se pojaviti ako je OSD > 1 po čvoru.
Naravno, oni se mogu riješiti, ali mi koristimo Rook da pojednostavimo stvari, ali dobijemo veću složenost.
Poteškoće u odabiru granica za ceph demone
Za baremetalnu instalaciju ceph-a, prilično je lako izračunati potrebne resurse za klaster - postoje formule i dostupna su istraživanja. Ako koristite slab CPU, i dalje ćete morati da izvršite neke testove performansi da saznate šta je Numa, ali je i dalje lakše od Rook-a.
U slučaju Rooka, pored ograničenja memorije koja se mogu izračunati, imate pitanje postavljanja ograničenja CPU-a.
I ovdje ćete morati naporno raditi sa testovima performansi. Ako snizite granice, dobićete spor klaster; ako postavite unlim, dobićete aktivnu upotrebu CPU-a tokom rebalansiranja, što će loše uticati na vaše aplikacije u kubernetesu.
Problemi s umrežavanjem v1
Za ceph se preporučuje korištenje mreže veličine 2x10GB. Jedan za klijentski promet, drugi za potrebe ceph servisa (rebalans). Ako živite sa ceph-om na baremetal-u, onda se ova podjela lako konfiguriše, ako živite sa Rookom, onda će vam podjela po mrežama stvarati probleme, zbog činjenice da vam svaka konfiguracija klastera ne dozvoljava da dvije različite mreže napajate pod .
Problemi s umrežavanjem v2
Ako odbijete da odvojite mreže, onda će prilikom ponovnog balansiranja ceph saobraćaj začepiti cijeli kanal i vaše aplikacije u kubernetes-u će se usporiti ili srušiti. Možete smanjiti brzinu rebalansiranja ceph-a, ali tada zbog dugog rebalansa dobijate povećan rizik da drugi čvor ispadne iz klastera preko diskova ili OOM-a, a već postoji zagarantovano čitanje samo za klaster.
Dugačak rebalans - dugi zastoji u aplikaciji
Citat iz Cephove objave. Anatomija katastrofe.
Testirajte performanse klastera:
Operacija pisanja veličine 4 KB traje 1 ms, performanse su 1000 operacija/sekundi u 1 niti.
Operacija od 4 MB (veličina objekta) traje 22 ms, performanse su 45 operacija/sekundi.
Posljedično, kada jedan od tri domena pokvari, klaster je neko vrijeme u degradiranom stanju, a polovina vrućih objekata se distribuira na različite verzije, tada će polovina operacija pisanja početi prinudnim oporavkom.
Približno izračunavamo vrijeme prisilnog oporavka - operacije upisivanja na degradirani objekt.
Prvo čitamo 4 MB za 22 ms, upisujemo 22 ms, a zatim za 1 ms upisujemo 4 KB stvarnih podataka. Ukupno 45 ms po operaciji pisanja na degradirani objekt na SSD-u, kada je standardna izvedba bila 1 ms - 45-struki pad performansi.
Što je veći procenat degradiranih objekata, sve postaje gore.
Ispostavilo se da je brzina rebalansiranja kritična za ispravan rad klastera.
Specifične postavke servera za ceph
ceph može zahtijevati specifično podešavanje hosta.
Primjer: sysctl postavke i isti JumboFrame, neke od ovih postavki mogu negativno utjecati na vaše opterećenje.
Prava potreba za Topom ostaje pod znakom pitanja
Ako ste u oblaku, imate pohranu od svog dobavljača usluga u oblaku, što je mnogo praktičnije.
Ako ste na svojim serverima, onda će upravljanje ceph-om biti praktičnije bez kubernetesa.
Da li iznajmljujete servere od nekog jeftinog hostinga? Tada ćete se jako zabaviti sa mrežom, njenim kašnjenjima i propusnim opsegom, što jasno negativno utiče na ceph.
Ukupno: Implementacija kuberentes-a i implementacija skladištenja su različiti zadaci sa različitim ulazima i različitim opcijama rješenja - njihovo miješanje znači napraviti potencijalno opasan kompromis za dobrobit jednog ili drugog. Biće veoma teško kombinovati ova rešenja čak iu fazi projektovanja, a još uvek postoji period rada.
Lista korištene literature:
Ali kažeš Ceph... da li je stvarno tako dobar?
Ceph. Anatomija katastrofe
izvor: www.habr.com
