Chapter 12. Status - Here be dragons
Most users never need understand the contents of the status section and can be content with the output from crm_mon
. However for those with a curious inclination, the following attempts to proved an overview of its contents.
In addition to the cluster's configuration, the CIB holds an up-to-date representation of each cluster node in the status section.
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 with the tools for those subsystems.
Table 12.1. Authoritative Sources for State Information
Dataset
|
Authoritative Source
|
---|
node_state fields
|
crmd
|
transient_attributes tag
|
attrd
|
lrm tag
|
lrmd
|
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 12.2. Node Status Fields
Field
|
Description
|
---|
id
|
Unique identifier for the node. Corosync based clusters use the same value as uname, Heartbeat cluster use a human-readable (but annoying) UUID.
|
uname
|
The node's machine name (output from uname -n)
|
ha
|
Is the cluster software active on the node. Allowed values: active, dead
|
in_ccm
|
Is the node part of the cluster's membership. Allowed values: true, false
|
crmd
|
Is the crmd process active on the node. Allowed values: online, offline
|
join
|
Is the node participating in hosting resources. Allowed values: down, pending, member, banned
|
expected
|
Expected value for join
|
crm-debug-origin
|
Diagnostic indicator. The origin of the most recent change(s).
|
The cluster uses these fields to determine if, at the node level, the node is healthy or is in a failed state and needs to be fenced.