On 27/03/15 07:31, Jan Friesse 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. Yes, this is basically that remote CPG idea with bells on I suppose :) CPG messages still have a nodeid in them, and that's not going to change - satellites have unique nodeid just like quorum nodes. So a message sent from a satellite will have the correct nodeid in it. Having just written that I realise that we are going to have to send CPG join/leave messages for satellites. I'll add that to the list! > > 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. > Hard but probably not impossible. I think it should be a goal, but not a 1.0 one. Chrissie _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
