cluster/group/daemon cman.c cpg.c gd_internal. ...

cluster/group/daemon cman.c cpg.c gd_internal. ...

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	teigland@sourceware.org	2006-06-20 18:09:12

Modified files:
	group/daemon   : cman.c cpg.c gd_internal.h main.c 

Log message:
	Moving the cluster infrastructure to userland introduced a new problem
	that we didn't need to worry about before.  All cluster state now exists
	in userland processes which can go away and then come back like new, i.e.
	unaware of the previous state.
	
	Typically, when the userland cluster infrastructure on a node
	"disappears", another node recognizes this as a node failure and recovers.
	There's no problem there.  The problem is when the cluster infrastructure
	disappears on all the cluster nodes and then comes back.  The
	infrastructure that disappeared may have abandoned control of gfs/dlm
	instances in the kernel.  When the infrastructure comes back, it's like a
	brand new cluster, it knows nothing about the residual, uncontrolled
	instances of gfs/dlm.  New nodes would use gfs/dlm in this new cluster
	independently of the unknown gfs/dlm users from before and there'd be
	immediate corruption [1].
	
	Eventually, the infrastructure may be able to reconstruct the global state
	of abandoned instances of gfs/dlm when it comes back and reassert control
	of them, but that's not realistic any time soon.  For now, the
	infrastructure needs to recognize nodes with residual gfs/dlm state as
	failed nodes that need recovery (starting with fencing).  That recognition
	and recovery now happens as part of the startup initialization, before new
	instances of gfs/dlm are created [2].
	
	[1] This is trivial to demonstrate:
	- start up a cluster on nodes A,B,C
	- mount gfs on nodes A,B
	- run 'cman_tool leave force' on A,B,C
	- start up the cluster again on A,B,C
	- mount gfs on node C
	- nodes A,B are now using gfs independently of node C
	
	[2] The previous example now works like this:
	- start up a cluster on nodes A,B,C
	- mount gfs on nodes A,B
	- run 'cman_tool leave force' on A,B,C
	- start up the cluster again on A,B,C
	i)  when groupd starts on A,B, it recognizes the uncontrolled instance
	of gfs, kills cman locally and fences the local node [3]
	ii) when C runs fence_tool join, a new fence domain is started which
	fences nodes with an unknown state, which are A and B
	- mount gfs on node C
	
	[3] This self-fencing does nothing for node C which still needs to fence
	both A and B itself.  If A fences itself before C fences it, A will be
	fenced twice.  This self-fencing step is optional, but it can be
	convenient when 1) all the nodes restarting the infrastructure find
	residual gfs/dlm instances and 2) reboot fencing is used.  The anticipated
	situation is one where everyone has residual state so no one can start up
	to fence anyone else; all are stuck.  But, they all fence themselves,
	reboot and resolve everything.
	
	There's a different approach we could take that would be more convenient
	when not all cluster nodes are likely to be mounting gfs or SAN fencing is
	used.  In this case, a node that finds residual gfs/dlm instances would
	remain a cman member and not fence itself.  This would contribute quorum
	to help another node without residual state start up and fence it.
	
	The solution to this confusing situation is simple:
	- groupd now checks for residual gfs/dlm kernel state when it starts up
	and if it finds any it kills cman and exec's fence_node <myname>.
	- fenced can't bypass fencing of a node unless the node is both a cman
	member and has fully started groupd (a node may need fencing if it's
	joined the cluster but groupd isn't starting).
	- the same consideration in fence_manual as fenced

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/cman.c.diff?cvsroot=cluster&r1=1.22&r2=1.23
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/cpg.c.diff?cvsroot=cluster&r1=1.22&r2=1.23
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/gd_internal.h.diff?cvsroot=cluster&r1=1.30&r2=1.31
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/main.c.diff?cvsroot=cluster&r1=1.33&r2=1.34

cluster/group/daemon cman.c cpg.c gd_internal. ...

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	teigland@sourceware.org	2006-03-23 17:01:14

Modified files:
	group/daemon   : cman.c cpg.c gd_internal.h main.c 

Log message:
	Exit if we get POLLHUP on cman fd.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/cman.c.diff?cvsroot=cluster&r1=1.19&r2=1.20
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/cpg.c.diff?cvsroot=cluster&r1=1.15&r2=1.16
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/gd_internal.h.diff?cvsroot=cluster&r1=1.27&r2=1.28
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/main.c.diff?cvsroot=cluster&r1=1.30&r2=1.31

cluster/group/daemon cman.c cpg.c gd_internal. ...

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	teigland@sourceware.org	2006-02-22 21:49:15

Modified files:
	group/daemon   : cman.c cpg.c gd_internal.h groupd.h 

Log message:
	clean out a few unused bits

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/cman.c.diff?cvsroot=cluster&r1=1.13&r2=1.14
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/cpg.c.diff?cvsroot=cluster&r1=1.5&r2=1.6
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/gd_internal.h.diff?cvsroot=cluster&r1=1.20&r2=1.21
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/group/daemon/groupd.h.diff?cvsroot=cluster&r1=1.3&r2=1.4