Using Pacemaker with Lustre - Revision history

Brian: /* Configuring Resources */

2011-02-04T16:59:14Z

Configuring Resources

← Older revision		Revision as of 09:59, 4 February 2011
Line 211:		Line 211:
	For the ''device'' parameter it is highly recommended to avoid using <tt>/dev/sd</tt> device names but use something that is immune to device reordering such as the <tt>/dev/disk/by-/</tt> links. <tt>/dev/disk/by-uuid/</tt> for example should be coherent for the lifetime of a formatting of the target as those names are constructed with the ldiskfs (i.e. ext3/ext4) UUID. This value should only ever change if you reformat the target.		For the ''device'' parameter it is highly recommended to avoid using <tt>/dev/sd</tt> device names but use something that is immune to device reordering such as the <tt>/dev/disk/by-/</tt> links. <tt>/dev/disk/by-uuid/</tt> for example should be coherent for the lifetime of a formatting of the target as those names are constructed with the ldiskfs (i.e. ext3/ext4) UUID. This value should only ever change if you reformat the target.

	If you do reformat the target you can discover it's new UUID by running <tt>blkid</tt> after the format and either looking at it's output or looking in <tt>/dev/disk/by-uuid/</tt> for the new name.		If you do reformat the target you can discover it's new UUID by running <tt>blkid</tt> and <tt>udevtrigger</tt> after the format and either looking at it's output or looking in <tt>/dev/disk/by-uuid/</tt> for the new name.

	Once the new name has been determined you can update your resource with:		Once the new name has been determined you can update your resource with:

Brian: /* Configuring Resources */

2011-02-04T15:51:19Z

Configuring Resources

← Older revision		Revision as of 08:51, 4 February 2011
Line 208:		Line 208:

	The ''start'' and ''stop'' operations have each been set to a timeout of 300 sec. The resource is monitored at intervals of 120 seconds. The parameters "''device''", "''directory''" and "lustre" are passed to the ''mount'' command.		The ''start'' and ''stop'' operations have each been set to a timeout of 300 sec. The resource is monitored at intervals of 120 seconds. The parameters "''device''", "''directory''" and "lustre" are passed to the ''mount'' command.

			For the ''device'' parameter it is highly recommended to avoid using <tt>/dev/sd</tt> device names but use something that is immune to device reordering such as the <tt>/dev/disk/by-/</tt> links. <tt>/dev/disk/by-uuid/</tt> for example should be coherent for the lifetime of a formatting of the target as those names are constructed with the ldiskfs (i.e. ext3/ext4) UUID. This value should only ever change if you reformat the target.

			If you do reformat the target you can discover it's new UUID by running <tt>blkid</tt> after the format and either looking at it's output or looking in <tt>/dev/disk/by-uuid/</tt> for the new name.

			Once the new name has been determined you can update your resource with:

			<pre>
			crm resource param resMyOST set device /dev/disk/by-uuid/new-uuid
			</pre>

	'''2. Read the definition into your cluster configuration''' by entering:		'''2. Read the definition into your cluster configuration''' by entering:

Brian at 20:57, 1 February 2011

2011-02-01T20:57:21Z

← Older revision		Revision as of 13:57, 1 February 2011
Line 71:		Line 71:
	use_mgmtd: yes		use_mgmtd: yes
	}		}
			</pre>

			It is worth noting at this point that RHEL5 includes a basic firewall "out of the box". If you wish to run that firewall, you will need to add a rule to allow the Corosync traffic. I did this by adding a rule to the <tt>/etc/sysconfig/iptables</tt> file in the appropriate place:

			<pre>
			-A RH-Firewall-1-INPUT -p udp --dport 5405 -j ACCEPT
	</pre>		</pre>

Brian: Remove some ; from in front of a

block so that it formats correctly

2011-01-31T22:46:09Z

Remove some ; from in front of a <pre></pre> block so that it formats correctly

← Older revision		Revision as of 15:46, 31 January 2011
Line 65:		Line 65:
	'''4. (Optional) To use the Pacemaker GUI, add the ''mgmt'' daemon to the ''service'' section:'''		'''4. (Optional) To use the Pacemaker GUI, add the ''mgmt'' daemon to the ''service'' section:'''

	:<pre>		<pre>
	;service {		service {
	; name: pacemaker		name: pacemaker
	; version: 0		version: 0
	; use_mgmtd: yes		use_mgmtd: yes
	;}		}
	</pre>		</pre>

Misch: /* Polling the Failcounters */ -> Typo

2010-02-24T09:43:52Z

Polling the Failcounters: -> Typo

← Older revision		Revision as of 02:43, 24 February 2010
Line 416:		Line 416:
	If all the nodes of a cluster have problems, pushing information about events may be not be sufficient. An alternative is to check the failcounters of all resources periodically from the network management station (NMS). A simple script that checks for the presence of any failcounters in the output of ''crm_mon -1f'' is shown below:		If all the nodes of a cluster have problems, pushing information about events may be not be sufficient. An alternative is to check the failcounters of all resources periodically from the network management station (NMS). A simple script that checks for the presence of any failcounters in the output of ''crm_mon -1f'' is shown below:

	# crm_mon -1f \| grep ~~failcounter~~		# crm_mon -1f \| grep fail-count

	This script can be called by the NMS via SSH, or by the SNMP agent on the nodes by adding the following line to the Net-SNMP configuration in ''snmpd.conf'':		This script can be called by the NMS via SSH, or by the SNMP agent on the nodes by adding the following line to the Net-SNMP configuration in ''snmpd.conf'':

	extend failcounter crm_mon -1f \| grep -q ~~failcounter~~		extend failcounter crm_mon -1f \| grep -q fail-count

	The code returned by the script can be checked by the NMS using:		The code returned by the script can be checked by the NMS using:

Sbarthel at 19:17, 22 February 2010

2010-02-22T19:17:51Z

← Older revision		Revision as of 12:17, 22 February 2010
Line 1:		Line 1:
	~~----~~		<small>''(Updated: Jan 2010)''</small>

	DISCLAIMER - EXTERNAL CONTRIBUTOR CONTENT		<small>''DISCLAIMER - EXTERNAL CONTRIBUTOR CONTENT''</small>

	This content was submitted by an external contributor. We provide this information as a resource for the Lustre™ open-source community, but we make no representation as to the accuracy, completeness or reliability of this information.

			<small>''This content was submitted by an external contributor. We provide this information as a resource for the Lustre™ open-source community, but we make no representation as to the accuracy, completeness or reliability of this information.''</small>
	----		----
	__TOC__		__TOC__

Docadmin at 17:23, 22 January 2010

2010-01-22T17:23:34Z

← Older revision		Revision as of 10:23, 22 January 2010
Line 7:		Line 7:
	----		----
	__TOC__		__TOC__
	This page describes how to configure and use Pacemaker with Lustre failover. ~~For more about Lustre failover, see~~ [~~[Configuring Lustre for Failover]~~].		This page describes how to configure and use Pacemaker with Lustre failover. [http://www.multinet.de/ Dr. Michael Schwartzkopff] has contributed this content.

	[~~http://www.multinet.de/ Dr. Michael Schwartzkopff~~] ~~has contributed this content~~.		For more about Lustre failover, see [[Configuring Lustre for Failover]].

	== Setting Up Cluster Communications ==		== Setting Up Cluster Communications ==

Docadmin at 17:22, 22 January 2010

2010-01-22T17:22:19Z

← Older revision		Revision as of 10:22, 22 January 2010
Line 8:		Line 8:
	__TOC__		__TOC__
	This page describes how to configure and use Pacemaker with Lustre failover. For more about Lustre failover, see [[Configuring Lustre for Failover]].		This page describes how to configure and use Pacemaker with Lustre failover. For more about Lustre failover, see [[Configuring Lustre for Failover]].

			[http://www.multinet.de/ Dr. Michael Schwartzkopff] has contributed this content.

	== Setting Up Cluster Communications ==		== Setting Up Cluster Communications ==

Docadmin: /* Using crm_mon to send SNMP traps */

2010-01-18T18:34:36Z

Using crm_mon to send SNMP traps

← Older revision		Revision as of 11:34, 18 January 2010
Line 396:		Line 396:
	If a node fails, which could prevent the email from being sent, the resource is started on another node and an email about the successful start of the resource is sent out from the new node. The administrator's task is to search for the cause of the failover.		If a node fails, which could prevent the email from being sent, the resource is started on another node and an email about the successful start of the resource is sent out from the new node. The administrator's task is to search for the cause of the failover.

	==== Using ''crm_mon'' to ~~send~~ SNMP ~~traps~~ ====		==== Using ''crm_mon'' to Send SNMP Traps ====
	The ''crm_mon'' daemon can be used to send SNMP traps to a network management server. The configuration from the command line is:		The ''crm_mon'' daemon can be used to send SNMP traps to a network management server. The configuration from the command line is:

Docadmin: /* Administering the Cluster */

2010-01-18T18:28:49Z

Administering the Cluster

← Older revision		Revision as of 11:28, 18 January 2010
Line 320:		Line 320:
	# crm resource migrate resMyOST		# crm resource migrate resMyOST

	This command adds a location constraint to the configuration that specifies that the resource ''resMyOST'' ~~cannot~~ no longer run on the original node.		This command adds a location constraint to the configuration that specifies that the resource ''resMyOST'' can no longer run on the original node.

	To delete this constraint, enter:		To delete this constraint, enter: