Product SiteDocumentation Site

Chapter 5. Create an Active/Passive Cluster

Table of Contents

5.1. Explore the Existing Configuration
5.2. Add a Resource
5.3. Perform a Failover
5.4. Prevent Resources from Moving after Recovery

5.1. Explore the Existing Configuration

When Pacemaker starts up, it automatically records the number and details of the nodes in the cluster, as well as which stack is being used and the version of Pacemaker being used.
The first few lines of output should look like this:
[root@pcmk-1 ~]# pcs status
Cluster name: mycluster
WARNING: no stonith devices and stonith-enabled is not false
Last updated: Tue Dec 16 16:15:29 2014
Last change: Tue Dec 16 15:49:47 2014
Stack: corosync
Current DC: pcmk-2 (2) - partition with quorum
Version: 1.1.12-a9c8177
2 Nodes configured
0 Resources configured


Online: [ pcmk-1 pcmk-2 ]
For those who are not of afraid of XML, you can see the raw cluster configuration and status by using the pcs cluster cib command.

Example 5.1. The last XML you’ll see in this document

[root@pcmk-1 ~]# pcs cluster cib
<cib crm_feature_set="3.0.9" validate-with="pacemaker-2.2" epoch="5" num_updates="8" admin_epoch="0" cib-last-written="Tue Dec 16 15:49:47 2014" have-quorum="1" dc-uuid="2">
  <configuration>
    <crm_config>
      <cluster_property_set id="cib-bootstrap-options">
        <nvpair id="cib-bootstrap-options-have-watchdog" name="have-watchdog" value="false"/>
        <nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value="1.1.12-a9c8177"/>
        <nvpair id="cib-bootstrap-options-cluster-infrastructure" name="cluster-infrastructure" value="corosync"/>
        <nvpair id="cib-bootstrap-options-cluster-name" name="cluster-name" value="mycluster"/>
      </cluster_property_set>
    </crm_config>
    <nodes>
      <node id="1" uname="pcmk-1"/>
      <node id="2" uname="pcmk-2"/>
    </nodes>
    <resources/>
    <constraints/>
  </configuration>
  <status>
    <node_state id="2" uname="pcmk-2" in_ccm="true" crmd="online" crm-debug-origin="do_state_transition" join="member" expected="member">
      <lrm id="2">
        <lrm_resources/>
      </lrm>
      <transient_attributes id="2">
        <instance_attributes id="status-2">
          <nvpair id="status-2-shutdown" name="shutdown" value="0"/>
          <nvpair id="status-2-probe_complete" name="probe_complete" value="true"/>
        </instance_attributes>
      </transient_attributes>
    </node_state>
    <node_state id="1" uname="pcmk-1" in_ccm="true" crmd="online" crm-debug-origin="do_state_transition" join="member" expected="member">
      <lrm id="1">
        <lrm_resources/>
      </lrm>
      <transient_attributes id="1">
        <instance_attributes id="status-1">
          <nvpair id="status-1-shutdown" name="shutdown" value="0"/>
          <nvpair id="status-1-probe_complete" name="probe_complete" value="true"/>
        </instance_attributes>
      </transient_attributes>
    </node_state>
  </status>
</cib>
Before we make any changes, it’s a good idea to check the validity of the configuration.
[root@pcmk-1 ~]# crm_verify -L -V
   error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
   error: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option
   error: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid
As you can see, the tool has found some errors.
In order to guarantee the safety of your data, [9] the default for STONITH [10] in Pacemaker is enabled. However, it also knows when no STONITH configuration has been supplied and reports this as a problem (since the cluster would not be able to make progress if a situation requiring node fencing arose).
We will disable this feature for now and configure it later.
To disable STONITH, set the stonith-enabled cluster option to false:
[root@pcmk-1 ~]# pcs property set stonith-enabled=false
[root@pcmk-1 ~]# crm_verify -L
With the new cluster option set, the configuration is now valid.

Warning

The use of stonith-enabled=false is completely inappropriate for a production cluster. It tells the cluster to simply pretend that failed nodes are safely powered off. Some vendors will refuse to support clusters that have STONITH disabled.
We disable STONITH here only to defer the discussion of its configuration, which can differ widely from one installation to the next. See Section 8.1, “What is STONITH?” for information on why STONITH is important and details on how to configure it.


[9] If the data is corrupt, there is little point in continuing to make it available
[10] A common node fencing mechanism. Used to ensure data integrity by powering off "bad" nodes