hyperwarp: uj storage a lathataron

a melohely approveolta hogy open sourceba toljuk teljesen az uj projektemet. egyelore a tervasztalon van, de gondoltam irok rola par szot.

szigoruan a sajat velemenyem kovetkezik ezek utan

--

elosszor is jo erzes, hogy az ember foallasa reszekent csinalhat ilyet, teljes szabadsag mellett. kellett mar nekem ez, hogy ne csak a belso ceges dolgokat csinaljuk, hanem nyissunk kicsit kifele, es en is reszese lehessek ennek.

regota uzemeltetunk a csapattal relative nagy storage rendszereket (PB+), es az elmult 10 evben volt itt minden mint a jo boltban: GlusterFS, Ceph, GPFS, ZFS-bol takolt egy gepes megoldas, van VMware vSANunk, mdraid + NFS, ... szoval azt mondanam, eleg sok mindent kiprobaltunk.

az utolso csepp a poharban amikor azt mondtam hogy nevetseges ez az egesz jelenlegi helyzet az az volt, amikor egy 500 NVMe driveos, 2x100Gbit/szerveres clustert teszteltunk, es a raw teljesitmeny 95%-a eluszott "valahol a stackben". nem, nem allok be a hajbi fele hozongok fele, a kollegaim mar publikaltak tobb papert arrol, hogy a mostani stackek nagyon dragak, inditottak is egy apache projektet, viszont latszolag ez nem mozog semerre, plusz ugyan technologiailag top notch, nem az az irany, amit en szeretnek.

 

ket fo problemat latok jelenleg az open source storage megoldasok kozul:
- egyik sem arra van kihegyezve, hogy kihajtsa a nyers teljesitmeny 100%-at: elismerem, lehet niche, de nekem nagyon zavarja a csorom amikor berakom a baromi draga optanet, aztan kijon belole 5%.
- bloatware az egesz, es a rossz fajtabol: telerakjak olyan ficsorokkel aminek semmi helye egy storage rendszerben, szigoruan nezve. hello Ceph, hello mindent rakjunk kontenerbe, kiraz a hideg. a cephadm, ami az octopustol a hivatalosan tamogatott deploy tool csak olyan 5-6 ezer sor python, egy fajlban...

 

ugyhogy ugy dontottunk, csinalunk egy uj rendszert, a kovetkezo feltetelezesekkel/dontesekkel:
- a meghajtoid mar a halozaton vannak es beszelnek NVMeoF-et, remelhetoleg RDMA-val, de ha TCPvel, az sem baj (de nyilvan az elvarasokat ehhez merten kell megtenni): vannak mar HW dobozok ahol bedugod az NVMe meghajtot es csak halozat jon ki hatul
- a fabric sebessege sokkal gyorsabb mint az adattaroloid sebessege (pelda kedveert van, ahol 29x lassabb az NVMe diszk mint egy 100GbE fabric, irasnal mar csak van ahol 12x)
- vannak WAL eszkozeid (ZFS-es terminologiaval: ZIL), szinten a halozaton szetszorva: amugy nagyon draga az EC-s read-modify-write ciklus
- a metadatat kitoljuk valami kulso DB-be, nem fogunk szivni vele: nezd meg mi tortent a cephnel, a ceph-monok addig nottek es bonyolodtak, amig egyszercsak be kellett vezetni a ceph-mgrt is
- nem fogunk fajlrendszert adni, arra mar van ezer megoldas ha neked elosztott FS kell egy elosztott blokkeszkoz felett
- CAP-bol CP mint Ceph

a dolog egyelore ott tart, hogy mikrobenchmarkokat irogatunk, es majd ezek eredmenyeit szeretnenk kitolni jovore par konferenciara (meg persze github blog postra), szoval meg messze van az, hogy barki tesztelhesse.

Hozzászólások

bocs ha kicsit off: mit ajánlanál több millió pdf tárolására redundánsan, több gépen elérhetően, lehetőleg valami egységes protokollal (s3?)

alapvetően egyszer írós, ritkán olvasós adatok, de néha teljes beolvasás szükséges, így a felhős megoldások kiesnek

tömörítés előny lehet, mivel 5-6TB nyersen, 3TB tömörítve

köszönöm!

Szerkesztve: 2020. 08. 21., p – 11:05

NVMeoF nagyon jo amikor egy cel es egy forras van, (iSer is elbujhat) .
Nem tudom hol rontjak el manpsag a nepszeru  'distributed and parallel' megoldasok,
de altalaban nem tcp -a fo gond (lehetne, mert RDMA ~20 szor jobb valasz idoket mutat nalam) ,
de a software tcp- re foghato ido elenyeszo a tenyleges lassusaghoz kepest.

Tobb 'NVMe namespaces ' tamogatasa fog -e kelleni hozza, vagy akkarmilye nvme jo lesz ?
(legtobb nvme nem tudja, az otthoni felhasznaloknak szantak szinte soha sem tudjak )

Nem lepodnek meg, ha nic-ek elobb utobb eleg okosak legyenek ahhoz,
hogy maguk   "raidlejenek" ossze tobb NVMeoF forrast .
A sebbesseg aranyok masok ,
szoval nem feltetlen akkarod 5000 forrasbol behuzni az egy volumot.
 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

a TCP is jo lehetne, a folotte levo stackben rontjak el azzal, hogy iszonyat sok dolgot belenyomnak, ami teljesen felesleges.

NVMe nem spacek nem fognak kelleni, a teljes logical volume management a mi kodunkban van

mar eleg okosak:), teszteltem ilyen megoldast, meg most is beszeltunk par gyartoval a 2022-es NVMeoF cuccokkal kapcsolatban (sajnos minden NDA alatt van)

 

mit ertesz az utolso mondatod alatt? miert ne akarnam behuzni 5000 forrasbol? ha 5000bol nem, mennyibol akarom? 200? 500? 50?

Nem kell 5000 egy kis 100GB volumhoz.., mert ~32  vel mar eleg jo a troughtput,
5000 forrast kezelni nyilvan maceransabb is, eleg kivalsztani kevesebbet a meglevo forrasokboll es tartani kivant rendundanciat.
Ha  maga volume joval nagyobb (>>64TB) nyilvan tobbnek is lesz ertelme ..

birthday paradox is felmerul, de a legtobb megoldasnal nem olyan veszes.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

" - bloatware az egesz, es a rossz fajtabol: telerakjak olyan ficsorokkel aminek semmi helye egy storage rendszerben, szigoruan nezve. hello Ceph, hello mindent rakjunk kontenerbe, kiraz a hideg. a cephadm, ami az octopustol a hivatalosan tamogatott deploy tool csak olyan 5-6 ezer sor python, egy fajlban... "

Ezt teljesen átérzem. Amikor "mindennek is" benne kell lennie valamiben, minden új feature és it hipszter dolognak szerepelnie kell a listában, csak azért mert éppen trendi. Az, hogy egy évek óta kerülgetett bug-ot javítsanak, netalántán ?optimalizálni? egy kicsit a meglévő kódbázist, soha nem fog megtörténni mert fontosabb, hogy a webgui (aminek megszületnie se kellett volna) bootstrap 5 legyen. Nem gond hogy alpha és két hete jelent meg, de a bootstrap 4 már milyen elavult és "nem is trendi".

btw.: sok sikert a projekthez

// Happy debugging, suckers
#define true (rand() > 10)

a kedvencem a CRUSH. Sage kitalalta, hudeszuper, kurvajo, phd lett belole (ott kellett volna megallni vele), aztan evekig sirtak a juzerek hogy van 300 diszkjuk de az egyik mar 95% es leall a PG rajta toofull uzivel de a tobbi diszk meg 30%...
mi lett a megoldas? ujragondolni? ah azt nem lehet, szoval hekkeljuk szet: csinaljunk egy masodlagos, fix mappingot, ami felulirja a crush bizonyos reszeit!
hello upmap, hello balancer.

 

