| title: | Linux cluster Re cgl discussion Re dcl |
|
On Tue, 2004-08-10 at 13:58, Lars Marowsky-Bree wrote:
On 2004-08-10T13:49:26,
John Cherry <cherry@xxxxxxxx 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 isnt quite true. cman as a whole is not quite in the best position
for mainline acceptance; actually, most isnt.
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
doesnt 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 theres 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@xxxxxxx
|
