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. 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. Cheers Fabio
quorum_proposal.pdf
Description: Adobe PDF document
_______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
