On Thu, Apr 16, 2009 at 12:29:27PM -0500, David Teigland wrote: > VS guarantees that all cpg members will see the same sequence of messages > and configuration changes, i.e. history of events. If a cpg is partitioned, > that immediately violates VS. One part must be killed so that the remaining > nodes will all agree on one version of history, thus maintaining VS. > Partitioning can't be avoided, so an application must be able to deal with > it and kill/stop one part (assuming the app depends on VS.)
> corosync might make this easier by not merging cpg's (or even whole > clusters) that have been partitioned, but that raises other questions and > I've been told that doing it would be next to impossible. I've done more reading, and it's become clear why corosync works the way it does, and shouldn't really be blamed. Corosync implements the totem protocol which is Extended Virtual Synchrony. I never knew the difference between Virtual Synchrony and Extended Virtual Synchrony. It turns out that this partitioning/remerging behavior is exactly what makes EVS different from VS. EVS/totem assumes that an app wants to continue running after being partitioned, so it extends some message ordering guarantees among nodes in both partitions. Messages sent just before the partition may be delivered in both partitions, and the idea behind EVS is that these messages will be delivered in the same order in the separate partitions (even though other messages, and confchg's of course, will be different). To get this message ordering between partitions without violating other rules, EVS adds a second "transitional" configuration change. So an app sees two configuration changes, the first removing nodes, the second potentially adding nodes. It seems that most apps want the standard VS behavior, and there's some doubt about whether the EVS behaviors would really be wanted or needed in real applications. So, our apps are left doing some extra work to reduce the EVS behavior to something closer to "traditional" VS. Dave _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
