Jól halad a ZFS on Windows fejlesztése

 ( trey | 2018. november 22., csütörtök - 9:59 )

Már elég stabil, hogy teljesítménymérő alkalmazásokat futtassunk rajta.

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ő.

Lundman is great.

Szuper. Akkor mire jön a következő hájpolt "a jövő fájlrendszere", addigra talán használható is lesz - persze kizárólag játszós környezetben.

http://docs.ceph.com/docs/mimic/cephfs/ ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

dupla

1 node-os gépen (== desktop) ennek van értelme?? Szerverek esetén (ahol megvan a szükséges háttér infrastruktúra) még talán-talán, bár root kötet így se teszel rá szerintem..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

semmi, turul szokas szerint tultolta

Mit is? Bedobott egy fölösleges linket. Semmit nem tolt meg szerintem.

Nincs ertelem egyetelen gepen.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

akkor mi koze a ZFS-hez, ami _csak_ egy gepes?

Next hype lehetoseg es filerendszer.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Akkor várom az érveket, hogy szerinted miért nevezhetne ez a "jövő fájlrendszere" címre.
Illetve a másik amire kíváncsi lennék az a performanciája (főleg a FUSE-s függőség miatt)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Van kernel driver:
http://docs.ceph.com/docs/mimic/cephfs/kernel/

Leginkabb azert jo, mert ha ceph-et mar hasznalod block vagy object storagenak,
akkor szinte ingyen, hogy legyen egy network filerendszer is.

Habar mostmar nfs is van:
http://docs.ceph.com/docs/mimic/radosgw/nfs/


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Épp ezért nem értem miért mint filerendszerként promózod. Ahogy te is írod, ez egy hálózati block device access, ami fölé odaraktak egy FS funkciót.
Az, hogy természetéből fakadóan distributed még szerintem nem teszi kiemelkedővé, mint filerendszer (hasonló okok miatt glusterFS-t se tartom kiemelkedőnek - egyszerűen másra valóak)
És pont ez miatt mint FS semmi olyan plusz feature-t nem ad amit egy mai modern FS-től elvárnánk (encryption, deduplication, Checksumming, dynamic increase )
Sőt, részben azokat se tudja amiket az "ősök" viszont igen ( pl Online Snapshoting).
Szóval szerintem az FS ligában nem versenyez ezen okoknál fogva.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

turul hulyesegeket beszel (ZFSes threadben), de a CephFS tud snapshotokat, checksumokat, lehet online novelni, a dedup es titkositas uton van.

de persze a GPFS a legjobb, ne keressetek mast. :)

snapshot - experimental feature (jogos, nem fogalmaztam teljesen tisztán):

Idézet:
Like multiple active MDSes, CephFS is designed from the ground up to support snapshotting of arbitrary directories. There are no known bugs at the time of writing, but there is insufficient testing to provide stability guarantees and every expansion of testing has generally revealed new issues. If you do enable snapshots and experience failure, manual intervention will be needed.
Snapshots are known not to work properly with multiple filesystems (below) in some cases. Specifically, if you share a pool for multiple FSes and delete a snapshot in one FS, expect to lose snapshotted file data in any other FS using snapshots. See the CephFS Snapshots page for more information.

checksum - ceph-nek mintha tényleg lenne, de kliens oldalon (cephfs) nem találtam erre vonatkozó adatot

Online növelhetőség: Ugyan az mint Checksum esetén: RBD kötetet tudsz online növelni, de kliens oldalról nem találtam erre megoldást (bár tény, hogy nem sok időt foglalkoztam vele) - tudsz kliens oldalról olyan kérést beküldeni a fő szerver felé, ami egy időben megnöveli a kötetet, és kliens oldalon is az FS-t?

Dedup és titkosítás gondolom szintén RBD szintű funkció lesz, ami az én olvasatomban megint nem FS funkció (bár tény, hogy ebben a fajta implementációban irreleváns, hogy melyik absztrakciós layer felel a funkcióért)

szerk: Amúgy a GPFS-t tényleg a mai napig imádom, de kliens/szerver oldalon JFS2-őt szerintem semmi nem veri ;)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

