Messages in this thread | | | Subject | Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30 | From | Steven Dake <> | Date | Thu, 08 Jul 2004 12:41:21 -0700 |
| |
On Thu, 2004-07-08 at 11:22, Daniel Phillips wrote: > Hi Dave, > > On Thursday 08 July 2004 06:53, David Teigland wrote: > > We have a symmetric, kernel-based, stand-alone cluster manager (CMAN) > > that has no ties to anything else whatsoever. It'll simply run and > > answer the question "who's in the cluster?" by providing a list of > > names/nodeids. > > While we're in here, could you please explain why CMAN needs to be > kernel-based? (Just thought I'd broach the question before Christoph > does.) > > Regards, > > Daniel
Daniel,
I have that same question as well. I can think of several disadvantages:
1) security faults in the protocol can crash the kernel or violate system security 2) secure group communication is difficult to implement in kernel - secure group key protocols can be implemented fairly easily in userspace using packages like openssl. Implementing these protocols in kernel will prove to be very complex. 3) live upgrades are much more difficult with kernel components 4) a standard interface (the SA Forum AIS) is not being used, disallowing replaceability of components. This is a big deal for people interested in clustering that dont want to be locked into a partciular implementation. 5) dlm, fencing, cluster messaging (including membership) can be done in userspace, so why not do it there. 6) cluster services for the kernel and cluster services for applications will fork, because SA Forum AIS will be chosen for application level services. 7) faults in the protocols can bring down all of Linux, instead of one cluster service on one node. 8) kernel changes require much longer to get into the field and are much more difficult to distribute. userspace applications are much simpler to unit test, qualify, and release.
The advantages are: interrupt driven timers some possible reduction in latency related to the cost of executing a system call when sending messages (including lock messages)
I would like to share with you the efforts of the industry standards body Service Availability Forum (www.saforum.org). The Forum is intersted in specifying interfaces for improving availability of a system. One of the collections of APIs (called the application interface specification) utilizes redundant software components using clustering approaches to improve availability.
The AIS specification specifies APIs for cluster membership, application failover, checkpointing, eventing, messaging, and distributed locks. All of these services are designed to work with multiple nodes.
It would be beneficial to everyone to adopt these standard interfaces. Alot of thought has gone into them. They are pretty solid. And there are atleast two open source implementations under way (openais and linux-ha) and more on the horizon.
One of these projects, the openais project which I maintain, implements 3 of these services (and the rest will be done in the timeframes we are talking about) in user space without any kernel changes required. It would be possible with kernel to userland communication for the cluster applications (GFS, distributed block device, etc) to use this standard interface and implementation. Then we could avoid all of the unnecessary kernel maintenance and potential problems that come along with it.
Are you interested in such an approach?
Thanks -steve
> - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |