A DRBD kalandozásaimon (első rész, második rész) felbuzdulva, no meg egy újabb munkahelyi igény megjelenésével szétnéztem, hogy milyen lehetőségek vannak az egyszerűbb klaszter fájlrendszerek használatára.

A probléma: A DRBD kiváló, ha mester-szolga replikáció kell. Kipusztul a mester, azonnal indul a szolga, és mindenki boldog. Ez két gép esetén teljesen jó. Akkor is jó, ha a gépek párosával vannak, hiszen a szolgáltatásokat párosával kiosztva nincs probléma. Akkor is jó, ha a szolgáltatások elférnek két gépen, és mester-mester replikációval a két gép párhuzamosan dolgozik. Azonban ha nem tudunk párokat alkotni, akkor a DRBD (8-as széria) kettő, maximum három szerverig használható, felette igencsak problémás.

A kihívás: négy, viszonylag kis teljesítményű gépre szétosztani a szolgáltatásokat úgy, hogy bármelyik gép teljes meghibásodása esetén (pl. kijön belőle a működtető füst) ne legyen fennakadás és minden (szinte) onnan folytatódhasson, ahol a meghibásodás előtt tartott.

Miért GlusterFS?

Elsősorban olyan szabad szoftveres megoldást kerestem, ami:

• nem igényel metaadat szervert
• semennyi (vagy kevés) munkával életre kelthető Linuxban
• egyszerűen illeszkedjen az Ubuntu (és némileg Gentoo) környezetbe
• rendszeresen karbantartják
• legyen extrém módon hibatűrő: akkor is működjön, ha egy kivételével minden csomópont kinyiffant. Továbbá a helyi működéshez ne igényelje a többi csomópont jelenlétét.

Továbbá, mivel mindössze négy (4) elemű a kis klaszter, nem szeretnék olyan dolgokkal foglalkozni, ami ennél sok nagyságrenddel nagyobb rendszereknél kell. Ilyen pl. a fencing, azaz a hibás(nak vélt) csomópont automatikus lekapcsolása/kizárása a rendszerből. A jelenlegi alacsony költségvetésű környezetben nem engedhetek meg magamnak ilyen luxust.

Eme követelmények miatt kihullott többek közt az OCFS2 (2012-es az utolsó kiadása), Lustre (csak CentOS & Red Hat támogatott), GFS[1,2] (igényli a fentebb említett fencinget), Ceph (kiváló, imádom, van is vele tapasztalatom, de ez a környezet túl kicsi hozzá), BeeGFS (metaadat szerver kell hozzá), HDFS (kicsik vagyunk hozzá). Így első körben, ezek jutottak eszembe, amiket körbejártam.

A GlusterFS teljesít mindent, ugyanis:

• Nem igényel metaadat szervert.
• Telepítése: sudo apt-get install glusterfs-server (vagy emerge -avqD glusterfs).
• A legfrissebb verzióhoz is van Ubuntu PPA, illetve kis ráhagyással a Gentoo is követi.
• Rendszeres a karbantartás, legutóbbi kiadása 2016 februári.
• Nem kell hozzá fencing.

Ami plusz öröm, hogy a GlusterFS a nevével ellentétben, nem egy külön fájlrendszer, hanem egy már működő FS felett dolgozik. Ez megadja azt a biztonságot, hogy ha valami gond van a Gluster szerverrel, akkor a sima ext4-ről is elérek mindent. Más szóval viszonylag kockázatmentes a használata, ugyanis ha az egész rendszer beborul és csak egy… mondjuk GParted LiveCD-ről érem el az egyik gépet, az ext4-ről akkor is ki tudom menteni az adatokat, mindenféle varázslat nélkül. Ilyen tekintetben, ez már egy plusz funkció a DRBD-hez képest.

Telepítés

Aki nálam kicsit (sokkal) elővigyázatosabb, az telepítheti az Ubuntu 14.04 szerver által szállított, viszonylag régi glusterfs-server csomagot. Ismerem a saját szerencsémet és a alacsony verziószámú szoftverekkel való kapcsolatomat, ezért inkább egy PPA-ra fizettem be. Egészen pontosan a Gluster 3.7-es verzióját tartalmazó PPA-ra.

sudo add-apt-repository ppa:gluster/glusterfs-3.7
sudo apt-get update
sudo apt-get install glusterfs-server