mimic-tol stabil a cephfs snapshot, elotte nem volt.

amit utana irtal, az nekem azt jelzi, hogy nem teljesen tiszta Neked hogy mukodik ez. itt nincs FS, meg nincs RBD. itt RADOS van, a RADOS folott van az RBD implementalva meg az FS is. a CephFS is RADOS-t beszel _alul_, igy az osszes RADOS-ba meno funkcio atmegy oda is - pl checksum illetve dedup support (ha majd lesz egyszer).

nincsenek "kotetek", egy globalis fajlrendszer van - GPFS eseten sem tud a kliens novelni, ehhez be kell rakni diszkeket a poolba, es voila, magatol megno. nem iSCSI LUN-okrol beszelunk...

Félig van igazad - Valóban nem foglalkozok CEPHFS-el napi szinten, CEPH-el, viszont elég gyakran az Openstack környezetekben amik a kezem alatt vannak. És tény, hogy kicsit keverem a fogalmakat helyenként (shame on me, elismerem), de amit leírtál az kb. lefedi azt amit én is írtam: "Itt nincs FS, meg nincs RBD. itt RADOS van, a RADOS folott van az RBD implementalva meg az FS is".
És igen, pont erről beszélek én is - Igen, van egy csomó képesség, igen, van fölé egy FS húzva, de nem az FS adja a képességeket, hanem az alatta levő réteg, ami viszont a klienstől és FS-től teljesen szeparált. Ugyan ezen oknál zártam ki az elején a glusterFS-t, mert a valóságban az se egy valódi filerendszer, hanem egy distributed data store, ami fölé rakhatsz egy FS-t (XFS, ext4, whatever).
Aztán persze lehet, hogy csak az én fejemben vannak ezek a fogalmak ennyire szeparálva, hogy nem szeretem őket egy kalap alá venni*

* kicsit olyan érzés ez, mint ha azt mondanád, hogy az XY FS-ed tud dedupot, mikor a valóságban azt a képességet a storage backend (legyen mondjuk Storewize) adja
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

ha a storwize dedupol, akkor az FS-nek errol fogalma sincs - ergo egy 5TBos LUNon az FS max 5TB-ot fog tarolni.

a Ceph eseteben az osszes feature vertikalisan integralva van, ezert mukodik az, hogy ha boviteni akarod az fs-ed, akkor betolsz a (RADOS) poolba diszket, es voila.

Rendben, ezt az érvet így már elfogadom.
Mondjuk azon sajnos nem változtat, hogy kliens oldalon ez az "FS" még ettől nem lesz komoly opció, bár előre kialakított infrastruktúrában dataFS-ként akár még el is tudom képzelni.

ps: Külön köszönet az értelmes és technikai magyarázatért.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Én olyasmit keresek mindenhol - és eddig csak a VMFS-ben találtam meg - mint a CBT (Change Block Tracking), vagyis csak azokat a blokkokat kell mentenem, amik valóban változtak, nem az egész hóbelevancot.

Ilyen valahol (vagy bárhol) létezik a VMFS-en kívül? Nyilván a megfelelő API-val és az arra épülő mentési megoldásokkal.

--
trey @ gépház

a Ceph pont tud ilyet: RBD imageken levo snapshoto kozotti diffeles pont ezt a listat adja vissza, a backy2 pl ezt hasznalja.
az uj ceph verzioban ha minden igaz erkezik egy zfs send / receive szeru funkcio, amivel szinten lehet backupot implementalni, illteve az rbd mirror (ket ceph cluster kozotti georeplikacio) is ugyanezt hasznalja.

GPFS eseten a snapshotokat kulon lehet backupolni inkrementalisan, sokan cron-bol csinalnak snapshotokat (itt nyilvan ahhoz, hogy alkalmazas szinten konzisztens legyen, kell meg magic)

Köszi az infót.

Nekem ez így kicsit reszelgetésnek tűnik (pl. a ZFS send/reveive incremental snapshotok) egy jól bejáratott VMFS+CBT+{Veeam, VDP, Barracuda Backup stb. támogatott megoldás) mellett.

