On Mon, Apr 18, 2016 at 10:02:34AM -0600, Marcelo E. Magallon wrote: > On Mon, Apr 11, 2016 at 03:44:09PM -0700, Ben Pfaff wrote: > > On Fri, Apr 01, 2016 at 10:52:26AM -0700, Ben Pfaff wrote: > > > I don't think it makes sense to stack replication and Raft-based HA. > > > > > > Thinking about OpenSwitch, I guess that your use case is something > > > like this: an OpenSwitch instance maintains, on-box, an > > > authoritative database instance, and then the replication feature > > > allows that database's content to be backed up somewhere else. I > > > see how that differs from the use case for Raft, where there is no > > > preference for a particular database server to be authoritative. > > > What I don't see yet is how or why that's useful. What is the use > > > case? > > > > In case it wasn't clear, I didn't mean my message above to sound like > > a "no, we won't take this". Instead, I'm trying to understand the use > > case better. Perhaps there is room for both replication and HA in > > OVSDB, but before I say "yes" to that, I want to understand both > > cases. > > Yes, that's totally fair. > > We do not have a need for only 1+1 redundancy. We have a need in which > we have to remain operational with less than a quantum of instances in > operation, which raft can’t do unless you introduce modifications to > the algorithm (e.g. etcd or consul, I can't remember which one > exactly). > > Also, raft assumes that everybody's vote is equal. If you’re treating > multiple instances of OVS as one large virtual switch, you are not > running a separate version of OSPF on each instance, each feeding its > own version of the routing table into the database. You have one OSPF > instance on a "stack commander" feeding the entire routing table into > the database. This is the "correct" state, no matter how many raft > members have voted on it. We grow to more than 2 members by setting up > multiple one way replications, all originating from the "commander". In > future patches, we will also implement two way replication so that the > member can write to his local database to reflect state that the > commander cannot know about (like port state) ... until that happens > daemons on a "member" can connect directly to the commander's OVSDB > instance and update the commander's state directly. > > This work is done in the conetxt of OpenSwitch (http://openswitch.net/, > probaly http://openswitch.net/documents/user/architecture is more > relevant to this discussion). With the proposed patch we can have two > OVSDB instances each running on a TOR switch. One of the switches is > active and the other is a stand-by. The stand-by instance is constantly > replicating the active one. In case of a failure in the active, the > stand-by can take over and the control plane can be rebuilt from the > state stored in the database. > > I don't think the two approaches are in conflict with each other, > actually the complement each other. What I'm trying to figure out is > where they overlap (from a code point of view).
OK, I think I understand the use case better now. I'll try to take a look at the patches this week. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
