lkml.org 
[lkml]   [2004]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30
    On 2004-07-05T16:27:51,
    Daniel Phillips <phillips@redhat.com> 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@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

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

    \
     
     \ /
      Last update: 2005-03-22 14:04    [W:0.025 / U:275.188 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site