CRM - instalace

Na stránkách http://www.clusterlabs.org je popsán postup kompilace ze zdrojových kódů . Ovšem kompilovat v rámci clusteru zvlášť CRM na každém nodu je nesmysl. Proto je lepší mít binární instalační balíčky, které lze mezi ně distribuovat. Ovšem udělat kvalitní instalační balíčky vyžaduje 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 přes APT

Instalace distribučního Pacemakeru u Debianu byla pro mne na samém počátku dost zmatečná, neboť ji provázela spousta protichůdných informací posbíraných všude možně po internetu. Situaci komplikovala skutečnost, že jsem zpočátku dost dobře nechápal, jak to všechno vlastně funguje a především netušil, že heartbeat i corosync dělají defakto to samé. (viz ...)

Po několikadenním trápení a nesčetných pokusech jsem došel k tomu, že postup instalace, kterým jsem začal na samém počátku byl v zásadě správný:

nod-1:~# apt-get install corosync pacemaker

Veškeré potřebné soubory si pak APT doinstaloval sám. Jenže..

Debianí instalační balíky pro Pacemaker mi přišly nějak divně a komplikovaně udělané.

• Především mi nebyla jasná závislost na instalačních balících heartbeatu. Proč bych je měl cpát do systému, když stejně používám corosync? Teprve když jsem začal dělat vlastní balíky jsem zjistil že i když Pacemaker primárně pro komunikaci používá corosync, využívá zároveň přitom i některé knihovny od heartbeatu
• Některé banální operace v rámci CRM vyvolávaly Kernel panic celého systému
• Debianí verze Pacemakeru mi navíc přišla zastaralá. Verze 1.0.10 se objevila téměř před rokem, zatím co aktuální vývojová verze byla 1.1.5
• Poslední kapkou byla změna verze perlu. Což o to na samotný Pacemaker to sice vliv nemělo, jenže balík net-snmp, vyžadovaný pro kompilaci podpory snmp, kterou jsem chtěl otestovat měl s kompilací problém

Proto jsem si udělal instalační balíky pro architekturu amd64 vlastní.

Ovšem jak se zdá, ledy se od jara t.r. (května 2011) přece jenom pohnuly. I když i nadále z hlediska zpracování působí distribuční balíček chaoticky, byl aktualizován, takže aktuálně je v distribuci jak ve sqeezu, tak unstable k dispozici Pacemaker verze 1.1.6

Není tedy důvod se zdržovat údržbou vlastních instalačních balíčků.

Kromě toho v současné době (říjen 2011) změnil corosync způsob komunikace - využívá při ní externí knihovnu libqb se kterou Pacemaker zatím pracovat neumí.

Pokud někdo použil instalační balíčky z naší repository, pak je přechod na distribuční verzi poměrně jednoduchý.. 1, Nejprve přes apt-get nechte odinstalovat všechny balíčky co začínají crm 2, Pak je třeba odebrat také tyto balíčky apt-get remove libplumbgpl2 libpils2 libsnmp15 libsnmp-base 3, Jelikož distribuční balíčky pracují s dynamicky nastavenou systémovou skupinou a uživatelem, je třeba odstranit stávajícího uživatele a skupinu (jinak by instalace zkončila chybou) deluser hacluster; delgroup haclient 4, A posledním krokem je odstranění adresáře, ve kterém jsou uloženy cib soubory. Pozor - nastavená pravidla je třeba předem odzálohovat, jako čistý text! rm /var/lib/heartbeat 5, Nyní již lze nainstalovat distribuční Pacemaker. Aby si sebou přitáhnul všechny potřebné knihovny z oficiální repository, je vhodné přidat přes volbu -t že má tahat z unstable apt-get -t unstable install pacemaker

Reinstalace corosyncu přepíše stávající konfigurační soubor, proto je třeba v souboru /etc/corosync/corosync.conf nahradit localhostovou adresu (127.0.0.1) adresou jakou má stroj v rámci síťové infrastruktury clusteru a rovněž změnit i multicastovou adresu (na 224.0.0.1)

Aby v balících nebyl takový nepořádek, jako u oficiální distribuce, zvolil jsem základní pojmenování balíků podle CLI nástroje Pacemakeru - crm. Využil jsem toho, že v oficiální distribuci žádný jiný balíček stejného jména není, a zároveň tak mohl vytvořit tzv. meta-balíček, který sám o sobě nic neobsahuje, ale pouze na základě závislostí stáhne a nainstaluje ve správném pořadí vše potřebné. Jen pro srovnání uvádím v pořadí nutném pro kompilaci názvy dílčích instalačních balíků a v závorkách názvy jejich distribučních ekvivalentů.

1. crm-glue (cluster-glue)
2. crm-agents (cluster-agents)
3. crm-heartbeat (heartbeat)
4. crm-corosync (corosync)
5. crm-pacemaker (pacemaker)

Pokud si přidáte do zdrojů pro APT mou repository...

deb http://support.dce.felk.cvut.cz/debian/ unstable main
deb-src http://support.dce.felk.cvut.cz/debian/ unstable main

Pak můžete (po aktualizaci zdrojů) nainstalovat Pacemaker včetně veškerých závislostí jedním příkazem..

