CRM (konfigurace zdrojů)

CRM (Cluster Resource Management) pracuje se "zdroji" (resource). "Zdroje" jsou ve své podstatě pojmenované konfigurace agentů, co zajišťují běh různých, vzájemně na sobě závislých služeb. Agent je ve své podstatě spustitelný skript, připravený takto pojmenovanou konfiguraci zpracovat a na základě výsledku jejího zpracování pak vrací hodnotu, kterou crm zobrazuje jako stav zdroje.

Takovým zdrojem je kupř. služba která zajistí nahození IP adresy, spuštění webového serveru, namountování adresáře do určitého bodu, aj.

Jednotlivé zdroje mohou (ale nemusí) být na sobě závislé. Některé mohou být vázané jen na učité stroje a u jiných zase může být důležité pořadí spouštění - tohle všechno řeší Pacemaker.

init skripty (LSB) versus zdroje

Při použití Pacemakeru by se měly prostřednictvím init skriptů automaticky spouštět pouze služby, které jsou nezbytné pro jeho nahození. Spouštění ostatních služeb by již měla ošetřit jeho konfigurace.

Je třeba si uvědomit, že init skripty jsou určeny k lokálnímu použití a samy o sobě nemají k dispozici prostředky k tomu, aby mohly zajistit, po spuštění nedojde ke konfliktu s konfigurací jiného stroje.

Pacemaker - díky tomu, že využívá v rámci infrastruktury clusteru komunikační vrstvu (corosync nebo Heartbeat) - ví o tom, kde co zrovna běží a tak může potencionálnímu konfliktu včas zabránit. Pochopitelně pouze v případě, že jde o službu kterou spravuje.

CIB

Interně jsou veškerá data clusteru, včetně konfigurace a stavových informací, uchovávána v XML souboru zvaném CIB ( zkratka z angl. Cluster Information Base ). Ten je lokálně uložen jako /var/lib/heartbeat/crm/cib.xml a průběžně replikován démonem /usr/lib/heartbeat/cib mezi ostatní nody.

Celá konfigurace a aktuální stav clusteru je rozparcelována v CIB souboru do dílčích elementů, se kterými lze pracovat jako s tzv. scope

configuration - Obsahuje konfigurační nastavení, které lze upravovat také přes CLI

crm_config - nastavení clusteru

nodes - nody

resources - zdroje

constraints - pořadí spouštění a lokace zdrojů

status - Obsahuje informace o aktuální situaci zdrojů na jednotlivých nodech

node_state

lrm - pro každý nod existuje samostatný element

lrm_resources - elementy s informacemi o aktuálním stav zdrojů na příslušném nodu

Veškeré operace s CIB se provádí výhradně prostřednictvím nástrojů k tomu určených. Při každé změně se totiž původní CIB soubor přejmenuje a místo něj se zapíše pod stejným názvem CIB nový. Současně se při tom vygeneruje jeho kontrolní součet. Pokud by došlo k dodatečné editaci, tak by se stal tento kontrolní součet neplatný, což by Pacemaker vyhodnotil jako chybu - proto se důrazně nedoporučuje editovat tyto soubory přímo!

Ke správě CIB souboru lze použít buď přímo konzolové nástroje k tomu určené (cibadmin, crm_attribute, ...) nebo CLI rozhraní, které je z hlediska administrace intuitivnější. Ze CLI rozhraní se nejčastěji používá shellový crmsh, který se spouští příkazem crm, ale lze použít také nástroj pcs, napsaný v jazyce python (Red Hat).

SUSE Linux Enterprise má pro crmsh navíc k dispozici také webové rozhraní Hawk (HA Web Konsole), naprogramované v programovacím jazyce ruby.

cibadmin

Lze brát jako základní nástroj pro manipulaci s CIB souborem. Jeho prostřednictvím lze nejenom data z CIB souboru získat, ale také měnit. V jistém smyslu se jedná o XML editor, který může pracovat v několika módech, specifikovaných jako atribut.

--query | -Q

Umožňuje z CIB souboru vypsat určitou oblast (scope), která odpovídá příslušnému XML elementu, ale také obsah všech XML elementů, které vyhoví předanému Xpath výrazu.

