ceph benchmarking @ SoftLayer

nem lehet eleg koran kezdeni felkeszulni az aprilisi eloadasunkra, igy a hardwaret meg is rendeltuk SoftLayeren.

a sorozatban megnezzuk mit lehet kihozni 576TB (0.576PB)-nyi diszkbol (es 46TB-nyi flashbol).. de el fog tartani egy darabig, az biztos.

a konkret HW, ami rendelkezres all (x6):
- 2xE5-2650v3 (ez fizikailag 20, HT-vel 40 mag)
- 64GB memoria
- 2x10Gbit public, 2x10Gbit private network (egyik a kliens halozat, a masik a replikacios lesz)
- 24x4TB WD RE
- 8x960GB SanDisk CloudSpeed 1000 SSD
- LSI 9361-8i (12Gbit/s SAS RAID vezerlo 1GB flash-el)

a clustert lehet felbovitjuk kesobb x12-re, de 6 gep is eleg a kezdeshez. a mereseket CentOS 7 illetve Ubuntu 14.04 alatt is el fogjuk vegezni.

a kovetkezo kerdesekre keressuk a valaszt:
- hogy alakult a ceph teljesitmenye a kulonbozo releaseket nezve? (firefly->giant->hammer)
- ki lehet-e valtani az SSD journalt 100% write cache melletti egydiszkes RAID0-aba rakott diszkekkel?
- a mostani cache pool implementacio mennyire jo?
- 3 -> 4 -> 5 -> 6 gepnel hogy skalazodik a teljesitmeny?
- TPC DB2-vel, illetve sysbench perconas MySQL-el meres varhato kulon gepen futo VM-ekben, amik ide csatlakoznak majd

azt nem garantalom, hogy minden blogpost meg fog jelenni magyarul is, ugyanis eleg nagy nyomas van rajtam/unk, hogy a hivatalos IBM-es cloud blogba irogassunk ezekrol, hiszen az uj termekunk (IBM Cloud OpenStack Services) alatt is altalunk tervezett ceph storage fut; viszont ide sokkal konnyebb barmilyen blogot irni, mint oda :)

plusz ha valakinek van kerdese/otlete, hogy milyen merest latna szivesen, ne tartsa magaban!

( asm v | 2015. 01. 10., szo – 20:52 )

a GPFS-t miert vetettetek el? Allitolag az is mukodik (tamogatott?) OpenStack alatt...

mukodik, viszont az en csapatom konkret szakterulete a ceph - probaljuk betolni minel tobb IBM-es termekekbe :)

a GPFS regota jelen van, sokat benchmarkoltak mar, ezzel szemben a ceph egy feltorekvo, uj technologia, amit ceges szinten tamogatnunk kell, legalabbis ez a velemenyem. szerencsere sokan gondoljak ugyanezt.

( Elbandi v | 2015. 01. 10., szo – 21:59 )

csak vm-ek ala hasznalod poolnak vagy mds-t is hasznalod?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( sibike | 2015. 01. 11., v – 07:45 )

Az angol nyelvű blogbejegyzéseket elég ha belinkeled, ha nincs időtök lefordítani.

( bra | 2015. 01. 11., v – 21:44 )

Sosem volt időm megmerni:
Ha csak egyszer írt (immutable, például videók, képek, emailek stb) objektumokat akarok tárolni, és az adott hardverrel a legoptimalisabban kiszolgalni,
- mekkora overheadje van a cephnek a nyers adathoz képest, azaz az 1 tb-om hány ceph tb? (a redundanciat ertelemszeruen ne számoljuk ide)
- ha azt feltételezzuk, hogy minden objektumnak van egy egyedi azonositoja (kv store), akkor a sima fajlrendszerhez (pld zfs) képest mennyi az iops igény irasnal, olvasasnal?
--
zsebHUP-ot használok!

