5. Configuring Pacemaker
Pacemaker’s configuration, the CIB, is stored in XML format. Cluster administrators have multiple options for modifying the configuration either via the XML, or at a more abstract (and easier for humans to understand) level.
Pacemaker reacts to configuration changes as soon as they are saved. Pacemaker’s command-line tools and most higher-level tools provide the ability to batch changes together and commit them at once, rather than make a series of small changes, which could cause avoid unnecessary actions as Pacemaker responds to each change individually.
Pacemaker tracks revisions to the configuration and will reject any update older than the current revision. Thus, it is a good idea to serialize all changes to the configuration. Avoid attempting simultaneous changes, whether on the same node or different nodes, and whether manually or using some automated configuration tool.
Note
It is not necessary to update the configuration on all cluster nodes. Pacemaker immediately synchronizes changes to all active members of the cluster. To reduce bandwidth, the cluster only broadcasts the incremental updates that result from your changes and uses checksums to ensure that each copy is consistent.
5.1. Configuration Using Higher-level Tools
Most users will benefit from using higher-level tools provided by projects separate from Pacemaker. Popular ones include the crm shell and pcs. 1
See those projects’ documentation for details on how to configure Pacemaker using them.
5.2. Configuration Using Pacemaker’s Command-Line Tools
Pacemaker provides lower-level, command-line tools to manage the cluster. Most configuration tasks can be performed with these tools, without needing any XML knowledge.
To enable STONITH for example, one could run:
# crm_attribute --name stonith-enabled --update 1
Or, to check whether node1 is allowed to run resources, there is:
# crm_standby --query --node node1
Or, to change the failure threshold of my-test-rsc, one can use:
# crm_resource -r my-test-rsc --set-parameter migration-threshold --parameter-value 3 --meta
Examples of using these tools for specific cases will be given throughout this document where appropriate. See the man pages for further details.
See Edit the CIB XML with cibadmin for how to edit the CIB using XML.
See Batch Configuration Changes with crm_shadow for a way to make a series of changes, then commit them all at once to the live cluster.
5.2.1. Working with CIB Properties
Although these fields can be written to by the user, in most cases the cluster will overwrite any values specified by the user with the “correct” ones.
To change the ones that can be specified by the user, for example
admin_epoch, one should use:
# cibadmin --modify --xml-text '<cib admin_epoch="42"/>'
A complete set of CIB properties will look something like this:
XML attributes set for a cib element
<cib crm_feature_set="3.0.7" validate-with="pacemaker-1.2"
admin_epoch="42" epoch="116" num_updates="1"
cib-last-written="Mon Jan 12 15:46:39 2015" update-origin="rhel7-1"
update-client="crm_attribute" have-quorum="1" dc-uuid="1">
5.2.2. Querying and Setting Cluster Options
Cluster options can be queried and modified using the crm_attribute tool.
To get the current value of cluster-delay, you can run:
# crm_attribute --query --name cluster-delay
which is more simply written as
# crm_attribute -G -n cluster-delay
If a value is found, you’ll see a result like this:
# crm_attribute -G -n cluster-delay
scope=crm_config name=cluster-delay value=60s
If no value is found, the tool will display an error:
# crm_attribute -G -n clusta-deway
scope=crm_config name=clusta-deway value=(null)
Error performing operation: No such device or address
To use a different value (for example, 30 seconds), simply run:
# crm_attribute --name cluster-delay --update 30s
To go back to the cluster’s default value, you can delete the value, for example:
# crm_attribute --name cluster-delay --delete
Deleted crm_config option: id=cib-bootstrap-options-cluster-delay name=cluster-delay
5.2.3. When Options are Listed More Than Once
If you ever see something like the following, it means that the option you’re modifying is present more than once.
Deleting an option that is listed twice
# crm_attribute --name batch-limit --delete
Please choose from one of the matches below and supply the 'id' with --id
Multiple attributes match name=batch-limit in crm_config:
Value: 50 (set=cib-bootstrap-options, id=cib-bootstrap-options-batch-limit)
Value: 100 (set=custom, id=custom-batch-limit)
In such cases, follow the on-screen instructions to perform the requested action. To determine which value is currently being used by the cluster, refer to the “Rules” chapter of Pacemaker Explained.
5.3. Connecting from a Remote Machine
It is possible to run configuration commands from a machine that is not part of the cluster.
For security reasons, this capability is disabled by default. If you wish to
allow remote access, set the remote-tls-port (encrypted) or
remote-clear-port (unencrypted) CIB properties (attributes of the cib
element). Encrypted communication can be performed keyless (which makes it
subject to man-in-the-middle attacks), but a better option is to also use
TLS certificates.
To enable TLS certificates, it is recommended to first set up your own Certificate Authority (CA) and generate a root CA certificate. Then create a public/private key pair and certificate signing request (CSR) for your server. Use the CA to sign this CSR.
Then, create a public/private key pair and CSR for each remote system that you wish to have remote access. Use the CA to sign the CSRs. It is recommended to use a unique certificate for each remote system so they can be revoked if necessary.
The server’s public/private key pair and signed certificate should be installed
to the /etc/pacemaker directory and owned by CIB_user. Remember that
private keys should not be readable by anyone other than their owner. Finally,
edit the /etc/sysconfig/pacemaker file to refer to these credentials:
PCMK_ca_file="/etc/pacemaker/ca.cert.pem"
PCMK_cert_file="/etc/pacemaker/server.cert.pem"
PCMK_key_file="/etc/pacemaker/server.key.pem"
The administrator’s machine simply needs Pacemaker installed. To connect to the cluster, set the following environment variables:
CIB_port (required)
Only the Pacemaker daemon user (hacluster) may be used as CIB_user.
To use TLS certificates, the administrator’s machine also needs their public/private key pair, signed client certificate, and root CA certificate. Those must additionally be specified with the following environment variables:
As an example, if node1 is a cluster node, and the CIB is configured with
remote-tls-port set to 1234, the administrator could read the current
cluster configuration using the following commands, and would be prompted for
the daemon user’s password:
# export CIB_server=node1; export CIB_port=1234; export CIB_encrypted=true
# export CIB_ca_file=/etc/pacemaker/ca.cert.pem
# export CIB_cert_file=/etc/pacemaker/admin.cert.pem
# export CIB_key_file=/etc/pacemaker/admin.key.pem
# cibadmin -Q
Optionally, CIB_crl_file may be set to the location of a Certificate Revocation List in PEM format.
Note
Pacemaker must have been built with PAM support for remote access to work.
You can check by running pacemakerd --features. If the output contains
pam, remote access is supported. (since 3.0.0; before 3.0.0, in a build
without PAM support, all remote connections are accepted without any
authentication)
Footnotes
- 1
For a list, see “Configuration Tools” at https://clusterlabs.org/components.html