On 17/08/11 09:26, Fabio M. Di Nitto 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. > > 6) quorumd is optional. corosync should work with or without. cpg_1 > clients will get different quorum info (QUORATED, NOT_QUORATED, > QUORUM_INFO_NOT_AVAILABLE, etc) based on the status.
A minor point but the language is simple QUORATE and not QUORATED > 7) quorumd will require some configuration or information to be able to > act correctly. For example "how many nodes are supposed to be in the > cluster?" etc. This is an implementation detail but it is something to > take into account. Most of those information are tight to the quorum > calculation algorithm and we will need to evaluate on a case by case how > to handle it correctly. How a quorum provider calculates quorum is entirely up to it and cannot be provided by lower layers really. It can ask for services (such as number of nodes, as you mentioned) but don't try to build anything more specific into the quorum interface as it'll just look silly and be ignored by most providers. Let them provide their own APIs for requesting data. What I did with quorum/votequorum might not be ideal but it shows the level of separation that's needed I think. Chrissie _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
