A pacemaker egy számítógépfürtben (clusterben) alkalmazott erőforrás-kezelő 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ükA pacemaker nem tudja, hogy egy program milyen szolgáltatást nyújt a felhasználónak. Mindössze annyit tud, hogyan kell elindítani, leállítani, és ellenőrizni, hogy fut-e. Ettől lesz általános célú. (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: crmcrm - Pacemaker command line interface for configuration and management (Ubuntu manuals) (debian alapú disztribúciók és SLESHASLESHA-ban a crm shell a crmsh csomagban van, és külön kell telepíteni. Debiánban és Ubuntuban a pacemaker csomag tartalmazza.) pcs (Red Hat Linux)The pcs Command Line Interface (RedHat)
A pacemaker része a legtöbb szabad linux-disztribúciónak. Az enterpriseNem (teljesen) ingyenes disztribúció, melyhez szakmai támogatás vásárolható. 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ás-kezelőnek is szántak. 1999-ben a fejlesztés a project keretében folytatódott,Linux-HA (HA wiki) melyet eredetileg a kifejlesztésére hoztak létre.FAQ (Pacemaker) 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ímNem IP-címet, hanem hálózati címet kell megadni, azaz a netmask-on kívüli bitek értéke 0 legyen. 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 szabályos kézi leállítást a pacemaker nyilvántartja: az nem okoz szétesést. 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ás-fü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-kompatibilis 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.