Mukund-pondkule-6a11@uni-paderborn.de at 18:13, 9 December 2020

2020-12-09T18:13:19Z

Robert-schade-e757@uni-paderborn.de at 15:45, 2 November 2020

2020-11-02T15:45:32Z

Robert-schade-e757@uni-paderborn.de at 14:44, 2 November 2020

2020-11-02T14:44:32Z

Robert-schade-e757@uni-paderborn.de: Author Roland Pabel

2020-10-30T18:22:41Z

Author Roland Pabel

New page

[[Category:HPC-Admin]]
[[Category:HPC.NRW-Best-Practices]]

= Pacemaker =

Pacemaker is a mature software for setting up a high availability cluster on Linux. For CentOS 7, the packages are in the default repository but for CentOS 8 were moved to the [https://mirror.netcologne.de/centos/8.1.1911/HighAvailability/ High Availablity] section.

Pacemaker consists of the services <code>corosync</code> (synchronisation service), <code>pcsd</code> (PCS GUI and remote configuration interface) and <code>pacemaker</code> (Pacemaker High Availability Cluster Manager). Setup of pacemaker is described on many websites, very detailed is [https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_administration/ch-startup-haaa RedHat Documentation].

== Nomenclature ==

* Resource: A Resource can be a service, a mount point, basically anything for which a script exists that describs how this resource works. These scripts are usually save under <code>/usr/lib/ocf/resource.d/</code> and referenced according to their path (e.g. <code>ocf::heartbeat:Filesystem</code> for the file <code>/usr/lib/ocf/heartbeat/Filesystem</code>).
* Clone: The default is for a resource to run only once in a HA cluster. If a resource should be run on all nodes of the HA cluster, for example <code>ntpd</code>, then a clone is used.
* Group: A Collection of Resources that are ordered (in the order they are added to a group). If a resource in a group fails or is disabled, all dependent resources are stopped.
* Meta Properties: Properties of a Resource,etc that are only evaluated by pacemaker, not by the resource.
* Constraints: Pacemaker starts resources according to the constraints set by the administrator. A constraint can be based upon hosts, time, other resources (colocation), etc.
* Stickiness: Resources have meta property called “stickiness” which is just a number. This number sets a limit so that a resource is (not) moved to a node. Its purpose is to not have resource hop around nodes just because some minor detail changes in the cluster.
* Fail Counts: If a resource fails, a counter is increased and a resource is usually forbidden on a node where it failed in the past.

== Configuration ==

Configuration of pacemaker is done using <code>pcs</code> or the <code>crm</code> (cluster resource manager) tools. <code>pcs</code> is just a <code>python</code> frontend for the <code>crm</code> commands, but it is definitely easier to use. For example, <code>pcs status</code> is basically only <code>crm_info -1otf</code>, but a much clearer command. The <code>crm</code> tools are not known for being admin friendly, so <code>pcs</code> is definitely recommended. <code>pcs</code> has a very nice help and man page.

== Tipps ==

<ul>
<li><p>Resources and their dependencies should be put into groups together. Do not group resources according to type.</p>
<p>'''DO:'''</p>
<pre> Resource Group: group1
group1-fs (ocf::heartbeat:Filesystem): Started
group1-ip (ocf::heartbeat:IPaddr2): Started
group1-server (systemd:group1-service): Started
Resource Group: group2
group2-fs (ocf::heartbeat:Filesystem): Started
group2-ip (ocf::heartbeat:IPaddr2): Started
group2-server (systemd:group1-service): Started</pre></li></ul>

'''DONT:'''

<pre> Resource Group: group-fs
group1-fs (ocf::heartbeat:Filesystem): Started
group2-fs (ocf::heartbeat:Filesystem): Started
Resource Group: group1
group1-ip (ocf::heartbeat:IPaddr2): Started
group1-server (systemd:group1-service): Started
Resource Group: group2
group2-ip (ocf::heartbeat:IPaddr2): Started
group2-server (systemd:group1-service): Started

Colocation Constraints:
group1 with group-fs (score:INFINITY)
group2 with group-fs (score:INFINITY)
Ordering Constraints:
start group-fs then start group1 (kind:Mandatory)
start group-fs then start group2 (kind:Mandatory)</pre>
* Try to use constraints as little as possible. There are valid cases for them (for example, when several resources depend on one but there is no order among the resources), but a group is usually preferable to colocation and ordering constraints.
* All <code>systemd</code> Services are automatically available as resources. In case this is not sufficient, writing your own scripts is very easy. The only important detail to look out for is this:

<source lang="bash"> # Monitor _MUST!_ differentiate correctly between running
# (SUCCESS), failed (ERROR) or _cleanly_ stopped (NOT RUNNING).
# That is THREE states, not just yes/no.</source>
For an example, see [https://github.com/russki/cluster-agents/blob/master/generic-script generic-script on github]

@@ Line 1: / Line 1: @@
-[[Category:HPC-Admin|Pacemaker]]
+[[Category:HPC-Admin|Pacemaker]]<nowiki />
-[[Category:HPC.NRW-Best-Practices|Pacemaker]]
+[[Category:HPC.NRW-Best-Practices|Pacemaker]]<nowiki />
-[[Category:Pacemaker]]
+[[Category:Pacemaker]]<nowiki />
 = Pacemaker =

@@ Line 1: / Line 1: @@
 [[Category:HPC-Admin|Pacemaker]]
 [[Category:HPC.NRW-Best-Practices|Pacemaker]]
 = Pacemaker =

Admin Guide Pacemaker - Revision history

Mukund-pondkule-6a11@uni-paderborn.de at 18:13, 9 December 2020

Robert-schade-e757@uni-paderborn.de at 15:45, 2 November 2020

Robert-schade-e757@uni-paderborn.de at 14:44, 2 November 2020

Robert-schade-e757@uni-paderborn.de: Author Roland Pabel