Varga Tamás tollából. Úgy adódott, hogy munkám során egy számomra új megoldással találkoztam, AIX platformon. Ez egy magas rendelkezésre állást biztosító filerendszer, amely cluster-szemlélet szerint működik, azonban a cluster-megoldást csak a filerendszerre alkalmazza. Ez azt jelenti, hogy a filerendszert használó alkalmazást a GPFS maga nem kezeli le. A következő leírás bemutatja, a GPFS alapjait ill. hogy hogyan lehet AIX platformon egy GPFS clustert.
Mi a GPFS?
A GPFS a General Parallel File System rövidítése. Ez egy clusterezett filerendszer, mely lehetővé teszi több host egyidejű hozzáférését az adott filerendszerhez. Ezt úgy kell elképzelni, hogy külön AIX rendszereket, saját tárterülettel fürtöznénk. A GPFS azt teszi lehetővé, hogy ezen külön álló rendszerek közös filerendszereket birtokoljanak, úgy hogy eközben minden AIX saját és nem közös tároló kapacitással rendelkezik. Maga a GPFS driver nem része az AIX-nak, külön kell a filesetet megvásárolni és telepíteni. Az AIX mellett a Linux és Windows platformokon is támogatást élvez.

Topológia
Az általam bemutatott példában kettő node, egymást egyetlen ethernet linken keresztül érik el. A szükséges diszkeket egy EMC SAN biztosítja, a node-ok HBA kártyán kapják meg. IP kapcsolat közöttük konfigurált.
test01 – 192.168.132.91
test02 – 192.168.132.92
Előfeltételek
A cluster node-ok kommunikációja ssh és scp segítségével történik, ami azt vonja magával, hogy a node-oknak egymást el kell tudni érni hálózaton ill. az ssh/scp-nek jelszó nélkülinek kell lennie (tehát kulcs alapú autentikációt használ). Ezt nagyon röviden leírva:
1., NodeA-n: ssh-keygen –t rsa
2., A generálódott id_rsa.pub file másold a NodeB-re
3., Az átmásolt id_rsa.pub file tartalmát illeszd az .ssh/authorized_keys fileba
4., NodeB-n: ssh-keygen –t rsa
5., A generálódott id_rsa.pub file másold a NodeA-ra
6., Az átmásolt id_rsa.pub file tartalmát illeszd az .ssh/authorized_keys fileba
Az sshd_configban: PermitRootLogin értéke: yes, majd ssh daemonok restartja a mindkét node-on. Ezután a node-oknak képesnek kell jelszó nélkül is elérni egymásnak.
Természetesen a GPFS cluster node-okon a node-ok nevének feloldhatónak kell lennie (helyes hosts fileok!!).
Telepítsük a filesetet a HACMP-ről szóló cikkben már megismert módon, smittyvel (mindkét node-on). Ha ez megtörtént, mielőtt még bármibe is belefognánk, upgradeljük is rögtön (nekem ugyanis 7.1-es AIX-on a 3.4.0.0-s GPFS fileset gyönyörűen vágta a coredump-okat, egészen addig, amíg a GPFS 3.4.0.10-es patch-setet fel nem tettem).

Ha nem szeretnénk sokat gépelni, akkor módosítsuk a PATH beállítást az alábbiak szerint:
# export PATH=$PATH:/usr/lpp/mmfs/bin
A cluster létrehozásának lépései
1., Szükségünk lesz egy filera, mely a résztvevő node-ok nevét és szerepkörét (designation) tartalmazza; nálam ez az /etc/gpfs_nodes lett, az alábbi tartalommal (ezt tapasztalat szerint elég az egyik node-on, ahonnak a cluster-t létrehozzuk, megkreálni).

2., Ezután hozzuk létre a cluster-t magát, a következő paranccsal.
# mmcrcluster -N /etc/gpfs_nodes -p test01 -s test02 -r /usr/bin/ssh -R /usr/bin/scp -C testgpfs –A
ahol
-N a node definiciós file
-p a primary node
-s a secondary node
-r a remote shell tool
-R a remote copy tool
-C a cluster neve
-A a GPFS daemonok automatikus indulásáért felel

A clusterünk tulajdonképpen létre is jött ezzel, bár további konfiguráció nélkül természetesen nem tudjuk használni még a célnak megfelelően. Ellenőrizzük le:
# mmlscluster

3., Licenszeljük be a node-okat!
# mmchlicense server –accept -N test01,test02

Itt egy pillanatra térjünk ki arra, hogy mit is jelent a ’server’ kifejezés a parancsban! Alapvetően kettőféle lehet ez: ’server’ vagy ’client’. Mi a különbség a kettő közt? A ’server’ mode a megengedőbb: mindkettő képes a node-ok közt clusterezni a filerendszert, azonban ’client’ módban licenszelt node-on nem tehetjük azt meg, hogy fájlmegosztást is használjunk a GPFS filerendszeren; így ’client’ módú node-on a GPFS filerendszer nem leszünk képesek kiajánlani NFS-en, FTP-n, Sambán, stb. Ellenőrzéskor ilyesmit kell látnunk:

