[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 2004-08-11T09:18:50,
   John Cherry <cherry osdl org> said:

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

Let's be a bit more specific, we have so far agreed on defining the
membership API in the kernel (and likely starting from the cman one
here), but via a vfs-like "Virtual Cluster Switch" with pluggable
components right from the start, of which cman may be one, or a module
to go out and talk to a user-level membership implementation another.

That all these components need to be in the kernel hasn't been quite
agreed on, just that their information needs to be available there.

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

Right.

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

Communication was specifically excluded because the communication APIs
are much more complex to define; how the membership is computed
internally is, well, internal to the membership module, and thus is it's
communication method...

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

Eventually, but it's also more complex and was thus excluded. We
specifically listed those three components I gave, for good reasons...

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

GFS for one doesn't need any further communication channels beyond the
DLM and membership.

There's more components which are needed here, ie the recovery
coordination provided by their Service Manager and some others, however
for very good reasons (both their technical as their political
complexity) those were left out of the initial go at this.

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

You better be as careful as everyone was at the Summit, or you'll
quickly be treading very loose ground ;-)


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

-- 
High Availability & Clustering	    \ Philosophy proclaiming reason to be 
SUSE Labs, Research and Development | the supreme human virtue is falling
SUSE LINUX AG - A Novell company    \ prey to self-adulation.


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