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

[Linux-cluster] Re: [cgl_discussion] Re: [dcl_discussion] Cluster summit materials



On Tue, 2004-08-10 at 13:58, Lars Marowsky-Bree wrote:
> On 2004-08-10T13:49:26,
>    John Cherry <cherry osdl org> said:
> 
> Hi John, minor correction here...
> > This is a work in progress since Daniel Phillips is continuing to add
> > The time was right to consider common clusters components.  While we
> > expected a fair amount of contention at the meetings, it was good to see
> > a fairly unanimous desire to identify common components that could be
> > leveraged over the various cluster implementations and to drive these
> > common components to mainline acceptance.  The common cluster components
> > identified at the summit were...
> > 
> >    cman - cluster manager (membership/quorum/heartbeat, recovery
> >           control.
> >    fence - userland daemon which decides which nodes need fencing
> >    dlm - fully distributed, fully symmetrical lock manager
> >    gfs - clustered filesystem
> > 
> > While these common components all have RHAT/Sistina roots, these
> > components are in the best position for mainline acceptance.  As APIs
> > are defined for these services, other implementations could also be used
> > (the vfs model).
> 
> This isn't quite true. cman as a whole is not quite in the best position
> for mainline acceptance; actually, most isn't.

I realize that cman will probably be at "alpha" level maturity in
October, but we did not discuss any other possibilities for kernel level
membership/communication.  linux-ha and openais have user level
components.  I suppose SSI membership could be considered as a candidate
implementation for the initial merge, but the consensus was that we
would focus on cman, define the APIs, and use cman as the initial
membership/communication module.  Multiple implementations would be good
and if we do a good job defining the APIs (membership, communication,
fencing), other membership services could be used down the road.

Was I at a different summit than you attended, or is that your
understanding of the strategic direction of moving Linux to be a
"clusterable kernel"?

> 
> However, what was identified was that the following components
> 
> - membership

How can we have membership without some form of communication service?
(communication-based membership or connectivity-based membership)

The low level cluster communication mechanism is one of those services
that I believe we need an API definition for since it will also be
leveraged by higher level services such as group messaging or an event
service.

So you can call the core service "membership", but what we really need
is membership/communication, which is what cman provides.  Do you have
another suggestion for this?  TIPC + membership?

> - DLM
> - Fencing

At the summit I attended, we also talked about using GFS as the initial
"consumer" of the cluster infrastructure.  The cluster infrastructure
doesn't stand a chance of mainline acceptance without a consumer that
both validates the interfaces and hardens the services.

I am not being as subtile as RHAT was at the summit.  If we are going to
start the process to mainline the components needed to make linux a
"clusterable kernel" this year, we will need to get behind the core
services that we discussed at the summit.

John

> 
> would be the best ones to work on merging first, but it was acknowledged
> that there's quite some work left for these to be done, in particular on
> the API and the conceptual model behind it.
> 
> 
> Sincerely,
>     Lars Marowsky-Brée <lmb suse de>


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