Two-Node CentOS 5 cluster.conf
This is the /etc/cluster/cluster.conf file used in the 2-Node CentOS5 Cluster.
Note: This is used in a generic node and should be safe to use and adapt for any 2-node cluster.
<?xml version="1.0"?> <!-- The cluster's name is "an-cluster" and, as this is the first version of this file, it is set to version "1". Each time this file changes in any way, the version number will have to be incremented by 1. --> <cluster name="an-cluster" config_version="1"> <!-- This is a special cman argument to enable cluster services to run without quorum. Being a two-node cluster, quorum with a failed node is quit impossible. :) If we had no need for this, we'd just put in the self-closing argument: <cman/> --> <cman two_node="1" expected_votes="1"> </cman> <!-- This is where the nodes in this cluster are defined. --> <clusternodes> <!-- AN!Cluster Node 1 --> <!-- The clusternode names must match the name returned by `uname -n`. --> <clusternode name="an-node01.alteeve.com" nodeid="1"> <fence> <!-- The entries here reference devices defined below in the <fencedevices/> section. The options passed control how the device is called. When multiple devices are listed, they are tried in the order that the are listed here. The 'name' argument must match a 'name' argument in the '<fencedevice>' section below. The details must define how 'fenced' will fence *this* device. The 'method' name seems to be unpassed to the fence agent and is useful to the human reader only? All options here are passed as 'var=val' to the fence agent, one per line. Note that 'action' was formerly known as 'option'. In the 'fence_na' agent, 'option' will be converted to 'action' if used. --> <method name="node_assassin"> <device name="motoko" port="01" action="off"/> </method> </fence> </clusternode> <!-- AN!Cluster Node 2 --> <clusternode name="an-node02.alteeve.com" nodeid="2"> <fence> <method name="node_assassin"> <device name="motoko" port="02" action="off"/> </method> </fence> </clusternode> </clusternodes> <!-- The fence device is mandatory and it defined how the cluster will handle nodes that have dropped out of communication. In our case, we will use the Node Assassin fence device. --> <fencedevices> <!-- This names the device, the agent (script) to controls it, where to find it and how to access it. --> <fencedevice name="motoko" agent="fence_na" ipaddr="motoko.alteeve.com" login="motoko" passwd="secret" quiet="1"> </fencedevice> <!-- If you have two or more fence devices, you can add the extra one(s) below. The cluster will attempt to fence a bad node using these devices in the order that they appear. --> </fencedevices> <!-- When the cluster starts, any nodes not yet in the cluster may be fenced. By default, there is a 6 second buffer, but this isn't very much time. The following argument increases the time window where other nodes can join before being fenced. I like to give up to one minute but the Red Hat man page suggests 20 seconds. Please do your own testing to determine what time is needed for your environment. --> <fence_daemon post_join_delay="60"> </fence_daemon> </cluster>
|Any questions, feedback, advice, complaints or meanderings are welcome.|
|Us: Alteeve's Niche!||Support: Mailing List||IRC: #clusterlabs on Freenode||© Alteeve's Niche! Inc. 1997-2019|
|legal stuff: All info is provided "As-Is". Do not use anything here unless you are willing and able to take responsibility for your own actions.|