> Isn't some of this covered by crm/corosync/pacemaker/heartbeat? Sorta, kinda, mostly no. Those implement virtual synchrony, which is closely related to consensus but not quite the same even in a formal CS sense. In practice, using them is *very* different. Two jobs ago, I inherited a design based on the idea that if everyone starts at the same state and handles the same messages in the same order (in that case they were using Spread) then they'd all stay consistent. Sounds great in theory, right? Unfortunately, in practice it meant that returning a node which had missed messages to a consistent state was our problem, and it was an unreasonably complex one. Debugging failure-during-recovery problems in that code was some of the least fun I ever had at that job. A consensus protocol, with its focus on consistency of data rather than consistency of communication, seems like a better fit for what we're trying to achieve. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
