table of contents
cman(5) | cluster.conf cman configuration section | cman(5) |
NAME¶
cman - cluster.conf cman configuration sectionDESCRIPTION¶
Cman configuration values are placed in the <cman> </cman> section of cluster.conf. Per-node configuration related to cman is placed in the standard <clusternode> </clusternode> sections. All cman configuration settings are optional; usually none are used. The <cman> section is placed under the <cluster> section in cluster.conf.
<cluster>
<cman>
</cman>
...
</cluster>
By default, cman will use UDP port 5405/5404 for internode communication. This can be changed by setting a port number as follows:
<cman port="6809">
</cman>
The expected votes value is used by cman to determine quorum. The cluster is quorate if the sum of votes of existing members is over half of the expected votes value. By default, cman sets the expected votes value to be the sum of votes of all nodes listed in cluster.conf. This can be overridden by setting an explicit expected_votes value as follows:
<cman expected_votes="3">
</cman>
Ordinarily, the loss of quorum after one out of two nodes fails will prevent the remaining node from continuing (if both nodes have one vote.) Special configuration options can be set to allow the one remaining node to continue operating if the other fails. To do this only two nodes, each with one vote, can be defined in cluster.conf. The two_node and expected_votes values must then be set to 1 in the cman section as follows.
<cman two_node="1" expected_votes="1">
</cman>
By default, a node is given one vote toward the calculation of quorum. This can be changed by giving a node a specific number of votes as follows:
<clusternode name="nd1" votes="2">
</clusternode>
<clusternode name="nd1" nodeid="1">
</clusternode>
Multi-home configuration
It is quite common to use multiple ethernet adapters for cluster nodes, so they will tolerate the failure of one link. A common way to do this is to use ethernet bonding. Alternatively you can get corosync to run in redundant ring mode by specifying an 'altname' for the node. This is an alternative name by which the node is known, that resolves to another IP address used on the other ethernet adapter(s). You can optionally specify a different port and/or multicast address for each altname in use. Up to 9 altnames (10 interfaces in total) can be used.
<clusternode name="nd1" nodeid="1">
<altname name="nd1a" port="6809" mcast="229.192.0.2"/>
</clusternode>
<dlm protocol="sctp"/>
cman uses multicast UDP packets to communicate with other nodes in the cluster. By default it will generate a multicast address using 239.192.x.x where x.x is the 16bit cluster ID number split into bytes. This, in turn is generated from a hash of the cluster name though it can be specified explicitly. The purpose of this is to allow multiple clusters to share the same subnet - they will each use a different multicast address. You might also/instead want to isolate clusters using the port number as shown above.
<cman>
<multicast addr="229.192.0.1"/>
</cman>
The cluster ID number is used to isolate clusters in the same subnet. Usually it is generated from a hash of the cluster name, but it can be overridden here if you feel the need. Sometimes cluster names can hash to the same ID.
<cman cluster_id="669">
</cman>
All traffic sent out by cman/corosync is encrypted. By default the security key used is simply the cluster name. If you need more security you can specify a key file that contains the key used to encrypt cluster communications. Of course, the contents of the key file must be the same on all nodes in the cluster. It is up to you to securely copy the file to the nodes.
<cman keyfile="/etc/cluster/corosync.key">
</cman>
When corosync is started by cman (cman_tool runs corosync), the corosync.conf file is not used. Many of the configuration parameters listed in corosync.conf can be set in cluster.conf instead. Cman will read corosync parameters from the following sections in cluster.conf and load them into corosync:
<cluster>
<totem />
<event />
<aisexec />
<group />
</cluster>
<totem
vsftype="none"
token="10000"
token_retransmits_before_loss_const="20"
join="60"
consensus="4800"
rrp_mode="none"
<!-- or rrp_mode="active" if altnames are present >
/>
<aisexec user="root" group="root" />
<totem token="5000"/>