Pacemaker (fürt)

A pacemaker egy számítógépfürtben (clusterben) alkalmazott erőforráskezelő rendszer. Képes mind magas rendelkezésre állásra(en), mind terheléselosztásra. Többféle operációs rendszer alatt fut, a fejlesztői platform a linux. Szabad szoftver GPLv2 licenc alatt. Bináris könyvtárai és C-headerjei a még megengedőbb LGPLv2 licenc alatt állnak.

A pacemaker feladata a fürtben az erőforráskezelés(en). A fürt erőforrásai a szervereken futó szolgáltatások, pl. webszerver, adatbázis szerver, levelezőszerver(en), stb. Kezelésen a szolgáltatások indítását, leállítását, más csomópontra mozgatását és az ehhez szükséges döntések meghozását értjük (lásd üzemeltetés alább).

A fürt csomópontjai (node-jai) közötti kommunikációt egy alsóbb réteg látja el, mellyel a pacemaker szabványos API-n keresztül kommunikál, így a kommunikációs réteg cserélhető. E szócikk írásakor általában a corosync(en)-et használják, mivel a korábbi heartbeat fejlesztése leállt.

A beállításhoz és üzemeltetéshez szükséges parancsokat shell továbbítja a fürt adminisztrátorától a pacemaker programnak, mely továbbítja valamennyi csomópontnak (ha a csomópont épp nem csatlakozik a fürthöz, akkor a csatlakozáskor). Ez azt jelenti, hogy a pacemaker shell-utasításait elég az egyik csomóponton kiadni. Két shell terjedt el a pacemakerhez, melyek szintaxisa eléggé különbözik:

• crm (debian alapú disztribúciók és SLESHA)
• pcs (Red Hat Linux)

A pacemaker része a legtöbb szabad linux-disztribúciónak. Az enterprise változatokhoz (RedHat, SLES(en)) csak kiegészítésként, külön licenc- és supportdíjért érthető el. Érdekesség, hogy még e külön díj sem tartalmazza minden komponens támogatását.

Története

A szabad forrású fürt fejlesztése a heartbeat-tel kezdődött 1998-ban, melyet eredetileg erőforráskezelőnek is szántak. 1999-ben a fejlesztés a Linux-HA(en) project keretében folytatódott, melyet eredetileg a corosync(en) kifejlesztésére hoztak létre. A heartbeat erőforráskezelőjét Andrew Beekhof fejlesztette tovább a SUSE(en)-nál (mely ebben az időben került a Novellhez) 2003-tól kezdve. A heartbeat 2.0-s változata 2005-ben jelent meg, már az új erőforráskezelővel.

2007-ben az erőforráskezelő fejlesztése OpenAIS néven külön projectben folytatódott. A projectet elsősorban a RedHat kezdeményezte. A heartbeat 2.1.3-as kiadásában elválasztották egymástól az erőforráskezelő és kommunikációs réteget. A pacemaker kommunikációs rétege a heartbeat helyett a corosync lett, de a hearbeat továbbra is támogatott maradt.

Szükséges hardver

A pacemaker fürt működéséhez legalább két számítógép szükséges azonos operációs rendszerrel, feltelepített pacemaker programmal, és a gépek (csomópontok) között hálózati összeköttetéssel. Nyomatékosan ajánlott egy második, a csomópontok közötti gerinchálózat, melyhez más gép nem férhet hozzá. Ilyenkor a szolgáltatások a publikus hálón kommunikálnak a felhasználókkal, a csomópontok a gerinchálón egymással.

A csomópontok multicast(en)-címmel találják meg egymást. Két hálókártya esetén az elsődleges IP-cím általában a szolgáltatásoké. Ilyenkor külön kell gondoskodni arról, hogy a multicast is a gerinc felé menjen. Ez biztonsági szempontból is fontos: a multicast üzenetre helyesen válaszoló gép automatikusan a fürt csomópontja lesz. (Egy hálókártya esetén a helyi tűzfalon kell biztosítani, hogy a csomópont csak a megfelelő IP-című küldőktől fogadja el a multicast címet.)

Nagyon fontos, hogy a csomópontok folyamatosan elérjék egymást hálózaton keresztül, ellenkező esetben szétesik a fürt. A corosync egy vagy két hálókártyát képes kezelni, de több hálókártya összefogható bond(en)-ba az operációs rendszer szintjén is. Ilyenkor a kieső hálókártyát (vagy kábelt) a többi képes pótolni.

A corosync-hez mellékelnek egy példa konfigurációt. A multicast cím és a (gerinc)hálózati cím javítása után a pacemaker működőképes. Fontos, hogy a /etc/corosync/corosync.conf file minden csomóponton azonos (vagy ha van közös diszk, azon) legyen.