4., Ez talán nem is kötelező lépés, de tegyük meg, későbbiekben nem lesz így kavar: hozzuk szinkronba és azonos verzióra a node-okon a cluster-konfigurációt!
# mmchconfig release=LATEST

5., Most pedig, indítsuk el a clustert mindkét node-on, majd ellenőrizzük:
# mmstartup –a (elindítja a GPFS-t minden résztvevő node-on)
# mmgetstate –aLs (bőbeszédű státuszkimenet)

A cluster másik nodeján eközben a logban is láthatjuk, hogy sikeresen működtünk:

Az NSD létrehozásának lépései
Eddig nagyon jó, de mi a helyzet az ígért cluster filerendszerrel? Ezt is létre kell hoznunk, és itt jön be egy új fogalom is: az NSD. Ez a Network Shared Disk rövidítése. Ez lesz az a fizikai diszk, mely részt vesz a cluster node-okon megosztott filerendszerben, mint fizikai kötet. Hogyan tudjuk ezt konfigurálni?
1., Szükségünk lesz itt is, mint a cluster node-oknál, egy leíró filera, ami nálam az /etc/gpfs_disks lett:

Ennek a formátuma, mint látjuk a fenti képen, a következőképpen néz ki:
DiskName : PrimaryServer : BackupServer : DiskUsage : FailureGroup : DesiredName : StoragePool
Ez nem mind kötelező paraméter, de legalább a Diskname, PrimaryServer,DiskUsage, FailureGroup, és DesiredName igen. Ezt célszerű rögtön backupolni is, mert a cluster a következő lépésben beleír!
# cp /etc/gpfs_disks /etc/gpfs_disks.bak
2., A mi test01 node-on levő hdisk8 fizikai kötetből fog kreálni egy nsd12 nevű NSD-t, a következőképpen:
# mmcrnsd -v no -F /etc/gpfs_disks

# mmlsnsd (ellenőrzés)
Fájlrendszer létrehozása az NSD-n
# mkdir /gpfs
# mmcrfs /gpfs/testgpfs /dev/testgpfs -F /etc/gpfs_disks -B 64k -A yes

Látjuk, hogy a fájlrendszer létrehozásával egyidejűleg a parancs létrehozza a /dev/testgpfs virtuális eszközt is, melyet majd a /gpfs/testgpfs alá fogunk csatolni. Nézzük meg, mit csináltunk!

Itt láthatjuk a létrehozott filerendszer össze paraméterét, melyet természetesen változtathatunk a későbbiekben. Itt jegyezném azt, hogy a GPFS cluster alkalmazásban a meglevő AIX kötet- ill. fájlrendszerkezelési ismereteinket kamatoztathatjuk, ugyanis nagyon sok párhuzamot találhatunk a normál AIX ill. GPFS parancsok között, melyek ’mm’-mel kezdődnek, úgy, mint például:
lsfs – mmlsfs
chfs – mmchfs
mount – mmmount
df – mmdf
És így tovább. De visszatérve a folytatásra, a fájlrendszerünk kész. Ellenőrizhetjük még a diszket, melyen a filerendszer van:
# mmlsdisk testgpfs

Mountoljuk fel mindkét résztvevő node-on:
# mmmount testgpfs –a

Nézzük meg, hogy sikeres volt e:
# mmlsmount testgpfs –L

Mindeközben a másik node logjában ugyancsak figyelemmel kísérhetjük a folyamatot:

