Creating a Framework for High Availability with Pacemaker - Revision history

Malcolm: /* resource-stickiness */

2017-09-11T23:50:43Z

resource-stickiness

← Older revision		Revision as of 16:50, 11 September 2017
Line 432:		Line 432:
	If a resource is running on a non-preferred node, and the resource is healthy, it will not be migrated automatically back to its preferred node. If the stickiness is higher than the preference score of a resource, the resource will not move automatically while the machine it is running on remains healthy.		If a resource is running on a non-preferred node, and the resource is healthy, it will not be migrated automatically back to its preferred node. If the stickiness is higher than the preference score of a resource, the resource will not move automatically while the machine it is running on remains healthy.

	The default value is 0 (zero). It's common to set the value greater than 100 as an indicator that the resource should not be disrupted by migrating it automatically, if the resource and the node it is running on are both healthy.		The default value is 0 (zero). It's common to set the value greater than 100 as an indicator that the resource should not be disrupted by migrating it automatically if the resource and the node it is running on are both healthy.

	<pre style="overflow-x:auto;">		<pre style="overflow-x:auto;">

Malcolm: /* Configure the PCS Daemon */

2017-09-11T06:24:42Z

Configure the PCS Daemon

← Older revision		Revision as of 23:24, 10 September 2017
Line 159:		Line 159:
	<li>Start the Pacemaker configuration daemon, <code>pcsd</code>, on all servers:		<li>Start the Pacemaker configuration daemon, <code>pcsd</code>, on all servers:
	<ul>		<ul>
	<li>RHEL 7: <~~code~~>systemctl start pcsd.service</~~code~~></li>		<li>RHEL 7:
	<li>RHEL 6: <~~code~~>service pcsd start</~~code~~></li>		<pre style="overflow-x:auto;">
			systemctl start pcsd.service
			systemctl enable pcsd.service
			</pre>
			</li>
			<li>RHEL 6:
			<pre style="overflow-x:auto;">
			service pcsd start
			chkconfig pcsd on
			</pre>
			</li>
	</ul>		</ul>
	</li>		</li>

Malcolm at 05:04, 8 September 2017

2017-09-08T05:04:47Z

← Older revision		Revision as of 22:04, 7 September 2017
Line 1:		Line 1:
			== Introduction ==

	High availability, usually abbreviated to "HA", is a term used to describe systems and software frameworks that are designed to preserve application service availability even in the event of failure of a component of the system. The failed component might be software or hardware; the HA framework will attempt to respond to the failure such that the applications running within the framework continue to operate correctly.		High availability, usually abbreviated to "HA", is a term used to describe systems and software frameworks that are designed to preserve application service availability even in the event of failure of a component of the system. The failed component might be software or hardware; the HA framework will attempt to respond to the failure such that the applications running within the framework continue to operate correctly.

Malcolm at 04:56, 8 September 2017

2017-09-08T04:56:02Z

← Older revision		Revision as of 21:56, 7 September 2017
Line 38:		Line 38:
	This article will demonstrate how to configure a Lustre high-availability building block using two servers and a dedicated external storage array that is connected to both servers. The two-node building block designs for metadata servers and object storage servers provide a suitable basis for deployment of a production-ready, high-availability Lustre parallel file system cluster.		This article will demonstrate how to configure a Lustre high-availability building block using two servers and a dedicated external storage array that is connected to both servers. The two-node building block designs for metadata servers and object storage servers provide a suitable basis for deployment of a production-ready, high-availability Lustre parallel file system cluster.

	[[#Figure 13\|Figure 13]] shows a blue-print for typical high-availability Lustre server building blocks, one for the metadata and management services, and one for object storage.		[[#Figure 1\|Figure 1]] shows a blue-print for typical high-availability Lustre server building blocks, one for the metadata and management services, and one for object storage.

	<div id="Figure 13">		<div id="Figure 1">
	[[File:Lustre HA Server Building Blocks hires v1.png\|thumb\|center\|~~450px~~\|Figure 13. Lustre Server High-Availability Building Blocks]]		[[File:Lustre HA Server Building Blocks hires v1.png\|thumb\|center\|512px\|Figure 1. Lustre Server High-Availability Building Blocks]]
	</div>		</div>

	Each server depicted in [[#Figure 13\|Figure 13]] requires three network interfaces:		Each server depicted in [[#Figure 1\|Figure 1]] requires three network interfaces:
	# A dedicated cluster communication network between paired servers, used as a Corosync communications ring. This can be a cross-over / point-to-point connection, or can be made via a switch.		# A dedicated cluster communication network between paired servers, used as a Corosync communications ring. This can be a cross-over / point-to-point connection, or can be made via a switch.
	# A management network or public interface connection. This will be used by the HA cluster as an additional communications ring for Corosync.		# A management network or public interface connection. This will be used by the HA cluster as an additional communications ring for Corosync.

Malcolm: /* RHEL / CentOS */

2017-09-08T04:40:56Z

RHEL / CentOS

← Older revision		Revision as of 21:40, 7 September 2017
Line 124:		Line 124:
	</pre>		</pre>
	</li>		</li>
	<li>Lustre also requires port 988 to be open for incoming connections, and ports 1021-1023 for outgoing connections.		<li>Lustre also requires port <code>988</code> to be open for incoming connections, and ports 1021-1023 for outgoing connections.
	</li>		</li>

Malcolm at 03:26, 8 September 2017

2017-09-08T03:26:51Z

← Older revision		Revision as of 20:26, 7 September 2017
Line 538:		Line 538:

	For example, if one of the cluster node addresses shows up as <code>localhost</code> or <code>127.0.0.1</code>, this indicates a problem with the addresses supplied to <code>pcs</code> with the <code>--addr0</code> or <code>--addr1</code> flags.		For example, if one of the cluster node addresses shows up as <code>localhost</code> or <code>127.0.0.1</code>, this indicates a problem with the addresses supplied to <code>pcs</code> with the <code>--addr0</code> or <code>--addr1</code> flags.

			== Next Steps ==

			* [[Lustre Server Fault Isolation with Pacemaker Node Fencing]]
			* [[Creating Pacemaker Resources for Lustre Storage Services]]

	[[Category:Lustre High Availability]]		[[Category:Lustre High Availability]]
	[[Category:Lustre Systems Administration]]		[[Category:Lustre Systems Administration]]

Malcolm: /* stonith-enabled */

2017-09-08T03:23:36Z

stonith-enabled

← Older revision		Revision as of 20:23, 7 September 2017
Line 396:		Line 396:
	==== <code>stonith-enabled</code> ====		==== <code>stonith-enabled</code> ====

	The <code>stonith-enabled</code> property tells the cluster whether or not there are fencing agents configured on the cluster. If set to <code>true</code> (strongly recommended and essential for any production deployment), the cluster will try to fence any nodes that are running resources that cannot be stopped. The cluster will also refuse to start any resources unless there is at least one STONITH resource configured.		The <code>stonith-enabled</code> property tells the cluster whether or not there are [[Lustre Server Fault Isolation with Pacemaker Node Fencing\|fencing agents]] configured on the cluster. If set to <code>true</code> (strongly recommended and essential for any production deployment), the cluster will try to fence any nodes that are running resources that cannot be stopped. The cluster will also refuse to start any resources unless there is at least one STONITH resource configured.

	The property should only ever be set to <code>false</code> when the cluster will be used for demonstration purposes.		The property should only ever be set to <code>false</code> when the cluster will be used for demonstration purposes.

Malcolm: /* stonith-enabled */

2017-09-08T03:21:51Z

stonith-enabled

← Older revision		Revision as of 20:21, 7 September 2017
Line 396:		Line 396:
	==== <code>stonith-enabled</code> ====		==== <code>stonith-enabled</code> ====

	The <code>stonith-enabled</code> property tells the cluster whether or not there are fencing agents configured on the cluster. If set to <code>true</code> (strongly recommended and essential for any production deployment~~</code>~~, the cluster will try to fence any nodes that are running resources that cannot be stopped. The cluster will also refuse to start any resources unless there is at least one STONITH resource configured.		The <code>stonith-enabled</code> property tells the cluster whether or not there are fencing agents configured on the cluster. If set to <code>true</code> (strongly recommended and essential for any production deployment), the cluster will try to fence any nodes that are running resources that cannot be stopped. The cluster will also refuse to start any resources unless there is at least one STONITH resource configured.

	The property should only ever be set to <code>false</code> when the cluster will be used for demonstration purposes.		The property should only ever be set to <code>false</code> when the cluster will be used for demonstration purposes.

Malcolm: /* resource-stickiness */

2017-09-07T04:25:31Z

resource-stickiness

← Older revision		Revision as of 21:25, 6 September 2017
Line 420:		Line 420:
	If a resource is running on a non-preferred node, and the resource is healthy, it will not be migrated automatically back to its preferred node. If the stickiness is higher than the preference score of a resource, the resource will not move automatically while the machine it is running on remains healthy.		If a resource is running on a non-preferred node, and the resource is healthy, it will not be migrated automatically back to its preferred node. If the stickiness is higher than the preference score of a resource, the resource will not move automatically while the machine it is running on remains healthy.

	The default value is 0 (zero). It's common to set the value ~~to 1000~~ as an indicator that the resource should not be disrupted by migrating it automatically, if the resource and the node it is running on are both healthy.		The default value is 0 (zero). It's common to set the value greater than 100 as an indicator that the resource should not be disrupted by migrating it automatically, if the resource and the node it is running on are both healthy.

	<pre style="overflow-x:auto;">		<pre style="overflow-x:auto;">

Malcolm: /* resource-stickiness */

2017-09-07T04:24:55Z

resource-stickiness

← Older revision		Revision as of 21:24, 6 September 2017
Line 423:		Line 423:

	<pre style="overflow-x:auto;">		<pre style="overflow-x:auto;">
	pcs resource defaults resource-stickiness=~~1000~~		pcs resource defaults resource-stickiness=200
	</pre>		</pre>