Vicces. TFH egy átlagos levélméret 120k, és van 500 TiB levelünk.
Ha három helyre akarom replikálni az ugye 1,5PiB, plusz ezen az overhead (500*1024^4/(120*1024))*6000*3/1024^4=73,2 TiB, azaz a nyers adatnak a 14%-a.
Ha pedig erasure coding van, ha jól gondolom ez minden OSD-n jelentkezik, azaz ha mondjuk 10 OSD-re szórod szét az adatot (nem tudom ez mennyire életképes), akkor 244 TiB.
Jól számolok?
--
zsebHUP-ot használok!

elkovettem azt a hibat, hogy nem osztottam le a replikacios faktorral az en esetemben; ujramertem kulonbozo replikaciok mellett, es 2000 byte a helyes, raw ertek - en 3xos replikacio mellett kaptam az eredeti 6000-et.

tehat annyival pontositanam az elozo postomat, hogy minden, nem replikalt, legfeljebb 4MB-os chunkonknet rajon 2000 byte.

az atlag 120k-val az a problema, hogy amig egy 120k-s levelre tenyleg ra fog jonni a 2000 byte, egy 5 megas levelre mar 4000 jon ra, stb. meg kene nezni a szorast es az eloszlast is, hogy pontosabban lehessen tippelni :)

ha konkretan 500TB-nyi 120k-s adatod van, akkor a szamolas helyes, annyi kulonbseggel, hogy nem 6000-et, hanem 2000-et kell beirni, es igy 24.414TiB jon ki, ami ~4.88%

--

a VM-eknel erdekesebb kerdes az overhead (tudom, hogy nem csatlakozik szorosan a kerdeshez), ugyanis az RBD reteg szerintem pontosan 4MB-os RADOS objektumokat fog foglalni alul, igy ott lesz a legkisebb az overhead.

az erasure code resszel nem jatszottam meg eleget, hogy biztos valaszokat tudjak adni; folyamatban van. :)

szerintunk a placement group metainformacioibol, de erdemes lenne megnezni mas fajlrendszerek alatt is (en a default, xfs-en neztem). plusz erdekes lenne megnezni, hogy mi van, ha nem fajlrendszert rakunk ala, hanem mondjuk LevelDB-t (a store backend cserelheto a legujabb verziokban, igy nem csak fajlrendszer lehet az OSD alatt).

Egyelőre kicsit olyan érzésem van, hogy ennyi erővel objektumonként is eltárolhatnám akár, hogy hol van az objektum (2k-ba bőven belefér, sőt, még sokkal több minden, pld. counterek), így sokkal flexibilisebb kiosztást lehetne csinálni.
Egyedül vagyok ezzel? :)
--
zsebHUP-ot használok!

ez segitene abban, hogy be tudd olvasni (lenyegeben mint most a pgmap + osdmap + monmap + CRUSH), viszont maga a rendszerallapotot is el kell osztani a nodeok kozott - szerintem ez viszi el a legtobb extrat.

fogok csinalni par tesztet, ahol megnezem, hogy ha egy PG-re esik ket objektum, akkor a metaadat ott mennyivel no pontosan, de egyelore van mas, amit mernem kell... :)

a ceph Teged csak, mint object store erdekel? mert szerintem VM-eknel mar teljesen mas a tortenet.

A ceph engem egyáltalán nem érdekel, mert tele van linuxismmel. :)
Najó, annyira nagyon még talán nincs, egy valamelyest működő verziót sikerült portolnom egy délután alatt.

Az sem tetszik, hogy ennyire rámentek az egy admin gép, és onnan egy parancs húz fel/állít be mindent témára. Nálunk ez úgy működik, hogy ha valamiből sok van, indítok még, nem kell semmit sem telepíteni, konfigurálni...

Igen, amúgy elsősorban object store-ként.
--
zsebHUP-ot használok!

Te milyen storaget raknal sok-sok VM ala, ami hasonlo tudasu, mint a ceph, ha nem cephet? :)

