Product SiteDocumentation Site

Chapter 14. Status — Here be dragons

Table of Contents

14.1. Node Status
14.2. Transient Node Attributes
14.3. Operation History
14.3.1. Simple Operation History Example
14.3.2. Complex Operation History Example
Most users never need to understand the contents of the status section and can be happy with the output from crm_mon.
However for those with a curious inclination, this section attempts to provide an overview of its contents.

14.1. Node Status

In addition to the cluster’s configuration, the CIB holds an up-to-date representation of each cluster node in the status section.

Example 14.1. A bare-bones status entry for a healthy node cl-virt-1

  <node_state id="cl-virt-1" uname="cl-virt-2" ha="active" in_ccm="true" crmd="online" join="member" expected="member" crm-debug-origin="do_update_resource">
   <transient_attributes id="cl-virt-1"/>
   <lrm id="cl-virt-1"/>

Users are highly recommended not to modify any part of a node’s state directly. The cluster will periodically regenerate the entire section from authoritative sources, so any changes should be done with the tools appropriate to those sources.

Table 14.1. Authoritative Sources for State Information

CIB Object Authoritative Source

The fields used in the node_state objects are named as they are largely for historical reasons and are rooted in Pacemaker’s origins as the Heartbeat resource manager. They have remained unchanged to preserve compatibility with older versions.

Table 14.2. Node Status Fields

Field Description
Unique identifier for the node. Corosync-based clusters use a numeric counter, while Heartbeat clusters use a (barely) human-readable UUID.
The node’s machine name (output from uname -n).
Is the cluster software active on this node? Allowed values: active, dead.
Is the node a member of the cluster? Allowed values: true, false.
Is the crmd process active on the node? Allowed values: online, offline.
Does the node participate in hosting resources? Allowed values: down, pending, member, banned.
Expected value for join.
The origin of the most recent change(s). For diagnostic purposes.

The cluster uses these fields to determine whether, at the node level, the node is healthy or is in a failed state and needs to be fenced.