From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Teigland Date: Thu, 19 Nov 2009 11:04:04 -0600 Subject: [Cluster-devel] fencing conditions: what should trigger a fencing operation? In-Reply-To: <4B052D69.3010502@redhat.com> References: <4B052D69.3010502@redhat.com> Message-ID: <20091119170404.GA23287@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Thu, Nov 19, 2009 at 12:35:05PM +0100, Fabio M. Di Nitto wrote: > - what are the current fencing policies? node failure > - what can we do to improve them? node failure is a simple, black and white, fact > - should we monitor for more failures than we do now? corosync *exists* to to detect node failure > It is a known issue that node1 will crash at some point (kernel OOPS). oops is not necessarily node failure; if you *want* it to be, then you sysctl -w kernel.panic_on_oops=1 (gfs has also had it's own mount options over the years to force this behavior, even if the sysctl isn't set properly; it's a common issue. It seems panic_on_oops has had inconsistent default values over various releases, sometimes 0, sometimes 1; setting it has historically been part of cluster/gfs documentation since most customers want it to be 1.) Dave