On 12/01/2010 10:05 AM, Wez Furlong wrote: > On Dec 1, 2010, at 11:37 AM, Steven Dake wrote: > >> On 11/30/2010 12:02 PM, Wez Furlong wrote: >>> Hey folks, >>> >>> We use the agreed messaging mode of spread for coordinating nodes in our >>> cluster, and I've just discovered corosync. We have a love-hate >>> relationship with the spread software, and the possibility of moving to >>> another system with similar facilities is appealing to us (but at the same >>> time, we're not going to blindly leap!) >>> >> >> Which parts of spread don't you like? The main problem we had with >> spread was the license which made it unsuitable for use in open source >> distributions. > > The license is a source of frustration for us as well. > > We've had occasional mysterious hangs in the spread libraries (blocking with > no timeout) that are frustrating, but they are rare enough to not have posed > a serious problem for us (we have watchdog facilities for this)--it would be > nice to eliminate them, and/or to be able to work with an open community to > eliminate them. > >>> The evs_overview(8) docs suggest that EVS is not currently ready for prime >>> time, so I'm wondering which aspects of it need work? >>> >> >> Documentation in corosync is pretty weak and out of date. We spent our >> time writing good code instead ;) We hope to address the documentation >> issues in the future now that the code is quite stable. > > I know how that goes :-) > >> EVS is primetime - the api is very simple. We do recommend people use >> the CPG api (man cpg_overview) because it is where we intend to do our >> future development. > > I've very quickly skimmed the cpg man pages; the API looks very similar to > the evs functions; what's the main difference between the cpg and evs > facilities? >
CPG provides per-process membership information. EVS provides per node membership information. CPG also only allows publishing to groups the process is a member of (this is what makes it "closed"). Example: Node 1 has two processes 1023 and 1024 node 2 has three processes 1066 1067 1068 all processes are part of a cpg the last membership change will look something like 1:1023 1:1024 2:1066 2:1067 2:1068 Where evs the last membership change would be something like: 1 2 >> Corosync supports native rdma, udp broadcast, udp multicast, and udp >> unicast transports. Unlike spread, corosync is designed to only work >> within a LAN and as a result, there is higher latency when using over >> long haul networks. > > Do you have any numbers (rough/ballpark will be fine) on that increased > latency? Depends on wide area network latency, but no I don't have any measurements. > Are there any plans to improve operation over a wider area network, or is > that a definite non-goal for corosync? > In terms of priorities, wide area scaling is at the bottom of the list. Regards -steve > Thanks! > > --Wez. > _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
