Magas rendelkezésre állású fájlrendszer Linux-on – DRBD és OCFS2 használatával

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:

A fenti ábrán szereplő topológiához képest a változás mindössze annyi lesz a mi tesztünkben, hogy mindkét node-on aktív maradhat a fájlrendszer.

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

# modinfo drbd

A fentiekhez hasonló kimeneteket kell látnunk, ha minden rendben van.

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:

Indítsuk el a drbd daemon-t:

# /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!)

Ugyanez, ha a szinkron végbement:

A fenti kimenetek a secondary node-ról lettek vizsgálva, és a második kimeneten azt is látjuk, hogy a megelőző „Incosistent” státuszból „UpToDate” lett mindkét node-n. Persze, egy ez gyors local LAN és a résztvevő diszkek is csak 3GB-osak a teszt miatt, tehát ez igen gyors volt, de ez a gyakorlatban lehet több száz GB is, a node-ok közti sávszélesség pedig nem 1GB/s, hanem mondjuk csak 10MB/s. Szóval ez hosszú folyamat is lehet.

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

Itt már látjuk, hogy a node-jaink konzisztensek és primary státuszban vannak mindketten.

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

Itt fogunk még kapni kérdést arra vonatkozólag, hogy pl. elinduljon-e boot-kor az OCFS, mi a cluster neve (ez a konfigunkban www), továbbá pár timeout és ezzel összefüggő paraméterről (ezeket hagyhatjuk a felajánlott értéken). Ha minden ok volt, akkor elindul az OCFS és kapunk egy, az alábbihoz hasonló kimenetet:

Láthatjuk még továbbá egy „dmesg” és „modinfo” kimenetből is, hogy időközben itt bizony modul töltődött be:

Ha mindent jól csináltunk, akkor most képesnek kell lennünk létrehozni az OCFS2  fájlrendszert is a DRBD tömbünkre (és ennek természetesen mindkét node-on látszania is kell!) Ezt a parancsot már elég az egyik node-on kiadni.

# mkfs.ocfs2 -L „www” /dev/drbd0

Próbáljuk fölmountolni, természetesen mindkét oldalon:

# 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:

Nagyon szépen látszik, hogy a node-ok az OCFS2 szintjén is „észrevették egymást”.  Valamilyen oknál fogva a mount nem történt meg újraindításkor, ezért hozzáadtam még a következő sort a /etc/rc.local file végéhez mindkét node-on (az exit 0 elé): mount /dev/drbd0. Ezután az újraindítást követően , kézi beavatkozás nélkül is sikeresen elérhető volt a fájlrendszer.

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:

Továbbá találtam  még egy parancsot, mely képes egy adott device meta-datáit backupolni ill. restoreolni:

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.

Magas rendelkezésre állású fájlrendszer Linux-on – DRBD és OCFS2 használatával” bejegyzéshez 7 hozzászólás

  1. „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.

  2. 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

  3. 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.

Hozzászólás a(z) Varga Tamás bejegyzéshez Válasz megszakítása

Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük