CRM - instalace

Z DCEwiki
Verze z 6. 4. 2016, 10:10, kterou vytvořil Keny (diskuse | příspěvky)
(rozdíl) ← Starší verze | zobrazit aktuální verzi (rozdíl) | Novější verze → (rozdíl)
Skočit na navigaci Skočit na vyhledávání

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[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ů

Poznámka
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.
Poznámka 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.

Na co dávat pozor


  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.
  2. 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!
  3. 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