CRM (konfigurace zdrojů)

Obsah

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_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..

Použití

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.

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.

K tomu, aby zdroj fungoval jako master/slave, musí to podporovat agent výchozího primitiva. V případě testovacího Dummy agenta Pacemaker zdroj spustí na obou nodech jako slave/slave.

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

klon

Klonované zdroje jsou takové, u kterých není žádný z nodů dominantní.

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

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

Není-li určeno jinak, tak se Pacemaker vždy pokusí zdroj spustit ihned po nakonfigurování na prvním nodu, který se mu namane. Jsou zdroje u kterých to nevadí, ale jsou také zdroje, pro které je životně důležité, aby jiné zdroje, které jim mají zajistit potřebnou infrastruktury byly spuštěny dříve a pouze na vyhrazeném nodu.

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

Každá metoda pak má svou konfiguraci seskupenou do samostatného elementu, jehož název je složen z předpony rsc_ a názvu metody.

Nejdůležitějším atributem u každé metody je skóre. Jeho číselná hodnota vyjadřuje jakou má zdroj na příslušném nodu prioritu.

Ta kromě číselné hodnoty může být vyjádřena i slovem INFINITY, které zastupuje nekonečně kladnou hodnotu. Hodnota skóre může být i záporná, pokud je před tímto slovem umístěno znaménko mínus. Jinými slovy - kladná hodnota INFINITY znamená, že služba na příslušném nodu běžet musí, kdežto záporná že nesmí.

V případě pravidel 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.

"Přišpendlení" primitiva k nodu pomocí `location`

"Přišpedlení" primitiva zdroje k nodu je nutné použít především u Master/Slave zdrojů spuštěných v prostředí clusteru s větším počtem nodů, obzvláště, jde li o asymetrický cluster (viz níže). Typickým je nutno takto "přišpendlit" DRBD, které pracuje vždy pouze se dvěma nody.

Vliv `location` u asymetrického clusteru

Za asymetrický je považován cluster, který nemá nody vzájemně rovnocené. Mohou jej tvořit tři různé stroje, z nichž jeden je hardwarově lépe vybaven pro běh databáze, druhý pro web a třetí je schopen zaskočit kterýkoliv z nich.

Pro výchozí spuštění je tedy žádoucí, aby každý ze zdrojů měl vymezen svůj defaultní stroj, ovšem pro případ jeho výpadku zde existuje společný náhradní stroj, který je ho schopen nahradit.

Toto vymezení lze tedy nastavit čistě nastavením hodnoty skóre umístění pro každý z nodů.

Symetrický cluster

U symetrického clusteru jsou všechny nody identické. Tzn. že zdroje mohou běžet na kterémkoliv z nodů. Pokud tedy z nějakého důvodu nechceme, aby oba zdroje běžely současně na jednom stroji, je to třeba pomocí záporné hodnoty -INFINITY pro každý z nodů zakázat.

Automatické nastavení `location`

Automaticky se nastavuje location u vždy když dojde k migraci zdroje.

`order` - konfigurace pořadí a podmínek pro spuštění resp. zastavení zdroje

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