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. But we can map those to actual corosync.conf nodeids in the parent using another API call as I planned to do anyway. Chrissie _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
