Two-Node Fedora 14 cluster.conf - Revision history

Digimer at 05:02, 6 March 2011

2011-03-06T05:02:27Z

← Older revision		Revision as of 05:02, 6 March 2011
Line 232:		Line 232:
	<!-- <totem keyfile=""> -->		<!-- <totem keyfile=""> -->

	<!--		<!--
			***
			I don't think this is right. <interface ...> is not used. Instead, ring 0
			uses the subnet that <clusternode name="..."> resolves to. The
			'<altname ...>' attribute sets the subnet that ring 1 uses.
			***

			*** Left in until confirmed that this is wrong.

	Totem 'interface' arguments:		Totem 'interface' arguments:
	You can specifiy one or two '<interface...>' arguments within		You can specifiy one or two '<interface...>' arguments within

Digimer: moved Two-Node Fedora 13 cluster.conf to Two-Node Fedora 14 cluster.conf: There are no changes between Fedora 13 and 14.

2010-11-09T04:29:13Z

moved Two-Node Fedora 13 cluster.conf to Two-Node Fedora 14 cluster.conf: There are no changes between Fedora 13 and 14.

← Older revision		Revision as of 04:29, 9 November 2010
(No difference)

Digimer at 14:46, 17 August 2010

2010-08-17T14:46:29Z

← Older revision		Revision as of 14:46, 17 August 2010
Line 1:		Line 1:
	{{howto_header}}		{{howto_header}}

			* [[Cluster.conf\|See here]] for a more complete list of <span class="code">cluster.conf</span> options.

	This is the <span class="code">/etc/cluster/cluster.conf</span> file used in the [[Two Node Fedora 13 Cluster]].		This is the <span class="code">/etc/cluster/cluster.conf</span> file used in the [[Two Node Fedora 13 Cluster]].

Digimer at 04:29, 14 August 2010

2010-08-14T04:29:41Z

← Older revision		Revision as of 04:29, 14 August 2010
Line 327:		Line 327:

	<!--		<!--
	If a node fails the heuristics checks and/or fails to contact the		If a node fails the heuristics checks and/or fails to contact the
	Q. ~~Define~~ a ~~cycle~~ and ~~timing.~~		quorum disk after this many intervals, it will be declared dead and
			will be fenced (a "Technical Knock Out"). To determine how long this
			will actually take, multiple 'interval' by 'tko' and you will have the
			value is seconds.

			If you are using Oracle RAC, be sure that this and the 'interval' value
			are high enough to give the RAC a chance to react to a failure first.
			So if your RAC timeout is set to 60 seconds, and you are using the
			default 'interval' of '2', it is recommended to set this to at least
			'35' (70 seconds).

			Q. Is there a modern variant on the 'cman_deadnode_timeout' and, if so,
			does interval*tko still need to be lower?
	-->		-->
	<!-- <quorumd tko="" /> -->		<!-- <quorumd tko="" /> -->
Line 356:		Line 368:
	<!--		<!--
	The storage device the quorum daemon uses. The device must be the same		The storage device the quorum daemon uses. The device must be the same
	on all nodes.		on all nodes. It has no default and must be set unless you set 'label'
			below. For example, if you created your quorum disk with the call:

			mkqdisk -c /dev/sdi1 -l rac_qdisk

			This will be set to '/dev/sdi1'. When possible, use set the 'label'
			option below as it is more robust. If you use 'label' instead of this
			then the device does not need to be the same amoung nodes. In short,
			don't set this unless you have a good reason to.
			Q. Is this true?
	-->		-->
	<!-- <quorumd device="" /> -->		<!-- <quorumd device="" /> -->

	<!--		<!--
	Specifies the quorum disk label created by the mkqdisk utility. If ~~this~~		Specifies the quorum disk label created by the 'mkqdisk' utility. If
	~~field contains an entry,~~ the ~~label overrides~~ the 'device' ~~field~~. If		you look at the example given in the 'device' argument above, then this
	this field is used, the quorum daemon reads /proc/partitions and checks for		would be 'rac_qdisk'. Setting this instead of 'device' is preferable.
	qdisk signatures on every block device found, comparing the		If you set this, then 'device' is in fact ignored.
	label against the ~~specified label~~. This is useful in configurations
	~~where~~ the quorum device name differs among nodes.		If this field is used, the quorum daemon reads '/proc/partitions' and
			checks for qdisk signatures on every block device found, comparing the
			label against the value below. This is useful in configurations where
			the quorum device name differs among nodes.
	-->		-->
	<!-- <quorumd label="" /> -->		<!-- <quorumd label="" /> -->

	~~<!--~~
	~~-->~~
	~~<!-- <quorumd ="" /> -->~~

Digimer at 17:10, 13 August 2010

2010-08-13T17:10:57Z