A végeredményünk pedig, egy, a cluster mindkét node-ján párhuzamosan jelenlevő, elérhető és használható filerendszer. Meg kell azonban jegyeznünk néhány dolgot!
1., A diszk leíró fileban láthattuk, hogy a NSD pv-jét ebben a konfigurációban csak a test01 node birtokolja. Ez, így NEM redundáns, ugyanis ha a test01 clusternode down lesz, akkor viszi magával az NSD pv-jét is, így a secondary node-n sem lesz elérhető, noha a cluster ott még fut rendesen.
2., Az ajánlások szerint 2 node-os GPFS-clusternél érdemes ún. tiebreaker disk-eket létrehozni. Ez is új fogalom, én legalábbis sosem találkoztam még vele, kicsit ijesztőnek is tűnt (szószerint kötöttséget megszüntetőt jelent), egész addig, míg sikerült rátalálnom, hogy ez a tulajdonképpeni quorum disk.
Nézzünk meg egy ilyet is!
A tiebreaker disk konfigurációhoz adása (quorum)
Az előfeltétel természetesen egy mindkét node-on elérhető, tehát pl. SAN-ról egy kisebb LUN. Miután mindkét node-on látszik a disk (cfgmgr), meg kell PV-znünk őket mindkettőn, a már ismert módon (chdev –l hdiskX –a pv=yes).
1., Ehhez ismét szükség lesz egy diszk leíró filera, ez természetesen egy új file lesz, legyen mondjuk:
/etc/gpfs_tiedsk. Ennek a tartalma azonban más lesz, mintha normál NSD-t hoznánk létre.
# cat /etc/gpfs_tiedsk
#DiskName:PrimaryServer:BackupServer:DiskUsage:FailureGroup:DesiredName:StoragePool
hdisk10:::dataAndMetadata:0:tiebr_disk
Ha a másik node-on a pv neve más, ne törődjünk vele. Vegyük észre, hogy itt NINCS sem primary, sem backup server megadva, csak az adott node-on a PV neve, a DiskUsage, FailureGroup, és az uj NSD neve.
2., Hozzuk létre az NSD-t és ellenőrizzük
# mmcrnsd -v no -F /etc/gpfs_tiedsk

Látjuk, hogy létrejött, és ki is találta, hogy ez „directly attached”. Most pedig még meg kell mondanunk a konfignak, hogy ezt az NSD-t ,mint tiebreaker diszket kezelje:
3., Ehhez elöször le kell állítani a cluster-t, mindkét node-n.
# mmshutdown –a
4., Majd adjuk hozzá a konfigurációhoz és ellenőrizzük is le:
# mmchconfig tiebreakerDisks=”tiebr_disk”

A státuszt nézve pedig:

Failover test
Feltételek:
– 2GB LUN mindkét nodeon (meg PV-zve)
– hozzáadva data_disk nevű NSD-ként
– GPFS filesystemmel formázva
– mountolva a /gpfs/datagpfs alá
– mindkét oldalon konzisztens cluster konfig
– futó cluster mindkét node-on
Megfigyelés
A test01-es node-on létrehozok egy filet, tetszőleges tartalommal:
– azonnal megjelenik a test02 node-on is (sikeres a szinkron)
A test01-es node-t leállítom (durván, shutdown –F):
– a test02 node-n változatlanul, időbeli késés nélkül elérhető marad a fájlrendszer a rajta tárolt adatokkal
A test02-es node-n az elérhető filesystemen létrehozok egy új filet:
– nem történik replikáció sehova, hiszen a másik node down, de a logban megjelenik, hogy változás történt a GPFS-ben
A test01-s node-t újra elindítom, várok, hogy online legyen:
– onlinebe jövetele után a test01 node-on az fs mountja után azonnal megjelenik a test02 node-n létrehozott file
Következtetés
A filesystem redundancia a node fizikai hibáját emulálva teljesnek mondható.
Diagnosztika
# mmgetstate –aLs – cluster státusz (elég informatív)
# mmlsnsd – konfigurált NSD –k
# mmlsconfig – cluster konfigja
# mmlscluster – cluster info
# mmlspv – PV – NSD összerendelés lista
# mmlsfs all – összes GPFS fs mostani és konfigurálható attribútuma
# mmlsmgr – FS – manager node map
# mmlsmount all – GPFS mountok
# mmlsdisk [fsname] – NSD státusz
# mmlsnode – non-shared LUN node list
# mmdf [fsname] – filesystem counter és státusz
Log
/var/adm/ras/mmfs.log.latest – elég részletes és követhető
Cluster parancsok
# mmstartup –a – cluster onlinebe tétele az összes node-n
# mmstartup –N node1 – cluster onlinebe tétele csak a node1-n
# mmshutdown –a – cluster offlinebe tétele az összes node-n
# mmshutdown –N node1 – cluster offlinebe tétele csak a node1-n
# mmchconfig release=LATEST – cluster config szinkron
# rm -rf /var/mmfs/gen/* – teljes cluster config törlése az adott node-n (scratch)
Összegzés
Számomra a GPFS a cluster filesystem nagyon nagyszerű megvalósítását mutatta. Sokoldalú konfigurálhatósága, nem túl bonyolult, és szerintem elég könnyen átlátható konfigurálhatósága, diagnosztikája, stabilitása miatt nekem nagyon szimpatikussá vált; igazi élmény volt „megfejteni” az alapjait. A fentiekben leírtaknál lényegesen többet tud és több lehetőséget tartogat. Természetesen komoly terjedelmű és önálló irodalma van, amelyek bonyolultabb igények esetén jól használhatók, azonban a fentiekkel elindulva egy alapvető és jól működő clustert már lehet építeni.
“AIX GPFS – paralel filesystem” bejegyzéshez egy hozzászólás