A pacemaker+corosync pároshoz nem szükséges közös diszk (bár a legtöbb szolgáltatáshoz nyilván kell). A pacemaker képes együttműködni a DRBD(en)-vel, mely hálózaton keresztül képes szinkronizálni a csomópontok helyi diszkjeit, és együttműködik az OCFS2(en) és GFS2 fürt filerendszerrel is, melyek akár SAN(en)-on (DRBD nélkül), akár DRBD fölött használhatók a csomópontok számára közös filerendszernek.

Három vagy több csomópont esetén külön hardver szükséges ahhoz, hogy a fürt meghibásodásakor a jól működő gépek le tudják állítani a hibásakat (lásd quorum és STONITH alább).

Fogalmak

Szétesés (split-brain)

A fürtnek az az állapota, amikor (hálózati) üzemzavar folytán a csomópontok nem látják egymást. A csomópont ilyenkor nem tudja eldönteni, hogy a többi csomópont él-e, és csak a kapcsolat szakadt meg velük, vagy meghibásodtak/leálltak. A pacemakerben négy lehetőség valamelyikét lehet előre beállítani ilyen helyzetre:

1. A csomópont nem törődik a széteséssel, úgy működik tovább, mintha rajta (az általa elért csomópontokon) kívül nem lenne több élő csomópont. Ha mégis van, ezek a csomópontok is elindítják a szolgáltatásokat – azokat is, melyeknek csak egy példányban volna szabad létezniük.
2. A csomópont nem változtat az állapotán: nem állít le és nem indít el erőforrásokat (kivétel: a csomóponton futó erőforrás újraindítása, ha az hiba miatt leállt).
3. A csomópont leállítja a rajta futó összes erőforrást.
4. A csomópont leállítja saját magát is az erőforrásokkal együtt.

A szétesés különösen problematikus két csomópontból álló fürt esetén. A 3. és 4. esetben a leállítást mindkét csomópont megteszi, és megszűnik a szolgáltatás. A 2. esettel az a probléma, hogy a csomópont akkor sem veszi át a másik szolgáltatásait, ha az valóban meghibásodott. Más szóval: a fürt nem működik fürtként. Marad az első lehetőség azzal, hogy a szolgáltatások típusától függően a szétesés komoly üzemzavarhoz vezethet (pl. két gépen felhúzott azonos IP-cím).

Magas rendelkezésre állást csak nagyon biztonságos hálózati kapcsolattal, vagy legalább három csomóponttal lehet csak megvalósítani.

Quorum

A fürtben a quorum a csomópontok többsége (eggyel több, mint a csomópontok számának fele). Miután legfeljebb egy ilyen csoport lehet, ennek tagjai úgy vehetik, hogy nem szakadtak le a fürtről, és a szétesés beállításának megfelelően átvehetik az általuk el nem ért szolgáltatásokat, ill. ha a STONITH engedélyezve van, leállíthatnak más csomópontokat.

Két csomópont esetén nincs quorum (mindkettő kell a többséghez).

STONITH

A shoot the other node in the head (lődd fejbe a másik csomópontot) kifejezésből alkotott mozaikszó. Az az eljárás, amikor a többi csomópont leállítja a hibásan működő csomópontot. Erre olyankor lehet szükség, ha a hibás gép azt hiszi magáról, hogy ő működik jól, pl. a szétesés a fenti első módon van konfigurálva, és a csomópont leszakad a fürtről.

Egy másik gép leállításához speciális hardverre van szükség, pl.:

• ILO
• távvezérelhető szünetmentes tápegység vagy speciális, több tápkimenetű hardver
• SAN(en) switch (melynek átprogramozásával a STONITH-ot végző csomópont elveszi a hibás alól a diszket)
• virtuális gépben futó pacemaker/STONITH esetén a host-on keresztül állítja le a másik virtuális gépet (pl. VMware utility segítségével)

A STONITH is egy pacemaker erőforrástípus. Két csomópontos fürtben kötelezően tiltani kell, egyébként a pacemakerben nem lehet erőforrásokat létrehozni.

Attribútumok

A pacemaker működéséhez szükséges erőforrásfüggetlen paraméterek. Tipikus példa crm shellel:

crm configure property stonich-enabled=false
crm_attribute --attr-name no-quorum-policy --attr-value ignore
crm configure rsc_defaults resource-stickiness=100

Az első sor tiltja a STONITH-ot, a második széteséskor az első módot írja elő.

A pacemaker alaphelyzetben úgy gondolja, hogy az erőforrás áthelyezése az egyik csomópontról a másikra „ingyen” van, és az átesés „árát” nem számolja be a döntéseibe (lásd összetett erőforrások alább). A fenti példa harmadik sora azt mondja meg, hogy alaphelyzetben az átlökés ára 100. Az érték erőforrásonként változtatható.

Egyszerű erőforrások

primitive

