[Gluster-users] [Gluster-devel] Proposal for GlusterD-2.0

Jeff Darcy jdarcy at redhat.com
Fri Sep 5 12:25:16 UTC 2014


> 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.


More information about the Gluster-users mailing list