Pacemaker
Pacemaker je open source implementací CRM (Cluster Resource Management). Jde o sadu démonů, která v rámci HA clusteru zajišťuje spouštění či naopak zastavování konkrétních služeb. Tyto služby se nazývají zdroje (resource). Zdrojem může být prakticky libovolná služba, kterou má HA cluster zajišťovat (web server, virtuální stroj, sdílený disk & etc..).
Pacemaker vzniknul jako fork projeku Linux-HA, jehož cílem bylo vytvořit komplexní řešení clusterové infrastruktury postavené na Linuxu. Na počátku šlo o jeden balík démonů, ale postupem času se projekt rozdělil na tři samostatné větve:
- Nejprve se oddělil vývoj Cluster Glue (vývoj je samostatný od verze 1.0). Cluster Glue - 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 Název tohoto démona 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 Andrew Beekhof začal pracovat na novém CRM, který by odstranil omezení původního verze. Ta totiž, mimo jiné, umožňovala vytvořit cluster pouze o dvou nodech. 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 pak došlo na konci roku 2007.
Jak nainstalovat Pacemaker
Na stránkách http://www.clusterlabs.org je popsán postup kompilace ze zdrojových kódů . Doporučuji v každém případě tuto stránku prostudovat, protože obsahuje aktuální informace o jednotlivých verzích.
Kompilovat Pacemaker a jeho komponenty na každém nodu zvlášť je pochopitelně nesmysl. Proto je žádoucí vědět, jak se dělají binární instalační balíčky, a sestavené komponenty distribuovat jejich prostřednictvím. Ovšem k tomu, aby bylo možné udělat kvalitní instalační balíčky je nezbytných několik předpokladů:
- mít alespoň elementární znalosti balíčkování
- mít určité zkušenosti s kompilací software
- mít vhodné testovací stroje
- mít čas a chuť
Zpočátku jsem ani nechápal, jak to všechno vlastně funguje a jak spolu jednotlivé komponenty souvisí. Kupříkladu jsem ani netušil, že heartbeat i corosync dělají defakto to samé, tudíž lze použít buď jedno, nebo druhé ale nikoliv obojí najednou.
Když jsem instaloval svůj první cluster[1], tak jsem po několikadenním trápení a nesčetných pokusech došel k tomu, že postup instalace, kterým jsem začal na samém počátku, byl v zásadě správný:
Instalace Pacemakeru z distribučních balíků
nod-1:~# apt-get install corosync pacemaker
|
Veškeré potřebné balíky si APT doinstaluje sám. Současné distribuční balíky se již víceméně snaží sledovat aktuální trend. V zásadě tedy není důvod zdržovat se tvorbou vlastních instalačních balíčků. Problém tkví v tom, že instalace distribučního Pacemakeru je rozsekaná do hromady balíků u kterých - obzvláště pro začátečníka, není zřejmá vzájemná souvislost:
- Kupř. u starší verze mi nebyla jasná závislost na instalačních balících heartbeatu. Proč bych je měl cpát do systému, když Pacemaker stejně používá corosync? Teprve když jsem začal dělat vlastní balíky jsem zjistil, že i když Pacemaker primárně pro komunikaci používal corosync, využíval zároveň i některé knihovny z heartbeatu. U novějších verzí Pacemakeru to již neplatí.
- Některé banální operace vyvolávaly u distribučních balíků
Kernel panic
celého systému. - Debianí verze Pacemakeru (1.0.10) tehdy byla notně zastaralá. Aktuální vývojová verze byla 1.1.5
- Poslední kapkou byla změna verze perlu. Na samotný Pacemaker to sice vliv nemělo, jenže balík
net-snmp
, který byl vyžadován pro podporu snmp, kterou jsem chtěl otestovat, měl s kompilací problém
Proto jsem si tenkrát udělal instalační balíky pro architekturu amd64 vlastní. Ovšem od jara r. 2011 se ledy pohnuly. V říjnu 2011 změnil corosync způsob komunikace, zcela opustil heartbeat a začal využívat externí knihovnu libqb. Distribuční balíky v debianu byly aktualizovány a i když stále z hlediska zpracování vypadaly chaoticky, byl Pacemaker verze 1.1.6 v Debianu sqeezy již použitelný - i přesto, že s knihovnou libqb tehdy ještě neuměl spolupracovat.
Sestavení ze zdrojových kódů
Ovšem sestavení Pacemakeru na míru se může hodit, pokud chcete mít všechny komponenty v jednom binárním balíčku, do kterého vám nebude vrtat APT, takže jistě vezmete zavděk následujícími poznámkami, které se mohou hodit i při řešení problémů s distribuční instalací:
Instalace Pacemakeru se v současné době skládá z následujících komponent:
- libqb
- git://github.com/asalkeld/libqb.git - je základní knihovna pro lokální komunikaci mezi jednotlivými komponentami Pacemakeru. Přes tuto knihovnu pracuje pacemaker se soubory corosyncu, který v nich řeší obsah, který má být předmětem síťové komunikace s ostatními nody. Tato lokální komunikace ale nemusí nutně jít přes souborový systém[2] nodu. Může probíhat i přes vyhrazený prostor paměti nodu.
- corosync
- https://github.com/corosync/corosync.git - se stará o síťovou komunikaci nodů. Po spuštění si otevře síťové porty (ve výchozím stavu používá UDP porty 5404 a 5405) přes které komunikuje na příslušném síťovém segmentu s corosyncy jiných nodů, a přijatou komunikaci zapisuje přes libqb do lokálního systému, kde s ní dále pracuje pacemaker.
- pacemaker
- https://github.com/ClusterLabs/pacemaker.git - je soubor lokálních démonů, které spouští hlavní démon pacemakerd, přes které probíhá obsluha systému nodu. Součástí je sada utilit, jimiž lze Pamemaker spravovat. Aktuální konfigurace Pacemakeru, která se prostřednictvím corosyncu distribuuje mezi ostatní nody je v XML formátu.
- resource-agents
- https://github.com/ClusterLabs/resource-agents.git - jsou obslužné skripty, které spouští pacemaker v případě, že při vyhodnocení aktuální konfigurace a zpracování dat přijatých corosyncem dojde k závěru, že je to třeba. Tyto skripty - agenti - zpracují příslušnou akci, předanou jako parametr, a o jejím výsledku zpětně informují pacemaker. Zde vzniká nejvíc problému s tím, že Pacemaker dělá něco jiného, než se od něj očekává!!! Vývoj linuxových distribucí je totiž velmi rychlý, a agenti jsou psáni vesměs na míru komerčních distribucí, které ovšem mají s principu za aktuálním stavem zpoždění. Proto někdy nezbývá nic jiného, než si napsat agenty vlastní. Ale o tom více viz kapitola CRM (Resource Agents)
- crmsh
- https://github.com/crmsh/crmsh - je konzolová utilita, pro obsluhu Pacemakeru, napsaná pro Python verze 2.x, které předcházel obslužný skript (napsaný v shellu), který byl součástí pacemakeru. Tento skript za vývojem Pacemakeru beznadějně zastarával, proto začal Dejan Muhamedagic, který byl tehdy vývojářem pro SUSE, vyvíjet crmsh. Po něm převzal štafetu Kristoffer Grönlund[3], který jej vyvíjí dosud. Nástroj se do značné míry podobá původnímu crm, ale má mnoho zajímavých vychytávek, o kterých se původnímu nástroji ani nesnilo.
U binární distribuce jsou jednotlivé komponenty v samostatných balících. Bohužel z jejich názvů není patrné že patří k sobě. Proto pro pojmenování binárního balíku používám název základního CLI nástroje Pacemakeru - crm
, který je ovšem ve skutečnosti součástí komponenty crmsh a pro práci s Pacemakerem není nezbytně nutný.
V některých postupech, které jsou k nalezení na internetu, se místo crm používá pcs:
- pcs
- https://github.com/feist/pcs.git - je podobně jako crmsh konzolová utilita, která zastřešuje utility Pacemakeru. Je rovněž napsaná v jazyce Python, ovšem od verze 0.9.147 je kompatibilní nejenom se starší verzí 2.6, ale také s novější verzí 3.x To je velká výhoda oproti crmsh Na druhou stranu jeho použití není tak komfortní. Stojí za ní vývojáři fy. Red Hat, která potřebovala v r. 2011 - podobně jako fa. SuSe - nástroj, který by nahradil beznadějně zastaralé crm, které bylo součástí pacemakeru. Proto se s ní nejčastěji setkáte u distribucí, za kterými stojí právě tato firma.
Na co dávat pozor
Komunikační vrstva
Aby o sobě nody vzájemně věděly, musí spolu v rámci infrastruktury clusteru vzájemně komunikovat. Pacemaker umožňuje k této vzájemné komunikaci použít dvě různé implementace: heartbeat nebo corosync.
Heartbeat
http://linux-ha.org/wiki/Heartbeat
Jak už bylo zmíněno heartbeat byl komunikační démon z původního projektu Linux-HA. Ovšem pro vývojáře CRM bylo mnohem výhodnější než vyvíjet vlastní implementaci přejít na corosync, za jehož vývojem stojí Red Hat. Proto jeho vývoj opustili. Dalšího vývoje Heartbeatu se chopil Linbit (viz DRBD8, ale výsledný produkt se zdá mnohem méně stabilní. 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 u corosyncu
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 |
Konfigurace corosyncu
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ž budete vědět co vlastně CRM s naklepanou konfigurací dělá.
Především je třeba mít na paměti, že konfigurace pro corosync 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 se 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 CRM i na dalších nodech. Pokud je vše v pořádku, měly by se - po určitém intervalu - postupně 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
2 Nodes configured, 2 expected votes
0 Resources configured.
============
Online: [ nod-2 nod-1 ]
|
- ↑ Svůj první cluster jsem instaloval v dubnu 2011 v prostředí Debianu squeezy. Od té doby jsem sestavil dalších pět - symetrických i asymetrických. Osobně preferuji Debian unstable, ale některé s nich jsou nad Debianem wheezy a spravuji i několik starších symetrických clusterů, které běží ještě na Debianu lenny.
- ↑ V rámci souborového systému corosync zapisuje své soubory do adresáře
/dev/shm
. To je však v reálu symlink na adresář/run/shm
. V tom je nejčastější problém s rozběháním pacemakeru, že tento adresář neexistuje, případně do něj nelze zapisovat. U pacemakeru lze totiž výchozí umístění těchto komunikačních souborů ovlivnit při kompilaci, a je-li zvolena špatná cesta může vzniknout problém. Jen pro úplnost dodávám, že pro něj je výchozí cesta/var/run/shm
. Cílem je již zmíněný adresář/run/shm
, protože/var/run
je symlinkem na/run
. Může se však stát, že je při kompilaci špatně interpretován prefix a výchozí adresář pro pacemaker bude${prefix}/var/run/shm
! - ↑ Kristoffer Grönlund vyvíjí i webové rozhraní pro Pacemaker hawk, s kterým však nemám žádné zkušenosti. Podle iformací na webu je napsaný v Ruby on Rails a nepoužívá apache2 ale webový server puma rovněž napsaný v Ruby