| title: | Linux cluster Re cgl discussion Re dcl |
|
On 2004-08-11T09:18:50,
John Cherry <cherry@xxxxxxxx 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.
Lets 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 hasnt 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 its
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 its 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
doesnt stand a chance of mainline acceptance without a consumer that
both validates the interfaces and hardens the services.
GFS for one doesnt need any further communication channels beyond the
DLM and membership.
Theres 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 youll
quickly be treading very loose ground ;-)
Sincerely,
Lars Marowsky-Brée <lmb@xxxxxxx
--
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.
|