Az alkalmazás dokumentációja innentől mindent lefed, ábrákkal, teljesen intuitívan mutatja be, a működést, éppen ezért erre most nem térnék ki.

Buktatók

A telepítés és beállítás leírása helyett, inkább a buktatókra térnék ki. Vannak apróságok, amik szaporíthatják az ember ősz hajszálait.

I

Brick hozzáadása/eltávolítása esetén a kötethez tartozó másolatok (replikák) számát is változtatni kell, különben balhézik. Számomra evidens volt, hogy ezt egyszer kell beállítani létrehozáskor, utána automatikusan utánaállítja magát. Pedig nem. Szóval, új brick hozzáadása a kötethez:
gluster volume add-brick <kötet neve> replica <eddigi+új brickek száma> gépnév:/hol/van

Ugyanez az elv, ha elosztott kötettel dolgozol, csak nem másolatokról, hanem „csíkokról” van szó.

II

A rendszer befogadta az új bricket, de látszólag nem történik semmi: nem kerülnek adatok az új helyre.
Ilyenkor (ha még nem lenne) be kell kapcsolni a kötet gyógyítását, majd el kell kezdeni a műveletet (illetve elosztott kötet esetén az ezt követő kiegyensúlyozást).

gluster volume heal <kötet> enable
gluster volume heal <kötet>

A gyógyulás folyamatáról a gluster volume heal <kötet> info parancs ad tájékoztatást. Ha valami végképp elcsúszott volna, akkor indíts egy teljes körű vizsgálatot:
gluster volume heal <kötet> full

III

Ami fontos, hogy mindenképp azonos verziójú GlusterFS szervereket használj! Jókora mennyiségű bosszankodástól kíméled meg magad, ha hallgatsz rám. Nyilván, azért mondom ezt ennyire nyomatékosan, mert én belefutottam egy ilyenbe.

Tapasztalatok

Mivel a célkörnyezetben elsődleges az adatbiztonság és másodlagos a sebesség, ezért természetesen a replikált üzemmódját használom a GlusterFS-nek. Négy gép van, ebből egy igazi szerver, normális RAID vezérlővel, SAS lemezekkel és mindenféle finomsággal (csak kevés memóriával). A másodiknak már csak erős CPU és szoftveres RAID 5 jutott konzum SATA diszkekkel. A harmadik egy SOHO környezetbe szánt, belépőszintű szerver, RAID 1, Xeon és „éppen elegendő”, 8GB memória társaságában. A negyedik a kontroll gép, annyi feladata van hogy ha vége a világnak akkor innen még meg lehet menteni az adatokat, illetve innen vezérlem a glustert. Erre pedig 4GB RAM, i3 és 500GB lemez tökéletesen elég. Természetesen, mindegyik gép rendelkezik legalább 1db gigabites hálózati csatolóval.

Kicsit fentebb kihangsúlyoztam, hogy tessék azonos verziójú GlusterFS szervereket használni. Nem véletlen: az útkeresés, kísérletezgetés közben elég vegyes volt a felhozatal. 3.7.4-es GlusterFS szerver volt két Gentoo kiszolgálón és 3.7.6 majd 3.7.8-as a két Ubuntut futtatón. Ebből jött a káosz és az op-version kavarodások. A hercehurca végül odáig fajult, hogy a 3.7.4-essel nem volt hajlandó kommunikálni a 3.7.8-as gluster-server. Szóval ez esetben nem csak illik, de határozottan ajánlatos azonos patch verziószámú szoftvereket használni.

A jelenlegi éles teszt ciklusban nem jött ki eddig (kopp-kopp) semmi komolyabb probléma. A fő gondom jelenleg, hogy iszonyatosan lassúak az írás műveletek. Szerencsére, a napi üzem folyamán főleg olvasások vannak, de egy-egy nagyobb írástól egy rövid időre megakad a rendszer. Az elkövetkező időszak elsődleges feladata ennek a problémának a felszámolása, vagy a megakadás kockázatának a minimumra történő csökkentése.

Végszó

A kalandnak itt még koránt sincs vége, hiszen csak pár hete kezdődött az éles ismerkedés. Az első benyomások kedvezőek, de nem iszunk előre a medve bőrére. Ha ki szeretnéd próbálni a GlusterFS-t, akkor bátran ajánlom, érdemes vele kísérletezni. Nem ígérem, hogy a DRBD példájára lesz egy második rész is belőle, de sosem lehet tudni. :)