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

[Lars Marowsky-Bree]

On 2004-07-05T16:27:51,
   Daniel Phillips <phillips@xxxxxxxxxx> said:

> > Indeed. If your efforts in joining the infrastructure are more
> > successful than ours have been, more power to you ;-)
> 
> What problems did you run into?

The problems were mostly political. Maybe we tried to push too early,
but 1-3 years back, people weren't really interested in agreeing on some
common components or APIs. In particular a certain Linux vendor didn't
even join the group ;-) And the "industry" was very reluctant too. Which
meant that everybody spend ages talking and not much happening.

However, times may have changed, and hopefully for the better. The push
to get one solution included into the Linux kernel may be enough to
convince people that this time its for real...

There still is the Open Clustering Framework group though, which is a
sub-group of the FSG and maybe the right umbrella to put this under, to
stay away from the impression that it's a single vendor pushing.

If we could revive that and make real progress, I'd be as happy as a
well fed penguin.

Now with OpenAIS on the table, the GFS stack, the work already done by
OCF in the past (which is, admittedly, depressingly little, but I quite
like the Resource Agent API for one) et cetera, there may be a good
chance.

I'll try to get travel approval to go to the meeting. 

BTW, is the mailing list working? I tried subscribing when you first
announced it, but the subscription request hasn't been approved yet...
Maybe I shouldn't have subscribed with the suse.de address ;-)

> On a quick read-through, it seems quite straightforward for quorum, 
> membership and distributed locking.

Believe me, you'd be amazed to find out how long you can argue on how to
identify a node alone - node name, node number (sparse or continuous?),
UUID...? ;-)

And, how do you define quorum, and is it always needed? Some algorithms
don't need quorum (ie, election algorithms can do fine without), so a
membership service which only works with quorum isn't the right
component etc...

> The idea of having more than one node fencing system running at the same 
> time seems deeply scary, we'd better make some effort to come up with 
> something common.

Yes. This is actually an important point, and fencing policies are also
reasonably complex. The GFS stack seems to tie fencing quite deeply into
the system (which is understandable, since you always have shared
storage, otherwise a node wouldn't be part of the GFS domain in the
first place).

However, the new dependency based cluster resource manager we are
writing right now (which we simply call "Cluster Resource Manager" for
lack of creativity ;) decides whether or not it needs to fence a node
based on the resources in the cluster - if it isn't affecting the
resources we can run on the remaining nodes, or none of the resources
requires node-level fencing, no such operation will be done. 

This has advantages in larger clusters (where, if split, each partition
could still continue to run resources which are unaffected by the split
even the other nodes cannot be fenced), in shared nothing clusters or
resources which are self-fencing and do not need STONITH etc.

The ties between membership, quorum and fencing are not as strong in
these scenarios, at least not mandatory. So a stack which enforced
fencing at these levels, and w/o coordinating with the CRM first, would
not work out.

And by pushing for inclusion into the main kernel, you'll also raise all
sleeping zom^Wbeauties. I hope you have a long breath for the
discussions ;-)

There's lots of work there.


Sincerely,
    Lars Marowsky-Brée <lmb@xxxxxxx>

-- 
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/