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.

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