Az AIX GPFS fájlrendszeréről szóló írás után felmerült a gondolat, hogy hogyan is lehetne Linux platformon hasonló megoldást találni. A GPFS szépen lekezeli a magas rendelkezésre állás koncepcióját mind kötet , mind fájlrendszer szempontjából. Linux-on egyik, ha nem is kizárólagos megoldásként ezt két komponensből láttam jelenleg megvalósíthatónak. Kötetszinten a DRBD, míg fájlrendszer szintjén az OCFS2 valósítaná meg a redundanciát illetve egyszersmind a közös, konkurrens módon használható fájlrendszert. Lássuk, hogyan!
Magas rendelkezésre állású fájlrendszer Linux-on – DRBD és OCFS2 használatával
Környezet:
A tesztkörnyezet a már megszokott virtuális platform volt, az Oracle Virtualbox 4.2.6-os verzióján.
Node1:
RAM: 512MB
OS: Ubuntu 12.04 server LTS
Storage: sda (8GB ) ill. sdb (2GB)
Network: eth0 (192.168.55.16/24) ill. eth1 (10.0.0.1/22)
Node2:
RAM: 512MB
OS: Ubuntu 12.04 server LTS
Storage: sda (8GB ) ill. sdb (2GB)
Network: eth0 (192.168.55.17/24) ill. eth1 (10.0.0.2/22)
A node-ok sdb diszkjei fogják a magas rendelkezésre állású fájlrendszert tartalmazni, a node-ok közötti kommunikáció pedig az eth1 interfaceken fog történni, erre a célre egy kicsi, mindössze 2 kiosztható IP-t tartalmazó hálózatot hoztam létre.
Topológia:
Mi a DRBD és mire jó?
A DRBD a Distributed Replicated Block Device rövidítése, amit talán Elosztott replikált blokkeszköz-ként lehetne fordítani. Ez így talán nem sokat mond első olvasásra, de ha egy olyan RAID1-ről (mirror) beszélünk, ahol a lemezek közötti tükrözés nem egy fizikai gépen belül szoftveresen vagy hardveresen valósul meg, hanem kettő fizikai gép diszkjei vagy partíciói közt, akkor már elképzelhető, mi is ez. Az átviteli közeg, amely a diszkek közötti tükrözést biztosítja, pedig IP alapú hálózat lesz.
Mi az OCFS2 és mire jó?
Az OCFS2 az Oracle Cluster FileSystem rövidítése. Ez egy általános célú közös-diszk alapú fájlrendszer mely a magas rendelkezésre állást és performanciát egyaránt hivatott biztosítani. Főbb szolgáltatásai közé tartozik a node-menedzsment (az konfiguráció alapján induláskor „összerakja a filesystem cluster-t), az önellenőrzés (IP kommunikáció által figyeli, hogy mi a helyzet a node-okon) illetve Distributed Lock Management, azaz az elosztott file lock kontrollálása.
Miért van szükség mindkettőre?
A DRBD blokkszinten biztosítja a replikációt, de a fájlrendszerről ami rajta foglal helyet, kevés tudomása van. Nem foglalkozik azzal, hogy a tükör melyik tagjára ki ír, csak szolgai módon replikálja azt, továbbá a „hagyományos” fájlrendszerek (pl. ext3) sincsenek erre figyelemmel. El lehet képzelni, hogy ha mindkét node-on egymásról tudomást sem véve elkezdenek az alkalmazások írogatni rá a DRBD tömbre, annak nem lesz jó vége és adatvesztéshez fog vezetni. Itt kap központi szerepet az OCFS2, „aki” minderre figyelemmel van, és lekezeli ezeket a problémákat, többek közt éppen azáltal, hogy kontroll alatt tartja a node-okon az OCFS2 fájlrendszert.
Az előkészületek:
Mindkét node-on installáljuk a DRBD-t és az OCFS2-t
# apt-get install drbd8-utils
# apt-get install ocfs2-tools
Ubuntu-n ez szimpla dolog, mivel a csomag installja a megfelelő kernel-modulokat is installálja, de főleg más esetben győzödjünk meg arról, hogy a drbd modul a betöltődött-e:
# modprobe drbd
# dmesg
Fontos továbbá, hogy mindkét node fel tudja oldani a másik címét hosztnév alapon.
# cat /etc/hosts
A konfiguráció:
DRBD réteg konfigja
Először a drbd konfigurációját fogjuk felépíteni, ezt mindkét node-on konzisztensen meg kell tennünk.
Hozzunk létre egy pl. disk.res nevű filet az /etc/drbd.d/ könyvtár alatt.
# vi /etc/drbd.d/disk.res
A tartalma legyen a következő:
resource r0 {
protocol C;
syncer { rate 50M; }
startup {
-
wfc-timeout 15;
degr-wfc-timeout 60;
become-primary-on both;
}
net {
-
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
cram-hmac-alg sha1;
shared-secret „secret”;
}
on node01 {
-
device /dev/drbd0;
disk /dev/sdb1;
address 10.0.0.1:7788;
meta-disk internal;
}
on node02 {
-
device /dev/drbd0;
disk /dev/sdb1;
address 10.0.0.2:7788;
meta-disk internal;
}
}
Ide kívánkozik egy rövid magyarázat. A konfig vége, gondolom, egyértelmű, leírja, ki kicsoda, melyik node milyen IP-n, stb. A ‘net’ szekcióban azonban van négy sor, amelyik bővebb értelmezésre szorul, már csak fontossága miatt is:
allow-two-primaries; (engedi az egyenrangú node-okat (primary-primary)
after-sb-0pri discard-zero-changes; (split-brain esetén az utoljára írt node-t veszi referenciának a sync-nél)
after-sb-1pri discard-secondary; (split-brain esetén a a primary-ról syncel a secondaryra )
after-sb-2pri disconnect; (split-brain esetén ha semmiképp sem tudja kitalálni, hogy melyik node diszkje tartalmazza a helyes adatot, akkor lekapcsolja őket, és manuálisan kell kijelölnünk a konzisztens node-t)
Mentsük el a filet, majd ugyancsak mindkét nodeon adjuk ki a következő parancsot:
# drbdadm create-md r0
Körülbelül a következőt fogjuk kapni:
# /etc/init.d/drbd start
A következő parancsot már csak a primary node-on kell kiadnunk:
# drbdadm — –overwrite-data-of-peer primary all
Ezután a két node között a diszkek szinkronizációjának meg kell történnie, lássuk, ezt hogyan tudjuk követni:
# /etc/init.d/drbd status (ezt megnézhetjük a „cat /proc/drbd” paranccsal is!)
Az alapkoncepciónk viszont az volt, hogy mindkét node primary node lesz, szemben az eddig elért primary-secondary státusszal, így egy lépés még hátravan, amit most csak a secondary node-on kell kiadnunk:
# drbdadm primary r0
OCFS2 réteg konfigja:
A DRBD tömbünk kész van, aktív mindkét node-n. Ahogy az elején említettem, szükségünk van egy „intelligens” fájlrendszerre, aki a lock és konkurrens használat problémáit lekezeli illetve kiküszöböli.
Az installálás már megtörtént, konfiguráljuk is be, hasonlóképp és mindkét node-on:
# vi /etc/ocfs2/cluster.conf (figyeljünk a tabokra a „:”-os szekciók után kötelező! Enélkül hibás betöltést fogunk kapni.)
cluster:
-
node_count = 2
name = www
node:
-
ip_port = 7777
ip_address = 10.0.0.1
number = 1
name = node01
cluster = www
node:
-
ip_port = 7777
ip_address = 10.0.0.2
number = 2
name = node02
cluster = www
Mentsük el a konfigfájlt, majd mindkét szerveren olvastassuk fel ezt a konfigot:
# dpkg-reconfigure ocfs2-tools
# mkfs.ocfs2 -L „www” /dev/drbd0
# mkdir /www
Adjuk az /etc/fstab végéhez a következőt, hogy reboot után automatikus legyen a csatolás!
/dev/drbd0 /var/www ocfs2 noauto,noatime,nodiratime 0 0
# mount /www
Amint ez megtörtént, a „dmesg” kimenetben ilyesmit láttam:
Failover-test:
Természetesen mindez, amit az előbbiekben leírtam, csak teória marad, ha nem teszteljük le a rendszerünket, olyasformán, mintha valóságos kiesés lenne valamelyik node-on. Annak érdekében, hogy ez kellőképpen „durván” történjen, mind a DRBD-t, mind az OCFS kommunikációt, tesszük mégpedig ezt olyanformán, hogy egyszerűen kilőjük az egyik, majd a másik node-ot.
A node01-es node-on létrehozok egy filet, tetszőleges tartalommal:
– azonnal megjelenik a node02 node-on is (sikeres a szinkron)
A node01-es node-t leállítom (durván, shutdown –F now):
– a node02 node-n változatlanul, időbeli késés nélkül elérhető marad a fájlrendszer a rajta tárolt adatokkal
A node02-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 próbálkozik a node01-hez kapcsolódni
A node01-s node-t újra elindítom, várok, hogy online legyen:
– onlinebe jövetele után a node01 node-on az fs mountja után azonnal megjelenik a node02 node-n létrehozott file
Konklúzió:
A node kiesését szimulálva a fájlrendszer stabilitása, konzisztenciájés redundanciája a kiesés utáni visszaállást követően teljes és hibátlan.
Diagnosztika:
Túl sok diagnosztikai parancsot nem találtam az OCFS-hez. A logok természetesen segítenek, nem is keveset és a bennük szereplő sorok is egyértelműek. Ami lekérdezést ehhez találtam:
Backup: # o2image /dev/sdb1 sdb.metadata
Restore: # o2image -I /dev/sdb1 sdb.metadata
Összegzés:
Az AIX-on régebben összerakott GPFS cluster után már nem volt nagy meglepetés, hogy létezik ilyen megoldás. Azonban ez egy kétlépcsős megoldás volt, és noha a lépések logikailag nagyon hasonlók, azért mégis öröm és sikerélmény volt, hogy legalábbis a tesztek során nagyon szépen és követhetően, mindenféle rejtélyes hiba nélkül és megbízhatóan sikerült működésre bírni ezt a megoldást. Fontos itt is -akárcsak a GPFS esetében- megjegyezni, hogy a clusterezés itt is csak a fájlrendszerre vonatkozik, tehát az alkalmazásokat, amik esetlegesen használják ezt a magas rendelkezésre állású fájlrendszert, egy másmilyen cluster megoldással kell lekezelnünk.
Ez nagyon jo lett fiu! minden a howto-k szerint! holnap megy produktivba! :)
Köszönöm szépen! Jól is műxik!
„Adjuk az /etc/fstab végéhez a következőt, hogy reboot után automatikus legyen a csatolás!
/dev/drbd0 /var/www ocfs2 noauto,noatime,nodiratime 0 0”
A „noauto” mount opció eltávolítása után ki lehet venni a local-ből mount-ot :)
Ami pedig a kernelmodulokat illeti, a „modinfo” nem csak egy betöltött, hanem bármelyik telepített modulról szolgáltat információkat – tehát a betöltés bizonyságául a dmesg-ben látható printk-k mellett inkább az lsmod lehetne reprezentatív.
Jogos :) Van akinek jobb a szeme, mint nekem :) Biztos korral jár :D
Van a linuxos mount parancsnak egy _netdev opciója, amivel meg tudod oldani. Idézet a man page-ből:
_netdev
The filesystem resides on a device that requires network access
(used to prevent the system from attempting to mount these
filesystems until the network has been enabled on the system).
Üdv:
Tóni
Nem tudom mennyire éles rendszeren akarjátok használni ezt a megoldást. A DRBD-vel kapcsolatosan elég sok rosszat hallottam (Nekem sem üzemelt valami fényesen). Erősen teszteljétek a „split-brain”, node elhalás stb esetekben.