Redundáns tároló klaszter DRBD-vel és Heartbeattel forrásának megtekintése


== Röviden a DRBD-ről ==

A DRBD (Distributed Replicated Block Device) egy olyan szoftveres eszköz, amivel kettő vagy több számítógép között szinkronban lehet tartani a merevlemezek tartalmát. Ez a szinkronizáció valós időben, és a felhasználói programok számára áttetsző módon történik, mégpedig úgy, hogy egy virtuális blokkos eszköz jön létre minden DRBD kötethez.
A DRBD egyrészt egy kernel modulból áll, amivel beépül a kernel I/O alrendszerébe, másrészt felhasználói szinten futtatható adminisztrációs eszközökből, amelyek közül a legfontosabb a drbdadm. Gyakorlatilag egy rendszer felépítéséhez elég ennek a működését ismerni, ezen keresztül lehet, és érdemes használni az összes többit.

Egy DRBD node szerepe (role) szerint lehet elsődleges vagy másodlagos (primary/secondary). Az elsődleges node-on lehet írni és olvasni a DRBD által létrehozott blokkos eszközt, míg a másodlagoson nem lehet se írni, se olvasni, ide csak szinkronizáció útján juthat adat. Egy node szerepét futás közben lehet változtatni.
Egy rendszerben egyszerre egy vagy kettő elsődleges node lehet (Single-primary mode, Dual-primary mode), az előbbi tipikus konfiguráció HA klaszterekhez, az utóbbi használatához viszont valamilyen elosztott fájlrendszer (GFS, OCFS2) szükséges, és legalább 8.0-s verziójú DRBD.

A DRBD a másodlagos node-okon a helyes adatokon kívül "inkonzisztens" (inconsistent) és "elévült" (outdated) adatokat különböztet meg. Inkonzisztens adatnak nevezzük, ha olyan adat van a lemezen, ami nem tekinthető értelmesnek. Ilyen például az az adat, ami éppen olyan szinkronizálás alatt van, hogy nem tudni, melyik része aktuális, melyik nem, és hogy ép fájlrendszerrel van-e dolgunk egyáltalán. Az elévült adat ilyen értelemben konzisztens, de nem egyezik teljesen azzal, ami az elsődleges node-on található. A DRBD nem engedi ezeket a node-okat elsődlegessé tenni.


== A példarendszer ==

Mi egy elsődleges és egy másodlagos node-ot fogunk létrehozni, tehát az elsődleges gépre írunk, a másik gépre pedig replikálódni fognak az adatok a hálózaton kereszül, és ez lesz a melegtartalék. A Linux HA Project Heartbeat nevű eszközével lehet majd elérni, hogy az aktív gép szerepét átvegye a tartalék, ha az elsődleges kiesik.

A kísérlethez Debian 5.01 disztibúciót használtam, ezen fogom bemutatni, hogy mit, hogyan kell csinálni, de hasonlóan kell eljárni bármilyen más választás esetén.


== A DRBD telepítése ==

Először a DRBD-t kell telepíteni mindkét gépre, és a hozzá való kernelmodult.

<pre>
sudo apt-get install drbd8-utils drbd8-modules-2.xx.xx-xxx (az aktuális kernel verziószámának megfelelően)
</pre>

Ezután a ''modprobe drbd'' paranccsal azonnal be lehet tölteni a kernelbe a modult.

A DRBD-elrendezesben szereplo ket számítógépet úgy konfiguráltam, hogy egy nagy területet külön particionáltam, és nem mountoltam fel. Ez nálam mindkét gépen a ''/dev/sda3'', de a DRBD legújabb verziója használata esetén tulajdonképpen akármi lehetne, még másik DRBD eszköz is.
Hasznos tudni, hogy a DRBD a 7788-tól kezdve felfelé haladva két TCP portot foglal erőforrásonként (egyet-egyet a ki- és a bemenő adatoknak). Ha tűzfalat használnánk, azt most be kellene állítani. Érdemes lenne a szinkronizációhoz dedikált hálózati kapcsolatot használni, és a két gép switchét és hálózati kábeleit is replikálni, de most ezzel nem törődünk.

A DRBD konfigurációja a ''/etc/drbd.conf''-ban található.

Az elsődleges gép IP-je legyen 10.0.0.1, a másiké pedig 10.0.0.2.

