On Thu, Mar 31, 2016 at 2:29 PM, Russell Bryant <russ...@ovn.org> wrote: > > On Thu, Mar 31, 2016 at 11:26 AM, Marcelo E. Magallon < > marcelo.magal...@hpe.com> wrote: > > > Hi Ben, > > > > On 03/30/2016 06:13 PM, Ben Pfaff wrote: > > > > I understand the technical differences between the approaches. My question > >> is whether high availability is your actual goal. If it is, then it > >> probably does not make sense to have multiple implementations. If you are > >> trying to accomplish something else, then it could be that there is > >> something complementary about the two implementations. > >> > > > > I believe the two approaches are complementary. > > > > Like I said, the proposed patch aims at having a stand by database > > available, but since there's no proxy or anything like that, if the active > > database goes down, clients would have to reconnect. Ideally, after > > failover, the stand-by database becomes the active and clients can reuse > > the same connection parameters, but a reconnection must happen. If someone > > is interested in filling that gap, haproxy is an option, but I have not yet > > tested it. Same thing applies to a Raft-based solution. > > > > What you are doing with Raft is complementary in the sense that you can > > have six database servers, expose three of them to the clients and the > > other three become stand-bys for the three active ones. If any of the three > > actives go down, the corresponding stand-by steps up. With Raft, with 6 > > active databases, you can loose 2 (4 are needed for consensus). With this > > approach you only have 3 databases in service, but you can loose all three. > > Obviously you can come up with other topologies like 3+1, or 5+1, etc. The > > proposed patch is the "+" part in that design. > > > I don't understand the value of combining the two in the same installation. > > This all just sounds like an active-passive versus active-active HA > solution. Active-passive seems a bit easier to implement, but I would > always prefer the active-active solution if it's available. > > The one thing this approach would provide is an HA solution for 2 nodes > instead of at least 3. We're already using at least 3 nodes for HA reasons > in all of the environments that I care about for my use cases since we need > 3 for other active-active solutions. > > Do you have a requirement for a 2-node solution? Could you expand on your > use case? > > -- > Russell Bryant > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev
I agree that 2 or 3 nodes doesn't matter for a SDN controller cluster deployment. For my understanding the major point of this patch, compares to raft, is to sacrifice consistency for performance. We don't know for raft performance penalty yet. Assume raft performance penalty is not negligible, would it make sense to add NONBLOCK option (configurable) to raft implementation for customers who prioritize performance over consistency, rather than a completely different implementation? Regarding active-active, would raft be advantageous that it can serve read requests by any standby node, and redirect write requests to the leader? -- Best regards, Han _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