Výpis elementu rsc_order s identifikačním jménem or-test nod-1:~# cibadmin --query --xpath "//rsc_order[@id='or-test']" <rsc_order id="or-test" first="fs-users" then="test-ip"/> Položka je součástí oblasti constraints, takže se při jejím výpisu objeví mezi ostatními elementy typu rsc_order nod-1:~# cibadmin --query --scope constraints <constraints> ... <rsc_order id="or-test" first="fs-users" then="test-ip"/> ... </constraints>

--delete | -D

Odstraní první element, který vyhoví předaným parametrům

Odstranění elementu rsc_order s identifikačním jménem or-test nod-1:~# cibadmin --delete --xml-text '<rsc_order id="or-test"/>'

--erase | -E

Na rozdíl od --delete odstraní všechny elementy, které vyhoví předanému parametru.

--create | -C

Umožní vytvořit nový element v určité oblasti. Jeho syntaxe však musí být správná. Pokud syntaxe nového uzlu obsahuje chybu, nebo položku, která z hlediska syntaxe do elementu nepatří, pak změna realizována není. Příkaz nejprve vypíše chybu a za ní vysype celý XML obsah CIB souboru. Z chyby však lze vyčíst proč ke vložení uzlu nedošlo.

Vložení elementu rsc_order s identifikačním jménem or-test, kterým se nastaví pořadí spouštění zdrojů test-ip a fs-users nod-1:~# cibadmin -C --scope constraints --xml-text '<rsc_order id="or-test" first="fs-users" then="test-ip"/>'

--modify | -M

Umožňuje element upravit (nemám odzkoušeno)

--replace | -R

Umožňuje nahradit buď obsah celého CIB souboru, nebo jenom jeho vybrané oblasti či elementu obsahem předaným jako XML buď přímo na řádce jako hodnota atributu --xml-text, nebo ze souboru s modifikovaným obsahem přes atribut --xml-file, kde se jako hodnota předá cesta k modifikovanému XML obsahu.

Nahrazením elementu resources elementem bez potomků dojde ke zrušení všech nakonfigurovaných nodů nod-1:~# cibadmin --replace --scope resources --xml-text '<resources/>' Ale naimportováním upraveného obsahu resources lze naopak zdroje také přidat nod-1:~# cibadmin --query --scope resources > resources.xml nod-1:~# vi resources.xml ... nod-1:~# cibadmin --replace --scope resources --xml-file $HOME/resources.xml

--patch | -P

--upgrade | -u

--bump | -B

Dotazováním přes cibadmin lze ale zjistit řadu jiných zajímavých údajů. Např. zda-li je instance CRM zdroje na aktuálním nodu v režimu Master nebo Slave nebo kdy byla naposledy spuštěna, či zastavena. To se může hodit při psaní vlastních agentů ( viz kapitola CRM (Resource Agents)), obzvláště těch, které potřebujou znát informace o stavu zdroje na ostatních nodech. Pacemaker má (na rozdíl od dřívější verze Heartbeatu) sám o sobě pouze omezené množství (shellových) proměnných, které lze v agentu využít a ty se navíc ještě týkají spíš lokálního prostředí. Z CIB souboru toho lze zjistit mnohem více.

crm_mon

Pro monitorování aktuálního stavu clusteru lze použít nástroj crm_mon. Je-li démon /usr/lib/pacemaker/crmd v běhu, vypadá monitorovací výstup clusteru bez nakonfigurovaných a spuštěných zdrojů takto..

nod-1:~# crm_mon -1 Last updated: Mon Nov 4 16:38:01 2013 Last change: Mon Nov 4 15:07:05 2013 via crm_attribute on nod-2 Stack: classic openais (with plugin) Current DC: nod-1 - partition with quorum Version: 1.1.10-368c726 2 Nodes configured, 2 expected votes 19 Resources configured Online: [ nod-1 nod-2 ]

Výstup vypadá stejně jako výstup příkazu status CLI nástroje crm. Nástroj crm_mon ale umožňuje tento výstup vypsat také v XML formátu, který lze prohánět přes nějaký XML parser, nebo jej zapsat do souboru ve formátu HTML. Toho lze využít k monitorování stavu zdrojů z clusterového prostředí přes webové rozhraní. Je ovšem třeba zajistit, aby webový server měl právo exportovaný soubor číst. Jsou na to dva způsoby:

Nastavení práv adresáře s HTML výstupem

nod-1:~# mkdir /www_adresar_pro_monitor nod-1:~# ls -ald /www_adresar_pro_monitor drwxr-xr-x 2 root root 4096 lis 4 13:37 /www_adresar_pro_monitor nod-1:~# chmod g+rs nod-1:~# ls -ald /www_adresar_pro_monitor drwxr-sr-x 2 root root 4096 lis 4 13:37 /www_adresar_pro_monitor nod-1:~# chmod o-rwx nod-1:~# ls -ald /www_adresar_pro_monitor drwxr-s--- 2 root root 4096 lis 4 13:37 /www_adresar_pro_monitor nod-1:~# crm_mon --daemonize --as-html /www_adresar_pro_monitor/monitor.html nod-1:~# ls -al /www_adresar_pro_monitor drwxr-s--- 2 root www-data 4096 lis 4 13:47 . drwxr-xr-x 4 root root 4096 lis 4 13:37 .. -rw-r----- 1 root www-data 1954 lis 4 13:47 monitor.html

Změna výchozího nastavení umask pro nové soubory

Ve skriptu, kterým se monitor spouští se před vlastním spuštěním přenastaví hodnota umask pro nově vytvářené soubory na 027 (výchozí hodnota je 022)

#!/bin/bash umask 027 crm_mon --daemonize --as-html /www_adresar_pro/monitor.html

crm_standby

Wrapper pro crm_attribute, kterým lze nod řízeně odporoučet do stavu standby. Tím lze zabránit nepředvídaným akcím Pacemakeru pokud má nod projít aktualizací distribuce, aj. úkony, které by mohly ovlivnit spuštěné služby.

nod-1:~# crm_standby -G -N nod-2 scope=nodes name=standby value=off nod-1:~# crm_standby -N nod-2 -v on

Stejná operace realizovaná prostřednictvím crm

crm(live)node# standby nod-2

Do aktivního stavu lze stroj vrátit změnou hodnoty parametru -v' na off

nod-1:~# crm_standby -N nod-2 -v off

Stejná operace realizovaná prostřednictvím crm

crm(live)node# online nod-2

Po zrušení stavu standby už služby, které vyžadují nod ve stavu Master zůstanou na nodu, na který byly přesunuty po nastavení původního nodu do stavu standby

crm_attribute

Pro rychlou práci s atributy v konfiguraci CRM - k jejich vytvoření, i následnému dotazování, lze použít nástroj crm_attribute. Příkladem použití příkazu crm_attribute může být např. níže uvedený postup přidání poznámky do konfigurace ke stroji nod-2..

nod-2:~# crm_attribute -t nodes -N nod-2 -n note -v 'Stroj v racku 5' nod-2:~# crm_attribute --type nodes --node-uname snoopy --attr-name note --get-value scope=nodes name=note value=Stroj v racku 5 nod-2:~# crm configure show node nod-1 node nod-2 \ attributes note="Stroj v racku 5" property $id="cib-bootstrap-options" \ dc-version="1.1.5-f91f06164622c14af01409655773c66dea21a4d9" \ cluster-infrastructure="openais" \ expected-quorum-votes="2" \ no-quorum-policy="ignore" \ stonith-enabled="false" \ last-lrm-refresh="1303922378" nod-2:~# crm_attribute --type nodes --node-uname nod-2 --attr-name note --delete Deleted nodes attribute: id=nodes-nod-2-note name=note nod-2:~# crm configure show node nod-1 node nod-2 property $id="cib-bootstrap-options" \ dc-version="1.1.5-f91f06164622c14af01409655773c66dea21a4d9" \ cluster-infrastructure="openais" \ expected-quorum-votes="2" \ no-quorum-policy="ignore" \ stonith-enabled="false" \ last-lrm-refresh="1303922378"

* není-li uveden parametr --type, pracuje se přímo s atributy nastavení celého clusteru (sekce property) Hodnotou atributu musí být pouze ascii znaky. Ne proto že by nebylo možné vkládat unicode řetězce, ale proto že s nimi neumí (zatím) pracovat crm

Stejná operace realizovaná prostřednictvím crm

crm(live)node# attribute snoopy set note 'Stroj v racku 10' crm(live)node# attribute snoopy show note scope=nodes name=note value=Stroj v racku 10 crm(live)node# show charlie-brown: normal snoopy: normal note: Příliš žluťoučký kůň

Zdroje

Zdroje jsou v CIB potomky elementu resources

Základní zdroje - primitiva

