Pacemaker (fürt)

A Wikipédiából, a szabad enciklopédiából
Jump to navigation Jump to search

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[1] (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:

A pacemaker része a legtöbb szabad linux-disztribúciónak. Az enterprise[5] 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[szerkesztés]

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,[6] melyet eredetileg a corosync(en) kifejlesztésére hoztak létre.[7] 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[szerkesztés]

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[8] 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.[7]

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[szerkesztés]

Szétesés (split-brain)[szerkesztés]

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.[9] 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[szerkesztés]

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[szerkesztés]

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[szerkesztés]

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[szerkesztés]

primitive[szerkesztés]

A primitive a fürt valamelyik csomópontján egy példányban létezik.[1] 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[szerkesztés]

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[szerkesztés]

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[szerkesztés]

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[szerkesztés]

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[szerkesztés]

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.[10]
  • 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[szerkesztés]

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[szerkesztés]

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

Lekérdezések[szerkesztés]

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[szerkesztés]

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[szerkeszté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[szerkesztés]

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[szerkesztés]

  1. ^ a b A 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ú.
  2. crm - Pacemaker command line interface for configuration and management (Ubuntu manuals)
  3. SLESHA-ban a crm shell a crmsh csomagban van, és külön kell telepíteni. Debiánban és Ubuntuban a pacemaker csomag tartalmazza.
  4. The pcs Command Line Interface (RedHat)
  5. Nem (teljesen) ingyenes disztribúció, melyhez szakmai támogatás vásárolható.
  6. Linux-HA (HA wiki)
  7. ^ a b FAQ (Pacemaker)
  8. Nem IP-címet, hanem hálózati címet kell megadni, azaz a netmask-on kívüli bitek értéke 0 legyen.
  9. A szabályos kézi leállítást a pacemaker nyilvántartja: az nem okoz szétesést.
  10. A pacemaker alaphelyzetben azt feltételezi, hogy meghibásodás esetén kézi beavatkozás kell, és nem próbálja újraindítani az erőforrást. Erről globálisan a
    crm configure property start-failure-is-fatal="false" attribútummal lehet lebeszélni.

Forrás[szerkesztés]

Kapcsolódó lapok[szerkesztés]