Should I configure the nodes in my RHEL High Availability cluster to start cluster daemons on boot?

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux (RHEL) 5, 6, or 7 with the High Availability or Resilient Storage Add Ons

Issue

  • I'm not sure if I should enable or disable my cluster daemons on bootup. What are the advantages and disadvantages of each option?
  • I don't want to have a faulty node rejoin the cluster until we inspect it, but does configuring the node to not rejoin have any negative consequences?
  • If I enable cluster services to start on boot, are there are any negative consequences?
  • Should I chkconfig the cman service on?
  • Should I chkconfig pacemaker on?
  • Should I enable pacemaker and corosync in systemd?

Resolution

Red Hat recommends enabling High Availability and Resilient Storage cluster nodes to start services on boot so that it may quickly rejoin the cluster and continue serving its function after a failure or reboot. The result of leaving cluster daemons disabled on boot is that if a node is fenced or rebooted for any reason, it will not become a member again until an administrator intervenes to cause it to rejoin the cluster; during such a window the remaining nodes may be under more stress as they attempt to handle additional load, and/or applications managed by the cluster may have less redundancy and be more prone to complete outages if another node should fail.

There are situations, however, where preventing nodes from rejoining the cluster automatically after a reboot may be desirable. For instance, one common method for avoiding fence loops in two-node cman-based clusters is to leave daemons disabled on boot (although this is often unnecessary with pacemaker and corosync in RHEL 7; it may also be worthwhile to prevent automatic startup of cluster daemons if there is a desire to check the health of a recently failed node before it is introduced back into the cluster, although it is generally only recommended to do so if a sufficient level of redundancy is maintained in the cluster even with one node missing.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.