Základem všech zdrojů jsou primitiva. Není-li takový zdroj součástí zdroje typu master/slave nebo klon, spouští Pacemaker takto nakonfigurovanou službu vždy pouze na jednom nodu.

Součástí konfigurace primitiva však mohou být i parametry, které Pacemaker vezme v potaz až v případě, že se stane součástí zdroje složitějšího.

Pro testování má Pacemaker k dispozici testovacího agenta Dummy (více viz kapitola CRM (Resource Agents)). Následující příklad demonstruje vytvoření testovacího primitiva s id test-dummy a jak takové primitivum vypadá ve formě XML elementu

crm(live)configure# primitive test-dummy ocf:heartbeat:Dummy crm(live)configure# verify crm(live)configure# commit crm(live)configure# quit nod-1~:# cibadmin --query --scope resources .. <primitive id="test-dummy" class="ocf" provider="heartbeat" type="Dummy"/> ..

Po každé úpravě konfigurace je před odesláním změn příkazem commit dobré příkazem verify ověřit, jestli náhodou při editaci nedošlo k překlepu, nebo konfliktu.

Komentáře

Každá rozsáhlejší konfigurace se může po čase stát nesrozumitelnou, proto lze ke každému vytvořenému zdroji pro větší srozumitelnost přidat komentář. Ten se ke zdroji přidá jako hodnota atributu description. Komentář pak bude viditelný i ve statusu zdroje.

nod-1~:# crm configure edit test-dummy .. primitive test-dummy ocf:heartbeat:Dummy \ description="Testovaci zdroj" ... nod-1~:# cibadmin --query --scope resources .. <primitive id="test-dummy" class="ocf" provider="heartbeat" type="Dummy" description="Testovaci zdroj"/> .. nod-1~:# crm resource show test-dummy test-dummy (ocf::heartbeat:Dummy): Started Testovaci zdroj

I když by CRM s UTF-8 interně problém mít nemělo, jeho konzolové nástroje s ním pracovat neumí, proto se diakritice v komentářích raději vyhněte.

Složené zdroje

Složené zdroje se tvoří vždy z exitujícího primitiva, které by mělo ve své konfiguraci obsahovat také nastavené parametry pro monitorování zdroje v roli Master i Slave.

ms - nastavení zdroje master/slave

Zdroj typu master/slave pracuje pouze na dvěma nody. Je-li nakonfigurován v prostředí asymetrického clusteru, pak musí být vždy bezpodmínečně "ukotven" na tyto nody pomocí pravidla location! U clusteru se dvěma nody to sice není bezprostředně nutné, je pak ovšem třeba dát pozor hodnotu atributu symmetric-cluster. Je-li totiž nsatavená na hodnotu false, tak se cluster chová jako asymetrický přesto, že má pouze dva identické nody.

Zdroj se vytvoří z primitiva, které pak vždy na jednom z nodů běží v dominantním režimu (ve stavu master) a na druhém zpravidla v režimu závislém (ve stavu slave). To však nemusí platit vždy!

Kupř. DRBD může poskytovat zdroj v režimu master na obou nodech, protože si řeší paralelní přístup k datům interně. Ve většině případů však zdroj typu master/slave na master nodu zajišťuje normální provoz služby, kdežto zdroj spuštěný na slave nodu slouží pouze jako záložní pro případ selhání master nodu. Dojde-li k němu, pak se příslušné role zdroje mezi nody prohodí.

Toto přehození lze také vyvolat záměrně příkazem promote. V konfiguraci však v takovém případě zůstane záznam o vynucené lokaci, který lze odstranit tak, že je po přehození aplikován příkaz demote.

crm(live)configure# ms master-slave dummyA ... crm(live)# status ... Master/Slave Set: master-slave [dummyA] Slaves: [ nod-1 nod-2 ] ... Aby zdroj fungoval jako master/slave, musí mít podporu agenta výchozího primitiva. V případě testovacího Dummy agenta Pacemaker zdroj spustí na obou nodech jako Slave - žádný není dominantní.

Zdroje typu master/slave nelze přesouvat! Příkaz move u nich vede k tomu, že oba nody skončí ve stavu slave.

clone - klonování zdrojů

Klonované zdroje jsou takové, u kterých služba není na žádném z nodů dominantní. Ukázkový příklad použití demonstruje konfigurace pro spouštění distcc

