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 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@xxxxxxx>