A primitive a fürt valamelyik csomópontján egy példányban létezik. Lehet program (pl. webszerver), de lehet pl. IP-cím is.

Az erőforrásokhoz a pacemaker resource agenteken keresztül fér hozzá, melyek tipikusan unix shell scriptek(en), de természetesen bármilyen programnyelven megírhatók. A különböző típusok a script helyében és belépési pontjaiban különböznek:

• init scriptek
  • LSB(en): a hagyományos, /etc/init.d-beli indító scriptek szabványosított belépési pontokkal (start, stop, status) és visszatérési értékekkel
  • systemd(en): a linux számára továbbfejlesztett, párhuzamos indítást lehetővé tevő indító scriptek
  • upstart(en): az Ubuntu által korábban használt indító scriptek
• OCF(en). A heartbeat-hez fejlesztett OCF-kompatiblis scriptek a pacemakerben is megtalálhatók.
• nagios (távoli gép monitorozása) Beavatkozni ezen az agenten keresztül nem lehet.
• STONITH

A primitíveknek általában sok paraméterük van, ezek három csoportra oszthatók:

• az indító scriptnek átadott paraméterek (kulcsszó: params)
• működés közbeni paraméterek (op)
• egyéb paraméterek (meta)

Példa IP-cím erőforrás létrehozására crm shell-lel, OCF scripttel:

crm configure primitive revProxyVIP ocf:heartbeat:IPaddr params ip="172.22.2.22" cidr_netmask="16" op monitor interval="30s"

• revProxyVIP: a pacemaker-erőforrás neve
• heartbeat és IPaddr: IPaddr a script neve, heartbeat a script szállítója. (Az OCF lehetővé teszi, hogy ugyanazt a scriptet a különböző szállítók másképp írják meg.)
• monitor interval: ennyi időnként ellenőrzi a pacemaker, hogy él-e az IP-cím.

Példa webszerver erőforrás létrehozására crm shell-lel, LSB scipttel:

crm configure primitive revProxy lsb::apache2 op monitor interval="30s" op start timeout="40s" op stop timeout="60s"

• lsb::apache2: az LSB-erőforrásoknak nincs szállítójuk, így az erőforrás középső paramétere mindig üres. Az erőforráskezelő script a /etc/init.d/apache2.
• start/stop timeout: ha a script ennyi idő után nem tér vissza, a művelet sikertelen.

Összetett erőforrások

Az összetett erőforrások olyan szabályok/feltételek, melyek több erőforrás(példány)ra vonatkoznak. A szabályok általában tartalmaznak egy egész számot, mely azt mondja meg, mennyire előnyös vagy hátrányos (negatív szám) a szabály alkalmazása. A crm shellben a szám után mindig kettőspontot kell írni. Az inf: jelentése végtelen (a szabálynak mindig teljesülnie kell), a -inf: értékű szabály pedig sohasem teljesülhet (tiltás).

location

A location utasítással adhatjuk meg, melyik csomóponton (nem) szeretnénk futtatni az erőforrást, és mennyire. Példa:

crm configure location csomopont1 revProxy rule inf: #uname eq csomopont1

A fenti szabály azt mondja, hogy a revProxy erőforrás mindenképpen csomopont1-en kell fusson.

colocation

Azt adja meg, mely erőforrások (ne) fussanak ugyanazon a csomóponton. Példa:

crm configure colocation aaConstr -190: revProxy1 revProxy2

A fenti szabály azt jelenti, hogy revProxy1 és revProxy2 lehetőleg ne fusson egy csomóponton. Ha az átbillentés ára 100, és két erőforrásnak kell átesnie a csomópontváltáshoz (az IP-címnek és a reverse proxy-nak), akkor a két reverse proxy külön csomóponton fog futni, de ha az egyik csomópont leállás után visszatér a fürtbe, nincs automatikus átesés. Ha -190 helyett -210-t írtunk volna, akkor igen, azaz két élő csomópont esetén mindenképpen külön csomóponton futna a két erőforrás.

A fenti példa a terhelésmegosztás egyszerű megvalósítása. Nem kell hozzá más, csak egy olyan DNS-szerver, mely a szolgáltatás nevének lekérdezésekor véletlenszerűen hol revProxy1, hol revProxy2 IP-címét adja vissza (függetlenül attól, hogy mennyire terhelt a két futtató csomópont, hiszen a pacemaker nem tud a megosztásról. Ez az ára az egyszerűségnek.).

group

A group szabály két dolgot ad meg:

• mely erőforrásoknak kell ugyanazon a csomóponton futniuk
• az erőforrások indítási sorrendjét.

A leállítási sorrend az indítási sorrend fordítottja.

group utasítása nincs a pacemakernek. A crm shell fordítja le colocation-ra és az e szócikkben nem ismertetett order utasításra.

