Product SiteDocumentation Site

Chapter 3. Cluster Options

Table of Contents

3.1. Special Options
3.1.1. Configuration Version
3.1.2. Other Fields
3.1.3. Fields Maintained by the Cluster
3.2. Cluster Options
3.2.1. Available Cluster Options
3.2.2. Querying and Setting Cluster Options
3.2.3. When Options are Listed More Than Once

3.1. Special Options

The reason for these fields to be placed at the top level instead of with the rest of cluster options is simply a matter of parsing. These options are used by the configuration database which is, by design, mostly ignorant of the content it holds. So the decision was made to place them in an easy to find location.

3.1.1. Configuration Version

When a node joins the cluster, the cluster will perform a check to see who has the best configuration based on the fields below. It then asks the node with the highest (admin_epoch, epoch, num_updates) tuple to replace the configuration on all the nodes - which makes setting them and setting them correctly very important.
Table 3.1. Configuration Version Properties
Field Description
admin_epoch
Never modified by the cluster. Use this to make the configurations on any inactive nodes obsolete.
Never set this value to zero, in such cases the cluster cannot tell the difference between your configuration and the "empty" one used when nothing is found on disk.
epoch Incremented every time the configuration is updated (usually by the admin)
num_updates Incremented every time the configuration or status is updated (usually by the cluster)

3.1.2. Other Fields

Table 3.2. Properties Controling Validation
Field Description
validate-with Determines the type of validation being done on the configuration. If set to "none", the cluster will not verify that updates conform the the DTD (nor reject ones that don't). This option can be useful when operating a mixed version cluster during an upgrade.

3.1.3. Fields Maintained by the Cluster

Table 3.3. Properties Maintained by the Cluster
Field Description
crm-debug-origin Indicates where the last update came from. Informational purposes only.
cib-last-written Indicates when the configuration was last written to disk. Informational purposes only.
dc-uuid Indicates which cluster node is the current leader. Used by the cluster when placing resources and determining the order of some events.
have-quorum Indicates if the cluster has quorum. If false, this may mean that the cluster cannot start resources or fence other nodes. See no-quorum-policy below.

Note that although these fields can be written to by the admin, in most cases the cluster will overwrite any values specified by the admin with the "correct" ones. To change the admin_epoch, for example, one would use:
cibadmin --modify --crm_xml ‘<cib admin_epoch="42"/>'
A complete set of fields will look something like this:
Example 3.1. An example of the fields set for a cib object

 <cib have-quorum="true" validate-with="pacemaker-1.0" admin_epoch="1" epoch="12" num_updates="65"
    dc-uuid="ea7d39f4-3b94-4cfa-ba7a-952956daabee">