[cgl_discussion] Re: [dcl_discussion] Cluster summit materials

John Cherry cherry at osdl.org
Wed Aug 11 14:42:27 PDT 2004

On Wed, 2004-08-11 at 13:55, Lars Marowsky-Bree wrote:
> On 2004-08-11T09:18:50,
>    John Cherry <cherry at 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.

Quite right.  The primary "next step" we defined was to agree on the
membership API in the kernel.  In the OSS community, this means to
provide code that works and define the API based on the working code. 
You have to start with something, and cman (or whatever it becomes) is a
likely first candidate.  With a vfs-like cluster switch, any membership
service could be plugged in, including one that goes out and talks to a
user level membership implementation.  I wonder which one you might have
in mind?  :)

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

Yes.  Perhaps the communication API definitions were excluded in the
first go-around.  However, you have to admit that cluster communication
IS required, if for nothing else to provide redundant communication
paths, and exposing this communication API would be valuable for higher
level services.  For instance, you don't want an event service to
provide a completely orthogonal communication mechanism in the cluster
when it could use the one that also provides the cluster heartbeat

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

OK.  I admit that we were not going to focus on the communication API in
the first go-around.

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

I can agree with that.

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

Agreed.  However, fencing will probably need to be addressed as we
define the membership API.

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

Sorry.  I didn't mean to put words into anybody's mouth.  However, if
there was disagreement with the basic strategy moving forward....it was
pretty stealthy.  :)


More information about the cgl_discussion mailing list