GlusterFS paff?

> https://access.redhat.com/support/policy/updates/rhs/

Az RH "csendben" dobja a GlusterFS-t?

 

> https://www.gluster.org/release-schedule/

Ez nem olyan biztato:/

( NagyZ v | 2024. 04. 30., k – 09:45 )

2 eve volt az EOL bejelentve, talan kovetni kene a hireket :)

A gluster és a VMFS teljesen más megközelítés, illetve nagyon más feladatokat is old meg a problémából.

A válaszhoz első körben azt kellene tisztázni, hogy mit kell adni, és mi az elvárás, de ebben a szálban kevés esélyt látok arra, hogy a VMFS lehessen a jó válasz. :)

Mármint hogy VMFS a GlusterFS helyett? Igen, erre reagáltam én is.

Jó, értem, valószínűleg erre gondolsz:

Kb. 1TiB tárolása, legalább 2 node felől írhatónak kell lennie, bármelyik egy node kiesését/visszatérését tolerálja a megoldás. Írás jellemzően 35-50GiB/nap, jórészt egyenletes terheléssel.

de ha elolvasod a kontextust, szerintem abba a VMFS semmilyen szinten nem illeszkedik. De kérlek fejtsd ki, hogy szerinted hogyan és miért lenne a VMFS megoldás olyan helyen, ahol vsz. az összes konnektivitás a "pőre" Linuxot futtató, teljesen önálló gépek (és a benne lévő diszk(ek)) közt egy GE NIC.

* veled ellentétben semmilyen vonatkozó papírom nincs, így ebben a témában abszolút szaktekintély vagy, nagyon érdekelne a részletes(ebb) válaszod.

Világosítsátok már meg sötét elmémet, ha csak ezt: "legalább 2 node felől írhatónak kell lennie" nézzük, a VMFS mit teljesít ebből? Egy shared raw device-ot? Ennyi az igényed?

Vagy VMFS-en akarsz (POSIX FS) akármilyen fájlokat tárolni? Linuxon? Itt valami komoly diszkrepanciát (pun intended) érzek. :)

Miért, ha a node egy SAN-ba kötött gép, vagy egy VMWare-ben futó guest, akkor általános megoldást ad a VMFS?

Arra lennék kíváncsi, hogy milyen esetben alkalmas több gép közötti, elosztott adattárolásra önmagában a VMFS? Milyen use-case-re gondoltál, amikor ezt leírtad?

Szalmabábokat ne építs.

Pontosan tudod mire jó a VMFS, azt is, hogy mire használható shared storage-on, több node-dal (hosttal).

  • 1TiB tárolása - pipa
  • legalább 2 node felől írhatónak kell lennie - pipa
  • bármelyik egy node kiesését/visszatérését tolerálja a megoldás -pipa
  • Írás jellemzően 35-50GiB/nap, jórészt egyenletes terheléssel - pipa

trey @ gépház

Jópár éve nem az enterprise IT-ben dolgozom, így ez a "támogatott környezet" kicsit olyan archaikus, dohszagú izé, amivel az abba ragadtak védekeznek, ha nem tudnak mit mondani. :)

Az általad javasolt megoldás ettől függetlenül itt továbbra sem látom, hogy mire kínálna választ, de ezt úgy tűnik soha sem fogom megtudni.

Nem, meguntam a nagyvállalati környezetet, ami volt, azt már vállalkozóként viszem tovább, így sokkal nyugodtabb. De jóideje inkább cloudban tákolgatunk, az meg általában megint más világ.

Az viszont egyre gázabb, hogy már egy szakmai kérdésre sem tudsz válaszolni, amelyről ráadásul rengeteg papírod is van.

Ezt mondod az ügyfeleknek is, ha nem tudsz válaszolni egy kérdésükre, vagy megkéred a vendort, hogy válaszoljon helyetted?

Én általában igyekszem szerény lenni, mert tudom, hogy mennyire korlátozott az az ismeretanyag, ami a fejemben van, arca szerintem neked van. :)

Itt a lehetőség, hogy beégess, olyan területen, amihez amúgy semmilyen formális műveltségem sincs. Ne hagyd ki kérlek!

Te itt nem ügyfél vagy, hanem elvileg egy szakmabeli. Ha szakmabelivel társalgok, akkor megkérem, hogy írja le, hogy mi pontosan a feladat, mi a büdzsé, mi az elvárás. Gúnyos heherészés nem szokta előremozdítani az ügyet, simán volt olyan, hogy megköszöntem az érdeklődését és ajánlottam mást, hogy azt szórakoztassa.

Bizony.

Ja, mindjárt nagyon szerényen indítottál:

https://hup.hu/comment/3053783#comment-3053783

trey @ gépház

suckit nem a haverom, en azt hittem ti vagytok az oribarik ;), de most jelen pillanatban 100%-ig igaza van, a VMFS meg csak nem is focizik ezen a teruleten, igy en sem ertettem (es biztos, hogy meg sokan masok se), hogy miert hoztad fel. nem lehet linuxos kliensrol nativan mountolni, es alapbol nem clustered, ha csak A, nem veszel vSAN-t B, nem rakod mar kulso HA tarolorol jovo LUN-ra (~LUN, ertem en, hogy az NVMeoRDMA-nak semmi koze a SCSI LUNokhoz, ebbe most kar belekotni)

Sose volt haverom.

Én zeller kiírására írtam egy kommentet egy fájlrendszerrel, ami minden tekintetben megfelel az ő hevenyészett kiírásának. Pontosan tudom mire való és azt is, hogy egy feladatnak nem csak egy megvalósítása vagy megoldása van.

Nem alternatívaként írtam, hanem más szemléletet javasoltam. Nem mellesleg támogatottat.

trey @ gépház

Csak az ő kommentjét olvastam, a többit le se szartam, főleg nem a ballib troll nyitó posztját. A komment neki szólt, kb. ismerem a tákolgatós fajtáját (volt egykét körünk már storage témakörben), arra odaszúrásnak ment, mert kb. sosem lesz rávalója.

Kb. be is jött, meg is lett a válaszcunami. Mondjuk tőletek, de így se rossz.

trey @ gépház

1024 éve drbd-t és "némi" scriptelést mondtam volna a két node-ra, de jobb lenne azért ennél kevésbé érzékeny megoldás... A 2+ node nem gond, ha node-onként frissíthető a motyó úgy, hogy az nem okoz adatvesztést, illetve az sem hátrány, ha n node esetén nem n-szeres a tárhelyigény...

De, jól írtam. 1TiB. Ha mindenképp a "venni" a megoldás, akkor arra én is tudok megoldást/szállítót, de itt most kifejezetten nem a "vegyünk valamit" lenne a cél, hanem az, hogy ennyi tárterületet bármelyik node újraindítását elviselő megoldással tudjon egy HA-ban működő alkalmazás írni. Fájlok, több száz darab, nagyjából folyamatosan nyitva írásra mind.

( Zsugabubus | 2024. 04. 30., k – 14:59 )

Szerintem szar volt eleve, fájl volt a legkisebb egység, amit kezelni tudott, azaz DB fájlok tárolására teljesen alkalmatlan volt. Kb. úgy működött, mint egy intelligens(ebb) rsync.

( ibenny v | 2024. 05. 05., v – 14:53 )

Én sem hallottam erről, 2-3 éve szálltunk le róla, azóta nem követtem.