1cluster.conf(5) File Formats Manual cluster.conf(5)
3
7 cluster.conf - The configuration file for cluster products
8
11 The cluster.conf file is located in the /etc/cluster directory. It is
12 the source of information used by the cluster products - accessed indi‐
13 rectly through CCS (see ccs(7)). This file contains all the informa‐
14 tion needed for the cluster to operate, such as: what nodes are in the
15 cluster and how to I/O fence those nodes. There is generic information
16 that is applicable to all cluster infrastructures, as well as specific
17 information relevant for specific cluster products.
18 This man page describes the generic contents of the cluster.conf file.
20 The product specific sections of cluster.conf are left to their respec‐
21 tive man pages. For example, after constructing the generic content, a
22 user should look at the cman(5) man page for further information about
23 the cman section of cluster.conf.
24 The cluster.conf file is an XML file. It has one encompassing section
26 in which everything is contained. That entity's name is cluster and it
27 has two mandatory attributes: name and config_version. The name
28 attribute specifies the name of the cluster. It is important that this
29 name is unique from other clusters the user might set up. The con‐
30 fig_version attribute is a number used to identify the revision level
31 of the cluster.conf file. Given this information, your cluster.conf
32 file might look something like:
33 <cluster name="alpha" config_version="1">
35 </cluster>
37 You should specify a <cman/> tag even if no special cman parameters are
39 needed for the cluster.
40 A mandatory subsection of cluster is fencedevices. It contains all of
42 the I/O fencing devices at the disposal of the cluster. The I/O fenc‐
43 ing devices are listed as entities designated as fencedevice and have
44 attributes that describe the particular fencing device. For example:
45 <fencedevices>
47 <fencedevice name="apc" agent="fence_apc"
48 ipaddr="apc_1" login="apc" passwd="apc"/>
49 </fencedevices>
50 Concerning the fencedevice entity, the name and agent attributes must
52 be specified for all I/O fence devices. The remaining attributes are
53 device specific and are used to specify the necessary information to
54 access the device. The name attribute must be unique and is used to
55 reference the I/O fence device in other sections of the cluster.conf
56 file. The agent attribute is used to specify the binary fence agent
57 program used to communicate with the particular device. Your clus‐
58 ter.conf file might now look something like:
59 <cluster name="alpha" config_version="1">
61 <cman/>
62 <fencedevices>
63 <fencedevice name="apc" agent="fence_apc"
64 ipaddr="apc_1" login="apc" passwd="apc"/>
65 <fencedevice name="brocade" agent="fence_brocade"
67 ipaddr="brocade_1" login="bro" passwd="bro"/>
68 <!-- The WTI fence device requires no login name -->
70 <fencedevice name="wti" agent="fence_wti"
71 ipaddr="wti_1" passwd="wti"/>
72 <fencedevice name="last_resort" agent="fence_manual"/>
74 </fencedevices> </cluster>
75 The final mandatory subsection of cluster is clusternodes. It contains
77 the individual specification of all the machines (members) in the clus‐
78 ter. Each machine has its own section, clusternode, which has the name
79 attribute - this should be the name of the machine. Each machine
80 should be given a unique node id number with the option nodeid
81 attribute. For example, nodeid="3". The clusternode section also con‐
82 tains the fence section. Not to be confused with fencedevices the
83 fence section is used to specify all the possible "methods" for fencing
84 a particular machine, as well as the device used to perform that method
85 and the machine specific parameters necessary. By example, the clus‐
86 ternodes section may look as follows:
87 <!-- This example only contains one machine -->
89 <clusternodes>
90 <clusternode name="nd01" nodeid="1">
91 <fence>
92 <!-- "power" method is tried before all others -->
93 <method name="power">
94 <device name="apc" switch="1" port="1"/>
95 </method>
96 <!-- If the "power" method fails,
97 try fencing through the "fabric" -->
98 <method name="fabric">
99 <device name="brocade" port="1"/>
100 </method> <!-- If all else fails,
101 make someone do it manually -->
102 <method name="human">
103 <device name="last_resort" ipaddr="nd01"/>
104 </method>
105 </fence>
106 </clusternode>
107 </clusternodes>
108 Putting it all together, a three node cluster's cluster.conf file might
110 look like:
111 <cluster name="example" config_version="1">
114 <cman/>
115 <clusternodes>
116 <clusternode name="nd01" nodeid="1">
117 <fence>
118 <!-- "power" method is tried before all others -->
119 <method name="power">
120 <device name="apc" switch="1" port="1"/>
121 </method>
122 <!-- If the "power" method fails,
123 try fencing through the "fabric" -->
124 <method name="fabric">
125 <device name="brocade" port="1"/>
126 </method> <!-- If all else fails,
127 make someone do it manually -->
128 <method name="human">
129 <device name="last_resort" ipaddr="nd01"/>
130 </method>
131 </fence>
132 </clusternode>
133 <clusternode name="nd02" nodeid="2">
134 <fence>
135 <!-- "power" method is tried before all others -->
136 <method name="power">
137 <device name="apc" switch="1" port="2"/>
138 </method>
139 <!-- If the "power" method fails,
140 try fencing through the "fabric" -->
141 <method name="fabric">
142 <device name="brocade" port="2"/>
143 </method> <!-- If all else fails,
144 make someone do it manually -->
145 <method name="human">
146 <device name="last_resort" ipaddr="nd02"/>
147 </method>
148 </fence>
149 </clusternode>
150 <clusternode name="nd11" nodeid="3">
151 <fence>
152 <!-- "power" method is tried before all others -->
153 <method name="power">
154 <!-- This machine has 2 power supplies -->
155 <device name="apc" switch="2" port="1"/>
156 <device name="wti" port="1"/>
157 </method>
158 <!-- If the "power" method fails,
159 try fencing through the "fabric" -->
160 <method name="fabric">
161 <device name="brocade" port="11"/>
162 </method> <!-- If all else fails,
163 make someone do it manually -->
164 <method name="human">
165 <device name="last_resort" ipaddr="nd11"/>
166 </method>
167 </fence>
168 </clusternode>
169 </clusternodes>
170 <fencedevices>
172 <fencedevice name="apc" agent="fence_apc"
173 ipaddr="apc_1" login="apc" passwd="apc"/>
174 <fencedevice name="brocade" agent="fence_brocade"
176 ipaddr="brocade_1" login="bro" passwd="bro"/>
177 <!-- The WTI fence device requires no login name -->
179 <fencedevice name="wti" agent="fence_wti"
180 ipaddr="wti_1" passwd="wti"/>
181 <fencedevice name="last_resort" agent="fence_manual"/>
183 </fencedevices> </cluster>
184 Special two-node cluster options:
186 Two-node clusters have special options in cluster.conf because they
188 need to decide quorum between them without a majority of votes. These
189 options are placed with the <cman/> tag. For example:
190 <cman two_node="1" expected_votes="1"/>
193 Validating your cluster.conf file:
196 While cluster.conf files produced by the system-config-cluster GUI are
198 pretty certain to be well-formed, it is convenient to have a way to
199 validate legacy configuration files, or files that were produced by
200 hand in an editor. If you have the system-config-cluster GUI, you can
201 validate a cluster.conf file with this command:
202 xmllint --relaxng /usr/share/system-config-cluster/misc/cluster.ng
204 /etc/cluster/cluster.conf
205 If validation errors are detected in your conf file, the first place to
207 start is with the first error. Sometimes addressing the first error
208 will remove all error messages. Another good troubleshooting approach
209 is to comment out sections of the conf file. For example, it is okay
210 to have nothing beneath the <rm> tag. If you have services, failover‐
211 domains and resources defined there, temporarily comment them all out
212 and rerun xmllint to see if the problems go away. This may help you
213 locate the problem. Errors that contain the string IDREF mean that an
214 attribute value is supposed to be shared two places in the file, and
215 that no other instance of the name string could be located. Finally,
216 the most common problem with hand-edited cluster.conf files is spelling
217 errors. Check your attribute and tag names carefully.
218
221 ccs(7), ccs_tool(8), cman(5)
222 cluster.conf(5)