az admin node annyira nem lenyeg, nalam pl a monitorok toltik be ezt a szerepet is. az automatikus bovites meg puppettel/cheffel/mindenki kedvencevel megoldhato, nem? azt muszaj elmagyaraznod barmilyen rendszer eseten is a rendszernek, hogy milyen diszkeket ehet meg a gepbol - ha ezt erted konfiguracio alatt

Fogalmam sincs, nem gondolkoztam rajta, mivel nekem más igényeim vannak. Most kell kitalálnom? :)

A kész megoldások közül vsz. a ceph a legjobb, de nem tartom kizártnak, hogy a te konkrét igényedre jobbat is lehetne csinálni.

Nem a külön admin node-dal van bajom, hanem azzal, hogy azt kibogozni, reprodukálni, amit a basztató scriptjük csinál nem egyszerű (de lehet, hogy bennem van a hiba), mivel az nálam nem működik (nem linux, meg amúgyis read only minden), ezért mindent kézzel kell csinálni, az meg sehol sincs dokumentálva.
--
zsebHUP-ot használok!

( bra | 2015. 01. 11., v – 21:49 )

Plusz érdekelne, hogy mi szól meg a diszkek mellett. A cephben van már erasure coding, amivel pld tudsz mondjuk 64+8 (a hasamra ütöttem) redundanciat csinálni, és ha azt vesszük, hogy az ssdnek kb két nagysagrenddel nagyobb az io képessége, teljesítményben elvileg vered a hdd-ket, és lehet, hogy azonos aron.
Kérdezem ezt úgy, hogy sosem próbáltam, lehet, hogy halva született ötlet, pld CPU, network, vagy a nagyon apró diszk io-k miatt.
--
zsebHUP-ot használok!

ezt kifejtened kicsit?

a problema az, hogy $/TB-ban az SSDk sehol sincsenek meg mindig a HDD-khez kepest. ha jol ertem, fent azt mondod, hogy a 3x-osan replikalt HDD-kkel felvehetne a versenyt egy erasure coded SSD rendszer IOPS-ban? ez szerintem megallna a helyet, viszont a $/TB meg mindig magas lenne, viszont megerne egy szamolast; felirom a merendok koze :)

a masik problema az, hogy erasure coded poolokra nem lehet VM-eket rakni, mert nincs reszleges iras, igy nagyon koltseges lenne; erre azt talaltak ki, hogy raknak egy replikalt poolt ele, ahol a teljes rbd szemantika mukodik.

Igen, valami ilyesmit. Nyilván az egész attól függ, hogy milyen diszket veszel, honnan, és mibe teszed, ugyanez az SSD-kkel.
Pld. a brand gépek (mondjuk HP) esetén egy Supermicróba dugott, a "sarki boltban" megvett SSD-nél már kijön a matek, főleg, ha beleszámolod, hogy 500 db diszk pörgetése évente kb. 10-12M forintba kerül (áram, hűtés), míg kétszer annyi SSD-nél ez kb. a tizede, azaz évi 9-10 milliót nyersz, öt évre levetítve ez már elég komoly mennyiség.
Persze ha a diszkeknél is hasonló körülmények vannak (azaz kb. feleannyiért veszed őket), akkor már kevésbé vonzó. 2-3 éven belül viszont az lesz.

Egy copy on write fs-nél ez gond?
--
zsebHUP-ot használok!

eljatszok vele picit, es jelentkezem. Softlayer teljesen Supermicro, "sarki boltban megvett" SSD-kkel (Sandisk CloudSpeed) es HDD-kkel (van HGST, WD, Seagate, minden).

