1cman(5) cluster.conf cman configuration section cman(5)
3
7 cman - cluster.conf cman configuration section
8
11 Cman configuration values are placed in the <cman> </cman> sec‐
12 tion of cluster.conf. Per-node configuration related to cman is
13 placed in the standard <clusternode> </clusternode> sections.
14 All cman configuration settings are optional; usually none are
15 used. The <cman> section is placed under the <cluster> section
16 in cluster.conf.
17 <cluster>
19 <cman>
20 </cman>
21 ...
22 </cluster>
23 UDP port
26 By default, cman will use UDP port 5405/5404 for internode com‐
27 munication. This can be changed by setting a port number as
28 follows:
29 <cman port="6809">
31 </cman>
32 This will cause cman to use ports 6809 and 6808 for cluster com‐
34 munications.
35 Expected votes
39 The expected votes value is used by cman to determine quorum.
40 The cluster is quorate if the sum of votes of existing members
41 is over half of the expected votes value. By default, cman sets
42 the expected votes value to be the sum of votes of all nodes
43 listed in cluster.conf. This can be overridden by setting an
44 explicit expected_votes value as follows:
45 <cman expected_votes="3">
47 </cman>
48 If the cluster becomes partitioned, improper use of this option
50 can result in more than one partition gaining quorum. In that
51 event, nodes in each partition will enable cluster services.
52 Two node clusters
55 Ordinarily, the loss of quorum after one out of two nodes fails
56 will prevent the remaining node from continuing (if both nodes
57 have one vote.) Special configuration options can be set to
58 allow the one remaining node to continue operating if the other
59 fails. To do this only two nodes, each with one vote, can be
60 defined in cluster.conf. The two_node and expected_votes values
61 must then be set to 1 in the cman section as follows.
62 <cman two_node="1" expected_votes="1">
64 </cman>
65 Node votes
68 By default, a node is given one vote toward the calculation of
69 quorum. This can be changed by giving a node a specific number
70 of votes as follows:
71 <clusternode name="nd1" votes="2">
73 </clusternode>
74 Node ID
77 All nodes must have a unique node ID. This is a single integer
79 that identifies it to the cluster. A node's application to join
80 the cluster may be rejected if you try to set the nodeid to one
81 that is already used.
82 <clusternode name="nd1" nodeid="1">
84 </clusternode>
85 Multi-home configuration
87 It is quite common to use multiple ethernet adapters for cluster
88 nodes, so they will tolerate the failure of one link. A common
89 way to do this is to use ethernet bonding. Alternatively you can
90 get corosync to run in redundant ring mode by specifying an
91 'altname' for the node. This is an alternative name by which the
92 node is known, that resolves to another IP address used on the
93 other ethernet adapter(s). You can optionally specify a differ‐
94 ent port and/or multicast address for each altname in use. Only
95 one altname (2 interfaces in total) is valid for each node.
96 Note that if you are using the DLM with cman/corosync then you
98 MUST tell it to use SCTP as it's communications protocol as TCP
99 does not support multihoming.
100 <clusternode name="nd1" nodeid="1">
102 <altname name="nd1a" port="6809" mcast="239.192.0.2"/>
103 </clusternode>
104 <dlm protocol="sctp"/>
106 Multicast network configuration
109 cman uses multicast UDP packets to communicate with other nodes
110 in the cluster. By default it will generate a multicast address
111 using 239.192.x.x where x.x is the 16bit cluster ID number split
112 into bytes. This, in turn is generated from a hash of the clus‐
113 ter name though it can be specified explicitly. The purpose of
114 this is to allow multiple clusters to share the same subnet -
115 they will each use a different multicast address. You might
116 also/instead want to isolate clusters using the port number as
117 shown above.
118 It is possible to override the multicast address by specifying
120 it in cluster.conf as shown:
121 <cman>
123 <multicast addr="239.192.0.1"/>
124 </cman>
125 Cluster ID
128 The cluster ID number is used to isolate clusters in the same
129 subnet. Usually it is generated from a hash of the cluster name,
130 but it can be overridden here if you feel the need. Sometimes
131 cluster names can hash to the same ID.
132 <cman cluster_id="669">
134 </cman>
135 corosync security key
138 All traffic sent out by cman/corosync is encrypted. By default
139 the security key used is simply the cluster name. If you need
140 more security you can specify a key file that contains the key
141 used to encrypt cluster communications. Of course, the contents
142 of the key file must be the same on all nodes in the cluster. It
143 is up to you to securely copy the file to the nodes.
144 <cman keyfile="/etc/cluster/corosync.key">
146 </cman>
147 Note that this only applies to cluster communication. The DLM
149 does not encrypt traffic.
150 Other corosync parameters
153 When corosync is started by cman (cman_tool runs corosync), the
154 corosync.conf file is not used. Many of the configuration
155 parameters listed in corosync.conf can be set in cluster.conf
156 instead. Cman will read corosync parameters from the following
157 sections in cluster.conf and load them into corosync:
158 <cluster>
160 <totem />
161 <event />
162 <aisexec />
163 <group />
164 </cluster>
165 See the corosync.conf(5) man page for more information on keys
167 that are valid for these sections. Note that settings in the
168 <clusternodes> section will override settings in the sections
169 above, and options on the cman_tool command line will override
170 both. In particular, settings like bindnetaddr, mcastaddr,
171 mcastport and nodeid will always be replaced by values in <clus‐
172 ternodes>.
173 Cman uses different defaults for some of the corosync parameters
175 listed in corosync.conf(5). If you wish to use a non-default
176 setting, they can be configured in cluster.conf as shown above.
177 Cman uses the following default values:
178 <totem
180 vsftype="none"
181 token="10000"
182 token_retransmits_before_loss_const="20"
183 join="60"
184 consensus="4800"
185 rrp_mode="none"
186 <!-- or rrp_mode="active" if altname is present >
187 />
188 <aisexec user="root" group="root" />
189 Here's how to set the token timeout to five seconds:
191 <totem token="5000"/>
193
200 cluster.conf(5), corosync.conf(5), cman_tool(8)
201 cman(5)