Chapter 5. Manual Configuration of a Cluster | ||||
|---|---|---|---|---|
 | 4.11. Migrating a Cluster Resource | 5.2. Configuring Resources |  | |
Chapter 5. Manual Configuration of a Cluster | ||||
|---|---|---|---|---|
| 4.11. Migrating a Cluster Resource | 5.2. Configuring Resources | | |
Contents
Manual configuration of a Heartbeat cluster is often the most effective way of creating a reliable cluster that meets specific needs. Because of the extensive configurability of Heartbeat and the range of needs it can meet, it is not possible to document every possible scenario. To introduce several concepts of the Heartbeat configuration and demonstrate basic procedures, consider a real world example of an NFS file server. The goal is to create an NFS server that can be built with very low-cost parts and is as redundant as possible. For this, set up the following cluster:
Two machines that have redundant hardware
Data is mirrored on the disks of those machines with drbd
Only one machine at a time accesses and exports the data
Assign a special IP address to the computer for exporting the file system
Before starting with the cluster configuration, set up two nodes as described in Chapter 2, Installation and Setup. In addition to the system installation, both should have a data partition of the same size to setup drbd.
The configuration splits into two main parts. First, all the
resources must be configured. After this, create a set of
constraints that define the starting rules for
those resources.
All the configuration data is written in XML. For convenience, the example relies on snippets that may be loaded into the cluster configuration individually.
The cluster is divided into two main sections, configuration and status. The status section contains the history of each resource on each node and based on this data, the cluster can construct the complete current state of the cluster. The authoritative source for the status section is the local resource manager (lrmd) process on each cluster node. The cluster will occasionally repopulate the entire section. For this reason it is never written to disk and administrators are advised against modifying it in any way.
The configuration section contains the more traditional information like cluster options, lists of resources and indications of where they should be placed. It is the primary focus of this document and is divided into four parts:
Configuration options (called crm_config)
Nodes
Resources
Resource relationships (called constraints)
Example 5.1. Structure of an Empty Configuration
<cib generated="true" admin_epoch="0" epoch="0" num_updates="0" have_quorum="false">
<configuration>
<crm_config/>
<nodes/>
<resources/>
<constraints/>
</configuration>
<status/>
</cib>Before you start to configure a cluster, it is worth explaining how to view the finished product. For this purpose use the crm_mon utility that will display the current state of an active cluster. It can show the cluster status by node or by resource and can be used in either single-shot or dynamically-updating mode. Using this tool, you can examine the state of the cluster for irregularities and see how it responds when you cause or simulate failures.
Details on all the available options can be obtained using the
crm_mon --help command.
There is a basic warning for updating the cluster configuration:
![[Warning]](admon/warning.png) | Rules For Updating the Configuration |
|---|---|
Never edit the | |
To modify your cluster configuration, use the cibadmin command which talks to a running cluster. With cibadmin, you can query, add, remove, update or replace any part of the configuration. All changes take effect immediately and there is no need to perform a reload-like operation.
The simplest way of using cibadmin is a three-step procedure:
Save the current configuration to a temporary file:
cibadmin --cib_query > /tmp/tmp.xml
Edit the temporary file with your favorite text or XML editor.
Some of the better XML editors are able to use the
DTD (document type definition) to make sure that any changes
you make are valid. The DTD describing the configuration can
be found in /usr/lib/heartbeat/crm.dtd
on your systems.
Upload the revised configuration:
cibadmin --cib_replace --xml-file /tmp/tmp.xml
If you only want to modify the
resources section, do the following to avoid
modifying any other part of the configuration:
cibadmin --cib_query --obj_type resources > /tmp/tmp.xml vi /tmp/tmp.xml cibadmin --cib_replace --obj_type resources --xml-file /tmp/tmp.xml
Sometimes it is necessary to delete an object quickly. This can be done in three easy steps:
Identify the object you wish to delete, for example:
cibadmin -Q | grep stonith <nvpair id="cib-bootstrap-options-stonith-action" name="stonith-action" value="reboot"/> <nvpair id="cib-bootstrap-options-stonith-enabled" name="stonith-enabled" value="1"/> <primitive id="child_DoFencing" class="stonith" type="external/vmware"> <lrm_resource id="child_DoFencing:0" type="external/vmware" class="stonith"> <lrm_resource id="child_DoFencing:0" type="external/vmware" class="stonith"> <lrm_resource id="child_DoFencing:1" type="external/vmware" class="stonith"> <lrm_resource id="child_DoFencing:0" type="external/vmware" class="stonith"> <lrm_resource id="child_DoFencing:2" type="external/vmware" class="stonith"> <lrm_resource id="child_DoFencing:0" type="external/vmware" class="stonith"> <lrm_resource id="child_DoFencing:3" type="external/vmware" class="stonith">
Identify the resource’s tag name and id (in this case
primitive and
child_DoFencing.
Execute cibadmin:
cibadmin --cib_delete --crm_xml ‘<primitive id=”child_DoFencing”/>’
Some common tasks can also be performed with one of the
higher level tools that avoid the need to read or edit
XML. Run the following command to enable STONITH, for example:
crm_attribute --attr-name stonith-enabled --attr-value true
Or to see if somenode is allowed to run
resources, there is:
crm_standby --get-value --node-uname somenode
Or to find the current location of my-test-rsc one can use:
crm_resource --locate --resource my-test-rsc
It is not necessary to modify a real cluster in order to test the effect of the configuration changes. Do the following to test your modifications:
Save the current configuration to a temporary file:
cibadmin --cib_query > /tmp/tmp.xml
Edit the temporary file with your favorite text or XML editor.
Simulate the effect of the changes with
ptest:
ptest -VVVVV --xml-file /tmp/tmp.xml --save-graph tmp.graph --save-dotfile tmp.dot
The tool uses the same library as the live cluster to show
the impact it would have done. Its output,
in addition to a significant amount of logging, is stored in two
files, tmp.graph and
tmp.dot. Both files are representations of the
same thing—the cluster’s response to your changes. In the
graph file the complete transition is stored, containing a list
of all actions, their parameters and their prerequisites.
The transition graph is not very easy to read. Therefore,
the tool also generates a Graphviz dot-file representing the same
information.