crm(live)configure# clone klon dummyA ... crm(live)# status ... Clone Set: klon [test-dummyA] Started: [ nod-1 nod-2 ] ...

Klonované zdroje má smysl přesouvat pouze v případě, je-li nakonfigurován běh pouze pro omezený počet paraleleních instancí.

group - seskupení zdrojů

Seskupovatt lze pouze primitivní zdroje, které mohou běžet v rámci jednoho nodu. V případě složených zdrojů lze dosáhnout podobného efektu pomocí metod order, a colocation.

Seskupené zdroje lze pak spouštět či zastavovat přes id pseudozdroje. Spouštění ale neprobíhá náhodně, nýbrž podle pořadí ve skupině. Tzn. že každý následující zdroj se nespustí, dokud neběží ten předchozí.

crm(live)configure# group skupina dummyA dummyB dummyC ... crm(live)# status ... Resource Group: skupina dummyA (ocf::heartbeat:Dummy): Started nod-1 dummyB (ocf::heartbeat:Dummy): Started nod-1 dummyC (ocf::heartbeat:Dummy): Started nod-1 ... Aby se spustilo dummyB musí běžet dummyA a bez spuštěného dummyB se nespustí dummyC.

Umístění zdrojů, pořadí a závislosti při jejich spouštění v rámci clusteru

O tom, kde bude v rámci clusteru zdroj spuštěn, rozhoduje kombinace řady faktorů. Jak se k nim bude přistupovat, vychází z nastavení vlastností clusteru.

Ve výchozím stavu, tedy bezprostředně po instalaci a spuštění, Pacemaker pokládá cluster za symetrický, tj. že každý z nodů je z hlediska využitelnosti rovnocenný.

Tohle ovšem může, ale nemusí být pravda. Máme-li cluster sestavený z nodů různé kvality a výkonu a hardwarového vybavení, pak máme dvě možnosti jak postupovat:

• Buď upravit konfiguraci nodů a zdrojů pomocí atributů utilization a tím, že pomocí parametru location spouštění zdroje výslovně zakážete na nodech, na kterých zdroj provozovat nelze..
• Nebo můžete změnit celý na cluster asymetrický. Pak je ovšem třeba v konfiguraci implicitně říct, kde se zdroj pustit může.

Každopádně v obou případech hraje roli nastavení strategie pro rozmístění zdrojů.

Strategie rozmísťování zdrojů

Chcete-li si ověřit, jaké je aktuální nastavení, můžete se nejdřív dotázat na aktuální hodnotu atributu. Nebude-li žádná hodnota nastavena, pak to znamená, že se akceptuje výchozí hodnota clusteru - default.

nod-1~:# crm_attribute --name placement-strategy --query scope=crm_config name=placement-strategy value=(null) Error performing operation: No such device or address

default

Je-li hodnota parametru placement-strategy default, nebo není-li nastavena vůbec, je pro Pacemaker rozhodující pouze hodnota aktuálního skóre. Háček je v tom, že pokud je hodnota skóre zdroje pro všechny nody stejná (což je typické pro symetrický cluster), tak se snaží zdroje rozhazovat tak, aby byly rozstrkané v rámci nodů rovnoměrně. Což ovšem může mít nepříjemné důsledky. Pokud totiž na některém z nodů vypnutí zdroje poklesne jejich počet, tak Pacemaker bude mít snahu některému z ostatních nodů ulehčit a přehodí některý z nich, aniž bychom o to vyloženě stáli.

utilization

Při tomto nastavení bere kromě aktuálního skóre Pacemaker při spouštění v potaz také atributy, které limitují množství dostupných prostředků (utilization), na které jinak kašle. Bere je však v potaz pouze když se rozhoduje, je-li nod způsobilý k uspokojení nároků zdroje. Jinak je pro něj stále rozhodující počet zdrojů. Znamená to, že k přehození zdroje nedojde pouze tehdy, pokud by tím součet nárokovaný zdroji překročil hodnotu nastavenou na příslušném nodu. Kupř. pokud by to znamenalo vyčerpání dostupného množství paměti, atp.

balanced

Při balancování Pacemaker snaží rozmísťovat zdroje tak, aby optimalizoval využití všech zdrojů. Tzn. že zdroje nepřehazuje tak aby byly rozmístěny rovnoměrně podle toho kolik jich je, ale tak aby se pokud možno rovnoměrně vyčerpávaly dostupné prostředky. I v tomto případě se ale nelze vyhnout nechtěnému přehazování zdrojů.

