Re: [RFC] quorum module configuration bits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Wed, Jan 11, 2012 at 01:08:56PM -0500, David Teigland wrote:
> On Wed, Jan 11, 2012 at 11:21:59AM -0500, David Teigland wrote:
> > > I much prefer the expected_votes field to any enumeration of the nodes.
> > 
> > Expect admins to keep track of what expected_votes should be?
> > That sounds nearly impossible to do correctly.
> > 
> > > Does anyone need the list of nodes to be preconfigured?
> > 
> > The alternative would be trying to remember what they all are?
> > Defining the set of nodes that compose the cluster seems like
> > a very good thing just for its own sake.
> 
> I guess that's just one view.  There really are two legitimate styles
> of assembling a cluster that we're trying to merge.
> 
> In the first, you have a conceptual view of just a big pool nodes, more
> or less anonymous.  They are just "workers", which higher level software
> (e.g. pacemaker) can use as needed to run things.
> 
> The second is a more fixed, static approach.  You start with with some
> specific nodes and you want to access some shared resource from those
> nodes.  Because the resource is shared, there needs to be clustering
> involved to access it.  e.g. this node needs to mount that gfs2 file
> system.
> 
> The first view has historically been taken by corosync and pacemaker,
> and the second by cman/gfs2.  Folks with the first view would think
> of a static node list as unnecessary, whereas it's the starting point
> in the second view.

Not sure if I can recall exactly, but HPC clusters belong to the
first category. At least I'd expect them to.

Even though corosync doesn't require (for multicast) a fixed list
of nodes, I'd put it also in the second category. I doubt that
there are many corosync or openais clusters which have node sets
frequently changing. As for pacemaker, it just gets the
membership events and creates nodes as necessary. Heartbeat
requires that all nodes are listed in static configuration files.

As for whether admins can err counting nodes I guess it's not
likely for small clusters. Though one never knows ;-)

Thanks,

Dejan

> Anyway, I think that explains the disconnect.  Getting back to the real
> question of what needs a node list, quorum is the only thing I can think of.
> 
> _______________________________________________
> discuss mailing list
> discuss@xxxxxxxxxxxx
> http://lists.corosync.org/mailman/listinfo/discuss
_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss


[Index of Archives]     [Linux Clusters]     [Corosync Project]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Linux Kernel]     [Linux SCSI]     [X.Org]

  Powered by Linux