CRM (Resource Agents)

Z DCEwiki
Přejít na: navigace, hledání

Spouštění a zastavování zdrojů provádí Pacemaker přes tzv. agenty. Agent může být jak skript skript, tak binární soubor, který Pacemaker volá podle nakonfigurovaných pravidel.

Třídy[editovat]

Třída - "class" seskupuje agenty určitého typu, a tak na zajištění spouštění jednoho zdroje můžeme mít k dispozici více agentů. Dokonce i v rámci třídy lze mít k dispozici více agentů s podobným účelem. Aby v jejich názvech nevznikal zbytečný zmatek, může v rámci hierarchické struktury crm tedy existovat ještě tzv. "provider", což je vlastně podadresář, v němž je skript (nebo binární soubor) agenta umístěn. Pokud se tedy nějaký "provider" v rámci třídy vyskytuje, je vypsán při sekvenci crm -> ra -> classes za lomítkem..

Poznámka
crm(live)ra# classes
heartbeat
lsb
ocf / dce heartbeat linbit pacemaker
stonith

Z výpisu lze vyčíst, že v systému je několik základních sad těchto agentů (tzv. zdrojů agentů - Resource Agents):

  1. Původní skripty pro Heartbeat
  2. Skripty podle specifikace OCF (Open Cluster Framework)
  3. Skripty podle specifikace LSB (Linux Standard Base), což jsou v podstatě standardní spouštěcí init skripty
  4. A speciální skupina agentů stonith, která zajišťuje akce spojené s odstřelem příslušné služby
Poznámka Jelikož mi zpočátku dlouho nebylo jasné, co je u crm konzolový příkaz a co konfigurační sekvence, pokusil jsem se pro větší přehlednost u konfiguračních sekvencí uvádět znaky ->, kterými jsem chtěl naznačit krok - "dopiš a dej enter"

Výsledkem sekvence crm -> ra -> help by tedy mělo být, že se vám na konzoli vypíše přehled dostupných příkazů v rámci ra, což je oblast v níž lze zjišťovat informace o dostupných agentech - jaké lze u nich použít parametry, jaké jsou doporučené hodnoty, atd.

Pokud chcete zjistit jací agenti jsou v rámci zdroje k dispozici, můžete použít příkaz crm -> ra -> list. Viz příklad:

Poznámka
crm(live)# ra
crm(live)ra# list ocf heartbeat
AoEtarget           AudibleAlarm        CTDB                ClusterMon          Delay
DrbdDummy           Dummy               EvmsSCC             Evmsd               Filesystem
ICP                 IPaddr              IPaddr2             IPsrcaddr           IPv6addr
LVM                 LinuxSCSI           MailTo              ManageRAID          ManageVE
Pure-FTPd           Raid1               Route               SAPDatabase         SAPInstance
SendArp             ServeRAID           SphinxSearchDaemon  Squid               Stateful
SysInfo             VIPArip             VirtualDomain       WAS                 WAS6
WinPopup            Xen                 Xinetd              anything            apache
conntrackd          db2                 drbd                eDir88              exportfs
fio                 iSCSILogicalUnit    iSCSITarget         ids                 iscsi
jboss               ldirectord          mysql               mysql-proxy         nfsserver
nginx               oracle              oralsnr             pgsql               pingd
portblock           postfix             proftpd             rsyncd              scsi2reservation
sfex                syslog-ng           tomcat              vmware

Ale stejně tak můžete rovnou zavolat:

Poznámka
nod-1~# crm ra list ocf heartbeat
AoEtarget           AudibleAlarm        CTDB                ClusterMon          Delay
...

Každá z tříd má svůj specifický adresář a provider není v podstatě nic jiného, než adresář s agenty. Při nastavení zdroje v konfiguraci se cesta k agentovi, který má být použit, uvádí přes tři parametry, navzájem oddělené dvojtečkami:

class:provider:agent

Postupy které se týkají konfigurace Pacemakeru, které se válí na internetu, jsou většinou založeny na použití agentů ze standardní instalace. Můžete se však dostat do situace, kdy žádný z nich vašim potřebám vyhovovat nebude, resp. zjistíte že nefunguje tak jak by měl. V takovém případě máte dvě možnosti:

  1. Vyzkoušet použít agenta od jiného poskytovatele ("providera") Viz seznam agentů , kde naleznete i popis k těm distribučním.
  2. Napsat si agenta vlastního. Tomu, jak takový agent má vypadat bude věnována až následující kapitola.

Původní skripty pro Heartbeat[editovat]

Umístění agentů v rámci adresářové struktury 
/etc/ha.d/resource.d/ (skripty)

U původní verze Heartbeatu (1.0) vypadal a fungoval kód agentů trochu jinak, ale protože někteří uživatelé měli na tyto původní agenty navázané zase své vlastní, zůstala jejich implementace kvůli zpětné kompatibilitě zachovaná.

Poznámka Implementaci těchto původních agentů, přepsanou podle specifikace OCF najdete ve třídě ocf pod providerem heartbeat

OCF skripty[editovat]

Umístění agentů v rámci adresářové struktury 
/usr/lib/ocf/resource.d/ (skripty)

