Az első rész elkészülte után három nappal „végre” lett egy kis akció is. Történetesen volt egy hosszabb áramszünet. Olyannyira hosszabb, hogy a gépeket tápláló szünetmenteseket sikerült lemeríteni. Természetesen mindez munkaidőn kívül történt, így minden reakció az automatikára lett (volna) bízva.

Még mielőtt belecsapnánk a lecsóba, fontos tudnod, hogy nem célom a DRBD a-tól z-ig történő ismertetése, aka. rizsát eddigi (jó?) szokásomhoz híven természetesen kihagyom, továbbra is igyekszek a lényegre törekedni. Aki a szükséges körítésre kíváncsi, az nézze meg a DRBD dokumentációt. Más szóval, ha elolvastad az első részt és átlapoztad már a doksit, akkor fogod igazán értékelni a cikket.

Nos, ami ebből az áramszünetből minket érint, az a DRBD node-ok reakciója. Nos, mindig kell egy első teszt. :) Miután visszatért az áram, „meglepő módon” nem indultak el a gépek. Az egyik elfelejtette, hogy melyik merevlemezről is kellene bootolnia, így megpróbált a legelsőnek detektáltról, sikertelenül persze.
A második elindult, de csak a RAID fele gondolta úgy, hogy neki dolgoznia kellene. Természetesen, pont az a fele, melyik darabolva volt és nem az, melyik tükrözött. Így szintén nem volt sikeres az indítás. Öröm az ürömben, hogy „mindössze” ennyi volt a gond. Az elsődleges csomóponton a RAID-et összerakva, DRBD-t élesítve minden adat sértetlen maradt. Felcsatolás után a virtuális gépet elindítva mindent ment szépen. A második node ugyanígy.

Mivel teszt környezetről beszélünk, ezért történt kísérletezés minden irányba, ami olykor a kifejezetten nem támogatott megoldásokat is magában foglalja.

Primary–Primary

Az alapértelmezett felállás eddig az volt, hogy két csomópont van: egy elsődleges és egy másodlagos. Az elsődlegesen fel lehet csatolni a fájlrendszert, lehet rá írni. A másodlagost viszont nem lehet felcsatolni, még csak olvasásra sem. Így tartja meg a rendszer a konzisztenciát, nagyon helyesen.

A DRBD azonban ismeri a Primary–Primary felállást, amikor mind a két csomópont elsődleges, így mindketten tudnak a fájlrendszerre írni. Ez egyértelműen azt a problémát vonja maga után, hogy a gépeknek tudniuk kell arról, éppen melyik állományhoz fér hozzá a másik. Ugyanis mi történik akkor, ha valaki olvas egy állományt, amíg a másik ír rá? Vagy mindketten írnak bele? Melyik maradna meg? Nos, erre találták ki az olyan speciális fájlrendszereket, mint a GVFS vagy a OCFS2. Itt a gépek értesítik egymást, hogy ki mit csinál, megadott módon zárolják az állományokat és biztosítják, hogy nem lesz ütközés. Egy ilyen összeállítása a DRBD dokumentáció alapján nem vészes.

Azt tudni kell, hogy ilyen esetben, ha mindkét rendszer komolyabb I/O műveletet végez, akkor feleződik az I/O teljesítmény. Ez kisebb állományok esetén nem vészes és egész jól optimalizálható, ugyanakkor ha két operációs rendszert telepítesz ugyanarra a kötetre, az bajos. Tudom, mert megcsináltam. :) Szóval csak csínján a rendszerekkel, érdemes átgondolni.

Mint említettem, a konkurens hozzáférés a hagyományos fájlrendszereknél gond. Eszedbe se jusson, primary–primary módban hagyományos, ext* vagy bármilyen más rendszert használni, mert nem fog menni. Tudom, mert ezt is kipróbáltam. :)

Primary–Secondory && Secondory–Primary

Ha nem szükséges a két csomópontnak egymás adatait elérni, és jól tervezhető a replikálandó adatmennyiség, akkor a klaszter helyett bármelyik, hagyományos fájlrendszer megteszi. „Mindössze” a tervezett adatmennyiségnek megfelelő méretű helyet kell megadnunk a DRBD-nek. Fontos, hogy ha egy kötet(csoport)on van az olvasható és a replikált adat, akkor ugyanúgy feleződik az I/O nagyobb műveleteknél.

Gentoo + Friss kernel + DRBD

Ha most ismerkedsz a DRBD-vel, akkor semmiképp se Gentoo-n kezdd a barátkozást. Jelenleg elég kaotikus a helyzet, ugyanis a Linux 4.0 a DRBD 8.4.5-öt tartalmazza, de a hozzákapcsolódó eszközökből a 8.4.2-es a stabil és 8.4.3-as a tesztelés alatt álló. Bár 8.4.3-as eszközökkel is sikeresen összeállít rendszer és működött is, lehet csak szerencsém volt. Szóval melegen ajánlott verzióazonos eszközöket használni, amire amúgy figyelmeztet is a rendszer.

Ha rám hallgatsz, a kezdeti lépéseket Ubuntu szerverrel teszed meg. Máshol sem bonyolultabb a dolog, de itt apt-get install és minden járulékos teher, mint a kernel modul automatikus betöltése és hasonlók megtörténnek. Automatikusan, ami kényelmes, mert mi tesztelünk és eredményeket akarunk. Most és azonnal! :)

Különböző verziójú DRBD csomópontok

A fenti Gentoo-s élményt „természetesen” összekötöttem azzal, hogy a másik oldalon egy Ubuntu 14.04.2 szerver volt, azaz szinte semmilyen verzióazonosság nem volt a két DRBD között, mégis működött. Ennek ellenére ha jót akarsz magadnak, törekedsz a verzióazonosságra.