minimal

Při této strategii se množství dostupných prostředků bere v potaz pouze při rozhodování, zda-li je nod způsobilý ke spuštění dalšího zdroje. Pacemaker se v tomto případě snaží soustředit pokud možno zdroje na co nejmenší počet uzlů. Je to jediná strategie u symetrického clusteru, při které nedochází k nežádoucímu přehazování zdrojů. Primárním cílem této strategie ovšem je - snížit celkové energetické nároky clusteru.

Nastavení žádané strategie se udělá naprosto jednoduše, pomocí utility crm_attribute nastavením parametru placement-strategy :

nod-1~:# crm_attribute --name placement-strategy --update minimal

Tuto operaci lze provést rovněž pomocí konzolového nástroje:

crm(configure) property placement-strategy=minimal crm(configure) commit

Změna strategie může pochopitelně vést k přeskupení aktuálně spuštěných zdrojů

Jaké parametry lze zjistit, nebo měnit pomocí utility crm_attribute se můžete dozvědět z XML obsahu cib souboru, který lze vytáhnout pomocí utility cibadmin: nod-1~:# cibadmin --query ...

Změna clusteru ze symetrického na asymetrický

Pokud nejsou v clusteru vzájemně zastupitelné, je lepší symetrické chování vypnout. To se udělá nastavením parametru symmetric-cluster na hodnotu false.

crm(configure) property symmetric-cluster=false

případně..

nod-1~:# crm_attribute --name symmetric-cluster --update false

Pozor! V tomto případě může dojít k pozastavení aktuálně spuštěných zdrojů, pokud není před touto změnou v konfiguraci implicitně řečeno, kde mohou být spuštěny!

utilization

Díky tomuto nastavení, lze v závislosti na zvolené strategii pro spouštění zdrojů lépe využívat dostupné hardwarové prostředky. Tyto atributy využití (utilization attributes), se nastavují jak u nodu, tak u zdroje. Pojmenovat je lze zcela libovolně a může jich být libovolný počet. Pravidlem je pouze to, že hodnotou musí být číslo.

Pacemaker pak při rozhodování kde zdroj spustí, sečte celkový počet hodnot příslušného atributu u spuštěných zdrojů a porovná, zda-li by při spuštění zdroje nedošlo k překročení hodnoty nastavené na příslušném nodu.

Pokud ne, tak zdroj spustí. Pokud ano, pokusí se jej spustit na jiném nodu. A pokud žádný jiný nod, na kterém by zdroj mohl spustit k dispozici nemá, pak jej nespustí vůbec.

Nastavení nodu

Dejme tomu, že máme limitované množství paměti a procesorů. Nastavíme tedy pro každý z nodů dostupný počet jader CPU a RAM.

Dejme tomu, že stroje nod1, má 4 jádra a 32GB paměti a z toho chceme nechat obětovat zdrojům maximálně 3 jádra a 24GB RAM (24576 v MB). Nastavení provedeme takto:

crm(live)node# utilization nod1 set cpu 3 crm(live)node# utilization nod1 set memory 24576 crm(live)node# status <nodes> <node id="167772205" uname="nod1"> <instance_attributes id="nodes-167772205"> <nvpair id="nodes-167772205-standby" name="standby" value="off"/> </instance_attributes> <utilization id="nodes-167772205-utilization"> <nvpair id="nodes-167772205-utilization-cpu" name="cpu" value="3"/> <nvpair id="nodes-167772205-utilization-memory" name="memory" value="24576"/> </utilization> </node> ... </nodes>

Změnu hodnoty, nebo rovnou nastavení atributu můžeme provést i změnou přímo v konfiguračním souboru:

crm(live)configure# show ... node 167772195: nod1 \ attributes standby=off \ utilization cpu=3 memory=24576 ...

Nastavení zdroje

Mám-li na nodech tyto atributy nastavené, provedeme jejich nastavení u zdrojů. Pro virtuální stroje může být rozhodující spíš dostupné množství paměti, než počet procesorů.

crm(live)resource# utilization stroj set memory 4096 crm(live)resource# cd ../configure crm(live)configure# show stroj ... utilization memory=4096

I v tomto případě lze provést nastavení úpravou konfigurace.

Stroj nod1, pak bude považován za způsobilý k provozu služby, dokud se celkový počet nárokované paměti zdrojů, vejde do hodnoty 24576. Virtuál, jehož spuštění by mohlo vést k překročení hodnoty nastavené na stroji nod1 se Pacemaker již pokusí spustit jinde.

Aktuální hodnotu atributů memory nodu nod1 a zdroje stroj, lze vypsat takto:

crm(live)node# utilization nod1 show memory scope=nodes name=memory value=24576 crm(live)resource# utilization stroj show memory 4096

score

Pro procedury, jimiž je vymezováno nejenom pořadí a závislosti při spuštění, ale i nody na kterých lze zdroje spustit a čas kdy mohou běžet, používá XML struktura CIB souboru element - constraints.

Každá procedura pak má svou konfiguraci seskupenou do samostatného elementu, jehož název je složen z předpony rsc_ a názvu procedury. Významným prvkem elementů těchto procedur je atribut score.

Atribut score je zcela zásadní. Místo číselné hodnoty může obsahovat slovo INFINITY, které zastupuje nekonečně kladnou hodnotu (v konfiguraci prostřednictvím crm se používá zkratka inf). Hodnota atributu lze negovat použitím znaménka mínus. Takže hodnota score="-INFINITY" - znamená, že zdroj na příslušném nodu běžet za žádných okolností nesmí.

V případě metod u kterých se aktuální hodnota skóre počítá z číselných hodnot, má záporná hodnota (tedy že zdroj nesmí na příslušném nodu být spuštěn) vždy přednost.

location

Procedurou location lze specifikovat kde a kdy má být zdroj spuštěný.

Není-li příslušnému zdroji přiřazeno žádné nastavení location, tak se ho Pacemaker pokusí spustit ihned poté, co byla jeho konfigurace odeslána do CIB souboru. A to na nodu, který má z jeho hlediska nejvyšší prioritu. Ta přímo vychází z hodnoty id - čísla které nod získá v okamžiku kdy se přihlásí do clusteru. Čím je služebně starší, tím je hodnota id nižší a priorita nodu vyšší.

Jakou má nod aktuálně hodnotu id lze zjistit spuštěním příkazu crm_node s parametrem -i

nod-1:~# crm_node -i 1680648384 ... nod-2:~# crm_node -i 3358369984 Podle aktuálních hodnot uvedených v příkladu má vyšší prioritu nod-1

Vliv location u asymetrického clusteru

U symetrického clusteru, který má hardwarové prostředky na všech nodech stejné může být vcelku jedno, který nod zrovna hraje prim. Proceduru location tak většinou použijeme pouze v případě, že z nějakého důvodu chceme, aby Pacemaker přesunul zdroj z primárního nodu jinam, nebo pokud chceme aby byl zdroj dostupný (nebo naopak nedostupný) pouze po určitou dobu.

V prostředí asymetrického clusteru však nemusí být vybavení nodů stejné a vždy existují zdroje, pro které je životně důležité kde se spustí. Asymetrický cluster umožňuje integrovat nody, které nejsou vzájemně hardwarově rovnocené. Jeden může být lépe vybaven pro běh databáze, jiný pro web a další může fungovat jako záložní stroj schopný dočasně zastoupit v případě nutnosti kterýkoliv z nich.

Automatické nastavení location

V prostředí symetrického clusteru se obvykle procedury typu location nekonfigurují, ale Pacemaker je vytvoří ke zdroji automaticky vždy, pokud provedeme jeho migraci. Ten ho totiž donutí ke změně lokace tím, že zakáže jeho běh na nodu, který by měl jinak z hlediska zdroje vyšší prioritu.