Tyto skripty jsou součástí instalačního balíku crm-agents (v oficiálním Debianu cluster-agents. :* OCF skripty podporují nastavení parametrů v prostředí crm

  • Konfigurační XML kód je zároveň dokumentací agenta
  • Jsou vesměs shellové skripty, které lze snadno doplnit a upravit

Jelikož se mohou vyskytovat různé implementace jednoho agenta, od různých poskytovatelů (providers), věnujte velkou pozornost dokumentaci k nastavení agenta. Viz příklad, jak vypsat kupř. info o testovacím agentu Dummy

Poznámka
nod-1~# crm ra info ocf:heartbeat:Dummy
Example stateless resource agent (ocf:heartbeat:Dummy)
...

Mimochodem - info výpis je také dobrým testem při psaní vlastního agenta.

LSB skripty[editovat]

Umístění agentů v rámci adresářové struktury 
/etc/init.d (systémové spouštěcí skripty)

LSB skripty jsou v podstatě standardní spouštěcí skripty, z adresáře /etc/init.d. V rámci CRM jsou sdružené ve třídě lsb. Na rozdíl od OCF skriptů LSB v původní implementaci neobsahovalo žádné volání, kterým by bylo možné zjistit stav služby. Většina spouštěcích skriptů pracovala pouze s operacemi start-stop. Pacemaker tudíž u této třídy agentů nemá implementováno nic, co by umožňovalo analyzovat jejich návratovou hodnotu. Vyhodnotí pouze jako chybu následující stav:

  • Když se agent pokusí znovu o spuštění již spuštěné služby
  • Když se agent pokusí znovu zastavit již zastavenou službu
Upozornění Na tyto zdroje tím pádem nelze aplikovat žádnou akci typu monitor!

stonith[editovat]

Umístění agentů v rámci adresářové struktury 
/usr/lib/stonith/plugins/stonith2 (binárky)
/usr/lib/stonith/plugins/external (skripty)

Na rozdíl od ostatních tříd, ve třídě stonith se vyskytují vedle skriptů i binární soubory. Agenti z této třídy se používají pro zajištění bezpečného "odstřelu" potenciálně nebezpečných nodů, které by nějakým způsobem mohly nabourat správná data na ostatních nodech.

Poznámka "Odstřelený" nod se totiž po restartu dostane v rámci clusteru do submisivního postavení a tím je mu zabráněno zreplikovat na ostatní nody poškozená data.

OCF agent[editovat]

Agent podle specifikace OCF obsahuje funkce a nastavení výchozích proměnných, které se při konfiguraci mohou přenastavit podle potřeb a parametrů zdroje. Tato konfigurace se provádí prostřednictvím konzolového nástroje crm, a to buď při výchozí konfiguraci zdroje ( crm -> configure ), nebo i operativně, později za běhu ( crm -> resource ). Jaké parametry lze u použitého agenta nastavit, se lze dozvědět přes jejich informační rozhraní (viz výše uvedený příklad aplikace příkazu info)

Vlastní agent[editovat]

Kdy a proč si napsat vlastního agenta?

Důvody mohou být různé, mne osobně k tomu přimělo několik následujících důvodů:

  • Agent pro OCFS2 (ocf:pacemaker:o2cb) byl nedodělaný (jeho autor se očividně spokojil jen s hrubou předělávkou modulu ocf:heartbeat:pingd
  • Agent pro připojení souborových systémů (ocf:heartbeat:Filesystem) zase pro změnu nefungoval jak měl.
  • A agent pro KVM virtualizaci (ocf:heartbeat:VirtualDomain) byl zase na můj vkus až příliš závislý na knihovně libvirt

Umístění vlastního agenta[editovat]

Vlastního agenta je nejlépe začít tvořit ve vlastním "provider" adresáři, tak aby nemohl nabourat ostatní agenty.

Poznámka Vzhledem k tomu, že by skript agenta měl být identický na všech nodech, ulehčí práci skript, kterým po každé změně můžeme provést jeho rozkopírování mezi nody. Abychom se přitom nemuseli zdržovat zadáváním hesla, je vhodné nastavit pro vzájemnou autorizaci mezi nody, u uživatele pod kterým agenta chcete psát autorizaci přes veřejné ssh klíče.

Když se objeví ve skriptu nějaká chyba, lze ji nejsnáze nalézt, je-li zavolán crm jako příkaz, když crmd démon neběží. Jinak se objeví pouze oznámení o chybě, bez konkrétního výpisu.

Poznámka
nod-2:~# crm configure ra info ocf:dce:drbd

Volání agenta[editovat]

CRM jako takové se stará o vzájemnou kooperaci mezi jednotlivými zdroji v rámci clusteru. Agenta volá v případě, že potřebuje provést lokální akci. Agent, je ve skutečnosti skript se sadou funkcí, které se spouštějí v závislosti na volání CRM. Přitom ovšem ne všechna volání "probublají" až do skriptu. Většina agentů zpracovává pouze následující volání:

meta_data
start
stop
monitor

Základem každého agenta je funkce meta_data(), skrz kterou se do CRM načítá výchozí konfigurace instance zdroje v XML formátu. V tomto XML kódu se rovněž definují:

proměnné 
se kterými pak lze v rámci agenta pracovat (jejich hodnoty se přiřazují při konfiguraci primitiva jako parameter); jsou součástí elementu parameters
výchozí časové intervaly pro akce 
které pak lze při konfiguraci upracovat přes meta; jsou součástí elementu action.
Upozornění Agenti nemají žádnou lokalizaci, přestože parametr lang="en" v elementech budí dojem, že ano. Ve skutečnosti CRM u elementů nastavením tohoto parametru ignoruje, takže když do něj naprasíte text v utf8, tak se na konzoli normálně vypíše včetně diakritiky.