Pacemaker (fürt)
A pacemaker egy számítógépfürtben (clusterben) alkalmazott erőforráskezelő rendszer. Képes mind , 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 . A fürt erőforrásai a szervereken futó szolgáltatások, pl. webszerver, adatbázis szerver, , 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 -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, ) 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  project keretében folytatódott, melyet eredetileg a  kifejlesztésére hoztak létre. A heartbeat erőforráskezelőjét Andrew Beekhof fejlesztette tovább a -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 -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ó -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 -vel, mely hálózaton keresztül képes szinkronizálni a csomópontok helyi diszkjeit, és együttműködik az  és GFS2 fürt filerendszerrel is, melyek akár -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:
  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.
 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).
 A csomópont leállítja a rajta futó összes erőforrást.
 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
  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 , 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
 : 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
 : a linux számára továbbfejlesztett, párhuzamos indítást lehetővé tevő indító scriptek
 : az Ubuntu által korábban használt indító scriptek
 . 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 , 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

Jegyzetek

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

Szerverszoftverek
A pacemaker egy számítógépfürtben ( clusterben ) alkalmazott erőforráskezelő rendszer . Képes mind , 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 \ . A fürt erőforrásai a szervereken futó szolgáltatások , pl. webszerver , adatbázis szerver , , 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 -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 , ) 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öttban , melyet eredetileg erőforráskezelőnek is szántak.ben a fejlesztés a project keretében folytatódott , melyet eredetileg a kifejlesztésére hoztak létre . A heartbeat erőforráskezelőjét Andrew Beekhof fejlesztette tovább a -nál ( mely ebben az időben került a Novellhez) tól kezdve . A heartbeat0-s változataben 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 heartbeat1.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 -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ó -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 -vel , mely hálózaton keresztül képes szinkronizálni a csomópontok helyi diszkjeit , és együttműködik az és GFS2 fürt filerendszerrel is , melyek akár -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 : 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 . 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 ) . A csomópont leállítja a rajta futó összes erőforrást . 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 és esetben a leállítást mindkét csomópont megteszi , és megszűnik a szolgáltatás . A 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 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 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 , 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 \ : 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 \ : a linux számára továbbfejlesztett , párhuzamos indítást lehetővé tevő indító scriptek \ : az Ubuntu által korábban használt indító scriptek \ . 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 revProxy1 revProxy2 A fenti szabály azt jelenti , hogy revProxy1 és revProxy2 lehetőleg ne fusson egy csomóponton . Ha az átbillentés ára é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 . Hahelyettt í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ópontonpé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 , 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-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 Jegyzetek 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 Szerverszoftverek