Pacemaker - utilizace

7.6.2016 20:26 | Přečteno: 2049× | Za vším hledej Linux | | poslední úprava: 8.6.2016 10:00

Pacemaker je aplikace se kterou s velkou pravděpodobností většina z vás vůbec nepřijde do styku. A když už, tak zpravidla pouze ve dvou nodovém nasazení. Ovšem kola dějin se točí dál a s pozvolným nástupem distribuovaných souborových systémů už přestávají být vícenodové clustery raritou. A pokud budete chtít v takovém prostředí provozovat Pacemaker, tak dříve či později narazíte na parametr utilization

Utilizační parametry Pacemaker využívá při rozhodování o tom, zda na příslušném nodu může službu pustit, nebo ne.

V podstatě to funguje velice primitivně. Každá služba má nastavenou určitou cenu vyjádřenou číslem, a nod kredit, ze kterého se při spuštění služby její cena odečte. Pokud zbývající kredit ke spuštění další služby nestačí, je spuštěna jinde, nebo vůbec.

Utilizačních parametrů může být více - může to být vázané na počet procesorů, dostupné množství paměti, aj.

Utilizace ovšem v sobě skrývá i jistou záludnost - obzvláště pokud zapomenete na fakt, že s ní pracují služby i nody. A mě pěkně potrápila v uplynulých dnech.

Jak možná někteří z vás vědí, využívám již několik let Pacemaker pro spouštění virtuálních strojů. Pro kterýžto účel jsem si napsal i vlastního agenta. Důvod je celkem prostý - používat libvirt je jako dělat děti s pánskou ochranou. Proč by měl agent Pacemakeru spoléhat na libvirt, když si může všechno zajistit sám?

Jen pro vaši představu uvádím jak vypadá konfigurace takového virtuálu:

stroj :~# crm configure show unstable
primitive unstable ocf:dce:kvm \
        params workdir="/root" binfile=qemu-system-x86_64
          ifup="/etc/openvswitch/ovs-ifup"
          ifdown="/etc/openvswitch/ovs-ifdown"
          cpu="kvm64 -smp cpus=2 -M q35" memory=2048
          monitor=7001 bus=scsi-hd
          drives="sheepdog:localhost:8000:unstable,none,disk,qcow2"
          nic="bf:cf:df:00:40:01,virtio,tap,interni, bf:cf:df:02:40:01,virtio,tap,main,1"
          serial="file:/var/log/unstable.serial"
          logfile="/var/log/unstable.log"
          spice="port=4001,password=xY1yZ"
          errlogfile="/var/log/unstable.err" \
        meta target-role=Started is-managed=true \
        op monitor interval=20 \
        op start interval=0 timeout=30 \
        op stop interval=0 timeout=30 \
        utilization cpu=2 memory=2048

Na tomto základě sestaví agent příkaz, kterým spustí na některém z nodů qemu s virtuálem. O porty na virtuálním switchi se postarají skripty ovs-ifup a ovs-ifdown.

Přidat další disk znamená pouze rozšířit parametr drives - podobným způsobem, jako jsou parametrem nic nastaveny dvě virtuální síťovky - jedna do interní a druhá do vnější sítě.

Již v době, kdy jsem psal první verzi (leden 2014) jsem měl v plánu zapracovat i živou migraci virtuálních strojů, ale nakonec k tomu nedošlo protože chyběl základní předpoklad - spolehlivé datové úložiště, dostupné ze všech nodů. Teprve s nasazením sheepdogu (prosinec 2015) začala mít živá migrace smysl.

Nejprve však bylo nutné vyřešit problém aktualizace Pacemakeru. Agent byl totiž napsán a vyzkoušen u verze 1.1.12 ovšem to byla na dlouhou dobu poslední verze, kterou se mi podařilo bezproblémově uchodit. Situace se zlepšila relativně nedávno. Ovšem nemilé překvapení s aktuální verzí 1.1.14 mi na delší dobu vzala chuť pokračovat v ostrém provozu.

Pro další testování jsem si tedy vytvořil virtuální virtualizační cluster. Druhý pokus o aktualizaci jsem spojil s přechodem na ceph, který si vyžádal přepracování agenta tak, aby nebylo nutné používat v konfiguraci přes crm zpětná lomítka.

Použití zpětných lomítek totiž vede k tomu, že utilita crmsh při konfiguraci přestane parsovat xml. Takže místo výše uvedené konfigurace se v editoru otevře rovnou XML kód cib souboru.

Aby mi aktualizace Pacemakeru nenabourala produkční infrastrukturu, přesunul jsem virtuály na nod, který do něj zatím zapojen není a příslušné služby zastavil, aby nedocházelo ke kolizím. Pro první testy jsem zvolil disklessový stroj s názvem unstable. Odladil jsem agenta a začal s testováním live migrace. Jde o asymetrický cluster, složený ze tří původních AMD strojů, který roztahuji přes nody s procesory Intel.

Všechno šlo jako na drátkách. Stroj se překlápěl zaživa bez nejmenším problémů sem tam. Takže jsem přidal další testovací stroj, který ovšem již není disklessový, ale používá ceph - se kterým jsem agenta dosud vyzkoušeného neměl.

