Hi, I have been following this discussion. Corosync's scalability is important to our product. This looks like an interesting way to achieve that.
I just like to ask if this approach still preserves the "total order" among all the nodes including those satellite nodes? Thanks, Qiuping Li -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Christine Caulfield Sent: Thursday, March 26, 2015 12:20 PM To: [email protected] Subject: Re: [corosync] RFC: Extending corosync to high node counts On 26/03/15 10:36, Christine Caulfield wrote: > On 25/03/15 01:24, Steven Dake wrote: >> I think if you dont care about performance, you can have a daemon >> process (second process) connect as a cpg service and maintain an >> overlay network on top of CPG. Then many other external endpoints >> could connect to this server over TCP. > > That's an interesting idea that I quite like. And it might be nice and > easy to get a proof-of-concept up and running. > > It would probably require a different API to the normal corosync one > (I'm not sure that emulating libcpg etc for a different daemon would > be sensible). > > How does that sound to the Pacemaker team? > I've been thinking about Steven Dake's idea most of today and I really like it. It's clean, doesn't interfere with corosync internals and will be easier to implement and maintain. Also it won't break the on-wire protocol. The one main drawback I see is that the CPG membership will not include the satellite nodes (unless the parent joins the CPG once for each parent, which seems excessive). Looking at the pacemaker code this doesn't seem to be a problem. We can still send node up/down notifications if needed, even if a satellite joins the cluster, it would just show the same list of central nodes each time. I'm less worried about the performance hit for this sort of implementation though it does need to be borne in mind. I'll forward an updated document early next week for perusal if David or Andrew chip in about Pacemaker requirements above. thoughts? Chrissie _______________________________________________ discuss mailing list [email protected] http://lists.corosync.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list [email protected] http://lists.corosync.org/mailman/listinfo/discuss
