Keresek egy file rendszert...

 ( Cajga | 2015. február 6., péntek - 17:28 )

Fontos: A topic egy elmeleti jatszadozas. Nem keresek masik megoldast a problemamra, kifejezetten arra lennek kivancsi, hogy letezik-e ilyen file rendszer, ami az igenyeimet kielegiti (a tobb szem tobbet lat alapon, mivel en nem talaltam megfelelot).

Problema leirasa:
Adott N server, amik egy FC SAN-bol kiajanlott kozos disk-et latnak. Egy olyan file rendszert keresek, ami megfelel a kovetkezo kriteriumoknak:
* Fel lehet mountolni minden serveren egyszerre ugy, hogy kizarolag egy RW mount tortenik a tobbi mind RO
* A server, ami RW-be mountolja NEM rendelkezik semmi halozattal
* A szerverek nem kepesek kommunikalni egymassal (nincs halozat, nincs soros kabel, nincs semmi :) )
* az RW node altal irt adatok meghatarozott idon belul lathatoak az RO node-okon (akkor is, ha eppen ugyanazt a konyvtarat listazzak ki mint 1 masodpeecel ezelott (tehat a kernel tudja "valahogyan", hogy a Page cache mar invalid))
* Linux-on hasznalhato es Open Source
(* plusz egy raadas: jo volna ha valami journaling fs lenne)

Ha nem letezik, akkor ennek ki, milyen technikai okat latja?

NEM MUKODIK:
* NFS, CIFS, GlusterFS, CephFS, GFS1/2, OCFS1/2 etc.: halozat szukseges hozzajuk
* Ext2/3/4, XFS es tarsaik: Nem lehet tobbszor felmountolni oket
* VMFS: zart, hatalmas limitaciok linux alatt, nem skalazodik elegge

Szerk1:
Elindultunk egy jo iranyba es koszonhetoen a commenteknek folyamatosan finomitom a kriteriumokat. Osszeszedtem a kilott FS-eket is, es az okat a kilovesnek

Szerk2:
Mondjuk ugy, ha az XFS-t fel lehetne mountolni tobbszor (1 RW es N RO) akkor az lenne a tokeletes FS-em. (snapshotos trukkozes a kovetkezo level aljan nem jatszik mivel folyamatos iras van)

Szerk3:
Szoval az eddig osszegyujtottek alapjan egy olyan OS-t keresunk, aminel:
* kikapcsolhato a kernel write cache hasznalata (lsd sync option ext2/3/4-nel) vagy optimalis esetben valahogyan garantalni tudja, hogy csak "osszefuggo modositasok" talalhatoak a dirty page cache-ben
* read eseteben kikeruli a kernel read cache-et vagy optimalis esetben valahogyan tudja, hogy iras tortent az RW node-on ezert az adot page invalid a cache-ben
* az irasnal a file lockolasa megoldott a disk-en keresztul

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"A szerverek (es ugye igy az FS) kizarolag a SAN-on keresztul kepesek kommunikalni egymassal (nincs halozat, nincs soros kabel, nincs semmi :) )"
Elég, ha csak az egyik szerver felől a többi felé megy a kommunikáció és vissza nem? A többi szerver meg nem is tud egymásról. Mert ha csak "írásban" kommunikálnak és csak az egyik tud írni, a többi csak olvasni, akkor ez egyirányú információáramlás.
Szóval gondold ezt át! :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Mint irtam, tudnanak kommunikalni egymassal a SAN-on keresztul (pl kapnak egy masik disket, amit mindenki lat es irogat (akar block level szinten) stb.) de mivel ugy latom, ez csak bonyolitja a helyzetet es a te kerdesedhez hasonlo kerdeseket fog szulni, leegyszerusitettem a kiirast.

Az IP over FC az csalás, vagy tényleg csak az zavar, hogy a SAN-on kívül más kapcsolat is van?

Most akkor az jó lenne, hogy 9p fájlrendszert felcsatolsz N-szer RO módban, egyszer RW módban?
És akkor kéne valami, ami mindezt automatizálja?

Mi a probléma? Mármint mit szeretnél ezzel megoldani?
És mennyire lesz probléma, hogy az írásról csak késve értesülnek a többiek?
Vagy pont a szinkront szeretnéd megoldani?

GT

Sosem hallottam meg a 9p fs-rol. Mivel a kovetkezo idezet a wikipediarol azt mondja, hogy alapvetoen ez egy halozati protokol ezert ez nem megoldas:
"9P (or the Plan 9 Filesystem Protocol or Styx) is a network protocol"

Mint irtam a kezdo topicban nem megoldast keresek egy problemara. A problemat megoldottuk, de ugy gondolom, hogyha letezne az altalam megalmodott FS akkor az jobb megoldas lenne. Sokszor tortent mar velem hogy kitalaltam vmit, azt gondoltam kva nagy otlet, korul neztem es mar vki megcsinalta vagy nagyon kozel volt hozza. Ebben az esetben nem talalom a kesz termeket.

Pontositottam a kiirast, hogy egyertelmubb legyen, hogy "normal" halozat nem jatszik.

van ilyen, sot tobbet is tud, vmfs-nek hivjak

Jo irany es megfelelt az eddigi kiirasomnak ( elso :) )! Sajnos a lockolasa miatti limitaciok, a linuxon valo hasznalhatatlansaga miatt nem megoldas.
Pontositottam a kiirasomat.

Clusterfs-eken kivul szerintem csak nfs.
De gondolom te lokalis fs-re gondoltal.

Igy van, halozat kilove.

Miért kell kilőni a hálózatot? Ha az RW node mindegyik RO node-dal egy külön VLAN-ban kommunikál (ad absurdum, egy pont-pont kapcsolaton keresztül) akkor tolhatod rajta az NFS-t, és semmi bajod nem lesz belőle...

... vagy, én nem értem a problémádat :)

Te nem erted. Nincs halozat. Fogadd el es kesz. Az adott kriteriumokra keresek egy FS-t nem pedig "egy masik, szted jobb megoldast".

Az üres halmaznál jobb a "nem pont ezt akartuk, de végülis megfelel a célnak". Ezt hívják kompromisszumkészségnek :)

A "cluster fájlrendszer, hálózat nélkül, linuxon, openszósszal" szerintem egy üres halmaz.

Ahogy irta, a kompromisszumot mar megkototte.

Oke megprobalom utoljara, legyszi olvassd el nyugodtan, odafigyeloen. Az adott kriteriumoknak megfelelo file rendszert keresek, nem pedig egy masik megoldast.

Mint fentebb irtam, van megoldas a valos eletbeli problemankra (NFS-t hasznalunk jelenleg egy hierarchikus FS felett ;) ) ez kizaroan egy elmeleti jatszadozas

Nem ismerem, az ocfs2 nem pont ez lenne, vagy annak kell net?

"There is a simple, TCP-based messaging system which is used by OCFS2 to talk between nodes in a cluster."

Szerintem ezen a ponton elvérzett.

Igy van, bovitettem a nem mukodik listat :)

Amugy pl. Ext4-et nem lehet mountolni 2x valoban?

Elso volt, amit megneztem, amikor az otlet az eszembe jutott :)

En ugy tudom, hogy nem lehet. Mivel nem vagyok egy kernel level fs hacker lehet, hogy vki meg tud cafolni, ezert leirom azokat a problemakat amirol en tudok (es a megoldasokat amit en ismerek rajuk (hatha rosszak :) )):
1) Journal replay, akkor is amikor ro-ban mountolod: Ez ugye akkor jatszik, ha ugy tunik, hogy nem tisztan lett umountolva (ez barmikor lehet koszonhetoen az RW node dirty cache-nek (lasd kesobbi problema)). Ez elvileg megoldhato a noload mount option-nel az RO node-on, igy hagyjuk, hogy az RW node kezelje a problemakat a journal segitsegevel.

2) Dirty page cache az RW OS-nel (bar ez nem direktben az FS problemaja): Ugye by default a kernel nem ir ki mindent a diskre egybol hanem a memoriaban tarolja oket (Dirty Page Cache). Bar sokaig azt gondoltam, hogy ezt nem lehet kikapcsolni FS szinten (csak ha az app DirectIO-t hasznal vagy megfelelo utemben hivja a fsync()-et) de most ugy tunik szamomra, hogy a sync mount option megis minden megold ebben a problemakorben (bar elmeletben egy erre tervezett FS/kernel paros akar hasznalhatna dirty page cache-t is (kivancsi vok hogy a VMFS ezt hogy oldja meg))

3) VFS cache a RO-oldali OS-eknel. Bar ez sem direktben FS problema, de erre nem tudok megoldast jelenleg ext2/3/4 eseteben. Ugye az OS hasznal read cache-t amit pl a echo 3 > /proc/sys/vm/drop_caches parancsal el is tudunk dobni. Ezt kikapcsolni nem lehet es az EXT2/3/4 nem tudja ezt megkerulni. Mivel az iras nem az RO OS-en tortenik a kernel azt gondolja majd, hogy a cache-ben levo page-ek meg jok es azokat fogja visszaadni.

4) Dap kollega altal felvetett locking problema is fennal ilyen FS-ek eseteben: "Egy általános fájlrendszer sok összetett adatstruktúraval dolgozik, amit nem egy atomic read-del olvas fel, ergo nem biztos hogy az konzisztens lesz. Lockolni kell az írás idejére". Erre nincs megoldas jelenleg Ext2/3/4, XFS eseteben

Szerk: OK, szoval gondolom a fentebb emlitett okoknak (is) koszonhetoen VMware nem hasznal (legalabbis 2011-ben) cache-t a VMFS-ben (se read se write cache-t): http://www.yellow-bricks.com/2011/04/07/mythbusters-esxesxi-caching-io/

Szerk2: Bar azt nem irtam le, de gondolom a 2-es es 3-as problemanak a kovetkezmenye egyertelmu: rossz file tartalom, mar torolt file-ok olvasasa stb.

Szerk3: hozzaadtam Dap kollega lockolasi problemajat 4-es pontkent

De, ha RO mindenki, akkor lehet...

> RW node altal irt adatok meghatarozott idon belul lathatoak az RO node-okon
Mi az a meghatározott idő? 1 mp, 1 óra, 1 nap..?

Valojaban ez nem szamit. De, hogy egyszerubb legyen az elet :) :
1 ora

Ami fontos, hogy mindig konzisztens legyen, amit latnak (lasd fentebb a 2-es es a 3-as problemat)

És mi baj az óránkénti filesystem/blockdev szintű snapshottal?

"1 oraig nem latjak a valtozast" vs "egy ora kesessel latnak mindent valtozast"

Nem értem. A késés csak egy fix időeltolódással elfogadható vagy ezt hogy érted?

Igen. De ez megint rossz irany.

Ez a megoldas nem optimalis:
1) ugye fsfreeze a snapshot ideje alatt
2) overhead (munkaban nezve) az umount/remount az RO node-oknal

Szeretnem ha az FS mindent lekezelne hasonlo mokolas nelkul. (tudod, nem egy masik megoldast keresek hanem egy FS-t :) )

Csak azért mentem bele, mert a posztban nem azért zártad ki a snapshotot mert mókolás, hanem mert "folyamatos írás van" és nem értettem, hogy ez miért zárja ki a snapshotot. De ha mókolás, akkor skip. :)

Igazad van. Eddig a snapshot-os megoldas tunik a legkozelebbinek de meg mindig nem az igazi (nem egy FS :) )

Ehhez legközelebb az append-only logfs-ek (log-structured filesystem) állnak. A cache invalidálás ott is megoldandó probléma, de legalább lockolni nem kell.

Na erre kiváncsi vagyok... Ez egy pofon egyszerű probléma, kell hogy legyen megoldás rá. Csilivili cluster fs-ek?

"Ez egy pofon egyszerű probléma, kell hogy legyen megoldás rá"
En is ezt gondoltam :)

"Csilivili cluster fs-ek?"
Eddig kilove mind... lasd a kezdo post-ban

Szerk3 a nyito posztban (hatha segit valakinek :) )

Az R/W cache kikapcsolása csak félmegoldás.

Egy általános fájlrendszer sok összetett adatstruktúraval dolgozik, amit nem egy atomic read-del olvas fel, ergo nem biztos hogy az konzisztens lesz. Lockolni kell az írás idejére vagy logfs kell (bár elméletben ott is kell lock, de ott egyszerűbb a mechanizmus).

Ez erdekes felvetes (modositottam a szerk3-at emiatt).
Normal, lokalis FS (XFS, EXT2/3/4) eseten (gondolom) ezt kernel szinten oldjak meg. ClusterFS-ek eseten distributed locking-al (es ehhez hasznaljak altalaban a TCP stack-et).

A mi esetunkben ezt disk-en keresztuli lockolassal kellene megoldani.

En ugy gondolom, hogy technikailag meg mingid lehetseges lehet egy ilyen FS letezese.

Csak valos igeny nincs ra. Minek, mi volt a project?

Probaltam elkerulni, hogy leirjam, mert mindenki arra fog fokuszalni, hogy hogyan oldana meg. De mint irtam parszor nem ez a lenyege a topic-nak. Mivel ugy tunik, hogy a kivant FS-em nem letezik, ezert leirom a mi projectunket es meg par use case-t amit el tudok kepzelni.

Szoval nalunk a project az, hogy tobb station kuld adatot egy kozponti DC-be. Ezen az adaton (jelenleg kb 30GB/nap) kozponti serverek jol parallelizalhato nagy szamitasigenyu feladatokat vegeznek. Mivel az algoritmus valtozik/optimalizalodik neha ujra kell kezdeni az egesz data set-en (jelenleg kozel 1PB) vagy csak egy reszen. Mint lathato, mondhatjuk, hogy 1 host ir es a tobbi olvassa az adatot. Jelenleg NFS-el van megoldva de gondoltam ha letezne egy ilyen FS azzal elkerulheto a plusz egy, halozati layer. ClusterFS-ekkel a problema, hogy neha (rekalkulacioknal) tobb server is beszall es ez sok esetben nem annyira egyszeru megoldani. Valamint nem nyujtana jobb megoldast mint az NFS. DistributedFS nem szukseges mivel van high-end storage csilliokert es nem kell software-es megoldason gondolkodnunk. Legegyszerubb az lenne ha csak siman felmountolnam az fs-t az uj server-eken es mehetne is a kalkulacio.

Igazabol barmilyen use case-nel lehetne hasznositani ahol ClusterFS-t hasznalnak de eleg lenne ha csak 1 server irna:
* nagy forgalmu weboldal, ahol tobb server szolgalja ki a tartalmat
* IaaS kornyezetben uj VM-ek inditasanal

Mint fentebb irtam, elso ranezesre egyszeru dolognak tunt es nem ertettem, hogy miert nem talalom ezt az FS-t. Azt gondoltam, hogy a a distributed locking a clusterfs-eknel csak azert kell mert tobb host is irhat egyszerre a file rendszerre es elkerulheto lenne ha csak egy irhatna. Ugy tunik a distributed locking ebben az esetben sem megkerulheto es valoszinu, hogy a TCP/IP stack hasznalata erre jobb megoldas, mint a disk-en keresztuli lock-ing, ezert nem talalom ezt az FS-t :)

Nekem ebbol meg mindig az derul ki, hogy nincs ra valos felhasznalasi igeny, ill. egesz konkretan csak marginalis igeny lenne ra:)

Oke. Kosz a velemenyedet.

mint a disk-en keresztuli lock-ing

Ezt már sokadszorra írod, csak nem értem, hogy mi az alapja annak, hogy ilyesmiről beszélsz. A diszktartalmon keresztül lehetne lockolást csinálni, csak baromira lassú lesz. Az meg, hogy a diszk firmware-ben implementáljanak valami szofisztikált lockolást, hát lásd be, hogy ez azért az irreális kategóriája... és hogy menne ez? Valamelyik FS kitalálói megkérik az összes gyártót, hogy csinálják meg? Vagy csak egy diszktípussal fog működni az a FS? Na ennek aztán nagy piaca lenne...

Szóval hogyan, milyen jelenleg is létező diszkművelettel gondoltál lockolást csinálni? Mert leginkább azért nem létezik ilyen FS, mert nem létezik ez a fajta lockolás sem... így azt várni, hogy "majd akkor valaki megírja" erőteljesen veszett fejsze nyele.

how does it feel to be added?

OpenVMS, 1980-2015-...

>b-but muh superior bazarlinyux

tough

subscribe