Gyakorlatban ez úgy néz ki, hogy…

Ennyi elég is volt az elméletből és a próbálkozásokból, lássuk azt, hogy mi is működik és hogyan.

Struktúra és konfigurálás

A DRBD erőforrásokat definiál. Egy gépen lehet több erőforrás is. Ezeket az erőforrásokat a /etc/drbd.d/erőforrás-neve.res állományban definiáljuk. Működő konfigurációt fogok mutatni, ezért esetünkben a neve legyen database.res. Egy erőforráson belül értelmezünk Primary, azaz elsődleges (aki írhat & felcsatolhat) és Secondory, azaz másodlagos csomópontot. Az erőforrások függetlenek egymástól, tehát lehet az adott gép 20 erőforrásnál elsődleges és 30-nál másodlagos. Nem érdekes. Csak azokat a változásokat emelem ki, melyek az alapértelmezett konfigurációhoz képest változtak (vagy értelme van beszélni róla).

resource datatabase {

Definiáljuk a database erőforrást. Ilyen néven fogunk rá később hivatkozni.

protocol A;

Háromféle protokoll létezik. A, B és C.
Visszafele haladva, a C protokoll a legszigorúbb és egyben a legbiztonságosabb. Ha ezt használod, akkor biztos lehetsz abban, hogy az adat a helyi és a távoli csomóponton is háttértárra íródott. Ez azzal jár, hogy az elsődleges gép addig vár a másodlagosra, amíg az be nem fejezi az írást. Biztonságos, de lassú. Ha primary–primary felállásban gondolkozol, csak ez jöhet szóba.

A B protokoll esetén a DRBD megvárja, amíg az adat elér a másik gépig, de nem várja meg, amíg az ki is írja. Természetesen helyben már ki kellett írni.

Az A protokoll mindössze annyit vár, hogy kiíródjon az adat a helyi háttértárra és az adat másolata készen álljon a küldésre.

data-integrity-alg crc32c;

Gép tesztelésére, hogy bírja-e a (és elég stabil-e) a DRBD megpróbáltatásait. Ha a naplózásban Digest integrity check FAILED jellegű üzeneteket kapsz, akkor valami gáz van, mindenképp vizsgáld ki. Lehet válogatni md5, sha1 és crc32c között alapértelmezetten, de bármelyik, a kernel által támogatott algoritmust lehet integritás ellenőrzésre használni. Kikapcsolható. A crc32c tökéletes nekem, mert jelzi a hibát, ugyanakkor elég gyorsan fut az öreg CPU-kon is.

 cram-hmac-alg md5;
shared-secret "jóhosszústring";

Mikor a felek azonosítják egymást a shared-secret értékét ezzel a HMAC algoritmussal ellenőrzik az értékeket.

A teljes konfigurációs állomány egyben:

resource database {
        startup {
                wfc-timeout  15;
                degr-wfc-timeout 60;
                become-primary-on database-host;
        }
        net {
                protocol A;
 
                cram-hmac-alg md5;
                shared-secret "jóhosszústring";
                data-integrity-alg crc32c;
 
                after-sb-0pri discard-zero-changes;
                after-sb-1pri discard-secondary;
                after-sb-2pri disconnect;
        }
 
        on database-host {
                device /dev/drbd0;
                disk /dev/md0;
                address 10.10.91.21:7788;
                meta-disk internal;
        }
        on Ingvildr {
                device /dev/drbd0;
                disk /dev/md1;
                address 10.10.91.3:7788;
                meta-disk internal;
        }
}

Ennyi lenne, amit pluszban, az alapértelmezett beállításokhoz képest érdemes tudni & meglépni.

Buktatók

A /etc/hosts állományban rögzíteni kell a host neveket. Nincs ezzel gond, de egyszerű benézni a kisbetű-nagybetű különbségeket, ha az ember fáradt. Ugyanez igaz az erőforrás csomópontjainak a megadásakor: kisbetű-nagybetű érzékeny! Igen, én is benéztem. Van ez így. :)

Mindenképp egyezzenek a méretek a két oldalon. Ha a secondary nagyobb, az nem baj, de kisebb ne legyen. Jah, igen: ha virtuális gép(ek)kel dolgozol és nem foglalod le előre a tárhelyet, hanem dinamikusan, szükség szerint allokálod, akkor figyelj oda, hogy a lemezkép ne legyen nagyobb, mint a DRBD helye, különben megint hülyén nézés van. Nekem kb. 1 MB-tal volt nagyobb a lemezkép a kelleténél, ami ugye df -h esetén már kerekítési nagyságrend. Szóval ne centizdbyte-old ki a méreteket, ha nem muszáj. Amúgy megéri előre lefoglalni, mert jót tesz I/O-nak, de az már egy más téma.

Ha azt mondom, hogy a drbdadm nem viszi túlzásba a panaszkodást, ha hiba van, akkor még igen finoman fogalmazok. Szóval kedvenc parancsod a dmesg, mert a rémek onnan jönnek. Izé logok. Amúgy ha már rávetted a drbd-t, hogy fusson, akkor egész sokat naplóz. Figyelmesen olvasd, mert néha nem elég feltűnően szól, hogy „töki, a secondary túl kicsi!”

Jó tesztelést! Kihagytam valamit?

Azt hiszem, mindent elmondtam, amit szerettem volna. Ha úgy érzed, hogy elnagyoltam ezt & azt, akkor írj bátran! Akár kommentben, akár közvetlenül az „Írj” menüpontból.