Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30

Lars Marowsky-Bree
2004-07-12T10:16:57Z

On 2004-07-08T18:53:38,
David Teigland <teigland@redhat.com> said:

> I'm afraid the fencing issue has been rather misrepresented. Here's
> what we're doing (a lot of background is necessary I'm afraid.) We
> have a symmetric, kernel-based, stand-alone cluster manager (CMAN)
> that has no ties to anything else whatsoever. It'll simply run and
> answer the question "who's in the cluster?" by providing a list of
> names/nodeids.

Excuse my ignorance, but does this ensure that there's concensus among
the nodes about this membership?

> has quorum. It's a very standard way of doing things -- we modelled it
> directly off the VMS-cluster style. Whether you care about this quorum value
> or what you do with it are beside the point.

OK, I agree with this. As long as the CMAN itself doesn't care about
this either but just reports it to the cluster, that's fine.

> What about Fencing? Fencing is not a part of the cluster manager, not
> a part of the dlm and not a part of gfs. It's an entirely independent
> system that runs on its own in userland. It depends on cman for
> cluster information just like the dlm or gfs does. I'll repeat what I
> said on the linux-cluster mailing list:

I doubt it can be entirely independent; or how do you implement lock
recovery without a fencing mechanism?

> This fencing system is suitable for us in our gfs/clvm work. It's
> probably suitable for others, too. For everyone? no.

It sounds useful enough even for our work, given appropriate
notification of fencing events; instead of scheduling a fencing event,
we'd need to make sure that the node joins a fencing domain and later
block until receiving a notification. It's not as fine grained, but our
approach (based on the dependencies of the resources managed, basically)
might have been more fine grained than required in a typical
environment.

Yes, I can see how that could be made to work.

Sincerely,
Lars Marowsky-Brée <lmb@suse.de>

--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs, Research and Development | try again. fail again. fail better.
SUSE LINUX AG - A Novell company \ -- Samuel Beckett