Daemons needed in Pacemaker/Corosync cluster configuration
The tips and suggestions provided in this article are intended to help you configure a high availability cluster for testing purposes. This example utilises third-party software, and while we strive to provide accurate and helpful information, we do not assume any liability for the use of the instructions and advice in this article. Users are responsible for ensuring that any actions taken are appropriate for their specific situation. Always back up your data and configurations before making any changes to your system.
The Services / Daemons
A high availability (HA) cluster built on Corosync / Pacemaker relies on three daemons being operational in order to work:
-
corosync provides ongoing messaging and membership monitoring to the HA cluster. It keenly keeps track of all nodes in the cluster, and whether they are active, idle or in a degraded state. The information that Corosync provides is critical in facilitating responses to various events, for example: if a node goes down it will inform Pacemaker that it needs to reconfigure available resources on-the-fly.
-
pacemaker manages the resources that have been configured in the cluster (e.g. authorised nodes, virtual IPs, etc). Its primary objective is to monitor availability of these resources, working with data provided by corosync as its messaging layer. Pacemaker is particularly crucial in the event of a resource failure - such as a node in the cluster becoming unavailable - and reacts accordingly based on policies set by the administrator (such as failing-over to a standby node).
-
pcsd (Pacemaker / Corosync Configuration System) is the daemon backing the command line tool 'pcs' used to configure and manage both Corosync and Pacemaker. It allows initial setup of the cluster as well as ongoing maintenance. Cluster configuration and monitoring of the cluster are carried out with this tool, including assessing the status of the daemons.
To assess the cluster status, run the following command from the command line of any node that is part of the cluster:
sudo pcs status
For demonstration, below is a screenshot of the resultant output from one node of a healthy active-active two-node cluster:
In this example, we can note that all three relevant daemons are shown to be 'active', which means they are present on the system and running in the background. All three are also listed as 'enabled', meaning they should automatically be started on system boot.
It is only mandatory for each daemon to be 'active' for the cluster to operate; they don't have to be 'enabled'. For example, the daemons may be started via a custom bash script that runs on system startup.
In an eventuality when the Corosync and/or Pacemaker daemons are not operational, executing the same sudo pcs status command will likely result in an error message similar to that shown below:
If the cluster configuration has previously been operational, the likelihood is this issue has come about because one of the daemons has stalled, or didn't start on boot-up of the node.
Where the daemons have already stopped or are in a degraded state, running the following command will start them up again on a healthy system:
sudo systemctl restart corosync pacemaker pcsd
Enabling the daemons on boot using 'systemctl'
If the daemons are not enabled, unless an alternative method is in place (such as a bash script) these services will not automatically start when the node is booted. Run:
sudo pcs status
If any of the daemons are not enabled, it will be displayed as demonstrated below:
If it is desired to explicitly enable all daemons on system bootup, run the following command:
sudo systemctl enable corosync pacemaker pcsd
The default configuration when Corosync / Pacemaker is first installed is only for the 'pcsd' daemon to be enabled. The 'pacemaker' and 'corosync' daemons will both be disabled by default. It is beyond the scope of this article to explore other methods for starting these daemons on boot via alternative methods, but one common option is to use a bash script. An example of where you may wish to use this method is where the daemons must start only once another service has been brought into operation at boot time.