<pre>
global {
# részt szeretnénk-e venni a DRBD-t használók számának felmérésében
 usage-count no;
}
common {
# A DRBD-ben háromféle replikációs mód van, Protocol A, B, és C. 
# "A" protokoll esetén kész az írás, amint az első gépen rögzítésre került, 
# és aszinkron módon kerül a másik gépre a replikált adat. 
# "C" esetén csak akkor, ha megtörtént a replikált adat kiírása. 
# A "B" valahol a kettő között helyezhető el, akkor lesz kész az írás,
# ha elküldtük a replikált adatot.
  protocol C;
}
# Egyetlen erőforrást definiálunk.
resource r0 {
  # Ga megszakad a hálózat, próbáljunk újrakapcsolódni
  syncer {
    # Itt a szinkronizáció max. bitsebességét állítjuk 30 Megabitre.
    # Különböző megfontolásokból egy 100 Mbites hálózathoz ennyit ajánlanak.
    # Ez kb. tizede egy merevlemez sebességének. Látható, hogy hálózati replikáció esetén
    # vigyázni kell, hogy ne kerüljön nagy késésbe a replikáció az írással, ha "A" protokollt
    # használunk.
    rate 30M;
  }
  net {
    on-disconnect reconnect;
  }
  # ket node van, megadható hogy melyiken hol legyen a blokkos eszköz (device), melyik lemezen
  # tárolódjon az adat (disk), milyen címen érhető el a node (address)
  # A meta-disk internal; azt jelenti, hogy a metaadatok a tároló lemez végén legyenek.
  # Lehetne más eszközre rakni, akár több erőforrásét is egyre, és többféle módon is...
  on node1 {
    device    /dev/drbd1;
    disk      /dev/sda3;
    address   10.0.0.1:7789;
    meta-disk internal;
  }
  on node2 {
    device    /dev/drbd1;
    disk      /dev/sda3;
    address   10.0.0.2:7789;
    meta-disk internal;
  }
}
</pre>

A DRBD adminisztrációs eszköz segítségével most létre kell hozni a DRBD metaadatait, és aktiválni kell az eszközöket. Mindkét gépen végrehajtandó:

<pre>
drbdadm create-md r0
drbdadm attach r0
drbdadm syncer r0
drbdadm connect r0
</pre>

Az utóbbi három helyett használható a 'drbdadm up' is, az rövidebb, és nem keverhetjük össze a sorrendet.

A DRBD, amint sikeresen elindult, a /proc/drbd-ben jelzi állapotát. Ez kezdetben tartalmaz valami ilyesmi sort:

<pre>
 0: cs:Connected st:Secondary/Secondary ld:Inconsistent
</pre>

Érthetően a kiszolgálóink nem tudják eldönteni, melyik az elsődleges node, mert mindkettő inkonzisztens állapotban van.
Kiválasztjuk a node1 nevű gépünket elsődlegesnek, és kiadom rajta a parancsot. Kicsit erőszakosnak kell lennünk, mert különben nem tehetnénk node-ot elsődlegessé inkonzisztens adattal.
<pre>
drbdadm -- --overwrite-data-of-peer primary r0
</pre>

A ''/proc/drbd''-ben máris látszik, hogy aktívan megy a szinkronizálás, és hogy mennyi ideig fog tartani. Közben az elsődleges eszköz írható, olvasható.

<pre>
1: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r---
    ns:101952 nr:0 dw:0 dr:101952 al:0 bm:6 lo:0 pe:0 ua:0 ap:0
        [>....................] sync'ed:  1.7% (6175/6275)M
        finish: 4:23:29 speed: 340 (316) K/sec
        resync: used:0/61 hits:6365 misses:7 starving:0 dirty:0 changed:7
        act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0
</pre>

* (Megjegyzés: Reménykedem benne, hogy éles környezetben ez nem tart eddig, nálam a VMWare-es gépek közt valamiért nagyon lassú volt a virtuális hálózati adapteren.)

== DRBD fail-over Heartbeattel ==

Az előbbiek végrehajtása után a ''drbadm -- primary/secondary r0'' paranccsal akármikor bármelyik node-ot ki tudnánk nevezni elsődlegesnek vagy másodlagosnak, ha nem elévült rajta az adat. Így már kezd alakulni a rendszer klaszter jellege, de ettől még mindig nem lett melegtartalék a secondary node-ból. 
Ehhez fog kelleni a Heartbeat, egy elosztott klaszter menedzser szoftver, ami megadott időközönként jeleket küld és fogad a hálózaton, ebből megállapítja, hogy a klaszter többi része üzemel-e, és ennek függvényében különböző resource agent-ek (~erőforrás ügynök...) segítségével közbeavatkozik.
Debian alatt az alábbi paranccsal telepíthető:

<pre>
apt-get install heartbeat
</pre>

A node-ok közti adatok küldésekor a Heartbeat egy közös titkot alkalmaz az azonosításra, amit a /etc/ha.d/authkeys-ben be kell állítani:

<pre>
auth 1
1 sha1 secret
</pre>

Majd a fájlra chmod 600, egyrészt biztonsági szempontból, másrészt a Heartbeat meg is követeli.

A klaszter konfigurációs fájlja a ''/etc/ha.d/ha.cf''.

