Pacemaker - utilizace (diskuse)

[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?