> On 27 Mar 2015, at 6:31 pm, Jan Friesse <[email protected]> wrote: > > Christine Caulfield napsal(a): >> 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? >> > > Looong time ago there was also idea about remote cpg. So basically > application uses special cpg which just forwards request to master node. So > only difference between normal and remote cpg would be IPC layer. In theory > this may be also way to go because it's essentially same idea as additional > daemon but without need for daemon. I can imagine to enrich CPG so not only > nodeid is sent but also IP of sending client so it would be possible to find > out which satellite "nodes" (clients) exists. > > What would be probably very hard to achieve (both daemon/remote cpg) seems to > be a possibility to have only ONE configuration file across all nodes > (master/satellite) and ability to promote one of satellite node to master > node when one of master nodes die.
Shouldn't be too bad as long as we still have the control plane connect to the satellites (and not the other way around). _______________________________________________ discuss mailing list [email protected] http://lists.corosync.org/mailman/listinfo/discuss