Najel bez problémů. První přesun - ok, druhý přesun - ok, třetí přesun - nic. Na nodu s Intelem se nespustil. Aplikuji unmove - najel. Znovu přesun - nic. No. Trápil jsem se s tím opravdu dlouho.

Naťuknul mne včerejší pokus, kdy jsem zkusil spustit stejný stroj pod jiným názvem služby - původně jsem podezříval nějaký zapomenutý element v cib souboru - a najel. Chtěl jsem ho odmigrovat jinam, což ale Pacemaker odmítl s tím, že mne upozornil na to že chybí meta atribut target-role. Použil jsem totiž pouze konfiguraci parametrů původního virtuálu, ne jeho meta atributy. Nastavil jsem je tedy, a migrace bez problémů proběhla. Jenže zpátky už stroj přesunout nešel.

Vrtalo mi to hlavou, ale až dnes ráno mi svitlo v čem nejspíš bude problém. Utilizace - u toho nově přidaného nodu jsem totiž nenastavil - na rozdíl od těch původních AMD strojů - žádný počet cpu. Stroj unstable v konfiguraci žádné utilizační parametry neměl, proto jeho migrace probíhala bez problémů, kdežto ten druhý stroj měl nastaveno, že má vyžadovat 2 cpu. Přidal jsem tedy nodu parametry pro utilizaci a virtuál najel.

Dovětek na téma migrace služeb v Pacemakeru..

Myslím, že by někoho mohlo zajímat i to, jakým způsobem vlastně v prostředí asymetrického clusteru s parametrem placement-strategy na minimal taková migrace probíhá.

Při takto zvolené strategii se snaží Pacemaker koncetrovat virtuální stroje na minimální počet nodů - s tím, že při jejich umisťování postupuje v pořadí dle priority nodů. Jsou-li k dispozici tyto nody:

Online: [ A B C D ]

Postupně spouští zdroje na stroji A dokud nevyčerpá jeho prostředky nastavené přes utilizaci. Pak bude pokračovat na stroji B, atd.

Ovšem jsou situace, kdy chceme (nebo naopak nechceme) aby služba běžela na některém konkrétním nodu. To pacemaker řeší nastavením location pro příslušnou službu. Jak, to ukáži na následujících příkladech.

Pokud chceme, aby virtál unstable běžel na stroji C, musíme dát příkaz:

~# crm resource move unstable C

Efekt tohoto příkazu je takový, že crmsh přidá do konfigurace následující parametr:

~# crm configure show | grep location | grep unstable
location cli-prefer-unstable unstable role=Started inf: C

Pro práci se droji ale není nezbytně nutné používat crmsh. Lepší je použít crm_resource:

~# crm_resource -r unstable -M -N C

Případně v ukecanějším módu:

~# crm_resource --resource unstable --move --node C

Pokud bychom neuvedli konkrétní jméno nodu:

~# crm resource move unstable

popř.

~# crm_resource --resource unstable --move

..tak by Pacemaker přesunul stroj unstable na nejbližší volný nod, tedy B. A v konfiguraci by se objevilo místo předchozího nastavení toto:

~# crm configure show | grep location | grep unstable
location cli-ban-unstable-on-A unstable role=Started -inf: A

Což v podstatě znamená: Služba unstable může běžet všude jinde, než na stroji A. Ovšem jsou situace kdy naopak nechceme aby nějaká služba běžela na jiném nodu. V takovém případě ji můžeme "připíchnout" ke konkrétnímu nodu přímo nastavením parametru location:

~# crm configure show pin-unstable
location pin-unstable unstable \
        rule #uname eq C

Přes crm_resource lze také rychle zjistit zda a kde zdroj aktuálně běží:

~# crm_resource -r unstable --locate
resource unstable is running on: C

       

Komentáře

[Max]

Díky za pěkné počtení.
Zdar Max

[Ruža Becelin]

Pekna serie informaci o Peacemakeru, diky za to.

Fakt nechapu, kterej blbec to hodnotil spatne :-/

[Aleš Kapica]

Tak důvody mohou být dva - buď zde nenašel co čekal, nebo to považuje za profláknutí svého žárlivě střeženého know-how. No a pak mě napadá ještě třetí. Lidé co blogposty některých osob hodnotí záporně již z principu. Ať tak, nebo tak, je mi to fuk. Blogy píšu pro ty co by to mohlo zajímat. Jim pro zlost ne.

[xxxs]

moze byt aj preklik.

[Prohnutá nudle]

Pekny clanek, diky!

btw. kolik pacemaker zvladne max. nodu? Je tam nejaky prakticky limit?

ps. utilizace je naprosto otresnej patvar new speaku, trvalo mi par odstavcu, nez sem pochopil ze se mluvi o vyuziti.

[Aleš Kapica]

Mě tedy trvalo mnohem déle, než jsem pochopil k čemu to je Díky za vhodný výraz.

Kolik zvládne Pacemaker nodů? Kdesi jsem četl, že omezení měly mít hlavně starší verze corosyncu. Každopádně na netu jsem narazil na mail (z r. 2012) kde psali, že je to dané tím, kolik strojů zvládne vzájemně komunikovat. A to je věc corosyncu. Ten prý reálně testovali na 32 nodovém clusteru a pro vyšší počet nodů doporučovali udělat menší clustery (viz).

A narazil jsem také na mail člověka, který chtěl sestavit 80 nodový cluster a narazil na limit corosyncu - 64 nodů (viz)

[Prohnutá nudle]

diky za info.

[trekker.dk]

Druhý pokus o aktualizaci jsem spojil s přechodem na ceph

Nějaký zápisek o tomhle bude? Zrovna nedávno jsem si s tím zoušel hrát taky a byl to docela porod.

[Aleš Kapica]

Přechod byl v zásadě dokončen včera, a změn je více - kupř. místo puppetu jsem začal používat ansible, takže mám ještě hafo práce před sebou, než to budu moct nějak přetavit na blogpost.

[Ondra Beneš]

Čau Aleši,

dík za článek, zajímavé téma. Můžu se zeptat, kde ten pacemaker provozuješ?

S KVM na pacemakeru zkušenosti ještě nemám, potřebuju si to vyzkoušet a budu čerpat i z tohohle článku.

Vypadá to, že na RHEL a CentOS se ten resource jmenuje ocf:heartbeat:VirtualDomain a utilisation bere z virsh.

# pcs resource describe  ocf:heartbeat:VirtualDomain
ocf:heartbeat:VirtualDomain - Manages virtual domains through the libvirt virtualization framework

Resource agent for a virtual domain (a.k.a. domU, virtual machine,
virtual environment etc., depending on context) managed by libvirtd.

Resource options:
  config (required): Absolute path to the libvirt configuration file, for this virtual domain.
  hypervisor: Hypervisor URI to connect to. See the libvirt documentation for details on supported URI formats. The default is system
              dependent. Determine the system's default uri by running 'virsh --quiet uri'.
  force_stop: Always forcefully shut down ("destroy") the domain on stop. The default behavior is to resort to a forceful shutdown only
              after a graceful shutdown attempt has failed. You should only set this to true if your virtual domain (or your
              virtualization backend) does not support graceful shutdown.
  migration_transport: Transport used to connect to the remote hypervisor while migrating. Please refer to the libvirt documentation
                       for details on transports available. If this parameter is omitted, the resource will use libvirt's default
                       transport to connect to the remote hypervisor.
  migration_network_suffix: Use a dedicated migration network. The migration URI is composed by adding this parameters value to the end
                            of the node name. If the node name happens to be an FQDN (as opposed to an unqualified host name), insert
                            the suffix immediately prior to the first period (.) in the FQDN. At the moment Qemu/KVM and Xen migration
                            via a dedicated network is supported. Note: Be sure this composed host name is locally resolveable and the
                            associated IP is reachable through the favored network.
  monitor_scripts: To additionally monitor services within the virtual domain, add this parameter with a list of scripts to monitor.
                   Note: when monitor scripts are used, the start and migrate_from operations will complete only when all monitor
                   scripts have completed successfully. Be sure to set the timeout of these operations to accommodate this delay.
  autoset_utilization_cpu: If set true, the agent will detect the number of domainU's vCPUs from virsh, and put it into the CPU
                           utilization of the resource when the monitor is executed.
  autoset_utilization_hv_memory: If set true, the agent will detect the number of *Max memory* from virsh, and put it into the
                                 hv_memory utilization of the resource when the monitor is executed.
  migrateport: This port will be used in the qemu migrateuri. If unset, the port will be a random highport.
  snapshot: Path to the snapshot directory where the virtual machine image will be stored. When this parameter is set, the virtual
            machine's RAM state will be saved to a file in the snapshot directory when stopped. If on start a state file is present for
            the domain, the domain will be restored to the same state it was in right before it stopped last. This option is
            incompatible with the 'force_stop' option.

Díky, Ondra

[Aleš Kapica]

Tak já těch clusterů provozuji víc. Tenhle konkrétně u nás ve škole. Jede to nad Debianem unstable. Použitý agent je z mé vlastní provenience. V ofiko distribuci ho nenajdeš. Ale není problém ti ho poskytnout. Kromě KVM virtualizace provozuji také clustery kde se používá XEN.

Ti agenti pro Pacemaker vypadají většinou podobně jako init skripty, takže se můžeš do nich normálně kouknout a zjistit co vlastně dělají. Nevím jak je tomu v současné době, ale hodně jich bylo napsaných dost ehm.. no ne zrovna pěkně. Kupř. agenta pro připojení souborového systému jsem si také raději napsal vlastního - ten co byl v distribuci totiž neuměl mountovat subvolume Btrfs.

Jinak pokud ti mohu doporučit - zkontaktuj mne raději přímo mailem, nebo ještě lépe pokud také používáš jabber, tak kecálek je na řešení podobných věcí vhodnější.

[Käyttäjä 11133]

Není na takový use-case použít něco jiného, dynamického?

[Aleš Kapica]

Co máš na mysli?