> On 16 Apr 2015, at 5:09 pm, Christine Caulfield <ccaulfie@xxxxxxxxxx> wrote: > > On 13/04/15 08:26, Christine Caulfield wrote: >> On 13/04/15 04:44, Andrew Beekhof wrote: >>> >>>> On 31 Mar 2015, at 12:25 am, Christine Caulfield <ccaulfie@xxxxxxxxxx> wrote: >>>> >>>> This is an updated document based on the responses I've had. Thank you >>>> everyone. >> >>>> Which is client/server? (if satellites are client with authkey we >>>> get easy failover and config, but ... DOS potential??) >>> >>> satellites have to be the server. >>> otherwise security and failure are a nightmare. >> >> >> Agreed >> >>>> >>>> How to 'fake' satellite node IDs in the CPG nodes list - will >>>> probably need to extend the libcpg API. >>>> >>>> do we need to add 'fake' join/leave events too? >>>> >>>> What if tcp buffers get full? Suggest just cutting off the node. >>>> >>>> Fencing, do we need it? (pacemaker problem?) >>>> >>>> Keeping two node lists (totem/quorum and satellite) - duplicate node >>>> IDs are not allowed and this will need to be enforced. >>>> >>>> No real idea if this will scale as well as I hope it will! >>>> >>>> GFS2 et al? is this needed/possible? >>> >>> I’d not go there :) >>> >> >> Wise advice :) >> >>>> >>>> How (if at all) does knet fit into all this? >>>> >>>> How it will (possibly) work >>>> --------------------------- >>>> Have a separate daemon that runs on a corosync parent node and >>>> communicates between the local corosync & its satellites >>>> IDEA: Can we use the 'real' corosync libs and have a different server >>>> back end on the satellites? >>>> - reuse the corosync server-side IPC code >>>> >>>> CPG - would just be forwarded on to the parent with node ID 'fixed' >>>> cmap - forwarded to parent corosync >>>> quorum - keep own context >>>> CFG - shutdown request as corosync cfg >>>> >>>> Need some API (or cmap?) for satellite node list >>> >>> If you have the daemon make one connection per satellite (maybe by spawning a child for each one) they’d automatically show up in the CPG list. >>> >> >> They will get a unique CPG connection yes, but they will share a nodeid, >> The pid/nodeid pair will be unique though - would that be sufficient? >> >> if that's the case then we probably don't even need to allocate extra >> nodeids for satellites, just keep a list of nodeid/pid pairs. Which >> makes things a lot easier! >> > > It occurs to me that we can have both. As the nodeid/pid pairs are > unstable - a satellite could leave and rejoin and have a totally > different nodeid/pid pair - that might not be much use to pacemaker. Agreed. > But > we can map those to actual corosync.conf nodeids in the parent using > another API call as I planned to do anyway. Sounds fine to me. _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