Példa. Ha azt akarjuk, hogy a webszerverünk és a hozzá tartozó IP-cím egy csomóponton legyen, és a pacemaker először az IP-címet húzza fel:

crm configure group revProxyGroup revProxyVIP revProxy

clone

Elemi erőforrás futtatása több példányban. Megadható, hogy a fürtben összesen hány példány fusson, és egy csomóponton legfeljebb mennyi (alaphelyzetben mindegyik csomóponton 1-1 példány). Kétféle típusa van:

• Globálisan (az egész fürtön belül) egyetlen. Pl. az IP-cím mint egyszerű erőforrás klónozható, a klón egy IP-tartomány lesz. E tartomány lesz a fürtön belül egyedi.
• Névtelen. Az erőforrás minden példánya egyforma. Egy csomóponton legfeljebb egy példány futhat, hiszen a példányok csak a csomópontok alapján különböztethetők meg. Például ha azt szeretnénk, hogy minden csomóponton fusson egy localhostra hallgató locWWW nevű webszerver (melyet reverse proxy-n keresztül érhetünk el), akkor az locWWW így konfigurálható:

crm configure primitive locWWW lsb::locwww \
        meta failure-timeout="120" op monitor interval="30s"
crm configure clone locWWWClone locWWW meta migration-threshold="2" \
        interleave=true globally-unique=false

Az első utasítás az elemi erőforrás létrehozása. A klón paraméterei:

• migration-threshold="2": az első meghibásodáskor a pacemaker megpróbálja újraindítani az erőforrást, és csak azután nyilvánítja hibásnak az erőforráspéldányt. Átesésről a fenti konfigurációban nem lehet szó, hiszen nem korlátoztuk a példányok számát, ami azt jelenti, hogy mindegyik csomóponton elindult egy példány, több pedig nem futhat.
• interleave=true: a klón példányai párhuzamosan indulnak, nem várják meg egymást
• globally-unique=false: ez adja meg, hogy névtelen, és nem globálisan egyedi a klón.

ms

Az ms lehet a multistate, de a master/slave rövidítése is. Több példányban futó, egymással nem egyenrangú egyszerű erőforrások csoportját jelöli.

Master/slave erőforrás lehet pl. a DRBD(en), ahol tipikusan az egyik gép a master, melynek diszkjét írni lehet, és ennek tartalma másolódik át a slave-ekre. Utóbbiak diszkjét csak a DRBD írhatja, a felhasználó közvetlenül nem.

Üzemeltetés

Az alábbiak csak a legfontosabb üzemeltetési feladatok megoldását írják le.

Lekérdezések

crm_mon -r -f

A fenti utasítás minden fontos változást (az erőforrásokat, azok csomópontjait, a hibákat, áteséseket) kiír a képernyőre. A képernyő csak változáskor frissül, innen lehet tudni az utolsó változás idejét.

Az erőforrások összes adatának lekérdezése:

crm configure show

Az erőforrások hibaállapota:

crm_mon -1 -t

Erőforrások indítása és leállítása

Indítás és leállítás:

crm resource start erőforrás
crm resource stop  erőforrás

A pacemaker dönti el, hogy az erőforrás melyik csomóponton induljon el, ezt paraméterrel befolyásolni nem lehet, szabállyal azonban igen:

crm configure location tmpLoc erőforrás inf: node
crm resource start erőforrás
crm configure delete tmpLoc

Az első sor létrehoz egy ideiglenes szabályt, mely a megadott csomóponthoz köti az erőforrást, majd az indítás után a harmadik sor letörli a szabályt.

Csomópontváltás

Erőforrás kézi áthelyezése a jelenlegi helyéről másik csomópontra:

crm_resource -o -f -Q -M -r erőforrás -H node

Az átlökés után a pacemaker létrehoz egy szabályt, amely megakadályozza, hogy az erőforrást az általa optimálisnak vélt helyre tegye át (esetleg vissza). Ez megakadályozza azt is, hogy az erőforrás később más csomópontra essék át. A szabályt így lehet törölni:

crm_resource -U -r erőforrás

Hibaállapot törlése

crm_resource -P                      # a teljes fürtben
crm_resource -C -r erőforrás         # egy erőforrás hibaállapot-törlése
crm_resource -C -r erőforrás -N node # a clone egy példányának hibaállapot-törlése

Források

• A scalable High Availability cluster resource manager (ClusterLabs.org)
• Pacemaker wiki (ClusterLabs.org)
• OpenStack High Availability Guide (openstack)
• Linux-HA (linux-ha.org)
• Magas rendelkezésre állású virtualizációs cluster készítése Xen, DRBD és Corosync segítségével (oktatóvideó, Linuxakadémia)
• crm(8)
• Pacemaker (Pacemaker wiki)

Kapcsolódó lapok

• Számítógépfürt
• Terheléselosztás