On 09/21/2011 10:23 PM, Andrew Beekhof wrote: > Stupid question, but if quorum is being calculated in quorumd, > shouldn't clients get it from there directly? > What's the advantage to corosync being involved (other than as a client itself)? > There are two problems with getting it directly from quorum daemon 1) The quorum state and cpg timing are not synced 2) more generically, it would be helpful to get all the low level cluster info from one location 1 is the deal killer though. Note we have this problem today in corosync because quorum and cpg are not synchronized. We plan to synchronize quorum delivery into the cpg callback stream so that cpg applications that need quorum will only obtain callbacks if they are part of the primary component. In order to do this synchronization, the quorum information has to come from corosync (and more specifically the cpg interface). Regards -steve >> >> On Wed, Aug 17, 2011 at 6:26 PM, Fabio M. Di Nitto <fdinitto@xxxxxxxxxx> wrote: >>> Hi all, >>> >>> for a long time cman has been the quorum provider within RHCS. cman is >>> going to be obsoleted in the long term and a replacement needs to be >>> implemented. >>> >>> In this proposal I left out API names.. they are not important at this >>> stage and can be defined later on (also because some interfaces like >>> confdb/objdb might change in 2.0). >>> >>> I am also assuming that we want the option to plug different quorum >>> providers into the system (network based, disk based, etc) and different >>> algorithms to calculate quorum (YKD, etc). >>> >>> Attached to this email there is a small pdf with the data flow diagram >>> as one picture can explain better than 1000 words (at least given my >>> level of itaglish ;)) >>> >>> Keep always in mind that: >>> >>> 1) At any given time, only one "cluster view provider" feeds information >>> to quorumd. The provider must be the same across all nodes. >>> >>> 2) At any given time, only one "quorum calculation algorithm" can be >>> used and it must be the same across all nodes. >>> >>> 3) disk based provider can either be a separate daemon or run within >>> quorumd. Due to the nature of the provider, the implementation needs >>> either threads or libaio (that´s not very portable) and therefor it >>> cannot run within corosync directly for blocking reasons. >>> >>> 4) a quorum state change, has to trigger a cpg_1 notification (assuming >>> that we will use cpg as notification method, but that would save the >>> issue of synchronizing cpg notifications with quorum ones). >>> >>> 5) dispatch of notification between cpg_0 and cpg_1 has to be >>> synchronized to allow quorumd to act on network based cluster view >>> provider. In theory the only user for cpg_0 is quorumd. >>> > > _______________________________________________ > discuss mailing list > discuss@xxxxxxxxxxxx > http://lists.corosync.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