<pre>
# Életjelek közti idő másodpercben
keepalive 1
# 5 másodperc után figyelmeztessen, hogy lehet hogy kiesett egy csomópont
# 10 után tekintse kiesettnek, de mikor előszor indul, csak 60 mp után
warntime 5
deadtime 10
initdead 60
# Nem baj, ha mindkét gépen a sajátja is szerepel, így legalább ugyanaz a konfigfájl használható.
# Jó esetben erre külön hálózati interfész lenne, multicast és broadcast is használható lenne
ucast eth0 10.0.0.1
ucast eth0 10.0.0.2
# itt fel kell sorolni a csomópontokat
node node1
node node2
</pre>

A Heartbeat rengeteg erőforrásfélét tud kezelni. Az erőforrások kezelése különböző ágenseken keresztül történik, amik lehetnek Heartbeat erőforrás scriptek, LSB init scriptek, vagy OCF kompatibilis ágensek.
A Heartbeat erőforrás scriptek a ''/etc/ha.d/resource.d'' könyvtárban találhatóak, és paraméterezhetőek. Nekünk most a drbddisk nevű kell. Az erőforrást a ''/etc/ha.d/haresources'' fájlban lehet beállítani:

<pre>
node1 drbddisk::r0
</pre>

A node1 a "preferrált node", vagyis a szolgáltatás névleges tulajdonosa. A drbddisk a Heartbeat erőforrástípus neve, és az r0 paraméterrel adjuk át, hogy melyik DRBD erőforrást kezelje. Mindkét gépen ugyanezt kell beállítani, különben - ahogy a Linux HA dokumentációban szerepel - RosszDolgokFognakTörténni. (Lásd: http://www.linux-ha.org/BadThingsWillHappen)

Ezután mindkét gépen elindítjuk a Heartbeat szolgáltatást:
<pre>
/etc/init.d/heartbeat start
</pre>
Most, ha az elsődleges gépen újraindítjuk a szolgáltatást, ezt látjuk:

<pre>
Stopping High-Availability services:
Done.

Waiting to allow resource takeover to complete:
Done.

Starting High-Availability services:
Done.
</pre>

Tehát, amikor az egyik gépen leállítjuk a szolgáltatást, megvárja leállással, míg a másik átveszi a azt a másik.
Drasztikusabb esetben (pl. kilőjük a gépet) is működik a dolog, érdemes megnézni a ''/var/log/ha-log'' fájlt.


== IP fail-over és iSCSI ==

A melegtartalék mostmár működik, csak annyi van hátra, hogy hiba esetén átvegyük a kiesett gép IP címét is. Ehhez ki kell egészíteni (természetesen mindkét gépen) a haresources fájlunkat. Az IPaddr script úgynevezett IP fail-over szolgáltatást nyújt.

<pre>
node1 drbddisk::r0 \
      IPaddr::10.0.0.1/24/eth0
</pre>

Ezzel beállítottuk, hogy a klaszter az eth0 csatolón keresztül, a 10.0.0.1 címen legyen elérhető, és hogy 255.255.255.0 legyen az alhálózati maszk. A '\' jelet a soremelés kiküszöbölésére lehet használni.

Ezután már működik a teljes klaszter, és egy IP címen kiesés esetén is mindig elérhető marad egy gép, de még fel kell telepítenünk valamilyen szolgáltatást, amin keresztül az elkészített rendszerben levő adatokat elérjük. Most egy iSCSI célpontot fogunk létrehozni, de használhatnánk bármit, amihez létezik megírt Heartbeat erőforrás típus, írunk mi magunk, vagy elegendő az init script is.
Az IETD-féle iSCSI target-et könnyen telepíthetjük:

<pre>
apt-get install iscsitarget iscsitarget-modules-2.xx.xx-xxx (az aktuális kernel verziószámának megfelelően)
</pre>

Majd csak újból ki kell egészíteni a haresources-t:

<pre>
node1 drbddisk::r0 \
      IPaddr::10.0.0.1/24/eth0 \
      iscsi-target
</pre>

Ezután a ''/etc/ietd.conf'' fájlban lehet beállítani az iSCSI targetet, hogy át tudjuk adni a kliensnek a DRBD blokkos eszközt. Ez valahogy így fog kinézni:

<pre>
Target iqn.2009-12.com.example:storage.lun1
        IncomingUser valaki titok
        OutgoingUser
        Lun 0 Path=/dev/drbd1,Type=fileio
        Alias LUN1
</pre>

Ezután készen vagyunk, már csak a kliens gépen kell konfigurálni az iSCSI-t, és lesz egy redundáns, nagy rendelkezésre állású hálózati meghajtónk.

* (Tipp: Ha szükség van rá, hasonló módon ki lehet egészíteni a konfigurációt LVM kötetkezeléssel is.)

== Források ==

* DRBD dokumentáció: http://www.drbd.org/docs/about
** Fokozottan ajánlott, olvasmányos
* Linux HA Project: http://linux-ha.com/
* The iSCSI Enterprise Target Project: http://iscsitarget.sourceforge.net/