nod-1:~# apt-get install crm

V repository je také aktualizovaná verze lm-sensors a proti ní zkompilované binární balíčky net-snmp v. 5.6.1 (v oficiální distribuci je verze 5.4.3)

Rekompilace ze zdrojových balíčků

Pokud si budete chtít zkusit rebuildovat Pacemaker na míru z mých zdrojových balíčků a máte k dispozici několik strojů, ze kterých budete pak chtít cluster sestavit, můžete zkrátit čas kompilace použitím distcc.

Jeden ze strojů si zvolte jako kompilační stroj pro sestavování balíků (klient) a na ostatních nakonfigurujte a spusťe distcc jako server. Jelikož se serverová část distcc spouští na všech strojích, můžete využít, podobně jako já funkčního CRM pro jeho spouštění a zastavení.

distcc

sám o sobě není kompilátor, ale frontend pro gcc vyvíjen od r. 2002

Jde o jednoduchou aplikaci typu klient-server, která umožňuje rozdělit kompilaci mezi více strojů a využít tak v případě potřeby jejich výpočetní výkon ke zkrácení doby kompilace. Instalace distcc je v Debianu triviální. Na každém z nodů, které mají být součástí kompilační farmy stačí spustit:

apt-get install distcc

Konfigurace distcc

Součástí instalačního balíčku je jak klientská aplikace distcc, tak serverový démon distccd'. Ten po svém spuštění vytvoří několik procesů vyhlížejících svou dávku ke kompilaci. Každý z nodů tak může fungovat zároveň jako klient i jako server. Pro sestavování instalačních balíků však lze používat kupř. virtuální stroj a nody využívat jen při vlastní kompilaci.

Efektivita použití distcc záleží na několika faktorech:

• Jak rychlá a spolehlivá je síť, skrz kterou klient komunikuje se servery?
• Jak jsou výkonné servery?
• Jak je výkonný server?

Při pomalejší síti lze využít pro přenos dat mezi klientem a servery lzo kompresi

Klient

Je stroj na kterém bude probíhat sestavování instalačních balíků. Je třeba si uvědomit, že vlastní kompilace nemusí být při sestavování balíku ta nejnáročnější činnost. Záleží také na tom, jak rychle stíhá klient načítat z disku a rozesílat data ke kompilaci. Propustnost sítě zase ovlivňuje to, jak stíhají servery vracet zpracované bloky.

U distcc při kompilaci komunikuje vždy klient se servery, nikoliv servery mezi sebou!

Klientská aplikace distcc si při svém spuštění přebírá seznam serverů z proměnnné $DISTCC_HOST, není-li nastavena, načte si jej z konfiguračního souboru /etc/distcc/hosts. Stroje mohou být identifikovány buď:

• doménovým jménem (pokud mají vlastní doménu) nebo
• svým hostname (pokud pro ně existuje záznam v souboru /etc/hosts) nebo
• IP adresou

Jednotlivé identifikátory jsou odděleny mezerami.

Server

Je stroj na kterém běží serverová část - démon distccd. U Debianu si parametry při spouštění démon distccd spouštěný přes init natahuje z konfiguračního souboru /etc/default/distcc.

Využití ccache

Utilita ccache funguje tak, že archivuje dílčí výsledky při všech kompilacích, takže pokud se má kompilovat již jednou zpracovaný kus kódu, použije se - pokud nedošlo k nějakým změnám - kód z ccache. Pozor na to že:

• ccacche lze použít pouze na straně klienta
• ccache nelze používat v PUMP módu.

pump

Standardně distcc řeší pouze kompilaci, všechny zbývající operace, jako např. kompilace výsledného bajtkódu, atp. už probíhají na klientovi. distcc-pupmpje varianta, která umožňuje distribuovat i jiné operace prepocesoru. Má to však několik omezení:

1. především jak na straně klienta i serveru musí být použita verze distcc-pump novější než 3.0
2. hlavičky i cesty ke knihovnám musí být během kompilačního procesu jak na straně klienta tak serveru stejné.
3. komplexní

Vytvoření zdroje pro spouštění distcc

primitive DistCC lsb:distcc clone clDistCC DistCC

Jelikož se distcc na jednotlivých nodech spouští init skriptem, není třeba zadávat žádné jiné parametry. Aby se služba spouštěla současně na všech aktivních nodech, je třeba primitivu DistCC nastavit jako klon. Tím bude zajištěno, že spuštění a případné zastavení služby proběhne na všech aktivních nodech současně.

U clusteru pouze se dvěma nody by se dal použít i Master/Slave mod

Použití distcc

• Při testovacím buildování deb balíku na klientském stroji..

stroj:~# MAKEFLAGS="CC=distcc" fakeroot debian/rules binary -j16

• Při rebuildování zdrojového deb balíku na klientském stroji..

user@stroj:~$ MAKEFLAGS="CC=distcc" fakeroot dpkg-buildpackage -j16

• Při kompilaci vanilla kernelu na jednom z nodů..

nod-1:~# MAKEFLAGS="CC=distcc" make oldconfig nod-1:~# time MAKEFLAGS="CC=distcc" make -j16 nod-1:~# time MAKEFLAGS="CC=distcc" make deb-pkg -j16