RedHat GFS tapasztalatok?

Naplózó filerendszerek (journaling)

Használta valaki a RedHat GFS-ét? Leginkább a megbízhatósága érdekel, a teljesítménye most másodlagos.

  • 2386 megtekintés

( frank | 2006. 10. 20., p – 10:12 )

Egyelore csak teszt kornyezetben nyuzom, eddig a stabilitasra nincs panaszom. Viszont amin lesz idom ujra felvenni a projekt szalat gyurom majd kicsit ocfs2-t is. Apropo, akinek ezzel (ocsfs2) kapcsolatban van pozitiv/negativ tapasztalata, azt is leirhatna ide (remelem a topic nyito nem haragszik erte, elvegre related).

GFS eseteben engem pl. zavar, hogy gyakorlatilag az egesz Red Hat Cluster Suite kell ahhoz, hogy hasznalni tudd.

2-300+

A filerendszer megmarad, a többi viszi (szolgáltatja) tovább. (Elméletileg)

Kíváncsi vagyok, hogy helyesen kezeli-e a GFS a kvórumokat (quorum). Ez azt jelenti, hogy ha egy node nem lát kellő számú (n/2+1) node-ot elérhetőnek, akkor úgy veszi, hogy leszakadt a többségről, így érvénytelenek az adatai. A RH Cluster Suite Update4-ben látom, hogy van egy ún. Quorum Disk feature, de nem tudom, hogy ezt a GFS csinálja-e vagy valami add-on csoda.

Nem ertem a kerdest. Mit akarsz kezdeni harom egymastol fuggetlen 1TB-os storage alrendszerrel? GFS-nek elofeltetele, hogy a clusterben reszt vevo gepeknek legyen hozzaferesuk ugyanazon fizikai adattarolo eszkozhoz (iSCSI, Fibre Channel, stb.). GFS az altalanos filerendszer funkciokat biztositja + konzisztenciat speci lockolasi mechanizmussal megelozendo, hogy a gepek osszekuszalhassak egymas alatt az fs-t. Ergo annyi redundanciat kapsz, mint barmelyik journaling filerendszertol csak eppen multihost hozzaferessel (semmit).

Biztos, hogy ez az amit te keresel?

öhm, köszi a választ, vaóban nem erre gondolok... A helyzet az, h van n darab gépem bennük szép nagy diszk. Ha nem a gfs akkor mi az amivel ezt az n darabot egybe láthatnám (nem darabonként, hanem egy "deviceként")? Mintha egy hálózatos raid 5 lenne, mondjuk...

DRBD lehet meg egy megoldas szamodra. A 0.8-as fejlesztoi agban mar van primary-primary tamogatas, amivel egyszerre 2 node-ot is irhatova tehetsz (na itt mar szukseged van osztott cluster filerendszerre). Ezzel gyak. 2db TeraByte-os gepet tukrozol (halozati raid1). Ha megnagyobb redundanciat akarsz vinni a dologba, es mondjuk nemcsak FOSS szoftver johet szoba, akkor erdemes lehet vetned egy pillantast a DRBD+-ra (3 node is lehet akar) is, nem hinnem hogy megfizethetetlenul draga lenne. Csak egy otlet.

Nem akarok reklámozni senkit, de valamilyen ATA Over Ethernet megoldással (pl. Coraid) nagyságrendileg 200kHUF/TB áron megcsinálhatod ugyanezt, nagyobb teljesítménnyel, fájlrendszer-trükkök nélkül (mondjuk GFS-sel).

Szerintem olcsóbb és jobban skálázódik annál, mintha "olcsó satás gépeket" fűznél össze.

meselj errol egy kicsit :-)

coraidnek enis lattam h vannak ilyen megoldasai,
de az a 200k/TB meg mindig sok ;)

gondolj bele: egy 320g -s sata2 diszk ara
~25k, tehat 100kbol megvan ~1.3T.

ez a coraid hogy muxik? mint a kulso
scsi shelfek, csak nem u320as kulso
scsi a csati, hanem ...? GiE? vagymi?

meg mennyire jo a teljesitmenye? tud hwbol
raidX -et?

Tudni tud, de a stabil verzio (0.7) doksijaban azt irjak, hogy nem ajanlott. Helyette inkabb csatolt fel csak a primary oldalan, es barmilyen halozati filrendszerrel tedd elerhetove a masik node szamara. Mukodik, hasznaltam igy is a dolgot. Az, hogy ez hogyan mukodik a fejlesztoi verzioban (ami tesztjeim szerint stabil, de nem hasznalnam eles kornyezetben, amig a fejlesztok nem mondjak ra azt) nem tudom, de a siteon ott a 0.8 roadmap, abban biztos le van irva.

ocfs2: egyszeruen konfigolhato, poccre megy. miutan bekerult a kernelbe akkor probaltam ki, azota nem nagyon neztem, de gondolom rosszabb nem lett ;) azt nem tudom, hogy clvm-el ossze lehet-e hozni.

gfs: gfs2-t probaltam meg regebben (nem tudom mar mikor, de meg az -mm faban sem volt benne), a hozza valo cluster suitevel voltak gondok, localban tudtam mountolni, szoval kernel resszel nem volt gond, dehat development. mindez ppc64 platformon debian etch alatt, lehet ez is kozrejatszott ;) lehet ki kellene probalni most is, mennyit haladtak.

En GFS-sel jatszottam GFS2-t nem is neztem, tekintve, hogy produktiv rendszerben kellene hasznalnom. Az viszont latszik, hogy a sracok igyekeznek minel tobb reszt userspace-be mozgatni, es csak a nagyon szukseges dolgokat meghagyni kernel szinten, ezzel is egyszerusitve a standard kernelhez illesztest.

"GFS2 and DLM are the only two kernel components and we expect to see them merged into the standard kernel."

RHEL5-t mar az uj suite-tal akarjak szallitani?

( lloyddzilla | 2006. 10. 20., p – 10:23 )

Hat ya GFS nagyobb kornyezetben elonyos, nagy storage-nel, megoszotott halozari SAN-ok eseten, olyan mint a cXFS viszont atombiztos, es elnyuhetetlen :>

( YanChi | 2006. 10. 22., v – 13:50 )

Én élesben használom egy nagyobb web2-es site-on, hogy több frontend szerver is lássa (és írja) a közös adatokat. A storage 4 partícióját használja egyszerre 4 frontend, és kiválóan működik (a sok írás miatt elég sok az i/o wait, de ez természetes).