CRM - instalace

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.

---