On 26/03/15 12:19 PM, Christine Caulfield wrote: > 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 As a lay-person; what kind of cluster sizes might this theoretically enable? -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
