I think there are many open source distributed DB alternatives that can be plugged and implement the OVSDB DB operations API and behaviour.
Ben and Justin, i am interested to know whats your opinion on this suggestion, i think now is a good time to consider something like that. I can say that personally i have heard many supporting opinions from people regarding this and would love to know what you guys think about this. On Thu, Jun 25, 2015 at 5:07 PM, Russell Bryant <rbry...@redhat.com> wrote: > On 06/25/2015 07:21 AM, Gal Sagie wrote: > > Hello All, > > > > Currently OVN uses centralized ovsdb-server to serve the Northbound and > the > > Southbound DB to all the local controllers (sitting at each of the > compute > > nodes). > > > > It is a single point of failure and probably a major bottleneck to the > > operation of OVN in scale. > > Yes, it's definitely something we need to address one way or another. > > > I know there are efforts to make ovsdb-server distributed using Raft, > while > > i think this is an important effort i believe that open source is about > > being open to alternative and choices while reusing other open and > reliable > > solutions, this is why i want to suggest the following idea: > > > > Design the DB distribution layer in a pluggable manner, doing so, users > can > > pick alternate distributed DB options that are reliable and have been in > > the market for some time which also have performance optimizations. (Of > > course that the default plugin will use the ovsdb-server implementation) > > I think an important aspect in this regards is that different > > environments/setups with different scale needs can have different > solutions > > that fits them, the ability to choose which back end to use can help in > > these scenarios. > > > > If we analyze OVSDB, there are 3 major areas an alternate solution needs > to > > support: > > > > 1) The DB JSON schema itself > > Should be the same between all solutions > > > > 2) The OVSDB protocol features > > like: monitor (publish-subscribe) / transactions / garbage > collection / > > locking > > sync-verify (multi writes/reads for same values) > > > > It is important to note that any pluggable solution must support all > > these features > > > > 3) The connection between the client and the server > > This i believe can be pluggable as long as the messages that are > > exchanged (the protocol > > features) are still exchanged > > > > Then the only thing that needs to be modified is basically the client > > library which can map > > the API's to the client requests depending on the picked solution. > > > > Looking forward hearing your opinions. > > Do you have a particular alternative db in mind? Just curious. I think > it'd be easier for me to think through it with a specific example in mind. > > One way I've thought about approaching playing with this is to write a > ovsdb-to-<whatever> proxy that would run local to each ovn-controller. > Of course, I'm sure it's harder than it seems in my head. :-) It's > probably a waste of time since I don't think anyone would want to use > that for real. > > In any case, I do like the idea of still being able to use ovsdb-server > even if we started adding support for something else. ovsdb-server > keeps the deployment really simple since you already have it for OVS. > > I think some abstraction here would be nice. Even if ovsdb-server > becomes a distributed db, I suspect there would be a difficult > perception and trust battle. "Ugh, they implemented their own > distributed db?! NIH, etc .." "Ugh, a distributed db that nobody else > uses? I don't trust that." Those are the reactions I'm already hearing > talking to people about this stuff. > > -- > Russell Bryant > -- Best Regards , The G. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
