Pacemaker

http://www.clusterlabs.org/

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ť

Instalace distribučního Pacemakeru u Debianu - alespoň tedy pro mne - pro mne vždy znamenala problém. Je to tím, že vývoj jednotlivých komponent je dost divoký a na internetu se válí hromady informací, které jsou už buď zastaralé, nebo zcela mimo mísu. Mnohdy při hledání příčiny chyby narazíte na nezodpovězené bugreporty, u kterých se už nikdo zpětně nenamáhal uvést co bylo příčinou a jak problém vyřešil.

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, 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 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, 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.

Pořadí, v jakém jsou jednotlivé komponenty uvedeny, odpovídá i pořadí, v jakém je třeba je kompilovat. Původně se ještě před sestavením crmsh musely nainstalovat tzv. glue, ale v současné době to již není nutné

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.

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 i corosync zajišťují jednu a tu samou věc, tudíž je nelze spouštět oba zároveň. Pacemaker může stejně používat vždy jen jeden z nich a nikdy ne oba dva najednou. Navíc v případě chybné konfigurace může docházet i k nežádoucím kolizím v rámci infrastruktury clusteru.

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 nod-1 node nod-2 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

http://www.corosync.org/

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.

Pro vygenerování autorizačního klíče není třeba téměř nic, kromě spuštění následujícího příkazu.. nod-1:~# corosync-keygen .. a trochy entropie. Podtržení není vůbec náhodné. Natrápil jsem se docela dlouho, než jsem zjistil, že při vzdáleném přístupu přes ssh můžete klepat do klávesnice jako zběsilí a nestane se vůbec nic. V takovém případě je třeba potřebnou entropii pro vygenerování klíče dodat jiným způsobem. Stačí k tomu kupř. paralelně spustit na stroji nod-1 příkaz find na nějaký větší rozsáhlejší adresář. O dodání potřebné entropie se pak postarají IO operace.

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:

1. zda už náhodou démon coresync neběží, abyste se nedostali do konfliktu..
2. 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 ]