mint "ugyfel" a Softlayeren a hutes illetve az aram mar benne van a havidijban, igy ezek koltseget nem tudom leamortizalni az SSD-s felarakon idovel, mivel ket kulon zsebbol megy :(

a CoW FS dolgot nem ertem - CephFS-re gondolsz? fogalmam sincs a CephFS-rol egyelore, ugyanis nem production ready, maximum jatszani jo; allitolag a kovetkezo honapokban mar lehet ra supportot venni, de meg nem.

a qemu tud nativ rbd-t a diszkekre, igy altalaban RBD -> RADOS a felallas; erre irtam fent, hogy az RBD lehet, hogy teljes 4MB-os RADOS objektumokat allokal alulra, es igy minimalis az overhead.

Nem, arra gondolok, hogy az általad felvetett problémára (ha jól értettem), mely szerint az erasure coding eléggé hazavágná a teljesítményt, mivel írásnál olvasni is kellene (újraszámolni a blokkot) megoldás lehet egy COW FS, amennyiben az mindig az erasure coded blokkméretet, vagy annak többszörösét írja.
Ilyenkor nem kell beolvasni semmit (legalábbis a ceph szintjén).
--
zsebHUP-ot használok!

( csardij v | 2017. 01. 19., cs – 19:08 )

Helló,

Lett publikálva valahol ez a teszt?

ha storageot epitunk, rendesen kell csinalni, hiszen a storage problema _MINDENT_ erint. hidd el, a legeslegelso dolog amire gondol az ember, ha futtatsz egy belso felhot, es jonnek a felhasznalok hogy "lassu" az az, hogy rosszul lett megepitve a cluster.

a szart pontosan lehet definialni: mekkora az irasi latencyd? (a journal pontosan ezt fogja meghatarozni!); jo-e a feladathoz? sima object storera, ahol mindegy a teljesitmeny, nincsenek latency igenyek, oda tokeletes 10 desktoppc gigabiten.

de hidd el, mar nagyon sok ember nagyon sok ceph clusteret lemeoztam, es sok helyen a szarral gurigalas megy. levetett gepek, nincs eleg memoria, nincs rendes halozat, aztan amikor elkezdik hasznalni akkor meg megy a nyunnyoges, hogy "jajj miert ilyen, azthittem ez a ceph sokkal jobb, mekkora hazugsag!!!"
ezert fontos, hogy az igenyeket osszeegyeztesse az ember a realitassal.

lattam mar annyi ceph clustert, hogy nem el tudom donteni, hogy jol van-e megepitve. ha leirod, hogy mibol akartok epitkezni, akkor elmondom, hogy szerintem jo lesz-e. nem a "mas"-sal van a baj, hanem a szarbol varattal ami sok helyen van - de ahogy irtam, az igenyeket kell osszemerni a lehetosegekkel.

felesleges 50 millioval dobalozni, mert van ahova ez sok penz, es van ahol pedig csak a diszkek nem jonnek ki ennyibol - peldaul egy 1.8-3PB RAW clusterbe csak a diszkek nagyjabol 35M HUF (400$/diszkkel szamoltam, ennel van aki olcsobban, van, aki dragan veszi a diszkeket [6/8/10TB])

Hohohoh. Szó sincs itt gigabitről, meg desktop pc-ről.

Sima sata diskzed ha van, a journaling iras (meg amúgy is) miatt lofaszjoska teljesítményt nem kapsz, mert a sata disk randomba szar, ami várható. A kérdésem pont arra irányult, hogy mivel a raid kártya cache ezt kiegyenesíti, már nem teljesen randomba kapják a kiírandó adatot a hdd-k, mekkora a különbség úgy ahhoz képest amikor nincs raid kártya, de ssd-n van a journal?

A nyitó bejegyzésben ugye fel lett sorolva, hogy ezt leméritek majd, erre kérdeztem, hogy ez le lett, vagy sem.

nem lett lemerve, mert az akkori raid kartya cachek 1-2GBok voltak - mostmar vannak sokkal nagyobb flash alapu cachek is, amik nyilvan jobban tudjak ezt kezelni. az SSD eletkepesebb megoldas volt akkor, es szerintem most is az.

fogd a raid cache meretet - legyen 2GB -, tegyuk fel, hogy 100% write cachenek konfizod, majd vegyuk azt, hogy mennyi az atlagos iras per gep. ha belefersz ugy, hogy lesz idod destagelni, akkor jo lehet. de az SSD-t ujra lehet hasznalni mondjuk bcache/Intel CAS-ra is, es akkor mar van egy read cached is.