nod-1:~# crm_mon -1 | grep test-dummyA test-dummyA (ocf::heartbeat:Dummy): Started nod-1 nod-1:~# crm resource move dummyA nod-1:~# crm_mon -1 | grep test-dummyA test-dummyA (ocf::heartbeat:Dummy): Started nod-2 nod-1:~# crm configure show cli-ban-test-dummyA-on-nod-1 location cli-ban-test-dummyA-on-nod-1 test-dummyA -inf: nod-1 nod-1:~# crm resource move dummyA nod-1:~# crm_mon -1 | grep test-dummyA nod-1:~# crm configure show cli-ban-test-dummyA-on-nod-2 location cli-ban-test-dummyA-on-nod-2 test-dummyA -inf: nod-2 nod-1:~# crm resource unmove dummyA nod-1:~# crm_mon -1 | grep test-dummyA test-dummyA (ocf::heartbeat:Dummy): Started nod-1 nod-1:~# crm configure show cli-ban-test-dummyA-on-nod-2 ERROR: object cli-ban-test-dummyA-on-nod-2 does not exist nod-1:~# crm configure show cli-ban-test-dummyA-on-nod-1 ERROR: object cli-ban-test-dummyA-on-nod-1 does not exist Při prvním přesunu Pacemaker vytvořil proceduru cli-ban-test-dummyA-on-nod-1, kterou zakázal běh zdroje test-dummyA na stroji nod-1. Ten se tedy přesunul na nod-2 Dalším zavoláním příkazu move byla vytvořena procedura cli-ban-test-dummyA-on-nod-2, protože zdroj aktuálně běžel na tomto nodu. Kdyby bylo v clusteru více nodů, tak by se zdroj přesunul zase na další. Ale protože tomu tak není a cluster měl k dispozici pouze dva nody, Pacemaker zdroj test-dummyA tedy zastavil. Příkaz unmove však zrušil veškeré automaticky vytvořené procedury typu location, které se vztahovaly ke zdroji test-dummyA a proto byl zdroj opět spuštěn ve své původní lokaci na nodu nod-1

order

Procedurou order lze konfigurovat vzájemné závislosti, pořadí a podmínky pro spuštění, běh i zastavení zdrojů

Podmíněné spuštění - zdroj A nemůže běžet bez zdroje B

crm(live)configure# order AiB inf: A B ... nod-1~:# cibadmin --query --scope constraints .. <rsc_order first="A" id="AiB" score="INFINITY" then="B"/> ..

Pro nastavení podmíněného spuštění lze použít v konfiguraci order také slovní hodnotu mandatory. Výsledek ovšem bude stejný jako byl demonstrován v předchozím odstavci

crm(live)configure# order AiB mandatory: A B

• Když zdroj A který byl spuštěn jako první byl z nějakého důvodu zastaven, bude zastaven - je-li spuštěn - také zdroj B
• Pokud zdroj A neběží a ani jej nelze nahodit, nepůjde spustit ani zdroj B
• Je-li zdroj A restartován, bude restartován i zdroj B. Restart v tomto případě znamená, že bude zastaven a znovu spuštěn po spuštění zdroje A

Podmíněné spuštění pro větší počet závislých zdrojů

Podmíněné spouštění lze u order ale nastavit i pro více než dva zdroje. Pořadí při spouštění pak ovšem v CIB souboru nebude určeno atributy first a then, ale pořadím subelementů resource_ref.

crm(live)configure# order AiBiC inf: A B C ... nod-1~:# cibadmin --query --scope constraints .. <rsc_order id="AiBiC" score="INFINITY"/> <resource_set id="AiBiC"> <resource_ref id="A"/> <resource_ref id="B"/> <resource_ref id="C"/> </resource_set> </rsc_order> ..

• Ke spuštění všech zdrojů dojde teprve při spuštění zdroje A
• Nelze tedy nejprve spustit zdroj B nebo C
• Je-li zdroj B zastaven, bude zastaven i zdroj C. Aby došlo k postupnému spuštění všech tří zdrojů, musí být zdroj B znovu spuštěn.

Nezávislá změna stavu

Jsou situace, kdy je nám jedno jestli zdroj A je závislý na zdroji B a vyžadujeme pouze aby jejich spuštění či zastavení bylo realizováno u obou současně. V takovém případě, pokud nastavíme hodnotu skóre na 0, s zdroje až oba dostanou povel start.

Zásadní rozdíl oproti mandatory tkví v tom, že zde není vzájemná závislost na aktuálním stavu zdroje. Pokud zdroj A zastavíme, tak zdroj B bude tuto skutečnost ignorovat a zůstane dál v běhu. A povel cleanup bude akceptován pouze budou-li oba zdroje ve stejném stavu. Tj. pokud poběží, budou postupně zastaveny a naopak. Jsou-li zastaveny, budou nahozeny.

crm(live)configure# order AB 0: A B ... nod-1~:# cibadmin --query --scope constraints .. <rsc_order first="A" id="AiB" score="0" then="B"/> ..

I v tomto případě lze použít při nastavení slovní hodnoty - advisory

crm(live)configure# order AB advisory: A B