Pacemaker
CRM (Cluster Resource Management) je sada démonů, která v rámci HA clusteru zajišťuje vzájemnou komunikaci a manipulaci se zdroji (resource). Zdrojem může být prakticky libovolná služba, kterou má HA cluster poskytovat (web server, virtuální stroj, sdílený disk & etc..). Existuje více řešení CRM, mezi open-source patří Pacemaker.
Pacemaker
Pacemaker je CRM manager, který zajišťuje spouštění či naopak zastavování konkrétních služeb (nastavení IP adres, spouštění serverů aj.) na jednotlivých nodech. Aby věděl která služba má kde být spuštěna, musí mít k dispozici démona, který udržuje v rámci infrastruktury clusteru vzájemnou komunikaci mezi jednotlivými nody.
Pacemaker vzniknul v rámci projeku Linux-HA, což mělo být komplexní řešení clusterové infrastruktury, postavené na Linuxu. Na počátku šlo o jeden balík démonů, ale postupem času se vývoj projektu rozdělil na tři samostatné větve:
- Nejprve se oddělil vývoj Cluster Glue (samostatný od verze 1.0), což je sada démonů zajišťujících spolupráci nodu s infrastrukturou clusteru.
- vývoj démona obstarávajícího vzájemnou komunikaci nodů, s názvem heartbeat se oddělil od hlavního projektu od verze 2.1.4 Jeho název se často používal jako synonymum pro celý projekt Linux-HA.
- samostatný vývoj správce zdrojů (Resource Agents) s názvem Pacemaker začal na sklonku roku 2003, kdy začal Andrew Beekhof pracovat na novém CRM, který by odstranil omezení původního verze. Ten totiž, mimo jiné, umožňoval vytvořit cluster maximálně se dvěma nody. První zárodek Pacemakeru se objevil 30. července 2005 v rámci vydání Heartbeat v. 2.0.0. K úplnému osamostatnění projektu došlo na konci roku 2007.
Pacemaker komunikuje prostřednictvím heartbeatu, nebo corosyncu s CRM na ostatních nodech a zároveň s lokálním systémem nodu.
- cib - zajišťuje replikaci konfigurace, tak aby byla na všech nodech identická
- crmd - interpretuje pravidla nastavená v konfiguraci a podle potřeby volá buď lokální lrmd, stonith nebo pengine
- stonith - zajišťuje v případě potřeby odstřelení vzpurného nodu
- lrmd - spouští či zastavuje lokální služby v rámci nodu
- attrd
- pengine - zajišťuje správné pořadí spouštění služeb, aby nedošlo případně ke konfliktu
Heartbeat
http://linux-ha.org/wiki/Heartbeat
Jak už bylo zmíněno Heartbeat byl pokračováním původního projektu Linux-HA. Původní vývojáři jej však opustili, protože je pro ně výhodnější stavět nad corosyncem, za jehož vývojem stojí Red Hat. Vývoje Heartbeatu se chopil Linbit (viz DRBD8, ale výsledný produkt má asi nějaké nepříjemné bugy, které se v našem konkrétním případě projevovaly tím, že při spouštění heartbeatu byl vždy nabourán linuxový kernel, což vedlo k opakovaným restartům systému.
Jinak konfigurace Heartbeatu je poměrně triviální. Viz obsah souboru /etc/heartbeat/ha.cf
use_logd off
logfile /var/log/ha-log.log
debugfile /var/log/ha-debug.log
crm on
autojoin none
mcast6 eth3 ff02::1 694 1 0
#mcast eth3 224.0.0.1 694 1 0
node charlie-brown
node snoopy
pacemaker
|
Poznámky ke konfiguračnímu souboru:
- Cesta
/etc/ha.d
je u Debianu pouze symlink na adresář/etc/heartbeat
- Nody se hledají přes multicast. V ukázkové konfiguraci je nastaveno, že pakety se mají posílat na rozhraní eth3.
- Identifikace lokálního nodu se provádí přes jeho hostname
- ve výchozí stavu use_logd loguje do /var/log/daemon.log
Heartbeat až do verze 3.0.4 (vydané v prosinci 2010) nepodporoval IPv6 protokol, a maintainer debianího instalačního balíku heartbeat-3.0.4-1 opoměl plugin mcast6 do něj přidat!
|
Autorizace u heartbeatu
..se provádí na základě klíče v souboru /etc/heartbeat/authkeys
. Pozor! Výchozí jméno i obsah tohoto autorizačního souboru jsou jiné, než při autorizaci co používá #corosync.
/etc/heartbeat/authkeys
je textový soubor, kde je uveden typ použitého šifrování a heslo, případně jeho hash. Viz níže:
auth 1
1 sha1 (stdin)= df6973cd744d4de118b85c72eee3625
|
Corosync
Corosync Vzniknul jako derivát projektu openais, jehož cílem byla implementace jednotného API pro komunikaci v rámci clusteru.
Vývoj původního projektu openais trval téměř šest let a během té doby si mnoho projektů vytvořilo své vlastní komunikační mechanismy. Proto byl na základech tohoto projektu postaven Corosync Cluster Engine, který umožnil jejich sjednocení do jednoho komunikačního rozhraní a protokol openais se tak stal jejich pojítkem.
Autorizace
Před vlastní konfigurací corosyncu si musíte vygenerovat autorizační klíč, kterým se budou mezi sebou jednotlivé nody vzájemně autorizovat. Autorizační klíč pro corosync je umístěn v binární klíčence, což je (ve výchozím nastavení) soubor /etc/corosync/authkey
. Nejde tedy o textový soubor, jako v případě heartbeatu.
Tento vygenerovaný klíč pak musíte rozkopírovat mezi jednotlivé nody. U všech musí být stejný a na stejném místě - v adresáři /etc/corosync
Konfiguraci HA clusteru vám velmi usnadní když si mezi jednotlivé nody rozkopírujete veřejné ssh klíče. jak na to viz kapitola Přihlašování přes ssh bez nutnosti zadávat heslo |
Instalace
Instalace na Debianu pro mne byla na samém počátku dosti zmatečná, neboť ji provázelo spousta protichůdných informací posbíraných po internetu. Situaci také komplikovalo to, že jsem dost dobře nechápal, jak to všechno vlastně funguje a hlavně že netušil, že heartbeat i corosync dělají defakto to samé.
Po několikadenním trápení a nesčetných pokusech jsem došel k tomu, že postup instalace, kterým jsem začal byl v zásadě správný:
nod-1:~# apt-get install corosync pacemaker
|
Veškeré potřebné soubory si apt-get doinstaloval sám.
Konfigurace
Hromadu problémů jsem si navařil tím, že jsem zkoušel aplikovat nejrůznější postupy co se válí po netu. Doporučuji na ně zapomenout přinejmenší do doby, než si přečtete následující podkapitolu a budete vědět co vlastně CRM s naklepanou konfigurací dělá.
Především je třeba mít na paměti, že počáteční konfigurace corosyncu nemá(!) nic společného s konfigurací zdrojů (resources) v CRM. |
Po instalaci najdete konfigurační soubor corosync.conf
v adresáři /etc/corosync
. Kdo by to čekal, že?
Jeho struktura je rozdělena do několika částí. V podstatě není třeba nic víc, než nakonfigurovat sekci totem
(což je název protokolu, který byl vytvořen v rámci projektu openais). Tzn.:
- u položky
bindnetaddr
doplnit platnou IP adresu nodu, na kterém se instalace provádí (ve výchozí volbě je uvedena lokální IPv4 adresa 127.0.0.1) - u položky
mcastaddr
uvést multicastovou adresu - a používáte-li při multicastu IPv6 protokol, tak ještě
nodeid
. Což může být libovolné celé (32bitové) číslo, které by mělo být v rámci clusteru jedinečné.
Tím by měla být konfigurace nodu hotova.
Předtím, než se corosync pokusíte spustit zkontrolujte:
- zda už náhodou démon coresync neběží, abyste je nedostali do konfliktu..
- a zda je v konfiguračním souboru /etc/default/corosync nastavená hodnota proměnné START na "yes"
Pokud je vše v pořádku, můžete zkusit corosync nahodit.
Naběhne-li vše v pořádku, měli byste najít ve spuštěných procesech něco podobného..
nod-1:~# ps axf
...
29601 ? Ss 0:00 ha_logd: read process
29602 ? S 0:00 \_ ha_logd: write process
29802 ? Ssl 0:00 /usr/sbin/corosync
29813 ? SLs 0:00 \_ /usr/lib/heartbeat/stonithd
29814 ? S 0:00 \_ /usr/lib/heartbeat/cib
29815 ? S 0:00 \_ /usr/lib/heartbeat/lrmd
29816 ? S 0:00 \_ /usr/lib/heartbeat/attrd
29817 ? S 0:00 \_ /usr/lib/heartbeat/pengine
29818 ? S 0:00 \_ /usr/lib/heartbeat/crmd
|
Stejným způsobem pak postupně nakonfigurujte a spusťte i další nody. Pokud je vše v pořádku, měly by se vám po určitém intervalu vaše nody objevit ve výstupu monitorovacího příkazu crm_mon Viz níže..
nod-2:~# crm_mon -1
============
Last updated: Thu Apr 7 15:52:20 2011
Stack: openais
Current DC: nod-1 - partition with quorum
Version: 1.0.9-da7075976b5ff0bee71074385f8fd02f296ec8a3
4 Nodes configured, 2 expected votes
0 Resources configured.
============
Online: [ nod-2 nod-1 ]
OFFLINE: [ nod-1 nod2 ]
|
Také jste si všimli té podivnosti, že přestože jsou nody pouze dva, oznamuje crm_mon čtyři? A ke všemu to vypadá, jako by se ve výpisu nějak duplikovaly. A proč je duplikovaná skupina uvedena jako OFFLINE? Tahle věc mě hodně mátla, než jsem narazil (víceméně náhodou) v jedné diskuzi proč to tak je a jak to vyřešit..
Jak je to možné aby byly nody online a zároveň offline?!
Příčina tkví (pravděpodobně) v tom, že v manuálu je sice uvedeno, že máte nastavit při IPv6 v konfiguraci nastavit nějaké nodeid
, ale corosync si nejspíš ještě nějaké interní nodeid
vygeneruje sám při spouštění. Záznam načtený z konfiguračního souboru tedy není spojen s žádnou běžící službou, a proto je ve stavu OFFLINE.
K řešení mne přivedla zmínka v diskuzi[1] s odkazem do manuálu na stránkách http://www.clusterlabs.org
Celý postup v následujícím příkladu demonstruji na stroji nod-2. Pro zbývající nody je postup v podstatě identickž
Jelikož je komunikační vrstva v rámci clusteru dominantní, je třeba při odstraňování nadbytečného záznamu nod kterého se to týká z komunikace vyřadit. Předtím je však třeba zjistit jeho nodeid
, se kterým je záznam svázaný...
nod-2:~# crm_node -i
270
nod-2:~# /etc/init.d/corosync stop
Stopping corosync daemon: corosync.
|
Další postup pokračuje na "živém" nodu clusteru. Nejdřív se kontrolním výpisem ujistíme, že stroj nod-2 skutečně přestal komunikovat. A pak odstraníme záznam spjatý s jeho nodeid
.
nod-1:~# crm_mon -1
============
Last updated: Thu Apr 7 18:49:06 2011
Stack: openais
Current DC: nod-1 - partition WITHOUT quorum
Version: 1.0.9-da7075976b5ff0bee71074385f8fd02f296ec8a3
4 Nodes configured, 2 expected votes
0 Resources configured.
============
Online: [ nod-1 ]
OFFLINE: [ nod-1 nod-2 nod-2 ]
nod-1:~# crm_node -R 270
The supplied command is considered dangerous. To prevent accidental destruction of
the cluster, the --force flag is required in order to proceed.
nod-1:~# crm_node --force -R 270
nod-1:~# cibadmin --delete --obj_type nodes --crm_xml '<node uname="nod-2"/>'
nod-1:~# cibadmin --delete --obj_type status --crm_xml '<node_state uname="nod-2"/>'
|
Po této operaci můžeme corosync znovu nahodit. A vida! Jeden záznam už přestal být duplicitní!
nod-2:~# /etc/init.d/corosync start
Starting corosync daemon: corosync.
nod-2:~# crm_mon -1
============
Last updated: Thu Apr 7 18:51:53 2011
Stack: openais
Current DC: nod-1 - partition with quorum
Version: 1.0.9-da7075976b5ff0bee71074385f8fd02f296ec8a3
3 Nodes configured, 2 expected votes
0 Resources configured.
============
Online: [ nod-2 nod-1 ]
OFFLINE: [ nod-1 ]
|
Stejný postup pak zopakujeme i pro ostatní nody.