mindezt azert mert keptelenek voltak elismerni hogy igen, ez a megoldas fos, a tradicionalis megoldasok (lookup tablak a metaadatokhoz amik lookup tablakra mutatnak az adatokhoz) tokeletesen mukodtek, de nem azt akarjuk...

 

napestig sorolhatnam.

koszi :)

Sima weight change -> rebalance , habar kelloen nagy csoport szam esten ez ilyen anomaliaknak nagyon ritkanak kene lennie ..

Akkor egy lookup siman kerult 8ms -ba, ha tenyleg diskre vartal, a crush dolog egylatalan nem tunt veszesnek ..

Ma egy tavoli `lookup` megvan 100usec  alatt, de talan 2 usec alatt is ..
illetve nem mindegy, hogy minden picsanyi 4k adatert nezel egy tavoli loopuot vagy
egy viszonylag kiss tabla megadja ami kell
amit viszonyalg kis szamu keres utan cachels  (vagy csak "letoltetted" egyben es kesz..)

Ha olyan modszert valasztasz aminel a cel(forras)  `kiszmathato` 2 usec alatt (zero lookup -al),
ez meg mindig versenykepes ..

Az megint egy erdekes kerdes, hogy akkar -e az emeber egyaltalan rebalancolni ..

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ami mindenre jó semmire se jó. Mai napig legstabilabb sotrageunk egy sok sok éves ISCSI SAN. Sok mindent nem tud (nem is kell neki), de azt rohadt stabilan, sok sok éve.

Szóval minél egyszerűbb, annál jobb, stabilabb stb. Ezt kéne szem előtt tartani, nem pedig, hogy egy storage mondjuk kávét is főz mert most az a trendi Az hogy cserébe lassú, bugos már nem érdekes, mert hát kávét is főz. 

Fedora 42, Thinkpad x280

+1, van egy rég(ebb)i md3200 SAS storageunk, már 3x örökölték meg és atomstabil.

Lett helyette újabb már DellEmc ME4024, volt olyan, hogy amíg egy warningot nem okéztunk le, nem lehetett beállítást savelni, persze azt nem mondta el miért... :)

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Kiváncsi leszek az opensource projektetekre. És nem csak a végeredményre, hanem a közbenső mérési eredményekre, buktatók elkerülésére, konklúziókra is.
Izgalmasnak hangzik, főleg a látható hibaesetek és azok hibakezelései.

erről a bejegyzésről ez jutott eszembe :) Szakmailag meg hogy hajrá, király!

Ez a lehülyézésnél hangyányit keményebb.

Ilyenkor mindig eszembe jut a mime formátum. Amikor megjelent, részt vettem egy előadáson, ahol három előadó szerepelt:

- Egy oxfordi leányzó olyan szép angol kiejtéssel, hogy még én is értettem.

- Zsuzsa Kovács aki elnézést kért (magyarul), mert még nem tanulta meg magyarul az előadást, így angolul tette meg.

- Egy arab srác, aki elnézést kért (magyarul), mert ugyan elő tudna adni angolul, németül, (arabul?), de azért ő mégis magyarul fog. És tette legalább olyan jól magyarul, mint Cathy Oxfordból angolul! :-D

"hogy kihajtsa a nyers teljesitmeny 100%-at: elismerem, lehet niche"

Egy bizonyos méret fölött muszáj vele foglalkozni, mert akkor már megéri beletolni a mérnöki órákat. Nálunk is elég fontos téma a hatékonyság növelése. De sajnos a storage dolgokkal annyira nem vagyok tisztában, illetve ha lennék, valszeg akkor se mondhatnék róla sok mindent :). Viszont találtam ilyet nyilvánosan: http://www.pdsw.org/pdsw-discs17/slides/PDSW-DISCS-Google-Keynote.pdf

A lathataron eleg nagyvonalu jelzo mikor magad irod, hogy meg jo messze van az mikor ezt barki hasznalhatja...