Nyilván ezek nem kevés pénzbe kerülnek, de ahol használom, ott nem kevés pénzt is keresnek velük. Viszont olyan a felelősség, ahol nem szívesen állok bele nem támogatott, tákolt megoldásokba.

Visszatérve a topikhoz, jók ezek a "Windowson ZFS" meg társai, de tároljon rajta felelősen éles adatot az, aki szeret aggódni.

--
trey @ gépház

Ha jól értem pedig a CoW snapshotok így/hasonlóan működnek, tehát egy ZFS/BTRFS snapshot send/receive pont az eltérést fogja csak áttolni (ha értelmesen paraméterezed).
Ezt BTRFS-nél saját gépeken napi szinten használom is incremental backupra, teljesen jól teszi a működik, gyors, helytakarékos.

Az már más kérdés, hogy ZFS on Windowst, de még BTRFS-t se használnék éles rendszeren. De senki nem mondta, hogy csak éles szeróról van itt szó.

Tudsz mondani ismert gyártótól olyan mentési megoldást, ami ezekre épül?

Vannak helyek, ahova a Ferike összereszelt marék scriptje már a "nem megy" kategória.

--
trey @ gépház

És ezzel most mit akartál mondani? :D
Végig is olvastad amit írtam? Nem csak enterspájz rendszerek léteznek, miért ne lehetne másról (is) beszélni? Valahogy mintha személyes támadásnak vennéd, ha a saját professzionális favoritodon kívül van akinek megfelel más is.

Avagy: Ferike gépén/játszós szerverén a VMFS+CBT+anyámkínja nem játszik, de (gyors, működő) inkrementális backupra igénye attól még lehet.

Nem személyes kedvencről van itt szó, hanem iparban széles körben használt megoldásokról. Igény lehet a kiváltására számos okból. Mondjuk az egyik az anyagi. De ahhoz, hogy az összehasonlítás ne almát a körtével legyen, lehetőleg hasonló feature set, hasonló support, hasonló megbízhatóság azért nem árt. Különben röhögés, SLA sértés, kötbér stb. lesz a vége.

Felvetettem egy kérdést, ami jelenleg foglalkoztat, azt hittem itt kapok rá valamiféle választ. Tévedtem. El tudom engedni.

--
trey @ gépház

Visszaolvasva én értettem a szándékaidat félre, sry.

Joyentet vágom, hogy fasza, nem kókánypeti megoldásaik vannak OpenSolaris (SmartOS) + ZFS alapon. Most hogy a ti igényszintetekhez hogyan idomul, azt nyilván meg nem mondom. Eleve nem is "szakmabeli" vagyok (nem üzemeltetek, max saját szakállra), nem szeretnék ezen a téren okoskodni.

Oracle - http://www.oracle.com/us/products/servers-storage/storage/nas/zfs-backup-appliance/zfs-backup-appliance-ds-1579018.pdf
QNAP - https://enterprise-nas.qnap.com/en/
Egyéb: http://open-zfs.org/wiki/Companies
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

visszaterve a kicsit offtopic VMware temara: en szeretem a VMware cuccait, van egy pici (4 gep, ~10TB flash) vSphere/vSAN clusterunk, viszont fogalmam sincs ki az, aki ki tudja fizetni ezt egy akar csak 200 hypervisoros kornyezetre is, annyira draga, osszevetve barmi massal (a Canonical mindig azt nyomja, hogy ok mennyire olcsoak a RedHathoz kepest, dehat kerem, a VMwarehez kepest a RedHat is olcso...)

a vSphere@AWS annyira draga, hogy elmondani nem lehet.

ha pedig hyperscale szinten vagyunk, es kell 10k hypervisor, akkor mar latszik hogy senki nem fizeti meg...

Ha esetleg a Microsoft is dobja a meglévő Windowst és újjáépíti FreeBSD alapokon, akkor biztosan lesz benne stabil ZFS is. :)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Érdekes és olvastam picit utána, de csak egy értelmes célt tudok kitalálni, az a recovery, esetleg. Más nem jut eszembe.

A másik gond ami aggasztóbb, hogy az "igazi" zfs és az openzfs az eredeti v28-as verziótól nem kompatibilis egymással, de ezzel bőven együtt ehet élni szerintem.