cman(5) cluster.conf cman configuration section cman(5)NAMEcman - cluster.conf cman configuration section
DESCRIPTION
Cman configuration values are placed in the <cman> </cman> sec‐
tion 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>
UDP port
By default, cman will use UDP port 5405/5404 for internode com‐
munication. This can be changed by setting a port number as
follows:
<cman port="6809">
</cman>
This will cause cman to use ports 6809 and 6808 for cluster com‐
munications.
Expected votes
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>
If the cluster becomes partitioned, improper use of this option
can result in more than one partition gaining quorum. In that
event, nodes in each partition will enable cluster services.
Two node clusters
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>
Node votes
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>
Node ID
All nodes must have a unique node ID. This is a single integer
that identifies it to the cluster. A node's application to join
the cluster may be rejected if you try to set the nodeid to one
that is already used.
<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 differ‐
ent port and/or multicast address for each altname in use. Up to
9 altnames (10 interfaces in total) can be used.
Note that if you are using the DLM with cman/corosync then you
MUST tell it to use SCTP as it's communications protocol as TCP
does not support multihoming.
<clusternode name="nd1" nodeid="1">
<altname name="nd1a" port="6809" mcast="239.192.0.2"/>
</clusternode>
<dlm protocol="sctp"/>
Multicast network configuration
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 clus‐
ter 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.
It is possible to override the multicast address by specifying
it in cluster.conf as shown:
<cman>
<multicast addr="239.192.0.1"/>
</cman>
Cluster ID
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>
corosync security key
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>
Note that this only applies to cluster communication. The DLM
does not encrypt traffic.
Other corosync parameters
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>
See the corosync.conf(5) man page for more information on keys
that are valid for these sections. Note that settings in the
<clusternodes> section will override settings in the sections
above, and options on the cman_tool command line will override
both. In particular, settings like bindnetaddr, mcastaddr,
mcastport and nodeid will always be replaced by values in <clus‐
ternodes>.
Cman uses different defaults for some of the corosync parameters
listed in corosync.conf(5). If you wish to use a non-default
setting, they can be configured in cluster.conf as shown above.
Cman uses the following default values:
<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" />
Here's how to set the token timeout to five seconds:
<totem token="5000"/>
SEE ALSOcluster.conf(5), corosync.conf(5), cman_tool(8)cman(5)