← Older revision		Revision as of 17:10, 13 August 2010
Line 298:		Line 298:
	This section is not required and can be left out when you aren't		This section is not required and can be left out when you aren't
	using a quorum disk partition.		using a quorum disk partition.

			A quorum partition cannot be used in clusters greater than 16 nodes.
			This is due to the latency caused be clusters larger that 16 nodes
			causing unreliable quorum disks. With 17 or more nodes, you must use
			IP-based (totem protocol) quorum only.

			A quorum disk must be a raw 10MB or larger (11MB recommended)
			partition on an iSCSI or SAN device. It is recommended that your nodes
			use multipath to access the quorum disk. You can not use a CLVM
			partition.
			Q. On a 2-node DRBD partition, can a raw 10MB partition be used? This
			is probably irrelevant as there is the 'two_node' cman option, but
			might be useful for the heuristics in a split brain.
			See: http://magazine.redhat.com/2007/12/19/enhancing-cluster-quorum-with-qdisk/
	-->		-->

Line 304:		Line 318:
	will attempt to write it's status to the quorum disk and read the		will attempt to write it's status to the quorum disk and read the
	status of other nodes. The higher this value is, the less chance that		status of other nodes. The higher this value is, the less chance that
	a transiant error will disolve quorum ~~and the~~ longer it will take to		a transiant error will disolve quorum. The longer it will take to
	detect and recover from a failure. The default is '2'.		detect and recover from a failure. The default is '2'. Please see the
			'<heuristics...>' section below for heuristics interval.
	Q. Is this accurate?		Q. Is this accurate?
			Q. Does this control the huristics or disk poll?
	-->		-->
	<!-- <quorumd interval="2" /> -->		<!-- <quorumd interval="2" /> -->

	<!--		<!--
	~~The number of cycles~~ a node ~~must miss~~ to ~~be declared dead.~~		If a node fails the heuristics checks and/or fails to contact the
	Q. Define a cycle and timing.		Q. Define a cycle and timing.
	-->		-->
Line 317:		Line 333:

	<!--		<!--
	~~The~~ number of votes the quorum ~~daemon advertises~~ to ~~CMAN~~ when ~~it has~~ a		This is the number of votes assigned to the quorum disk. This value
	~~high enough score~~.		should be the total number of votes of your cluster minus the minimum
			number of nodes your cluster can operate with. For example, if you have
			a four-node cluster that can operate with just one node, you would set
			this to '3' (4-1). This value must be set when using a quorum disk as
			there is no default.
			Q. Is this true, or would the votes be calculated?
	-->		-->
	<!-- <quorumd votes="" /> -->		<!-- <quorumd votes="" /> -->
Line 326:		Line 347:
	to 0, the default function, floor((n+1)/2), is used, where n is the sum		to 0, the default function, floor((n+1)/2), is used, where n is the sum
	of the heuristics scores. The Minimum Score value must never exceed the		of the heuristics scores. The Minimum Score value must never exceed the
	sum of the heuristic scores~~; otherwise~~, the ~~quorum disk cannot be~~		sum of the heuristic scores. If set higher, it will be impossible for
	~~available~~.		the heuristics tests to pass. If the resulting score is below this
			value, the node will reboot to try an return in a better state.
			Q. Does it reboot after one failure?
	-->		-->
	<!-- <quorumd min_score="" /> -->		<!-- <quorumd min_score="" /> -->
Line 591:		Line 614:
	-->		-->
	<fencedevice name="batou" agent="fence_na"		<fencedevice name="batou" agent="fence_na"
	ipaddr="batou.alteeve.com" login="~~user~~"		ipaddr="batou.alteeve.com" login="section9"
	passwd="~~secret~~" quiet="1"></fencedevice>		passwd="project2501" quiet="1"></fencedevice>
	<fencedevice name="motoko" agent="fence_na"		<fencedevice name="motoko" agent="fence_na"
	ipaddr="motoko.alteeve.com" login="~~user~~"		ipaddr="motoko.alteeve.com" login="section9"
	passwd="~~secret~~" quiet="1"></fencedevice>		passwd="project2501" quiet="1"></fencedevice>
	<!--		<!--
	If you have two or more fence devices, you can add the extra		If you have two or more fence devices, you can add the extra

Digimer at 14:55, 2 August 2010

2010-08-02T14:55:16Z

Show changes

Digimer at 21:53, 24 July 2010

2010-07-24T21:53:59Z

Show changes

Digimer at 03:19, 19 July 2010

2010-07-19T03:19:18Z

← Older revision		Revision as of 03:19, 19 July 2010
Line 12:		Line 12:
	version number will have to be incremented by 1.		version number will have to be incremented by 1.
	-->		-->
	<cluster name="an-cluster" config_version="1">		<cluster name="an-cluster" config_version="12">
	<!-- Totem Ring and the Redundant Ring Protocol -->		<!-- Totem Ring and the Redundant Ring Protocol -->
	<!--		<!--
Line 42:		Line 42:

	<!-- DLM; The Distributed Lock Manager -->		<!-- DLM; The Distributed Lock Manager -->
	<!-- ~~DLM kernel options~~ -->		<!-- Options can be combined in one <dlm...> statement. -->
	<!--		<!--
	This tells DLM to use automatically determine whether to use TCP or		This tells DLM to use automatically determine whether to use TCP or
Line 115:		Line 115:
	<dlm enable_plock="1" />		<dlm enable_plock="1" />
	<!--		<!--
	This controls the rate of plock operations. The default is '0', which		This controls the rate of plock operations per second. The default is
	is "unlimited". Set a positive whole integer to ~~set~~ a limit.		'0', which is "unlimited". Set a positive whole integer to impose a
	Q. ~~Is this a limit at any given time, operations per period of time,~~		limit. This mat be needed is excessive plock messages are causing
	~~etc?~~		network load issues.
	-->		-->
	<dlm plock_rate_limit="0"/>		<dlm plock_rate_limit="0"/>
	<!--		<!--
			This controls the plock ownership function. When enabled, performance
			gains may be seen where a given node repeatedly issues the same lock.
			By default, this is set to '1', enabled. This can affect backward
			compatibility with older versions of dlm. To disable it, set this to
			'0'.
			Q. Is this right? This should be explained better.
	-->		-->
	<dlm plock_ownership="1" />		<dlm plock_ownership="1" />
	<!--		<!--
			This is the number of milliseconds to wait before dropping the cache
			of lock information. The default is 10 seconds (10000). The lower this
			value, the better the performance but the more memory will be used.
			NOTE: This value is ignored when 'plock_ownership' is disabled.
			Q. Is this right?
	-->		-->
	<dlm drop_resources_time="10000"/>		<dlm drop_resources_time="10000"/>
	<!--		<!--
			This is the number of cached items to attempt to drop each
			'drop_resources_time' milliseconds. The higher this number, the better
			the potential performance, but the more memory will be used.
			NOTE: This value is ignored when 'plock_ownership' is disabled.
			Q. Is this right?
	-->		-->
	<dlm drop_resources_count="10"/>		<dlm drop_resources_count="10"/>
			<!--
			This is the number of milliseconds that a cached item is allowed to go
			unused before it is set to be dropped. The default it 10 seconds
			(10000). The lower this value, the better the performance but the more
			memory will be used.
			NOTE: This value is ignored when 'plock_ownership' is disabled.
			Q. Is this right?
			-->
			<dlm drop_resources_age="10000"/>

			<!-- GFS Control daemon -->
			<!--
			There are several <gfs_controld...> arguments that are still supported,
			but they have been deprecated in favour of the <dlm_controld...>
			arguments. To see a full list, please read the 'gfs_controld(8)' man
			page.

			The one remaining argument that is still current is 'enable_withdraw'.
			When set to '1', the default, GFS will respond to a withdrawl. To
			disable the responce, set this to '0'.
			Q. What does the responce actually do?
			-->
			<gfs_controld enable_withdraw="1"/>

	<!-- Cluster Nodes -->		<!-- Cluster Nodes -->
Line 223:		Line 261:
	-->		-->
	<fencedevice name="batou" agent="fence_na"		<fencedevice name="batou" agent="fence_na"
	ipaddr="batou.alteeve.com" login="~~username~~"		ipaddr="batou.alteeve.com" login="section9"
	passwd="~~secretpw~~" quiet="1"></fencedevice>		passwd="project2501" quiet="1"></fencedevice>
	<fencedevice name="motoko" agent="fence_na"		<fencedevice name="motoko" agent="fence_na"
	ipaddr="motoko.alteeve.com" login="~~username~~"		ipaddr="motoko.alteeve.com" login="section9"
	passwd="~~secretpw~~" quiet="1"></fencedevice>		passwd="project2501" quiet="1"></fencedevice>
	<!--		<!--
	If you have two or more fence devices, you can add the extra		If you have two or more fence devices, you can add the extra
Line 245:		Line 283:
	</fence_daemon>		</fence_daemon>
	</cluster>		</cluster>

	</source>		</source>

	{{footer}}		{{footer}}

Digimer at 18:50, 18 July 2010

2010-07-18T18:50:36Z

Show changes

Digimer at 03:24, 14 July 2010

2010-07-14T03:24:10Z

@@ Line 13: / Line 13: @@
 -->
 <cluster name="an-cluster" config_version="1">
 	<!--
 	This is a special cman argument to enable cluster services to run