8.2. Creating a Basic Cluster Configuration File
/etc/cluster/cluster.conf) and start running the High Availability Add-On. As a starting point only, this section describes how to create a skeleton cluster configuration file without fencing, failover domains, and HA services. Subsequent sections describe how to configure those parts of the configuration file.
- At any node in the cluster, create
/etc/cluster/cluster.conf, using the template of the example in Example 8.1, “
cluster.confSample: Basic Configuration”.
- (Optional) If you are configuring a two-node cluster, you can add the following line to the configuration file to allow a single node to maintain quorum (for example, if one node fails):
<cman two_node="1" expected_votes="1"/>When you add or remove the
two_nodeoption from the
cluster.conffile, you must restart the cluster for this change to take effect when you update the configuration. For information on updating a cluster configuration, see Section 9.4, “Updating a Configuration”. For an example of specifying the
two_nodeoption, see Example 8.2, “
cluster.confSample: Basic Two-Node Configuration”.
- Specify the cluster name and the configuration version number using the
config_version(see Example 8.1, “
cluster.confSample: Basic Configuration” or Example 8.2, “
cluster.confSample: Basic Two-Node Configuration”).
- In the
clusternodessection, specify the node name and the node ID of each node using the
nodeid. The node name can be up to 255 bytes in length.
- Validate the file against the cluster schema (
cluster.rng) by running the
ccs_config_validatecommand. For example:
- Propagate the configuration file to
/etc/cluster/in each cluster node. For example, you could propagate the file to other cluster nodes using the
NotePropagating the cluster configuration file this way is necessary the first time a cluster is created. Once a cluster is installed and running, the cluster configuration file can be propagated using the
cman_tool version -rcommand. It is possible to use the
scpcommand to propagate an updated configuration file; however, the cluster software must be stopped on all nodes while using the
scpcommand. In addition, you should run
ccs_config_validateif you propagate an updated configuration file by means of the
NoteWhile there are other elements and attributes present in the sample configuration file (for example,
fencedevices), there is no need to populate them now. Subsequent procedures in this chapter provide information about specifying other elements and attributes.
- Start the cluster. At each cluster node enter the following command:
service cman startFor example:
service cman startStarting cluster: Checking Network Manager... [ OK ] Global setup... [ OK ] Loading kernel modules... [ OK ] Mounting configfs... [ OK ] Starting cman... [ OK ] Waiting for quorum... [ OK ] Starting fenced... [ OK ] Starting dlm_controld... [ OK ] Starting gfs_controld... [ OK ] Unfencing self... [ OK ] Joining fence domain... [ OK ]
- At any cluster node, run
cman_tool nodesto verify that the nodes are functioning as members in the cluster (signified as "M" in the status column, "Sts"). For example:
cman_tool nodesNode Sts Inc Joined Name 1 M 548 2010-09-28 10:52:21 node-01.example.com 2 M 548 2010-09-28 10:52:21 node-02.example.com 3 M 544 2010-09-28 10:52:21 node-03.example.com
- If the cluster is running, proceed to Section 8.3, “Configuring Fencing”.
Basic Configuration Examples
cluster.confSample: Basic Configuration” and Example 8.2, “
cluster.confSample: Basic Two-Node Configuration” (for a two-node cluster) each provide a very basic sample cluster configuration file as a starting point. Subsequent procedures in this chapter provide information about configuring fencing and HA services.
cluster.conf Sample: Basic Configuration
<cluster name="mycluster" config_version="2"> <clusternodes> <clusternode name="node-01.example.com" nodeid="1"> <fence> </fence> </clusternode> <clusternode name="node-02.example.com" nodeid="2"> <fence> </fence> </clusternode> <clusternode name="node-03.example.com" nodeid="3"> <fence> </fence> </clusternode> </clusternodes> <fencedevices> </fencedevices> <rm> </rm> </cluster>
cluster.conf Sample: Basic Two-Node Configuration
<cluster name="mycluster" config_version="2"> <cman two_node="1" expected_votes="1"/> <clusternodes> <clusternode name="node-01.example.com" nodeid="1"> <fence> </fence> </clusternode> <clusternode name="node-02.example.com" nodeid="2"> <fence> </fence> </clusternode> </clusternodes> <fencedevices> </fencedevices> <rm> </rm> </cluster>
consensus Value for
totem in a Two-Node Cluster
consensusvalue in the
totemtag in the
cluster.conffile so that the
consensusvalue is calculated automatically. When the
consensusvalue is calculated automatically, the following rules are used:
- If there are two nodes or fewer, the
consensusvalue will be (token * 0.2), with a ceiling of 2000 msec and a floor of 200 msec.
- If there are three or more nodes, the
consensusvalue will be (token + 2000 msec)
cmanutility configure your consensus timeout in this fashion, then moving at a later time from two to three (or more) nodes will require a cluster restart, since the consensus timeout will need to change to the larger value based on the token timeout.
<totem token="X" consensus="X + 2000" />
cman, the number of physical nodes is what matters and not the presence of the
two_node=1directive in the